trying taking Musashi’s Sword from his hands should be handled with setting true the deadflag…
Best regards from Italy,
dott. Piergiorgio.
trying taking Musashi’s Sword from his hands should be handled with setting true the deadflag…
Best regards from Italy,
dott. Piergiorgio.
Or as they say in ZIL, <JIGS-UP>
True that, but then I would lose the Merciful rating for my game. Hmmmm. Maybe I should add some gratuitous violence? Nah, time is pressing enough already… Maybe in a future game.
There’s an anecdote from the life of Musashi:
Once, a group of some young samurai tried to provoke into a duel Musashi when he was eating (so, chopsticks in his hand); of course, he has already assessed the situation and determined that their lack of wisdom don’t deserve a quick death, so he simply killed two flies with a quick flash of his chopstick; the youths was wise enough to understand their deadly foolishness and take a quick and honorable retreat.
so, a merciful solution is in the actual wisdom of the author of the Book of Five Rings…
Best regards from Italy,
dott. Piergiorgio.
AN ASCII-ART AUTOMAP???
I’ve liked your snippet anyway as I can’t just keep paying sexiness.
Actually, at a thought level I’m partial to code that builds data or indexes. I’m not sure why. It can be hard to wrangle but is often finessed over time (which you personally don’t have) and ultimately becomes streamlined and small, and you can look at it and think, ‘This is essential and does a lot, but look how petite and streamlined I’ve made it.’
-Wade
I know there is a bit of scepticism against ZIL but I think it is very elegant and love seeing the snippets here. I long to get back and actually write something in it myself.
At some point in the near future I want to gather up my notes and share my experiences. But not right now ![]()
To paraphrase Vladimir Ilyich Lenin:
There are weeks where nothing happens; and there are days where weeks happen.
Agreed. If I ignore the little warts I sometimes experience it is a very elegant language indeed once one gets used to it. I want to try out its macro features and possibly do something with its standard library (I remind myself that with inform 7 I basically disabled all in game verbs and implemented my own to ensure the game was fully under my control as its author). Not sure how much customization zillib offers.
Just 24hrs after this??
Are you speed running the 7 Stages??? WHAT HAS THIS COMP DONE TO YOU @Lancelot ARE YOU OK?!?!?!? PLEASE PLEASE PLEASE CALL YOUR SPONSOR!!!
What can I say. Visiting the Japanese garden today reminded me of many things. And gave me some inspiration I could not ignore.
Seems like you have not been put off by your experiences after all
– The ZILF library can be extremely customised, from just replacing the LIBRARY-MESSAGE messages (As explained in another thread by @vaporware) to a complete override of a routine or macro using a mix of DELAY-DEFINITION, REPLACE-DEFINITION or setting REDEFINE - With these you can manipulate exiting hooks, macros and routines to completely take control of how the parser handles things (all without manipulating the original Library files at all - something Infocom did constantly by rewriting whole areas, they didn’t really have a library as such!). I am still experimenting with it, but it’s extremely powerful. Hope you get some time to ‘cook’ with it some more (After a well deserved rest post comp).
I definitely will! One of the things which keeps tripping me up is something which I also had not anticipated: <GET ,HERE ,P?INDEX> which of course should have been <GETP ,HERE ,P?INDEX>. The compiler doesn’t seem to mind. THAT kind of bug takes me a LOT of time to find. They say that FINDing a bug is half the work. I start wondering if this is already addressed in newer ZILF releases.
well, the opening talks about “chamaleon device” and “red box”…
Best regards from Italy,
dott. Piergiorgio.
Aww NOOOOOOO I have been found out! But if you are thinking of the T.A.R.D.I.S., that one was frozen into the shape of a blue police box, not a red telephone booth. But I visited London a few months ago and that scenic spot (with a lot of tourists queueing up to take pictures) stuck in my mind.
The Timelords aren’t few.
(actually I have fooled around a fanfiction around TARDIS with working chamaleon and a container ship. Guess what shape was involved
)
Best regards from Italy,
dott. Piergiorgio.
Not yet, but I’ve added it to the to-do list.
FYI, the project tab on zilf.io always has the latest (unreleased) compiler version.
For what it’s worth, IFComp’s policy on these things follows the Organization for Transformative Works one, which basically says that fanfic is completely fine as long as it’s transformative and noncommercial. That seems as good a rule of thumb as any.
Nobody seemed to have an issue with REZROV last episode, after all; and the term “chameleon circuit” seems much less distinctive than that!
In Dialog it’s certainly possible to have two different rooms with the exact same name, but since there’s a built in world model, it’s easier to adapt that.
You can specify the temporal and spacial location of each room such that duplicate, identically-named rooms have the same spacial location. Then, when the player switches between time periods, you can find the room with the same spacial location but a different temporal location, and move the player to that room. The downside of this method of implementation is that you have to create multiples of every single room, and everything the player could enter or sit on. (For instance, if there’s a bench in a room and the PC is sitting on it, when they move forward in time they should stay on the bench, but any other items that were on the bench should stay in the past.)
You can also implement the system in such a way that you only need one room per location. Dialog’s world model is written in Dialog code, which makes it fairly simple to modify. Additionally, you can easily create a single room with a description that varies based on a particular condition. Instead of creating duplicate objects, you can specify the initial temporal location of each object and the time periods in which each room is accessible and keep track of which time period the player is currently in. You can then prevent any item that’s not in the current time period from being treated as if it were in the room. I find this solution preferable; it’s much simpler to keep track of the world model, since there’s no risk of mixing up different versions of the same room, and it scales up much better, since you don’t need to duplicate large parts of the game world.
For comparison purposes, I implemented a small demo game twice: once using identically-named rooms and once using only different time periods. Here’s the source code and compiled versions of both implementations:
time_travel_tests.zip (72.9 KB)
(“time_travel_test.dg” and “time_travel_test.z8” are for the implementation modifying the default world model, and the ones ending in “multi_room” use duplicate identically-named rooms.)