How difficult is choicescript to duplicate?

I’ve done some studying and it seems platform wise, choicescript is one of the best. But they have limited competition and amongst other things, not innovating and offer miserly revenue share. I mean their friggin website looks like it’s from 2007.

I got some ideas and some money to risk.

Would choicescript be difficult to duplicate? It involves its own language. I know how to program but took a bootcamp 7 years ago. I’d need to relearn everything.



I’d never underestimate the challenge of programming up your own version of something else. But the language is just one element of the whole enchilada. Choicescript has communities, keen and good authors, a cultivated popular house style, etc. All that is a great challenge to cultivate.

A ton of folks come through the forum with new systems. Most never produce one story with them, and maybe the one story is average or below average, and nobody makes a second one. A ton of stuff has to be good or great to even get the ball rolling.



It might be worth your time to look at the other competitors in the choice space (many of whom have died along the way).

The success of CoG is more in the quality mark (house style, length and branching expectations, editing and testing) than the actual engine (though that’s of course a necessary part of it). The UI could be a lot more attractive, of course. HTML radio buttons are long out of vogue. But the core experience— the writing— has a decent minimum floor.

It’s like how is still ticking along despite barely updating the site design in the last 25 years and yet four stories and hour are published on it. If the content is good, people will keep coming.


Let me double-down on this advice. I’ve built (and documented) a pretty cool system. but the reality is that, after 2 years, I only have several games in bits (admittedly part of that is chasing a moving target, but the point still stands) and — frankly — it’s struggle to get anyone interested in what I am doing.

For me that’s… okay. I built it for me first & foremost and I got a lot of joy from the creating. However, now that it’s more or less finished I do find it frustrating. Partly because I find myself wondering what cool things other people might do with it, but I will confess to craving some validation also!

I’d say coding up an alternative is the easy part of the problem. The bigger challenge is marketing a new solution in the face of many good, established, alternatives. Being better, alone, isn’t enough.


I’d just like to point out that you’re unlikely to find platforms with better royalties and similar benefits. Choice of Games is more generous than most book publishers, does the actual work of publishing and pushing updates for your game and brings a wide audience to your game and that’s hard to ignore.

I had a large game I published recently I thought of putting on Steam, but I’d need some art assets for it and marketing. I actually thought of approaching some people with pre existing storefronts (like Simon Christiansen) and offering a 90/10 revenue split (with me getting the 10%) just so they’d do all the work for me, and that would be worth it for me. The 25% from Choice of Games is really nice.


Ink is an open-source (MIT licensed) competitor to ChoiceScript, which you can use for whatever you want with no royalties. So on the programming language front, that’s a good starting point. In my (limited) experience it can do everything ChoiceScript can, and if you export for the web, its default presentation is much more aesthetic (with no radio buttons!).

…but, I get the sense you’re not asking about ChoiceScript but about Choice of Games. If you make a game with Ink, you won’t find a big company that’s already set up to handle all the logistics of hosting and publishing and selling your game.

There are competitors out there— and Steam are both designed to make it relatively straightforward to sell indie games—but the amount of marketing and publishing work you’ll need to do yourself is far greater than working through Choice of Games. You’ll need to weigh that amount of work against the cut Choice of Games wants.

(Personally, I prefer working in Ink to working in ChoiceScript, but I’m not aiming to make money off any of this. So the selling aspect isn’t a concern for me.)


I mean, the radio buttons in a table are an explicit accessibility UI choice: farther apart than a list of links so you’re less likely to accidentally hit the wrong choice on mobile, and making it an extra tap to confirm so that if you do get it wrong you still have an extra chance to fix it before choosing an option you didn’t mean.


I’ll mainly echo what has been said and include my historical observations regarding people who propose to create a new IF parser/choice authoring systems from scratch:

  • Making an interactive fiction creation system is a lot of work, potentially for little reward
  • Duplicating the exact functionality of an existing system is a lot of work, and invariably will suffer comparison: “Why should I learn and use XXXcreator when ChoiceScript exists already with thousands of hours of testing and support?”
    • Specifically: ChoiceScript can be used for free so long as you’re not making money from what you create. If you don’t want them to host, you can negotiate a royalty payment/scheme with Choice of Games for rights to self-publish commercially.
  • Ideally, you want to distinguish yourself and your system - if you’re duplicating an existing creation system, you want to improve on it in some way that makes similar-minded people want to use your system instead of the original that can be explained in an elevator-pitch. For example: "I want to make a system like ChoiceScript, but including robust multimedia support for images and music, an inventory system, and auto-mapping."
  • As good as your system is, ideally you also should develop a “killer game” (or at least a very competent one) to release alongside it that shows off your system’s abilities to their best effect. If possible this should be a playable game that shows it off well, not just Cloak of Darkness or a one-room example of functionality. Ideally you want people to play this debut game and inspire them to say, “I really want to make a game with this system…” Ideally, enter this game in a comp for exposure so you’ll get buzz “What did they use to make this? I’ve never seen a game do X and X before/at the same time! I want to be able to do that!”
  • There are already many lesser-known choice-narrative systems online that are “good enough” for people who don’t want to use a complicated standalone system. so your prospective “killer feature” or combo of killer features that gives people reason to use your system and not an established one is key.
  • “ChoiceScript, but free” isn’t something people are clamoring for, and may step on their legal intellectual property if you simply duplicate the functionality of their work.
Real World Example

I will cite one system that got a long way and crashed and burned: ElmStory Creator. It was perfect for what I wanted - I even donated a bit to its progress. It was usable in alpha state (with some problems that were being worked on) and being developed by a team. Then the lead programmer got a day job, team infighting ensued, and the all progress was halted due to lack of support, and all messages regarding its progress were rage-deleted on here by someone who was upset about it before we restored them. This was a professional-quality QBN choice system with ideas and a ton of work put into it that did not reach fruition.

I even posted screenshots of prototypes I was creating with it:

Introducing Elm Story - a new tool to visually compose and publish interactive storyworlds - #19 by HanonO


I wrote an open source CS interpreter in C back in 2017. It runs some games but not all. The project would need to be dusted down and finished.


11 posts were split to a new topic: Self/-- Publishing and Marketing IF [Split topic]

First off, I find this fascinating. I’ve always wanted to build my own engine of sorts. I don’t have a proper programming education, but I’ve managed to muddle my way through most programming related things. The one area of true interest I have is interface design.

In the engine I’m working on, I’m trying to make a mobile friendly, parser-like choice framework. Of course, I’m just hard coding a bunch of stuff to begin with, but the more I started working with it, the more I realized that I don’t have to make my own scripting language for the authors to use. At least, not a robust one (just some simple, if conditions in the story prose and variable outputs would suffice, I think) and the rest of the authoring can be done through an editor interface. Then you can leverage browser capabilities, like spell checking.

I guess what I’m saying is, how would you improve the ChoiceScript experience? Maybe being able to duplicate ChoiceScript isn’t even necessary depending on what you envision a choice-based story to look and behave like.

1 Like

Several people have commented, from different directions, that ChoiceScript has a pretty simple design. Replicating it (in a technical sense) would be pretty easy. Inventing a system that was “ChoiceScript with a bunch of features added” wouldn’t be that hard either.

I agree with that! But I would add: CoG has a good competitive advantage in CS. The advantage is not that CS is the most featureful system out there. The advantage is that CS is familiar, stable, very well-supported, and well-understood by lots of authors and editors.

If you crash in with the idea that “CS with more features” will be a strong competitor, you’re not seeing how the landscape works. Also, you should look at Ink again.


Some of us might have ignored potentially part of your question, focusing on the technical aspects of coding and developing a system, but on re-read it appears as if you might also have been implied duplicating the hosting/revenue side as well.

Again, historically many attempts have been made at a business model of “Write with our tool, publish on our site, share the revenue.” It’s a great idea and CoG is one of the few successful ones. Many others have tried and failed.

Storynexus was essentially “Create your own Fallen London-style epic” and had a lot of interest. They tried for a couple years, but it was difficult for singular authors and small teams to create a story world on the scale of Fallen London that would keep people invested enough that they’d spend for “candle” turns, or create a big enough network of legit smaller games that could draw people into a cloud of games using that model and pay for them. My assumption is if they could lose money for a couple years they might have gained popularity and become profitable but I believe they ultimately decided they couldn’t keep it running at the pace that people were creating.

Varytale was a similar but simpler QBN engine for more literary sedate stories, the idea being “premium” chapter choices could require credits readers paid for. It went down before Storynexus after producing the lauded Emily Short game BEE which was lovingly recreated in Dendry so it would still be playable.

I’m sure there are a ton of other “publish your story on our site, make the first chapters free, pay to read the rest” or each page of the story has ads and generates passive revenue even though the reader doesn’t pay. Many of these don’t catch on, but I think there are some that might flourish in their niches, such as erotica or furries or fanfic.

A few do this without a revenue model:

Texture is a unique system that hosts its own works together with the tool. I think they get by because the engine is very light and text is inexpensive (similar to ChoiceScript), essentially creating games that run like web-pages, so bandwidth costs are not a burden. have two engines - Quest and Squiffy - which are free to use and publish games on their site or separately and have a devoted player/creator base. They also accept browser-playable games for free hosting such as works in Twine.

Borogove hosts small games and “snippets” created on their site - they’re less a game site (in my mind) as much as functional builds of several IF engines for authors that can be used online. They’re great for testing and demonstrations - such as if you want to experiment with Vorple before setting it up. One of the coolest uses is they will host a “snippet” that runs in an iframe - many here use it to put working examples of code and a playable test game directly in a forum message.

The other thing, marketing-wise, you’re competing with is They are not a gaming system but essentially Steam without restrictions and will host practically any game for free made in any system with robust marketing features, online browser play, free/pay-to-download or pay-what-you-want monetization schemes, and have a built in base of approximately a gazillion players you can put your games in front of. Not all of them are looking for IF, but if you find your niche and tag your game appropriately so it appears with popular search terms, it works.

itch is huge

I have several free erotic games on itch, I barely pay attention to them and they do extremely well. If you can create targeted content for people hungry for it (it doesn’t have to be erotica - short horror games are popular also) they likely have the biggest potential audience. Someone smarter than me could probably parlay this into a minor revenue stream by catering to an audience and publishing what they want regularly, drumming up donations or charging $1 for frequent short games.


I’m obviously biased, as cofounder of Choice of Games and designer of ChoiceScript, but I did have a few words of advice.

If you’re starting a competitive publishing house, I recommend paying large advances

Choice of Games offers a $7,500 advance against 25% royalties, or, if the author prefers, a $10,000 advance against 10% royalties.

EDIT: On Jan 24, we announced that we’re offering a $10,000 advance against 25% royalties, or, if the author prefers, a $15,000 advance against 10% royalties.

For those not familiar with the publishing industry, an “advance” is an amount that a publisher pays the author up front; it functions somewhat like a loan to the author, but the author never makes any payments against the loan. When the book/game goes on sale, the publisher initially keeps 100% of the sales, until the author “earns out the advance.” So, if/when a game makes $30,000 in sales, that’s when the author’s 25% would have been equal to $7,500. From then on, the author receives 25% of any additional sales past $30,000. If the game never earns $30,000 in sales, then the author never receives any royalties, but never has to return any part of the advance; the publisher always has to risk losing the advance.

When Choice of Games started, we launched with a much larger royalty share for authors, but we found that we couldn’t convince authors with professional experience to work with us unless we paid large advances instead.

Literary agents would reliably advise their authors that royalty percentage means nothing, because publishers can never be trusted to pay you, and instead you should assume that the only money you’ll ever receive from a publisher is the advance. (Surprisingly, we heard from some authors that they found our large royalty share suspicious, indicating that we were “desperate.”)

Taking that feedback to heart, we put the royalty rates much, much lower (but, as others have noted here, still very competitive with the rest of the publishing industry), and cranked the advances as high as we could afford to risk.

You’re right that we have limited competition (and I think having capital to risk is a big part of that).

I predict that if you’d like to compete with us, you, too, will need to provide large advances, and, unless you have very deep pockets and/or an insatiable appetite for risk, you, too, will have to lower your royalty share, to compensate.

We also have a Hosted Games label, where we offer $0 in advance and only 25% royalties. Our policy is to have the HG royalty no higher than the CoG royalty, giving authors no reason to prefer to publish on HG over CoG.

People have asked, “Why is it worth it to publish on HG at all if the royalty share is so low? Why don’t I just self publish?”

There are two answers there. First, we do have marketing muscle to offer (we have hundreds of thousands of members on our mailing list, which drives a lot of sales), but another reason people choose HG over self publishing is the technical challenge of reaching all of the platforms.

Integrating with the app stores is a technical challenge

As others have noted in this thread, there are already a number of interesting competitor platforms, including Twine, Ink, and Adventuron. And it’s easy to develop your own, too. Developing a work of choice-based IF is often a novice programmer’s second program, literally right after “hello world.” It’s one of the recommended projects in JavaScript for Kids for Dummies. (Chapter 16: Choose Your Own Adventure)

But it’s surprisingly challenging to take a Twine, Ink, or Adventuron game and publish it in a native app for iOS, Android, and Steam. When you publish your first game for all of those platforms, you’ll have to pay hundreds of dollars in fees to the stores just to be allowed to publish at all, and you’ll find that it requires (at the very least) dozens of hours of work to get your game through the submission process. allows you to submit an HTML file and publish that, but Apple, Google, and Steam all require you to develop a native app. There are PWA wrappers that can do that for you, but they don’t work well, and they especially don’t integrate with native platform features like in-app purchases, achievements, and ads. Getting that right requires learning how to write a native app (even if the app is mostly a wrapper around your HTML), which might require you to learn Swift for iOS/Mac, Kotlin for Android, and C++ or Rust for Windows.

And the app stores take a 15-30% fee of their own. (Our royalty percentage comes out of the 70-85% Apple/Google/Valve lets us have!) If you want to avoid that fee, you’ll have to implement your own online store, which requires setting up a database (probably using SQL), and writing server-side web code in a language of your choice.

Visual design stems from supporting touchscreens, mouse, and gamepads

If you want to sell your game on iOS, Android, and Steam, you’ll have to ensure that your game works well on touchscreens, mouse, and gamepad controllers, which typically means constraining your visual design.

For example, hyperlinks are hard to select accurately on touch screens, especially if they’re very close together, so IMO most good mobile choice-based IF displays options on a menu as large, tappable buttons.

Gamepads make this even harder. Many popular choice-based IF games designed to operate well on gamepad require the author to limit the number of options in any given choice menu. For example, if you use a “dialogue wheel”, you really can’t have a dozen options on a wheel. Even just pressing “down down down” 8 times to get to the eighth option on a list can be quite unpleasant on gamepads.

I predict that if you start from scratch and aim to support touchscreens, mouse, and gamepads, your visual design will converge on something very much like what ChoiceScript looks like now.

Alternately, you can design different experiences for touchscreen, mouse, and gamepad. That might be better! But it’s way more work for the author/designer/programmer. (“What should the choice at the start of chapter 3 look like on touchscreens? On desktop? On gamepad?”)


Ha! Yeah… that sounds about right! :smile:

Just curious, what does the device landscape look like for ChoiceScript players? Like, what’s the rough percentages between Desktop, Tablet and Mobile?

1 Like

We have solid data on sales between Apple, Google, and Steam, but converting that data into sales by “desktop,” “tablet,” and “mobile” is kinda hard.

When you buy on the Apple App Store or the Google Play store, you can play on any iOS or Android device you own, so sales aren’t categorized by “phone” or “tablet.”

Similarly, when you buy on Steam, you can play it any way you want, including with a mouse on a desktop/laptop, or via Steam Deck, or projected to a TV, or even on mobile, via Steam Link.

All of those platforms support keyboards and controllers, (even mobile!) but you don’t have to use controllers on any of them.

I don’t think we have a good record of “X minutes played on phones” vs. “X minutes played on tablets,” or even “X minutes played on touchscreen” vs. “X minutes played via mouse”, “keyboard”, “gamepad”, etc.

I’m not sure what we’d do with that data; we’re just going to try to ship great experiences (and fix bugs!) on all of the platforms, whatever way you want to play it.


I admit that I’m naive about this, but I would use that data to determine the importance of providing slightly different aesthetics and possible mechanics for the same published story. It would feel like the same experience, but just have a few tweaks depending on the device.

For example, with the click to choose, then click to confirm… with a game pad, it’s way less likely that the wrong choice would be made, but maybe have the user hold down the button longer (with a small meter icon) to confirm the choice. Another example, for mobile, is it’s not convenient to scroll down after making a choice to confirm. 2 taps is fine, but tap, scroll down, tap is kind of clunky. An author can only restrict the text in their choices by so much so I wonder… maybe tap, then a confirm button appears on the bottom on top of the story layer; equals no scrolling required after the choice is made. Things like that are always in the back of my mind. If very few people play ChoiceScript games on their phones is it because the experience isn’t as good as a tablet or desktop? If so, maybe that can be remedied to expand the audience even more.

I’ve only every played ChoiceScript games on my desktop so apologies if you already implemented something like what I’ve described.

1 Like

On the flipside, I’d say you’re the single most qualified person here to answer the question! Plenty of us can talk about what it’s like to use ChoiceScript on the technical front but very few of us can talk about the logistics of running a digital publishing house!


Here’s the way ChoiceScript works today.

  1. On touchscreens, when you tap on a radio button, we display a little translucent animation, sliding from right to left. If you then slide your finger from right to left on an option, it will select that option, without requiring you to scroll down and tap “Next.” (You can turn this off in the Menu → Settings → Touch slide controls.)

  2. When playing with a mouse, you click an option, and you then need to click “Next” to confirm it.

  3. You can also play with a keyboard. (You can press the ? key to see the shortcuts.) Note that the “down” arrow key usually just scrolls the page down slightly, and I did not change that behavior here.

  4. On Steam, when playing with a gamepad, I map the controls to keyboard shortcuts.

    • Left stick: “down” to Space and “up” to Shift-Space
    • Right stick: “down” to J, “up” to K
    • X: (The primary OK button) Enter key
    • Right trigger: Enter key (so you get to choose which button you want to use to submit)
    • “Options”: W (Menu)
    • Another face button: Q (Show Stats).

Since all of this is in place, none of this requires me to know how many minutes people play on different platforms to decide whether to make the experience better.

When I ask myself, “Should I make the experience better?” the answer is “yes, if I can see how to do it.”

(I do wind up making some judgment calls on how to prioritize those bugs, but I usually just do it by gut feel.)


That sounds absolutely brilliant, Dan!

Obviously, I had no idea how slick you made the choice mechanics across the board. Now I get why you’re not concerned about tracking devices… you’ve pretty much thought of everything! :laughing:

I can see why your platform is so popular. Thanks for the thorough reply… and for humouring me. :wink:

1 Like