Neighbouring maps : triggerless area transition

[youngneil1]

Neighbouring maps : triggerless area transition

This one I had almost finished coding back then when I tried to do an illlusion of seamless maps - I thought mayhaps we can reuse a part of the (modified) idea:

There are different types of areas transitions from a gameplay standpoint:

1. vertically down ( go down ladder, stairs, etc.)
2. vertically up (go up ladder, stairs, etc.)
3. change to zoomed in scale (e.g. from village map into a house map)
4. change to zoomed out scale (from e.g. area map to world map, or from hosue to village, etc.)
5. teleport (this tranistion breaks the logic of connected maps and can be from anywhere to anywhere)

These five types of transition I think work great with the existing triggers for transition. We might use additionally five different kinds of props (read graphic Icons) to help the player quickly grasp which of these five transisition types will happen to the party (like stairs up prop, stairs down down prop, etc.).

But then there's also a sixth type of transition:

6. horizontal tranisition to neighbouring map: in an ideal world our maps would be endless and this type of transition wouldnt even exist. For technical reasons and also for building the world step by step we need to use these artificial seams though. Therefore, we might make this transition as immersive as possible like mayhaps so:

An area gets four new string properties: northernNeighbourArea, southernNeighbourArea, easternNeighbourArea and westernNeighbourArea. They default to blank(""). If the author enters an area name here though, a player pressing or clicking a move arrow Icon or key in direction of border on any square of the respective border of current map is automatically transitioned to the neighbour map defined.

The party will find itself on the very same square after transition that a normal move on a seamless map would have led it to. Therefore, the rules for x,y coordinates after transition will depend on which side the party has left the map (north, east, south or west). E.g. on to move to northern neighbour a party standing on y0,x11 will find itself on the new map on y(mapsize-1),x11, while a move to eastern side from x(mapsize-1),y4 would lead to a new party position on x0,y4 and so forth. The four corner squares would allow transitions in two directions actually in this system, depending on which arrow key/button is pressed.

Such system will make tying up neighbouring maps very easy for authors - no more manual trigger painting required. Furthermore, all walkable squares on map border trigger this transition upon key press/button clcik automatically. This will feel much more organic imho. The border itself will remain playable with this approach as only walking "against" the map border actively will cause the transition to happen.

This system has few map design implications though:

1. Ideally target map is walkable on the opposing side, too. The code must check for this and deny transition with a message to player, like "blocked from other side" to catch these situations.
2. Ideally the maps have the same size (and be square shaped, as it is now already). The code must check wheter an opposing square exists at all, if not again the transition must be denied with some warning message.

Due to 1. and 2. author's best practice might be to keep opposing border squares either both walkable or both non-walkable. In case of differently sized maps neighbouring each other, the larger map should have its extra surplus border squares non-walkable.

3. It might be helpful if - perhaps even drawn automatically by code - a fine green line at the border edge of the border squares would indicate a possible walk to neighbour option and a red line would indicate that this option does not exist here (blocked from other side, no neighbour existing or due to size difference of neighbouring maps). I would prefer to try without these lines for starters and see how it feels though - in this case using non-walkable border squares where neccessary with visible ingame obstacles like cliffs, rock walls, fences, dense wood, whatever. Mayhaps it would be good practice for authors to make players realize the free transitions between neighbour maps via a little tutorial quest early on.

[youngneil1]

And done with writing above text (not coding it already ) .

[youngneil1]

Just to store the idea(s):

Enemy chaser props that are actively chasing the party and are within say 3 squares from party (i.e. nearby) might actually render all transition events (trigger and code to neighbour) inactive. This way there would be no easy cheesing away from dangerous creatures by just crossing a map border - unless either the creature is defeated or the party manages to flee from the chaser by navigating long enough away from it on current map, so that the creature gives up the chase or falls at least more tahn 3 squares behind.

Further down the road, a quick toggle dispalying detection range of chasers migth be helpful, too (or mayhaps some ranger like traits will do so automatically).

[Dorateen]

Hey, this sounds wonderful. I hope it is able to be implemented. One thing I would need personally, would be the ability to designate the border area. For example, Hearkenwold uses 16 x 16 maps, however I have that marble overlay, which eats up 2 squares. Effectively turns each area into a 14 x 14 size. But the design in principle would be most helpful to transition across maps in a large open world.

[youngneil1]

Fine to hear you like the approach, much appreciated . I will try add a borderAreaSize property to the module properties, which will default to 0. For Hearkenwold you could set it to 2 then and the 14th square wille effectively act like the 16th when it comes to the automatic transitions. Let me see ...

[youngneil1]

Yep, that worked out just fine. It's all in the engine now. I must yet just expose borderAreaSize as property of module in the toolset and you should be ready to go .