1. Introduction
1.1 Project Summary
Our project is a space dogfighting video game where two players attempt to destroy each other using a variety of ships and weapons. The battlefield is a 128×100 pixel area on a TV, and a small planet resides in the middle, exerting gravitational forces on the ships and inviting them to certain death. The input devices are Sega Genesis controllers, which were chosen because of their signal simplicity and sleek look (which makes Nintendo/SNES controllers look dorky in comparison).
1.2 Motivation
We initially had some trouble thinking of an interesting project, and discarded several options that would have taken too much time or money. Since we are both avid game players, we finally settled on the idea of making a video game, since this would be something we would enjoy working on for 4 weeks. Next, we had to agree on which type of game to make; I proposed a 2-D dogfighting game because it is a time-honored but dying genre, as nearly all dogfighting games now are 3-D and aim for realism and complexity rather than straightforward fun. Thus, we aimed to create a game that is simple to pick up and learn, yet entertaining and challenging to master.
2. High Level Design
2.1 Rationale and Idea Sources
For our inspiration, we drew upon a variety of old classics in the genre; Joran has had significant experience in playing the mutiplayer online shooter Subspace, and I have recently introduced him to one of my all-time favorites in the genre, Star Control II. Both games featured the kind of top-down shooting action we were looking for, although SCII‘s melee mode was closer to what we envisioned our final project to be. In addition, we saw that last year’s ECE 476 projects featured a 3-player ship dueling game; however, its emphasis of that game was mainly on the impressive greyscale graphics scheme, and the actual gameplay elements were very simple. We felt that we could take a step in the other direction, and create a game with deeper gameplay, but less impressive graphics. Our goals were to implement several unique playable ships that had different handling characteristics and weapons, a planet that exerted gravitational forces upon the playing field, and a nifty zoom feature seen in SCII which would zoom in on the dueling ships if they were in close proximity. The end result was StarDuel.
2.2 Logical Structure
The game consists of a state machine with 3 states: Title, Menu, and Game. The Title state simply shows a splash screen featuring our game name and logo, and prompts a user to press a button. The Menu state is where the players select their ship type, and the Game state is where all the action takes place. Below is a flowchart of the game setup logic:
In the Game state, time is either spent updating the graphics display or taking in user input and calculating what to display next. We borrowed some of the display framework code from Lab 4, and modified it for our use. The processor time is largely used to output the TV display lines 30-231, and afterwards we are free to use to remaining time for computations. Here, we would execute 7 major tasks, each possibly split into several minor tasks. The tasks were:
1. Poll for player inputs
2. Update ship information
3. Update bullet information
4. Update explosion information
5. Check is zoom condition is met
6. Detect collisions between objects and endgame detection
7. Render everything on the TV output
Below is a flowchart of the gameplay logic.
Due to computational time constraints, we were forced to use an alternating scheme where all of Player 1’s tasks would be executed in a frame, then Player 2’s tasks would be executed in the next frame, and so on. The gameplay is still quite smooth though, and the difference from executing everything once per frame is not noticeable.
2.3 Hardware/Software Tradeoffs
In the early design process, we considered several Atmel chips for the project. From our experiences with ATMega32 in Lab 4, we noticed the small amount of SRAM available. As a result, we spent some time studying other chip possibilities, such as ATMega162, which supports external memory. However, from discussion with various members of the course staff, we found out that external memory is not supported on STK500. We would have to switch to STK200, along with changing of clock crystals, etc. In summary, it would have taken at least a week just to get this hardware working. In the end, we decide to forgo the external memory support, and use the week for more software development. We saw the limitation of the SRAM as a challenge and motivation for better and more efficent coding.
On the software aspect, based on our past experiences, we decided to break up the code, so that the code would actually be maintainable. Breaking up the code into modules will also allow concurrent development by both game creators, and reduce the time spent to merge code together. Furthermore, we also decided to try to program as much in C, and only program in assembly for video and time critical sections. This decision was based on the fact that C code is easier to read and easier to debug. We rather spend more time implementing features, instead of taking on the job of a compiler as well.
2.4 Relevant Standards and Copyrights
The display that we used was a black and white television, which follows the RS170 and NTSC video standards. RS170 specifies the voltage levels required to generate white, black, and sync signals as well as synchronization pulses in the horizontal and vertical direction. It specifies three different voltage levels (sync, black, and white) along with two sync pulses for horizontal and vertical alignment. The NTSC standard specifies that we need 525 lines per frame, 30 frames per second, with odd lines rendered separately from the even ones (interlacing). Instead of interlacing, we just repeated lines twice as done in lab, which cuts down on processing time but halves the potential resolution.
We based the design of our game on various classical spaceship fighter games, including Star Control II which has been publicly release under the GNU license. We give full credit to the Pam Levins and his programming team, as well as all contributors in the 3DO and sourceforge versions of the game.
Gameplay Design
3.1 Gameplay Code Organization
We implemented three types of ships, 3 primary weapons, and 3 secondary weapons/specialities. Each player’s ship is represented by a structure containing many variables, and at upon entering the gameplay state, we initialize most of the variables based on what ship type was chosen. Variables include ship x/y position, velocity, direction, ship type, weapon fire delays, and life remaining. In addition the the single variables, we also maintain arrays containing information about the ship’s bullets (at most 4 onscreen at a time for each ship) and explosions caused by these bullets. The index (0-3) represents the bullet, and the arrays contain information such as x/y position, direction, time left till self detonation, whether it is active or not, etc. The explosions have a similar setup within the structure as well.
Aside from these constantly changing variables, we maintain flash tables that store static information about the various ship and bullet characteristics such as turning rate, damage, max life, max velocities, collision radius, etc. Simply by knowing the ship or weapon type, a function could quickly look up the value of a certain characteristic from these tables. Of particular note is that the x and y accelerations for the ships (corresponding to each direction) have also been hardcoded into flash, since we didn’t want to do any intensive sine/cosine calculations. Bullet x/y velocities have been hardcoded similarly (we viewed them as massless, and thus didn’t account for their acceleration).
The bitmaps for all objects are stored in flash. This includes the planet, explosion animations, and ships/bullets. Our ships and bullets only can face in 8 directions (cardinal and sub-cardinal), so we created bitmaps for each direction.
The details of the structure and variable organization can be found within our code, which we have commented heavily. In particular, game.c, flash.c, and ships.h should be referred to.
Parts List:
Parts and Costs
Our major hardware components included:
- 1 AMega32 chip ($8.00)
- 3 Resistors (Free)
- 2 Genesis Controllers (Free)
- 2 DB9 Connectors ($0.45 each)
- 1 Breadboard ($5.00 each)
The overall cost of our project is $13.90
For more detail: Star Duel video game
