Interface overhaul/stripdown (like Myst)

[Kawa]

You can have a handleEvent in your room. Add it to gMouseHandler and gKeyHandler on init, remove it again on dispose. The template game's title screen does this so it can respond to clicks, though my copy calls them gOldMH/gOldKH... doesn't make a difference.

Importantly, the title screen room adds itself to the front of the list. If you want things in the room to respond first, you might rather use addToEnd.

[MusicallyInspired]

Like the actual DoVerbCode of Feature itself not an override from an object based on Feature? This could work as I'd have basically the same actions across every room. I'll probably replace polygons with colours in this case because that's easier to check for rather than polygons which are specific to each room, yes? This would also solve my "click on nothing" problem.

[Kawa]

I was under the impression that polygons and control colors were both room-specific. In fact, wouldn't control colors be more room-specific, in a way?

[MusicallyInspired]

If I put code in a public method to watch for certain control colours it shouldn't matter, should it?

[Kawa]

Having a few colors be common across the whole game? Sure, that shouldn't matter.

[MusicallyInspired]

I mean, there are only 16 colours. I used region scripts which are spread across multiple rooms for handling changing Graham's VIEW as he wades in and out of the water in KQ2SCI.

[Kawa]

To be fair, AGI made do with worse.

[MusicallyInspired]

I guess what I'm getting at is I don't understand how control colours would be "more room-specific."

[Kawa]

You usually have one picture per room, right? And it's the pictures that determine which control colors go where, right?

[lskovlun]

Like the actual DoVerbCode of Feature itself not an override from an object based on Feature? This could work as I'd have basically the same actions across every room. I'll probably replace polygons with colours in this case because that's easier to check for rather than polygons which are specific to each room, yes? This would also solve my "click on nothing" problem.

There should be a global variable - the version of the template game I'm looking at calls it gDoVerbCode - that you can set to point to an instance of Code (so it's a little different from the usual doVerb handling). It gets called if a) you remember to call the superclass in the doVerbs that you do have and b) there is no message associated with the feature's noun/verb/case. Sierra usually set it somewhere in the game initialization, but I bet you could change it around if you wanted to.

Another interesting tidbit that I found is the concept of "actions", notably used in Conquests of the Longbow. If the actions property is set to an instance, then its doVerb method completely overrides that of the feature - so you could have day1Actions, day2Actions, etc. - or in the case of reused actor instances, select which set of responses the user would get.

[MusicallyInspired]

Ohhh neat.

You usually have one picture per room, right? And it's the pictures that determine which control colors go where, right?

Well yeah, but that's for the colour data itself. I'm just talking about referencing it; triggering certain actions based on its existence. I don't need the same exact colours/polygons on every screen. In fact I don't want that.

[Kawa]

I didn't say you'd have the same colors/polys on every screen.

I meant like, just an example, if you can click somewhere to go in a cardinal direction (considering the north/east/south/west properties on rooms), you'd have the dark blue, green, cyan, and red colors mean "go in that direction". Depending on the visual size and shape of the room, a given direction might need to be closer to the center or whathaveyou, or not be an option at all. Or perhaps there's a default response to clicking on the sky, if and where it's visible, that's the same throughout the game?

It's like having a general "in water" color in a regular game with a visible Ego walking around -- not all rooms have water in them, and those that do don't have the water in the same places.

[MusicallyInspired]

Yeah, that's exactly what I said above with my water-wading Region script in KQ2SCI. I think we're on the same page....I still don't understand why you brought up control colours being room specific though. The colours themselves, yes. I'd just draw them on every picture. But the code can be handled globally.

[Kawa]

The code can be handled both globally and locally. Anything not caught locally bubbles up to global. "Well, I guess I have a bit too many distinct clickable areas here, but there's only one exit so let's just use one of the exit colors as a puzzle button input."

(Which is a silly example as my game has Features that share a single color, but are on opposite sides of the screen.)

[MusicallyInspired]

The code I'm talking about being global wouldn't handle the actual room changing. Just changing the cursor VIEW when hovering over certain colours (for turning around, grabbing something, looking up/down, etc).