Flappy-Ship: A Two Week Tale.. #1

Starting a new Project is always a nerve-wracking idea but everything has to start somewhere.

Week One:

This Project is our attempt at a "One-button Game".

To create a playable level and some obstacles for the player to hit.

Ideas:

The first step to any great game is an idea, which my partner and I came up with a handful.

I sketched my ideas onto a notepad with small annotations.

• 1st idea: Similar gameplay to games such as Flappy Bird and Mario. Where dodging obstacles throughout the level was the main goal. However, unlike Flappy Bird, we opted not to use gravity to make the Player fall but rather allow the player to control their vertical position by moving their mouse up and down.

• 2nd idea: Gameplay similar to the mobile game Super Mario Run, the player runs through the level and has to jump over obstacles but obstacles do not cause damage, only enemies. However, I couldn't think of any interesting mechanics to separate it from the game and I didn't want to make a copy of Super Mario Run so I scrapped this idea.

• Spaceship overlooking a Larger ship where a political peace talk was occurring and the player is stationed to pay attention to threats. I took inspiration for this game from games like 'Please, don't touch anything ' and the cockpit from Metroid Prime 3. The main premise would be that there would be a big fire button and the player is instructed not to press it but if they do press it other panels open and they can do other things, one of which would be to shoot the ship. However, I wasn't too confident with doing this within the 2-week deadline and wasn't confident in making the gameplay enjoyable.

Metroid Prime 3: Corruption

• A museum, with the player acting as a security guard stationed at his post. The player would have to look at the behaviour of the visitors and determine whether they are attempting to steal. However similar to the previous idea, I felt that it was above my skill level for a 2-week project so I scrapped this idea.

• Partners Idea: was a first-person shooter similar to those arcade games, where the player's movement is on rails. The only 'input' is aiming and shooting.

We both agreed on the first idea for 'Flappy Ship' as it was within the scope of a 2-week project and that we liked it the most.

Originally, we had planned to work in unreal engine 5 as it was my partner's preferred software. However, I had not used the software before, which posed an added challenge of learning unreal in 2 weeks. After a couple of days, we decided unity would be the easier option since I have used it in the past and we would be able to produce something playable within 2 weeks.

Moving the player, Boosters engaged:

For our game, we wanted to give the player the ability to use the mouse to move up and down. Since I had not used the mouse as an input, I decided that this would be the most challenging.. and it was.

My first idea was to get the position of the mouse and the position of the Player object and compare them, if the value of the mouse position was too high or too low compared to the object I was going to apply a relative force either up or down. Unfortunately, I could not figure out how to do this by myself and could not find a method of doing this online so I looked for a different approach.

This approach included finding the mouse position and drawing the object at that position, which worked in giving a similar feel I was going for, however, the speed at which the player moves is dependent on the dpi of their mouse. Players with a higher dpi will be able to move the Player much faster than those with a lower dpi. This was the first feature I couldn't find a fix for and decided to move on due to time constraints.

I followed this quick tutorial:

This resulted in this script:

This script allows the player to move anywhere on the screen if they point their mouse at that point. We wanted to keep the player in the middle of the screen. I asked my personal tutor for some advice and he suggested zeroing the mousepos.x . This made the player object be placed on the left side of the screen. This inspired me to instead use the width of the screen and divide it by 2 so the player would be in the middle. Since this feature uses the camera, I think it's only right to talk about the camera next because that also gave me a headache...

Camera: Viewing the world

The original plan was for the player to move forward and for the camera to follow the player.

To do this I added the cine-machine package to unity and made the main camera a follow camera with a cine-machine brain. This created multiple problems, however.

The first problem encountered by this was that the camera and Player object would begin to move away from the level together. I fixed this by changing the binding mode on the camera from Lock to Target to World Space.

The other problem with using a cine-machine camera is that it will follow the Player object if they go too high vertically, which would allow the player to go over the cave level if they went high enough so I wanted to limit this.

To achieve this I decided to change the approach we had taken towards player movement. Rather than the player moving through the level, I decided to instead, make the level move towards the player. So I swapped out the cine-machine camera for a normal stationary camera, so it did not follow the player. This was not the best way I could have done this, as it presented issues such as every object placed in the scene had to have the script that moved them, which caused some issues later on when I forgot to add them. Instead I perhaps should have kept the follow camera and, limited its movement to one axis, so it just followed the player left to right or even if I couldn't get this to work, I could have set the player and a stationary camera to move at the same speed to the right.

Collisions: Hit and run

The collisions for this game were nothing special, just some box colliders and mesh colliders.

I used OnCollisionEnter as well as a switch statement checking for an 'Obstacle' tag on objects colliding with the player, to initiate the player 'death', which consisted of playing audio, and particles, stopping player movement and reloading the level. I wasn't sure how to go about creating my own particles so I used a pre-made set of explosion particles from a unity 3D course I did over the summer.

Conclusion

Overall I felt that this first week has been very productive and although I had problems, I felt that I overcame most of them without too much effort. We were able to make a playable build of the game so next week will be focusing on importing assets and making the level look good.