Multiple-Message Terminals
By Jason Harper, JasonHarper@pobox.com
Version 1.0: March 5, 1999

This document will expand on the ideas presented by Claude Errera in his "Task-Sensitive Comm Terms on Unfinished Levels" tutorial. To summarize the problem being solved here: Marathon directly supports only one way in which a terminal can change the message it displays, namely by specifying separate Unfinished and Finished messages. The message actually displayed depends on whether the level's goal has been accomplished, as defined in the Level Parameters dialog: Repair, Extermination, Exploration, etc. This is sufficient for many purposes, but does not allow for having more than one condition that affects terminal messages, or for terminals with three or more different messages. Using only basic map-making techniques, these limitations could be worked around by having several separate light-activated terminals, with a series of lights wired to allow only the terminal with the proper message to be accessed at any given time. In fact, this is how the technique shown here works: it's simply a way of stacking these multiple individual terminals so that they appear to be a single terminal with multiple messages. The accompanying Multerminal map contains a basic demonstration of this technique. You might want to play it now, so that the following explanations will make more sense: try various combinations of the three switches, and note that the terminal has a different message for each of the eight possibilities.

BASIC OPERATION

The fundamental idea behind this technique is that if the Action key is used when facing an inactive terminal, Marathon will look further along the player's line of sight in an attempt to find an active one. The search continues until a solid wall (negative space) is reached, or the distance limit for activating a terminal is exceeded. (The search may also be halted by a completely closed platform, I haven't tested this condition.) Any number of terminals can be stacked up, and the frontmost one which is light-activated and lit (or that isn't light-activated, but that would be useless) will be accessed by the Action key. I'm pretty sure that this would work with other types of control panels as well (pattern buffers, switches, and rechargers), but that doesn't seem likely to be useful.

CONSTRUCTION

To make a multi-message terminal, start by building an inset in a wall, just as you would for a normal terminal. Set its floor and ceiling heights as usual, to match the terminal texture. For each additional message that is to be displayed, add an additional polygon of the same width (either rectangular or triangular) behind the inset. Use the same ceiling height, but add a little to the floor height (perhaps 0.05 WU or less) for each successive polygon to produce a stair-step effect. Each stair riser will have a terminal texture placed on it: each will have a different terminal script number and light number, and each must have the Light-Activated box checked.

Don't worry about texture alignment at this point - the backmost terminal can easily be adjusted later, and the other terminals will be completely invisible once you're done.

Once the multi-terminal has been completely debugged (and don't be too quick to decide this), you can clean it up so that it looks like a normal terminal. Set all of the polygons in the terminal inset to the same floor height, and perform any needed texture alignment on the back terminal. You'll probably want to move the points on the sides closer together, so that the total depth of the inset matches that of your other terminals. If you do this, you'll also need to touch up the textures on the side walls, since they will no longer be aligned properly. Note that when you're done, the terminals other than the one in back will not have a single pixel visible from any direction, and will be completely undetectable by any means other than examining the map in an editor - but Marathon still knows they're there, and will check them in order from front to back when the Action key is used here.

TERMINAL & LIGHT ASSIGNMENT

The procedure above glossed over the need to create lights to control the terminals, and indeed no universal answer is possible - it all depends on exactly how and when you want your terminal messages to change. Here are some general hints, and solutions for some specific cases.

• The backmost terminal will probably be permanently lit (light #0), unless you want a condition in which no message at all is to be displayed (such as not having turned on the power yet). Be careful to avoid any possibility of having the back terminal dark, but one of the others being lit. In general, the message on the back terminal will reflect the initial conditions when the player entered the level.
• It is not necessary to have exactly one terminal lit at a time. Examine all conditions in which multiple terminals can be lit, and ensure that the one with the message you want the player to see is closer to the front.
• If the terminal messages represent a series of events that the player can ONLY do in a specific order, then the design becomes simple. Assign the terminals in chronological order from back to front, with lights that are turned on by the corresponding event - via a tag, activated by a door that the player must have opened, by a light-on polygon that the player must have walked through, etc. The most recently completed event's message will appear on the terminal. Note: beware of players missile-hopping to avoid events that you intended to be unavoidable! If you haven't seen the Marathon Hang Time Guide (available at your friendly neighborhood Marathon Archive), you probably have no idea of what a skilled player armed with even the Assault Rifle is truly capable of - would you believe climbing 8 WU straight up a wall?
• If you want the player to be able to complete events in an arbitrary order, with terminal messages that accurately reflect what has and hasn't been done yet, you're going to need a fair amount of behind-the-scenes machinery to implement this. For example, the demo map, with three "events" that can occur in any order, uses a mechanism consisting of 11 platforms to detect the various possible combinations of events. For general techniques for constructing such mechanisms, see my Missed Island scenario - it's on the Marathon Trilogy Box Set map CD, and available for download here. The remainder of this document will build upon the information included with Missed Island to design some mechanisms of specific use for implementing multi-message terminals.

AND GATES REVISITED

Missed Island discusses a couple of techniques for implementing an AND gate - in electronic terms, a circuit whose output is active only if every one of its inputs is active. Those techniques involve one creature shooting at another, with intervening platforms or liquids (controlled by the inputs) that can block the projectile, preventing it from hitting a switch (which controls the output). Described here will be a completely inorganic form of AND gate. It has a higher cost in terms of number of platforms needed, but is much easier to set up as it is completely independent of the physics model and shapes file that are used, and its response time is not affected by the player's selected difficulty level.

Note that it is easy to build an OR gate - a circuit whose output is active if at least one of its inputs is active. Up to 8 input platforms can surround an output platform, and any one of the inputs can trigger the output by setting an appropriate flag. Now, here's the trick: if you invert (interchange the 'active' and 'inactive' states) all of the inputs and the output of an OR gate, the result is an AND gate. (And likewise, inverting the inputs and output of an AND gate produces an OR gate. These are known as De Morgan's Laws, in case you ever get asked on a quiz show.) To invert the state of a platform, set its Deactivate Adjacent on Activating and Activate Adjacent on Deactivating flags, and put another platform next to it - the new platform will be active when the original is inactive, and vice versa. The desired form of output for our uses here will be a light, which is even easier to invert: just set the light parameters so that it is dark when active, and bright when inactive. Remember, for purposes of a light-activated terminal (or other control panel), it is the actual brightness of the light that counts (76% or higher allows activation), not the active or inactive state of the light.

Before we proceed, let me introduce another bit of digital electronics notation. The name of a condition, with a bar over it or a slash in front of it, represents the inverse of that condition. Much of the mechanism I'll be describing here works with inverted conditions (and coincidentally, the same is true of much actual electronics), so this notation saves a lot of space over writing "the inverse of" or "NOT" each time. I've used overbars in the labels on the actual map, but I'll have to use slashes here in the text since my word processor doesn't support overbars. Examples: /1 represents a platform that is active only when tag 1 is inactive, and /12 is a platform that is active when either tag 1 or tag 2 is inactive.

The mechanism for the demo map needs to be able to distinguish each possible combination of its three inputs, which are switches controlling tags number 1 (left), 2 (middle), and 3 (right). The specific outputs needed are each combination of two active inputs (1 AND 2, 1 AND 3, 2 AND 3), and for all three inputs being active (1 AND 2 AND 3). These are implemented using De Morgan's Law as mentioned above: for example, 1 AND 2 is actually built as NOT(/1 OR /2). To save platforms, each of the three tags is inverted once, and the result is shared between the OR gates using that input. This has the effect of turning the whole mechanism into a single, indivisible lump, rather than four independent gates.

Here's the complete mechanism (except for a platform labeled INIT whose purpose won't make sense until later). Arrows indicate the flow of control between platforms. The platforms labeled 1, 2, and 3 are the inputs, controlled by the corresponding tag switches, which also control lights 21 (red), 22 (green), and 23 (blue), respectively. The important settings for these platforms are: Deactivate Never, Deactivates Adjacent on Activate, and Activates Adjacent on Deactivate. These settings cause the adjoining platforms to be an inverted version of the tags, and therefore those platforms are labeled /1, /2, and /3.

The inverted platforms also have Deactivate Never set. They move fast, have a short range of motion, and have the Activate Adjacent At Each Level flag set, so they constantly activate the nearby platforms (except for the input platform that triggered them, due to use of the Don't Activate Parent flag).

The output platforms (/12, /13, /23, and /123) are also fast moving, and have Deactivate At Each Level set so that they will quickly shut off in the absence of signals from /1, /2, or /3. The output platforms control no further platforms (which would be disastrous, they're adjacent to too many other things), but instead control lights (24 thru 27) which are used to activate terminals, and also form part of the diagram on the floor. As mentioned earlier, these outputs need to be inverted, which is done by assigning 0% brightness to the active state of the lights, and 100% brightness to their inactive state. The lights also have to handle the fact that the platforms controlling them are not quite continuous: there are regular brief pauses between the time that the output platforms deactivate themselves and the next time an input platform reactivates them. This is accomplished by assigning a Becoming Inactive phase that extends the Active phase's brightness (0%) for 10 ticks, long enough to cover up these pauses.

STARTUP CONSIDERATIONS

The mechanism as described so far performs just fine once it's running, however it has a problem at startup time. Consider what the initial state of the platforms ought to be:

• Platform 1 (as well as 2 and 3) should initially be inactive, since the tag switch controlling it starts out inactive.
• Platform /1 (and /2 and /3) should therefore be initially active.
• /1 will quickly activate the adjacent output platforms, so their initial state doesn't matter.

The problem is that platform /1 will also activate platform 1, getting the mechanism out of sync with the tag switches. The Can't Activate Parent flag on /1 doesn't prevent this, since an initially active platform doesn't have a parent. It is therefore necessary to start up the mechanism in the opposite state: 1 active, /1 inactive. An additional platform labeled INIT (not visible in the diagram above) starts out active, but quickly deactivates itself and the adjacent platforms 1, 2, and 3, placing the mechanism in the desired initial state. INIT has the Activates Only Once flag set, and therefore has no further effect on anything. The need to have the INIT platform adjacent to all three inputs resulted in the rather strange shape of those platforms.

USING THE OUTPUTS

Note that the mechanism does not supply a single, distinct output for each of the eight possible combinations of its inputs. In particular:

• There is no output to indicate that none of the inputs are active.
• There are no outputs that indicate that exactly one of the inputs is active.
• The outputs corresponding to two active inputs remain active even if the third input is also on.

As mentioned before, it is not necessary to activate exactly one terminal at a time: it is sufficient to recognize the conditions where more than one terminal is active, and make sure that the proper one is closer to the front of the stack. Applying this rule results in the following terminal assignments:

• When all three inputs are active, ALL of the output lights are lit. Therefore, the terminal activated by the proper light (#27, controlled by platform /123) must be the frontmost one.
• When two inputs are active, both the proper output light (#24-26) and the lights for the two active inputs (#21-23) are lit. Therefore, the terminals controlled by lights 24-26 must be in front of those controlled by 21-23.
• Since there is no specific output for all of the inputs being off, the corresponding terminal has to be the permanently lit one in the back (the one terminal the player can actually see, in the completed multi-terminal). It will be accessed only of none of the output lights are lit.·

To summarize, here are the complete terminal and light assignments for the demo map, in order from back to front.

MultiMessageTerminals