Table of Contents
Introduction
We've all played the classic game of Snake, where a player moves a 2D snake-like line around a screen to collect items with its head to grow in size. In our version of the game, the snake moves around the screen by tilting the board's accelerometer around. The game is displayed in the terminal of a computer using a simple ASCII output. Besides the NXP FRDM-KL25Z board, we did not use any additional hardware. In this game, we coded in both C and Python, with C used for the board to poll the accelerometer as well as setting up the gamestate and game logic. From the board, the Python program takes in a serial input with data in a string that contains the coordinates of the fruit and the snake. The Python program is used to take in the data provided by the board and the C program to parse it and display it as an ASCII output in the terminal. Through this program, we learned how to read the reference manual, configure the hardware from the FRDM board, send and receive signals through a serial connection, and write software that takes in hardware inputs. It was interesting to learn how to integrate hardware and software together using two different languages and use interrupts to poll the accelerometer.
Video
System Diagram
System Description
Our program consists of two major pieces with all of the computing relevant to the game being done on the board in C, and the game display being done on the host computer in Python. The board handles all of the game logic including movement, gamestate, and score. Initially, all of the computing was to be done on the board, but early trials found printing strings on the terminal was too slow. This made the game unplayable, so a serial connection had to be made to allow data transfer so the host computer could display the gamestate.
Game Logic (mma845x_poll.c)
The snake is implemented as a linked list of sections. Each section contains three fields with the x and y coordinates of the section’s location on the board and the reference to the next section. This is implemented in mma845x_drv.h.
In order to poll the accelerometer data, our project was built upon already existing code for the FRDM-KL25Z board. This library project file provided all of the necessary drivers and initialization in order to properly utilize the accelerometer. Mma845x_poll.c was the provided file that contained the main() function, so most of the additions were made in that file. Inside main(), the helper function setup() is called to set or reset the required values. Afterwards, an infinite loop is entered where the accelerometer is polled every 0.3 seconds to determine the speed of the game. This was accomplished by making and calling the helper function delay(). After the delay, the accelerometer is polled and the data is parsed to determine which direction the user input. If the directional input passes a certain threshold, a direction is chosen as the user’s new_direction. Having a threshold allows for the board to only account for intentional movements. Once the new_direction is determined, helper functions game() and print() are called to calculate the game logic and send data over the serial connection.
Setup() is a short helper function that initializes all values for the game. The snake is reset and placed at the starting position and the fruit is randomly placed on the board. Fruit generation is conducted by calling the helper function fruit() and checking to see if the fruit overlaps with the snake at any point. If there is overlap, fruit() is called again until it is placed in an empty space.
Game() is the helper function that contains the bulk of the game logic. At first, the movement of the snake is calculated by using the new_direction data from main(). The movement of the snake is calculated using this value alongside the value of direction. In the game, the snake can not move up if it is currently moving down as that would cause it to turn on itself. Conditional statements were created to catch the case of turning around, so this error would not occur. After the new coordinates of the head of the snake is calculated, the coordinate values of the linked list are shifted up one section to account for the movement. At the end of the linked list, it is checked whether the snake’s head is on the fruit and the snake is elongated at the end if necessary. After the snake's growth and movement is complete, game() then calculates whether the game is in a lost state. The head of the snake is checked to see if it has gone out of bounds (collided with the wall) or collided with itself. If it has, the value of gamestate is updated to represent the lost state.
Print() is the final helper function that sends over data over the serial connection. If the game is in a lost state, the function sends over the final length/score of the snake and a character that is used to tell the function in Python that the game is lost. If the game is still ongoing, print() sends over the coordinates of the fruit followed by the coordinates of the snake from head to tail. All coordinate values are sent as 2 digit integers with the x coordinate followed by the y coordinate.
Game Display (snake.py)
The game was displayed using an ASCII output into the terminal. We used a Python program to parse and display the game’s data because the output to the console from the board directly is too slow. From a provided library code for taking in the serial input, we were able to parse data regarding the game state given as a string into the terminal output on the computer screen. The string data that is given over records the two-digit x-y coordinates of the fruit and the snake as well as the current score of the player. The first 4 digits are the coordinates of the fruit given and the following digits in groups of 4 are the coordinates of each block of the snake. The end of the string has a new line character “\n” which signifies the end of the data input for the Python program. For example, the string literal “ 040512011202120312041205\n” would mean the fruit is at coordinates (4,5) and the snake has its head at (12,1) stretching through (12, 2), (12,3), (12,4), and (12,5). If the game is over, whether that be from hitting an obstacle (sides of the playing area or itself), then the character “q” is sent. The data is parsed through the Python program and then displayed using an ASCII created board that is shown in the terminal.
Testing
Accelerometer Testing (quick modification to display on the console)
We started by testing the accelerometer on the board as it would be the input for the game. We used the sample code in the SDK to get the accelerometer data and the provided serial python code to display it. We slightly modified the serial code to print just the character sent from the board to make it easier to read.
Game Logic
To test the game logic we incrementally added new features and used the serial code from before to check our outputs. We began by creating a fruit and one section long snake in set positions and checking that the right coordinates were printed. Then we started to add movement so first we printed out the direction the snake would move and then the new coordinates of the snake. After movement we added interaction with the fruit and expected the coordinates of the fruit to change, and the output string to be longer as the coordinates of the new sections of the snake were added. Whenever we ran into issues as we were implementing these features, we used the debugger of the IDE to step through the code line by line and check the values in the data structures to determine where it went wrong.
Game Display
The game display code has two main sections: one for displaying the game map and another for receiving input from the board.We tested the first section by providing predefined strings in the same format which the board should output and checking that every object was in the correct position. We also added temporary print statements to check that the code was splitting the input string correctly into coordinate pairs. The second section we tested after having working game logic and had it print the string it received as input as the game was played. After that worked, we integrated all the sections and played the game several times checking all the functionality as a whole.
Work Distribution
Before starting the programming, all members of the team took a look at and set up the library code for the UART serial connection and the accelerometer. After the resources were made known to all members, a zoom call was conducted to discuss the structure of the project. With the division of sections, programming began in a manner where one person shared their screen over the zoom call while the other members looked along and were involved in the discussion of implementation and sent snippets of code over that could be placed into the main programmer’s code. For the game logic in C, Chris was the main programmer, and for the game display in Python, Marek was the main programmer. This method was used for the initial writeup of the code.
When going to debugging and thorough testing, the work shifted to a more individual focused method with all members having access to the code. Communication at this point was done either in a zoom call or over a group messaging chat. When a minor bug was found, it was quickly fixed and made aware to all other members of its existence and its fix. For major bugs that could not be fixed quickly, it was made aware to all other members, so it can be discussed. This bug would be what all members worked individually on until it was resolved. If needed, the same method used for the initial code write up was used to think collaboratively. Testing was conducted in an individual manner and later notified the team so all edge cases could be tested.