Introduction: BitRunner FPGA Game

About: I enjoy firmware and low level programming

Create and play your own Bit Runner Game. No console or beefy computer required! Press the dodge button to Dodge incoming obstacles to achieve the highest score! This project is decently hard, a challenge for beginners but not for experts.
This was a CPE 133 final project at Cal Poly SLO. We spent about 2-3 weeks working on this, using a Digilent: Nexys 3 board.

Bit Runner -----------------
LEDs come down the line toward the red LED. When the red LED lights up, you press the dodge button to “avoid” the oncoming lights. The score displays on the seven segment display, which increments in every shift of the obstacles.

Step 1: Materials

Acquire the following legally:

FPGA board – If you want one that works for sure, use a Nexys 3 from Digilent Inc.

You can get it here: http://www.digilentinc.com/Products/Detail.cfm?Na...

9 LEDs – Be sure to order through-hole LEDs and not surface-mount ones.

Wiring – the easiest way to wire this would be with jumper wires, but if clumps of wires bother you, then going the extra mile by cutting and stripping your own wires will lead to a cleaner project.

1 breadboard – large enough to connect the LEDs and wires above

Step 2: Constructing the LED Board

Orient the breadboard such that components would be connected if they were at the same horizontal position as shown.

Now insert all the negative leads(generally the shorter lead) for all but one of the LEDs in the same row. Do the same with the positive leads on a row below. Now place the last LED above the most left LED in the row. None of the leads should be electrically connected to each other.

Now use wires to connect all the negative leads together. This connection will serve as ground.

Now use a wire to connect each positive lead to a programmable pin on the FPGA. Try to connect pins systematically so you don’t get lost assigning them in VHDL.

Finally, connect ground to a FPGA pin.

The board should look something similar to the photo. For extra reference, we labeled a breadboard with wire mappings and which pins on the nexys 3 they are connected to. These pins scan be referenced in the last picture, acquired from http://www.digilentinc.com/Data/Products/NEXYS3/NE... .

Step 3: Programming the FPGA

Using the Xilinix Design Suite you can assemble the files into a working system of modules. You can follow these steps here to get it. For a technical genius such as yourself assembling this should be no big deal, but if you need further explanations on the modules, there are comments within the uploaded vhd files. You can ignore the notes under each part in this step if you don't need an explanation on how to implement the module because you are such a technical genius.

One more thing before we get into this

For a clearer, or more in depth black box diagram.

- Download and synthesize our vhd modules

- Expand the synthesize option and double click on “View RTL schematic”

- Double click black box diagram to expand it

Part 1. Create a shift register for the obstacles. You’ll need a clock divider to make shift register obstacles run at comprehensible speeds.

- Initially, give the 8 bit shift register a ‘1’ to start off the obstacles.

- on every rising_edge(clk) after that

----- Shift the bits down by passing the (6 downto 0) to the (7 downto 1) of the “next” signal (lfsr_next) as we called it

----- Set the 1st bit of the “next” signal equal to the bit of the current register "xor" another bit of the current register

----- You can choose any two bits to xor, this will simply result in a pseudorandom order.

--------- It has some random properties, but the pattern repeats.

Note 1: SSEG decoder and Clk_div are given to us by our teacher. These modules were created by Professor Bryan Mealy at Cal Poly Slo. The sseg decoder takes an 8 bit number and displays that number in decimal on the seven segment display. The clk_div is a clock divider that stretches out the clk period. Just copy, paste that in. Warning: The sseg decoder may yield warnings of how the counter is unused. This is because the counter never reaches that high of a number to require certain bits. Thus vhdl optimizes those bits and spits a warning out.

Test that these modules work by uploading your program and watching the LEDs light up. If done properly, your brain should be thinking that the light pattern emitted is moving as obstacles to the left. In the event this is not true, check the breadboard setup, modules and your own brain.


Part 2. Create the Score Decoder. The module outputs a score based on the time, essentially it is a counter. No game is complete without a cold, unbiased way of distinguishing how bad you are in comparison to others. Be sure to create a module similar to sseg_dec.vhd so you and your judging peers can view the score on the seven segment display with ease.

- On the rising edge of the clk after being put through the clk_div, increment the score

Test if this works by simulating it. Ensure the numbers increment correctly. Then you can further test by sending your score decoder output to the sseg_dec to determine it works visually. The score should increase by one for every rising clock edge.

Note 2: When simulating the score decoder, the window of simulation is within a few nanoseconds, so reduce your clock factor to 1 for proper results. Otherwise nothing will seem to be happening.


Part 3. Combine Shift Register and the Score Decoder with a main module. Be sure to have the clock divider operating as the clock for both shift register and score. The end result should have a score that increments on every shift of the obstacles.


Part 4. Create a module for the button decoder. It takes in the input from a button and determines whether the player is in dodge state or not. This is required to prevent players from holding down the dodge button and dodging all the oncoming obstacles.

- This module can be represented using a finite state machine, represented in the attached finite state diagram

- Defaults to wait state

- If you don't press the button the state stays in wait mode

- If they do, then it goes to dodge mode and outputs dodge for a set time

------ This is determined by a clk which counts up to a certain number on rising edge (up to you)

- After finishing the dodge mode, it automatically goes to let_go state and doesn’t go back to wait state until the player lets go of the button.


Part 5. Create a module to check if the player is hit by the block and that the game is over.

- The game is over If the obstacle at the end is on and the player is not in dodge mode.

- If the game ends you can choose to reset the shift register and score_decoder, which we did

----- Or you can wait for a user input to restart the game

This was tested with a simulation file. We set the inputs to different combinations and visually confirmed correctness.


Part 6. Put this all together in you main module and run the game with your constraints file.

- The mappings of most the pins can be found on the board.

- For the LED wires that are to be plugged in, you’ll have to look it up on the website of the board. If you’re using a NEXYS 3 board, you can use our constraints/implementation file which comments what pins are on the board.

-Test this with simulation as well. It's easy to see what's happening with a simulated file since you can look at the outputs of the individual modules as well.

Note 3: You will get the same warnings as note 1 with some other modules for the same reason.


Part 7. Optional. (Mandatory if all the Parts before this were a breeze to you) Modify everything with a clock divider and the button decoder to take in the count (don’t do this for the sseg decoder). This way as the score increases you can pass a different count and speed up the game to increase difficulty.

Note 4: If you do this, you may get some extra warnings, stating that you have created a latch. Also the simulations were done before this, so you'll have to add those assignments if you wish to simulate after the addition.

Note 5: You may get a warning that some things are being sourced by a combinatorial pin. This is fine, it won’t affect the game.

Part 8. Uploading the bit file to your FPGA. Because despite all this work, your FPGA still does nothing. To do this download and install a program called Adept.

You can get it here http://www.digilentinc.com/Products/Detail.cfm?Nav...

Once you have installed it connect the micro USB cord to the FPGA and select the bit file. Then press program. If you have reached this part without skipping any steps then a tiny game we call our project should be sitting in front of you.

Step 4: Extra Challenges

We put a lot of passion into this game and couldn't ask for more. You can see the finished product in the link above. We really like the idea of this project because you can test your skills without having to worry about working with an external device. The focus is on the project idea, and what you know, rather than figuring out how a peripheral works. It ends up being a great project for practicing at the beginner level. Having said that, we know it could be improved and it doesn't contain much difficulty for non beginners. While great in its simplicity there is always more to do. Here are some things you can do to make your Bit Runner Game better.

Sound - Adding something as simple as beeps can let the game provide much better feedback. Try it out with a Digital to Analog Converter and some speakers.

Display - LEDs are great, but don't quite simulate obstacles in motion too well. Try upgrading the screen with a VGA cable and monitor or if that is too big, an LCD display.

Your own idea - Try making something that alters the game ...or not. It's up to you how you want this to continue.