A flexible and cross-platform toolchain. We decided early on in development that we wanted to keep the original game data intact wherever feasible. The theory was that it would remove sources of uncertainty in the conversion process -- existing loader code would provide a completely reliable method of establishing assets in RAM, and the only potential sources of bugs would be later on in the gameplay code. This theory did not survive being put into practice, but when the dust settled we were much better off after all.

The problem was the high-resolution sprite loader. We had already abandoned the original sprite collection format in favor of 32-bit PNGs, but the tens of thousands of seeks the game performed when launched were unacceptable. Collecting the assets into a small number of package files meant that we were no longer strictly loading the original data, but it also allowed us to shave over ten seconds off the load time, a very fair trade. Later in development, the package file system also allowed us to integrate compression, which turned out to be essential to reaching XBLA's 150-megabyte file size cap.

The package files necessitated the creation of a tool to assemble them, but other tools were also created over the course of the project. Marathon originally stored its sprites and animation data in the same place -- a single filed named "Shapes". Once the decision was made to move sprites to individual PNG files, the copies of the images within the shapes file became redundant, a waste of about 10 megabytes of space. A tool had to be created to gut the Shapes file, leaving only the animations. It was at this point one of the unexpected advantages of being a Mac-centric studio was noted -- the (PowerPC) Macintosh and the Xbox 360 are both big-endian.

Load times were still unacceptable, so one final optimization was performed on the package file format. It was found that the package file was being searched with simple string comparisons (each chunk within it was referred to by what its path had been before packing), and the work done to iterate over this table was adding up. The packaging tool was changed to hash the paths and store the resulting table in the package instead of a simple mapping of path strings to locations. Integrating this into the resource loading system was easy thanks to the reliance on packages, and it shaved around 10 seconds off the load with virtually no cost in reworking other areas of the game.

Leaderboard-linked Achievements. There are two leaderboards in M2:D that record the time at which a player earned an Achievement -- one for completing the single-player campaign while obeying some restrictions (the "vidmaster" rules), another for a "viral" achievement awarded for kills in network games. This was proven to be a good idea when the first few entries on the board were deluged with Xbox Live messages, most asking for assistance in earning their own place on the board. The leaderboards practically became an alternative friends list, as existing vidmasters hosted cooperative games to induct new ones.

The standard Xbox 360 Achievement system allows players to compare their Achievements, but only to one friend at a time. The idea of building a global list of Achievement earners added a new facet to the feature -- the chance to move faster than other players and to be higher on the list.