States, Saves, and Simplifying Testing

May 7, 2021

This month I take a timeout from releasing screenshots for Sleuthounds: Cruise to go into some of the tech behind the game. As the ongoing development time should show, Cruise is a bigger more complex game than anything I’ve done before. This presents certain challenges in its creation, especially as pertains to testing. Fortunately, a recent addition to the game engine, based on existing tech, has greatly simplified the process, helping to speed up development as a result.

One of the fundamental building blocks in Sleuthhounds: Cruise, as with all the previous Sleuthhounds games, is the state variable. In general, a variable is anything that can change or be changed. In computers a variable is any bit of data that a computer program can manipulate. Basically, anything that can be altered in a game, however small, has at least one variable backing it up. Take a simple door, for example. While there’s a bunch of information that could be tracked about that door, one characteristic that it has that can vary is whether it’s open or not. A door may start off closed, but when it’s interacted with the variable representing the closed state can change to be open.

The values for all of the different variables in a game at any given time represent that game’s state. The current state the game is in controls what it is and isn’t possible for a player to do. For example, if the game is in a state where a guard is on duty, the Sleuthhounds will be unable to access the door he’s guarding until the player finds a way to change the game’s state to get rid of the guard. Ordinarily, this changing of state occurs through the natural flow of the game itself. Players do one action after another, changing the variables and ultimately the game state, to make progress.

Now, while it’s all well and good for players to change the variables as they go along in a playthrough, for development of the game it’s a bit inconvenient. If I need to work on or test something that happens late in the game that is in some way influenced by the changing of a variable from early on, I don’t want to have to replay the entire game to get to the point I want to test. Take for instance, the character of the Colonel. He has an ongoing character arc involving playing a board game throughout nearly the entire story. Based on what the player does at various points, the final outcome of this arc has several different endings. It would be very time consuming having to replay the entire game to develop and test each one. Far better if those variables could be quickly and easily altered directly.

The Sleuthhounds games have had a general state variable structure built into them right from the start with The Unlocked Room. Having a specific module within the game engine dedicated to storing and manipulating state variables greatly simplifies development and makes it very easy to provide such necessities as allowing players to save at any time during the game. So all of that state variable data already exists behind the scenes, I just needed a way to access it more directly than playing through the game in its entirety.

The State Variable Editor gives immediate access to all the variables making up the state of the game.

Enter the admittedly unoriginally named State Variable Editor. This is a special window that I can open at any time while working on the game to see what the current settings of all of the state variables. More importantly, it lets me change any of those variables. Variables represent everything, from what doors are unlocked, to what items the player has picked up, to what options they’ve said to characters throughout the game play. Now instead of spending potentially hours to get to the point of being able to test the effect of a variable being changed, I can pop open the State Variable Editor and change it right away.

The State Variable Editor is pretty bare bones, but what it provides is quite useful. State variables are listed alphabetically by name, making it easy to find any given one. The intrinsic type of each variable is then shown. The type of variable indicates the kind of data that it’s supposed to hold. For example, an integer variable is intended for holding numbers, a string variable is intended for holding a string of text, and a Boolean variable (named for some historical guy, obviously) is intended for holding variables that can be true of false. One feature my game engine has is the ability to convert back and forth between any of the variable types, which is why each variable is shown with all three representations in the window.

Now, there are several drawbacks to having the power to change any variable at any time. Primarily these all stem from the State Variable Editor not knowing the context within which a variable is used. To the editor, these are just things that can change. There’s nothing to limit how they can change. There’s nothing to stop the state variable for a door going immediately from the door being locked to the door swinging open. This, in fact, is what I want to be able to do for my testing. However, if you consider the state of the door as being represented by three values such as 1 being locked, 2 being unlocked, and 3 being open then what would it mean if I accidentally changed this variable to a 4? The State Variable Editor makes it just as quick and easy to put the game into a bad state as a good one.

Even if the game isn’t put into a bad state, per se, it’s also possible to put the game into a state that isn’t actually achievable while playing the game itself. If I forget to script that a door can be unlocked through normal game play, there’s nothing to stop me during development changing that door to be unlocked with the State Variable Editor. So, when I go in to change a variable with the State Variable Editor it’s with the underlying assumptions that (a) I’m changing the variable to a valid value and (b) that the value itself can be set at some point while playing the game normally.

While the State Variable Editor does allow me to push the game into a state that’s not actually valid through normal game play, the benefits of significantly reducing the time needed to develop and test the game far outweigh the potential risks. And to be sure, the State Variable Editor will not be the only thing I’ll be using to test the game for final release. I will be doing full playthroughs to verify that everything works as expected. And lest there be anyone out there thinking they can just use the State Variable Editor to quickly skip through the game when it finally releases, let me just say you’ll find such attempts thwarted. The State Variable Editor is setup in such a way that it’s only included in the game during development builds. The final released version of Cruise will not have the State Variable Editor available.

Previous:   |   Next: