Creating a CYOA Game (Creatures)

Note: This post deals with my game Creatures Such as We. As such, it will contain spoilers.

Making a full-sized CYOA (in Choicescript) was daunting: it was a lot of writing, and it was difficult to QA and course correct. It ended up eating more time than expected in some areas, although it gave a lot of unexpected leeway in others.

Research

I did a lot of research and reading about space and gaming to try and convert them into an interesting game. I dedicated time and some small funds to research, and it paid off with a realistic setting, and I feel like having a realistic setting is what allows people to really connect with and understand the characters. I've actually talked more about my research and inspirations on a separate blog post.

Planning

I assigned myself deadlines for major development milestones, which made it really easy to figure out my progress and stick to a schedule. Planning (including research, game design and character development) got a full two months. Choicescript isn't the most visually easy-to-follow tool to work with, so I storyboarded the whole game in Twine first. It may have been a bit overkill, but for me visually seeing the connections helped me realize which parts would need more writing attention (the philosophical conversations), plan workable deadlines, and get a sense of progress for those deadlines. It also helped having a rough sketch of different plot flows with large markers that helped keep track of affection gain/loss points.

Storyboarding was also helpful because I ended up cutting some scenes from the Twine storyboard to help maintain a workable game scope, and to keep the plot focused on what was actually important. Cutting those scene after they had been committed to ChoiceScript would have been frustrating and annoying and, in many cases, extremely difficult to do. There definitely would have been a much stronger tendency towards just letting things fly

Writing

The writing ended up being a monster. Almost the majority of the game is just text text and more text, so all of it has to be thoroughly copy-edited, and it has to be consistent from one paragraph to the next, and it has to flow well. Most of the bugs in Creatures actually came from changing some little descriptive detail, and then failing to track down all the multiple spots that referenced that one detail. Then of course, there were a few repetition-of-information bugs. I had to come up with an informal system of deciding how to prevent multiple instances of the same phrasing in a multi-branching conversation.

Programming

The programming was a bit of a mixed bag. I've only really taken one formal programming class, so it kind of took me awhile to get used to some of the basic techniques of good GOTO or subroutine command use. On the other hand, good GOTO techniques is really most of what you need, so once I figured that out, things went pretty smoothly. I fell into a good rhythm after maybe 2 or 3 weeks. There were a lot of difference things specific to Choicescript that I liked / didn't like, and I've documented those on the separate Choicescript blog.

Testing

Quality assurance for this game was a whole lot different from any kind of QA I've done before. There were a few programming bugs, but those actually didn't take that much effort to weed out. (Choicescript has really fantastic automated testing that picks up on those immediately.) I did end up needing to refactor the affection system due to one really bad bug, but even something as major as that only took a day or two to fix.

The majority of the QA time went into copy-editing and rewrites. I ended up printing out the raw game files (twice!) to deal with copy-editing just because of the sheer volume of text. I tried to minimize rewrites (with all that planning) because rewrites were so painful, but it was still an inevitability. Dealing with tester feedback might mean adding a few thousand words to the game. Cutting out a nonsensical subplot (about a poisoner) was a nightmare: it took nearly two months before I finally axed the last reference to that. Even something simple(ish) like renaming a character with Ctrl-F Replace was pretty tough: I had old names popping up in weird and unexpected places.

The most tedious was dealing with repetition from bad flow, because there's no way to test it expect to brute force it. For example, I'd run into paths where maybe Ren would pour her syrup and then potentially do it again. It took a lot of work to sort out those kinds of problems, but I ended up making a depth-code system for maintaining consistency.

And while the re-writing was a lot of work, it ended up being pretty much the entire QA process. Once that was sorted out, there's little else left that can go wrong with the game. That extra time was really nice because it meant I had a lot more leeway to focus on detailed tester input and figure out how to correct mistakes or poor writing or re-writes to fix poor choices.

The Whole Process

I feel like I've gotten the game development process down to a procedure:

• Do research and let the setting inspire the story
• Visually chart out the plot flow first
• Assign deadlines to chunks of content based on the visual chart
• As real work begins, compare actual progress to plan and adjust deadlines or re-scope as needed
• Try to keep things always moving down, never GOTO something up
• Test scenes as you write them (with use of testing goto_scene commands)
• Do separate testing passes for stat tracking vs. writing issues
• Print out files for proofreading (and read them aloud, if you can)
• Stagger out beta testers, if you can
• Plan for breaks where you take your focus off the game and then return