Walkbehinds with walking behind hills

[Unknown]

Related forum topic:

http://www.bigbluecup.com/yabb/index.php?topic=14303

To-do list entry:

 - Someway for QFG2 Desert type walk-behinds... where the user goes down
   instead of foward.

[Joseph DiPerla]

I think the best way to do this is using the set baseline option and ignore walkbehind functions. I really do not see an easier or better way to do this. Perhaps adding an enabling and disabling walkbehind event could be an option to be added. Just a thought.

[Crimson Wizard]

I think the best way to do this is using the set baseline option and ignore walkbehind functions. I really do not see an easier or better way to do this. Perhaps adding an enabling and disabling walkbehind event could be an option to be added. Just a thought.

Yeah, this is pretty much possible to do with scripting.
I suppose that a scripting module could be better solution for this case, since it does not require adding any new basic functionality.

• Status changed from to New
• Type changed from Bug to Feature

[Snarky]

If walkable areas were defined as polygons instead of as bitmaps, so that you could have overlapping ones, this would be possible. (Though you would also need to be able to define reverse scaling on some of the regions, and lock the area's z-order to a certain baseline.) Polygon-based walkable areas have other benefits, too.

[Crimson Wizard]

If walkable areas were defined as polygons instead of as bitmaps, so that you could have overlapping ones, this would be possible.

I have nothing to say against polygons and overlapped regions, but I'd note again that this behavior could be scripted relatively easy in current AGS.
There's already such module by SSH: http://www.adventuregamestudio.co.uk/forums/index.php?topic=29235.0
Also I did this separately on my own some time ago when was helping other ppls project.

[Snarky]

It's actually pretty hard (close to impossible) to script a properly working general solution that handles all the aspects correctly with the current system. The hardest is probably doing correct pathfinding when it involves crossing a hill. And that means the only feasible way to have people walking on the far side of hills right now is through blocking animations and cut-scenes, in which case you haven't really gained that much.

SSH's module is very restrictive, and doesn't support what I would think is the most common requirement: the ability to walk straight up the front of a hill and straight down the back, with the character's feet being in the same x,y coordinate regions during both the climb and the descent. With that module, unless I'm missing something major, you have to make the uphill and downhill regions separate, non-overlapping walkable areas (i.e. you have to go up and down the hills sideways).

[Crimson Wizard]

Hmm, I used same walkable area, but I also used certain trick to make it work properly.
On other hand I was thinking about simple case of "downhill" all the time. So I must agree with your points.

Generic solution will probably require a use of layers? If there is a number of characters walking around the room and you do not want to control their every step, there should be a way to make characters switch between "front" and "back" side of the hill, and the one "behind" the hill.

But I am afraid  this won't be solved merely by overlapping regions. There should be a way to make engine know when to switch character from one layer to another. And also coordinates... how to make character go to certain point behind the hill while he's before the hill? There must be a way to distinguish coordinates on different layers. Those on "beyond" layers should be probably inverted?

I do not see much benefit the polygonal regions could give here. In fact I think masks would be easier to use to make a randomly shaped hill work (again, that does not mean I am against polygonal regions in general).

[Snarky]

Well, with polygon-based walkable areas, you could have one area for the front of the hill and one area for the back of the hill, connected along their top edge(s). You couldn't click on something that was hidden behind the hill, of course, but if the bottom of the hill connected to yet another (visible) walkable area further away and you clicked on that, the pathfinding could work out how to get there. Or you could do a programmatic walkto which specified not just the 2D x,y coordinates, but also which walkable area.

As for how to identify certain of them as being downhill (and therefore using the opposite front-back animations), you could do it in several ways. The simplest would be to just use the scaling: if it has higher scaling at the top than at the bottom, then increasing y-coordinates must mean moving further away, so switch the animations. Or if you want to go more fancy, you could indicate angles or z-coordinates in various ways, up to the point where you're actually modeling the walkable areas in 3D.

I don't think the problem of following the curve of the hill is that important. It's tedious to draw a complex outline of a walkable area however you do it.

But this is one of those cases where AGS uses a simple hack that works OK on typical cases (flat ground) and with low detail (simple animations and low resolution) but not when things get more complicated, while the "right way" (a simple 3D model of each room to handle pathfinding, character angles, scaling and distance sorting, even if the backgrounds and sprites are still 2D), while it is much more powerful and avoids all the little artifacts of the hack, is also a great deal more complex.

Polygons defined in 2D with scaling and z-order, like I believe Scumm used, would get you most of the benefits while either simpler or at least not that much more difficult both for the game authors and for the engine.

[Crimson Wizard]

Well, with polygon-based walkable areas, you could have one area for the front of the hill and one area for the back of the hill, connected along their top edge(s).

Yes, this idea sounds good. Likewise, the "behind" area is connected with "farther" area on the bottom edge. But I guess similarly you may have mask-based areas connect if their outlines match? Can't say if that will be really difficult.
Anyway, thinking of polygons I realized that it is not important to make pixel-matching walkable-areas, it is only important to make pixel-matching walk-behinds.

As for how to identify certain of them as being downhill (and therefore using the opposite front-back animations), you could do it in several ways. The simplest would be to just use the scaling: if it has higher scaling at the top than at the bottom, then increasing y-coordinates must mean moving further away, so switch the animations. Or if you want to go more fancy, you could indicate angles or z-coordinates in various ways, up to the point where you're actually modeling the walkable areas in 3D.

Well, since this assumes adding a new feature to the engine anyway, I'd prefer a normal way of indication be added as well. Angles... hmmm. Sounds cool but a bit complicated.
I'd go for simple "inverted surface" flag for starters.
(Then again, it is unknown when this will be implemented, if ever, so that depends on amount of time ppl would like to spend on this)

I don't think the problem of following the curve of the hill is that important. It's tedious to draw a complex outline of a walkable area however you do it.

I stopped to draw regions by hand as soon as I learned how to import region masks in AGS. I find it much more simple to draw background using layers from start and then convert separate layers into walkable area/walk-behind masks. Otherwise word "tedious" won't express the the process quite enough .



EDIT: I should quit the habit to give quick answers .
The more I think about that "angle" idea the more I like it.
A walkable area with "slope" = 0 means flat surface. When "slope" is increased (up to 90) it means hill and this results in character Y is changing faster than usual to emulate different vector of movement (not just away, but also up). When "slope" goes negative (down to -90) it means opposite side of hill, and when ordered to go away, character actually walks down (and vice versa).

• Category changed from (none) to Regions