This blog posts concludes this project by describing some of the techniques used to code a physics based jumping game. Sadly specific code used for this project is not mentioned here to prevent plagiarism but will be posted later on in the year for those of you who are interested. Many of you will recognize the main idea for a platform based jumping game from such games as Doodle Jump that became very popular for their simple but fun concept. Instead of calling this game a super catchy title like "Platform Based Physics Jumping Game" I instead opted for something shorter like Plink, not least because this is a string that will actually fit on the LCD. The main idea is to jump the blob from platform to platform and avoid falling to your death while the screen scrolls upwards. At first I defined some of the different things that need to take place within the code. These were:
1 - Initial Physics Conditions
The initial conditions need to be a velocity upwards, an acceleration due to gravity downwards and a starting position in the bottom middle of the display. After some careful tweaking the best values for these parameters were
- Acceleration (0,10)
- Velocity (0,-25)
- Position (41,47)
After reading these values you might be thinking to yourself, why is the acceleration positive in the Y-axis and Velocity negative in the Y-axis? Surely that would give you an acceleration upwards and a velocity downwards which is the exact opposite to what you want! Well you wouldn't be wrong if the LCD display accepted Cartesian Coordinates with the X and Y axes beginning at the bottom left of the screen, however this is not the case as is shown by the figures below.
2 - 'Blob' animation
When the ball that is used to bounce up and down on the platforms actually hits the platforms it should perform a small 'blob' animation where the bottom of the ball looks like it becomes elastic on the platform. Some initial pixel art was done of these animations and for simplicity's sake there will only be 2 frames to the animation. The image below shows the ball that will be drawn on the display for all cases other than colliding with a platform and the two frames that should play when the ball comes within the right distance of the platform. The red dot here represents the centre coordinate of the ball.
3 - Collisions
An obvious requirement is that when the ball hits a platform it should bounce back with a constant velocity so that even if the ball impacts it with very small velocity then it will jump the same distance into the air that it would if it hit any other platform. This makes it so that the player can progress vertically through the game.
There was a decision to be made regarding whether or not the ball should collide with the bounding walls or whether a periodic kind of boundary should be used so the ball can go off one side and then appear at the other. For the sake of simplicity and so the game isn't made too difficult, the walls will be solid and when the ball collides with them it should rebound with the same amount of velocity that it hit them with.
4 - Movement from Pushing Joystick
The entire point of the game is to be interactive so this is a no brainer. However another decision needs to be made regarding whther the user should control the acceleration of the ball and by association the velocity or if the velocity should be altered directly. On one side of the argument, changing the acceleration will give a more real world physics based feel but might be slightly difficult to control accurately and on the other hand altering the velocity might make the game easier to control but would also remove some of the physics of the game.
5 - Screen Scrolling
When the ball reaches above a certain height (below a certain Y value) then the entire screen should scroll downwards to reveal more platforms but also to remove lower platforms from the game. In order to do this the code is written so that while the Y position of the ball is less than 14, every object has its Y value incremented until the Y value of the ball is no longer less than 14. This adds a nice looking scrolling effect that, coupled with the physics based motion of the ball, does a good job of smoothly transitioning the platforms down.
6 - Platform Generation
Instead of having a pre-allocated set of platforms already created up further than I think any player would be able to reach which would take up valuable memory and also limit the game, I need to create a function that takes the first already existing platform and randomly generates further platforms at differing X ad Y values above the previous platform. This allows me to have only an array of 20 platforms at any one time and when a platform goes off the bottom of the screen then it will be deleted from the array and a new one created. This also gives me control over the difficulty of the game because I can increase or decrease the range of Y values each platform is allowed to be from the last.
7 - Score Keeping
An easy way to keep score is to keep track of the number of pixels that the screen has had to scroll because this is a good indicator of the height somebody has reached and can easily be implemented int eh screen scrolling function where it is incremented like all the other variables.
Using these 7 initial ideas for this game I quickly created a prototype and fine tuned some of the variables. One thing that jumped out in particular was that if I added a small damping factor to the X-axis velocity of the ball then it would come to a rest after a short while which was much preferred to the previous case where it would continue in whatever direction it was already travelling in without slowing down. Another issue that was raised was the ability to change the difficulty of the game whether through the difficulty menu or by the height the player reaches. From a quick ideas search I came up with 4 basic ways of increasing or decreasing the difficulty of the game.
- Decrease Platform Width
- Increase gameplay speed
- Increase distance between platforms
- Decrease the number of available platforms
Sadly if the gameplay speed is altered then other factors like the damping factor begin to change how the game works because of the way it is implemented. Really, this leaves us with 2 methods of changing the difficulty since the last two are very similar and could be combined. This means that through the difficulty menu you can change the platform width and height difficulty is going to be done by changing the way new platforms are generated at different stages. The basic idea is outlined int he image below where there are 3 stages each with a different algorithm for generating new platforms.
PowerUps
The game as a whole works alright but lacks something exciting so I decided to implements power ups that would perform various changes to the game such as making the platforms larger or smaller or making the ball larger or smaller or even allowing the ball to bounce higher for a limited amount of time. Using pixel art I designed a power up box with a question mark inside it that would be printed on the display at roughly every 150 pixels of height:
When the ball collides with this box a random number is generated to provide a random power up (or power down in the case of smaller platforms) and after 100 pixels of height this effect will wear off.
Demo
Here are a few pictures of the working thing, apologies for the bad quality and blurriness. The first photo shows the starting position and the blurry mess in the middle is the ball in motion, don't worry this is not what it looks like in reality, just a too long camera exposure. The second image shows the power up box and the third image shows one of the consequences of the power ups, in this case a shrunken ball which lasts for 100 pixels.
