Post-Mortem

  • Developer:  Team 11 in Senior Design, Spring and Summer 2005
  • Number of Developers:  5
  • Length of Development:  8 months
  • Personal Development Hardware: 
    • Standard Home PC:  AMD Athlon XP 2400+, ATI Radeon 9550, 1GB RAM
    • Senior Design Lab PC:  Intel P4, Intel integrated graphics card
  • Software/Tools Used:  Torque Game Engine (includes in-game mission and GUI editors), Visual Studio .NET 2003 (minor C++ code changes), Audacity (sound editing), Paint Shop Pro (basic weapon skins), Tribal IDE (script file editing), Fraps (benchmarking), dbPowerAmp Converter (recording and convertingMIDI to .ogg)
  • Release Date:  August 5, 2005
  • Target Platforms:  Currently Windows PC (engine does also support MacOS and Linux)         
What went right:

  1. The Torque scripting language
The scripting language including with the Torque engine was pretty simple to pick up.  Since a large part of my coding dealt with the “feel” of the control, it was important that I be able to test changes quickly and easily.  Sometimes I wouldn’t even have to restart the full game to test things…I could just reload a level.

  1. Using the in-game mission editor
The in-game mission editor was also of great use to me, as I worked on placing objects throughout the levels Billy created.  Repositioning objects was a simple matter of drag and drop, and once again, I didn’t have to do any length recompiles or anything.  I was able to visually see changes I made in real-time.

  1. Tasks known in advance
Our team actually had a pretty decent schedule set up where we laid out all the tasks that needed to be done in advance.  We did this twice, and both times it helped immensely.  I was never lost as far as what to do next, as I just had to check off tasks/requirements as I go along.

What went wrong:

  1. Limited playtesting
Unfortunately, I wasn’t able to really get more outside views on the project we worked on.  Obviously I, and the rest of the team played it constantly to check things out, but it might’ve been nice if we allowed others to play it too.  When we had the final game on display, I would notice some people doing some things that I never noticed before so it would’ve been nice to have that feedback while it was originally in development, and is definitely something I would keep in mind on future projects.  I would want to get as many people as possible to play it, even early on, so I could notice those things.

  1. Possible game ending bug
In the final level of the game, there are some issues with the dog and how it’s loaded into the level…sometimes it will crash, or sometimes the enemy won’t even fire at you.  I could not figure out what caused this to happen, as it seems to be completely random, but my theory is that it has something to do with how Torque reads in the 3D model.  I could not get it fixed in time.  This sort of ties into the playtesting  part of things, as maybe I could get more data for why it crashes if I tested it on more varied systems.

  1. Inefficient source control
Since most of my work was done on my home PC, every once in a while there were some issues dealing with multiple versions of the project, when other team members made changes.  My source code was relatively simple to track, as I worked on relatively few files, so I knew for the most part where I made changes.  SourceSafe seemed to only work on LAN or local machines, but not over the internet.  There were packages available where we could all work from the same centralized project, but at that point in the project it was too late.  We ended up using a FTP server shared between the team and just uploaded new projects whenever we made changes.  This was better than before, but still not as efficient as it could’ve been.  In the future, I should definitely do more research into version control software, even if I only use it for my own personal code.

  1. Audio issues
This wasn’t a major problem, but still something that sort of bothered me about the finished product.  I did all the voice work, and it retrospect, I could’ve equalized things a bit more.  Some of the voices are recorded in different volumes, and the voice of Sam Maverick still sounds too much like me.  If I could redo it, I’d standardize the sound recording process a bit better, and maybe make some more alterations to the Sam Maverick voice clips.

            All in all, we did get the project done, so I’m definitely happy about that, and it was a great learning experience.  It was definitely interesting dealing with some of the complexities of team development and making sure everyone is on the same page, and for the most part, we accomplished that.  We got the project done, we nailed most of our requirements, and made decently fun and silly game.  I think what kept me going was just my general passion for game development and knowing the satisfaction I would have when the project is completed.  It was a great experience though, and I hope to be doing it again soon out in the real game industry.