Customising/Reimplementing ChoiceScript

I strongly recommend against it for commercial usage.

  • If you want to make a game and sell it on your own (creating your own developer account for Apple, Google, and Steam, or making customizations that we don’t support), you can contact us and get a license to do that, or just write your game in a non-ChoiceScript language.
    • Specifically, instead of ChoiceScript, I’d recommend writing your commercial game in Ink. Ink is MIT licensed, it’s pretty close to ChoiceScript, and it’s designed to be embedded in other non-IF game platforms.
  • If you want to start a competing publishing house, it seems strange to even want to use ChoiceScript for that. You’d probably be better off using Ink, Twine, or an IF engine that you fully control.
  • If you make and sell a game in ChoiceScript, we might need to investigate whether you copied any of our code. (Just telling us you didn’t may or may not be sufficient.) If necessary, we’ll have our lawyer contact you. We might decide not to get lawyers involved if we think that the money you’re making isn’t worth our time/money, but, in that case, it may not have been worth your time/money making the game in the first place!

In the other thread, I was mostly referring to the UI structure, which has to support mouse, keyboard, touchscreen, and gamepad. If you want to support all of those with the same UI, you kinda can’t use inline hypertext links. You’ll just have to put all your options in a menu at the bottom. And, if you want to support more than a dozen options, you’ll probably need the options to appear in a linear list, and not a dialogue wheel or anything fancier.

If you’re referring to visual theming (colors, styles, etc.) I’d just like to add that ChoiceScript gets quite a bit of our sales from visually impaired users using screen readers.

ChoiceScript is designed to prevent the author from controlling colors and styles in order to ensure that the author doesn’t convey essential information using color.

For example, in some Twine games, dialogue is depicted between multiple characters on a screen, representing each character’s writing in a different color, without any text to make it clear who’s talking (e.g. “said Dan” or whatever). Screen readers basically can’t handle that sort of thing.

It’s possible that we could be somewhat more flexible, or offer authors a choice of CSS themes for styling their entire game, but we’re going to continue to be much more constrained than Twine.

My impression was that your framework was designed to scratch an itch for you, which is fine, but if you really just want “ChoiceScript but I want to change the look a little,” working with us directly is going to be a much, much better use of your time than designing a whole ChoiceScript-compatible IF engine from scratch!

Also for my stuff I need something Turing-complete, and that would be pretty easy to integrate into CS.

Huh? ChoiceScript is already Turing-complete. (I thought you just wanted to use TypeScript and Svelte…?)