Previously, I went over the basics of the GB system, giving a simple example of an interaction, this time, I went to talk more about the structure of the interactions and how they are composed. This is a highly modular system primed to re-use pre-prepared components and is also extremely interoperable with everything else in the game. From all of the AI modules to the phrase/dialogue generators.
1) Scenarios
Every significant interaction in the game is described as a scenario. The goal of a scenario is to set up any data that will be needed and seed the stack with initial elements to process. A lot of this setup is further generalised, so it doesn’t need to be re-written each time. A significant part of this pre-written code is setting up the GB system itself and, optionally, a character for interaction.
Thus every interaction starts with calling a scenario that does the initial setup and doesn’t matter after that. This means that once running, the system can smoothly interpolate between different scenarios or call them recursively if you prefer.
As an example, let’s use a situation where the player character encounters a minor character they already know while moving from location to location.
2) Behaviours
Most interactions will have some generic elements that can be repeated across different scenarios. Such isolated, generic blocks that can include some narration, dialogue and responders (as well as other things) are called behaviours. There is no significant difference between the way a behaviour is written compared to a scenario, except that they don’t perform any setup. They can still use the full range of options available in the system but don’t describe full interactions or events, just parts of them.
In the example given above, the scenario could start with a “hello” behaviour of the “chance meeting” flavour and then end with a “goodbye” behaviour with the theme of “parting ways”.
Due to their generic nature, behaviours will often use procedural generation to offer diverse narration and dialogue over subsequent uses. Again, this is an element of interoperability, as it will often call back to various phrase generators defined for general usage already.
3) Responders
While every responder is an individual definition, a responder can be built from parts. Therefore, sometimes it makes sense to provide some generic responder options that can be quickly added to an interaction.
This can be used to bridge from the GB system to the various available phrases – for example, “hello” while also allowing the predefined handling to take as much data from the system’s setup as possible or to define whole mechanics, such as the emotional responses.
The goal of these fragmentary responders is to provide a way to build complex interactions quickly by providing a way to drop in what can be the equivalent of a whole small conversation tree.
4) Dialogue and narration
In the previous article, I went over how two of the most elementary elements used in the system are dialogue and narration calls. Predefined forms of such can also be accessed. Some are simply phrase wrappers, while others can be written specifically for the sake of the system.
The GB system, as an integral part of the game as a whole, supports the procedural generation of text. In many cases, it’s worth considering if a given phrase can’t be in some way parametrised.
5) Tools and essentials
Sometimes it’s important to use something from outside of the GB system from within it. For such cases, the system provides some tools and essentials. The difference between them is a bit subtle, but some examples should clarify it.
Tools are used when the GB system has to access existing mechanics and interactions already present in the game — opening the inventory to select an item, changing equipment, or reading a document. In these cases, the module has its own input and output that is then interwoven into the regular system interactions.
In the case of essentials, there is no input or output visible to the player. They are data transformations based on existing code from outside the GB system. This can be any of the AI modules, graph algorithms, or machines (though machines can also be used inline). They allow for more complex mechanical expressions within the system by drawing upon existing code within the game.
Now, knowing our tools, we can move on to using them in the following article.
Esoteric Musings... 