Have you ever wondered about what could possibly take so long when making a module? Or wondered how developers can possibly have messed up again and need another patch? For example, how could opening a door be such a difficult job to code, right? Well, wonder no more, as I share with you a day ... or more ... in a developers life when it comes to coding aspects of ... just a door ... JUST ONE DOOR!
It's Never What It Seems
The bottom line for myself, and I imagine many coders work, will be this ... What the player sees in-game does not reflect what is actually going on behind the scenes. In this case, I'm not talking about the AI of creatures or behind the scenes systems, like weather or mapping, but instead, more dedicated scenes, like a cutscene or a scripted event. Sometimes, there are moments in the game, colloquially know as "choke points", or a "critical path", where the player has to meet certain criteria for the game to move forward, and these points require a lot of checking to ensure everything is just right before the game can move forward ... Now without giving too much away, I hope to explain one such situation using a door as an example.
Multiple Paths
Linear style games, by their very nature, are less likely to suffer from any such coding issues. After all, if there is only one way to open a door (with a key) and there is only one way to acquire that key, then the logical process of acquiring the said key and then using it to unlock the door is pretty straightforward to code. To be fair, many games, including those non-linear games with multiple paths, will still use this kind of linear approach for the majority of their work. The difference, however, is that multiple path games may have a different "key" at the end of multiple linear paths, which may impact upon how they finally open a particular critical door when they reach it. To recap: A linear style will always have a single path, with a single key, that does a specific task. Whereas a multiple path may have many paths to different "keys", which do something different with the door they finally open. This is where it starts to become complicated ...
I've Got The Key!
So the player finally beats their way through the game and wins the key they need to open that door at the end of the dungeon. To the player, it was an inevitable event ... and is the exact feeling a builder wants their player to have. BUT ... and here is the exciting part for both builders and players, what if there was more than one way to bypass that door? Did they have to do what they did to get through that dungeon door, or did another player do it a different way?
In NWN2, we are blessed with great flexibility of play styles, which also already allows some various means to open some locked doors, if setup so by the builder: Bash it, lock pick it, use Knock spell on it, or even just use the key when found. However, with scripting, the means to "open a door" can become much more varied and differ as much as a builder is prepared to put into it. However, having said all this, this is still not the main issue. Let me explain a builders dilemma of a multi-path module ...
What Do I know?
The real issue with any multi-path issue, beyond the various means to bypass a locked door, is what does the player's PC know at the point they reach this door? Recall that reaching this door can vary in a multi-path game, and so the PCs may have picked up various pieces of information or met different NPCs along the way. How much of that information is critical for what lies beyond that door? If it is, then the builder needs to be able to ensure any path the player has taken will leave them with the same critical information as any other player will have received in their path taken. This begins to show the real differences of "maintenance" required between a linear and a non-linear style game. The former, every player receives game knowledge at the same time and pace, whereas in a multi-path game, this knowledge can be gleaned at different rates and times. Welcome to logical flow!
Logical Flow
Generally, if a game cannot suffer from logical flow, then it suggests it must be of a linear design. By contrast, the more multiple paths you start to add, the greater risk of logical flow creeping into the game there is. This risk is compounded by the amount of knowledge differences the player's PCs gather along the particular path they take, which can differ by both the physical path they take, and their personal time path of events along each physical path. An example of a differing physical path is when a party can travel one direction and learn of events along that path before effectively turning back and then taking another path and learning new or complementing knowledge along the second path. An example of differing a time path is when a party of PCs encounter different events at different times along the same physical path. The more points of knowledge the PC gains along either of these path types, usually updated by quest updates, requires more checks at new situations where that quest can be updated again. More importantly, it dictates how NPCs or scripted events act out by the time the player's PCs encounter them.
That Single Door!
So, hopefully, by now, I have explained enough to give you an overview of what can go wrong at any given point in a multi-path game. Let me now take you back to my door event as an example ... and do so in a way that I hope does not spoil anything.
Imagine a situation where the PCs have learned of a task they need to do. They head to it, but the builder knows certain criteria must be met by the time the player "opens that door that must be opened". The builder has to ask themselves certain questions: Have the PCs learned what they need to know yet? Have they spoken to all the correct NPCs yet? Do they need to speak with everyone, or are only some required to be spoken to? What happens if they speak to some and not others and learn only some of what they need to do? In a multi-player game, is everyone there to start as expected? Do the party of heroes have what they need to open the door? Can it be bashed, pick-locked, knocked or does it simply need a key? If so, do the PCs have the resources to bypass it? Is anything else supposed to happen when that door is opened? If it is a critical door, which must respond in some way regardless of how the player interacts with it, have I considered all possible mouse-click interpretations that will lead to the expected event? BUT ... importantly, it's all the stuff that happened before clicking the door that matters!
Let's Rewind The Clock!
Now let us rewind the clock that brought us to this stage in the first place ... because it is about what has already happened that now dictates what the end result will be when the player finally has their PC click on that one door. As a builder, we have to answer all those questions I mention above to a degree of satisfaction before I can write the code that determines what that door does at the moment of a player clicking on it ... and then, consider all possible responses subject to whatever state the party is in: This is governed by such things as basic quest states, but also by many variable states subject to what knowledge the PCs have gained through various sources, such as NPC conversations, books or scrolls read, or any other such information, including what they may have encountered on reaching this point. The point being, the moment a player has their PC click on this door (left or right click, and with any PC or player in a MP game), the builder has to be ready to provide a logical response that will not break the module's sense of flow. If it is a critical door, this can involve a lot of questions that need to be answered before it even opens.
The Critical Issues
Of course, a critical path issue (or "choke point") does not have to come about as the result of clicking on a door, but a door is a good example as it is often the "portal" by which the game concludes in one aspect, but continues to open into new directions beyond. The point is, however, if you enjoy a game with many potential paths through it, allowing you to play it the way you want to, and maybe overcome a challenge differently from another player, then a multi-path game with multiple critical path choke points is likely to appeal to you. The downside is, however, preparing and coding for such multi-path choke points is a lot more involved, and potentially subject to initial potential logical flow issues until ironed out through testing.
So, next time you click on "just one door" or sense a critical path in a multi-path game, spare a thought to the many days it may have taken to ensure the path you took worked out as expected. After all, there may be a few other ways it could have been done, which you may have the pleasure of experiencing if you ever play such a game again.
 |
| It's Just One Door! |
A VERY MUCH SIMPLIFIED EPILOGUE ...
PC Fighter: "Hey, look! It's the locked door we've been looking for!"
PC Thief: "Don't worry, I still have a key."
BOOK KNOWLEDGE READ:
PC Wizard: "Didn't I read somewhere that there is a fake key that summons monsters, if used?"
OR ...
BOOK KNOWLEDGE NOT READ:
PC Wizard: "At last. Unlock it then!"
