Red Devour - Timing Game

Jinior Smith

Overview

The goal of this project was to create a 2-button game which has you "stop" when the screen has as much blue as possible without being entirely blue. If the screen does become entirely blue, it is called timing out, and you get a score of zero points. Another goal was to add the "back button" feature, which also wants you to be as close as possible to blue, but instead of ending the game, it adds a multiple of the end closeness to your score. This bonus allows you to score significantly more points than you would with just the "stop" button. To clarify more directly, your score is (approximately) as follows:

stopCloseness * Σ ^{numBackPresses} _i=0 closenessAtPress / numBackPresses

This is not 1:1, but it establishes the concept. It’s not multiplying for each press, but more presses make more score, but more bad presses lower score and can be more harmful than just not pressing it to begin with. There is also a home screen, a score screen, and 2 information screens which explain the game. The system runs using a finite state machine (excluding interrupts) to determine what actions to perform at any given time, and you can only do screen-specific actions on each screen.

Hardware

The module is based on BG22-EK4108A Microcontroller Development Kit from Silicon Labs and color LCD with 96x64 resolution with built-in SSD1331 driver. It also has 2 buttons for interfacing with the user.

The major software modules used in my project are as follows:

• CMU: Clock Management Unit (CMU) Peripheral API
• EMU: Energy Management Unit (EMU) peripheral API
• GPIO: General Purpose IO (GPIO) peripheral API
• LETIMER: Low Energy Timer (LETIMER) peripheral API
• RTCC: Real Time Counter (RTCC) peripheral API
• TIMER: Timer/counter (TIMER) peripheral API
• USART: Universal synchronous/asynchronous receiver/transmitter (USART/UART) peripheral API

Home screen		Help screen 1		Help screen 2		Score screen

The gradient in the background is the same for every image. The black on the score screen is for consistency with the text module I didn't bother figuring out.

Software

Parameters of Gameplay / State variables

To produce results, we are going to need parameters of gameplay, and the ability to track button presses, time, and the state of the system. What naturally follows are the following variables:

• Track Button Presses
  • rPressed: boolean which holds true if right button is pressed, false otherwise
  • lPressed: boolean which holds true if left button is pressed, false otherwise
• Track Time
  • Cur: Establishes exactly where you are in the timer for each frame of the screen
  • Max: Establishes how far cur can go before the player times out
  • Sleep Timer: Ensures frames are kept at a consistent rate
• Track State of the System
  • State: Char which represents what state the system is in

Mechanics of State Variables

• Track Button Presses
  • Whenever input is needed to be understood, a sub-method called inputSensing() is called which updates values wherever relevant.
• Track Time
  • Whenever a frame is rendered, cur is incremented. If at the end of the frame, cur = max, then you time out. However, you have the entire rendering time of the frame to hit the button, and within this smaller timeframe there exists a variable subCur which tells you when within the frame you hit the button.
• Track state of the System
  • The following states include:
    • 'G': Transition to Game State
    • 'g': Active Game State
    • 'H': Transition to Home Screen State
    • 'h': Active Home Screen State
    • 'S': Transition to Scoring Screen State
    • 's': Active Scoring Screen State
    • 'I': Transition to Info Screen State
    • 'i': Active Info Screen State
  • Every state is set up with its own actions, with its own initializer method. In order to actually *switch* to a state, you have to set state to the capital letter corresponding to it. The mechanics of each method are pretty 1:1 with what you'd expect, the game state just performs the previously mentioned operations, the home screen is just an image, the scoring screen says the score, and the info screen lets you choose between 2 images to look at

Other Operations

In order to actually use these states, you have to have certain functionality. Trivial ones won't be mentioned, but important ones will be.

• writeImage(img*, x, y, h, w)
  • This method writes the image based upon the dimensions of h and w and the contents of the img array
• randomMax(seed)
  • This method generates a random number 46-95, for use of Max. seed gets incremented at almost every game action, so you won’t get stuck on the same size ever
• rgbToInt(r, g, b)
  • This method takes 3 unsigned unformatted integers for each value and converts it to the SSD1331 approved format for rendering on the screen instead of the standard 32 bit RGB notation
• getRGBAt(x, y)
  • This method takes a location on screen, finds how far away from the center it is, and then gives it a red/blue inversely proportional brightness depending on how far you have progressed + how close it is to the center, as well as having a certain amount of green to represent the number of back presses at any given time
• Button_Callback(pin)
  • This method is an interrupt, which activates the instant the button is hit. It is used for the precision of the timing on back and stop button presses so the game doesn't lag you out of something you can't control.

Final Thoughts

I really liked the end result of the getRGBAt(x, y) function, as it made the gameplay visuals unique and exactly what I was looking for, and it was the entire reason I decided to make a timing game in the first place. This project was a thinly veiled attempt at masking the desire to make a fun interactive gradient :). Regardless, there are some things I would do differently if I made this project again. First off, I would recommend not using the integrated SSD1331 system's image renderer, as the images it takes have to be pre-loaded with every pixel and if you're dealing with things at the pixel level, you might as well do it yourself and save yourself the headache of trying to learn the system. Additionally, I would recommend avoiding splitting the location of where your logic is stored. Pick either the state-based methods or interrupts, but not both. I recommend going purely interrupt driven, however it is not what I ended up doing. This results in what I believe to be a less responsive system, sadly. Also, I would have added a feature where the longer you held the 'back' button, the more points it is worth, but adding a limit to how long you can hold it for and some screen effect alterations to indicate how close you are to expiring it. That gameplay feature would have made the system a bit more interesting.

Downloads

• Project file
• Eagle PCB layout