The sometimes strange organization of the engine led to one particularly thorny problem with the weapon-in-hand animations. For a long time after the functionality was ported, the feel of the weapons was slightly off. Guns would fire too quickly or not quickly enough, and animation glitches and timing problems were rampant, but there was no clear data corruption or logical error to be found. The animation of the weapons was all correctly loaded, as was the "physics model" file that defined the rest of their behavior, but the two data sets were inconsistent and had always been.

It was eventually discovered that there was a preprocessing function that synchronized the two that had been left out entirely -- its only invocation was in an obscure area of initialization that had been superseded by an Xbox 360-specific rewrite. The question of why one set of conflicting data wasn’t chosen to be canonical and used in its original loaded form was never answered.

Fixed-point arithmetic was used throughout the original game, and it was sometimes reflected in the gameplay in unexpected ways. Marathon has two features that were fairly unique for its time: liquid volumes with variable height and currents that push the player around, and wall panels that can be used to recharge health. We received a bug for a level late in the game -- there was an underwater recharger that could not be used, since the liquid would push the player away from it. Why didn’t the liquid push the player away in the original game?

The answer lay in the fact that the liquid current was now stored in a float rather than a fixed-point integer. The exact value of the liquid's force was applied to the player at reduced strength (the full value was used to animate its flowing surface); a division by 4 for a float, a right shift of 2 bits for a fixed. Most of the time, these gave similar results, but what if the current flow was already less than 4? The fixed-point math drops it all the way to zero; the float leaves it at a very small positive value. The underwater recharger worked because of this inaccuracy; once it was manually restored the player could recharge again.

Was an updated port a good idea in the first place? Why do people play old games, especially old games they have never played before? Some do it for nostalgia, to reinforce their memories of when the game was brand new. Some do it to satisfy their curiosity about an experience that others feel is worth remembering even after countless other games were released. Some do it to witness the evolution of modern games, and see brand new concepts in their unrefined states. Fundamentally, the goal is the same regardless -- to go back and experience the game as it once was, to see for oneself the greatness that was once discovered in it without preconceptions or the relaxed standards of hindsight.

We had decided to go in a different direction. We felt the core of what made the game great -- the level design, the feel of working the game’s controls and weapons, the story, deserved a stronger technological foundation. Some of the game’s limitations added nothing to it and could be discarded, and additions could be made that enhanced the parts of the experience we felt were lacking. In hindsight, this was a fundamental mistake. Fidelity to the original should have been absolutely paramount, and it could have been done while playing to the 360’s strengths all along. Our long experience with the game and its tightly-knit original community led us to fail to consider what a player approaching it for the very first time was expecting to find.

Practically every other port on Xbox Live, and older games running under emulators or virtual machines on PCs, can be made to look so similar to the original that it’s practically impossible to distinguish screenshots of the two. Ours cannot. Texture filtering is always used; the blocky nearest-neighbor look of software texturing is gone. Vertical foreshortening always occurs in the truly 3D renderer. The new HUD, while unavoidable for reasons stated above, is nevertheless new. The port’s 60 fps performance makes some effects carefully tweaked for half that rate look strange, such as the flamethrower or the rocket’s contrail.

The high-quality mode is not simply a tweaked version of the standard, but a completely new look that warps the aesthetics of some areas in unexpected ways. These changes may be superficial to the gameplay, but they are pervasive and unavoidable and they make the game a unique experience to old and new players alike; an experience that can’t decide whether it wants to be judged as a modern game weighed down by gameplay and rough edges a decade old, or a relic of the past that tries to deny its players the very reason they sought it out. Lost in the gap between contemporary expectations of polish and the implicit forgiveness in gaming archaeology, the experience is not exactly what we had intended for any one player.

Conclusion

Just because a project is a port of an older game does not imply that it will be less complex. Overhauling systems not suitable for use on a different platform can involve a great deal of work, and console platforms with certification processes may require the creation of large swaths of brand-new code and content. But while all this new work is performed, the core goal of the project must not be lost -- a port is a chance for an old game to have another chance at entertaining a new audience.

Project Stats

Developer: Freeverse
Publisher: Microsoft Game Studios
Platform: Xbox 360 (Xbox Live Arcade)
Release date: August 1, 2007
Development time: 10 months
Number of developers: 5
Hardware: Mac minis running Windows XP under Boot Camp
Development software: Visual Studio 2005, Adobe CS 2.0, Xcode
Technologies: DirectX
Lines of code: 42,000
Budget: $300,000