That's right, we are tracking a whole bunch of data for OUR convenience. It is meta data relating to... wait for it... our video game.
Of course, we're not tracking you. Don't worry about that. Our website does not have any cookies, so you need not worry.
What we are tracking are variables briefly discussed in our previous article, which is required if we are to find out what values to use in any given condition in any part of the game. To do this, we have the following tracker interface:
These values are taken from two different states. The first is the state for the Best Outcome and the next is for the Worst Outcome. They look the same above, and that's because we haven't actually implemented our Simulation Engine yet. However, eventually we will be able to simulate up to our currently opened conversation, and simulate two different possibilities: Best and Worst Outcome.
This is not a custom interface as was previously discussed. The idea behind the custom drawn method was to allow for breakpoints and locking variables so they don't change between states. The checkboxes above will instead act as breakpoints, and there now no longer needs to be a locking mechanism, as the original idea seemed over-the-top for our needs.
Our variables change depending on the scripts executed based on Best and Worst outcomes.
Take the following example:
Here, we have three options that have three separate priorities. The highest is 7, meaning that is the best option to pick, while the choice given the priority level of 3 is the worst option.
Based on this, our Simulation Engine can determine the lowest and highest values, and execute each script and change the two states accordingly.
Once all the scripts have been combined together and executed, we get two final states that are then fed into our tracker, which we can then use to determine the best values when scripting our current conversation.
However, that is not all.
For the Simulation Engine to know how to get to our currently open conversation, we need to tell it the order the story effectively appears in as if we were playing the game.
Here, we can add and remove files that exist in our "Chapters" directory and reorder our main story. We can also do the same for conversations relating to our Journals. This data, aside from the Main Story, is primarily for the benefit of the Simulation Engine and will not be used in-game. Some or all parts of the Main Story order shown in the upper portion of the interface may be used for the benefit of in-game progress, but this has not been decided yet.
Each Journal has an option for "After Main Story Part". Here, we are telling the Simulation Engine that once we reach this conversation and executed it, we should execute all scripts that are a part of this Journal entry, up to and including the currently open conversation if our open conversation happens to be part of this journal entry.
The option "Include Journals in Simulation" will help to determine what options should be available to the player. Now we have an important distinguishing feature that needs to be taken into account when determining conditions.
Not every player may necessarily complete optional Journal entries. Despite the video game when released with its Introduction demo involving mostly optional Journal entries, Chapters 2-4 will constitute primarily Main Story Journals and choices in conversation will need to take into account both options.
Of course, what we also need to ensure is that we only allow the Simulation Engine to pick choices that will indeed be available to the player, which means executing each choice condition and seeing if that choice will appear to the player. Once we do that, we only execute the choice with either the highest or lowest priority level depending on conditions applied to those choices respectively.
What this also provides is a way to check if conditions on choices are reasonable, or no choices are available at all. A way to record this would be advantageous, to understand how the game will progress in the hands of a player who does not know which choices are best.
The Next Move
We are getting to the point in the project when progress is slowing down. This is primarily due to the fact that problems in programming are becoming harder to solve. This is the equivalent of a debugger after all, and making such things are not as easy as one would think.
However, what this does mean is that more effort can be put into other projects planned to help both with the video game as well as other types of projects, like websites.
What we plan to design and develop alongside StoryDev I'm sure will shock you, but time management is key to success, is it not?