I’m sure you wouldn’t mind if I post this picture you probably already know
I like the idea to standardise this, but I think it’s a difficult goal to achieve, especially because everyone pretend his or her format is the best. For my part, I’m working on textallion and the txt2cyoa project for more than 7 years, so there are things I know I want, and others I don’t want.
For example I don’t want markdown or other harcoded markup systems because on contrary with txt2tags, as explained earlier, I can customise my own syntax as I want, and I can also include other syntaxes if needed. And with some regex I can export to also every system we can think of (so far: hyena, renpy, inform7, ramus, undum, twine, choice of game…).
At the moment, I’m looking for a way to enter random numbers into the syntax, as it’s a common request.
Most game apps need access to the internet. If you hook in Google Play services, or - for example - want to allow players to download stories directly from the internet (which is pretty much a necessity if one doesn’t want to make things extremely inconvenient for the user), you need online. In addition, for a game of this sort, you would probably want access to the users SD card (otherwise you can’t read story files the users has placed there), which is another place you don’t want any random internet person to be able to read/write from.
True. However, I believe in the coders law that says “the likelihood of a bug occurring is directly proportional to the amount of damage it can do”. I’ve had mails from people who’ve used memory manipulation on my app (to try and edit how much gold they have), and others who have used reverse-engineering tools to peek at the code. When you throw an app out to a few hundred thousand users, that is the sort of thing that will happen. If there is a bug, someone will find it. Personally, it is not the kind of risk I would be comfortable taking with other people’s devices.
One can do pretty awesome stuff with just a limited set of commands such as those suggested in Squiffy, though, so I don’t think that needs to be a big issue, if it is not supported universally.
I can’t say I agree, because I’m not of the opinion that my way is the best. Not that I lack confidence in what I build, but I always like to study what others do - one may often discover some neat tricks or ideas that is a blind spot in one’s own work.
But of course - given that your goals are for a different type of system - it is quite understandable that your interest in this sort of thing is limited. No problem.
I was simply suggesting people to use a common base such as txt2tags which is flexible enough so they could build their alternative syntax using it, and it would also be easier to work on some convergence in the syntaxes if it’s using the same plateform.
In addition to some exports to different systems, I’m also using my own output in html and in pdf.
So, maybe I’m misunderstanding, but isn’t the txt2tags syntax essentially a markup language syntax that can easily be converted to a bunch of other markup languages (really cool implementation, btw)?
Wrt the elements that Ficdown defines, I’d say there’s already not much difference in the core syntax. I’m not sure how one would build more on that, though. Seems like one would have to cut away a lot of txt2tags features that are unnecessary for IF, and then add a bunch of features that I wouldn’t think is really of general interest to the txt2tags use-case (conditionals, “special” conventions, etc). Actually, I’m quite surprised that you have people requesting a random number generator…
Or perhaps I’m missing something. Wouldn’t be the first time.
What would be interesting for me for gamebookformat is to probably replace my own html+js dynamic player thing with some other format, since it is a problem others have already solved so well, and it is not my main focus anyway. But I do not think I need a standard format for that, only some new output-format templates to generate the correct format for that other tool (be it twine or one of the other formats earlier in this thread). There is a big overlap in features of different tools around here, and even though I enjoy adding features and supporting all sorts of things I think my tool will end up better with a more clear focus than what it has now.
Input format requirement for me seems quite different from most other tools. I only want things that can be perfectly rendered in both static formats (to print or play in a dumb ebook reader) and in javascript (browser or app). Allowing the author to insert variables or scripts will make it impossible to do that. For instance my tool requires that if something is to be tracked (eg gold carried by player) it has to be declared inline using tags in a section, in a way that will be visible to the player reading a static version and also make it possible for the javascript to figure out that gold must be tracked (and what its initial value is, if one is given). There can not be any hidden information outside of the text that the player reading the static version will not see. So my quite limited format should be possible to export to any other more dynamic format, but the other way around would likely result in a lot of warnings about unsupported features and author frustration.
EDIT: Re-reading this thread, and looking closer at tools linked from it, has started a lot of re-thinking here. I think gamebookformat is probably doing (or trying to do) way too much. What I really need is a simple tool that handles all the section shuffling/numbering/filtering/exporting stuff that was the original reason for making the tool. There are other tools that do a great job at formatting text to export to different output file-format, so other than just enjoying solving various problems I do not think there is a very good reason for me to mix that into the same tool. Better to have several small tools that each do one thing well.
To me the problem with any kind of scripting is that it makes it impossible for the tool to do real analysis of a story, or stuff like the duplicated static paragraphs discussed earlier in the thread. If I was supporting a common format it would be pure data, not code. Simple markup that says “add 3 gold” or “only.allow this choice if player has the sword” is of course limited, but it gives the tool full control of what goes on. Not the goal of everyone, but it has benefits.
Interesting observations, pelle. Understand where you are coming from.
For my purposes, of course, scripting/variable manipulation is critical - as all of the games I’m building with this engine so far have lots of extraneous elements; maps, a complex role-playing engine, combat modelling, etc. I need to be able to hook into those elements in a secure way. The engine should work fine without those elements, though, which is why I find the idea of trying to standardize interesting. It would mean that the people who I collaborate with and modders could do some basic testing of their scripts on using alternative tools. It would also provide some incentive for me to do some work on breaking out the story parser into its own app/library.
Seems like we all have slightly specialized requirements that are just enough different to make attempts at collaboration difficult, though, so I guess this suggestion will end up the same way as Markdown: each site (system) with its own flavor.
I started TwineQuest (a more powerful platform for Twine plugins) for much the same reasons. Though it didn’t get far before the looming Twine2 was going to obselete any further work I did. It’s a really good idea because it allows the language core to remain simple and flexible but provides a clean via to import other functionality as needed. Also, preserves the ultimate freedom of the author/programmer to build their worlds the way they want.
I prefer that approach to having to work around disabling things an engine insists on doing for me.
I’ve seen some mention of Twine2, and finally found this page describing some of the syntax. Is there any other sites, or is this the official definition of the Twine2 syntax?
Twine 2 looks like it would be a great match for a output-format for gamebookformat, as long as there is a nice multi-platform command-line tool for it. Only thing I don’t see is if they have some kind of automatic handling of collections like inventory that I would need to generate code for collection tags (eg adding an item to inventory or a codeword that should be visible on screen somewhere). Or do every Twine story have to make their own GUI for such things?
Twine has none of these. Every author rolls their own. I actually prefer having a minimal core with optional add-ons. When things like inventory become standard then authors that don’t want them end out jumping through all kinds of hoops.
Like what I see of Twine2; some interesting solutions in there. I don’t like the macro syntax; I’ve used something similar in past iterations on my script engine (using brackets and colons), and I ended up regretting it. The less escape syntax is required, the better. It also contains way more constructs than I’ll ever need (my minimal core is even smaller), but wouldn’t be hard to add support for the basic Twine2 elements as alternatives to those I’m using. Will have to keep an eye on that possibility.
Any idea when Twine2 will be out?
Thinking over what I wrote earlier, I decided that breaking out my Story Parser was probably a good idea regardless. So I did, and built a quick and dirty app framework around it and wrote up Cloak of Darkness. Quite fun. The source file for a cloak of darkness can be seen here.
At the moment, I’m pretty happy with this. The syntax works very well in the majority of the Markdown editors I tested, and it’s much simpler to read and write than my previous attempts. It’s not as compatible with Ficdown as I would like it to be - working with variables that can be strings and numbers and my need for link branching/scripting meant that I chose some alternative conventions in a couple of places - so at the moment it just takes inspiration from it.
Considering adding a “stats” (i.e., display variables) screen, and putting the app out for free on Google Play, since the thing is a pretty capable CYOA engine already. Think I need to create a more elaborate demo game than Cloak of Darkness first, though (alternatively find a suitable story to convert).
Personally, I find the web interface a little worrisome - I know I can download my files, but… yeah. Sticking with what I know better for now (to the extent that I know Twine, which is limited.)
Yep. One of the major reasons why ducked out of Twine dev was the disregard for total transparency on file location. Mind you, I hope to remedy that once RL circumstances allow: probably a local install based on NodeJS complete with file|save.
Technically the actual macros themselves are part of Harlowe (Leon’s storyformat). To the extent they are intended to be core is a bit beyond me. I’d take Leon’s document more for syntax than vocab.
I’m curious. Have you seen this elseif construct on paper/PDF? I’ve seen RPG based ones using tables/switch-case ( if you roll 1-2, go 56; roll 3, go 41; roll 4 or higher go 78) but I don’t think I’ve seen elseif on paper. It only happens on code. I’m curious as to how to properly present such cases on paper (or at least rtf format).
I can put out a new thread. Maybe a few days from now. But basically there’s CYOA competition that requires RTF rich text format gamebooks, and I wonder what kind of choices can there be with if-elseif-else on ChoiceIF because I haven’t seen any in print format.
The boardgame Ambush! is built around a paragraph booklet that is just like a gamebook (i.e. choice-based i-f, printed, with a paper map and cardboard counters). It does have some pretty complex if-else-trees in some paragraphs, sometimes spread out over multiple paragraphs. So you get “If an active soldier has LOS to hex B-4, see 23, otherwise if active soldier has LOS to C-17 see 33, otherwise if Sighting 3 has occurred see 932, otherwise see 52” and then some of those paragraphs can contain their own if-else-if-else. I wrote a tool once to try to make my own missions and large part of that was to try to make it easier to describe different conditions and links and then have the tool automatically combine it into as minimal if-else-trees as possible (DIY Ambush! Missions | Ambush!). Luckily typical gamebooks or choice-based i-f in general I have seen do not end up with such complex decision-trees.
Looks like a great candidate for computer game implementation. Doing something like that, I gave up really quickly and decided to just design the process using playing cards, shuffled and played one after another. Fight, heal, run, raise alarms, and other NPC acts (such as conversation tree) are all decided by random card.
Rather interesting because if all the cards available are fighting cards, then it’s shoot first, ask questions later. Whereas if all cards are conversation, then it’s bluffing time!
Even so, it’s rather complex for average player. No problem for me to do solo, but that’s about it.
