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.
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.
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.
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.
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.
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.
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
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.
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.
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:
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.
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).
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.
SugarCube’s save system is multi-slot.
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.
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?
(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.
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.
It seems SugarCube at least has a construct for gotos, but there are multiple warnings not to use them.
Using <<goto>> to automatically forward players from one passage to another with no input from them will both create junk moments within the story history and make it extremely difficult for players to navigate the history. It is strongly recommended that you look into other methods to achieve your goals instead—e.g., Config.navigation.override.
WARNING:<<goto>>does not terminate passage rendering in the passage where it was encountered, so care must be taken to ensure that no unwanted state modifications occur after its call.
These behaviors don’t seem optimal (and I don’t really see what an “alternative” would be), but as another person mentioned I might be able to just code it in with some extra js.
I guess… to me, that’s not how you usually do goto in Twine. That functionality is split up in a bunch of different ways depending on what exactly you’re doing.
And any tool that you use or make is going to have these kinds of quirks. You might notice it less if you make your own tool because you’re going to design it to fit the way you want to think… or you might have more problems because you’re running into all the little gotchas that existing tools have figured out over the years. Who knows?
Dunno. I like making tools, personally. If that’s what you enjoy, go for it. But if you just want to make a game and ChoiceScript is close in some ways but not quite what you’re looking for, then it’s probably not too hard to tweak Twine to do what you’re looking for.
To be fair, every language and toolset I’ve ever used that had goto support also came with at least three warnings, so this is kinda par for the course.
