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 
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
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?
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.
That is something that may most probably be solved with a simple css using media queries, or maybe a pure responsive css style. Sadly it’s allways my last priority cause of my personal dislike for playing IF in a mobile phone (too small for my patience). I’ll have a look at that anyway, it’s not what I like, it should be what player like 
Correctly-designed web pages should look fine on both desktop and mobile, and they should respond adequately to changing the font size (usually because all sizes should be specified in vws or rems). Prospero for example fulfils those requirements, though it wasn’t targeted at devices with extremely small screens – the baseline I use is a first-gen Moto G, which is a lower end device with a small screen.
You can’t really tailor a web interface to specific devices reliably, but you can tailor it to specific screen sizes (and to touch versus desktop interfaces), which should be enough.
Hear hear. But again, the more customization the actual game provides, the better. Because, well, you’d think that all web browsers today allow you to change font size, right? But the browser I have to use to play them on my small iOS device doesn’t, not for web pages that I’m opening from local storage. Just goes to show you can’t anything for granted!
I do think that you’ll generally get the best experience with a tool made to play IF compared to a webpage, although webpage does have certain benefits as well.