Game development Weeks 1 and 2 Devlog

Patrick Work:

My main task for this week involved defining the movement of the player. To this extent, I have made functional movement for the player allowing for precise collisions in the setup environment. The movement has a bit of a floaty feel to emulate the spaceship drifting feel, yet will not feel lagging when precise movement is needed in combat, as the lingering acceleration is removed if the player needs to quickly head another direction. 

Alongside this, I decided to spend a bit too much time working on the project. I've added cinemachine cameras to allow the player to switch the camera between rooms and hallways. While doing this, I also made the closing gates between rooms, trapping the player in until the enemies art defeated. I'll work on this system further when the enemies are further developed by Liam. 

I've designed the map layout for the game as seen below, which James will begin working on shortly. 

I've also worked on some cutscene art to explain the story to the player briefly before shoving them into the level, seen here:

This isn't finished, as I need to make two more pieces of art for the cutscene, but I do not know what the player model looks like, and will wait until such to draw the rest.

I also added a shader holograph seen below, which will be used for the player portrait in the ui, to give it just a slight bit more of a spacey feel, and to add more personality to the player, I added a dialogue system for them, which lets them speak during events, which will also help give personality to the player, and explain away events and such. below, you see their war cry when they enter a room (1 of 5 dialogue options). also, the text renders above solid objects, so it will not be obscured by the walls.

Here is a full list of things I've worked on for reference:

player movement and collisions (including diagonal), player facing direction, camera switching between rooms, gate toggling in different rooms, locked gates and keys, simple bullet shooting, bullet collisions functioning (doesn't overlap with player or other bullets), opening cutscene art + fade to black transition script, enemy spawning between rooms and toggle active for better performance, dialogue system for player, including ability to render text over objects, hologram shader effect for the player portrait in the ui, drawn map layout


Liam Work:

In this week, I worked on programming enemies’ behaviour. In our game there will be 3 enemies that do different things. The first enemy I worked on is a Turret. This enemy is the simplest to program out of the 3. It’s a stationary enemy that shoot at the player periodically. We did have a prototype model of a Turret but there were some issues with its orientation when it was imported in Unity, making it upside down when it starts shooting. So, I’ll use the ship model to demonstrate how they work and same with the other two enemies. I didn’t have many issues with programming this behaviour, but it may need some tweak when we use the model created by James.

The next enemy I worked on is the Rifter. These enemy will move around and shoot periodically at the player. It will keep its distance, so when the player gets closer to the enemy, it will go backwards, and when the player moves away, it moves towards them. I also made it so they are strafing, making it harder to hit them, giving a challenge to a player. This behaviour will need some tweaking once we get our level layout completed, to ensure they don’t hit the walls or obstacles.

 The last enemy I worked on is the Mosquito. These enemy will dash at the player. Once it starts its dash, it will stay in that direction and keep going until it hits a wall or a player. Mosquito has 3 different states - charge, back off and cooldown. The charge state is when it tries to charge towards the player and when the charge state is finished by hitting a wall or a player, it will go into a back off state. This is dependent on what it hits. If it hits the player, it will move back a certain distance away from the player, to realign itself for the next charge. If it hits the wall, it will move away from the wall but more of a bounce. When it stops backing off, it goes into cooldown, which starts the timer and once it reached a certain time, it will repeat the cycle. This enemy was the most difficult to program. I tried a lot of things I thought would work when it comes to getting the enemy to bounce off the wall but none of it worked which lost a lot of my time. So, I used ChatGPT to help me get the enemy to bounce of the wall and it uses some things I never used before, and it works as we wanted (The ChatGPT conversation is linked at the end of this section). At the moment, during its cooldown, it is still and planned to make it move around sometime next week so it’s not an easy target to hit.

I enjoyed programming these enemy behaviours and I feel and I have better knowledge on how I can implement AI. Next week will be focused on implementing a health system and doing more work on the enemies behaviours. 

ChatGPT conversation:

Mosquito Wall Collision Behaviour - https://chatgpt.com/c/68087059-a224-8002-9c52-b27720a24ef3

James' Work:

To start with I got to working on the environment using the unity terrain tools. To help get the layout correct I applied the map design that Patrick made and used that as a template for our terrain.

Once I had made the terrain, I got to creating on the models. I started with the player's model, so I took inspiration from the prototypes that I made during the early stages of planning (shown below). 

For my design I have somewhat combined the right two models into one. We wanted a central section of the ship for the bullets to come from, as we didn't want them spawning from thin air, and I felt that wings would look better than whatever I added to the sides of design two, so I made angular looking wings like what model three has.