Blocking characters (such as a door)?

spydaniel · Mon 26/07/2010 23:43:20

I know you can set width and height blocking on objects, but that just won't work for certain perspectives which are on an angle.

Is it possible to block the characters path where filled in pixels exist but not where they don't (transparency)?

Calin Leafshade · Tue 27/07/2010 00:16:38

use a different walkable area for the gap.

then you can enable and disable that walkable area when you open and close the door.

use RemoveWalkableArea(int ID) and RestoreWalkableArea(int ID)

Rocco · Tue 27/07/2010 10:18:28

what can i do, if there are all 15 walkable areas are used?
Whats the best workaround?

Mouth for war · Tue 27/07/2010 10:43:47

hmm...maybe you could use a region? When the character walks onto region you make him stop and then disable that region when he's able to walk through the door?

spydaniel · Tue 27/07/2010 11:04:09

Quote from: Calin Leafshade on Tue 27/07/2010 00:16:38
use a different walkable area for the gap.

then you can enable and disable that walkable area when you open and close the door.

use RemoveWalkableArea(int ID) and RestoreWalkableArea(int ID)

I completely forgot about using another walkable area. Thanks for the help

About the door object, would I set the baseline to 0 so that the character is on top of the sprite and not behind it?

Matti · Tue 27/07/2010 11:12:36

Quote from: spydaniel on Tue 27/07/2010 11:04:09
About the door object, would I set the baseline to 0 so that the character is on top of the sprite and not behind it?

Yep, or at least something higher than where the character stands when he is in front of the door.

Khris · Tue 27/07/2010 11:56:56

Quote from: Rocco on Tue 27/07/2010 10:18:28
what can i do, if there are all 15 walkable areas are used?
Whats the best workaround?

Under normal circumstances you should be able to use one area in two spots and turn it on/off in rep_ex_always depending on the player's position in the room.
It really depends on what's going to happen in the room and the specific layout.

Rocco · Tue 27/07/2010 12:17:26

well i try to use them in different spots if its possible, but in this case its difficult.
i try to make a top-down burglar game, like the clou.
so lets say, you see a large bank with 20 different rooms from above.
the biggest problem are the walking area limitation, cause i need one for every single door,
and cant use it twice. One Door could be open another one is shut, so there must be different areas.

it is for sure possible to activate only the surrounding ares, when you stay in one room,
but this must be the hell of saving states and dealing with vars.

Khris · Tue 27/07/2010 12:29:08

Are there multiple characters controlled by the player?
Do they walk around as usual, i.e. after clicking somewhere, using the pathfinder?

If the areas are rectangular, you can use objects instead, or characters.

Rocco · Tue 27/07/2010 12:39:01

thx for this tipp, this should work without to much complications.
Most of the door-areas are rectangular.

The walking is as usual, and you control only one player Character.

Vince Twelve · Tue 27/07/2010 14:38:46

I ran into this same programming problem (using more than 15 walkable areas) in both Nanobots and Puzzlebots. The problem with having the same walkable area in two parts of the room and then turning them on/off in rep_ex_always is that you have to also force the character to stop, and walk again to get a new path when they cross over to the other side of the room otherwise they might calculate a path through one of the walkable areas that is on now, but will turn off when you get closer, or around one that is off now, but will turn on. If that makes sense...

It wouldn't really matter if the areas were far enough away on a scrolling room, but in Nanobots' case, they were not.

Puzzlebots wound up having a number of invisible blocking characters in one scene that had a very complicated walkable-area-intense puzzle (before the puzzle was later redesigned to be way easier

). Fun times.

Ryan Timothy B · Tue 27/07/2010 20:23:50

Vince, it's been quite some time since I have played Nanobots, but I can't for the life of me think of where you'd need more than 15 walkable areas in that one main room.

Unless each tile had their own walkable area so that you could just turn it off once that muscle robot pushed an object into that square. But couldn't you have just used Object.BlockingHeight to amount for the tile height?

Edit: Ahh, just discovered that the blocking height divides amongst the baseline (20 would be 10 above and 10 below). So then I was about to suggest changing the Object.Z to make it offset for that, but then discovered that object's don't support Z. So the only other solution would be to use character for those gumball machines and such, instead of objects.

Or just use walkable areas, which then end up being a pain in the arse as you've mentioned above.

Vince Twelve · Tue 27/07/2010 22:15:33

Yup, pretty much the same reason you talked about in your edit led me down that path. The problem with using invisible blocking characters is getting other playable characters stuck on them. Since I had to use move (or walk, or just updating the x/y coords, can't remember how i did it) commands that ignore walkable areas when moving the objects around the room, it becomes very possible to set one down on top of another bot and leave them stuck. I had to ninja around some of that and it got messy.

With walkable areas, I could tell more easily if a bot was going to get stuck and move them before the pushing stuff took place.

It also allowed more nice smooth walkable areas around the object rather than big honking blocking squares which, when placed next to each other, would often block a whole row, making it impossible to walk around the desk.

Calin Leafshade · Tue 27/07/2010 23:36:18

It would be nice if walkable areas (and everything for that matter) behaved more like guis & characters in their creation.

Instead of having a list of walkable areas you can create a new walkable area and then have a Game.WalkableAreaCount variable set at compile time.

In fact what would be *really* nice is if objects and stuff were dynamic at runtime.. so like.

Code: ags



oFairy = new Object(some required constructor variables)

although this might be a little redundant for walkable areas unless they had some kind of drawing surface or something..

just thinking out loud... in text form.

Dave Gilbert · Thu 29/07/2010 17:07:50

Quote from: Vince Twelve on Tue 27/07/2010 14:38:46
Puzzlebots wound up having a number of invisible blocking characters in one scene that had a very complicated walkable-area-intense puzzle (before the puzzle was later redesigned to be way easier ). Fun times.

Hah. Is that why it was programmed that way? I have to admit feeling bad about deleting all of that code when we redesigned the puzzle!

Vince Twelve · Thu 29/07/2010 18:12:45

You deleted it?! At least comment it out so it can live on in hiding instead of being removed from existence!

Trust me, if that slider puzzle could have been programmed in a way that didn't use 15 walkable areas and... I don't remember, 9 or 10 characters (visible and invisible) it would have been!