Marathon Engine Improvements

The engine is the Marathon app, the part that contains the executable content (the instructions for the CPU). The other files are the data files, which contain essentially all the artwork, sounds, maps, game-physics parameters, and so forth. There are three flavors of the engine, one for each of the three Marathon games (1, 2, and Infinity), but the third one is essentially the second one with a few extra features. However, since it is the most advanced one, it is the most likely candidate for patching. One problem might be that extra data would create incompatibilities in data-file formats; this can be avoided by keeping the old data files, but overriding their contents with new data files.

• Hardware Acceleration of 3D Rendering, which has become a common option in real-time-3D games, and in some, it is mandatory. There are several nice things that could be done with the assistance of such rendering:
  • Filtering of nearby surfaces, which keeps them from looking pixelated and instead makes them look blurry, which is usually a much more pleasant appearance.
  • Mipmapping of distant surfaces, This prevents moire effects, sparkling, and the like by doing local averaging in advance. The mip sets can be constructed automatically for every texture loaded, meaning that extra data may not be necessary.
  • Semitransparency of liquid surfaces, which will require altering the visibility calculations to assume that liquid surfaces are transparent rather than opaque, so one can see what is behind them. These surfaces will then be rendered with some constant transparency value.
  • Refraction, which could be approximated with manipulations of coordinate-transformation matrices, but those manipulations will be rather tricky, and may require serious engine modifications.
  • Bigger range of colors for wall textures, which can be done with 16-bit or 24-bit images; this will require new texture data, which is best placed in separate files. These wall textures could override existing ones. Glow mapping can also be implemented -- this is creation of an extra texture image that is unaffected by the surface's lighting. A shortcut could be the creation of a "glow strength" image.
  • Semitransparency of wall textures, which will require new texture data, because the current sort of transparency is all-or-nothing. However, auto-mipmapping could generate distant semitransparent textures automatically.
  • 3D-model landscapes, which is what Unreal does, and this would require some serious engine additions and some new data. For this, one creates a 3D-model landscape and adds a viewpoint position, which stays fixed. There are various shortcuts that can be used; for example, Quake 2 uses a textured cube for its landscapes. These landscapes could override existing landscapes.
  • 3D-model inhabitant objects, which would require some major additions to the engine. However, models with animations, such as Quake character models, could have sets of animation frames mapped onto Marathon-engine sequences. Different color-table selections could be mapped onto different skins. These models could override existing inhabitant sprite sets.
  • True bridges, etc. This may require essentially a new engine, one that does full-scale 3D. An alternative would be to create some inhabitant objects that would then serve as those bridges.
  • Fog and murk, which could be set for each kind of environment (air, the various liquids); the fog would have both an opacity and a color.
  • Point-source lighting. Some of the characters, weapon firing, and explosions could be made to illuminate their surroundings. One may have to use such shortcuts as not casting shadows, but it would certainly be feasible. And one will have to do visibility calculations to find out which surfaces will be illuminated.
  • Z-buffering, which is per-pixel depth sorting. The Marathon engine does not use this, because its portal rendering does the depth sorting automatically. However, if an object that belongs to some polygon is dragged outside of it, it will still be visible -- at a distance. Z-buffering would hide it until it crosses into the polygon.

  Some of these add-ons could be specified in an extra preferences panel, while some would belong in an extra data file. The preferences panel would contain global stuff, like:

  • Whether to do any 3D-accelerator rendering
  • Preferred rendering engine
  • Whether to do liquid transparency
  • Whether to do self-luminosity (may be subdivided if desired)
  • Whether to do the aforementioned overriding of existing data

  The extra data file would contain more specific stuff, like:

  • Extra wall textures, or references to them
  • Transparency parameters
  • Fog parameters (color, opacity, etc.)
  • Luminosity parameters (how bright, what color, what range)
  • Models for landscapes and objects, or references to them

  Such a data file may be constructed as a list of chunks. Each chunk contains a designation of the entity being replaced or modified, followed by that replacement. The engine would search these chunks, and then use their contents to modify or replace whatever entities were specified in them. An editor would create a list of chunks to select from, which can then be created, modified, and deleted. Several of these parameters could easily be set inside that editor, but it would not do either 2D or 3D editing. It may, however, have 2D and 3D preview modes.

  An alternative to this approach would be an ASCII script file that would be much like Quake 3 Arena's shader files. This would be easier to edit, requiring only one's favorite text editor. Images and models would, of course, be stored in separate files. And with a good text parser, this could be a very flexible approach.

  Last, but not least, there is the question of what 3D-rendering Application Program Interface (API) to use. Here are some common choices:

  • OpenGL. This is a cross-platform standard developed by Silicon Graphics, Inc.. It is abundantly documented; a good place to start would be this website devoted to it. It is relatively simple and straightforward, and it should not be too difficult to add it to the Marathon engine. Apple is now officially supporting it, meaning that we now see more MacOS apps using it, including games.
  • QuickDraw 3D RAVE. The Render Accelerator Virtual Engine is a low-level hardware-abstraction API for communicating with 3D cards. It is rather primitive in some ways; for example, unlike OpenGL, it assumes that all objects' coordinates are in view space, and it does not do clipping to the viewport. And given Apple's support of OpenGL, it seems likely to become a legacy API.
  • Direct3D. This is Microsoft's attempt at constructing an OpenGL clone. It is, of course, Microsoft-specific, and its Windows NT version lags behind its Windows 95/98 version (as I write this, #3 with unofficial #5 vs. #6 and soon #7). And like RAVE, it is limited to having objects' coordinates in view space.
  • GLide. This is specific to the 3Dfx family of cards; its creators have gone so far as to threaten legal action against those who have tried to make GLide-to-Direct3D adapters, thus limiting its usefulness as a general-purpose API. And like RAVE, it is limited to having objects' coordinates in view space.

  My pick is OpenGL, because of the features listed earlier about it; I don't have either the facilities or the inclination to try to support the other three.

• Increasing resource limits and correcting various misfeatures and bugs. Though this need not break file-format capability, this may result in data files that work poorly with, or are even incompatible with, existing versions of the Marathon engine. Here's a list of various such changes:
  • Increase number of map entities, which include the number of polygons, platforms, lights, liquids, etc.
  • Increase internal limits, which include the number of active NPC's at any one time (currently limited to 16) and the size of the transparent-lines database used in visibility calculation. The latter had been raised in the Win32 version of Marathon 2, but not in the later MacOS versions of the Marathon series.
  • Correction of poor design, examples being Marathon 1's inclusion of filenames and terminal texts in the engine file, and Win32 M2's having its chapter-screen list hardcoded in its engine.
  • Correction of engine bugs, which include
    • Difficulties in seeing more than 32 World Units (1/2 the world size).
    • The non-implementation of 3x wall-mounted rechargers in the M2/Moo water texture.

• Internet-friendly networking. For Internet duty, a game engine ought to support TCP/IP networking and to have client-server networking. The MacOS version of the Marathon engine has neither of these, however; it uses a coequal model and only uses AppleTalk. However, these should not be too difficult to add with Apple's NetSprocket library, which has now been open-sourced in the form of OpenPlay. For more on that, check out Apple's Public-Source Site.

  A simple networking approach would be for each of the participants to send their inputs to the game host, which then collects them and sends back collections of them at each time step. Alternative approaches are sending back the current positions of each of the inhabitants, or their changes from the last clock tick.

  Fine-tuning such networking to get good performance over slow or laggy (or both!) connections, will, however, be difficult, as the makers of Quake and Unreal have learned from bitter experience. There are some hacks that can be used, such as attempting to predict how the inhabitants will move, but I'm not sure if doing such things is worth the trouble here.

  No matter what kind of networking is used, no data-file modification will be necessary, except perhaps to store persistent networking information, such as one's favorite IP address to connect to, in the preferences file.

  A very useful addition to such networking is some sort of in-game chat facility, because of the physical separation from each other of most Internet gamers. This could be coupled with a Myth-like "anteroom" facility for added convenience in setting up over-the-Internet games.

• Improved AI and NPC Communication. This can include a variety of things:
  • Commands to friendly NPC's to
    • "Get out of my way"
    • "Follow me"
    • "Disperse"
    • "Stay where you are"
    • "Get them!"
    Such commands may have to have "decay times", so that if one gets preoccupied with something else, one's friends won't end up stuck doing the wrong thing.
  • Pack behavior, meaning staying in groups.
  • Self-preservation, such as doing hit-and-run attacks.
• Porting to other platforms. This is so users of other operating systems and hardware can play the Marathon games. This can be done with the help of the code that Bungie had written for the Win95 version of Marathon 2. The reason this can be helpful is that the Win95 version had to use flat filesystems, as opposed to the MacOS, with its two-fork filesystem (the "data fork" is flat, the "resource fork" is a mini-database). And since most other OSes support something like a flat filesystem, using code appropriate for one is the way to getting good portability.

• Other nice features. One of them would be a clean way of switching from the Marathon app to one's other software, something like what is implemented in the MacOS versions of Tomb Raider 1 and 2. The game gets paused, the display gets hidden, and one gets switched to the Finder (or its counterparts in other OSes).

  Another would be some of those proposed by Christopher Lund, clund at notam.uio.no:

  * Polys that activate tags.
  * Monsters activated by tags.
  * Breaking scenery objects activates tags (or lights).
  * Improved AI.
  * Alien/friend icon choise in motion detector.
  * Ambient/Random sounds with volume controlled by light.
  * Removal of "bouncy" bug.
  * Removal of line of sight limits (or at least a massive increase).
  * Removal of "vertice lineup" bug.
  * Multiple physics for each level. Physics could change when the level is
  completed, when tags are flipped, or when polys are walked on.
  * The ability to return to previous levels.
  * Conditional entry points in a level. Fex: When coming from so and so
  level, the player starts at location X using physics model Y.
  * Improved respawning. If you set it to 100%, you should get a new monster
  100% of the time. ;)
  * Break limit of 32(?) active monsters on the same level. Alternatly, let
  monsters "go asleep" if too many are activated at a time.
  * Extend max # of objects per map. 200-300 is not enough.
  * Extend limit of polys. 1024 is not enough.
  * Extend limit on #  scenery objects pr collection.
  * Extend limit on # of sounds.
  * Material properties for surfaces, such as hard, soft, brittle,
  flammable, etc. Has effect when surface is shot, burned, battered, etc.
  Ricochet or splinters?
  * "Scenery" (aka decals) that is flat, and is slapped onto
  surfaces as if they were textures. Could be used for burns, bullet holes,
  blood splashes, etc.
  * Ability to determine (via Anvil/physics) which types of damage cause
  death in fire.
  * Increase max # of scenery objects that can be in view at a time before
  removing ones at the back.
  * Conditioned teleport polys. Fex light-sensitive or tag-activated.
  * Let level parameters such as vacuum, gravity, and magnetism be altered
  by switches/tags, and so on.
  * Number of tags increase as you use them, not just a fixed number. I
  guess that's a Forge hack rather than an Engine hak.
  * Allow texture fx to be applicable to scenery as well, fex pulsating.
  * A texture fx map similar to the lightmap proposed by Loren, so portions
  of a texture could pulsate or scroll, while the rest does not.
  * Being able to put an upper or lower limit on a textured poly boundry,
  and ditto for an eventual "solid" tag. This would make it possible to make
  waist-high picket-fences one could grenade hop over.
  * Smashable/destroyable "solid" poly boundry. Ie it's solid until you
  shoot it (and a breaking glass or whatever sequence is played). Should be
  optional, btw.
  * Fix bug that makes monsters invisible when standing on very thin polys.
  * Add "scenery" section to the physics file.
  * Add "powerup" section to the physics file.
  * Add a "Move!" key to get friendlies out of the way without shooting them.
  

However, only the Marathon 2 source code has been released, though this may be enough to construct imitations of Marathon 1 and Marathon Infinity. Disappointingly, neither Forge nor Anvil source code was released.

Return to my Marathon page