Yeah, as I understand, Glulx uses a (relatively) simple text buffer to display the game text, and HTML-TADS has a basic HTML renderer which behaves more or less like a regular browser when resizing.

Hugo's method of layout and rendering has evolved largely from the desire to be as portable as possible. Being able to run on almost any platform with comparable functionality is to some degree related to the screen model. Not that, again, it wouldn't be possible to implement a similar resize/reflow behavior in something like the Windows version of Hugo; I just need to find the time to do it.

I designed Future Boy! to run at 800x600 or 1024x768. You can of course run it at higher resolutions, but if you're using graphics, things get spaced apart more. This is an expected side-effect as people's displays get higher in resolution. On my current 1280x1024 monitor, for instance, FB at full screen has quite a bit of empty space; I recommend people either run the game at a lower resolution or in a window for proper formatting.

Now, it is possible to design your images at a higher resolution and let the built-in resizing in the Windows, Mac, Linux, Pocket PC, and BeOS ports scale it with graphics smoothing turned on. On a slower machine the resizing may be noticeable, however, since it's doing a bilinear filter on every pixel (with graphics smoothing turned on). And without graphics smoothing turned on or on ports without it, resized images don't look as pretty.

So I'd probably recommend the same approach I took for FB.

Out of idle curiosity, I fired up WinFrotz 2002; it does the same thing.

I tried resetting my screen size (it was at 1280x1024) for both Hugo and WinFrotz, all the way down to 800x600, but results were the same.

Glulxe (playing City of Secrets) and Html-TADS v3.0c both resized appropriately.

Just something I never noticed before. This does lead me to ask: at what screen size should I design my (Hugo) game?

I think I understand what you mean. This is really due to the fact that the engine doesn't reflow the display the way a web browser would reformat the HTML. It does try to wait until the user is done resizing the window before shuffling things around, cropping (if necessary), etc., but on a maximize/restore it happens right away.

The reflow wouldn't be such a big deal normally for a Hugo game since they're usually mostly/all text, but in the event of windows, graphics, etc. it gets a little trickier. (Text-only would be much easier to dynamically reflow.)

Now, that said, it should be possible, especially with some of the things that have been built into the engine over the last couple of years. In fact it's something that I keep moving to the top of my list of things I'd like to take a better look at, but so far I haven't had the time.

Just noticed this noodling around with Vault of Hugo:

If I resize my game window, it cuts off any text that extends beyond the window. Upon re-maximizing the window, the cut-off text is still missing.