A Look at Aleph One (Part 2)
Monday, January 13th, 2003, 3:37 PM
Most people wouldn't expect a developer owned by Microsoft to run articles about open-source projects on their web site. But Bungie is no ordinary developer, and Aleph One is no ordinary open-source project. This effort to maintain and extend the Marathon 2 engine has made extraordinary progress in the years since Bungie released the source code, and we wanted to learn more about it. The first half of this story introduced you to four members of the Aleph One team; now we take a closer look at Aleph One itself and discover what the future holds for this fascinating project.
[NB: Jesse Simko's responses did not reach us before we published the first half of this interview, but we've gone back and added them in, so feel free to reread the first article for the complete picture.]
What do you think your greatest or most personally satisfying contributions to the Marathon open source project have been thus far?
Alexander Strange: I've mostly done a lot of small things. Probably most of what I've done has been for the OSX (SDL and Carbon) ports.
Jesse Simko: My contribution to the project is been the source.bungie.org web site, and it's been really satisfying to see people flock to it and read the news and download new builds of Marathon. But since maintaining the site involves no C programming, I'll try to speak for the others, who have done the real work of improving Marathon... The most exciting development had to have been the introduction of Inio's now-infamous "Bridges and Balconies" feature, which added support for 3D architecture like freestanding bridges and (well, naturally) balconies. This combined with features like high-resolution textures and OpenGL smoothing to give the engine the ability to display graphics that were generations ahead of the original Marathon engine- just what I had dreamed of when I learned that the source had become available. Unfortunately the Bridges and Balconies feature was never integrated into the ever-evolving code-base, and now it exists only in the form of a languishing Mac OS 9 build that I rescued from a trash heap of old executables so that it could serve as the engine for my overambitious, half-finished, and now totally abandoned total conversion, Carlos on the Run.
Loren Petrich: The OpenGL graphics support. It's nice to have a more real-looking display on a big screen and an end to that ugly blockiness.
Also good is getting rid of several annoying bugs, like the long-distance bug and the geometry-complexity bug.
Woody Zenfell: Generally, I am quite pleased to have contributed (and to have had published) what I think of as pretty good code to the project. None of my other efforts has really quite made the jump off my disk out into public yet. (I was sort of hoping that having good, working, published code out there would make it easier to get a job working on games "for real". But that hasn't worked out just yet.)
As my mdev-list colleagues could tell you, I've written a fair amount of text (usually in e-mails to the list, but some in voluminous comments within source files) about a variety of A1 topics. There's a list archive, so I'd hope that some of the discussion could help some people down the line that actually attempt to implement some of the things we've talked about. But more satisfying for me is the brain exercise I get thinking through various improvements and what they would take. I feel like I've learned a fair amount.
In terms of a specific area of the code I contributed, well I'm particularly proud of my dialog boxes. Heh heh. Sounds kind of dumb, but I like having little pictures of players pop up instead of little colored rectangles when folks join the game. I'm pleased that folks can choose different Map files from the Setup Network Game box without having to go back over to the Environment settings. But more than anything else I like the Postgame Carnage Report. It took a long time, but I got all the little details exactly the way I wanted them. You know, when you're viewing by team, the little player pictures group together by team. When you're viewing the results for a specific team or player, the player or team highlights and the others dim. If there are only a few graph bars, the bars themselves are labelled "5 deaths" or "3 suicides". But if there get to be more, that'd be awfully cluttered, so it just labels the bars with the numbers and puts a legend in the corner. It's careful to position text so it doesn't overlap. Etc. For me, it's reminiscent of using a Mac vs. using Windows. I use both, and they're both fine for what they're good at, but the Mac usually seems to exhibit this extra level of refinement and polish that only comes with careful craftsmanship - getting all the details just right. And I think that's what makes it so much more pleasant to use. I'd like to think that my Postgame Carnage Report is polished and pleasant to use (at least for the three people out there who have actually played an A1 netgame ;) ). (Note that my dialogs only apply to SDL versions of the game - like the Windows version.)
Are there any features in particular that you'd really like to see added or completed?
AS: I'd like it to be able to start up even if it can't find a map with the default name. That's always annoyed me, and has existed in the original as well.
JS: I'd love to see rock-solid stability restored to the engine. A new offshoot of the Marathon Open Source effort, called "Aleph Modular" is aimed at doing just that by stripping the engine down to its roots, gutting its innards, and establishing a crash-proof, robust core that will be more accepting of future additions such as the Bridges and Balconies feature that we all miss so much.
LP: TCP/IP Networking. I've had difficulty working on it, because I do not have any real experience doing network programming, because I don't have access to some convenient LAN, and because I have only one usable machine at home.
WZ: Well I think everyone would be excited to have a predictive latency-hiding scheme for Internet play. But given the amount of effort that would require reworking stuff all throughout the game engine, I don't really see it happening in practice.
I'd like to see networking working properly on all platforms, not just those that are SDL-based. I'd like to see realtime network audio working on all platforms, not just Windows. I'd like to have pre-game, in-game, and post-game chat.
On another front, I would really like to see A1 break the 30fps barrier. Unfortunately doing this involves a lot of the same things as the predictive latency-hiding stuff, so it's a lot harder than one might first think.
I would also very much like to see built-in support for Marathon 1. The M1A1 project is great, and I appreciate their efforts, but it still doesn't let me play 3rd-party M1 levels.
I think some kind of cleaner scenario packaging/management would be nice. You know, you just pick "Marathon 2" or whatever, not "M2 Shapes", "M2 Sounds", "M2 Images", "M2 Physics", etc. etc.
Are there any features that don't get as much respect or use as they deserve?
AS: Pfhortran, the scripting language we've added. It can be used to do some really neat stuff.
JS: I'd have to say the most underrated feature is Pfhortran, which is a scripting language used for doing pretty much everything - adjusting lights, moving characters, giving the player items, and so on. I'm pretty amazed that Chris Pruett (now a Game Boy Advance programmer), was able to weave an interpreted language into the codebase. (But according to Chis, "Pfhortran works, and Pfhortran sucks.")
LP:I'm disappointed at the shortage of replacement model-making; progress on that has been much less than progress on substitute wall textures. Maybe I'll have to do some of that myself.
Also, Pfhortran has not gotten much use, but that may be because using it requires some programming ability. MML, however, only requires understanding its format. :)
WZ: Yeah, all the ones I spent so much time putting in there. Ha ha ha. No really, the IP networking stuff has had trouble making it back into the "Classic" version, which is what I suspect most people use, even on Mac OS X. There are some technical obstacles with the scheduling holding us back. And the official Mac OS X version, Aleph One Carbon (which does have IP networking support, thanks to Br'fin's efforts), still is a bit rough around the edges as I understand it - especially if you don't have 10.2. I think Marathon has been (sadly) primarily a Mac phenomenon, so having the most-functional version of A1 be the Windows version is somewhat unfortunate.
Really though, I think A1's cross-platform nature is a huge achievement - and for that I think the credit basically goes to the Bungie code's underlying modularity, the free SDL library, and Christian Bauer, with I gather some help from Loren Petrich (I wasn't around when that phase happened, so I'm not entirely sure who did what). But sadly there just doesn't seem to be a whole lot of excitement in the community about non-Mac platforms. We are very fortunate to have Michael Adams making regular Windows builds, and I think a few people use A1 on Windows, but nobody's made builds for platforms like Linux for ages. (Though it was pretty cool to hear that A1 was recently ported to Dreamcast - wish that fellow had contributed to our CVS tree so the DC port won't wilt and die.)
Personally I'm also often surprised by just how many options and tweaks Loren Petrich has exposed via MML ("Marathon Markup Language") configuration files. I suspect a lot of that functionality goes unused in most cases as well.
I would gush about how great it is to have OpenGL rendering, hi-res textures, etc. but I suspect those features are properly appreciated. :)
The Marathon games had a relatively small but extraordinarily dedicated fanbase. Has that affected the development process, for good or ill?
AS: They've mostly been supportive. They mostly understand that we have to work in our free time and that we have to release a lot more often than you could, which causes bugs to occur more often.
JS: The fans that we come into contact with are the ones who write saying "I'm designing this really great scenario, but first you guys have to add features x, y, and z to the engine." When we deliver, they're very appreciative. When we don't they get discouraged and go design levels for Quake or something. Unfortunately that's what happened to most of the "old guard" Marathon fans who populated alt.games.marathon and the marathon.org and bungie.org forums.
Long ago, the most dedicated of Marathon's scenario-designing fans prided themselves on knowing all the ins and outs of Marathon's content creation tools, Forge and Anvil, and also ResEdit, which (according to legend) could be used to make the application completely unrecognizable as the Marathon engine. But the newfangled open source engine must have felt like a moving target. For three years Marathon Infinity had the same stable engine, and the same bugs, which called for the same workarounds. It's a real bubble-burster to learn that everything you know about how to design a scenario that won't crash the engine is no longer true.
Only a truly dedicated programmer would use his talents nurturing an antiquated engine that has been abandoned by many talented scenario designers, as alternative first-person-shooter engines emerge on the Mac platform. To anyone who understands interface design and gameplay, the appeal of Marathon is obvious and undeniable; it still feels like the most Mac-like game engine out there. Even so, you can't overlook the dedication of those who remain committed to this engine after the better part of a decade.
LP: It has resulted in a shortage of development expertise; 3dfx-card support has been imperfect, because nobody with such expertise has been willing to step up and do 3dfx-specific stuff to help display the HUD, save dialogs, etc.
Which has meant that I've gotten lots of feature requests, with me often to implement them.
WZ: Yes, in exactly the ways you might expect. I think the A1 community, given its relatively small size, has put a surprising amount of stuff in there. I'm especially impressed that folks have taken the trouble to create hi-res versions of the various textures (even if those folks occasionally took a little too much freedom for my taste, e.g. breaking up the color scheme of the M2 water textures by giving the doors primary red and blue markings). But of course because the developer community is small, advancements often don't come as quickly as folks would probably like. Because the user community is small, things often don't get very well-tested early on, and it's discouraging as a developer to think that you'll invest a whole bunch of effort and hardly anyone will ever see it.
With all the acclaim the Marathon games garnered for their story, and all the quality single-player scenarios created by players, was there any emphasis placed on expanding the abilities of scenario designers?
AS: Definitely. There's MML, which makes it so you don't have to patch the application to change the weapon names, for instance.
JS: The Marathon Markup Language, Pfhortran, support for high-resolution textures, new level editors like Pfhorge, and features like Bridges and Balconies were all created with scenario designers in mind. Other additions, like OpenGL texture smoothing and support for Windows and Linux, were designed to get more out of existing content. But I'd have to say that most of the emphasis has always been on expanding the abilities of scenario designers.
Recently the pendulum has shifted back towards stretching existing content further - the big effort now is to stabilize the engine and get multiplayer games working better. Maybe it was a mistake to save that for last; I don't have much of an understanding of the process of writing in C, but the new scenario design features might have been better integrated into a solidified engine than the one initially dropped by Bungie back in January of 2000.
LP: MML is an obvious one -- I've succeeded in exposing the large majority of engine parameters to scenario composers, though it does not get used as much as one might hope.
WZ: Not on my part, but other efforts like Loren's MML configuration, Chris Pruett's Pfhortran scripting, and Ian Rickard's abortive Bridges and Balconies attempt have tried to extend scenario author's reach. Of those, I think the MML configuration is the most exciting, because Loren has exposed so much stuff for tweaking. Pfhortran is probably pretty valuable for single-player scenarios, but currently it's very much broken for any sort of network play (including cooperative play), so I probably value it less than it actually deserves.
Of course, we're also in the debt of folks, like Joshua Orr, who are making tools to encourage developments that exploit A1's capabilities.
Recently Aleph One acquired TCP/IP support, one of the most-requested features for Marathon for years (even before the source was released). What's next?
AS: Making the networking work better :)
It's still mostly based on the old Appletalk networking stuff, which was great if you were all on a Token Ring network, but not for Internet games or something with a lot more lag.
JS: The effort to stabilize the engine seems to be picking up steam, and that will probably be followed by a serious attempt to get network play working better. As it stands, Marathon uses a fault-intolerant networking model - rather than transferring the game state across the network to the various players, only players' keystrokes are sent. So games occasionally get out of sync even on fast networks, with different computers showing the same character in two different positions. The problem just gets worse on slow networks, and it's horrible on the Internet, where dropped packets result in lost keystrokes.
LP: I've long hoped to start work on using the open-source Crystal Space engine, http://crystal.sourceforge.net as an alternative platform for running Marathon-engine stuff -- I'd write some code that composes a CS map internally from a Marathon one. The nice thing about CS is that one can easily do the equivalent of B&B in it without much trouble.
Also long in the works has been B&B itself -- Bridges and Balconies. However, that has been coming along slowly, and it is still feature-incomplete. One can see B&B's, but one can't walk on them. I'm disappointed that its developers have not incorporated partial versions into the main code.
WZ: I would hope that smoothing out installation problems and support in the Carbon version for pre-10.2 are near the top of the list. I'd also like to be sure that networking works right in Carbon - there have been some problems reported.
But realistically, I think it's hard to predict what the next big improvement will be. We're just a loose batch of developers who work on whatever catches our interest.
As developers, you must spend a fair amount of time testing things out.
WZ: Hmm, obviously you haven't actually TRIED Aleph One. Ha ha ha. No, really on Windows and Mac OS X with the "Classic" version, I think it works pretty well, once you get it installed right. But there are some lingering problems here and there, and the installation process could probably stand to be improved and made more friendly. Aleph One Carbon might work great on 10.2, also, but since I only have 10.1.5 I probably have a less-positive view of it at the moment than I should.
What's your all-time favorite Marathon map?
AS: Some of the Marathon 2 maps, and Tempus Irae. Rubicon is also nice, but tends to stress my video card.
JS: Glad you asked! I must confess, I was never one to actually buy games, so that meant I spent an inordinate amount of time playing and replaying the Marathon 2 Demo. My favorite map from those days was undeniably "What About Bob?" Nothing matched the thrill of racing a rising stream of lava up a set of spiraling staircases, leaving the cyborgs I so elegantly circumvented to be toasted by the flames below. But my all-time favorite Marathon map was made by the geniuses at Double Aught. The first level of Marathon Infinity, Ne Cede Malis, provided a rather tedious and frustrating gameplay experience, but from an aesthetic point of view, I was really blown away by the advanced mapmaking techniques that went into creating that level. The use of floating switches and 5D space made for the Marathon trilogy's coolest elevator shaft, and the very small polygons throughout the level allowed for intracate geometeric detail and fantastic lighting effects. There's so much atmosphere there. It's a darn shame Double Aught disbanded before they could complete their next project, Duality - which is, among games that never came out, far and away the best!
LP: I usually use Marathon 2 for that purpose, and sometimes some test maps I've created. I'd sometimes use maps from other scenarios, however.
WZ: Oh c'mon, nobody can pick just one! For me, there are a lot of net levels that have some nostalgic value, particularly M1 levels. "Mars Needs Women" for obvious reasons. "Waldo World Arena". "What goes up...". Suicide levels like "Which One?". Marathon: the Gathering levels like "Lord of the Pit". Some Bungie M2 net levels like "Ok, honeybunny" and "Everyone's Mortal But Me".
On the single-player front, M1's "Arrival" for obvious nostalgic reasons. Lots of M2 levels, like "If I Had a Rocket Launcher, I'd Make Somebody Pay" and "Eat It, Vid Boi!!" (if only for the name ;) I'm sure I'm not the only one who still goes "Eat THAT, Vid Boi!" when I do something especially vicious to another player). But the Infinity single-player levels might be the most memorable (sorry Bungie), since that game succeeded in building such a disconcerting, surreal feeling, and some had ridiculously complex level designs like "Aie Mak Sicur."
Many thanks to Alexander, Jesse, Loren and Woody for answering all our questions, and for their continuing efforts to preserve and improve the Marathon experience.