iDevGames

A Game with a Story

Marathon is one of the most memorable Mac games of all time. In 1994 Bungie Software introduced fast-paced 3D action to the Mac platform, while retaining the eerie atmosphere of its adventure-oriented predecessor, Pathways Into Darkness. Although its gameplay was reminiscent of Doom, Marathon remained true to the spirit of the Mac with its intelligent storyline and user-friendly interface. After three years and two sequels, the series arrived at Marathon Infinity, and with it came a sense of closure. By that time most of the missing pieces of the game’s convoluted storyline had been put into place and the Marathon engine had aged to the extent that it was no longer commercially viable. The three commercial games to license the Marathon engine suffered from the technology’s pseudo-3D architecture and lack of support for emerging hardware acceleration standards. However, at the same time, independent scenario designers were perfecting their Marathon level editing skills through the Mac’s only comprehensive set of mod-making utilities.

Marathon for the Masses

For most developers, releasing the source code to their game is like giving away the crown jewels. However, with id Software releasing the source code to their hit first-person shooters, some developers are slowly realizing the benefits that this can bring to the industry as a whole. On the Macintosh platform, Bungie was one of the first AAA title developers to release their source code. When Bungie released the Marathon source code to the public I immediately realized that this was a potentially great thing for Mac gaming. As one of the few Mac-first 3D action games, Marathon has always held a special place in the minds of Macintosh gamers. Unlike most AAA title games that started on the PC and were later ported to the Mac, Marathon was a game that Mac users could point to and say “Mac first.” On top of this, Bungie always provided comprehensive scenario creation tools. I was not sure what developers and game fans would do with Bungie’s gift but I crossed my fingers that support for hardware acceleration, better monster AI, and multiplayer internet play would be added by Mac programming gurus. My love of Marathon, however, was not the only reason I wanted to see this old 2.5-D game engine catch up to the likes of Quake and Unreal. For as long as the Marathon map editing tools had been available, I had been plugging away on my own scenario and I was motivated by the knowledge that any enhancements made to the Marathon engine would automatically enhance my own efforts.

Marathon Open Source is Born

The good folks at Bungie.org were easily convinced that the Marathon community needed a web site to coordinate the development and distribution of an improved Marathon. I set up shop at http://source.bungie.org and collected news for the site from the frenetic discussions held at alt.games.marathon. It took a few days to get the released code into a compilable form but from that point onward, Loren Petrich and others began adding new features and compiling builds on a regular basis.

In the beginning, the Marathon code was quite a challenge to decipher. In fact, I did not know if the code could even be modernized to allow for new features! I decided to be conservative in creating the group’s mission statement:

• Track the development process
• Promote an organized team approach to help prevent duplication of effort

• Provide the latest source code and executables

The first objective was easily done. I keep a close eye on various projects and networked with many groups so that new Marathon developments were posted shortly after they are announced. The second objective was a challenge during the early days. In a couple of cases, programmers who were unaware of the collective of programmers affiliated with source.bungie.org put in some long hours implementing features that had already been accomplished. However, I am happy to report that things are going much more smoothly now. Coverage at Inside Mac Games and MacAddict helped us to reach a wider audience and when Slashdot ran a story on the project many Linux users took notice and increased our total hits by 20 percent in a single day!

With the project well organized, redundant development is now a thing of the past. The organized team effort has been key to the project’s success. A large to-do list was assembled very early on, with many of the ideas coming from Marathon fans themselves rather than the programmers. The creation of a mailing list for the project became very popular and proved to be more beneficial than the to-do list and even the news group alt.games.marathon’s. My efforts to make the development process more efficient also involved assembling a collection of programming resources, including lessons on how to compile the source, archiving important developer rants, and reference information on the specifications of Marathon’s data files.

To the disappointment of some scenario designers, the features that were requested were not always the ones that were implemented. Some ideas have lingered on the Suggested Features page at the Marathon Open Source site for months without being addressed, and occasionally a feature is added to the game without ever having appeared on the Suggested Features page. The programmers’ detractors point out that if the scenario designers’ requests are not added to the engine then programmers will have themselves to blame for the lack of interest from the mod-making community. The programmers’ defenders counter that since open source programmers are unpaid volunteers they have the right to add whatever features they want. In actuality, programmers devote their limited time and energy to implementing what they are capable of adding to the game rather than enslaving themselves to the whims of the non-programmers. Suggested features like multiplayer gaming over the internet and support for 3D model characters have often taken a backseat to more modest, attainable goals. Fortunately, during the nineteen months that have progressed since the release of the Marathon source code, the programmers’ skills have improved and with it their willingness to take on ever larger challenges.

Enhancing Marathon

Surprise! A more powerful Marathon engine has emerged, and with it comes a potential renaissance of scenario design. It is fitting that in taking the game beyond Marathon Infinity, open source developers branded their builds Aleph One, a mathematical term for the infinite set of real numbers. Having acquired a name that no commercial software publisher’s marketing department would ever have put forth, one might wonder what other unexpected changes Marathon has undergone. Since January 2000 Marathon has gained a wide assortment of graphical and functional improvements and yet has retained its compatibility with the countless scenarios that have been developed over the years by the fan community.

Some of the modifications to the engine, such as a scripting language, new level creation tool and support for true 3D polygonal structures, have been aimed at increasing the creative possibilities for scenario designers. Others, like support for hardware acceleration and an optional third person perspective, enhance the perceived quality of existing content. Some have worked at increasing Marathon‘s audience by offering builds for Windows, Mac OS X, Linux, and BeOS. Those with design experience have opted to provide new icons and splash screens for the game. For my own part, I have helped maintain the Marathon Open Source Web site at source.bungie.org, which is my attempt to promote the game to an audience that normally shies away from anything as esoteric as open source software.

Our efforts are resulting in a game engine that is slowly becoming more cohesive and robust. With features like OpenGL texture smoothing and improved mouse control having been implemented, there is little left to add to the engine that could make Bungie’s original levels much more enjoyable. So recently programmers have made life easier for scenario designers, which should be welcome news to mapmakers who are interested in making sophisticated 3D game environments.

From Scenario Designer to Developer

Any potential scenario designer should assess the long-term viability of the Marathon engine alongside that of the Mac platform’s other mod making options. Will there be a place for the engine five years from now, or will superior systems take root? Well, for the last five years, Marathon has provided Mac gamers with their only comprehensive tool set for creating first-person 3D action games. In the unlikely event that this remains the case, then further development of the Marathon engine could be the only thing standing in the way of a complete exodus of creative gamers to the PC platform, where mod making tools abound. One way or another it should be possible to create, on the Mac platform, enjoyable games with graphical sophistication rivaling that of PC game mods.

Companies that port PC games to the Mac, like Westlake, are sometimes held responsible for the lack of Mac ports of level design tools for the games they port, but it is really a financial decision made by the publisher. Programmers at id Software, on the other hand, seem to be ensuring that the design tools for their new cross-platform games are themselves cross-platform, increasing the audience which can author mods for their game and increasing the game’s worth to the customer. Meanwhile Garage Games V12 engine (used for Tribes 2) and the Dim3 engine from little-known Klink Software, are being readied as inexpensive stand-alone Mac game design platforms. These two products are essentially content-free games bundled with mapmaking software, scripting languages and tools for importing data from common 3D model formats. Those who aspire to make a 3D first-person shooter without writing thousands of lines of C++ code should consider what Marathon offers but be aware of the more advanced but less understood V12 and Dimension 3 engines. I would like to finish with an overview of what Aleph One has to offer scenario designers and developers.

• The Marathon Markup Language (MML) allows scenario designers to override Marathon‘s default behavior. New features such as a wider cone of vision or animated textures must be “turned on” through an MML script. If an MML script is not present then the Marathon engine behaves as it would normally. MML scripts may be embedded into the resource fork of a map file or stored as independent text files.
• The Pfhortran scripting language moves characters, modifies the contents of the player’s inventory, adjusts the color and density of fog, controls the camera, manages variables and tags, inflicts damage on characters and even changes the background music—all dynamically.
• Aleph One takes advantage of hardware acceleration on all platforms through OpenGL. Both textures and sprites benefit from smoothing, MIP mapping, and any other features that may be offered by the user’s hardware, such as full screen anti-aliasing. Support for 24-bit textures of all resolutions has gone a long way towards modernizing Marathon‘s appearance.
• Scenario designers will soon be able to insert true 3D architecture into levels through MML. The designer of this “Bridges and Balconies” technology has come close to perfecting his creation, but builds with support for 3D inserts are not yet publicly available. Future map editors are expected to allow for the easy addition of such inserts.
• The basic level design and physics editing tools have been around for years and are very useful as long as you’re properly schooled in the art of bug avoidance. Fortunately, much effort has been put into the development of new tools to replace the old ones.
• Since Marathon has been released under the GPL, the source code is free to anyone who wants it. No million-dollar licensing fees apply! On the other hand, you cannot sell any products you create using the Marathon engine. Those who hope to sell their creations might consider programming a game in REALbasic or investigating the inexpensive licensing policies of The Tribes 2 or Dim3 engines.

• The Marathon engine has become very robust. Its fault tolerance is evident in its perfect compatibility with my own levels, which have been teetering on the brink of corruption—my levels have long since become too complex for the original Marathon engine to handle.

Final Thoughts

Clearly Aleph One has some impressive strengths and is getting better all the time. Nevertheless, developing for Aleph One has its difficulties. I will leave you with the best and worst experiences I have had developing for this engine:

Worst Aleph One Experience

An undocumented memory leak in Aleph One’s scripting language Pfhortran resulted in crashes in levels that utilized moving cameras. I was left with no option but to strip my cut screens of all their moving cameras. I then focused on adding 3D inserts to my levels, a process that went pretty smoothly. Months later when the Pfhortran camera bug was fixed, my moving cameras instantly regained their functionality. However, the enhanced Pfhortran code has yet to be integrated with the 3D inserts technology. I am left with three options: use 3D inserts, use Pfhortran, or use both, and hope for the future release of a build that supports the combined features.

Best Aleph One Experience

On several occasions I have received new builds of Aleph One that made my existing levels look and play better. It has been my experience that programmers can sometimes read minds—features that I had been hoping for have at times magically appeared in the engine.

return,of,marathon