I’m creating a text adventure in Java, because I want to get a feel for how text parsers are put together and really how the whole thing works on a deeper level than I might get in using a tool that’s made for IF.
So far it’s quite a challenge, but it’s one I’m enjoying. Plus when I’m done, it’ll run on basically anything without the need for a specialized interpreter, which is cool.
Anybody else here tried making one “from scratch?”
A few people per year try their hand at making brand new parser development system from scratch and often end up deciding not to re-invent the wheel. Just be aware:
That said, so long as you’re doing it for yourself or for your own education or to achieve a specific and unique type of game you can’t make with existing tech, more power to you!
The most successful new-parser development thing I’m aware of is Dialog.
Choice engines might be a tad easier - there are many more uniquely flavored ones, but sadly some of the coolest are now defunct: Varytale, Storynexus, (Is anyone using Undum or its flavors still?) and there are a ton of webkit-ish “make your own story!!!111” websites that some people really like.
Twine and Ink are pretty successful, Texture is really cool, and I thought a newer one called Inquisitor looked quite interesting. Robin Johnson made his own proprietary system for Detectiveland (among others) that is a parser-like choice hybrid.
I’ve experimented with parser design and development, primarily with Python. As my aim was to achieve the same level of power and flexibility present in Infocom/Inform-based games, I invariably dipped into the Inform standard library to try and understand how it performed its magic.
While my Python projects have generally been put to one side, the whole process was educational and certainly helped me understand the power of the Inform parser.
You’re going to have a hard time. Languages specifically for IF were created because people tried more general-purpose languages and got frustrated. You might make it easier by writing a library to ease low-level things.
It worked with MDL because that language is well-suited for things that IF requires.
I’m doing primarily in order to better understand how such games work. It’s not going to be an engine intended for others to use (though I might make the source code free so if they want to use it, that’s fine); I’m doing it to learn Java better and to understand how parsers work on the most fundamental level.
That said, this is kind of what I want to avoid. I’m interested in what can be done to make them stand out visually without being too distracting from the text, in much the way that a lot of choice-based games have managed to do. Imagine if there was a background around the text that changed subtly when you entered a haunted house, or if night fell. Maybe soft ambient music that takes on a sinister tone after you read an incantation. And so on.
If I wanted to make a choice game, I would almost certainly just use Ink. But a nice thing about Ink is that you can plug it into whatever you want, and add visuals, movement, etc., in a way you can’t (as far as I know) with Inform and the like. That, along with the lack of a need for people to use an interpreter if I do, is another reason I want to make my own.
I keep thinking, “What would Infocom do if they were around today?” and I don’t think the answer is make games that you basically have to run in an emulator, that look nearly identical to what they made in 1982. And as much as I love IF, parser-based stuff is way behind choice-based stuff in the visual department (with a couple exceptions).
None of this is a dig at IF that already exists, at all. Galatea and Blue Lacuna are not just among my favorite interactive fiction, but among my favorite games and my favorite pieces of literature period.
Any advice based on your own experience?
Yeah, I may well have a rough time of it. I just feel like choice-based engines give developers a lot more freedom these days. Like there’s a Unity plugin for Ink. To my knowledge there’s nothing like that for any of the big parser game languages like Inform or TADS.
So it seems like if I’m going to eventually want to make something that feels in some ways like Sorcery, or like a text-based RPG in which the player inputs commands, or anything that has background music and so on, I’ll probably have to roll my own.
If I’m mistaken, and some language exists for parser-based games which can also be easily incorporated into a larger game like that, please do let me know. I’d love to save the time.
You might want to look at the posted notes and slides from Graham Nelson’s I7 talk if you have not.
Why not package your game with an interpreter extended to do what you want? This seems like a lot less work than making everything from scratch. As an example, Glulx has the gestalt instruction exactly for this purpose, see https://eblong.com/zarf/glulx/glulx-spec_2.html#s.18.
I’m creating a text adventure in Java, because I want to get a feel for how text parsers are put together and really how the whole thing works on a deeper level than I might get in using a tool that’s made for IF.
You’ll get a much better idea of how parsers work by writing in a language specialised for a parser. Or at least by reading the documentation for one or two first.
I speak from experience here - I made my own parser engine in Javascript. There was a reason for it to exist at the time, since it was before Inform games were easy to put on the web, but it really didn’t teach me anything and made games that were limited in capability and hard to maintain. I made it behave like the IF games I knew about and it didn’t teach me anything about how parsers work.
Years later, I read Infocom’s internal ZIL manual and some other stuff, and learned how these things should actually work. Then I wrote another parser-like engine, which did something a bit new, and won IFComp with a game in it. I probably won’t go back to my first, bad parser again.
If you want to learn about parsers, write in I7 or I6 or Tads or ZIL. If you want a fun programming experience, do the same - all the challenge is there in the complexity of your game itself without having to write the parser as well. If you want to write a game engine, make it do something that hasn’t been done well already.
That’s my advice; if I’d heard it from someone else when I first got into IF, I’d have ignored it (and I’m pretty sure I did.) Good luck!
Oh, that really is exciting! Hmm.
That might be a better idea. Basically, I think there should be more games that at least aesthetically take an approach like CYPHER (music, the occasional sound effect, maybe a visual representation of one’s inventory; it would really depend on the game), and I’m trying to figure out the best way to do something like that myself. Of course, if I can do that while coding (at least much of) the gameplay itself in Inform, I’d love to do so.
(Responding to your whole post but didn’t want to quote the whole thing.)
You’re probably right, honestly. I’m really interested in interactive fiction, computer-generated or mediated storytelling, and even the possibilities of procedural storytelling (imagine a game where you have to rescue hostages, but the stakes are “real” in that, if you fail, you don’t get to reload the same case with the same hostage and try again).
I’m also interested in making IF more aesthetically interesting. I probably dove in at the wrong end, and could be learning about IF by creating it in a language made for it while I learn about how interpreters interface with these languages. Now that I think about it, I guess making the Inform version of the Unity plugin for Ink (or something like that) would be more useful, and probably less of a headache, than writing my own parser, and at the end, I’d be able to write my game in the easier-to-use language made for it.
Now I just need to read more about how interpreters work. Any further advice going forward would be appreciated.
I believe that’s why I’m partial to Axma Story Maker. I used to be hardcore parser, but Axma takes the player UI out of the author’s hands and does it automatically very well (including automatic configuration for mobile) with saves and audio and text size controls built in - at the expense of a bit of flexibility. The default output looks much better than the default output of Harlowe Twine though, and it’s very friendly with music and imagery. I know Twine will do all that, but I’m not good with CSS technical design. There’s also a new JS version of Axma that completely eludes me, but is capable of some incredible magic if you know JavaScript.
Let me join the chorus of people not wanting to dissuade you, but… concerning specifically the aspects of styling and multimedia and general-purpose extensibility, I’d like to point out Juhana Leinonen’s Vorple, which lets you use CSS and Javascript from within Inform.
Here’s a thread with a cool demo by @mulehollandaise (Hugo Labrande).
Vorple is also cross-platform, in the sense of being accessible via web browsers from various platforms. As far as I know, you normally need to run it from a server, so you could put it up on itch.io, like Hugo did, for example.
If you’d like to package it as a desktop application, you could check out this project by @Natrium729, which bundles Electron and Vorple.
So, as far as I can tell, this is literally exactly what I want. Thank you so much! Especially for mentioning the project that includes Electron together with Vorple.
Edit: Annnd Inform7.com is down so I can’t get Inform at the moment. lol
Yeah, it’s sort of the “do you really want to spend half a year of free time on research and $1000 on power tools in order to build your own coffee table when you can buy one right now already correctly-made at Ikea for $60?” question - but some people do want to do that.
The rewrite that Inform is undergoing may invalidate some of this reply, but here are my views:
Inform7’s standard rules are the de facto standard for the classic form of IF. You definitely need to give them a read.
Inform7 is around 20 years old and it’s evolved over time. That is, there were incremental changes made in response to changing environmental factors over the past two decades.
Consider Vorple and Parchment. They exist because there was a niche for running Z-Machine code in a web browser. They solve an important issue and bring much happiness to the world, but you now have one virtual machine (Z-Machine) running on top of another (web browser) due to the evolutionary approach.
Some people will tell you not to re-invent the wheel, but while evolution has made many wondrous creatures, it’s never evolved the wheel. There is value in inventing entirely new systems that cast aside outdated constraints.
Myself, I’m working on a JavaScript system that attempts to do something new in the world of parser IF. Will it be a success or a failure? I don’t know, but I’m having a lot of fun doing it and writing a parser really did deepen my understanding of comp sci. That’s not a waste of time.
As the official Person Who Lets Emily Short Know When Someone Mentions On This Here Forum That The Website Is Down, I have let Emily Short know that someone has mentioned on this here forum that the website is down.
The OS X version of Inform is available on the App Store right now–maybe other versions of the development environment are available on other platforms.
The latest versions of the Windows and OSX builds are available here: https://ifarchive.org/indexes/if-archive/infocom/compilers/inform7/executables/
That’s quite a title! And good idea. I’ll look ar–
Woohoo! Thanks.
There are many good reasons to write your own game parser, for example;
For example (3), it’s possible to write a game parser in yacc/bison. This is interesting because you can build on the idea and turn the game parser into a programming language (since bison grammars are designed for that) and make the game language the same to play as it is to write.
For java, there’s Antlr instead of bison.
on (4), there are ways to build a better game parser than currently exists. I have some theory on this, using Term Rewriting Systems. Basically the idea is to construct a set of grammar rules that “rewrite” the input into the output. The same sort of approach can be applied to solving logic problems and symbolic algebra.
The latter approach is a stunningly elegant solution, where instead of a tangle of recursive phrase groups, you have a peer-level “working set” of transforms. The trick is to ensure Confluence which is done by rule set completion. Ambiguity falls out as branches and resolution of context works to prune those branches. Ideally the unique branch remaining is the “parse”.