Frogger Inspired Game [Nov. 6, 2017]

Foreword:

This week we had to create a game using Processing and Arduino in conjunction with serial communication. My first idea was a game similar to Frogger, where the user would control one object and try to avoid the horizontal moving obstacles zooming in from the left. There are two safe areas at the top and bottom of the screen. When the player is in either safe zone the score is incremented but will not be able to be incremented using that safe area until the other one is visited. This was to remove the possibility of the player basically going in and out of the same safe area in quick succession and padding their score unfairly. If the player is hit by an obstacle the game is over and the Game Over screen is displayed. If the user wishes to play again they can press a button and the game will be restarted with new obstacles and reset score.

The serial communication part was fairly simple as I used the same code for the Etch-A-Sketch we created in class last week. The control scheme is the same: use two potentiometers to control the x and y position of the player and a button to trigger some event. So no problems were to be had there.

The hardest part was figuring out the logic for collision detection. All previous implementations of collision detection included fairly static items on the screen and only a few of them (for example: balls that would be moving, but the walls of the screen are constant). The problem was there were so many obstacles on the screen and the player could collide with them from any direction. Therefore to solve the problem I examined the cases. Either the player was coming from the right, the left, the bottom or the top of the object and so checked each condition in a series of nested if-statements. For example, if the object is within the bounds of another object from the right side, then if they were within the bounds of the object from the top then that is a collision. The same check has to be made for coming from the bottom as well and then these two checks have to be repeated but from the left side. This way all cases were handled.

I decided to add a score so that the game has some point to it (the way the score is calculated is described above), and a Game Over screen that shows the score and instructions on how to restart the game. The text() and textSize() functions were used to display text.

Finally, states in the game were all handled using boolean type variables so that the game would always know the state of different events. Is the game over? Has it been reset? Has this safe area been visited already? All these are stored in the boolean variables.

Edit: I added images for the player character. When you score in the top safe area the images changes to a downward facing frog sprite and when you score in the bottom safe area the image changes to an upwards facing frog sprite. I also added sound effects for when you die using the Processing Sound library.

Screenshots:

During Gameplay

Game Over Screen

Code:

Processing

Arduino

 

Leave a Reply

Your email address will not be published. Required fields are marked *