Why don’t authors include a cheat menu?


My WIP already has a cheat menu, one I put in for developing purposes as I was going through. You might think “Well then, you’re all set, just leave that in and you’re good to go” but there are a few problems with that:

First: It’s awful. Like I said, it’s for development purposes so it’s just one big *choice with options like “set flags” that make no sense to anyone who isn’t me.

Second: It’s for me. This is different for the first point because it’s not just that the UI was made to be understood by me, but the cheats only do what I need them to do. Namely:

Set flags: My game has a number of one-off flags for things of the form “did you make X choice because I want to reference it later if so.” The ‘set flags’ choice turns them all to true so I can make sure the special-case code is working. Many of these flags are mutually exclusive, so for a non-developer playing through they’re guaranteed to see things referring to events that never happened.

Randomize Stats: I don’t have a choice to max out stats. I need to make sure my failure paths are working as well as the success paths, so I have a choice to randomize them, so I can be good at some things and bad at others. Also, this option often puts stats at points unachievable through normal gameplay, and has no consistency whatsoever.

Jump to File: Of course non-developers have no idea what my files mean, they’re named significantly for me :). And jumping ahead (or back!) is a sure way to make the narrative go completely off the rails.

So it’s not just an issue of an author having to do extra effort to make a cheat system. For someone like me, it’d be an issue of juggling two cheat systems: One for me and a completely separate one for the player.


For the most part people will just want to view the scene files and make choices based on the code as they go though. That would require having the Steam or Chrome versions however. Mobile is the wrong platform for doing so.

I don’t really think special consideration needs to be made to add a cheat menu, just don’t obfuscate code or try and force players to adhere to a vision of “this is the only way to play my game”.


In retrospect, I wish I had included a cheat menu for several of my games, largely for the playtesters:

There was an error hidden deep in Chapter 9 of Tin Star. It involved the fight on the train and the PC cornering the villain in the locomotive’s engineering space. The problem didn’t show up in testing or playtesting, but it was there. When an error report was sent my way, I fixed it in less than an hour, but the poor player who had triggered it had to play Tin Star all the way through again. That is assuming they picked it up again.

There was a similar bug in the Shadow Horror that involved stepping into the attic at midnight. Single error report, easy fix, but totally avoidable.

For especially long games, I would like to give playtesters the tools to jump ahead, to test out different combinations of stats, or even try different romances without having to restart an effort completely. Whether I would leave that in for regular players is debatable. Certainly a disclaimer “Using this may break your game” seems advisable.

How to present it would be another question. Putting it out front feels like it would break immersion. Keeping it too well hidden defeats the purpose.


I believe part of the problem is ChoiceScripts deliberate prevention of being able to save state and go back. It would be beneficial if this “you can only go forward” design was revised. Twine alows for bouncing around backwards and forwards, as do many visual novels. Even with the old paperback gamebooks you just went back a few pages and carried on.


I really wouldn’t have thought of it if I hadn’t read this thread, but I believe Choice of Magics is going to have an option to cheat the next time around if you die. If the cheating option is selected on death, it will bump all the stat-checking stats by enough to solve most deadly problems, but disable achievements. (And send you back to the beginning of the chapter, but that was already implemented and can happen even if you don’t cheat.)

This took about an hour to implement, mostly adding annoying checks before every single *achieve to see whether we were currently cheating or not. The actual go-back-to-the-beginning-of-the-chapter functionality (with restoring autosaved stats) was already there with a couple short *scripts.

I think the hard thing about cheats in ChoiceScript and choice games is exactly where to put them. I like offering the cheat option only upon player death because it means the player at least tried to engage with the game on its own terms once. If the player’s cheating, it’s because they already gave not cheating a pretty good shot. It also means the player needs to be fairly well into the game, and have a particular build they’re dealing with, before beginning to cheat, so they can’t immediately push over all the facades and destroy all the illusions and rend all the curtains.

As a creator, my main concern about cheating would be that the player would lose interest in the game more quickly after cheating - if there’s no challenge, or if certain sleights of hand were made more obvious. But, for this particular game, it’s relatively rare to die, and by the time it’s possible, I think I’d like to allow the player to force a way to an ending. So cheating – sure.


Why no put an “unlock this cheat mode after you beat the game once”?


There are two challenges I see to implementing cheat modes in CoG games: the programming overhead of adding the tests, and the question of how to handle larger branching storylines.

Despite the difficulty, it might still be worth doing. Choicescript programmers go to all kinds of trouble to ensure games will be more enjoyable. The question for me would be how many readers want it, and how much more enjoyment it’d add for them.

The problem is not that this is hard to write. The problem is the number of lines that have to be changed and the potential for human error.

In many programming languages, stat checking would be handled by a function that might look a little like this.

function statCheck (value, target) {
  /* An imaginary function in an imaginary language */
  return true if (IgnoreStats);
  return true if (value > target);
  return false;

Whenever a stat needed to be checked, the code would call statCheck.

We could modify statCheck to look at an ignoreStats variable.

function statCheck (value, target) {
  /* An imaginary function in an imaginary language */
  return true if (ignoreStats);
  return true if (value > target);
  return false;

And by making one change to one function, we’ve now made every single stat test in the game work the same way.

It’s difficult to do something similar in Choicescript - difficult, not impossible - and would be a great deal of work to add it to an existing game.

So that approach makes sense for simple stat tests. What about other game branching?

Consider a game where the player is backing one of three aspirants to the throne. In cheat mode, do you let them choose which one they get? Do you show all three outcomes? If there are choices where you’d see different options based on who ended up on the throne, do you show all the possible options, even when they’re contradictory? You could do any of those things, but it will make the coding noticeably more complex.

Again, none of that means you can’t or shouldn’t provide a cheat menu that lets players get the outcome they want. But it probably needs to be more complex than turning on all the alternate text.


Enabling cheats after finishing the game once would definitely be one way to add longevity to a game that might otherwise only be played once. But, the thing I happen to be highlighting with Choice of Magics is a lot of replayability and different endings, and I think it’d be a better experience most of the time to just play the game again without cheats, since you’d have more suspense, achievements to unlock, and so on. Presenting the option to cheat on finishing would be one of those situations where choice A looks more fun but choice B actually is more fun. --Especially since putting it after finishing the game might make it look like a “prize” that makes it more exciting to try out.

This conversation now makes me want to add a “deluded” mode, unlocked on finishing, where your stats never increase from their starting values. I think this would be entertaining – after all, you can fail your way through pretty much the whole game since it follows the CoG design guidelines. But even there, it’s probably actually more fun to play the game the normal way (getting stat bumps being inherently pleasant), and it looks too enticing if presented as a reward for finishing. So I probably won’t do that either.


A fascinating challenge. :smiley:
I think the difficulty of implementing both can be significantly reduced with prudent design.

For the numerical stat checks…
If I may borrow your drifter example…

*if drifter >= 50

We can say that the above is the base check. Obviously, the stat called “drifter” has to be at or above 50.
Now for the cheat menu…

For the purposes of this, we’re going to assume that turning on cheats gives you +20 to all stats.
I think you can do this in many different ways. Perhaps a *gosub can be used…
Ok, here’s an example that should work if you copy and paste the code below into a startup.txt:

*temp checkstat ""
*temp checkstat2 ""
*temp drifterbase 30
*temp drifter 0
*temp cheatmenu 0

*label main
*set checkstat "drifter"
*set checkstat2 "drifterbase"
*gosub cheatcheck
Let's test the "drifter" stat.
Turning on cheats will increase all stats by 20.

[i](Note: there are actually two stats here. We will check "drifter" but there is actually a hidden "drifterbase" stat as well. "drifterbase" holds our base value, whereas "drifter" holds our final value.)[/i]

--> It's currently at ${drifter} and needs to be at least 50.

 *if cheatmenu = 0
  #Turn On Cheats (currently off)
   *set cheatmenu 1
   *goto main
 *if cheatmenu = 1
  #Turn Off Cheats (currently on)
   *set cheatmenu 0
   *goto main
 *selectable_if (drifter < 50) #Drifter is below 50.
 *selectable_if (drifter >= 50) #Drifter is at or above 50.

*label cheatcheck
*if cheatmenu = 1
 *set {checkstat} ({checkstat2} +20)
 *set {checkstat} ({checkstat2} +0)


Good point.

My argument of adding cheats would be “you can skip-sequence in old cyoa books by flipping the page” :confused:
But you’re right about having a better experience without cheat-mode.

Ah, I’m so broke about this :broken_heart:


Ehh. Depends on the game. I might really enjoy a game but sometimes I have absolutely no wish to replay it and feel like I am still going down the same path. (Despite choosing completely opposite stuff). Though I agree that disabling achievements with the cheats is a good idea.


This is a good job for the new Choicescript *params feature. And if you’re scrupulous about naming all your stats - drifter and drifterbase, parkour and parkourbase, et cetera - you can generalize this a bit more.

Now, instead of setting two variables every time, you call your subroutine as

*gosub drifter

(or whatever variable you want to adjust).

That said, I think this approach still leaves other problems to solve. For example, if you increase the drifter skill later in the game, you’ll need to increase both drifter and drifterbase - otherwise turning off cheats will erase the improvements by resetting the value back to the base.


Well, I intended it so that when you increase the drifter skill, you would actually be increasing the “drifterbase” skill, so that it shouldn’t matter if drifterbase increases or not because the code adds 20 to whatever drifterbase is (assuming the cheat is on), and comes up with “drifter” which is the stat that is actually tested.


Another alternative to a cheat menu could be new game plus codes like I did in UnNatural.

That was simple enough to code and had basic stat boosts to various stats.


There is no need for it, just do it yourself, (they’ll probably most likely put a price tag on it anyway) its a pretty simple code. But there are some games that ‘combat’ cheating (well… try to anyway) that could appear to be hard for some to work with but if you invest 30min or less (maybe more depending on the knowledge you have on the type of code being used) to study the structure of the code being used and how its being used you would be able to change the whole game in your favour.

(To experience the full feeling of playing a CoG or HG Game, i recommend not cheating but if you brought it, it doesn’t really matter, both sides would get what they want)


Well I’m all in for cheats as I believe it adds more choice to the games (it’s sorry I had to)

Also it doesn’t lead to blowing up/malware infesting my computer trying to unpack a file, plus modding isn’t even available to phone readers

And if the reader gets bored from the lack of difficulty then they can just turn back to normal mode, win for everybody really


Cheating is just a preference really, whether or not they break immersion is entirely dependant on who it is that plays the game.
If there are no cheat codes available to a game then you can always either just mod it or look on walkthroughs online that detail everything about the game, so it’s just a matter of convenience for people who are going to cheat in your game any way.

But why don’t authors include a cheat menu?
I think people have already pointed out the biggest reasons, hassle with coding and additional work, or having a different opinion on how games should be played.
People like us who enjoy cheating and who do it fairly regularly are likely in a minority, and as such I wouldn’t expect game designers and authors to pay us as much attention and consideration.


You need to talk to @Vendetta then, cause I remember from his playtest that he developed a save system that let the testers rapidly try out different scenes and different characters/backgrounds. Enhance that with a stat and perhaps flag setting menu and you’d be golden.
Know you and Cata are currently busy with “Burden of Command” though but I do hope you’ll return to making more choice games sometime in the future too.

I’d rather have a real save system then a back button though because in a long game like TinStar was not having a true save system but just a back button would mean that in the last parts of the game I’d still be an awful lock of clicks away if I wanted to do something different near the very middle of the story.
As a bonus it would allow me to play through a scene I really like, such as say the apartment party in ME3 a couple of times without having to restart the game every single time or just resort to reading the code.

Again wouldn’t starting with a simple save feature be better, as it would also help me with long games, again I’ll use Tin Star as an example here that I don’t have time to play through in one go on a normal day and having a true save feature would allow me to return to the point i left and would allow me to either retain my browser privacy settings on the old Chrome apps/possible new CoG omnibus app or protect me from Steam’s unprompted updates that can make the game forget my progress too and those things happen fairly frequently.


It is if the phone is rooted and/or you have the right app to edit the code.


It’s more of a pain but definitely possible.

I wish we had more stuff like that, I mean for many the stats screen can be immersion breaking so why not go a step forward? Plus if there’s chapter select on top of stat increases it really helps testers or people playing normally who ran into a error or just regular cheater reasons.