Request for ideas and pre-introducing GrueLang

[I moved this post from ‘other authoring systems’ because this thing doesn’t actually exist yet, I figured it was a bit disingenuous]

Hello!

I’ve been playing with various IF authoring tools and I’ve found Inform 7 to be really fun to use. However, as a programmer I found it somewhat confusing to use primarily how to organize the rules in a structured manner. Inform 7 is not open source so it is not really possible to experiment with possible alternative ways of doing this organization. To try to address what I perceive as possible points for improvement I’ve started a new project to implement an IF authoring system. I’ve called the project ‘GrueLang’ so really, the hard part is over, it has a name :wink:

It has a website here: gruelang.org currently there is only a wiki here with some preliminary ideas. I’m announcing the project this early primarily to solicit some help with the design of the initial concepts.

I’m not asking for programming help, this isn’t one of those ‘I have a half assed idea please build it for me’ type things. This is a ‘I have a half assed idea can someone help me fully-ass it so I can build it.’

If you want to have access to the wiki please shoot me an email, it’s noted on the front page. But I’m also very interested in just random ideas you may have, what would your ideal IF authoring system look like?

Please place a comment on this post!

Thanks you for your time!

[edit: I just noticed that on the mobile version of the website it’s not exactly clear that it is possible to press the ‘plus’ sign in the top-left to get access to the wiki menu. I’ve added a link directly to the ‘development’ page from the start page. Sorry if anyone was confused by this.]

So far I’ve received the following feedback through various channels:

  • Good tooling support, optional IDE and a package manager
  • Extension system
  • Maybe not include a conversation system because they all suck :slight_smile:

I’ve been looking into several different ways of rule precedence, this appears to be the hardest initial thing to get right besides the syntax. Rules that are ‘more specific’ need to override rules that are less so, but defining what actually constitutes more specific in a manner intuitive to the rule writer isn’t trivial. Inform 7 basically forces you to setup an explicit ordering in rulebooks which makes it easy to lose track of what rules apply where, especially if the rulebooks in question are in extensions or the base library. I’m hoping to do better than that, but this seems like a non-trivial problem.

About rule ordering: have you read zarf’s notes toward a purely rule-based language? It seems like a good resource.

One thing that I would desire about rule-ordering would be more ability to explicitly specify how the rules are to be ordered. In I7 what happens is that, after the compiler puts everything in the default order, it goes through the “listed before/after” declarations and moves around each relevant rule in turn–which can lead to unexpected results, where one of the declarations winds up getting violated in the end. See discussion here and here and here.

If I were designing a rule-based system from scratch–or if someone had invited me to say “Hey, give me your half-assed ideas and I’ll think about whether I want to build them”–I think I’d try to give the ability to specify rule ordering as an explicit list. “The order of rules in the enacting rulebook is {my first rule, my second rule, my third rule},” like that. I’m guessing that to make this work you’d have to have the compiler start with the order of the explicitly specified rules and then order the rest of the rules in the rulebook by specificity.

But that’s not what I really wanted to ask you for! I wanted to say, if I were getting someone to build a language from me for scratch, I’d want this:

  1. Flexible parser routines. Like, something where the default parser routine was nice and Informy, but where I could also write a grammar line as a function in the language. Something like:

To understand "Point [something] at [string]: check to see whether the lights are on; is the noun pointable? if not make no decision; evaluate string to see whether it's part of the description of an object that's visible; if so, understand the action as pointing the noun at the object we found; if not, make no decision.

  1. Disambiguation that’s easier to deal with and modify. These first two are the big ones.

  2. Pie-in-the-sky? Full modularity. Have something where the action model can interact with stuff about rooms, but if I want to write a game that doesn’t have rooms in its world model, I can just not include the functions that specify rooms and things will be OK. Or I can substitute a different library. (This is very optional–if the system makes me use rooms, I can put everything in one room and then ignore it.)

  3. Slightly less pie-in-the-sky modularity: Something that is modular enough that it can smoothly accept either parser or hyperlink inputs or something else even, without having to change the inner workings of whatever else is going on. zarf is doing something like this with Unified Glulx Input, but if we’re designing a language from the ground up we might want to build this in from the beginning.

Thanks for listening!

Thank you for your reply!

A large part of my desire to use a rule-based system comes from that site. I’ve also emailed Zarf to ask if he has ever gotten any further with his research, perhaps I’m going over well trodden ground here :slight_smile:

I’ve been toying with that idea also, but I’m a little worried it will become even more complicated to manage for an author. Rules can come from multiple sources, extensions, base library, game file. Creating a single unified list of what rule applies where in any situation may be difficult as it may not be immediately apparent what rules even COULD apply in any situation.

This sounds interesting, could you write a slightly more elaborate example to make sure I understand when you’d want to use this facility? Maybe a mock room with this in it and an expected interaction? I think I understand your meaning but I’m not entirely sure how to generalize it.

This is indeed the main problem. I’m trying some concept I’m now calling ‘scopes’ but I’m not sure how far they’ll stretch. The very early prototype syntax is here: https://gruelang.org/language_ideas#scoping

In a purely rule-based system this should be a default feature. If we do things right :slight_smile:

This sounds like an interesting idea also. I will give this some thought. The decoupling isn’t terribly difficult, and if the language has compilers for things other than the z-machine and gluxl it may even be relatively easy to add.

Thank you very much for your participation!

I was having a bit of a brainstorm on how to deal with rule precedence and I’ve come up with something. I hope some of you have a moment to look at the proposal and bash on it a bit. I seems to handle all cases that I can think of, this almost certainly means I’m missing a lot of cases in my consideration :slight_smile:

The proposal is on the wiki

Thank you very much for your time.

[edit: I’ve added an ‘always’ specifier as an escape hatch in the system]

Sure! I think that thinking about this I may have changed my specifications a bit. So here’s one example. The pseudocode looks something like this:

[code]A thing can be variably-described.
Understand “[a piece of the appearance of the item described]” as a variably-described thing.

To decide whether (string - a snippet) is a piece of the appearance of (prop - a thing):
repeat with index running from 1 to the number of words in the string:
if the initial appearance of the prop does not include word number index of the string and word number index of the string is not listed in the List of Inconsequential Words:
no;
yes. [this basically gives you: if every word in the string can be found in the initial appearance of the prop or the List of Inconsequential Words, which we write to include things like “a, an, the, that, of” then yes; otherwise no][/code]

And if you had something like this:

The rock is a privately-named thing in the hallway. It is variably-described. The description of the rock is "[if the player carries the lit lamp]There is a rock gleaming on the floor[otherwise]Something glints on the floor."

And here’s how it goes:

There would be ways to implement this particular example in Inform with conditional Understand statements, but it’d be nice to be able to write a general routine that let you look up a description and match words to it. Or in general, to be able to make parse tokens that ran routines to see if things matched them. (And to be able not to write parse tokens that did that if you wanted to–this would probably have the potential to eat up huge amounts of processing power if not done carefully.)

Here’s another kind of thing that might be nice:

Understand "fix [X - a thing] with [Y - a thing]" as repairing it with when Y can fix X. Understand "fix [X - a thing] with [Y - a thing]" as immobilizing when Y can immobilize X.

where “when Y can fix X” and “when Y can immobilize X” call user-defined routines to decide this. (Or even just calls a simplified set of relationships.) So the parser would have to evaluate possible values for X and Y, and then call the routine to see which of these lines matched, if either.

Thanks again for listening! I realize that these are, well, half-assed ideas that I’m asking someone else to build, and that may be pretty difficult to implement.

Honestly, the killer feature that would get me to make a parser game for something other than I7 would be the ability to natively generate a browser-based playable version of the game, and have true formatting control over the output – eg being able to specify which CSS classes to apply to a line of output, or even what element to wrap it in.

So I guess some kind of abstraction for input and output, as suggested earlier, and then a way of configuring extra attributes on individual outputs? You still want to be able to compile your game for glulx or z-machine I imagine, right?

I actually don’t care about that, if I can get a version that’s just a static website using pure javascript to run entirely on the browser. In fact, because of the nature of Glulx, compiling to Glulx and having proper styling control over the output are incompatible goals (until, of course, Glulx implements those features in the future).

Basically, I want to be able to write a parser game and have the same control over how it looks that I have with an Undum story.

Agreed with Sequitur. The things I like about z-machine/glulx are that they’re fairly cross-platform and can be played in browsers (which is another form of cross-platformity, I guess). But the cross-platform support is kind of meh–there aren’t any completely satisfactory Mac glulx interpreters right now–and web play doesn’t support every feature of glulx.

And I think some of the stuff I’d like to see would also be difficult to implement in z/glulx. zarf has said that some of the fragility of the I7 parser is partly down to the virtual machine (can’t find the thread now).

If you can output a browser page that can be downloaded and run offline, and that allows for save files, I’d be happy.

What is unsatisfying about the MacOS X gluxle VM that is so bad that a webpage is better? I’m not arguing that just sounds very, very bad indeed :slight_smile:

Well, web play is cross-platform. Is there really a platform that has a Glulx interpreter but not a modern web browser, that people actually use (as in, not as a retrocomputing curiosity)?

I think it’s less whether there are systems with interpreters and not browsers, and more how you can optimize an interpreter for the specific platform (e.g. compare the interface in iFrotz for iOS to Gargoyle for Windows). You can’t custom-tailor a website for each platform in the same way.

Maybe you don’t like its language if you like I7, but ngPAWS does exactly what you want.

Build the game, expand the default layout with whichever new HTML elements you want, apply css, apply css classes to output. All that is possible. It generates a html+javascript static game that can be played even offline.

I haven’t tried Uldum but you can build a game the same way you do with Squiffy or Twine, but parser based.

And if it’s not enough, ngPAWS allow you to build extensions in javascript.

I get your point, but there’s something else you’ll want to consider: web access.

Simply put, not everyone has web access at all times (even though it often seems that way these days!). I suppose it has a lot to do with which country you’re in, which services you can get, and how pricy they are. Take me, for instance - my iPod Touch is where I do my main IFfing these days, and I only have internet on it when I’m home and can access my own WiFi. Being able to afford that little device in the first place was a struggle. Internet all the time? That’s a luxury I really don’t need and can’t afford.

Also, the points brought up before are very, very true, about platform tailoring. When I play a game in iFrotz, I can expect by default a very, very smooth experience. Web-browser games (which I have very little time for playing at home, so actual online play is out - that’s why I always insist on finding a downloadable copy of web-based games; if I don’t find one, I just won’t have the time to play it) are a hazardous bunch, where I have little to no control over the output that would make all the difference. Mostly it’s text size. The one web browser I could find for the iOS which allows me to store and play games offline is Mercury, and I can only zoom in; I can’t increase the font type. In some games that’s ok; in others it’s a strain.

So there’s more than retro-gaming curiosity. It really is much better, for some people, to go with your average Glulx-based game than your average web-browser game.

EDIT - Also, hey, customisation. Any interpreter - Gargoyle, Glulx, iFrotz - allows you to configure background colour, foreground colour, text size, font. There are basic necessities for anything involving text for long periods of time.

An online game will either force the player to play as-is (and that can sometimes be very off-putting, depending on the defaults), or force the player to actually mess with the preferences for their browser to get that one game looking right - and that’s a step I doubt many players are willing to take.

A third option, of course, is for the game to allow such customisation itself. The engine that allows that will have my kudos and my blessing.

Actually, come to think of it, the Tads 3 web wrapper does allow it. Well, kudos and blessings to it.

Zoom isn’t maintained and has some instabilities and flakiness (I’m not sure but I think it doesn’t handle external files well–at least I recall being unable to start Sparkle a second time). Gargoyle I think has gotten a bit behind on maintenance and I find the way it handles scrollback incredibly frustrating–when I scroll up and type something it takes an unconscionably long time to snap back to the command line and start echoing the things I’m typing. Part of this is due to my computer being flaky in some ways, probably, but I don’t have this problem in web terps–I can just scroll up and down. (I think this may be that Gargoyle does some kind of infinite scrolling thing while Parchment cuts off the scrollback past a certain point, but Gargoyle just doesn’t work well for me.) Also Gargoyle on the Mac doesn’t support some recent features IIRC. (Something to do with sound? I think Delphina’s House had to have a special Gargoyle workaround for something.)

And those are all the Mac interpreters I know of! So if I have a choice of formats I’d rather play in my browser if it’s feasible, not that browser play supports every feature either.

Peter–when I talked about a webpage I meant a webpage that could be downloaded and played offline if necessary. Not sure how easy it is to run pages offline in mobile browsers. But I think that’s still the simplest solution for supporting a reasonable number of platforms.

But that sort of support will, unfortunately, be limited. We know (and I certainly went on about it) that it’s much, much easier for an interpreter to provide specific options, like font and text size customisation. It is unrealistic to expect a webpage game to offer that same support, partly because it doesn’t have a specific engine that does it for the author but mostly because webpage-game-authors, from what I’ve seen, delight in tweaking it to the smallest detail so that it looks exactly the way they want it to.

Which is a good thing! The not-so-good thing is that it may not look that way in a different device, and they’re not terribly motivated to either accomodate the smaller devices or to include a framework to allow the player proper customisation. And let’s be honest, the author that DOES do this is going above and beyond, you can hardly fault them.

And I’m been implicitly talking about Undum, Twine, and all the non-parser games. If we add parser games into the mix… well, it’s laborious to play in my iOS, and let’s leave it at that, whereas in iFrotz I get a great experience.

So, my point is, web-based will most likely be the simples solution, yes, but also the one that will cut down the gaming experience to its bare bones, and in some devices that will not be preferable. Again, I bring up Tads 3 as an example - you can provide BOTH versions of your game, in t3 and webpage form (it’s apparently not an entirely trivial process, but seems reasonably easy for 90% of the Tads games that might be made), so you have a choice to play it with an interpreter and all its niceties, if you have one, or webpage, if you don’t.

BTW, something else to mull over. The technology isn’t the same everywhere, and the most complex that a web-based game is - “Interactive Fiction Fund Creations” is showcasing a twine game wrapped in Unity3D, or something similar - the lesser the chance that it’ll run on a mobile device. So “web = immediate and easy cross-platform” isn’t automatically true.

EDIT - The only reason that I keep talking about T3 is that, as I understand, the Glulxe support in Parchment/Quixe is still a way away from what it could be (Ryan Veeder’s new dinosaur game plays excruciatingly slow online for me). But I’m sure that’s a matter of time, and when that’s sorted, then we’ll have two major terps with the ability to (relatively) easily export webpage versions of your game, to be played as cross-platform as possible. Heh, you could even talk the I7 dev team to, by default, always release the game along with an interpreter, so that by default every new game will exist in webpage and raw file form.

EDIT 2 - Let me try to make an active contribution to the original point of this thread!

[b]TMM, I would say that if your system exported to offline-playable webpages it’d be much appreciated, but it’d be even better if it allowed for some customisation of said webpages. Font and background colour, font type and text size - that would go a long, long way!

And for parser games, take into account the possible small size of the device, ok?[/b]

EDIT 3 - At the risk of being so direct that I’m being rude, I’d say that if there’s a problem with the mac interpreters, then the problem is with the mac interpreters, not with the format or the platform or even the OS. Sort out the long-standing 'terp problems and hey presto. I’m pretty much a layman here, I know, but it strikes me as very odd that, given that there’s a considerable amount of people here running Macs, no one actually buckles down and tries to tackle the Mac terp issue. Parchment and Glulxe are actively being bettered, and so are the windows terps (WinGit, WinGlulxe and WinFrotz still see updates). Considerable energy is being put into iOS frontends for games as apps. All of this is downright awesome. But why then aren’t the mac terps finally targeted and set right, to the point where they are at least stable? Wouldn’t it be better, even, to code up a new Mac terp?

I know this isn’t easy, and I know there are very many shiny and attractive other projects to be working on, but this has been a sore issue since I found this community. Doesn’t it need serious tackling?

If I understand everyone’s point of view correctly can I summarize the requirements like this?

  • Offline play
  • Developer customization of output text
  • User customization of output text
  • Web based play (and customization of generated html/css classes)

Is this a correct summation of all of your desires?

As far as I’m concerned, it’s spot on.

I don’t know that it has to generate web pages. It may be just optional. But I would imagine that, if the webpage route were to be taken, it would be hugely easier for you just to stick to it rather than try to arrange for any other output as well.

ngPaws is a good example of the whole thing, since it was brought up. It lacks the necessary customizations on the user-end for me to realistically play it offline on my iOS (and I’ve tried). I mention this because, otherwise, ngPaws does a lot of what’s been mentioned.

I’m considering that maybe a type of language-specific markup that can then be further customized for specific backends. With a little care of the author supporting multiple methods of play would be possible. It’s important to me that it is easy for people to make games that are playable by people with disabilities or, indeed, just cheap hardware. IF really should be playable by anyone.