Blog

We’re proud to announce that Undercover Agent, the latest in our popular “Choice of Games” line of multiple-choice interactive-fiction games, is now available for Steam, iOS, and Android. It’s 25% off until February 1st!

Think fast and lie faster! When you go undercover to retrieve a deadly new bio-weapon, can you pull off the mission and escape with your life?

Undercover Agent is an interactive novel by Naomi Laeuchli. It’s entirely text-based–135,000 words, without graphics or sound effects–and fueled by the vast, unstoppable power of your imagination.

You are the top operative at the DTU (Domestic Terrorist Unit), a covert agency that specializes in investigating terrorist groups on US soil. As Silas Bishop’s administrative assistant, you are in a prime position to spy on his business and search for the deadly weapon his scientists have engineered. But word has leaked there’s a mole, and you’re running out of time.

Can you depend on your computer hacking skills to get you out of a tight spot or will you count on your brawn? Would you rather sneak where you shouldn’t be found or bluff your way in with pure charisma and charm? And what about those friends you’ve made while undercover? Can they be trusted, or would you rather just use them? Cover your tracks, delay the mole hunt, and plot your escape.

• Rescue your best friend or leave him to his fate
• Avoid detection or kill those who suspect you
• Find love with your handler or even your enemy’s son
• Frame your coworkers or protect them
• Plant bugs, hack computers, crawl through vents, and use your charms
• Bribe, torture, or threaten information from targets
• Go on the run or earn a promotion
• Expose the mole in your own agency or join forces
• Retrieve the weapon, destroy it, or sell it

We hope you enjoy playing Undercover Agent. We encourage you to tell your friends about it, and recommend the game on StumbleUpon, Facebook, Twitter, and other sites. Don’t forget: our initial download rate determines our ranking on the App Store. The more times you download in the first week, the better our games will rank.

As part of our support for the Choice of Games Contest for Interactive Novels, we will be posting an irregular series of blog posts discussing important design and writing criteria for games. We hope that these can both provide guidance for people participating in the Contest and also help people understand how we think about questions of game design and some best practices. These don’t modify the evaluation criteria for the Contest, and (except as noted) participants are not required to conform to our recommendations–but it’s probably a good idea to listen when judges tell you what they’re looking for.

If these topics interest you, be sure to sign up for our contest mailing list below! We’ll post more of our thoughts on game design leading up to the contest deadline on January 31, 2018.

In our previous series of posts on how we judge a good game for the Contest, the we wrote the following about the Prose Styling category, which represents 10% of the overall score:

Your writing should attempt to be as word-perfect as possible: that means correct spelling, grammar, and usage. While prose styling beyond those elements is subjective (How good is this writing? Does it engage me and do I want to keep reading?) we expect to see evidence that you’ve worked to submit clean copy to us.

Writing should conform to our Style Guide both in terms of text (second person games should use first person options) and punctuation (no smart quotes, correct em-dashes, etc.)

Games which are beautifully written, or that deeply engage the player with their prose, are likely to score higher in this category. Games which are boring to read, or that that contain odd, confusing, or difficult writing are likely to score lower. Games which are unintelligible, which lack proper punctuation, or that are otherwise very poorly written may receive a 0 in Prose.

To expand further on this idea, I’d like to talk a little bit about how to edit yourself, and polish your prose.

The most methodical way to edit for spelling, grammar, good usage and style is to read your prose aloud to yourself, and pore over each sentence, looking for correct punctuation and good sentence structure as you go. As you read, ask yourself whether the sentence sounds good. Does it make sense? Reading aloud will bring to light infelicities like ambiguous antecedents (“Wait, who?”), using the same word twice in succession (“Oh, I started the last paragraph with ‘suddenly’”), options written in second person rather than first (“That should be ‘I!’”), and others.

When you read aloud you can hear where commas go and where they don’t. Reading aloud, you’ll see that your semicolons are connecting two incomplete sentences rather than two separate, related ideas which are both complete sentences. Do you always start sentences with conjunctions? Do you have a lot of sentences that are fragments? There are solutions for that. (Add a clause to the previous complete sentence with a comma or an em-dash.)

While I strenuously recommend the first technique as a way to improve your prose, there is another way to polish. Do a final edit against our Style Guide by using find and replace. Sublime Text, for instance, has a very robust F+R function. Want to make sure all your ellipses are unicode and flush with text? Search for non-unicode ones. Need to find em-dashes that aren’t flush with the text? Search for “[space]–[space].” Do you use the word “realize” or “suddenly,” or the phrase “and then” to exhaustion? Find them, replace them. Is all your *page_break custom text in headline case? Just search for every *page_break. Do you always misspell certain words? If you’re not already using the Spell Check function in Sublime Text, for instance, find and replace them.

While it’s difficult to teach someone how to write prose that is engaging and beautiful, there is a lot of good advice about fiction writing. Kurt Vonnegut’s dictum that each sentence should either reveal character or advance the plot is particularly good. You can read more of his advice here.

As part of our support for the Choice of Games Contest for Interactive Novels, we will be posting an irregular series of blog posts discussing important design and writing criteria for games. We hope that these can both provide guidance for people participating in the Contest and also help people understand how we think about questions of game design and some best practices. These don’t modify the evaluation criteria for the Contest, and (except as noted) participants are not required to conform to our recommendations–but it’s probably a good idea to listen when judges tell you what they’re looking for.

If these topics interest you, be sure to sign up for our contest mailing list below! We’ll post more of our thoughts on game design leading up to the contest deadline on January 31, 2018.

In our previous blog post, we explained how to use randomtest for debugging, and included some examples, particularly with choice_randomtest. Here we’re going to continue to show how to exercise some of the more esoteric kinds of bugs, then we’re going to include a bit on how to use randomtest to balance our game.

Now, if you have any errors that quicktest or randomtest are able to catch, the tools will run until they find them, then stop and say what the error is. These errors usually say what exactly the problem is, but if you need more detailed help with one, our forum has a category dedicated to already answered questions, or you can post your own questions or problems in the same place if they haven’t already been asked.

There is, however, one relatively rare error for which randomtest won’t display an error message: when randomtest gets caught in an infinite loop. Of course, randomtest does still detect this kind of bug, but since randomtest has no way to determine what is a reasonable amount of time to spend going through a loop, it just continues to run until it is forced to stop. Debugging these kinds of problems can be difficult, but once again automated tools come in handy. Simply make sure “Show choices selected during game” is selected. In most cases you should now see a long string of the same choice(s) being made over and over again, which will tell you right about where the game gets caught in the loop. If it’s difficult to understand though, you can also recreate the playthrough by following the options made (which should reproduce the error in game). Occasionally we won’t see a loop though (and instead options will just suddenly stop), and so we can turn on “Show full text during game” to see if the loop is shown in the text.

Now that our game not only passes randomtest, but is also well on its way to being optimized, we can move on to using some of the features of randomtest for game balancing. One thing we commonly use randomtest for is to simulate a large number of playthroughs. We do this by running a number of ‘seeds’, or playthroughs of the full game made by randomly selecting options when each choice comes up. We have already mentioned line coverage a little in this guide, but now we’re going to actually look at it. To do so, all we have to do is make sure that we tick the box that says “Show line coverage statistics after test” when running the HTML version of randomtest, then, at the bottom of the output, it will display a set of lines that look something like this (This example is taken from the example game when you download ChoiceScript):

variables 10000: *set leadership 10
variables 10000: *set strength 10
variables 10000:
variables 10000: What do you prefer?
variables 10000: *choice
variables 10000: #Leadership
variables 5000: *set leadership +10
variables 5000: *goto action
variables 10000: #Strength
variables 5000: *set strength +10
variables 5000:
variables 10000: *label action
variables 10000: What will you do today?
variables 10000: *choice
variables 10000: #Run for class president
variables 5000: *if leadership > 15
variables 2506: You win the election.
variables 2506: *finish
variables 2494: You lose the election.
variables 2494: *finish
variables 10000: #Lift weights
variables 5000: *if strength > 15
variables 2506: You lift the weights.
variables 2506: *finish
variables 2494: You drop the weights and hurt yourself badly. You never recover.
variables 2494:
variables 2494: *goto_scene death

Looking at this, we see two different types of choices in a very simple form. First, we have What do you prefer?, which is an Establishing Choice (more on establishing choices can be found here), while second, we have What will you do today?, which is Testing Choice (more about types of choices can be be read here). Combined, these two choices are one of the simplest examples of how we use delayed branching. First we choose to either be strong, or we choose to be a leader, then when faced with an option about what we’re going to do, if we pick the one that properly reflects our skill set, we succeed, while if try to do something we have no skill in, we fail.

Having run randomtest, we can see how this actually plays out. Randomtest will select whether the PC specializes in Strength or Leadership, then will randomly select which skill they are going to attempt to use. This means that randomtest has about a 50/50 chance of matching the PC’s preferred skill to the test, and looking at the output, we can see that’s the case. Each of the *ifs are hit 5,000 times (out of 10,000 runs), and each of the successes are displayed a little over 2,500 times. Of course a real game is more complex than this, and once we add a few more Establishing Choices, a couple more variables, and change everything to fairmath, we’re going to lose track of what the ranges our our stats are going to be.

So here are a few rules of thumb to keep in mind. First, if a player is given X stats to choose from, a test with a 1/X success rate for that stat is usually moderately difficult. For example in the above test we had two stats, so a success rate of 1/2 is moderately difficult. If we were to add a third variable (and options) then a success rate of 1/3 would be roughly equivalent. At about double this level of difficulty (again, measuring by how many people actually succeed on the test), any player that puts in any significant effort into raising the appropriate stats should be able to succeed, while at about half of it, and a player has to very specifically raise that stat to succeed at that test.

In addition to that, there is the consideration of the actual number of successes. Any line that is hit around a 100 times in 10,000 seeds, the default number of seeds run, is very difficult. That’s 1% of random players ending up with the right choices. Any lines that are hit around 10 times in the same number of seeds, are exceedingly difficult to reach, and should only be used for are very specific situations, such as singular lines covering rare scenarios, or very rare, special goals, which should virtually always be signposted with an achievement.

Occasionally though we’ll have lines that are never hit. When that happens we have a problem, because we’re unable to confirm whether or not they are at all reachable. Sometimes this is as easy to fix as tweaking some numbers up or down (by giving higher stats to player, or by making the difficulties lower), but occasionally we might find that’s not possible. For example we might be writing a heroic fantasy, and have a scene specifically for clerics that carry swords, but found that it never fires. For this we might insert choice_randomtest into our code (remembering to remove it once we’re done testing), forcing the game to only play clerics that carry swords (of course, remembering in the process that clerics are forbidden from using swords).

There are a couple other ways in which we can use randomtest too. For example, randomtest is how we determine playthrough length. To do this, we run some seeds with the “Show full text during game” option selected, which then shows the word count near the bottom when it’s finished. For a 100,000 word game, we generally expect the average playthrough to be around 20% of the game, or 20,000 words, but as a game’s total word count gets longer, actual playthrough tends to be a smaller percent of the game, although we don’t recommend going below 10% of the total length (otherwise so much of the game is in specific playthroughs, that it will feel short regardless of the total length).

This is of course, not an exhaustive list of uses for our testing tools; we might also use various other tricks, like a series of *ifs with *comments to tell us how many people reach a certain set of code with certain stats in randomtest, or the *bug command, which is documented here, to make quicktest pass, or get more information from randomtest. Maybe you’ll even come up with your own!

Your mission: go undercover at an evil organization and retrieve a deadly new bio-weapon. But word has leaked there’s a mole, and you’re running out of time to pull off your mission and escape with your life.

You are the top operative at the DTU (Domestic Terrorist Unit), a covert agency that specializes in investigating terrorist groups on US soil. Now put in place as Silas Bishop’s administrative assistant, you are in a prime position to spy on his business and search for the deadly weapon his scientists have engineered. Undercover Agent is a 135,000 word interactive novel by Naomi Laeuchli, releasing Thursday, January 25th. I sat down with Naomi for a short interview. 

What’s your background as a writer?

Since I was six years old, I’ve been writing. I was homeschooled, and something we had to do every day for school was write for half an hour. We could write anything we wanted we just had to write. I even spent a year writing fanfiction for a virtual pet site’s newsletter (it never did get accept). Writing was my favorite part of school, and at some point I realized I was doing it for fun as well.

When I was nineteen I got my first freelance writing job and have been doing it ever since. I’ve written about dentistry, garage doors, and diamond cuts, written reviews and created personality quizzes. During my time off, I wrote a four book romantic suspense series called Holly(Woods) and posted it online in web fiction format (though I’m now releasing it through Amazon).

Currently I’m lead game reviewer for the quarterly magazine Casual Game Insider.

What were some of the challenges of writing in ChoiceScript for you?

Not being able to write it in Microsoft Word! It made proofreading a lot more difficult.

Do you read much interactive fiction? Any favorites from the COG catalogue or otherwise?

I read it both on and off COG. My favorite non-COG one is Long Live the Queen. My favorite COG books are probably A Midsummer Night’s Choice (I adore the setting) and Choice of Alexandria (again, I think the setting is quite unique and I really enjoy that about it). Though I will always have a soft spot for Choice of Zombies, which is the first one I read and how I first discovered Choice of Games. I was nineteen at the time, and I remember thinking it would be amazing to write one of these, but they’d never have me!

What are you working on next?

I’m currently writing a werewolf novel, about a group of teens in a small town who killed a werewolf when they were kids, suffered some pretty bad consequences from it, and are now beginning to suspect there’s a new wolf in town.

Short answer, Bernard Pivot-style Questionnaire:

Favorite color.

Red.

Favorite word.

Felicity.

Profession other than your own you’d like to attempt.

Flight attendant or Queen.

Profession you would never want to attempt.

Bullfighter.

James Bond or George Smiley?

James Bond.

As part of our support for the Choice of Games Contest for Interactive Novels, we will be posting an irregular series of blog posts discussing important design and writing criteria for games. We hope that these can both provide guidance for people participating in the Contest and also help people understand how we think about questions of game design and some best practices. These don’t modify the evaluation criteria for the Contest, and (except as noted) participants are not required to conform to our recommendations–but it’s probably a good idea to listen when judges tell you what they’re looking for.

If these topics interest you, be sure to sign up for our contest mailing list below! We’ll post more of our thoughts on game design leading up to the contest deadline on January 31, 2018.

Coding in ChoiceScript is relatively simple, but that does not mean it’s always easy. In addition to writing a compelling story with a number of branches and making sure that the story flows naturally no matter which choices are made, you must also add a level of game design—of tension and uncertainty—to give a sense of accomplishment to successes and of replayability in finding more. This means considerations for things such as game balance must be made. If the game is too difficult, it narrows the options available and eliminates possibilities, while if it’s too easy, second and third playthroughs can lack a sense of tension. This is why we test our games. While testing by hand can be a useful tool for shorter games, or to quickly check something, the longer a game becomes, the more tedious and less useful testing by hand is. This is of course where automated tools come in.

There are a few different versions of the testings tools included in ChoiceScript, but for our purposes the html version is the easiest to use. All you need to do to run it is open up the folder you have your copy of ChoiceScript in, and open the html version of the tool in a web browser. (Like everything related to ChoiceScript development, we recommend you use Firefox.) If you would prefer to use the command line version, instructions on running that can be found here.

Now, if you have any errors that quicktest or randomtest are able to catch, the tools will run until they find them, then stop and say what the error is. These errors usually specify what exactly the problem is, but if you need more detailed help with one, our forum has a category dedicated to coding problems, with a number of questions already answered.

Of course, sometimes we know exactly what the problem is, but because of the limits of randomtest, it’s impossible for it to make a reasonable choice. Say, for example, we want to ask a player to input a password they learned earlier in the game. This is a barebones example of what we might use:

What is the password? (Hint: It’s the name of a fish.)
*input_text answer
*if answer = “swordfish”
	*goto correct_answer
*else
	*goto wrong_answer

When we think about how randomtest would run this, we can easily see the problem. Randomtest obviously has no way of actually understanding the question! (As a quick aside for the curious, when presented with *input_text, randomtest always says “blah blah”.)

For these situations we have a special variable called choice_randomtest. This variable never has to be created or set, it simply has to be tested like any other variable, but instead of a value based on player it choice, it simply returns true when the game is run by randomtest, and false when played normally. This will let us create special code to handle situations such as the above password. Of course we can make randomtest test always pass by simply checking *if (answer = “swordfish”) or (choice_randomtest), but let’s do something a little more complex, and have randomtest know the answer only some of the time. To do that, we’ll need to create a temporary variable, randomize it, then use that to set the answer. That would look something like this:

What is the password? (Hint: It’s the name of a fish.)
*input_text answer
*if choice_randomtest
	*temp coin 0
	*rand coin 1 2
	*if coin = 1
		*set answer “swordfish”
*if answer = “swordfish”
	*goto correct_answer
*else
	*goto wrong_answer

We now see that randomtest “guesses” the answer with a coin flip, returning the correct answer half the time, and failing the other half (with “blah blah” as its guess). We can of course tweak things even more, and make this much more complex (maybe it’s a really hard puzzle and randomtest should get it one out of ten times), but this is a good indication of how choice_randomtest can be used to reflect actual game play where randomtest otherwise wouldn’t.

That brings us to another common use for choice_randomtest. Some games include complex looping choices, such as requiring a player to confirm a selection, or there is an option which gives a player extra information, but doesn’t otherwise change the game. In randomtest, these kinds of choices add time to the playthrough (making randomtest take longer to run), and playthrough word count to the total, but don’t really accomplish anything. (This is also a small part of what we mean by coding efficiency.) For example, here is a simple loop where a player has to confirm a choice. (The confirmation is in a subroutine so we can more easily see how it all works together.)

*label take_a_shortcut
Which shortcut do you take?
*choice
	#Go through the rose bushes.
		It’s filled with thorns.
		*gosub confirm
		*goto rose_path
	#Climb the wall
		It looks very high. A fall might hurt.
		*gosub confirm
		*goto wall_path
	#Wade through the river
		It is running very fast and you can be swept away.
		*gosub confirm
		*goto river_path
	#Give up on 
		*goto give_up
*label confirm
Are you certain this is the path you want to take?
*choice
	#Yes
		*return
	#No
		*goto obstacle

Looking at this, we can see that when making a choice, randomtest would normally select any given choice about 25% of the time, but when given an opt-out, that one option, the easy path, suddenly becomes a lot more common. For example, if you run this through randomtest, it will give up about 40% of the time, close to double what would happen if there weren’t a confirmation, and almost certainly a lot more than a real player would (because a real player is more likely to assess the risks and take the path where they are most likely to succeed). But with one little change we can make it possible for randomtest to not opt out.

*label confirm
Do you continue?
*choice
	#Yes
		*goto obstacle
	*if (not(choice_randomtest)) #No
		*goto take_a_shortcut

In this case, we’ll see that when randomtest makes a choice, it no longer attempts to back out. This returns our run percentage back to reasonable 25% all around. This also has a side effect of speeding up randomtest. Again, we might want to fine tune this for more specific circumstances, but the general idea remains the same.

Looking at this, we see that we can force randomtest to arbitrarily make any decision and run any code. Sometimes we might use this to test specific possibilities in a game by inserting choice_randomtest into our code (and removing it once we’re done testing). For example, say we have a spy game, and while out on mission the player only has room for one hidden tool, and must make the important choice of whether bringing along a lockpicks, a pistol, or a disguise kit, and we lock and unlock certain paths based on what’s selected. Of course we want a player to be able to succeed no matter which tool they pick, and to be certain of that we might need to test what happens with each tool. So we would lock the other ones by an *if not(choice_randomtest), then running randomtest.

Of course, this has to be done with some care, as if randomtest makes decisions a player wouldn’t (or especially one that a player couldn’t) it becomes useless and detrimental to testing. Bad information can be worse than no information at all.

Hosted Games has a new game for you to play!

Create a mortal race to worship you and grow your strength. Guide them in their daily lives and help them grow. The power you collect will grow your mind and body. Dabble in the affairs of other gods or seek to destroy them and steal their power. It’s 33% off until January 18th!

The Aether: Life as a God is a 60,000 word interactive fantasy novel by A. Reddwolf, where your choices control the story. It’s entirely text-based—without graphics or sound effects—and fueled by the vast, unstoppable power of your imagination.

• Create a custom mortal race.
• Engage in mortal affairs.
• Travel the Aether and steal power from lesser beings.
• Dabble in political affairs at The Court of Gods.
• Battle other gods in epic one one one conflicts.
• Complete unique quests and events with impactful outcomes.

A. Reddwolf developed this game using ChoiceScript, a simple programming language for writing multiple-choice interactive novels like these. Writing games with ChoiceScript is easy and fun, even for authors with no programming experience. Write your own game and Hosted Games will publish it for you, giving you a share of the revenue your game produces.

As part of our support for the Choice of Games Contest for Interactive Novels, we will be posting an irregular series of blog posts discussing important design and writing criteria for games. We hope that these can both provide guidance for people participating in the Contest and also help people understand how we think about questions of game design and some best practices. These don’t modify the evaluation criteria for the Contest, and (except as noted) participants are not required to conform to our recommendations–but it’s probably a good idea to listen when judges tell you what they’re looking for.

If these topics interest you, be sure to sign up for our contest mailing list below! We’ll post more of our thoughts on game design leading up to the contest deadline on January 31, 2018.

Last time, we discussed basic Testing Choices and their variations. Today, we move to the topic of how certain choices help determine the outcomes of the various plotlines of your game.

To refresh your memory: the ChoiceScript Machine has three steps. The first step is Establishing Choices: where the reader establishes the character’s strengths and weaknesses; the second step is Testing Choices, where the reader applies their aptitudes (Primary Variables) to challenges (tests), resulting in success or failure in pursuit of goals (Secondary Variable effects); then, in Climax Choices, the Secondary Variables are tested to return the game’s End States: was the mob successfully dismantled? Did you get fired or get a promotion? Did your marriage survive? Was your partner caught, discharged, or did he get off scot free?

Previously, Testing Choices were generally set up to have one axis of success, meaning there’s one thing that all the #options are trying to succeed at in a *choice. The next step in opening up your game is the inclusion of Objective Testing Choices, where the #options point towards different Narrative Goals. As with a Testing Choice, a PV will be tested for success, but the different #options will each affect different SVs.

So, in the case of our detective, who finally has a mole in the Mob’s outfit:

#I persuade the mole to wear a wire, overcoming his fears of being
discovered. (Tests $diplomacy. Success: ++evidence_against_mob; failure: 
mole refuses to wear the wire.)
#I browbeat the mole into wearing a wire against my partner. (Tests 
$intimidation. Success:  +evidence_against_partner; failure: the mole 
refuses to wear the wire.)
#I bribe the mole to wear the wire against the mob, even though that’s 
against the law. (-$5000, ++evidence_against_mob, -principles)
#I have couples' counseling; I ask my partner to run the op. (Tests
$partner_rel. Success: +evidence_against_mob, +family_peace; failure: 
your partner does a poor job of convincing the mole to wear the wire, 
so he doesn't.)

Here, narrative tension can be provided by the conflict between Tools and Goals. What if you want to improve things with your family, but you have a poor relationship with your partner? And what if the reader wants to get evidence against their partner, but hasn’t developed any Intimidation? There are multiple axes of choice here: the reader is choosing both how they want to try to succeed, and what they want to try to succeed at. The tension between the PC’s aptitudes and their Narrative Goals deepens the experience for the reader.

OTCs are a key part of a good Choice of Games title. The mid- and late-game should be rife with them, as they force the choose along multiple axes of success.

Finally, we have Climax Choices. Climax Choices follow the basic template of an Objective Testing Choice, but test Secondary Variables instead of Primary Variables. Climax Choices can and (generally) should have Multiple Levels.

For example, in the Internal Affairs proceedings that follow the dismantling of the mob, the PC has the opportunity to make a case for themselves.

#I make a case for my outstanding service to the force and the 
city. (Tests $career; success results in a dismissal of the charges 
and a promotion.)
#I make a case for the guilt of my partner. (Tests 
$evidence_against_partner; success results in his imprisonment, you 
get to keep your job.)
#I make a case for my effectiveness as a detective. (Tests $arrests 
and/or $drugs_in_evidence; success lets the PC keep their job)

As previously mentioned regarding the ChoiceScript Machine, Climax Choices are where we see the payoff of the reader’s actions over the course of the game. If the reader has not made any effort to ensnare her partner, for example, attempts to indict the partner should fail at this moment. Impassioned pleas (a $diplomacy check), for example, are nothing compared to evidence ($evidence_against_partner) collected over the course of the game. These Climax Choices are the mechanical crux of the game, where the narrative forks as a consequence of both the cumulative successes of the player over the course of the game and the tactical response to the choice at hand. As a result of these Climax Choices, the broad contours of the playthrough’s endings are determined.

The different degrees of success in a Climax Choice are an example of End States: if the PC tries to get her partner investigated, the evidence may be overwhelming, resulting in a criminal trial; the evidence may result in the partner being sanctioned by the department; and the accusation may fall on deaf ears. That is the End States for one plot/goal of the game. When the End States for one goal are combined with the End States for all the other goals, we can determine their position within the matrix of End States, which is what the reader perceives as their “ending.”

Such is the basis of the ChoiceScript Machine: Establishing Choice determine Primary Variables; Testing Choices test PVs to effect Secondary Variable; Climax Choices test SVs to situate the player in the matrix of End States.

I hope you’ve enjoyed this taxonomy. It explains my conceptual framework for understanding choices in games, and ChoiceScript games in particular. If you have thoughts on any types of choices I’ve overlooked, I’m curious to hear!

PostScript

The Four Point Trap is a design pitfall where a game ends up posing the same choice again over and over again. The classic example of this is “do you do the good thing or the evil thing?” Once the player has decided that they’re either good or evil, it’s unlikely that they’ll change their minds during a given playthrough. Therefore, the Four Point Trap is where the game functionally asks the same question over and over again.

In Choice of Games titles, the most frustrating instance of this is in the context of basic Testing Choices specifically, where, for example, the question is: do you solve the problem by being strong, sneaky, smart, or charming? Once you’ve established that you’re one of those four things, an author may end up repeating that basic structure in their choices again and again. After a fashion, the only choice that mattered was the one at the beginning where the reader decided between those four aptitudes. The rest of the story is just about reading comprehension.

There are many ways to mitigate the Four Point Trap. Because the 4PT mostly pertains to skill-based variables, one of the first steps is to have more skills for the PC than you will typically have #options in a choice. Thus, if most of your Testing Choices are going to have three or four #options, then the PC should have at least five skill variables. Then, at the very least, you’ll be inclined to cycle through the skills when writing #options; this means that whatever the PC is best at won’t always be available as an #option.

More importantly, though, is to introduce other axes of choice: motivation, difficulty, and objective being examples mentioned above. Motivations give, at the very least, a sense of nuance to a choice. Multi-Level and Variable-Difficulty Choices change the calculus by offering the player different levels of risk and reward. Most importantly, however, different Narrative Goals produce narrative tension by forcing the reader to choose between (hopefully mutually exclusive) objectives.

We’re proud to announce that The Cryptkeepers of Hallowford, the latest in our popular “Choice of Games” line of multiple-choice interactive-fiction games, is now available for Steam, iOS, and Android!

Sharpen your sword to save Hallowford in this sequel to The Hero of Kendrickstone! Monstrous creatures prowl beneath the streets of Hallowford. When the enigmatic Cryptkeepers Guild sends a call for adventurers, you must answer. You’ll discover secrets in the crypts that are better left hidden, and a revelation that will shake Hallowford to its very foundations.

The Cryptkeepers of Hallowford is a 360,000 word interactive fantasy novel by Paul Wang, where your choices control the story. It’s entirely text-based—without graphics or sound effects—and fueled by the vast, unstoppable power of your imagination.

Step into the role of a veteran adventurer in a high fantasy world. Sharpen your steel, prepare your spells, and practise your silver tongue. Decide who to trust and who to betray. Discover lost secrets and forbidden magic. Ally with the powerful Cryptkeepers Guild, the town watch, your fellow adventurers, or follow your own agenda. Save Hallowford, or engineer its downfall for your own gain.

• Play as male, female, or non-binary; gay or straight.
• Continue the story of your adventurer from The Hero of Kendrickstone or create a new character.
• Play as a mighty warrior, or a smooth-tongued negotiator, a powerful mage, a stealthy infiltrator, or anything in between.
• Amass ancient secrets and lost knowledge to give you an edge in and out of combat.
• Betray or befriend knights, guildmasters, and your fellow adventurers.
• Delve into the sprawling underground passages beneath the town of Hallowford.
• Be an altruistic hero, a cruel villain, or someone just looking to make a little gold.

Will you complete your quest and save the town? Or will you make enemies of the Cryptkeepers of Hallowford?

We hope you enjoy playing The Cryptkeepers of Hallowford. We encourage you to tell your friends about it, and recommend the game on StumbleUpon, Facebook, Twitter, and other sites. Don’t forget: our initial download rate determines our ranking on the App Store. The more times you download in the first week, the better our games will rank.

As part of our support for the Choice of Games Contest for Interactive Novels, we will be posting an irregular series of blog posts discussing important design and writing criteria for games. We hope that these can both provide guidance for people participating in the Contest and also help people understand how we think about questions of game design and some best practices. These don’t modify the evaluation criteria for the Contest, and (except as noted) participants are not required to conform to our recommendations–but it’s probably a good idea to listen when judges tell you what they’re looking for.

If these topics interest you, be sure to sign up for our contest mailing list below! We’ll post more of our thoughts on game design leading up to the contest deadline on January 31, 2018.

Last time, we discussed various types of establishing choices and forking choices. Today, we’re going to discuss the ChoiceScript Machine and the different types of testing choices that drive the narrative forward towards success or failure.

The ChoiceScript Machine has three steps. The first step is Establishing Choices: where the reader establishes the character’s strengths and weaknesses; the second step is Testing Choices, where the reader applies their aptitudes (Primary Variables) to challenges (tests), resulting in success or failure in pursuit of goals (Secondary Variable effects); then, in Climax Choices, the Secondary Variables are tested to return the game’s End States: was the mob successfully dismantled? Did you get fired or get a promotion? Did your marriage survive? Was your partner caught, discharged, or did he get off scot free?

At its most basic, a Testing Choice tests a stat and returns either success or failure. This usually reflects some sort of challenge: riding a horse, flying a plane, stealing a watch. However, as frequently as possible, you don’t want to record the results of individual tests (road_horse_chp_3 true/false), so instead we recommend the use of FairMath generally and Secondary Variables specifically, thereby trading fidelity for efficiency; e.g. instead of tracking every decision with booleans, we assign values to decisions and compress them into numbers. In particular, a classic Testing Choice tests a Primary Variable and affects Secondary Variables to record that success or failure.

Returning to our police procedural, the PC is trying to arrest a member of the Russian mob who’s taken refuge in a house. She has drugs which she’s likely trying to flush down the toilet.

*choice
  #I kick down the door before she can finish. (Tests $athletics)
    *if athletics > 45
      *set arrests +1
      *set police_rep %+5
      *set drugs_in_evidence +2000
      You kick down the door with one swift blow and rush inside. Within moments, 
      you have the suspect cornered. Her puts her hands up; two whole kilos of 
      blow are at her feet.
      *goto after_confrontation
    *else
      You give the door a swift kick, but it doesn’t budge. You kick it again and 
      again. Finally, your partner steps up and you kick it together. If flies open. 
      You charge inside, yelling “Police!”

      *label misdemeanor
      By the time you get to the bathroom, most of the blow has been flushed down 
      the toilet. 
      *label misdemeanor2
      *set arrests +1
      *set police_rep %-5
      *set drugs_in_evidence +200
      It’s enough to make an arrest, but it will be be pled down to a misdemeanor.
      *goto after_confrontation
  #I call out to her as a distraction while my partner sneaks around back.
    *if diplomacy > 45
      *set arrests +1
      *set police_rep %+5
      *set drugs_in_evidence +2000
      Covering the peephole with your hand, you ring the doorbell and shout “Pizza!” 
      There are noises of confusion from inside. You hear the suspect on the other 
      side of the door. “POLICE! Open up!” you shout.

      The suspect stumbles away from the door. Little does she realize that your  
      partner has already entered from the rear. A few moments later, the front door 
      opens; the suspect is cuffed, and two kilos of coke are sitting on the coffee
      table.
      *goto after_confrontation
    *else
      You ring the doorbell. “Who is it?” a voice calls out.

      “The mailman. I have a package I need you to sign for.”

      “It’s 11 o’clock!”

      “Yeah, it’s...uh...a late shift for me too.”

      Out of the corner of your eye, you see the curtain flick just a bit; she 
      caught sight of you. You start kicking at the door, but by the time you get 
      inside, it’s too late. She had enough time to flush most of the coke down 
      the toilet.
      *goto misdemeanor
  #I have my partner call out to her while I sneak around back.
    You slip around back. You find a window
    *if stealth > 45
      *set arrests +1
      *set police_rep %+5
      *set drugs_in_evidence +2000
      and open it silently. You pull yourself through. Tiptoeing through the house, 
      you find yourself looking at the back of the suspect, arguing with your partner
      through the front door. “Freeze! Police!”

      There are two kilos of coke resting on the coffee table. Score!
      *goto after_confrontation
    *else
      and start to open it, but suddenly it slips from your grasp, falling with  
      a heavy thud. After a split second, you hear your partner yelling, “Police!”

      You shatter the window with the butt of your gun, clear out the sharp edges 
      and pull yourself through.
      *goto misdemeanor

Here, there is one objective: catch the criminal before she can destroy the evidence. Success in the test means you get to her before the drugs are flushed (+arrests, +drugs_for_evidence, +police_rep). Failure could be several things, depending on how you handle failure in your game: failure could mean that the drugs are entirely flushed, and so you have no basis to arrest her (-police_rep); or maybe you still stop her from flushing the drugs but you get hurt in the process (+wounds, +arrests, +drugs_for_evidence, -police_rep). Alternately, your partner could save the day, but he thinks less of you for it (-partner_rep).

Regardless, the objective of the choice is singular, though the failures may be diverse. This is sometimes called a “Tool for the Job” choice, because it’s about the PC picking the right tool (skill/stat) to succeed at the task.

There are two easily-identified limitations to basic Testing Choices. The first is that it has only one axis of choice: how do you try to succeed? It also has only one axis of success: do you succeed at catching the criminal before the drugs are flushed or not? Which doesn’t mean that you shouldn’t use Testing Choices, but you should be aware of these flaws: basic Testing Choices can quickly lead to the dreaded Four Point Trap, Scores, and other symptoms of one-dimensional gameplay.

It is important to note that Testing Choices should have at least three non-overlapping yet equally valid ways forward. That means that if you have three #options in a choice, then two of them can’t test the same stat.

A variation on the Testing Choice is the Multi-Level—or Declined—Testing Choice: here, there are multiple tests/checks under an option.

Because the concept is simple, I’m going to apply it to one of the options from above, rather than outline a whole new choice.

Choosing any of the options from the fleeing drug-courier above, a mid-level test ($diplomacy > 50 instead of $diplomacy > 65) might result in some of the drugs being recovered, instead of them all being flushed. Or, maybe the drugs are flushed, but the middle-success means you don’t get your nose broken in the scuffle, whereas you do with a total failure (+wounds).

You’re called to testify for one of your recent arrests.

*choice
  #I need to prevaricate a bit, lest my tactics seem too cruel.
    *if diplomacy > 65
      *set police_rep %+10
      *set lieutenant_sentence “20”
      You successfully steer your testimony away from the indelicate parts. 
      The jury convicts and the judges sentences the criminal to twenty years.
      *goto after_testimony
    *elseif diplomacy > 50
      *set police_rep %-5
      *set lieutenant_sentence “5”
      You are not quite able to avoid some of the stickier parts of how you 
      brought down the defendant. The jury convicts, but the judge only sentences
      the criminal to five years.
      *goto after_testimony
    *else
      *set police_rep %-20
      *set lieutenant_sentence “none”
      Unfortunately, you trip over your own story multiple times. By the time 
      you’re finished, the defendant’s lawyer calls for a dismissal, and the judge 
      grants the motion. The defendant walks free.
      *goto after_testimony

Here, the PC’s ability to defend their actions on the witness stand produces more than two possible results for the trial.

MLTCs are great, in that they provide nuance to the game. It also helps with the Four Point Trap, because it allows players to try and use a skill that they may not be best at without being penalized for it. However, you shouldn’t go overboard with MLTCs, because they’re a degree of detail that most players won’t value because most players won’t perceive their degree of difference; more than three possibilities is probably not worth the effort except in extreme/climactic situations.

You can, of course, test other stats as well (the declination doesn’t have to be in just one stat; the first stat tested could be Stealth, and then a test in Athletics, for example). By the mid-game, you should probably start including MLTCs in your game. Trials of the Thief-Taker is a recent example of a game that uses MLTCs extensively.

In contrast to an MLTC is a Variable-Difficulty Testing Choice. Here, the preamble or the text of the option has to clearly communicate that some options are easier or harder than others.

For example, if a team of bank-robbers are holed up in a bank, and our detective is the only one available to negotiate with them.

#intimidate them into surrendering their weapons and leaving the bank. (Hard Test of $intimidation)
#convince them to let children and the pregnant leave the bank. (Tests $diplomacy)
#offer to come into the bank to negotiate face-to-face. (Easy Test of $diplomacy)
#negotiate? I'm going to study the blueprints so I can get the drop on these guys. (Test $tactics)

The key here is to clearly telegraph to the reader that one or more options are harder or easier than the others. Most bank-robbers, for example, aren’t going to cave to threats and just give up their carefully-made plans. Notably, if one test is harder (or easier) than the others, then its consequences (SV-effects) should reflect the degree of difficulty: if the PC manages to flat-out intimidate the robbers into putting down their weapons and walking out of the bank, the reputation and career effects should be much more substantive than the other #options.

A variant on this idea is the expenditure of resources option: there may be multiple options that are a test, and then a final option which is the “bribe” option, which decreases a Resource Variable but lets you overcome the obstacle/choice without a test. (This doesn’t necessarily have to be a bribe, but that’s a common manifestation of this type of option.)

A final variant is the shirk option: an option that is clearly worse than the others, but which places nothing at risk. By shirking a test, the PC receives a small penalty (likely in the form of an SV nerf), but doesn’t risk the bigger loss of a failed Testing option. Think of the old arcade fighting games, where blocking meant you still got hit and lost a little life, but not nearly as much as if you didn’t block at all, or tried to dodge and failed.

An evolution on the Testing Choice is a Motivated Testing Choice. An MTC may have fewer “actions,” but those actions are explained in the context of motivations. Thus, an MTC still only has one axis of success, but it has two axes of choice.

So, when a criminal holds a gun to the head of a hostage, but our PC has the drop on him:

#shoot to kill, because this trash doesn't deserve to live. (+bloodthirst, tests $marksmanship)
#shoot to kill, because that's what SOP declares in this situation. (+order, test $marksmanship)
#despite regulations to the contrary, I try to sneak up behind the criminal and disarm him. (-bloodthirst, -order, tests $stealth)
#alert the criminal to my presence and try to talk him down. (-bloodthirst, tests $diplomacy)

A success on any of these means the hostage is unharmed (+case_solved, +police_rep), and the criminal is either dead (+bodycount) or arrested (+arrest); a failure similarly means the hostage is dead (-police_rep) and the criminal is either dead (+bodycount) or arrested (+arrest).

See, after the personality effect, the testing and the result of the shoot options are pretty much the same, but why the PC has done it can be important, especially in the context of later actions. The presence of two axes of choice (the aptitude test and the moral/ethical/personality reasoning) makes this a much more interesting choice.

These variations and complications to Testing Choices help complicate the axes of choice within a *choice, adding more dimensions to the gameplay of individual choices. Next time, we’ll look at adding axes of success to your choices through the pursuit of multiple Narrative Goals/plotlines, which corresponds to the difference between success-and-failure in the micro (individual choices) with success-and-failure in the macro (in the game).

Sharpen your sword to save Hallowford in this sequel to The Hero of Kendrickstone! Monstrous creatures prowl beneath the streets of Hallowford. When the enigmatic Cryptkeepers Guild sends a call for adventurers, you must answer. You’ll discover secrets in the crypts that are better left hidden, and a revelation that will shake Hallowford to its very foundations. Step into the role of a veteran adventurer in a high fantasy world. Sharpen your steel, prepare your spells, and practise your silver tongue. Decide who to trust and who to betray. Discover lost secrets and forbidden magic. Ally with the powerful Cryptkeepers Guild, the town watch, your fellow adventurers, or follow your own agenda. Save Hallowford, or engineer its downfall for your own gain. Cryptkeepers of Hallowford is a 360,000 word interactive fantasy novel by Paul Wang. I sat down with Paul to talk about his latest game, which releases this Thursday, December 21st.

Cryptkeepers is the long-awaited sequel to The Hero of Kendrickstone. Tell me what drew you back to this world.

Silly question, but do you enjoy writing sequels? Was there a way in which you want Cryptkeepers to work as a standalone?

Yes and No. Sequels let me build on plots and themes I’ve already established in previous installments. I think Cryptkeepers could have worked as a standalone, but I’d have to spend a lot more time establishing characters and elements of the setting which Kendrickstone had otherwise set up. The other edge of that sword is the fact that I have to juggle the choices which players made in previous installments as well. Not only do I have to offer a reasonable range of choices and balance gameplay for those who are starting the series with Cryptkeepers, but also for those who made certain decisions or brought forward certain advantages from Kendrickstone.

I’ve always found that the first few chapters are the fastest to write, and the shortest word count-wise. However, as choices are made and consequences pile up, later chapters start ballooning in size to accommodate them all. Sequels sort of work the same way in that regard.

Needless to say, not your first rodeo here, but I’m curious if you learned anything new about design in working on Cryptkeepers with Jason Hill, your editor here at Choice of Games.

Absolutely. I try to try something new every time I start on a new title, but Cryptkeepers is very experimental in a lot of ways. For example, this is my first time trying to create truly non-linear chapters, as well as my first time heavily using *gosubs, which have definitely made my life easier.

Jason’s been a particular help on the latter, encouraging me to do more with the *gosub command than I would have normally done otherwise. Without that push and his advice on how to go about it, Cryptkeepers would probably be much clunkier and unwieldy, and it’d have certainly been harder to edit and proofread.

Fans are curious about the next phase of your Hosted Game Infinite Sea series. What’s next for you? 

With Cryptkeepers finished, I’m currently working as a writer alongside Tin Star‘s Allen Gies on Burden of Command. However, once principal writing work wraps up early next year, I’ll be starting writing work on Lords of Infinity, the third title set in the Infinite Sea.

Lords of Infinity is kind of a transitional work. Sabres of Infinity and Guns of Infinity were the first discrete arc of a planned five-part series. Lords of Infinity marks the beginning of the second of those arcs. Whereas the first two titles were focused heavily on military operations with political, philosophical, and social themes taking a back seat, Lords of Infinity focuses more on the political aspect of the world. Personal dynasty-building, economic instability, and socio-political reform take centre stage, and may prove even more dangerous than a decade of war.

Tell me a little about your work on Burden of Command. 

Burden of Command is a narrative-driven tactical RPG set during the Second World War. The player takes the role of the commanding officer of an infantry company in the 7th US Infantry Regiment, a unit with a long and distinguished war record which took it to places most portrayals of the Second World War never touch on, like the Italian Campaign and Operation Dragoon, the second allied amphibious landing in France.

Our narrative focus is on the concept of leadership, and the titular “Burden of Command.” Junior infantry officers have to build the trust and respect of their men, look after their well-being, get to know them, and then send them into danger or death for reasons they might not even fully understand or agree with. The characters under the player’s command each have their own personalities, backgrounds and story arcs, but they are also individual pieces on a battlefield where death is often random, violent, and sudden. One bad decision (or even one good decision) on the field might cut short a character’s story for good, and it’s up to the player to decide how they and their unit deal with those sorts of conditions.

My job as a writer is to breathe life into those characters, and to flesh out the world and events which surround them. The last thing we want is for the player to start letting their men die simply because they don’t care about any of them, so my primary duty is to make sure all of those pieces on the combat map represent empathetic, relatable individuals whose deaths would offer the same emotional gut-punch to the player that they would to the player character. Not only does that mean writing dynamic, fleshed-out characters, but also placing them and their actions in the context of the world around them through meticulous research and a careful management of narrative tone.

It’s a project which isn’t really like anything I’ve ever seen before (though I’ve described it as “Fire Emblem meets Band of Brothers” once or twice) and I’m really excited to be working on it.

Short answer, Bernard Pivot-style: