Minions of Mirth - (Brief) Post Mortem

Josh Ritter
Prairie Games, Inc
12-15-05

Introduction

Minions of Mirth was developed by Prairie Games, Inc over 11 months in 2005. There was over a year of prototyping leading up to the main development period. This is a brief post mortem of the game's development. The game's production had the following breakdown:

Developer:
Prairie Games, Inc
Target platforms:
Windows and OSX
Length of development cycle:
11 months
Internal team members:
2
External contractors:
3 (Character Models, Clothing Textures, and Music)
Primary External Technology:
Torque Game Engine ($500 Commercial License), Python (Free), Twisted (Free), SQLObject (Free), SQLite (Free)
Programming Languages:
Python, C/C++
Components:
Master/Registration Server, World Server, Character Server, Zone Server, Client, Automated Packaging and Patcher System, RPG Database and Editing
Final Product Size:
226MB
Release Date:
December 15th, 2005

What went right?

1. Python Programming Language: Minions of Mirth was written in 11 months by one programmer using a number of inexpensive and freely available technologies. The bulk of the programming was done in Python. Python is an incredibly quick language to program in for tasks where it's a good fit. Python also has great debugging mechanisms which make it great for trapping errors not only on developer machines but also tester and end users.

The production would have taken much longer without a high level, cross platform language with extensive libraries, like Python. The master/registration server, world server, RPG database and compiler are pure Python applications. The packaging system and many utility scripts are also written in Python. My respect for Python only deepened over the production of MoM.

2. Torque Game Engine: We switched MoM to Torque on January 17th, 2005. At this time, I started a new codebase from scratch. I did roll in some of my previous work with TGE Python bindings and day/night cycles. The first thing I did was to get TGE compiling as a Python extension so it could be easily combined with other technology I wanted to use.

I changed around the Torque network game connection handshaking a bit. I pretty much gutted the engine's Player class, replacing much of the animation code and adding material overrides and other things specific to MoM. We had some problems with Torque's sound system which required some hacking. There were a number of changes to the GUI's C++ code that needed changing for the game.

I added some optimizations to the rendering system. The best (and easiest) being a visibility slider which handles terrain, dts shapes, and interiors. I was able to get interiors rendering using VBO's, though I didn't see any noticeable framerate increase. I lowered the client and server tick rates in half which saves a fair amount of CPU. Torque was a great fit for Minions of Mirth's development. I barely had to think about the actual art pipeline which was fantastic!

3. Twisted: Twisted is an open source, event-driven, networking framework written in Python. It's amazing how fast you can write client and servers with this framework. I used twisted's remote object and procedure perspective broker system for much of the RPG game data communications. The game's chat system uses twisted's IRC support. The patching system uses the twisted web client with SSL support. I wrote a nice user/role/permissions system that is shared between the various servers. Our master/registration server, world server, zone server, and client all use Twisted networking.

4. Subversion (as a cross platform auto-patching solution): We use Subversion for versioning control. The merits of version control on a project are well documented. I am mentioning Subversion in the post mortem for it's use as a backend to our auto-patching system. I wrote some Python scripts that are able to build demo/full version distributions from the game's sources and data files.

The scripts inspect assets like dif/dts to find out what files are needed. They also open up the RPG Database to find out what textures, sounds, models, etc are actually used. The scripts generate jpg files from pngs and do other operations to get the file sizes down. Multiple SHA checksums are then generated for every file and the results are stored in a manifest.zip file. The client keeps a cache of local SHA checksums and connects to the game's Subversion repository which is being served over SSL. It requests the manfest.zip and compares the SHA checksums with the local ones. The client then downloads any missing or changed files, verifies them once downloaded, requests the user to restart the application, and then copies the new files into the install. It's all very anal and has performed beautifully. It was awesome to painlessly patch users during the beta process. I don't remember getting one complaint!

5. SQLObject and SQLite: MoM uses the SQLite database via the SQLObject Python library. SQLite is a wonderful in process database that can be treated inline for most operations. I went with SQLite primarily for its zero server setup which was important to our "Host your own Persistent World" feature. It also greatly simplified many database operations where they may happen asynchronously. When using transactions, SQLite is very fast. Also, it lost absolutely no data as we were exclusively using transactions. Our testing server maintained the same characters from late alpha, through beta, and up to version 1.0!

SQLObject is "an Object Relational Manager for providing an object interface to your database, with tables as classes, rows as instances, and columns as attributes." It was great to work with because it transparently accesses the database from my Python classes, slick! Another nice thing about SQLObject is its support for MySQL, Postgres, SQLite, Firebird, SybaseConnection?, MAX DB, and MS SQL Server databases.

6. Contracting Artwork: Prairie Games, Inc's development staff numbers 2 people. That's one, two. We contracted with two excellent and very professional artists on MoM. There was a fair amount of communication that had to happen on the aesthetics and to catch any glitches in the artwork. There were very few problems involved in this process. I think a big part of this had to do with simplifying how the engine's animation system worked. Also, the technical savvy of the character artist saved us all a fair amount of pain.

7. Music: We didn't plan to have much music other than maybe some canned licensed stuff. We were approached by an artist who was excited about MoM and wanted to add music. I do remember us telling him that we didn't have much time to go back and forth with the music to get it right. He didn't seem to think this would be a problem and began working on the soundtrack in July of 2004. Over the next 10 months, he worked with Lara on getting the sound right in each of the compositions. I didn't really hear the music until we received the ftp link with over 2 hours of amazing music. The music adds so much depth and feeling. It's perfect for the game!

8. Community: We were very lucky to have some incredibly positive and wonderful people join our community. These people not only contributed feedback and assisted other players while testing, they even helped add quests, characters, dialog, items, and even buildings and other graphics to the game. MoM would not be the game it is today without their vigilant testing, input, and contributions.

9. Right Sizing Our Life: Lara and I moved to Wishek, North Dakota to pursue Prairie Games, Inc. We bought a house for $40k at a $300/month mortgage. We cut our expenses as low as we could. The game would have not been possible without this move and restructuring of our finances.

What went wrong

1. Internal Alpha - MoM had an "internal alpha" milestone of March 22nd. This was 2 months after switching (more like starting over) with Torque. We had to change the entire art pipeline, resurrect assets, and get most of the game's core functionality up in 60 days. This was far too short a time and the date was absolutely unrealistic. It caused a great deal of strain on our company. We were quite pleased with the alpha in the end. Though, the process of getting there was very painful.

2. Delay on Model Job - We didn't start the modeling job for characters and monsters until April. We had to work very quickly to get the game's animated models in place. Also, due to the late start, the game didn't ship with all of its models. We will be releasing additional models as upgrades via our auto-patching system.

3. Fumbling in 2004 - It's hard to remember the Quake2 GPL version of Minions of Mirth from 2004. Summer and Fall are kind of a blur. The game was single player only, then multiplayer, then back to single player. The game was going to use the D20 (SRD) ruleset and I wrote a ton of code. We switched to Quake3 in anticipation of its GPL status in December, 2004. The GPL was pushed back though it wasn't announced until January 1st, 2005. See "Internal Alpha" above!

Conclusion

I have learned an incredible amount in the years of R&D and production on Minions of Mirth. As most of the technology is written in Python and is platform/engine agnostic, we can port to newer engines such as the Torque Shader Engine. We have plans for Minions of Mirth expansions and to use the MoM technology in other game genres. We already have an active modding community which is even helping generate content for the official build of the game. I am very hopeful that Minions of Mirth is a success and finds its audience. So far, so good.

References

Prairie Games, Inc:
http://www.prairiegames.com
The Python Programming Language:
http://www.python.org
Torque Game Engine:
http://www.garagegames.com/products/1
Twisted:
http://twistedmatrix.com
Subversion:
http://subversion.tigris.org
SQLite:
http://www.sqlite.org
SQLObject:
http://www.sqlobject.org