Mark Carroll and Alex Hess
December 17, 2010
For our final project, we were presented with the verilog code for the game Red Hawk Duels. This game was run on a FPGA on a DE2 circuit board. A FPGA is a circuit that is reconfigurable after it is manufactured. The game consisted of a two dimensional battle between two space ships. Two players battled each other by connecting their DE2 boards to one another with an Ethernet cable. Each player received information about his or her ship but did not receive anything about the opponent’s ship. The problem with the game was that it was very hard to interpret information from the game and control your ship. The player was given information from a series of LED’s and seven segment displays on the DE2 board. The player controlled the game by flipping switches on the DE2 board. In both cases, understanding the game was not intuitive and required that the player read directions to know what everything represented.
The goal of our project was to modify the Red Hawk Duels game so that the player can be more competitive by making it easier to control the ship and understand the information received from the game. To improve how the user received information, we proposed to implement a VGA output to a computer monitor. The monitor would display information that was not originally included on the DE2 board. To provide the user with an easier way to control the game, we proposed to implement controlling the game with a keyboard via the PS/2 port on the DE2 board. Finally we proposed to implement a macro in the game that would cause our ship to automatically respond to situations on its own.
Final Design Setup
Here you can see our final setup. The DE2 board is on the bottom left. It is connected by PS/2 port to the front keyboard, by VGA to the monitor screen, and by Ethernet to the game controller(not shown on another DE2 board). Also not shown is the crystal array.
We designed our VGA to make it easy for the player to gather information from the game. Our VGA told the player the following information: his or her location in the playing area, what direction he or she is facing, the amount of power that he or she will receive within the next minute, a clock synchronized with the game clock, power amplification levels for every crystal combination, and finally if the sensor was currently pointing at another ship. This was a large improvement because the DE2 board had originally only told the player what the sensor was detecting.
Since the VGA was the largest aspect of our project, we created it using a spiral model for design. We started by implementing basic features and then added more and more detail as we progressed. Since building a VGA from scratch would be difficult, we used a VGA adapter circuit that was written by John Loomis from the University of Dayton. We had to read through his code and figure out how it worked so that we could modify it to display the information that we wanted. John Loomis used 8 by 16 blocks of pixels to display letters on his screen. We modified his code to help us display all of the characters on our screen and to create a box for the playing area.
To display the current ship location and a visual line of the direction that it was pointing, we had to modify the circuit so that we could turn on individual pixels. The ship was displayed using a 10 by 10 grid of pixels. To display the line we first had to calculate the angle the ship was facing. You can read how we did that in the angle section. We then used a linear equation to determine which pixels to turn on.
Our VGA also contained a timer that was synchronized with the timer on the game controller. We used two state machines to display the time along with a counter and the 50 Mhz clock to know when to change states. The first had 10 states to display the one's place and the second had seven states to display the ten's place.
This was our initial design for the VGA screen.
Diagram of Ship
The ship was 10 by 10 pixels. We used the 4 by 4 pixel from the top left corner as the center of the ship since there is not an exact middle pixel on a 10 by 10 grid. This center pixel is where we based our ship location within the playing field.
VGA Screen Output
This was the final design for our VGA screen. The "Ship Detected" line is not currently lit up due to the fact the sensor is not pointed at another ship.
Our keyboard module was a modified version of John Loomis'. Just like we did with his VGA, we had to step through hid code line by line to understand how his code worked. This wasn't as bad as the VGA display because the keyboard had a lot less code and in simplest terms just read in the scan code of a particular key.
Once we knew how his code worked, we then started brainstorming on how to check that a key was pressed and what to do when a certain key was pressed. Since we knew each key had a corresponding scan code and a corresponding break code for when the key was released, a finite state machine was proposed as a solution to this problem. The idea behind the state machine was have a state for every key we wanted to carry out some function and a state for when no key was being pressed. Loomis used a few registers he called "history" to keep track of the scan codes coming in and we utilized these registers to know when a key had been pressed and released (our state diagram below shows the state transitions). The keys we decided to use were: W for going forward, A for turning left, D for turning right, and SPACE for firing our cannon. When this was implemented and tested, we received a critical warning about our path being too long. Through the numerous tests we ran on our keyboard, this did not seem to negatively affect us so we ignored it. However, had we had more time this would have been something we would have liked to fix.
The implementation of a keyboard made our ship much easier to control and more user friendly for those accustomed to a keyboard instead of switches.
State Diagram for Keyboard
This is the state diagram that we drew while we were designing the state machine for our keyboard
To calculate the angle of our ship, a state machine with 14 states was made. Four of those states represented the hundreds spot in the angle and the other 10 represented the tens spot. We initially encountered a problem with figuring out how to sync our angle with the angle being displayed by the game controller. However, with some suggestions from Brian Hunt (another Red Hawks Duels participant), we were able to find a solution to this problem. We discovered a state of the Ethernet that sampled our current angle to display our ship on the spectator screen and input this into our angle calculations finite state machine. For our angle to change, we had to be turning the ship (with either the 'A' or 'D' keys) while the Ethernet was in the sample state. This seemed to sync very well with what the game controller displayed on the VGA.
We now wanted to make it easier to see what way our ship was facing. A line coming out from the front of our ship was suggested as a possible solution to this problem. In order to construct such a line, we knew the slope of the line at every given angle would need to be calculated. Bob Cole, another participant in the ECE 287 Red Hawk Duels, assisted in some of these calculations. The calculations consisted of figuring out the (rise/run) at every unique angle we wanted to represent. To draw the line, we took an arbitrary x-coordinate of our ship display and subtracted the x-coordinate that our ship was currently at and compared this to an arbitrary y-coordinate of our ship display minus the y-coordinate of the ship. We then took our constants, say run = a and rise = b at a given angle, and multiplied the x and y parts of our equation by a and b, respectively. This yielded an equation that looked like this: a*(x_coord - ship_x) == b*(y_coord - ship_y). Whenever this statement was true, we colored in that pixel red, otherwise we left them black. To prevent the line from going across our entire VGA display, bounds checking was added. We never let the line go past our boarder (depending on which side our ship was looking at) or extend past the y-coordinate of our ship. This yielded a line that made it easy to visualize where we were going.
Power and Crystal Array Calculation
The crystal array was a series of eight wires that are connected together in a linear pattern. The wires imitated the way an array of real crystals amplifies a beam of light traveling through them. The ship received varied levels of power based on the order that the wires were put together. The ship required power for moving forward, shooting, and running basic life support systems. The game ended when a ship could not generate enough power over a particular timeframe. Therefore it was important to be able to determine how much power your ship was generating and which crystal array order would generate the most power.
The game controller provided information about the power amplification between each crystal array. It was then just a matter of displaying this information on the screen. Calculating how much power the ship would receive was slightly more difficult. To do this we had to determine which crystals were connected together. The base power was 10 KW per minute. Finally we added the amount of each crystal amplification to this number.
While we were designing the project, we could not come up with a fully autonomous macro that would perform better than a human controller with the information that we had. However we did come up with one macro that worked well in slow movement situations. We designed cannon to automatically fire when the sensor detected a ship. This worked very well if both ships were moving slow but usually missed if the ships were turning or moving too fast. We also found a glitch in the game controller that would give us a false positive on ship detection if the sensor was pointed at a corner of the playing field. To prevent unnecessary power loss, we designed the macro to be able be turned on or off via switch six on the DE2 board.
Note: Keyboard and VGA do not include all files necessary to run this project. ship_proto.zip should be downloaded for a full working project.
In our project, we were successful in completing the three main project goals that we had originally proposed. We successfully implemented the VGA controller on the DE2 board. We were also in successful in controlling the ship with a keyboard through the PS/2 port on the keyboard. The macro that we implemented for automatic firing worked as well although the sensor did not always receive accurate information. Overall our project was a success. Our improvements to the original game helped us to play better and we made it to the final round of competition.