Customising/Reimplementing ChoiceScript

[Jacic (Jac)]

@J_J_Guest

Every ChoiceScript game looks exactly the same.

One of my wishlist items which I suspect will never come to pass is a customisable setting in addition tothe regular black/white/sepia because you’re right, in their native state all CS games look the same and it’s kinda boring. Are you publishing though HG/COG? Because if not you can to an extent go playing in the code to change things about. (It’s limited without writing scripts, but you can change things like colours, text type). If you’re going to use a custom colour scheme, I recommend adding a script to auto set the game to the “colour set” you’ve altered. Other than that you’re kinda stuck adding images. (If you’re planning on publishing through official channels though, then yeah most alterations and all scripts are not allowed.)

@zdillon

I, too, am surprised there isn’t more conversation about Ink and ChoiceScript in these circles. I thought I’d be lost without a node map, but it’s so much faster to write in CS than adding and typing in tons of little separate boxes in Twine (the contents of which you can’t really see unless you open them!).

Agree. When I first started writing IF with CS, I kept notepads with each scene mapped out. After a while I found I no longer needed it as a general rule and started finding it actually a little clunky to use the twine interface. Maybe you just end up in the right headspace sooner or later with enough practice? I’ve been fluffing about with ink on and off, I’m not sure why I’m finding it harder to pick up than choicescript as it seems like it shouldn’t be. In saying that I find twine harder to use than CS as well which is a shame as it is a lot more customisable.

@J_J_Guest

Well, ChoiceScript has its own forum, so writers from here tend to go over there if they have questions.

For questions sure and I highly recommend it as I’ve had problems solved there heaps of times. Usually lots of people willing to help. For general game discussion/design etc, anything not actually being built for a HG/COG release or not fitting the expected aspects gets very little attention. Not saying that’s bad, there is a specific niche there which is fine, but CS games outside of the official release channels don’t really have a regular discussion platform.

[J_J_Guest]

@Jacic

Are you publishing though HG/COG? Because if not you can to an extent go playing in the code to change things about. (It’s limited without writing scripts, but you can change things like colors, text type). If you’re going to use a custom color scheme, I recommend adding a script to auto set the game to the “color set” you’ve altered. Other than that you’re kinda stuck adding images.

I am planning to release the game through COG, as a hosted game, though in terms of structure it seriously pushes the boundaries of what typical COG fans tend to expect, so I can’t imagine it will appeal much to their core readership. It would be fun to add illustrations, but given the size of the game it would add years to the production schedule.

As an aside, Strand Games used to offer an alternative way to publish ChoiceScript games using their Brahman engine. I’m not sure whether this is still the case, or what would be the legal ramifications of monetising a game produced this in this way.

[Draconis (Daniel Stelzer)]

Huh, interesting. I believe (I am not a lawyer) that you can own the rights to a particular implementation, or to a particular name, but can’t own the rights to a language, so if someone wants to write their own ChoiceScript compiler or interpreter from scratch (and brand it without any reference to CoG), it’s legal to do so.

But also, in a small community like this it seems kind of rude to do that, so hopefully they ran it by Choice of Games first and got their approval.

[HAL9000]

From the GitHub repository for ChoiceScript:

Non-commercial usage and modification of the works is permitted
provided that (1) the ChoiceScript license is retained with the works,
so that any entity that uses the works is notified of this license,
and (2) the user grants at no charge an unrestricted, transferrable,
non-exclusive license to Dan Fabulich and Adam Morse for any
modifications, if any, made to the ChoiceScript interpreter.

It’s open source with commercial restrictions, basically, and the CS team gets the rights to use your code too. Sounds reasonable enough.

[Zed (Zed Lopez)]

I’m not a risk taker when it comes to potential IP infringement, but I wouldn’t fear legal consequences if I were to write or release a ChoiceScript work-alike (not that I’m planning on it).

There have been two discussions this year involving reproducing ChoiceScript

• Typescript/Svelte IF Framework
• How difficult is choicescript to duplicate?

Dan Fabulich was active in both talking about bits that are harder than they seem but didn’t begin to suggest the enterprise would be legally contraindicated.

[tsanderdev (Tarek Sander)]

@Draconis

I believe (I am not a lawyer) that you can own the rights to a particular implementation, or to a particular name, but can’t own the rights to a language, so if someone wants to write their own ChoiceScript compiler or interpreter from scratch (and brand it without any reference to CoG), it’s legal to do so.

I deliberately never looked at the ChoiceScript compiler code when I tried to recreate it, so I can’t even accidentally violate the copyright. I drifted a bit away from IF in the meantime though, but maybe I’ll pick it up again in the future. @dfabulich Mind stating how you feel about alternative implementations of CS? Would you go after them legally if they allow commercial usage?

@Jacic

In saying that I find twine harder to use than CS as well which is a shame as it is a lot more customisable.

Customizability was actually the reason for trying to make my own ChoiceScript implementation. I don’t agree with Dan’s view that you have to take away that much visual control from the authors to make the games playable and accessible on desktop and mobile. Also for my stuff I need something Turing-complete, and that would be pretty easy to integrate into CS.

@Mike_G

As a Firefox user, I still run into sites today that are broken unless I switch to Chrome. Less so for Edge, but double for Safari.

I encounter an unusable website on Firefox like once a year only.

@Mike_G

security problems

That’s true, but I think the best sandboxes of the entire world are the ones used in browsers, so it’s not usually a problem.

@HAL9000

Another alternative to present locally run JavaScript enabled IF is to package it into a browser executable. For example, a Chromium browser can be packaged with the webpages and web media and use JavaScript in it’s own application scope. However, there a level of risk with running executables from unknown and untrusted sources.

Congratulations, you just re-invented Electron lol. My problem with that approach is that it’s pretty bloated. Even if you just compile the V8 JS engine alone it’s 50 mb iirc. Tauri is the more lean approach, but has less integration between the front and backend and relies on the features available in the system’s WebView.

@HAL9000

Still, if a game was so large in scope that a performant database was required, webserver databases are probably the answer. My mind reels with what kind of game could demand a database to drive it. A monumental scale text adventure on a simulation level, maybe?

In before someone releases the first IF game that needs docker compose lol.

[dfabulich (Dan Fabulich)]

@tsanderdev

Mind stating how you feel about alternative implementations of CS? Would you go after them legally if they allow commercial usage?

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!

@tsanderdev

Customizability was actually the reason for trying to make my own ChoiceScript implementation. I don’t agree with Dan’s view that you have to take away that much visual control from the authors to make the games playable and accessible on desktop and mobile.

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…?)

[HAL9000]

@dfabulich

I’d just like to add that ChoiceScript gets quite a bit of our sales from visually impaired users using screen readers.

I think this is extremely important to explain (defend) ChoiceScript’s lack of visual control and layout. I kind of got that vibe after delving into the language. Even the image command encourages an alt attribute description.

[Jacic (Jac)]

@dfabulich

you can contact us and get a license to do that

Hey Dan, was just wondering about those the other day. Unless it’s only to publish to itch.io, isn’t the licence to be able to publish elsewhere on CS about $20k though? (I totally understand why, but would probably put it in the realms of individual devs not needing to consider it as an option if they wanted to make something to go on steam/app stores and just go with another language as you were suggesting.)

@dfabulich

or offer authors a choice of CSS themes for styling their entire game,

I would absolutely love a customisable theme that could be selected along with the sepia/white/black (or even instead of white or sepia since they’re very similar). I can do it by fluffing about in the code, but for those who don’t know how, or for official games it doesn’t happen. It just would be nice for authors to have an overall theme that suits their game for those who want to use it. Just a wishlist item that I wouldn’t think would interfere with screen readers and could go a long way to making games seem different from each other if used to set the atmosphere with a particular colour scheme. (And if someone decides to make a horrific setting like flouro pink text on yellow, well then the reader can always go back to good ol’ sepia to read so no one is forced to have to use the custom setting if they don’t like it.)

[Jacic (Jac)]

@J_J_Guest

so I can’t imagine it will appeal much to their core readership

Yeah. Unfortunately that is a downside. I’ve been finding myself (I tend to write things that don’t fit the expected themes) that it is hard to get much enthusaism for projects that don’t fit as the expectations have become very narrow over time (extremely long playthrough length, romance focused, blank-ish slate protag, branch and return structure etc). Worth a go though, never know, it might hit a chord that everyone really likes . What is it called so I can keep an eye out for it if you don’t mind me asking?

[ChanceOfFire (Vance Chance)]

@dfabulich

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.

Couldn’t we have both? It would be nice if we could have an option for writers to change the visual theming of their game for users who might be interested in it, while still ensuring that essential information isn’t conveyed with color, to ensure that these games remain inclusive to visually impaired users.

Being able to change fonts, colors, styles and so on would allow each game to have their own unique flavor. I have looked through twine games which were self-published on steam (Arcadie: Second-born, The Night Market) and both of them are just so much nicer to look at than a choicescript game. Speaking as both a published author and customer of choicescript games, I think this customization is something which would very much benefit the platform.

@dfabulich

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.

Speaking as someone who is working on his next choicescript game and is considering other platforms, it would be nice if we could have this flexibility.

[Jacic (Jac)]

@Jacic

It just would be nice for authors to have an overall theme that suits their game for those who want to use it.

Just an example from a game I just made for ectocomp. It’s choicescript with some colour changes made to the background, buttons and boarder colours. (All I’ve done is change some colour codes in the source coding for what used to be the ‘back background’ setting, and then used a script to push the game to use the back background as default so players know it is there.) Not sure if everyone agrees with me or not, but I feel it really helps with the theming without changing how the game is written at all so will not impact screen reader

[LeiaTalon]

That looks great, especially the teal button with the image at the top. Does it work as well for non-dark mode, or are you locked into white text on a dark background?

[Draconis (Daniel Stelzer)]

Honestly, easier than a custom ChoiceScript interpreter might be a translator from ChoiceScript into Ink or Twine or some other system. The goal wouldn’t be a perfect translation, since these systems have fundamentally different models of interaction, but it would give you a starting point to put your existing code/writing into a different system (and one designed to have the aesthetics customized extensively!) without doing the tedious part by hand.

[Jacic (Jac)]

@LeiaTalon

That looks great, especially the teal button with the image at the top.

Thank you!

@LeiaTalon

Does it work as well for non-dark mode, or are you locked into white text on a dark background?

In the menu option it gives you 3 colour preferences to choose from. Each colour setting (black/white/sepia) seems to have it’s own colour palates in the code though and they are not linked. I only changed the black background one so far for this game, so the other 2 settings are showing as they normally would (dark grey text/buttons on a white or sepia background).

I could go in and customise white and sepia to a more “green-blueish” theme, so they all work though with whatever colour setting people would prefer to use though. It’s actually kind of handy in a way that all the colour settings are separate, as it means you don’t have to worry about trying to pick a single button colour for example will work on both a white and black background.

[averyhiebert]

Since it’s fully the topic of the thread now: what, exactly, are the reasons why one would prefer reimplementing ChoiceScript over just using Ink (which is open source, more explicitly designed for extensibility, and already supports many languages/platforms/engines)?

The main use cases I can think of:

• Someone who wants the extensibility/openness of a system like Ink, but who (for reasons that are not clear to me) prefers the experience of writing in ChoiceScript to that of Ink? (my impression is that Ink is more ergonomic/less verbose, but I guess maybe ChoiceScript is more readable?)
• Developer who’s already familiar with ChoiceScript who now wants to apply their existing skills in a commercial non-CoG setting, or who has been seized with a sudden anxiety regarding the fact that they’ve tied their personal skillset to a proprietary platform.
• Launching a new platform, editing tool, etc. where you hope to attract the aforementioned existing CS authors
• Creating an open-source implementation of a proprietary language that you’re not particularly interested in using, just out of pure “everything should be open source” ideological commitment
• ???

Alternately, I would maybe be interested in some sort of Ink → ChoiceScript transpiler (maybe using a limited subset of Ink), just on the off chance that I start writing something in Ink but then realize that CoG would be a good venue for it? But I mostly don’t write or read their particular “house style” of branching narrative, so it’s kinda moot.

[Draconis (Daniel Stelzer)]

@averyhiebert

Since it’s fully the topic of the thread now: what, exactly, are the reasons why one would prefer reimplementing ChoiceScript over just using Ink (which is open source, more explicitly designed for extensibility, and already supports many languages/platforms/engines)?

That’s what made me think of a translator—because the main use case I can think of is “I wrote an entire novel in ChoiceScript but now want it to do something that ChoiceScript doesn’t support, and I’m willing to give up compatibility with all the platforms CS runs on (and the Choice of Games brand, and their marketing, and…) in order to customize it more”.

[ChanceOfFire (Vance Chance)]

@averyhiebert

Since it’s fully the topic of the thread now: what, exactly, are the reasons why one would prefer reimplementing ChoiceScript over just using Ink (which is open source, more explicitly designed for extensibility, and already supports many languages/platforms/engines)?

The reason would be if you had already created a game in choicescript and later decided that you wanted the game to be on another platform for another reason. I mean, it would have been easier to code the game in said platform from the very start, but we don’t always have the benefit of hindsight.

[Jacic (Jac)]

A translator would also be super cool for helping learn languages (either ink to CS or CS to ink). If you can see what commands are working in what way, it’s so much easier than wading through manuals and trial/error. When learning CS one of the things I did was code diving to see how games were actually written.

I’ve been meaning to learn ink just as an option. Most of my games either fall into HG published ones or free on itch. CS has been my fav of the languages I’ve used so far in terms of making sense to me as I’m not really more than a basic coder in terms of proficiency and the layout just kind of clicks for me.

I would very much like more options for customisation though (which is why I’ve dabbled with twine here and there), and it is entirely possible I’m going to end up writing a very long game in CS sooner or later than I decide after the fact is actually going to completely fail with that audience so perhaps would be worth releasing in another format if the licence fee is too great to justify releasing it independently as a game with a small fee to play or even with donations to help at least cover costs of release. (Neither of which would be appropriate due to the non-commercial licence for CS outside of the official publishing channels. Anything on steam for free is now problematic due to the $100 fee which I just can’t afford to write off on a regular basis.)

I think my main issue with ink was I was trying to learn on inklewriter first as I thought it would give me the basics then go across to freeform ink. That was probably a mistake as I wasn’t a huge fan of the format, but the ink code itself with some effort would be something I could learn (if I can ever manage pull together more free time to really sit down and work on it. But do-able potentially .)