@lft can give a more authoritative answer on just what he means when he says “vintage hardware” and what the chance of a C64 Å-machine is, but from early experiments I can say you probably do not want to use Dialog if your target is an unaccelerated Commodore 64. Please see this .z5 build of my Pick Up the Phone Booth and Die port for benchmarking, in a game in which basically nothing at all happens and there’s almost nothing to do. (It’s slow.)
Edit: I’ll update my speculation with this quote from the Aa-Machine doc, where lft does in fact say something about the prospect of 8-bit interpreters and the speed being better than of Z-Machine output:
…stories compiled for the Å-machine look better on the web, and are smaller and potentially faster on vintage hardware (the latter claim is unsubstantiated at the moment, but it has been an important design principle).
…the Å-machine is designed to run the same stories on everything from 8-bit systems to modern web browsers
Inform 5/6 games vary. I suspect it has a lot to do with how many libraries are salted into the codebase. Anecdotally, the earlier Inform 5/6 games (before there were lots of support libraries) seemed to run pretty well.
(Or, if you don’t mind leaving the Z-Machine behind, look into some of the vintage multi-platform authoring tools that are enjoying their own renaissance…)
It’s fun watching the evolution of standards and user experience/expectations.
Forty years ago, BRIEF-type modes were the standard because connections were slow, computers were slow, I/O was slow, and Actual Printer Terminals were both slow and, y’know, eating up paper every time the small brick building had to be described again.
Today, Dialog is 100% VERBOSE 100% of the time because of course you display all the text all the time in 2019.
(understand command [verbose])
(understand [brief/superbrief] as [verbose])
(perform [verbose])
The verbosity level of this story is not adjustable.
(stop)
The fact that Dialog games can be loaded and played at all on a C64 is interesting, but… yeah. Notably, the standard lib is so big that there’s no chance of making a single-file-load adventure, which can speed things up. With ZIL and (base) Inform, that’s still a distinct possibility if your game stays compact enough.
Inspired by Eric Eve’s Epistemology extension for Inform 7, a small extension that records things as seen or unseen, familiar or unfamiliar and known or unknown, I am trying and not making much progress on the question of how to mark every object that becomes visible to the player as (seen *). Any idea how I might do that?
Look at (recompute visibility) in stdlib? Specifically (this is 06_0_29, line numbers may vary) around line 310?
This is me bashing at it and being wrong, but I think it’s… the beginnings of approaching correct? Notably, in Cloak of Darkness it correctly sees #player, #hook, and #message at appropriate times, but never sees the #cloak.
(recompute visibility)
(current player $Player)
(current room $Room)
(visibility ceiling of $Player is $Ceil)
(now) (current visibility ceiling $Ceil)
(if) (light reaches ceiling $Ceil) (then)
(now) (player can see)
(exhaust) {
*($Object is #in $Room)
(now) (seen $Object)
I see $Object!
}
(else)
(now) ~(player can see)
(endif)
Win some, lose some…
Cloak of Darkness
A port of Roger Firth's reference game by Linus Åkesson.
Release 1. Serial number DEBUG.
Dialog Interactive Debugger (dgdebug) version 0g/06. Library version 0.29. Debugging extension 1.1.
I see #player!
Foyer of the Opera House
You are standing in a spacious hall, splendidly decorated in red and gold, with glittering chandeliers overhead. The entrance from the street is to the north, and there are doorways south and west.
> w
I see #player! You walk west.
Cloakroom
The walls of this small room were clearly once lined with hooks, though now only one remains. The exit is a door to the east.
I see #player! I see #hook!
> remove cloak
I see #player! I see #hook! You take off the velvet cloak. I see #player! I see #hook!
> hang cloak on hook
I see #player! I see #hook! You put the velvet cloak on the small brass hook. I see #player! I see #hook!
(Your score has gone up by one point.)
>
But we really don’t see objects when it’s dark!
> get cloak
I see #player! I see #hook! You take the velvet cloak off the small brass hook. I see #player! I see #hook!
> e
I see #player! I see #hook! You walk east. I see #hook!
Foyer of the Opera House
You are standing in a spacious hall, splendidly decorated in red and gold, with glittering chandeliers overhead. The entrance from the street is to the north, and there are doorways south and west.
I see #player!
> s
I see #player! You walk south.
In the dark
You are surrounded by darkness.
> look
In the dark
You are surrounded by darkness.
Internally, all values are represented as 16-bit words. The high bits determine the type (integer, object, dictionary word, and so on). For some of these types, the low bits are a reference into the heap. But for integers, the bits encode the actual value.
I’ve been considering the idea of adding support for big numbers that are stored in the heap, interoperating transparently with the normal integers. But I haven’t found an actual use case that would motivate the extra complexity. Do you have a particular use case in mind?
Not yet, but it’s in the works.
One day I hope to be able to prove you wrong, but for now I can’t argue with your experimental data.
I’m a little curious if anything you were saying in Question: Most Important Features in A Game Creator - #25 by justaguy relates to your plans for non-browser Å-Machines. Zeugma (the closest thing I know of to compare/infer from) is very impressive technically, but the “go figure out REU preloading on your own” business is not the greatest user experience.
gets us this. It’s still wrong because I’m not seeing items we “should” see (the #cloak) but it’s right in that it’s showing an accurate list of what we’re tagging as seen.
Foyer of the Opera House
You are standing in a spacious hall, splendidly decorated in red and gold, with glittering chandeliers overhead. The entrance from the street is to the north, and there are doorways south and west.
> (things ever seen)
yourself
Query succeeded: (things ever seen)
> w
Query succeeded: (get input [w])
I see #player! You walk west.
Cloakroom
The walls of this small room were clearly once lined with hooks, though now only one remains. The exit is a door to the east.
I see #player! I see #hook!
> (things ever seen)
a small brass hook and yourself
Query succeeded: (things ever seen)
> put cloak on hook
Query succeeded: (get input [put cloak on hook])
I see #player! I see #hook!
(first attempting to remove the velvet cloak)
You take off the velvet cloak. I see #player! I see #hook!
You put the velvet cloak on the small brass hook. I see #player! I see #hook!
(Your score has gone up by one point.)
> e
I see #player! I see #hook! You walk east. I see #hook!
Foyer of the Opera House
You are standing in a spacious hall, splendidly decorated in red and gold, with glittering chandeliers overhead. The entrance from the street is to the north, and there are doorways south and west.
I see #player!
> s
I see #player! You walk south.
Foyer Bar
The bar, much rougher than you'd have guessed after the opulence of the foyer to the north, is completely empty. There seems to be some sort of message scrawled in the sawdust on the floor.
I see #player! I see #message!
> (things ever seen)
a scrawled message, a small brass hook, and yourself
Query succeeded: (things ever seen)
I’m not sure if this solves your problem fully, but it could be a starting point. The library supports a way to flag objects as hidden:
(* is hidden)
This prevents the object from showing up in disambiguating questions, but it is still possible to refer to the object explicitly.
The library automatically clears the hidden-flag when printing the name of an object. Thus, if an object was declared hidden, but the flag isn’t set anymore, then you know that it has been seen by the player.
@jcompton describes a way of tracking what the player character has seen, which is subtly different. It’s a bit unclear which of these cases you’re aiming for.
I want to be able to let the user input a four-digit hexadecimal number and use that number, after some bitwise manipulation, to procedurally generate a room description.
First, you’d have to convert the player’s input from a word to a number. A feature that has already been suggested is the abity to convert a dictionary word to a list of characters. That would solve the problem partially. But if all four hexadecimal characters are 9 or less, the word of input would be represented as an integer instead, and you’d have to deal with that somehow.
Then there’s the problem of being limited to 14-bit numbers, as you’ve pointed out.
Next, there are no bitwise operations. You could use multiplication, addition, and modulo to implement a crude PRNG, but you would have to rely on undefined behaviour (when multiplication overflows) and deal with the fact that addition fails on overflow.
I think it would be better to have a way to seed the built-in random generator of Dialog in a predictable way, that works the same on every backend, platform, and interpreter. That way, players could communicate out-of-game and exchange interesting random seed values. And it would be possible to use e.g. (select) ... (at random) when setting up room properties.
The question is then, what would the API look like for seeding the randomizer? A single number contains too little entropy, so perhaps a list of numbers? In that case, the player’s input could be converted to a list of four numbers in the range 0–15, and that list could be used as a seed. Additionally, this would support a use case where coordinates are used as a seed value.
I’ll be standing by with more dumb test cases.