Episode 39: The Path Opens Before You!

It's a good feeling when plans start to come together, and the results of the last few days have helped a great deal with that feeling for me. At last, I am starting to move towards conversations that open more paths for the player to follow, which in turn, allow me to start to write more conversations and update journal entries. Read on ...

Opening Up The Pathways

My favourite kind of RPG is one where I can easily switch between the various tasks a module may offer and pursue them in various ways. i.e. I am not forced along a specific linear pathway because that is the way the story goes. Don't get me wrong, I am all up for a very strong and engaging story in an RPG, but how that story develops or unfolds, I like very much to be in the hands of the player. Achieving this, however, is not as straightforward as one may think

The key is to minimise choke points, which are basically those events that do force the player to have to pass a certain point in the game, and which the module designer uses to ensure the player's party is at a certain stage in the overall game. As an example, requiring a key could be designed as a choke point. If not handled well, however, a player with a rogue who can pick locks, or a wizard that can cast Knock, or even a fighter that can normally bash through walls will not be pleased about such from the perspective of player agency. Such points have to be carefully considered, and implemented in such a way that do not spoil the experience, and the builder must do as much as they can to have such choke points appear most logical under the circumstances.

A linear game basically consists of choke points at every stage of the game, and leaves little in the way of choice of direction for the player. Conversely, if used sparingly, such choke points will be conveniently "disguised" among the many other options the player is considering. The downside to designing such a game is that it requires a lot more time to make work, as followers of my bog will have already witnessed. As an example, I have a trigger that a player could activate in one of four states, subject to the path they have taken, with each response varying according to the party makeup. And this is just a small notification trigger that can either update a journal note or a journal quest stage.

The latest news, however, is that I have just passed through another such design aspect and am now able to progress with the main quest and various sub-tasks available beyond this latest choke point. From a design perspective, it allows the builder a little more breathing space to be more creative again. The only problem to remember with such, however, is that all these new paths need to be brought back together before the next choke point! This is less of an issue for side-tasks, but certainly important for the main quest.

The pathways now open again for me, I have already started work on two new quests and a continuation of a third. This involves a few more conversations and new area events, which should all be most fun for me to prepare and interesting to the player too!

Improved Code

Again, thanks to the latest feedback from my wife (who is playing yet another play-through of module one), I have been able to focus on those areas of coding that can go under the radar unless certain playing criteria are met. For example, the efficiency of "loops" in certain areas of code is one huge aspect I have concentrated on since she has been playing with a party size of 10- to 12 members. Other areas include the code around hard-core death, as she in playing another run through that way. Also what happens to certain NPCs who have a neutral faction and have been subject to monster attacks at inadvertent times. All such pointers from such play testing have now been addressed, and serve to make for much more efficient coding, and make the experience more enjoyable.

Most of all, however, being able to apply all the benefits of my knowledge of building module one to module two have been of great benefit. And having a huge library of module one functions to draw upon has made the whole process so much easier ... and fun! There is a definite shift in time spent debugging compared to time spent creating.

As a side note, I intend to release module one v1.36E after my wife has finished pay testing this time around, as there are a number of very useful fixes. 

Finally, here is an screenshot from a stage after moving on from the last choke point!

Never Ignore A Gut Feeling!