I have a puzzle that consists of a scanner the player must use to track a target. The scanner display is set to draw in the top half of the screen after an @split_window call, akin to the bathyscape sonar in Seastalker.
For the scanner puzzle to work, the entire scanner interface must be visible to the player. However, when I open up something like Windows Frotz, the default window is too narrow to accomodate the scanner. It can, of course, be resized but that’s annoying to do mid-game when you realize the display is wonky.
Is there a way (currently using Inform 6.41 to build .z5 file) to specify a minimum window width? Do any of the modern interpreters respect and accomodate such a request? I’m currently not targeting retro computers. Or just any general suggestions for handling the display of a split-screen puzzle like this cleanly?
There’s no way to specify a minimum size for the display in the Z-Machine: back in Infocom’s day most systems would have a fixed size display and that was what you got.
You can read the screen width (in characters) from the header and warn the user that the window is not big enough, that’s about the best you can do.
Some Infocom games check the screen width when they start, and if it’s less than X, they just print a message and exit. In some cases, it seems they could have easily avoided this limitation, e.g. it’s trivial to adapt Beyond Zork to a screen width of just 40 characters, but they had no intention of selling the game for any systems with screens that narrow, so they didn’t care.
Idea: Make two versions of that grid - a pretty one with the spacing, and a denser version without the spacing. If there’s not enough room for the pretty one, resort to the dense version.
Thanks for the input @DavidK and @fredrik
Having written an interpreter and modified some games for a resource (and character-width) constrained machine, I was aware of how Infocom handled things, which was… a little less than elegant. I guess I was hoping with fingers crossed that I might have more flexible options if I ignore those older machines and strictly target modern interpreters.
I’ll likely just implement the “two versions of the grid” idea, @fredrik. Thank you.
