JSON based IF language

I’d very likely use js-yaml.

Interesting that the article essentially just mentions “there is a tool for this” without going into any depth haha. Guess I’ll have to look at the source it links to instead.

EDIT: Yeah I stand corrected. Definitely not a hard translation with all the tools out there.

My thoughts, as someone who uses a custom system:

Consider what’s more important to you: do you want to make the best possible game or are you more interested in enjoying the process of making your game? Rolling your own system is a lot more work and is still likely to give inferior final results compared to using a tried and tested system. I think the trade off is worth it because I really enjoy tinkering with code. But I’m under no illusion, for the same amount of time spent I could have built much better games if I’d stuck to one of the standard systems.

3 Likes

I would actually like to create a good game, but nothing really offers the flexibility I need… like, at all.

Choicescript meets bare control flow functionality and has almost nothing in the way of controlling the way text is displayed, which is a must. Not to mention it’s proprietary, and I’m not sure the impacts of that if my game becomes larger. I was actually writing my code in choicescript, got almost 100,000 words in before I finally had to admit that it wasn’t gonna work out.

I looked into twine and it has a lot of fancy CSS features, but I can’t find any sort of twine engine that has the sort of control over gotos and labels I need (or other such program control). Everything is based on links and I can’t figure out a way to do a subroutine or goto without needing a user to click on a link, which is absolutely essential for what I need to do. Please correct me if I’m wrong about this and Twine can actually do that stuff, though.

Ink actually has almost exactly what I need in the way of flow control, but suffers direly from a lack of a save feature and an interface that I don’t exactly like. My reasoning is that fixing these issues would take almost as much time as creating a (possibly uglier at first glance, but still more workable/friendlier UX) language myself.

I’ve been recommended others like RPG maker, but even though those have nice pretty assets, there’s no way I’m going to be able to incorporate my game mechanics in their system… right? Idk I haven’t actually tried any of them but almost all of the others feel like they’d force me into a certain game paradigm. Even though choicescript was made for a lot more narrative novels than I’m making, it at least was designed to be flexible enough to write the sort of thing I’m making.

Oh, there’s the text adventure programs, too, plenty of those, but that sort of goes along with the last paragraph… I really, really am not making a “text adventure”. For one, my game is choice-based. For two, there’s no geometry to the locations (some locations/labels aren’t even places, just snippets of text that could be run from wherever), and while there’s an inventory, that’s not the central variable to the game. Variables can be relevant to multiple rooms in some very separate places, but may still not make sense to be global. And, well, it’s just not a text adventure. Like I said, when I’ve looked into these tools it feels like I’d just be constrained even more so than I ended up being in choicescript. Let me know if you think I should still give something a shot, though.

If I had any recommendations to myself, I’d tell myself to use S-expressions next time. You gotta love a thing where code and data are basically the same thing.

Bonus points for its historical relevance to Zork.

IME, it is difficult to convince anyone who wrote 300 words aguing they need to code their own system, to use any other existing system.

Now, you haven’t really told us what’s the exact thing you can’t do in choicescript/twine/ink, because surely, we can help you do that thing in at least 2 of these languages in less time that would be needed to whip up an entire language (pretty confident about this).

But again, you seem pretty stocked up creating a new one and I can’t blame you for this desire.

3 Likes

It would be interesting if you pointed us at a game that does (approximately) what you envision and explained where it falls short of what you want to do.

I don’t know what exactly you are trying to do and I probably don’t enough about twine to help if I did, but have you checked out the SugarCube v2 Documentation? It seems fairly extendible.

From the docs:

Saving and loading

To save the state of your story within your game, call:

string savedJson = _inkStory.state.ToJson();

...and then to load it again:

_inkStory.state.LoadJson(savedJson);

My gut feeling is that, if the save feature and interface are the only issues you have with it, Ink might still be your best bet. There’s a web Ink engine called calico that might (caveat: I’ve never used it) make styling the interface easier. And you can always ask for help on this forum. :slight_smile:

That said, writing your own engine is fun.

4 Likes

I confess, I’d not thought it all the way through when I wrote that. I like Markdown for its text formatting features. (There are times I’m coding TADS and I wish I could use Markdown instead of HTML for formatting.)

(Hand-waving commences.) My fuzzy idea for a [ simple / crude / wut? ] Markdown IF would be to use the header tags for containment, where H1 represents each location and H2/H3/H4… are objects within the location. You could possibly use other Markdown indicators for your “action” tags.

What you need (i think) is a flow-based paradigm that’s very low on syntax.

A flow based system is one where “terms” encountered in “flow” cause the programming equivalent of a subroutine call.

example 1:

STORY1
The cat sat on the mat.

example 2:

STORY2
The CAT sat on the MAT.

CAT
* cat
* dog
* rabbit

MAT
* mat
* carpet
* sofa

STORY1 emits “The cat sat on the mat.” And STORY2 emits random stories like “The dog sat on the sofa.”

The only syntax here is upper case words are “terms” and everything else is “flow”.

This syntax can be extended to make a whole choice game quite easily. This is the syntax I use in my Strand system. Extending to text adventure “worlds” is a bit more complicated, but straightforward.

This approach is not the same as CS or Ink because anything can branch regardless and there are no presupposed types of object like locations, scenes or acts.

You talk about wanting to control the way the text is displayed. Do you mean controlling the layout of the text (which i think is a GUI problem) or do you mean the formatting of the text - like rich text?

For the latter, i recommend a form of extended markdown so that your authored input files remain regular text files. That’s what i do.

anyway?

I’ve thought about making my own “engine” as well. I wrote out the syntax and basic commands that I would need. After all was said and done, I ended up with kind of a mixture of the 4 main Twine story formats. However, the main thing I wanted was to have something as bare bones as possible.


Snowman is a framework that requires you to make your own language on top of it to get anything reasonable out of it. However, it’s got everything you need in its base functionality. Meaning, you can launch it in Twine, but use your own commands to do whatever you want. The documentation is sparse, but so is the base functionality… which is a boon, not a knock against it. It honestly looks like a solid framework and seems like a great thing to read up on to determine if you’ve got your own base functionality covered.


Chapbook is like Snowman (kind of), but with an existing thin language on top of it. It’s straight forward to extend with your own custom commands, but it has some quirks. I’m currently learning it, but I have high hopes. Looks very promising. I want to be able to extend a language more than create one from scratch. Chapbook encourages authors to extend it and works with JavaScript very, very well. You can check out some discussion around figuring out how Chapbook works here, but the official documentation is limited.


The other two are Harlowe and SugarCube. I sense you won’t want to work with them (even though you can do whatever you want in both – see my journey with Harlowe) for the same reasons I’ve shied away. I just like the idea of coding in JavaScript as much as possible. I don’t like overriding someone else’s default CSS if possible. I don’t like the idea of a bloated framework where I’ll never use 95% of what is there. I don’t like having to work around someone else’s interpretation of how things should work.


It honestly sounds like you might want to visit Snowman. It’s got all the base functionality covered to be fully compatible with Twine, yet it needs a language of custom functions to make it feasible. It’s like C++ and you’re building your own library on top of it. That’s where I would start. Snowman, baby. Snowman. :wink:

You’ll have to decide if you enjoy the process of making a great game or making a great framework for a game. Both are worthy endeavours and a lot of fun.

Edit: I have no idea why this post replied to Jim.

1 Like

I think you’re conflating IF elements.

JSON might be good for world model state data. It might be good for describing grammar.

But I think logic and the turn engine might belong in JavaScript or Typescript.

4 Likes

really confused abt this bc twine sugarcube has all this functionality. just for example: goto can work in a conditional or with an auto-incrementing countdown timer, among others (I’ve used it in this way many a time for my games). idk what you mean by labels exactly but passage tags exist which you can get with js to do conditional logic and more with. customizable functions called widgets add more functionality (written in sugarcube) and if that’s not enough, can be extended with your own js code or a lot of pre-existing js libraries using auto-compiled .js script passages.

Like if you wanna write your own language (and you do seem like you’re set on it…) you can, but twine can do this stuff

2 Likes

Instead of JSON, how about JavaScript? Any file that is valid JSON is virtually JavaScript already, just add const data = at the start. But JavaScript is a lot less fussy, and you can have values that are functions too.

3 Likes

If you haven’t already, take a look at the source code for Gruescript, or at the files it spits out when you download your game (choose “The Party Line” from the Examples menu for a full-length example.) It builds a JSON object structure that includes rooms, items, verbs, etc. Gruesome is a parser game written using (almost) the same JSON model but with an actual parser on the front.

2 Likes

Another one that nobody’s mentioned is Adventuron. This uses JSON under the hoods, but it’s not open source, so you can’t see how it all works.

1 Like

Write this a couple days ago but needed to wait since I was posting too much as a new member apparently…

Sorry, didn’t mean to come across as so intense. Tbh, I just feel burned from the apparent complete lack of ability to implement some features I deemed necessary in choicescript after writing 100k words, but ultimately I just have to use best judgement rather than letting one past experience dictate how I go about everything in the future. I can probably get away with some tags even then? I’m not sure if that’s the best approach though, especially since CS is still proprietary. Here are a list of specific features I’d like:

  1. Multiple save slot system. I should have specified this better, since I was aware that ink had a saveslot system, but it’s not multi-slot. Still, I could probably implement my own. I’m just worried about also having to configure the UI differently and whether that will just end up being more work, but I’ll try to set aside those paranoias.
  2. Configurable UI. I got a lot of feedback that a little box for monthly alerts would be good, and so would another with some statistics relevant to the current storypoint. I also need a way to navigate to the full stats page, and I may need additional buttons or UI styling in the future. (This is where choicescript seemed to fail me).
  3. Access to goto and gosub constructs without user input. Twine seems to force clicking a link to do a goto, but if I can look at sugarcube again. Do you know if that’s true? Some constructs to make variables tied to certain defined scopes (maybe I want a variable to be accessible in town and tunnel, but not orphanage) would be nice, too.

ChoiceScript is intentionally limited to be more approachable to authors that are often new to programming and it’s a commercial tool so there’s no reason for them to add things that don’t fit their house style.

That’s not true of Twine, or as true of many of the other systems.

  1. SugarCube’s save system is multi-slot.
  2. UI: SugarCube does this pretty well, there’s a passage that you can add to completely replace the default UI, and functions to call for all the standard UI bits, I believe.
  3. I’m not sure where you got this idea because AFAIK it’s not true and has never been true. How do you want to trigger the goto? In SugarCube it’s just a function so you can call it whenever (on a timer, from another passage, etc.). I believe Harlowe is the same. Or…maybe I’m misunderstanding what you mean by goto or gosub…? Edit: yeah, the more I think about it, the more this feels like a terminology issue, and different kinds of goto/gosub might be handled different ways in different systems. Can you talk more about what you’re trying to do?
  4. (I’m splitting this because it seems separate) I’m not sure what you mean by accessible. In IF you generally just want things to be global because you never know when you may want to ask from somewhere else if…the train is in the tunnel or something like that (because your character might know because they can hear it, or they’re on a phone-call with someone who just got cut off because the train went in the tunnel, or any number of other reasons). If you’re the only programmer, make them global and just don’t use them. If you’re talking about interface visibility, that’s just an if statement so it’s also easy.
2 Likes

Remember that the backbone of all Twine stories is JavaScript and there is always a way to implement JavaScript with every Twine story format, if the story’s own language cannot support what you want.

However, it sounds like you want to make a parser game. Is this true? Twine is not setup for parser games, though it can be modified to do so. Creating arrays of objects that exist in certain passages, but not in others is always possible no matter the story format you choose.

1 Like

No it’s not parser based! Thank gosh, that would be much harder to code logic for.