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.
Itch.io 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?”)