A Table question

So, I want to set up a complicated maze. My first thought was: that is what tables are for. Because you want to have a table where you look up the intersection of a room name and a compass direction, and then find another room name: the room where you end up if you start out from the original room and move in the specified compass direction.

But that’s really not how tables work in Inform 7 at all, is it? Informally speaking, an Inform 7 table is not a function F(x,y)->z, where x, y and z can be variables of any type, but rather a collection of named, ordered lists of equal lengths. So I’m probably better off just defining the map connections without a table?

2 Likes

Practically speaking, building the map in some other way than through the built-in map storage would require rewriting the Going action. (Or you’d have to translate your tables into map connections at startup.) Personally, I’d avoid doing either of those as much as I can.

Aren’t those basically two sides of the same coin in this case? Unless there is some sort of mathematical relation between the inputs and outputs (like z = x+y), you’ll need to have some sort of underlying data structure.

2 Likes

I7 tables do not have constant-time lookup, which is the usual intuition about map/dict data types in most programming languages.

That aside, Adrian is correct that you can use a table for this. But there’s no particular advantage to it. The standard map model is straightforward, and a bunch of statements like

R1 is north of R2.
R2 is east of R3.
[...]

…is pretty similar to how you’d write a table anyhow.

(If your maze is highly mutable or has logic-based map connections, that’s when it might be worth changing the going action. I did this in Advent Door - Details .)

1 Like

Is your goal mostly just to have a convenient setup mechanism? If so, perhaps you can get the best of both worlds.

"Maze Table"

Some rooms are defined by the Table of Maze Rooms.

Table of Maze Rooms
Room	Direction	Destination
Maze1	east	Maze2
Maze2	north	Maze3
Maze3	southeast	Maze4
Maze4	down	Maze1


When play begins (this is the set up maze rule):
    repeat through the Table of Maze Rooms:
	    change the direction entry exit of room entry to destination entry.

Test me with "e / n / se / d".
2 Likes

Thanks everyone! I don’t mind messing with the going action. There’s another place in my game with complicated geometry, but there I wanted to keep access to Inform’s built-in route finding routines, and so I had to build things up out of standard map connections. Here, I’ll have neither route finding nor moving NPCs nor anything like that, so I guess I can mess around without consequences.

A table would mostly just be a nice way of setting things up, allowing one to see at a glance that room A has three connections to room B and no connections to room C. But I suspect it’s more of a bother to set this up in Inform 7 than the pay-off will be.

What I was ineffectively gesturing at is that an Inform Table doesn’t allow you to refer to columns using a value; you can’t have ‘way’ be a direction and then refer to the ‘way column’.

Well, with help from I6 and Brady Garvin one can: I7: Tables and functional programming Or at least one could ten years ago. I haven’t tried the code in 6M62; my guess would be that the table stuff is sound and some of the property stuff would need tweaking, but that’s not what you care about here.

So you could set up a table with a room-valued column for each direction and then get the column ids of the columns and create a relation of numbers to directions.

3 Likes

I’ve wound up using tables for a lot of things in Inform that they initially weren’t intended for.

I think in this case a table would be a great way to organize what goes where so

  1. you can see it visually if you have initial values set and
  2. if you want to print rooms in a certain order for debugging purposes, a table makes sure of these things, while if you write things into code, stuff like putting “room 130” in a table header might bump it to the top, ahead of room 1.

While I can’t add much technically to what’s above, I think tables would be most handy if you are keeping track of a lot of one-way passages. I would have

table of maze stuff
init-room north-room west-room east-room south-room up-room down-room
r1        r2         r3        r4        r5         r6      r7
r2        --         r1

I definitely use tables like this with pen and paper when working through a tricky maze! So it feels intuitive to me to do things this way, even knowing the basic Inform syntax of asymmetric mappings.

Speaking from experience, I really enjoy having a table instead of a bunch of properties to keep track of point-gaining actions. It’s probably inelegant in terms of optimal programming, but it’s so much more readable for me.

I often go so far as to have a separate extension file for my major tables, so they don’t distract from the game’s main engine code, e.g. “include This Game Tables by Andrew Schultz.” I mean, you can use “volume” and so forth, but once I started using source control, I enjoyed being able to see whether I was fixing core stuff or just game details.

1 Like