If IDEs (Integrated Development Environments) have debuggers, the ability to track variables and check performance, why shouldn't we do it?

Only StoryDev is not going to be a fully fledged IDE. It's not going to be as complicated as Visual Studio, for example. Simulations, as it is called here, is the method of comparing one or more "States" to determine how variables change from point A to point B. This is designed to help with identifying which functions to use and what conditional variables would be best in any given situation, no matter what conversation we have open.

We will use a variety of tools to help with that.

Simulation Tools

Here, we have a Play/Stop and Record button. The Play button will start the simulation engine, and will simulate up to the currently open conversation, changing the state as it goes. The state will eventually be trackable, meaning we will start to see the variables themselves as they change, including the full call-stack.

Our Record button, when toggled on, will record every state change. Once this is toggled back off, the state changes will be saved to a local file. This file can then be used to re-simulate part of the same conversation when we click on another branch and change the route up to that point.

That is complicated, and will likely take a long time to complete. But it will save huge amounts of time in the long run, as most of the actual game testing can be reduced down to simply making sure the game itself works.

We also have an option to change the template. Templates are all the variables we wish to track. It may not be all of them, but the Standard template seen above will track all known variables by default.

We can also track Best and Worst outcomes. Do you remember our discussion on Priorities? This is where it comes in.

Here, our simulation engine will make two separate simulations. When we press Play, we have two states going in one direction or the other. Best Outcome variables will change based on choices that have a Priority level greater than 7, and Worst Outcome will choose the lowest Priority level that exists, but ensuring it falls below or around 3.

We have two more options here:

  • Auto-Track States – When playing, automatically start tracking state changes across all conversations. This means more detailed information will be available during the entire simulation, which includes the call-stack. Turning this off means less data, thus greater performance.
  • Auto-Compare – Based on the latest saved state, automatically compare state changes while playing. In other words, all of the state changes made in the saved file will be compared with the new simulation run from the point the recording was made.

To help manage some of the simulation tools available to us, we have some options we can change.

Our Simulation tools window as above can be opened automatically when we open our Conversation Editor, which is just a nice option to have. We also have here the ability to "Re-simulate on every file open". This would work while currently playing a simulation, and this would be useful if we want to save states and compare when we do open a new file, otherwise playing and recording will stop when we open a new file.

Obviously checking this option will drastically affect performance.

We can also change the default Best and Worst Outcome priority levels, as well as the folder where States are saved.

States are saved in a custom format, using the template name as part of the file name. "STANDARD_2021_05_16_12_12_24" as an example.

Here is where we can enable state recording, which basically enables the "Record" button inside our Simulation Tools. We also have the ability to create and modify templates. Our Recording Details provides access to every trackable variable.

Checking a variable means we want to tell our simulation engine to track that variable. Anything unchecked will be ignored. You must check the parent of a child otherwise that will be ignored also.

We also have the option to "Save State per Change". If we uncheck this, recording the state will only save the current state once we stop recording, rather than saving all changes to the state.

Conclusion

We have the basics of the simulation system in place but we are nowhere near finished. Our next step is designing and putting together variable tracking. This will be custom drawn, and a certain degree of reflection will be involved to track variable changes. We can't do this until we also implement a scripting engine, which will likely take the form of a JavaScript interpreter for C# as that is the closest to Haxe Script without needing to use Haxe Script.

Stick around to find out more about variable tracking. It will likely be a design more than anything initially. A video will be more appropriate to demonstrate the simulation engine once complete, but this will come much later. Until next time.

Developer at home, customer services at work. In my free-time, I enjoy writing and coding.