# A question on feasibility in ZIL

I’m working on a space station scenario. Room count is some 110 locs in 6 levels. Plus all rooms are connected thru hatches that can be open or closed, closed-blocked, or closed-blocked-welded (meaning never opens ahain). What is you best suggestion on how to implement these doors, which must be 2sided? One object per door + status checks in connections? Any other ideas?

Also: hull breaches can occur, meaning a countdown starts for the remaining oxygen to breathe, and the oxygen progressively escaping along different routes, depending on which hatches may be open or not. How would you approach a realistic encoding of this type of event, with the system calculating the farthest location from which the oxygen starts to escape, thru a route of open doors towards the breach?

The same for a similar breach but in a submarine: here, the water starts on the floor of breach room, reaches height level 1… next room, water reaches level 2 in breach room and level 1cin next room… and unless the breach is contained the water floods a penetrating route thru the open doors…

Please don’t be too programatic in replies, I just want to make sure that encoding these situations is feasible with ZIL. And which z version, either 5 or 8, which is better for more than 256 objects?

The only difference between z5 and z8 is that z8 can handle more text and executable code. It’s reasonable to start with z5 and switch to z8 only if you need it.

Yeah, anything from 4 onward can theoretically support up to 65535 objects.

Which effectively means infinite, because you’ll run out of dynamic memory long before you run out of object slots. That’s something no version of the Z-machine is able to expand.

First the question abot feasibility: Becasuse ZIL is Turing Complete you should in theory be able to write code if you have the algorithm.

I havn’t thought this through all the way but I would approach it something like this:

1. Assign every room a property that tracks the distance from the breach (0 = the room with breach, -1 = no connection to breach, 1 = one room away, and so on) and one property that holds the quantity of oxygen in the room.
2. When a breach appears, recursivly loop through every exit and assign every connected room a distance of current room+1. If the room already have been assigned a distance, only assign it a new value if the distance is lower than the currently assigned.
3. When a hatch is opened the new room is assigned the distance if this room + 1 (if the distance is lower than the currently assigned).
4. When a hatch is closed, recalculate all distances as of point 2.
5. When breach is closed, reset all distances to -1.
6. For every turn subtract the escaping oxygen via the breach from rooms in predefined order. Maybe start with subtracting from distance = 0 until these rooms are empty, then subtract from rooms with distance = 1 and so on. Maybe by a completely different formula (I really don’t know how oxygen escapes…).
7. For every turn add new oxygen to room (if there is a system for regenerating oxygen) until it reaches max capacity. This will mean that when the breach is closed all returns to normal. If you want different max capcity for each room (in the real world, rooms are of different sizes), you need a new property for that.
8. Don’t allow muliple breaches (this would be so complicated…).

The submarine example is a bit tricker, because of gravity. Some level 0 rooms could, for example, only be reached via a level 1 room.This would mean that that level 0 room won’t fill with water before the connecting level 1 room is reached by the water.

Speaking from experience, the hardcore simulationist approach may prove a lot of work, you get a lot of code to maintain, the game will need a fast computer to run, and most players either won’t recognize the excellent simulation or won’t care. Consider using a simpler model, i.e:

• Split the space station into a reasonable number of sections.
• Give each room a property saying which section it is is.
• Make a table of all the airtight doors that connect sections, i.e. Door-object, From-secion, To-section.
• When a breach has occured, that section becomes lower and lower on oxygen for five turns. On the fifth turn, this oxygen deficiency spreads through any doors connecting the section to other sections. Etc.
• You don’t need to update status for a hundred rooms where the player isn’t. You can just check the oxygen level for the section where the player is.

Agree that you benefit from an easier model but my understanding was that he wanted a complex one.

1 Like

Or in other words, you’ll want Dijkstra’s algorithm for SSSP (Single Source Shortest Path). There are a lot of variations on this concept, but I think Dijkstra is your best bet here. (I knew that computer science degree would come in handy!) The hardest part is going to be the data structures you need to make it fast and efficient, since ZIL isn’t doing much of the work for you there.

However, the Z-machine has a lot of intrinsic limits beyond what’s considered in Turing completeness. This makes it hard to implement, for example, any fancy data structures.

Wow, tks+++ for your comments. I am no programming savvy at all by I somehow manage to encode using text adv languages and workarounds. Yes, I know about the D algorithm but yes it is a difficult task. I already have an alternative idea lurking in the back of my mind, using numeric non-game-objects names an a non-map room as stack. It may not be the most elegant solution but as far as it works… 1 fake object per game-room, each pair named named 001, 002, 003… 110.

The water option for the submarine scenario is easier as, when the breach occurs, the flood occurs from the hole inwards and it is just a question of creating simple objects 110 x 5 flood levels = 330 water units, and start looping thru rooms creating water unit instances from flooded room to connected rooms.

Thanks guys, i’ll let you know!

Objects are probably overkill—there’s a decent amount of overhead for each one. I’d just make a big array.

The amount of bytes an object takes up in version 4+ is at least 16. The minimum size of an object in Inform 6 is 20 bytes. Not sure about ZIL.

So, if you create 1000 objects, that’s at the very least 16000 bytes of dynamic memory. More if you want them to have luxuries such as a name and some property values.