Planning (The Sea Eternal)

Note: This post deals with my game The Sea Eternal. As such, it will contain spoilers.   

Planning was a huge part of getting ready for working in ChoiceScript. Because writing in ChoiceScript is just using a text editor, I find that lack of structure can lead to programming issues if I just jump right in.

So I planned the whole game out using Twine first. Here's a screenshot of a very early iteration of the game. You'll see that it's not a functional game, since there aren't really any links between boxes. But it's a representation. It's kind of an outline or even... pseudocode. Documenting a choice game with a flow chart allows the game to be represented like the actual game it's going to be. Thorough documentation like this really helps frame the game: where is everything going, how, and why?

As the game progressed, different aspects of the game spoke more to me in different ways, so I changed, updated and refined the overview document. I also got a lot more granular, breaking scenes up into different areas of focus.

Here's what a typical scene looked like close up:

Using a flowchart to document scenes was especially important for keeping more complicated material organized. For instance, the memory of the squid-whale battle offered the player multiple opportunities to change their focus, to move from one group to another. That all needed annotations to make sure that the different paths would split and merge without repeating or omitting information. You can see the visualization of the squid attack in this huge block of content. It looks like a huge lot of writing (and it was!) but those divisions are actually just much finer than the rest of the blocks, with extra continuity details.

Using Twine to plan and document game content also allowed me to predict how much attention a section of the game would need before it could feel complete. Most blocks represented between 3 to 5 choices. This made keeping track of game progress divisible into neat chunks that could then be used to track progress.

Most important to me, using Twine to track story pieces helped wrangle large chunks of content. Big splits that merge again can be difficult to keep track of. Twine was helpful for keeping the endings straight, but even things like larger conversations that could go in multiple directions, it was useful to be able to track everything. Having a Twine copy of the game allowed me to comment on the code without embedding those comments deep in the game where they might not have as many contextual clues.

For instance, here's my character bible and lore notes. They help me keep characters, settings, and the general mythology consistent.

The final benefit to using tracking my gameplay in Twine actually came out around testing time. Since there were several ways to reach different paths based on stats, I wanted to check that every path actually made sense and that every ending was reachable in some way, at least. I wanted to make sure, for instance, that the player would never encounter a choice that required both a high Bold and a high Patience. I actually ended up fleshing out the ending paths and tested and tweaked using that outline.