Follow the Yellow Brick Road

How to keep the player aware of their objectives

We're off to see the Wizard of Tulku

Loving Hexen II for more than 20 years should not blind us to its faults. One of the main criticisms against the game has always been the difficulty in keeping the thread of the quest, when to achieve objective A you must first go to place B which is sealed with the key C which is in level D which can only be accessed thanks to the item puzzle E which itself... Well, you see what I mean.

I guess people having made such criticisms focus mainly on the Thysis hub and maybe also a bit on Blackmarsh, the other hubs being more straightforward. I am pretty sure that another phenomenon has also come into play to aggravate the frustration: the two aforementioned hubs tend to be quite labyrinthine and very homogeneous in appearance: nothing looks more like the corridor/entire map where you are than the corridor/entire map you just came from. Would you remember what you are supposed to do, you might spend 15 minutes running like a headless chicken in identical lanes before being able to rediscover the right place to do it.

The player should never be put in such a frustrating situation. At all times they should have at least a rough idea of where they are and what they are supposed to do:

Never lost & never stuck

That should be your sacrosanct motto as a mapper.

Never lost means you have to carefully design your maps with enough variety and striking landmarks so the player never loses their sense of direction. You might want to lose the player on purpose, as in Quake's legendary Azure Agony level which is deliberately a claustrophobic nightmare. But trying to do so chances are you rather will end up with an irritating undifferentiated labyrinth having the appeal of a level from the original Wolfenstein 3D (also an "azure agony" of its kind, but not for the right reasons). Anyways, the whole atmosphere, gameplay and gamers themselves are not the same when you compare Quake to Hexen II. So better forget it.
I won't elaborate further on that topic: far more prominent mappers have written books about that, for example The Hows and Whys of Level Design by Sjoerd De Jong. So the better is to read them (I saved a copy of the aforementioned one in case the link is broken).

Never stuck means the player should never face a situation where they don't have the slightest idea about what to do next, whatever it is because it's not clear or they just forgot along the way. Unlike level design which is entirely your responsibility, the guys at Raven, aware of the criticisms against the base game, have introduced something new to help keep focus on the objectives in Portal of Praevus. Guess what? It calls trigger_objective.

trigger_objective is the entity responsible for that kind of reminder about the current to-do list, that the player can check anytime during the game when pressing the "o" key:

Find the spring that leads to the village well
Get the Sphere of Order from Eidolon's Throne Room

Might have been sooo valuable at the time of the original game. Great it came eventually, but too bad it came too late. Because honestly, PoP hubs are much less complex than the previous ones and, while still a good idea, objectives are no longer really essential. Especially the way they're implemented, imho. Look at the screenshot above. "Get the Sphere of Order from Eidolon's Throne Room": OK the message is pretty clear and you can't get confused when you discover the throne room: it really looks what it calls (and the Sphere of Order is so blantantly waiting to be picked up that there is no real need to say). Concerning the other one "Find the spring that leads to the village well", the objective is present in the list as soon as the player spawns. Wait a minute, what village and well are you talking about, to start with? The hero has just jumped down in a hole in the ground and arrived in front of the most powerful Serpent Rider's lair... and a note pops from nowhere talking about a village and a well. WTF?! Should I even mention what the first clear but bogus objective becomes once you have the Sphere in hand? "Take the Sphere of Order to the Thaumaturgical Conveyance". No, really guys? "Thaumaturgical Conveyance"? A term which, by the way, is never ever seen NOWHERE ELSE in the level, even where you are at the right place...

trigger_objective is a great idea, it's just that the way it was used in practice tends to suck. But don't give it up for that reason: it's up to you to use it a better way in your own maps. It's definitely an overlooked feature but caring about it means caring about the player and showing them you spent time even on small details to make their experience the best possible. It's a kind of nice wrapping around the gift that your map is to them, just like intermissions. And who knows, that may really help the player to figure out what to do. I've already been stuck in custom maps with no clue about the next move...

It is dead simple to set up, so there is really no excuse.

trigger_objective
targetname	It's a point entity so it has no touch function and must be triggered by a button or trigger or whatever.
frags	An integer refering to a message line # in infolist.txt in the mod's root directory. ⚠ Caution it's a zero-based index, so always put the line # minus 1 in frags.
spawnflags	Either check 1 to add the objective to the to-do list or 2 to remove it.
target	This property is not supported, although TrenchBroom incorrectly states otherwise. You should edit your Hexen2.fgd to remove it from the entity definition and get rid of the inconsistency: @PointClass base(Appearflags, Targetname, Target) = trigger_objective : "Trigger objective (PoP)"

It's interesting to note that no matter the order in which the player gets their objectives, they are always displayed following the frags order. That's why you must pay attention to have your infolist.txt sorted according to the logical order of actions.

Please also note that for each objective there must be always two trigger_objective entities: an ON entity (spawnflags = 1) and an OFF entity (spawnflags = 2). An objective added to the list but never removed once the conditions are met would be a pig's ear.


Actually the trickiest part about objectives is not how to set up the entity: it's to always ask yourself about the objectives' lifecycle.

Consider such objectives:

1. Get the Emerald key to open the gates of Emerald City.
2. Find the Wizard.

#2 may enter the to-do list very early, but anyways only has a chance to be completed after the gates are open. So #1 is a pre-requisite and should obviously enter the list when the player reads a plaque telling about the city entrance or missed the plaque but finds itself in front of the closed gates. Now, what if they found the key even before that? They may read the plaque or get to the gates later on, but this time none of those situations should trigger objective #1 because it has become obsolete.

The rule

When an objective is acomplished, not only must it be removed from the list by its OFF trigger_objective, but its ON trigger_objective must also imperatively be disabled at the same time in case it has not been triggered yet.

Incidentally, an ON trigger_objective entity can only be triggered once (just like a trigger_once), then it's removed from the game. At least one thing you won't have to worry about.


Finally, if I should sum up the caveats for the proper use of this entity:

• Always use it to remind the player of something they already know, not to drop new info (which is the plaque entity's job). In other words: beware the Village Well Syndrom!
• Don't make cheesy objectives about self-evidences (Get the Sphere Syndrom).
• If the player is likely to wander for a little while before they can achieve the objective (because the map is huge, or the required actions are spread out in several maps), then it may be good to remind where the objective needs to be completed. But then of course, make the name of the place clear enough (Thaumaturgical Conveyance Syndrom).
• And above all, always ask yourself about the objectives' lifecycle and bind their adding or removing to the very corresponding actions (not sooner or later) to keep consistency anytime.