Counter Revolutionary
Or, How To Teach Basic Arithmetic Skills To Marathon Creatures
By Jason Harper, JasonHarper@pobox.com
Version 1.0, 4/1/99

The accompanying map illustrates a technique for making your levels count - from 0 to 8 in this case, although it can be extended much further than that. The items being counted could be the number of players present in a solo/co-op level, the number of level goals that have been accomplished, the number of secret areas that have been found, or most anything else.

-=[ REFERENCES ]=-
The techniques developed here build upon previous efforts by myself and other mapmakers, which you'll need to be familiar with to make any use of this information. In particular, you MUST have Mark Levin's Co-op Only Level Bypass Tutorial, it was my immediate inspiration for this map, and contains information on relevant applications and techniques that I haven't bothered to duplicate here.

Extensive use is made of the multi-stop platform technique, which is discussed in detail at the Hastur's Workshop site and in my Missed Island map: A related technique, in that both are ways of making a level that responds more precisely to the player's actions, is given in my Multiple Message Terminals tutorial which in turn builds upon Claude Errera's Task-Sensitive Term Tutorial:

-=[ INTERMISSION ]=-
Please take some time now to actually play the map in Marathon Infinity: most of the documentation on the techniques being demonstrated are contained in the map's one terminal. The rest of this document contains details and ideas for further development, that won't make any sense until you've seen the counter mechanism in operation.

-=[ DOOR PARAMETERS ]=-
As promised in the terminal, here are the parameters for the nine doors in the map that allow them to open and close sequentially in response to events. Please note that this set of parameters will work only for counting up to 8: a 9th activation will reopen some of the earlier doors, and things just get wierder from there.

Common to all doors: Extends From Floor, Deactivates At Each Level, not initially active unless otherwise indicated, floor height 0 WU, ceiling height 9 WU, min height 0 WU.

NOTE: Doors 1 and 2 have to be specially handled. If they were set according to the same pattern as doors 3 thru 8 (which would mean max heights of 1 and 2 WU, respectively), they would initially open at the right time, but would open again at inappropriate times before the count reached 8. In particular, door 1 would alternately open and close on every event! To give these doors a sufficiently long operating cycle, their max heights are increased by 3 WU. They are initially active, but an adjacent platform (not visible to the player) deactivates them after they've moved by 3 WU, thus leaving them at the proper initial height. This all takes place within the first half second of starting the level, so you'll never notice it (and it takes more than half a second for the moving creatures to reach the trigger platform, so this doesn't create a problem with counting events even if they occur precisely at the start of the level).

To extend the counting range somewhat beyond 8, you'd need to add similar initialization platforms for more doors, and also increase the amount by which the existing initialization platform allows Doors 1 and 2 to move. If you increase the range to more than 9, you'll have to either make the floor height negative, or have doors that move less than 1 WU per count, due to Forge's -9..9 WU height limits. Exercise for the reader: extend the chart of platform heights to the right (note that the numbers simply go back and forth between 0 and the door's max height), to see what the door positions would be for counts beyond 8. A position of 0 (as will happen for Doors 1 and 3 on the next count) indicates an inappropriate reopening of the door.

-=[ POSSIBLE APPLICATIONS ]=-

• SOLO/CO-OP PLAYER COUNTER
  This was the original intended application that lead to the development of this technique, but please note that there would be problems in using the complete counter mechanism (as shown in the demo map) for this purpose. You might think of interesting ways in which to use an exact player count (for example, having more monsters appear if there are more than 3 players), but consider this: what happens if a co-op player dies, and regenerates on a starting location that hasn't been used yet? (I'm assuming that regeneration locations are randomly selected, but I've never actually played a co-op game.) After sufficient player deaths in a co-op game, the counter is going to be set to 8 regardless of how many players there actually are. This should be mostly fixable by disabling the counter (perhaps by closing a door between the Bobs and the trigger platform) after enough time has passed to have counted the initially used player starting positions, but I think that co-op players could still inflate the count by intentional suicides in the first few seconds of the level.
  
  A simple solo vs. co-op determination (count of 1 vs. more than 1) wouldn't suffer from this problem, and could be implemented with total of 3 or 4 platforms. See Mark Levin's map for the design of the two doors. You'd also need a control platform, and perhaps a separate trigger platform if you can't arrange for the Bobs to walk directly over the control platform to trigger it.
  
  
• VARIABLE REWARDS
  Let's say that you have a level with various secret areas (we'll assume 8 of them, to match the demo mechanism), and want to reward the player based on how many he managed to find. Each secret area would contain one of the event triggers, and the counting doors would be at the very end of the level. Perhaps Door 0 could have something nasty behind it, to punish the player for not having found anything. Doors 1 thru 3 wouldn't exist, since that's not enough secrets found to justify a reward. Doors 4 and up would have a rocket launcher, with one additional rocket 2-pack for each door beyond #4. And Door 8 would reveal your Ultra Secret Hidden Terminal, accessible only to the true masters of the game who have uncovered all your secrets (and to those who have examined your map in Forge, but there's not much you can do about that...).
  
  The same basic idea could be applied to any non-linear level, to create a predictable sequence of results (such as combat with increasingly difficult foes) regardless of the order in which the level's goals are completed.
  
  Note that when applying these ideas to a solo level, it would probably not be physically possible for any two of the events to occur without a fair amount of time passing between them. Therefore, you wouldn't need the Bobs & Ticks: the events could directly trigger the control platforms without any danger of missing an event. You'd only need a serialization mechanism if the level could be played co-op, or if some of the events could happen without the direct presence of the player.
  
  
• CHECKLISTS
  This doesn't have much to do with counting, but I think it would make for a very nifty level so I'm going to include this suggestion anyway.
  
  Imagine that you've got a non-linear level, with several goals that the player can complete in any order, and you want to keep the player informed as to which goals still need to be done. In some central location, that the player can get to most of the time, make a checklist out of several map text items. It might initially look like this on the automap:
  
  CHECKLIST:
  Repair igniter mechanism
  Restart coolant pumps
  Eliminate enemies in turbine room
  Download reactor control program
  
  Now, let's say that the player has managed to restart the coolant pumps. In the process of doing so, he will somehow trigger a Bob outside of the visible portion of the map: perhaps via a monster trigger polygon, perhaps via opening a door that allows the Bob (previously activated by other means) to finally move somewhere. The Bob will run through corridors measureless to man, down to a sunless... oops, sorry, wrong storyline. Anyway, have the Bob travel through a corridor unconnected to the player-accessible portions of the map (probably at a height of -9 WU, so it can easily be hidden via Forge's Height window), to a point just to the left of the corresponding checklist text item. There, a crushing platform or other fatal condition kills the poor Bob (or he could simply fall into a hole he can't get out of), leaving his blinking blue locator dot permanently on the automap at that location. Now, the automap will look like this:
  
  CHECKLIST:
  Repair igniter mechanism
  * Restart coolant pumps
  Eliminate enemies in turbine room
  Download reactor control program

Get the idea? If the particular type of Bob used does not otherwise appear on the level, you might consider increasing its movement speed in the physics model, so that the blue dot appears in the right location sooner.

Jason Harper
http://pobox.com/~JasonHarper

Counter Revolutionary