In some good development news, I already enacted Peter Piers’s idea that you can switch between the parser and the CYOA mode. I’m saying I’ve put this in technically so that the two layers now coexist without trampling on each other’s code or logic, not that it magically makes both layers integrated. The author has to do that
In parser mode, if you’re in a room and turn on CYOA, you go that room’s base node if world is on, and if it’s off, you need to supply the logic about which node it goes to.
In CYOA mode, if you’re in a room and turn on the parser, the player continues in the current location with the parser. If you switch to the parser and the world model is off, the player will be in the token ‘default’ room - but with the parser on. Authors can do with that mechanism what they wish.
And of course you don’t even necessarily have to have the layers overlapping. You can now use the extension to add a CYOA stretch to a parser game, or make a game with stretches of both, or be really avant and allow the player to switch back and forth at will. (Actually that seems to offer up some entertaining/bizarre possibilities.)
One wonders what Ferrous Ring would have looked like if the author had found this extension - and its newfound “Now it’s parser! Now it’s CYOA!” abilities.
The only thing that comes to mind for this is…does it have to be single keypresses? If a game is using that many links on the same screen, could the player type multiple digits/characters, then press enter?
The game switching links on/off will allow the game to provide a way for the player to do so. In mixed mode I would like that there are links (which you can use) but you can also use keys. If mixed mode was default you wouldn’t need to ask the player if they want keys (only) or links (only).
Invisible keys would be if the game instructed the player on the keys beforehand (e.g. use the number of the choice - in the example you could press 1, 2 or 3) then no label is necessary:
[code]Look at the map.
Enter the dark cave.
Wait until dawn.[/code]
Can deactivated links be a different colour?
Do you think it’s bad if a command suited to one room (from scrollback) fails in another room? The player can pick and choose appropriate general links like “Look”.
If you wanted your whole scene in Undum-style you could just have a switch to make all the links eternal.
One extension doesn’t have to do everything. Somebody else could make an Undum-style extension.
Hi Zarf. Yes, I already tried the new UGI and UNDO mechanism. Once I realised when the check undo rule was running in the flow of things, I got it going fine. I tested it both for both char-input (I added a check undo rule for that) and line-input. So it has allowed me to remove an I6 workaround/hack.
This strikes me as a really good solution overall, except for one thing which is that it would put key labels on in-prose hyperlinks by default. The advantage of having hyperlinks in the prose is their graceful integration with the prose. I will add this to the more thought pile.
Ah, I see what you’re saying now.
This seems doable. I think the result will be anti-intuitive in cases where players have to count prose hyperlinks as well as menu choices (which is where the numbering function has to be able to go for all of the flexibilities we’re coming up with to co-exist) but then the solution to that is the author just shouldn’t mix invisible labels AND in-prose AND menu links all in the same node.
I don’t think they can.
Well, I’m coming up with a new way of having the author list choices, and actually I think what you’re suggesting will work by default with it. Room-specific old choices will stay dead. But there will be a new choice type which is ‘general purpose’ or something similar. This is kind of like creating an action in the parser which a player could type anywhere. So you can drop in standard things like the directions, checking inventory, etc. And these will work even if clicked from an old position. I can’t mark them out as such on the display (except on first printing, but I don’t think it helps much to indicate that ‘inventory’ is a ‘special’ eternal command, etc.) because Inform cannot transform any text that’s already been printed. But I reckon I can have them continue to to work.
Just tried it. Works nicely on my chrome browser. Worked less nicely with my iPod. (my iPod doesn’t have a key pad, and didn’t seem to know that it should bring up the onscreen keypad, awaiting text).
I liked that the CYOA node stage “list choices” appears to be auto-numbering. I would like to be able to add choices from a stack, choices which were pushed to the stack by other events. I presume that should not be too difficult to implement.
I would be excited to try using this, if you are looking for other programmers to play with it.
Re: the iPod, this is sort of the only iOS area I don’t know about. I know Peter keeps talking about playing things on his iPod, I just wasn’t sure what kind of interface people are dealing with on there.
So when you say you’re running it on your iPod, how are you doing this? By visiting the online version, which runs Quixe? Or by putting the file into something else (EG Frotz?) And when it runs, would you normally expect the same interface as on an iPad or iPhone? IE The ability to touch links with your finger, and/or to type from the virtual keyboard when letters are expected?
The ultimate version will allow the user to say ‘I want key labels and hyperlinks for all choices’ (as well as keys only, or hyperlinks only, etc.) which I hope will cover everyone and all devices. This will be a question at boot time if the author didn’t choose the ‘all of everything’ mode as the default.
The choice scheme at the moment could be summarised like this:
A node can have choices that are only relevant to that node
A node can also have ‘general actions’ - these choices run the same rule/code no matter where they appear. So you could have a general ‘get’ command, and only add it to rooms where it may be relevant.
There are hotkey options that appear on every single move. This is primarily intended for save/quit etc., but you can decide what to do with it. So you could implement ‘inventory’ as this kind of option. You can also add or subtract the basic functions from a game (save, restore, quit, credits, transcript, undo). If keys are turned off or unavailable, hotkey options appear as hyperlinks
Any link can take the form of an image if you want it to, though additional image formatting will be pretty nonexistent. An image appears on a new line and the prose continues on the line after that. So this isn’t useful for creating a real GUI in any way, but is fine for dropping in vertical image lists, small single images, or for presenting one big image and having it be a link.
All of the above are already underway, but I’m also thinking of creating an ‘every turn’ equivalent mechanism for nodes. Basically, you could put general actions that you mostly want to have appear in every relevant room (but not have hotkeys assigned to 'em) in one place, and the game would check for them / add them to every node without you having to mention them in that node.
In terms of a stack, I’m not 100% sure how you intend to use it, but I figure that with the above mechanisms in place, it would be easy to implement.
If you’re pulling in options from a stack, presumably they’re options that might be useable in more than one location, so they would all be general actions. These are named as texts - eg “inventory” would identify the inventory general action. So you could make a table, drop the action names in it and there’s a stack you could pull from or push to at relevant moments.
Let me know if what you had in mind is something more specific or complicated. Thanks!
-Wade
PS The auto-numbering is already much better than in the demo. You no longer have to count choices; you get to stick a number on each choice when you create it. And the numbers you use yourself don’t have to be adjacent or anything because they’re labels. So if you define something with label 1, you just check for choice 1 at the other end. The onscreen numbering and key-labelling is all totally automatic now and unrelated to your internal labelling.
For the iPod I recommend you download it and use iFrotz.
I’m sure that you’re playing it online in your iPod… yeah, don’t do that. Web browsers are not smart enough to handle the keyboard input necessary elegantly. Whereas iFrotz is OPTIMISED for it. Point your iPod to the page and go for the “story file” option, it will open in iFrotz.
For me, it worked a treat.
EDIT - Wade, for maximum comfort and ease of use, any game done with this framework that is supposed to work online in iPods (and possibly similar devices) would do well to use only hyperlinks, which are easily clicked on. You may possibly add this note to the extension so that developers are aware. Using keypresses as input works a treat in iFrotz, but only in iFrotz. Possibly in larger devices this isn’t an issue, not if the keyboard can be up at all times, but in smaller devices that space is precious and you want to keep the keyboard out as long as you can.
Yeah, my thinking is - if the author specifies that everything shall be hyperlinked AND everything will be key-labelled, as their default presentation, I don’t need to ask the player anything at boot time, because that covers everyone and everything - desktop, portable, screen reader, etc.
If the author default is not that, then I will ask a question or two (I will try to compact the logic for this down). And then even if people blunder the question, they can change to the other modes from the options menu. But basically the extension now enforces the point that a player can tell it how to give them the choices.
I suppose that an author can always start the game with a disclaimer, if necessary, asking that the defaults are not overriden, in case the author was going for something fancy.
The Hypertext links should work fine on my iPod. Your “Dance” hypertext worked.
Thanks to Peter for recommending the iFrotz ap for other games.
The idea I had in mind for the stack was related to a “remember” command as you see in some z-code games. Memories are pushed out in response to certain in-game events. The memories can be accessed later. However I don’t want the player to accumulate a long menu of memories that they haven’t read yet. Serve up only one each turn (each node) after the earlier memories have been reviewed. Based on what you’ve already written about your extension, I can’t imagine any problems in doing this.
