Introduciton
In this blog post I will introduce some of the concepts I will be using to code the games I'm developing. Any readers should note that the actual code or specific algorithms mentioned in the next few blog posts will not be provided until after the project has been finished due to the possibility of plagiarism being committed. Using the FRDM K64F board and a Nokia LCD display I am going to be developing firstly a simple snake game and then a more complex physics based jumping game. In a previous blog post I went through the specification of the project and so for clarity the specification is shown below.
Specification
- The device will be powered with a 9V PP3 battery
- A 9V to 5V switching regulator (MC34063) will be used to step down voltage
- A Nokia 5110 LCD will be used to display the game
- A joystick and two button shall be used as inputs to the game
- A Piezo buzzer will generate sounds and tunes appropriate to the game using PWM signals
- The joystick and buttons will be located on either side of the screen to allow easier user input
- A potentiometer will be used to change the volume of the device
- A green LED will be used to display the status of the device (Power LED)
- A Menu system will be created to handle the user selecting difficulties, games, high scores etc
- A ‘snake’ game will be made as a backup game in case of time restraints
- A physics based platform jumping game will be made in the style of ‘doodle jump’
- The physics based platform jumping game will contain several different difficulties
- High scores will be stored on a micro SD card and accessed through a menu
Menu function
From this list it is clear that we are going to need several different building blocks to make up the code. The first is a menu system to take user input of the joystick and buttons to choose different options. Many of these menus are going to be similar in their layout because the Nokia 5110 LCD is only able to coherently show 6 lines of strings, each line being no more than 14 characters long. Therefore, in order to keep repetition of similar code to a minimum, a menu function can be created that requires certain inputs and will handle the user interaction for us. The basic layout of each selection screen is going to be as follows:
Title <-- Non-selectable line
>> Option1 <-- Icon for showing the currently selected line
Option2 <-- Selectable option
Option3
Option4
Option5
This menu function will require 6 strings and since we know that these strings cannot exceed 14 characters then we can make an array of strings, each string being an array of 14 possible characters. There is also the option fo allowing the user to enter values for the offset that they would like each string to have from the left hand side of the screen. This could come in useful for allowing easy manipulation of the offset of the title or allowing one of the options to stand out. Whatever the reason I will still provide the option of doing that. Now that the input to the menu function is sorted we can think about the output of the function. In our main code we would like to call this function and wait for a response that would indicate the selected option, so the output will be designed to give an integer number between 0 and 4 that indicates the option selected.
Now that the general purpose and layout of the function has been discussed I can make a list of the things this function is required to do:
- If the user moves the joystick in either the UP or DOWN directions then the screen selection will change the selected option accordingly.
- Depending on what is currently selected, a graphical indicator (>>) will be used before the selected option.
- The function will return the currently selected option as an integer between 0 and 4 when either the joystick button or button A is pressed.
- When button B is pressed it will automatically return an integer of -1 and exit the function.
When writing the menu function code several other factors had to be taken into account which are briefly explained here:
- To pass arrays from one function to another requires the use of pointers since an array is just a pointer to the address that contains the first indexed value of the array.
- Small de-bouncing delays needed to be added after the user presses a button so that a button flag is not kept on after the function has returned.
- Other small delays were needed between iterations of a main loop so that scrolling when the joystick is up or down happened at a reasonable pace.
- It becomes necessary when calling this function to check for when it returns -1 (when button B is pressed) rather than assuming it will return a selected option between 0 and 4
