Dialog

Technical Development Development Systems
1

In one corner of the room, a rugged metal box hums contentedly, while patterns of light
dance across a myriad of tiny indicators on its front panel. It’s a Zork machine; an
elegant system, for a more… optimized age.

On top of the Zork machine lies a surprisingly modern-looking book.

X BOOK

The glossy paperback appears to be fresh off the press, and looks incongruous on top
of the decades-old machinery. Yet it seems to have been placed there quite deliberately,
and you somehow get the impression that it wouldn’t truly belong anywhere else. Three
words are printed on its front cover in austere, sans-serif letters: “The Dialog Manual”.

READ IT

6 Likes
2

For those who haven’t been following what lft has been up to and don’t know what to make of this post… there’s an entire new IF language behind that link.

3

A new language that compiles to Z-Code, cool!

4

This is pretty much amazing. I love the language.

The part that compels me to flee in terror is instructions like:

I’m spoiled by IDEs for Inform 7 and CSide and Twine and AXMA that do everything internally. That’s my bad of course.

5

Wow - I am totally stunned - the underlying concept is simple but all the same complex and nearly perfect fitted for the needs of an IF author. And I don’t mind compiling the source which is only necessary if you’re on OSX - for Windows & Linux there a prebuild compiler executables.

Very nice!

6

I’ve started playing around with Dialog by attempting to port my old speed-if game “The Angel Curse” from Inform 6 to Dialog. I’ve managed to get quite a bit of it working, but (try [look]) just doesn’t seem to work from within my (intro) for some reason. And I’m still puzzling out how to code a vehicle that actually goes anywhere. My PC is in a wheelchair, and it took me ages to figure it out for Inform 6, way back when too.

7

Oops, that might be a bug in the library. Try (enter $Room) instead, which will invoke the [look] action in turn. I’m on it.

I’m happy to assist if you or anyone else have specific questions. This is all still in beta state.

This should get you started, if you haven’t already figured it out:

#wheelchair
(in-seat *)
(vehicle *)
(#player is #in *)

Best regards,
Linus

8

No, sorry, I already figured out that much. What happens is that when I try to go east, the game says “You will have to get out of the wheelchair first.” This seems to be generated by (when $O is $Rel $Parent) which was invoked by (prevent [go $]) (current player $Actor) ($Actor is $Rel $Obj) ~(room $Obj) (when $Actor is $Rel $Obj) … which doesn’t seem to consider vehicles at all. If I’m reading it correctly, if you’re in something that isn’t a room, you may not go anywhere. And I don’t think I can override it with my own prevent rule either, can I?

9

By the way, if people are curious what The Angel Curse’s code in Dialog looks like, it’s currently at http://plover.net/~davidw/test/angelcurse.dg

10

Thank you very much for the feedback! These are indeed bugs in the library, and I think they’re fixed now. Please try library version 0.13.

  • Bugfix: Made it possible to (try [look]) from within (intro).
  • Bugfix: Made it possible to drive vehicles from room to room.
11

I hear you, Hanon. I have two reasons:

The first reason is that I don’t consider the language stable enough just yet. In fact, I already have several ideas for improvements. But I don’t want to maintain both a command-line tool and a syntax-aware IDE while the language definition is in flux. This reason will diminish over time.

The second reason is that I personally prefer working with command-line tools. I don’t think this will change, as such. But I’d like at some point to have an interactive debugger, and to have it display the source code next to the output or program trace. From there, it shouldn’t be too much extra work to add some rudimentary editing capabilities to the source-code viewer, and that would be a start.

This is kind of long term, but don’t give up hope!

12

This system is enormously elegant and powerful. I much prefer this to Inform. And also it’s a programming system in its own right;

I think working with numbers needs to be improved a bit. It would be nice to be able to use infix arithmetic operators and bound variables like Prolog. Also the docs say numbers are non-negative. I definitely think they should be allowed to be negative as well.

But significantly,

can there be other back-ends? For example, could there be a back-end that interprets the AST directly? You might already have for for debugging? Having that alternative would be cool as it would mean Dialog is also a self-contained system not requiring a Z-machine.

Great work!

13

For an interactive debugger - maybe you could borrow from ZILF’s debugger?

14

Can you consider creating a github/gitlab page for this project?

15

Might support for Z-code version 3 (ZIP) also be added? (Other target VMs are possible too such as Glulx and TAVERN. With Glulx it could implement a larger range of numbers. Also, depending on the target VM some operations might not be implemented.) Another idea can be to support inline ZAP codes (if it can then target other VMs, it can use those instruction sets instead in those modes; some sort of conditional compilation should be supported for user libraries, not only for this purpose but there are other cases where conditional compilation is useful too). (Note also: The (uppercase) command of Dialog is available as a built-in command to TAVERN.) (I wrote a document about tricky stuff with Z-machine codes (the “Tricky Document”), about how some things could be optimized in a Z-code program.)

16

Thank you so much! I’m glad to hear it’s a future possibility. Dialog is ambitious and exciting and I like how it works from the bit I read.

Your documentation is wonderful. I was encouraged how you explain where to jump ahead, where a non-coder like me should start, and how to jump back and forth - which helps me a lot!

17

This looks lovely.

I haven’t been able to try it out yet, and I’m unfamiliar with the strict limitations of the z-Machine. I’ve been missing one thing for a long time from existing IF systems, and that is REPL. The ability to code IF during runtime would be as close as anything I can think of to a killer feature. Is that sort of thing even remotely in the cards?

18

Not with Zcode/Glulx as the back end. Inform’s “replay-to-here” feature (which plays back the command history) is as close as you’re going to get.

19

Like Zarf says, it’s not possible with a Z-machine backend, because the running program can only modify a small part of the memory map. I don’t know about Glulx, but I trust Zarf’s expertise on the matter.

With a generic backend, like jkj yuio suggested, things are more flexible. The idea of iterative IF development is quite attractive. When I was writing my own game, I often had to navigate through the first part of the game just to check something towards the end, only to find that it wasn’t quite fixed yet.

At one point during the development of Dialog, it was actually possible to put in queries, e.g. “(enter #library)”, directly at the game prompt. A nifty feature, but it caused all kinds of trouble for the optimizing compiler, so I had to scrap it, since generating optimized code was one of my explicit design goals.

An interactive debugger or IDE, with a custom backend, would have access to the complete source code. It would be expected to run on modern hardware, so the performance constraints are relaxed. This would remove the technical roadblocks.

But there’s another snag: In a traditional REPL, the programmer adds or replaces functions, which are maintained in a set. But in Dialog, the order of rules is significant. So when adding a rule, one would have to specify where in the program the rule should appear. It seems more natural, then, to have an editable source-code pane next to a pane with a running game. But there’s still room for innovation: What if the current game state is tracked using high-level constructs in the debugger, and modifications to the source code don’t reset this state. Then it should be possible to modify the rules and messages of the program/library, while still retaining all of the state of the running game (including current room and inventory). From time to time, it would still be necessary to replay all commands, just to verify that nothing has broken elsewhere in the game. But it should shorten the dev-cycle, which I think is what this feature request ultimately boils down to.

It’s long term, sure, but if I’m going to make an IDE at some point anyway, this does seem like a killer feature to have. And it’s one that has to be designed-in from the start, so thanks for bringing it up!

20

This is fascinating. I had no idea about the constraints of the z-Machine, nor the implications on the ordering of rules in Dialog, but it makes sense.

And yeah, it was my nefarious intent to sort of plant a seed, or at least place temptation in your path. If something comes out of it that can foster that type of exploratory development, consider me tempted in turn. :slight_smile: