Today I will talk about puzzles -- that is, the various types of iterations and how to use them well. Marathon is not a game that's devoted entirely to action, true, but I fear that some mappers overdo the level of puzzles that should be in an average Marathon map (unless you're making a map specifically puzzle-driven, in which case, you should let the player know that beforehand.
The term "puzzle" is used pretty loosely in Marathon, because it's not a puzzle game. Basically, a puzzle can be considered any situation where something beyond monsters prohibit you from reaching the next room. Puzzles break down into a few categories that are generally different:
Yes, I know that the Marathon engine doesn't support keys. (Tempus Irae and The Gray Incident have "keys," but that's a mapping trick that I may post later.) Key puzzles are unfortunately the most prominent form of puzzle in poor maps -- and way too common in TI.
Key puzzles work like this: press a switch, then look for the door that opened/lift that activated/etc. The name originates from Doom, where keys did exist, and you would have to both look for a key, and then look for the door that you can now open. The same principle is found in Marathon and it's annoying as shit. Key puzzles are a great way to artificially inflate the length of a map. You've got the main section of the map, which you can freely explore without pressing many buttons. But there are locked doors everywhere, so you have to look for a switch. But then, you have to go check out each of those previously-locked doors in turn and see which one opened. Beyond that door is the switch for the next door, repeat repeat repeat.
Why is it so annoying? The task of finding the switch, and then finding the door that opened, really adds a lot of tedium into a map. Most players don't enjoy trekking through corridors where all the monsters are already dead. And most players don't really like being lost at all, either. On the other hand, key puzzles really do extend the length of a map and also re-use areas, which is a mapping trick that really helps save polygons (and fakes non-linearity!). On the other hand, what if the player finds the switch before the door? Now the player has no idea what the switch did at all and can't even backtrack to reference points. It really messes everything up.
The (even more) annoying incarnation of the key puzzle is in a really linear map, where you come across a locked door and find out that you walked right by the switch five minutes ago. Now, if the player is actually told about this (or the switch is obvious) then this is okay, but if you hid the switch somewhere else and the player has to backtrack down your linear map, then that's pretty bad.
Note: puzzles where one switch activates another switch also fall into the key puzzle category. "Keycard" puzzles (in TI and TGI) or situations where you must find an uplink chip expressly so you can open a door (as opposed to some plot-related issue) qualify as well.
So how do you neutralize the downsides of key puzzles? It's not so hard. For instance, making the door that opens visible from the switch that opens said door. That way, all you really have to do is make your way to the door -- since you probably passed by it earlier. If you haven't reached the door yet, well, you know that it's soon to come (though this is usually a stupid idea, unless you have some other reason for locking the door until the switch is pressed).
In the above image, the switch on the right opens the door in the courtyard below that you can see. You absolutely have to open this door in order to exit the level, because the teleport is beyond it. You can't jump out of the window, but you can still get down into that courtyard in a matter of seconds, so the issue is not "find the door, find the switch, then find the door again;" it's just "find the switch," because both iterations of "find the door" are taken care of for you. Of course, you still have to fight the enemies in the courtyard, but you don't have to fight them while looking for your next destination.
Some maps have a version of the key puzzle at its core. As in, it's explicitly stated that "you must find three switches/uplink chips/etc. and open these doors here." This is alright, because there's lots of variation allowed. However, it really helps if you know where the doors are. Most TCs have at least one version of the many-uplink key puzzle, where three/four/six/whatever chips are scattered around the map, and you must put all of them into one bank to open the final door. This is excusable, but not often.
The platform puzzle is the "most traditional" iteration of puzzles, because unlike the other versions, (good) platform puzzles require a certain amount of logic and thinking before you can get beyond. Platform puzzles should not be confused with jumping puzzles (below); in this case, you can't get to the next area because you need to open a door -- like a key puzzle -- but the actual task of opening the door goes beyond simply pressing the button.
The above image represents a very simple platform puzzle. The four doors (marked by thick vertical light strips in the far end of the room) are toggled by the corresponding switches in the foreground. The limitation to this puzzle is that toggling a platform also toggles the ones immediately adjacent to it. The player, thusly, must decipher the combination of switches to press so that all four of the doors are down at once. (Of course, in the image above, it can be done in two moves. The puzzle is not presented as such.)
Above: the classic platform puzzle. The white switch merely exposes the black one. The black one toggles the blue thing in the center -- as well as a door somewhere else on the map; the two are synchronized. The door and the blue thing will both shut eventually; the player must deactivate the black switch while the blue thing is open, thus leaving the door open as well. It's a tricky puzzle, but not if you think about it. There are two instances of this puzzle; the other set of switches is on another side of the room, but it opens a door directly to its right. The principle carries over.
This is all fine and good, but platform puzzles have a battery of problems. The first one is that, with the Marathon engine, there just aren't that many viable applications of the platform puzzle. It's costly in terms of actual platforms used; a map can only have 64 platforms, and the puzzle in the above image used 14. Oh, sure, you can minimize the platforms used; you can use tag switches (much clumsier); there are many options, but ultimately, there just aren't that many ways to really construct a platform puzzle.
Another problem inherent is simply getting stuck. It's hard to test out every way to manipulate a platform puzzle, but you can bet that eventually, someone may try something you hadn't thought about. It's possible that it'll simply negate the puzzle, which is... well, it sucks, because he circumvented your puzzle, but it's not really detrimental. What's detrimental is if he somehow sticks himself. The puzzle is rendered unbeatable due to some variable you hadn't thought of; now a platform that's supposed to be up is down, or something.
The last problem is simply that platform puzzles aren't that fun. Sure, you can get away with one or two, but as I said before, if the player doesn't know that the game consists of lots of platform puzzles (Missed Island), it's really going to piss him off. Some of these puzzles are really mind-bendingly hard and can totally stick the player forever, because he can't get past one area that doesn't even have to do with his skill with a gun. And really, that's what the game's about. If you want to implement platform puzzles, be my guest. Just don't go overboard. Make them fairly simple, and don't put too many of them in there.
Jumping puzzles are very simple things: the player needs to get from point A to point B. However, point B is not accessible without some fancy acrobatics, so the player will need to jump from ledges or platforms in order to make his way up the cliff/across the pit.
At its simplest, the jumping puzzle only requires one jump. Not only is it the most simple, but it's pretty much always acceptable. Nobody's going to get mad at you if they have to jump over the occasional pit -- as long as it doesn't require you to cross over the pit fifty bajillion times. Once you start adding in additional variables, it gets a lot more complicated.
Above: an intimidating, but overall not too difficult, jumping puzzle. The player must jump along the rocky outcroppings along the wall on the right side and ultimately cross over the lava river below into that small red-and-black hole in the center of the image. Some extrenuating circumstances are present to help make it a little tougher. What do extrenuating circumstances consist of? Well, just jumping isn't really that hard, so you have to make it a bit tougher. Making some of the necessary intermediate ledges harder to see is a dirty, but valid, way of toughening it up a bit. Adding in monsters that throw off balance (Fighters, Compilers, and Troopers, mostly) is a much less appreciated way of doing it; their shots really send you flying. You can also have platforms that move up and down, thus requiring you to time your jumps. You can require that the player strafe-runs, or that he comes from a specific angle, and so on.
Okay, so they're not really that complicated. The biggest beef from jumping puzzles is that some mappers just make them too damn hard. In the case of the image above, falling means you die. There's no chance of recovering; you have to reload from a save, so you had better have a save (or some form of returning to the beginning of the puzzle) quickly and easily, because getting through a half-dozen tough fights only to fall because you missed a jump really sucks.
The other thing that makes them less appreciated is simply that they're out of place. You can get away with them sparingly, because they do add a bit of variety to a level -- and certainly, done well, can present a good challenge without unnecessarily frustrating the player. However, you're not playing Mario, you're playing Marathon, so the player will want to get back to shooting things in a hurry. Jumping puzzles should be limited throughout your level/scenario.
The last iteration of a puzzle is barely a puzzle at all, but I guess I'll allow it. An exploration puzzle is simply where you obscure the exit by means of tricky architecture, shading, and so on. "Exploration puzzle" is a really nice thing to call what's basically a maze, and they generally require the whole level. Exploration puzzles are (by nature) non-linear segments where there are dead-ends, looping sections, and other things to make the player wander around. The only way to continue is to keep looking for that one tunnel to continue on.
All I can say is, don't do this. It makes the player feel stupid when they finally find that one tunnel. However, sometimes it comes up unintentionally, and it happens; you don't really suspect that the exit is hard to find because, of course, it's your map; you know where the exit is. Other players might not be so lucky.
Marathon is not a puzzle game, it is a first-person shooter. You are free to add in a handful of puzzles to help spruce up the game and add some flavor, but ultimately, the game is a shooter. The focus of your levels should be more on combat than pressing buttons. It gets old, and fast.
Site designed by Jon Irons