Philip
Chou
Pauljames
Dimitriu
Kevin
Lau
Richard
Phipps
Amy
Tinsley
Lori
Tynan
Our initial concept for SpaceWars was a 3D version of the classic game, Asteroids. Four players would fight in space among flying asteroids. Play mechanics would remain faithful to the original game including asteroids which would explode into smaller, faster asteroids when shot and a frictionless flying model causing ships to fly in a constant direction. We quickly diverged from this concept in wanting to make the game team-oriented by having two teams fighting among the asteroids in a capture-the-flag scenario whereby each team would attempt to capture the other team’s flag. Feeling the need to make the game more exciting, we then moved from two flags to a single flag that each team would fight for in hopes of allowing for more dog-fighting among the teams. The remaining fragments of Asteroids were swept away after asteroids were moved to the back burner on our feature list due to time issues and the flight mechanics were changed to normal first-person-shooter-in-space physics in hopes that players could then actually fly the ships.
Once our SpaceWars concept was finalized in our initial design spec, the game remained relatively faithful to our vision throughout development. Some features were simply removed after seeing they would not make sense in our game while others due to time allotment. Some of these features are:
Originally, we planed to have a smart server controlling dumb clients. This seemed to be the easiest way to handle the networking as all game logic code would be on the server. However, as the game progressed, we realized that input was not very smooth and was hardly playable on some systems. Week after week, more and more game code was put into the client and less and less was handled by the server. By the final week, the client was in near control of the player’s game, telling the server what it was doing. The server simply acted as a broadcaster to let other clients know of each other’s actions. The server did handle scoring and flag pick-ups, however. This allowed for much smoother game play.
Unfortunately the sound implementation was not as robust as we were all hoping for. We did however get all the basic sounds done (weapon firing, thrusting, explosion...) that we had planned for in our original design. The sound implementation ended up being relatively easy and I think the main reason that we didn’t expand it was due to the lack of sound cards in the lab. By the time that we did get a sound card (which we of course thankful for) we were busy trying to implement other features in our game. We had planned on spending week 6 expanding our audio, but at that point audio didn’t seem to be the most import feature. Not to mention is was difficult to get everybody to agree on all the sound effects.
Our final game supported keyboard, mouse, and joystick input. In our initial design we were just planning on implementing keyboard and mouse input. However direct input allowed for joystick capabilities without too much extra work.
The graphics engine of our game didn’t change too much throughout the development cycle. This is due to the fact that there was no true “plan” for the graphics engine and was coded ad-hoc from week to week. A core object simply held other “modules” which implemented different features with each module in full control of its rendering. An attempt was made to implement a smarter rendering pipeline that would control all rendering which would make each module much simpler and easier to implement. However, due to lack of previous DirectGraphics programming, this attempt was not successful and was never used.
For the most part, our development remained relatively on schedule to our initial document. Every team experienced delays due to covering previously unknown territory and the requisite bugs encountered. Most of the time on graphics programming was spent figuring out how a feature could be implemented by reading newsgroups, message boards, and mysterious Microsoft SDK tutorials. Further, a delay in collision detections had a slight domino affect by pushing back other less important features.
Our group was divided into three independent teams of two people each: Graphics, Game Engine, and Networking/Input. Each team had the sole responsibility over its domain within the game. This worked out rather well and allowed for relatively quick and efficient implementations. Smaller decisions affecting only a single area of the game were handled by a single team, while the more global decisions were handled by the group as a whole. Our group was run in a democratic manner such that all decisions were made by a majority rule in the rare case of a disagreement. We did not experience any major disagreement throughout the entire process.
Each group member spent most of their time coding at their home. Therefore, most communication was done through either ICQ or email. The group also met at the computer lab at school twice a week to discuss any ongoing issues and to do multiplayer testing.
The code was also laid out in such a way that it was relatively easy for each member and team to not touch another’s file. Code was tested out before uploaded to CVS where we kept our working code. This sole difficulty of this process came about with multiplayer issues since it was next to impossible to fully test out code in a multiplayer environment on a day-to-day basis. Luckily, this was not a problem throughout most of the development.
Graphics programming posed serious challenges. The graphics team found that while DirectX was not extremely difficult, the implementation of specific desired features was a tedious process due to an extreme lack of help files. Reference files for the SDK were helpful in learning the basics, but in order to get a desired effect to work, web searching, message board posting and other researching was needed. An example is the skybox used in the game. There is no definitive skybox tutorial. Most of it was done in a trial-and-error manner. Further, there is only one available book on DirectX 8 at this time, adding to the fustration.
The Windows environment itself posed problems for members not familiar with Windows programming prior to this course.
Collision detection posed a few problems but was finally hammered out. While not a difficult process in and of itself, it falls under the same example as the skybox as far as needing a lot of trial-and-error.
Finally, the multiplayer aspect was difficult without a fully functioning lab to test out code. This made it a slow process to try out our game in its full capacity until the later stages of development.
Not too many tools were used outside of the program environment. The graphics team made heavy use of Photoshop and 3D Studio MAX. Better knowledge of these two programs would have come in handy, of course. While no one found the lack of other types of libraries a big hindrance, that’s not to say game libraries that handle collision detection and more advanced graphics pipelining wouldn’t have been appreciated.
For the most part, we are happy with the way the project went. The dividing up into separate teams worked out well for us; our team functioned well as a whole. That said, the big thing we would do differently is we would get the core game down much earlier. For instance, we should have worried more about getting four players up and running in the emptiness of space as our first priority. From there, we could then build a game up around this core. This would allow much smoother progression and allow for better testing as far as multiplayer issues go. As we did it, multiplayer aspects were not tested until later in the development cycle which came to haunt us at the end of the quarter.
Most of our members did not use any books, finding the SDK tutorials and the Internet a much better resource. This is due to the evolving nature of game programming, the lack of any “perfect” books, and the lack of time to read a large book for this course.
Of the books that were used, Game Architecture and Design was difficult to find and fell into the “not enough time to read” category. However, Beginning Direct3D Game Programming was a decent book going into slightly more depth than can be found in the SDK tutorials and covers DirectX 8. Finally, Insider DirectX was okay but not much more than a printed version of the SDK, although not necessarily a bad thing.
Take a light load (or no other classes)! Have fun but don’t ignore your other classes – you will be tempted! Get a stable, integrated game up early before adding any other features and work from there. Get lots of sleep before over spring break – you won’t be getting any during the quarter.
However, these are minor suggestions and the group found the class to be among the best taken with no real faults.