Walkable area and region limit

[Le Woltaire]

I just recognized, that the current limit for walkable areas and regions in one room is 16, right?
I guess it's because of the 16 color painting application.

I have a room where I need 18 walkable areas and regions.
Is it possible to raise the limit even by reusing existing colors?

[GarageGothic]

It would be easier to suggest a solution if you gave a more detailed explanation of what you're trying to accomplish. Do you need them for different light levels, for different walks-onto interactions or something complete different?

With as many as 18 areas it should be quite easy to find two areas that are on entirely separate parts of the screen. If so, you could draw them using the same color, and then in their walk-onto script (or maybe repeatedly_execute, depending on the purpose) you can check for the player coordinates before running the rest of the code. For example, if the character is on the left side of the screen (player.x<160), one script runs, if not, something else happens.

[Vince Twelve]

GG is right.  I made a room with 38 walkable areas using various checks of the player's coordinates.  It's an annoying work around, but it works well. 

The problem is if you need to have certain walkable areas disabled at various times depending on the player's actions, which is the issue I ran into.  If this is the case, having two walkable areas the same color can screw things up greatly since if you turn one of them off, you also turn the other off.  I wound up using a work around that checked for this, and when the player walked from one side of the room to the other, the script would stop him, reset the walkable areas for that side of the room, then start him walking again.  It sometimes had some unintended effects on the pathfinding, and made a small stutter in the animation when the player crossed that invisible line, but it worked well.

[subspark]

Wow, sounds like more trouble than it's worth for the majority. Perhaps CJ could pick some more color values and assign additional walkable area slots to them.

Cheers,
Paul.

EDIT: An 'Add Walkable Area/Region' function coupled with a color picker would be ideal but that will take CJ longer to implement. So I've added it to the suggestions list for a later version.

[Le Woltaire]

I also think that the limit should be raised if there is more than one person with the problem. The number of hotspots has already been increased in that way...

Back to my problem:
I'm scripting a 3 dimensional maze that consists of three levels in three rooms.
Each room needs 18 walkable areas that are assigned to one region. When you step on the region the whole maze changes.
All tree levels in the three rooms become different.
So the 18 regions of one room influence all the walkable areas in the other rooms. A total of 54 regions and walkable areas stand in continuous relationship to each other.

It works like Rubik's Cube but with 16 pieces on each side instead of 9.



The amount of mathematics to keep this maze under control is already very difficult for me. It would be very helpful for me to have clear numbers that I can assign to each of the walkable areas and regions...

I wouldn't want to mess around with coordinates because I believe it would smash my brain...
It already does now...

[Khris]

Depending on how a single (AGS-) room looks like, it might not be necessary to use more than one single walkable area.
E.g. if the walkable areas are drawn like iso tiles, you can use the player coords and a few simple arithmetic operations to determine the exact tile the player is standing on.

This might screw up bigger parts of your existing code, but it sounds like it's worth a try to me. Just speculating here.

[Lt. Smash]

If CJ could change the walkable areas, hotspots, regions to the box matrix SCUMM used, then there could be (nearly) infinite.
It works with simple trapezoids.
You create them, combine them. They can overlap and be as large as you want them. Also 1px thick ones would be available.

[Gilbert]

In fact, as far as I understand, according to the current implementation of the areas, the maximum number of each kind of areas could theoretically be 255 (+1 if you coutn the 'no area' areas, which, IMO, should be MUCH more than enough), so it would not be that difficult to raise those limits. However, a compromise is that how many do we actually need. IMO, having a reasonable limit can prevent people from messing things up by using unreasonably excessive number of areas when it is not required. I agree that the limit of 16 for most kinds of areas is a bit too limiting though, so I think that they could be increased.

[Radiant]

The way you can probably work around this for now, is by keeping careful track of how many other squares the character can move to from his current square.

This is, essentially, why you can mathematically prove it's possible to color a world map with just four (IIRC) colors, without ever having two adjacent countries in the same color.

[subspark]

Radiant has a point here. And its a good one. If you rearranged your walkable areas so that you recycle them but are careful not to place the same walkway too close to the last, then with a little clever scripting you could have the character undergo different states (scale/light/color) depending on where the character's coordinates are. Another way you could handle this is essentially stop your character from being able to go back over a previous walkable area that has been recycled. I know this is rather limiting your gameplay scenario but, doesn't your labyrinth change on the player anyway depending where he is? Reminds me of the movie with the young Jenifer Connelly. "Oh it's just not FAIR!!". 

Hope this helps.
Paul.

[Pumaman]

There's no particular reason why this limit couldn't be raised -- I think this is the first time that anyone has asked for it. If it's a popular suggestion, I can look into it.