Skies of Fury: Post-mortem

Skies of Fury was the first project I've worked on with Student Game Developers. While I can't speak for our director, John Will, I figure it'd be good to chronicle what I thought went well and what didn't with the project so that other could learn from our successes and failures.

WHAT IS SKIES OF FURY?

Skies of Fury (herein: "Skies" or "SoF") is a two-dimensional, top-down shooter that harkens back to the days of sprite animation and simple yet intense and addictive gameplay. The player assumes control of an advanced military fighter jet, taking on wave after wave of enemies, preparing for a challenging boss encounter at the end of each level. The goal simply is to make it through alive.


WHAT WENT WELL?

• We finished the game.  While very brief in length (more on that later), every feature we wanted to implement into the SoF game engine was implemented.  We consistently hit our targets every week with few exceptions, and as such we were able to stay on or in rare cases ahead of schedule throughout the development process.  We did have a bit of a crunch near the end of our dev cycle to get final tweaking and game balancing done, but this was expected.
• Our team performed incredibly well.  The most vital component to the completion and success of this project was the ability of the team to work together to get stuff done and meet weekly targets.  Our team was comparatively large compared to other teams at the outset of the project, but effectively half the team dropped from the project over the course of the semester.  The guys who did stay on (Matt Beattie, Charles Gibson, Steven Mond, Nick Wasilewski, Matthew Yu, and myself) in my opinion did an incredible job of communicating with John and each other about changes made to the game, upcoming targets, bug-squashing, and everything else that came about related to the game.  Along the same lines, each person at some point took some initiative to implement some critical feature into the game.  Such features that were originally added by the efforts and initiative of but a single person (and tweaked by the team from there) were: the backbone of the entire game engine, the entire first level, music and sound implementation, the boss fights, offscreen tracking arrows, and particle effects.
• The game is fun!  Thanks in part to being able to implement all of our features, the game turned out as good, if not better than we hoped for.  Everyone who played it at the Expo yesterday gave us positive feedback with regard to the fun factor of the game (alongside some constructive criticism and/or whining about dying too often -:) ).

WHAT COULD HAVE BEEN BETTER?

• Testing.  Throughout the design process, we struggled to get extensive feedback on our various builds of the game.  Our team at the outset had three testers, but by the end of the development cycle the only one who had ever contributed any feedback whatsoever was Matt Beattie (who contributed much useful feedback himself, but one tester can only be expected to do and find so much).  Many bugs in features were discovered weeks after the fact by our designers, who had to take up roles of testers as well to make up for the lack of feedback from two of our three listed testers.
• The game isn't quite as long as we wanted.  Our original plan was to have at least three levels in the game, each with five unique enemies and a boss.  Time constraints due to engine development bugs, lack of testing, and the rigors of being full-time students on top of participating in this project quickly cut into our ability to meet this goal, however.  The final game does have two levels with five shared basic enemies and two unique bosses.  Adding more content would have made this game significantly better, in my opinion; that said, we knowingly traded off content amount for having a stable and good game engine underneath all the content, and I firmly believe that SoF benefitted from this trade-off.
• Sloppy code and inconsistent documentation.  This is more of a personal gripe of mine that no one else may notice (and probably everyone on the team is guilty of, myself included), but throughout the game, memory is constantly being allocated and deallocated during gametime.  Given the fact that our game is a 2D shooter, this isn't a huge issue as any current hardware should handle our game no problem so long as we didn't try to do anything ridculous (like draw 500,000 particles at once), but this is still very poor practice; anything that we needed for a level should have been initialized in a single Initialize() call rather than in the main loop of the game.  Another gripe of mine is inconsistently commented code, which sometimes made it difficult to tweak the game or squash bugs.
• The game is sometimes too hard.  My personal thanks to Nick (our lead level and boss designer), you are evil :)

OVERALL IMPRESSION

I personally would call Skies a successful project.  Not only did we finish the game, but we made a fun enjoyable one.  It's not without flaws, but for my first full-fledged game project with SGD, I personally am very happy with how the game turned out.  The success of this project has me looking forward to working on a new project with the club (perhaps even some of the guys on this same team, should the chips fall that way) next semester.