Thank you so much!
The core idea of moving spells around came around the start of the year, and then I spent about six months ruminating on it, thinking about ideas, brainstorming with my siblings, and generally trying to come up with interesting ways to use spells. My goal with a core game mechanic like this is to have each spell used in three different ways, so I tried to think of spells with a lot of different possible uses, then as many puzzles as I could come up with for each one. It wasn’t until around June that I started implementing in earnest; everything before that was lots and lots of thinking.
The idea of curing a curse came early, and the way the two amulets would work, but all the things surrounding it slowly solidified across those months (amidst lots and lots of other ideas that didn’t work).
I personally really need the ability to split a project into multiple files that I can easily flip back and forth between. Having one file for the magic system, one for all the actions, one for the interface, one for each section of the world, and so on, just works better for me than Inform’s section headings.
The significant declaration order has actually never really been a problem for me. If I put the specific implementation and the general rules in separate files, then I can order those files once in the Makefile and never worry about it again.
Ooh, good question. Following up on the last few answers, I think dividing things between files in a way that works for you helps a lot. I like keeping the world (rooms, objects, etc), any new actions, and the interface in separate files so that I always know where to find something.
Apart from that, remember that objects are cheap. Use them for anything you want! All the footnote topics are objects.
Yep, just my own alterations to Linus’s classic Å-machine interpreter. I added some new options to the menus, changed the color scheme, and inserted the code to embed audio as well as images. The core of it is the same one that comes with vanilla aambundle.
Since I was usually building the game as part of a complicated make invocation, it was helpful to save the build logs to files that I could consult later. I mostly just looked at them when something went wrong to have a record of the warnings and error messages.
That is a great question, and it’s something I really should have kept better track of. A lot of the changes are just the quotes and apostrophes, as you noted, but there are also things like extensions to the list-writer that I would like to be able to reuse. But I didn’t keep track of them anywhere, so I’ll just have to go through a diff when the time comes…
If I only had to generate the field once, it wouldn’t save much time at all. But it made it a lot easier to make small changes, like turning “emmer” into a footnote when testers didn’t recognize the word.
Absolutely. Ever since Familiar Problems, I’ve become convinced that the best thing a game can do when a player gets stuck is to point them toward which problems are currently solvable. This is something that traditional hint sheets tend to be bad at, but Dialog’s relation-handling makes it easy to build into the game itself.
There’s a predicate called simply ($)—that is, a parameter and no other words—defined in the standard library. This is the version from Wise-Woman’s Dog:
(interface ($<Obj))
($Obj)
(zlink {(full name $Obj)})
That is, it calls (zlink $) with (full name $Obj). (zlink $Closure) is then defined in interface.dg and ends up compiled into (span @link) { (link) (query $Closure) }. (I use it instead of built-in (link) so I can format it specially on Z-machine.) So putting an object name in parentheses prints its full name as a link.
The fact that you can call a predicate simply ($) is very weird, and I suspect Linus implemented it specifically for this purpose!
Not at all! I love talking about things I made. I’m so glad you’re excited about it!