Hugo Wish List

[Merk]

This is a short list of things I wish were possible in Hugo. :) None of these may be right for Hugo, but if nobody ever asks, then there isn't even a slim chance. So... :)

1) I'd like a way to turn on and off the "pause" text feature. Something like a system(PAUSE_ON) and system(PAUSE_OFF), or SetPause true / SetPause false.

2) I'd like a way to redraw my screen when/if the user changes their screen options. What might work is to have the engine run DoScreenChange() if it appears as a routine in the currently-running game, whenever the screen is resized. It could also be run if the user turns on or off graphics, or changes font sizes. Then, it would be up to us authors to implement DoScreenChange() -- or not, as needed. In my new game, I do this whenever the player types "clear" or "cls". It'd be nice to make it automatic. :)

3) Global mouse support (instead of just when pausing). Something similar to #2 would work great. While at a command prompt, if the mouse is clicked, run DoMouseClick() in the current game (if the routine exists) with the Column and Row of the click as parameters. This could provide for better menus and in-game shortcuts.

That's all for now!

[Kent]

By (1) do you mean the [MORE] prompt?

(2) is actually sort of possible. Future Boy! does it, for instance, in certain situations.

(3) would be possible if the current behavior were overridden. Like, one would have to choose between the current/default behavior and more customizable behavior. Not a bad idea.

[Merk]

(1) Yep, the [MORE] prompt. I was looking at the C source code. It seems that a well-placed global in one routine could return out of the prompt without ever showing it. :)

(2) Giving it more thought, I think I have a solution. This might be what you did in FB!, not sure. If I had globals storing the "prior" value of display.screenwidth, display.screenheight, and display.hasgraphics, then each turn I could see if they change. If changed, I alter the screen. Seems possible.

3) It would be really cool! Maybe include a "display.mouseadvanced" property, so games could know if they're running on a 'terp that has the advanced mouse support. It could lend itself to more interactive graphics.

Now, having exact pixel coords and hotspots would be ever better. ;-)

[Kent]

See if display.needs_repaint does what you need. It's up to the port to set that to true whenever something has been done that might affect layout, such as resizing, turning graphics on/off, etc.

[Merk]

Yep, that also seems to work. I had written the routine to check prior states of display.screenwidth, display.screenheight, and display.hasgraphics. I commented that out and just checked display.needs_repaint, and it appeared to work the same.

The trick is, where best to put it? I found that if I put it in main() then it only works for any verb routines that return True. I thought only XVerbs would cause it not to re-run main(), but it seems that any verb routine that doesn't return True skips main() as well. So, I did a replace preParse() and put it there. I don't actually pre-parse anything -- I just check the screen change, and return false. That works as long as it's a recognized command. If the command references unknown objects, or starts with an unknown verb, then it appears the Parse() routine doesn't continue far enough to call preParse().

Any suggestions on where best to put it? I'd like to run it before the player's command is processed, as opposed to after. If running after, the result of the command would be erased during my screen re-draw. Unless I drop it in at the very beginning of Parse(), I'm not sure how to make sure it works after every command.

Thanks!

---- Mike.

[Kent]

In FB I put it in the before routine of the player similar to:

Code: Select all

before
{
	actor PreParse
	{
		if display.needs_repaint
		{
			...redraw code goes here...
		}
		else
			return false
	}
}

This way, it runs everytime a new command is entered (before it's sent to the parser).

FB's player class will probably be included in the source code I eventually release.

[Guest]

I should mention that the reason it's in a before routine like that is to make it easily contained; I tried to compartmentalize as much of the FB source as possible, and the derived player class that I base all the player objects on is where a lot of that customization happens.

You could also do this in a replaced PreParse routine.

[Merk]

Yeah, it seems to work the same in replace PreParse() as it does in the before-actor for the player. As long as the command is valid, it works -- but commands with invalid verbs, or verbs referencing invalid options seems to end in Parse() before PreParse() is even called.

Then again, I don't expect players to change their screen options frequently during play. When and if they do, it will at least correct itself with their next legit command.

[Lysander]

While I'm thinking of it, might there possibly be a command implamentable where the player can decide to turn off the text that is spoken by a character in a sound file? Like, in Future Boy, when you are talking to Frank, reading the same thing that was coming out of my speakers seemed a tad weird.

[Guest]

That's probably a matter of implementation, rather than engine. You'd need a verb like "voices on" or "voices off", which could be done in Hugo as it is, if the game gave the option. :)

Most of the console games I've played lately have spoken dialogue over written dialogue -- Still Life, Knights of the Old Republic, etc. It doesn't bother me at all, except sometimes when they changed the printed version a little, after the spoken version was already recorded. :)

[Guest]

Woops, that was me.

[Merk]

Me. Didn't know I wasn't logged in... the second time too. :)