Boston - Mouse in the Sewer Postmortem
Apr 16, 2009—
I entered uDevGames ’08 because I needed motivation to get something done. The three month deadline gave me something to work to. Boston was developed by a team of three — Nathan was in charge of story and music, Micah did the comic art and character design and I took care of the 3D art, level design, and all programming.
The first task was to get a story. I rounded up Micah and had a meeting with Nathan. After about ten minutes, we had a basic story line. I went back to trying to familiarize myself with the game engine while Micah, the artist, worked on character design for ‘Boston’. The next day, after another consultation with Nathan, the writer, we had our main character drawn out.
For most of December, Micah continued working on character designs while I modeled assets. By January, I had a completed model of Boston animated. I also had a police mouse who could walk across a determined set of points.
Nathan wrote a script and worked on music. I added gameplay elements, including a gun, a grapple gun, levels one and two, various bits of eye candy, and several power-ups. Micah worked on comic art based on our script.
I worked on stringing the levels and comic art into a game, and also worked on level three. Nathan and Micah continued working on music and comic art, respectively.
March 2, six hours before the deadline, I threw in a level four, fixed a few bugs, and uploaded the game.
What Went Right
Cheetah3D was used for all of the 3D art. It did it’s job, and aside from a few oddities in the program, worked very well. The animation system is clunky as of yet, which made timing animations very hard, but overall it was a pleasure to use.
We utilized the Unity3D game engine. It was easy to learn, easy to use, and, amazingly it ran fairly well on my Mac Mini.
Feedback and Help
Unity3D was really easy to pick up. However, when I had a problem, I could get help from the guys on the Unity3D forum and IRC chatroom. The iDevGames forum was also helpful for getting comments on how to improve gameplay.
What Went Wrong
Rigging the mesh
When I completed the modeling of a character, be it Boston, or an enemy, I put on a subdivision to smooth the rough parts over, and proceeded to add bones to the mesh. This being my first game, I didn’t worry about optimization until I had several characters on-screen at one time, which gave me a large performance hit. To improve performance, I had to go back into Cheetah, optimize the mesh, and re-rig the mesh to fix the fouled-up vertex weights.
A serious problem during the making of this game was my uncanny ability to focus on a small part of a project rather than the big picture. This is obvious in level three. One corner of the room is densely populated, whereas another corner is void of popuation. I spent hours trying to get an explosion to look the way I wanted rather than actually building a level.
Scattered throughout level three, I had various small objects. I reasoned that since these small objects had a very low triangle count, they wouldn’t affect performance much. Same with the large but relatively low-poly objects such as the desk, bookcase, and bed. But when researching optimization, I read that:
If you have a 100-triangle object it is going to be just as expensive to render as a 1500 poly object.
This would have been a good thing to know. Now I do.
We were able to tell only a small part of our story. This is because I set an extremely lofty goal for a first project: especially a three month first time project. I went for quantity over quality, and the result is clear throughout the whole of the game. Textures don’t match up, there are animation and modeling problems, and the enemy AI leaves much to be desired.
What I Learned:
- Optimization should be done throughout asset creation rather than after the fact.
- I will set a smaller goal and focus on polishing it more rather than setting a large goal and leaving things undone.
The Reviews — How Did We Do?
‘Cool idea but it felt unfinished in many ways.’
This section of the postmortem will contain reviews of Boston, both from the public and from the fellow developers. Keep in mind that these are snippets, so they may sound more negative/less helpful than the actual review was.
Music/Sound – 9th place
‘I really like the music. I think of the games I played, this may well be the contender for best audio.’
Some people liked the music, some people didn’t like it. The majority seem to like it, but there are some who find it less appealing. This is probably due to playing the first level, which starts out with a piece that is a bit loud. While I like the piece, I can see it being annoying.
Gameplay – 11th place
‘Graphics are quite nice but combat seemed an afterthought and wasn’t that much fun’
Gameplay could definitely be improved. It is extremely hard to kill a rat using your fists, there should be some kind of auto-aim/lock on system, and movement itself is a bit weird. A couple people said that it felt like a stock Unity FPS.
Graphics – 8th place
The graphics seem to be well received. Most of the reviews I got said that they liked the character design and/or the graphics.
‘First of all, great work with the modeling!’
‘Graphics are quite nice’
‘The presentation and graphics are both solid’
‘The character graphics looked good’
Of course, there were some exceptions:
‘Boston – Mouse in the Sewer is very weak. Graphics blow, music is annoying, terrible’ – Public Review
But overall, people seemed to like the graphics.
Story – 1st place
‘Boston: It’s hard not to like Boston- the game has a huge heart. The best parts about Boston were the Story elements. This is my top rated game in the Story category.’
Boston took 1st place in the story category of uDevGames. When I began my entry, I did not think I would be able to contend for graphics, polish, gameplay, or even audio. I knew that if I were to compete with the other entries, it would have to be in story. Nathan wrote one in 10 minutes, and everyone loved it.
The Future – Where Will Boston Go Now?
Boston 1.0 is only the beginning of what Boston will eventually become. There is much more story to tell, many more enemies to fight, and many more rooms to take over. For those of you who completed level four (is it possible?), you will see a two-panel comic scene that builds into a continuation of the Boston game. In the completion of the Boston story, Boston must take on a group of establishment mice who have named themselves ‘The Directive’. Upon entering the kitchen, Boston will find more weapons, but will also encounter more enemies, and, of course, ferocious, mouse-devouring bugs. And then there’s the cat.
I am pleased with what Boston turned into. There are endless things that could be made better, but I am satisfied that I made a relatively playable game in three months with a game engine I hadn’t used before.
- Game Title: Boston – Mouse in the Sewer
- Developer: BinkWorks Software
Team: Lincoln Green, Micah Green, Nathan Green
- Genre: Action/Adventure
- Team size: 3
- Critical Software: Unity3D, Cheetah3D, Audacity, Garageband ’08, Finale ’07, CeltX
- Hardware: Mac Mini Core Duo 1.83 GHZ, 512 MB RAM, GMA 950 64 MB shared VRAM, iMac 20" Core 2 Duo 2.0 GHZ, 1GB RAM, ATI Radeon HD 2400 XT 128 MB