Bringing the Gun and Game Together
CSE181A Winter 2011
Progress Report for Week #8 (2/16/2011 to 2/23/2011)
Project Title: Super Spray
This was a pretty exciting week for our project. Our major, Computer Science and Engineering, according to the Donald Bren School of Information and Computer Science is “designed to provide students with the fundamentals of computer science, both hardware and software, and the application of engineering concepts, techniques and methods to both computer systems engineering and software system design.” This week, that statement became a reality for us. I literally had two IDE’s open, one developing the PC client side of bluetooth data transfer, and the other programming the microcontroller directly and working with how data transfer is managed on the hardware end.
When we envisioned our system for how the game would work, we knew the proper engineering approach was to have the microcontroller simply read the sensors, send the PC the data, and have the PC make the decisions for what happened in the game. This is the most flexible solution, because once the hardware portion is complete, any changes that might need to be made after testing the game can be done on the software side, rather than re-programming a microcontroller. In practice however, we weren’t sure if this was possible. Having never worked with serial communication before, we were not sure if it would be possible to send this magnitude of data at high speeds to keep the gun and game in sync with each other. Things continued to look bleak when we couldn’t get the bluetooth working for a while.
Once bluetooth was working, we wanted to just get a rudimentary implementation of our game up and running. In order to do this, we made it so the microcontroller simply sent one signal to the computer, the character ‘P’ for when the trigger was pulled. This ended up consisting of the microcontroller doing a whole lot of game data processing that we didn’t really want it to do, including keeping counts for how much ammo was left, the score, and other things that really should have been handled by the game’s code itself. It didn’t make sense to have portions of the game scattered between hardware and software.
This week, we got our hands dirty with the Bluetooth communication and refined our hardware’s code, and wrote a clean set of C++ code for the computer that links the two together very well. Now, our gun sends data to the computer, and the computer decides what happens, and constantly updates the microcontroller as to what is going on. Here is the breakdown below:
Data Sent from PC to Microcontroller
- The score: This is converted from an int into a char array and sent char by char (byte by byte) because the microcontroller has to display the score on the LCD in terms of characters.
- The current ammo count: Instead of managing the ammo on the microcontroller, the microcontroller receives the ammo counter and stores it. This is how it knows how much ammo is left for the LCD HUD.
- Game start flag: This resets all of the game’s values on the microcontroller to their default state and lets the gun get ready for a new game.
- Game end flag: Currently does nothing, but it may be needed depending on what we want on the LCD HUD when a game is not being played.
Data Sent from Microcontroller to PC
- Trigger state: When the trigger is pulled, we send a ‘P’ to the PC.
- Reload flags: The microcontroller is constantly polling the accelerometers and checking to see if the player is reloading. If the threshold is reached, it sends an ‘R’ to the PC, and the PC then increments the ammo counter. This, in turn, is sent back to the microcontroller so that it’s data is updated.
- Gun movement flags: Like the reloading, the accelerometers are also outputting data to the microntroller regarding the other axis’ of orientation. This way we can detect if the gun is being shaken up, down, left, or right. The microcontroller sends a signal ‘X’ or ‘Z’ alerting the PC alerting it of those actions.
In our game code, the pollForBluetoothData() is placed in a timer function and is constantly being checked. If there is data, it processes it accordingly and updates all of the values as necessary, namely the ammo, score, trigger state, reload flags, etc. These values can then be accessed seamlessly with methods to set() and get() each of those components. When the values change on the PC side, it sends the new values to the microcontroller so that the two are always in sync.
As for our game structure, we finally have a working state of our entire game in our development branch. After having moved around from task to task, It was really nice to finally put it all together and see it run. The entire code structure has been modified such keeping track of the shots fired is a lot better. As for our start screen, we finally have a nice looking splash animation in which you can see in the embedded youtube page below. So far, this screen takes you straight to a running game when you fire a shot. However, we will eventually modify it such that the user will be able to see the top 10 scores for the day listed on it as well as go back to the calibration screen so that if they errored in calibrating, they can recalibrate it without having to restart the entire game.
These two windows were the main focus for the week and below is a quick youtube click showing you a run through from turning on our game to actually starting a round. I apologize for the choppy framerate in the video. I was recording the screen through quicktime and I guess my graphics card or something couldn’t handle recording it seamlessly. Do not be fooled, the game actually runs a lot smoother than the video shows. Alright, here it is…
Another big project for the week was actually establishing a Git repository and utilizing the program to greatly increase the productivity of our work. It took a little bit of a trial and error to learn the small differences between Git and the normal subversion programs that we were used to. However, after working with Git, we were surprised at how good of a program it is. We were even able to create a Github account online so that everybody on the team could easily work on it without never having the need to work right beside everyone else. It is an amazing program, and we are fully glad to be using it in our senior design project.
If you are interested, are code is availaible to look at in the following URL:
We also had to make our poster for demo day this week! It was was kind of a bummer we had to make it so early, because we wished we had more pictures and information that reflected a finished product, but what can you do. You’ll all be seeing it in two weeks!
Hardware Goals For This Week
- Exhaustive testing of the bluetooth communication. See if any data is being lost, correct any bugs if found.
- Try to get the game playable to the point where we’re not using the PC’s keyboard to shoot, but actually the button on the microcontroller.
- Hopefully begin a more serious installation of parts into the gun, it’s crunch time.
- Considering making a makeshift cable that would allow us to still program the microcontroller even when it’s in the gun. Considering using a molex-like connector with 6 pins, which is the bumber of pins the ATmega32’s programmer uses.
Software Goals For This Week
- Finally actually get sound working in our project, its been something we’ve been pushing back for way too long.
- Fine tune the Start and Calibration screens, adding the highscores list and ability to recalculate the screen.
- Begin coding game sctructure, like when hitting a target causes the players score to go up.
- Perfectly merge the hardware code, now that it is in a testable state, with the game code.