Creating a Local & World Map Mechanic

Would you like to have a map mechanic in your game that shows your player where they are both locally & in the world at large? In this guide I'll show you step by step how to create the very system I use in my own projects for these very purposes.

Introduction:

One of the staples of RPGs are maps, especially local & world maps which the player uses to navigate the game world. As well as to locate various quest points.

In this guide I'll show you step by step how I've set up a "World Map & "Local Map" mechanics in one of my own projects, an open world sandbox with Legend of Zelda style connected field maps, but no overarching "World Map" commonly seen in some JRPGs. As well as how to set up a secondary mechanic to read the player's location, & mark it out on both the "Local Maps" & the "World Map".

All without the use of plugins or scripting.

Requirements & Recommendations:

Requirements:

Plugins: None.
DLCs: None.
Scripts: None.
Additional Programs: None.

Recommendations:

Plugins: None.
DLCs: None.
Scripts: None.
Additional Programs: None.

There are no requirements for this guide, because nothing I am going to show you how to do here, requires anything other than vanilla eventing & some light math.

However, I will make two recommendations, both for the purposes of expanding the potential methods of activating the events we will be creating. Specifically,

1) Yanfly's Main Menu Manager.
http://yanfly.moe/2015/10/17/yep-14-main-menu-manager/

As this will allow you create both a "Local Map" & "World Map" command from your main menu, that will call up the common events we will be creating.

2) Yanfly's Button Common Events.
http://yanfly.moe/2016/01/23/yep-061-button-common-events/

As this will allow you to assign the common events we are going to create to specific key commands.

Understand neither of these plugins are required, you can easily go a completely vanilla approach, & simply have the common events we create be activated via an item, like so.


The important things to remember is to make sure the item isn't a consumable, & to zero out the price so the player can't accidently sell it.

Getting Started:

To begin with we're going to need designate a few variables & set aside a few common events. Now you can call these variables & common events by whatever name you prefer; however, as usual I'll be using the names I assigned to them in the example project, so they'll match with the screenshots I'll be using to demonstrate what I am doing.

So go ahead & identify the following variable & common events in your database.

Variables:
1) Player X Position.
2) Player Y Position.
3) World Map Id.
4) Local Map Id.
5) Region Id.

Commom Events:
1) World Map.
2) Local Map.

Now if you want to have quest markers to serve as way points on your local & world maps you will also need additional variables & common events to use towards that end. I won't be going into any great detail for those however, because while the marker positioning can be affected by mirroring the "Cursor Player" positional settings; how you set up your questing system will greatly effect how they are activated, & a questing system would need to be its own guide entirely. Also how many variables & common events you will need to use, will vary greatly depending upon how you use your quest system.

For example if you are using a single linear quest system, with each subsequent quest being unlocked by the completion of the previous quest, then you can easily get by with only the following.

Variables:
1) Quest Location Id WorldMap
2) Quest Location Id LocalMap
3) Quest Progress

Common Events:
1) Quest Marker World.
2) Quest Marker Local.

However, if you intend for your player to be able to undertake multiple quests simultaneously, either through the use of distinct subquests & the main quest, or by having multiple potential quest giver individuals or factions; as well as see those potential multiple quest markers on their map, the number of Common Events & especially variables will increase.

Finally, you'll need to create placeholder image files in your "Picture" folder, that you can have the Common Events call up. That way if you haven't created your maps yet, or you improve upon them overtime, you need only replace the existing image file/s with the new & improved versions.

At a minimum you'll need one for the "World Map", one for each of the "Local Maps", as well as image files for the "Player Marker", & however many "Quest Markers" you decide to use

The easiest way to create your "Local Map" images to be used when activating the "Local Map" common event, is simply to right click on each of the respective maps files from the main Menu, then simply select the option "Save as image". You can then resize the image file to your desired dimensions.

It's important to note that when you use this method, the various tile features will be saved on the map, but the images used to represent various events won't be. What that means is that if you were to use this method on a dungeon map, the floors, walls, furniture, statues, etcetera would be saved. However, things like Treasure Chests, visible enemies, switches, or any other image file anchored to an event wouldn't be saved to the image file of the map. So things like enemy locations, NPC locations, loot locations, etcetera wouldn't be revealed when the player looks at it; but they would be able to see the general floor plans, & use the map to navigate.

Creating a "World Map" image file can be a bit more complicated. If you are intending to use a standard JRPG "World Map", then you can simply follow the same instructions for the local maps. If you aren't using a world map though, & are instead using a Legend of Zelda style interconnected field maps, you will need to get more creative.

What I did with this project I am using as an example is create a kind of "World Map" in engine that serves as kind of "Satellite picture" of all of the interconnected field maps, based upon their respective terrain features, & positional relations to each other. Like so,


However, if you're more artistically inclined there is nothing saying you can't use something that looks more creative.

Running the Numbers:

Once you've designated your common events & variables, you're going to need to make a couple of decisions, that will determine the math for everything involved in this system. Specifically,

1) Desired Screen Resolution.
2) Default World & Local Map image dimensions.
3) Player & Quest Marker dimensions.
4) Standard Number of Region Ids used.

For the example project in this guide I am going to be using for screenshots, I'll be using the default screen resolution of 816 x 624, the World & Local Map image dimensions are both also going to be 816 x 624 as well, & the marker dimensions are going to be 24 x 24. & a standard Region Id grid of 10 x 10, totaling out to 100 regions for each map.

Now understand you don't have to use these numbers for your own project, I am simply using them as an example of what you can do. So that you'll understand the reason behind everything in regards to the example project used for screenshots. Feel free to disregard any of my own recommendations, in favor of whatever you think will best serve your project.

The reason for using the the default screen resolution should be obvious, it's the standard setting for the engine. & while the screen resolution can readily be increased beyond that by various plugins, I don't recommend doing so, unless you have a specific reason that a larger screen resolution would serve your project better.

I match the default picture image file's dimensions to the screen resolution, because I am not using any kind of secondary image file to as a framing UI, & to take advantage of the full potential space available to provide greater potential image detail. Also because by maintaining a universal map image file size, coordinate positioning for the markers only needs to be calculated once, & can be applied universally across all image files, rather than calculated & then evented individually to each potential conditional branch. More on that later.

I set the markers at 24 x 24, because at the default screen resolution it is an ideal size. Larger enough to be readily visually discernible, while small enough to minimize obfuscation of map details that it is overlaid on. I recommend that you don't go smaller than that, & don't go larger than 48 x 48 though.

This size also has the secondary benefit of being large enough that individual markers can be readily discernible from each other. A desirable quality if you happen to use multiple quest markers, to indicate quests given by different factions or quest givers.

If you're not familiar with Region Ids, region ids are the "R" tab on your tileset of each map. The number superimposed over the color, represents the "Region Id" that will be read on any map tile painted with it. See below.



Finally for regions I use a 10 x 10 Region Id grid, for each of my maps regardless of what the maps particular dimensions are. Once finished the map will look like so, when you click on the "R" tab of your tileset.


I do this for two reasons; primus it allows me to designate 100 specific coordinate points, to be reflected in marker format when overlaid onto map image files, without requiring unique positioning calculations for each map based on their respective dimensions, which dramatically reduces the size of the common event. Secondus it allows me to use the remaining region Ids to apply secondary characteristics via mechanisms that operate off of regional ids, while still using them to mark out positional coordinates.

For example, if you were using
1) Yanfly's Region Battlebacks http://yanfly.moe/2015/12/27/yep-52-region-battlebacks/
2) Yanfly's Region Events http://yanfly.moe/2015/10/19/yep-17-region-events/
3) Yanfly's Region Restrictions http://yanfly.moe/2015/10/20/yep-18-region-restrictions/

To apply various properties, you could use Region ID 13 & Region ID 113 to read as the same Player Marker coordinates, when your "Local Map" Common Event is activated. While assigning unique properties like a specific event, or NPC movement restrictions to region Id 113.

However, be aware that there are only 255 potential Region Ids; 256 if you count the "0" Id, i.e. any tile having no assigned region id to it. Which means that at most you can only have a 16 by 16 region grid. Also you might want to consider using a 9 by 9 Region Id grid, if you use a large amount of region control mechanics/plugins like the region plugins from Yanfly I've already listed. As this will allow you to have three different potential Region Ids, that will all read as the same relative position.

World Map Part 1:

Once we've established our numbers it's time to set up our events. We'll begin with the simpler event of the "World Map".

This event will actually function in nearly identical fashion to the "Local Map" common event if you use a standard JRPG "World Map" in your game. So I am only going to go over the version, based on you not using a "World Map", but only interconnected "Local Maps". In each of your maps you're going to create a parallel process event, that alters the required variables to their desired amounts, whenever the player enters that map, like so.


I recommend placing them in the upper left hand corner of your maps, for two reasons. Primus, so that you always have them in same spot in all of your maps; & secondus because if you are using map border transitions for interconnected maps, you wouldn't be able to reach it without touching a transition point first anyways.

Now because I am not using a "World Map", only interconnected "Local Maps", the variable "World Map Id" is used for two purposes the first to determine whether or not to display the world map image which I'll explain later, the second to determine the location to place the player marker on the world map image.

These parallel processes on each of our maps, are what common event "World Map" are going to rely upon to work. To being we will use the conditional branch option,



& then have it check if the "World Map Id" variable = 0, with an else deviation checked like so.


That way if we don't want our world map to be visible for whatever reason, we can set the "World Map Id" variable to "0", & any value other than "0" will cause the world map image to pop up like so. While "World Map Id" = "0', in the case of my example project will cause a sold black image file to display instead.


Because I am using an image file that's intended to take up the full screen, I keep the X & Y coordinates at "0" & "0"; along with setting the image file origin to "Upper Left", like so.



"0" & "0" represent the starting X & Y coordinates for each potential image, or the upper left corner of the screen. & the images "Origin" represents which point of the image file will be placed at those coordinates. In this case, the "Upper Left" corner of the image file, will be placed on "0" & "0" or the upper left most point on the screen.

World Map Part 2:

Next we need to set up our player marker locations based off of the value of the "World Map Id", this is going to require a bit of math on your part. As you're going to have to determine the position of each field map relative to each other, & how many field maps you have.

You might be asking "what do I mean by field map", what I mean is the particular local field area of one of more maps all occupying relatively the same territory. For example, a "Field map" of given city, will obviously have the various secondary maps that serve as building interiors. Another example would be a forest map, that has a cave "Dungeon" map or maps entrance attached to it.

Now you don't need to know in advance how many buildings are going to be in each city, or how many floors a given dungeon will be, as obviously they are all occupying the same general space allocated to that city's or that forest's respective "Field Map". But you do need to know how many if any field maps are to the North, South, East, & West of that city's field map or forest's field map respectively.

If you haven't determined that yet, you might want to leave off this second component of the common event, until you've made those determinations; & just use a placeholder image for the first half of the event, until you do.

However, I'll go ahead with project I am using as an example, & you can adjust your own math accordingly.

For this project I am using a total of one hundred "field maps", on a ten by ten grid. Any "Interior" maps or "Dungeon" maps, I'll give the same "World Map Id" value to as their respective entry point "Field Maps", because their entrances are found in their corresponding "Field Maps". However, their "Local Map Id" values will be different.

So I'll need to use conditional branches again,



& I will need a total of one hundred based on evaluating the "World Map Id" variable like so,



Then for each conditional branch I need to determine the relative position in pixels from the upper left corner of the screen, i.e. the "0"/"0" point I want the player marker to be. A relatively simple matter of because we already know our screen resolution, & the number of field maps.

Each of the one hundred segments is represented by X 81.6 pixels by Y 62.4 pixels, yes I am aware that most basic image manipulation software doesn't deal in smaller than single pixel increments; however we're including the decimal points to factor in our relative positioning to keep it more accurate. & not for the purposes of actual image manipulation.

So our upper left most player marker position, we will want within that range, specifically centered at 41 X by 31 Y, like so.



Unlike the world map image file, we want our player marker image file centered on the coordinates we provide, so we put the image origin to "Center", & use direct coordinates to tell it where to anchor. & we want the "Player Marker" to have a higher "Picture Number" than our world map image, so that it will be given display priority over the world map image.

Each subsequent migration from our default X 41 & Y 31, we'll add the the necessary X 81.6 & Y 62.4. So for example "World Map Id" = "37" will give us the coordinates of X 530 & Y 218.

Finally we need to create a mechanic to close out our "World Map" common event. Now, removing the world map image file & the "Player Marker" image file is easy enough, just select the "Erase Picture" option from the common event menu like so,


& erase the corresponding "Picture Numbers". However, if we leave our event as is, then the pictures for our world map & player marker will display, & then be erased near instantaneously. So we need an interceding event so that the player peruse the map at their leisure.

To that end we are going to create an empty dialogue box, that pops up between the image files for the world map & player marker being called up, & those image files being erased, like so.



That way, while the empty & transparent dialogue box stays open the world map & player marker image files stay up, but as soon as the player presses the action button again that will close the dialogue box, the final components of the common event that will erase the pictures will take effect as well. Which should look something like this once you're finished.


I would also recommend placing a copy of the empty dialogue box & "Erase Pictures" common event actions right below your equivalent to my blackout image, pulled up when "World Map Id = 0" conditional branch is activated. If you don't want the player marker & quest marker/s to appear on a map your player can't currently see.

Local Map Part 1:

Now the "Local Map" common event is more complicated, because there are considerably more potential images to be selected from, which dramatically increases our number of conditional branches. How much more, will of course depend upon the number of different maps you intend for the player to have access to. Will they be able to use "Local Map" in dungeons? WIll they be able to use "Local Map" in building interiors? That will be for you to decide.

Understand though, that unlike the world map mechanic it doesn't matter if you haven't decided yet. If you decide to add another local map the player can see, you merely need to add another conditional branch based on the maps assigned "Local Map Id" variable value. If you change your mind about having the player being able to see a particular local map, just change the parallel process event in that particular map's corner I discussed earlier "Local Map Id" variable value to "0".

Now to begin, we'll set up our "0" value "Local Map Id" conditional branch, like so.




To account for any area where you don't want the player to access their "Local Map". Also like the "World Map" I recommend placing a copy of the empty dialogue box & "Erase Pictures" common event actions right below your equivalent to my blackout image, pulled up when "Local Map Id = 0" conditional branch is activated. If you don't want the player marker & quest marker/s to appear on a map your player can't currently see.

Then you'll need to create a conditional branch for each individual local map image file the player will potentially access, via the same method. Just like the world map image before, we'll set each Local Map Image's origin to "Upper Left", & its coordinates to "0" by "0", because we want to use the full screen for our image files.

Local Map Part 2:

Once you've completed the various conditionals to determine which local map image will pull up, you'll need to determine the "Region Id" of the player's current location, however a tiles region id isn't something that we can check for with a conditional branch. So we need to convert the tile's region id the player is currently occupying, into a variable value we can evaluate in a conditional branch. To do that we're going to use the Common Event Option "Control Variables", & link the players "X" & "Y" positions with the variables of "Player X Position" & "Player Y Position" we've already created, like so.





Once we've turned the player's current "X" & "Y" positions into variable values, when can then tell the event to evaluate the Region Id of that position, & set our created variable of "Region Id" to match that value, like so.



We can then use the variable "Region Id" as the determining factor for the conditional branches, just as we used "World Map Id" to determine our player marker image relative position, like so.






Additionally, if we use the same 10 by 10 Region Id grid layout on all of our maps, we don't need to layer the conditional branches that evaluate the "Region Id" variable into each conditional branch of the "Local Map Id" eval.

Instead we can have the same coordinates for each "Region Id" variable value, so long as the image file representing that map is of the same size. I.e. it doesn't matter if our map is 50 x 50, 100 x 100, or 250 x 250; so long as we use the same Region Id grid layout in all of our maps, & the image files we use to represent those maps are the same dimensions.

Simply put, a 50 x 50 map will be 5 x 5 per region, a 100 x 100 map will be 10 x 10 per region, & a 250 x 250 map will be 25 x 25 per region. However, so long as the image files I use to represent those three distinct map sizes are all 816 x 624, I can use the same coordinates derived from the value of the "Region Id" for each map's region. The only difference will be in how "zoomed in" or "zoomed out" the view of the map is.

In fact, because I am using a 10 x 10 Region Id grid, & my world map image represents 100 interconnected field maps also on a 10 x 10 grid; I can use the positional coordinates already calculated in my "World Map" event, & simply change the criteria evaluated in the conditional branches from the variable of "World Map Id" to "Region Id".

Finally, as with "World Map" event we've already created, don't forget to create the empty dialogue box, just prior to the erasure of the image files that represent the Local Map & the Player Marker, like so.

Alternative Methods Part 1:

Now you might be inclined to ask, do I have to use region ids that seems like a lot of work? Isn't there any way I can use common eventing to calculate out my players position, & use that to place a marker on my "map image" to indicate where my player currently is; without having to paint out regions on maps? & isn't there a way to more accurately represent my player's position, rather than just the general areas they are in?

Yes in point of fact there are ways to do so, & I am not going to tell you not to use those methods. In fact I'll go over them here, & explain why I did not use those methods, based on their respective Pros & Cons.

Method 1: Direct Representation.
First let's look at using a method of direct representation, without region id evals.

We'll still use our variable of "Local Map Id" for conditional branches to determine what local map image to pull up with the event, we will still use our variables "Player X Position" & "Player Y Position" to determine location, & then we'll use them to determine the position of the player marker, like so.






Seems simple enough, so what is wrong with using this method you ask?

First while it will more accurately demonstrate your players position, it will only do so if you shrink your map image to be pulled up, to a size of 1 pixel equaling 1 tile. I.e. a 50 x 50 Map needs to be 50 x 50 pixel image, a 100 x 100 Map needs to be 100 x 100 pixel map. & it will also have to be anchored to the upper left hand corner of the screen.

This creates a few problems, which was why I didn't use this method.

1) Aesthetically speaking it doesn't look very good for the map to be in some far off corner, while the rest of the screen is empty.

2) When your player character is near the "Northern" end of your map, the player marker will either entirely or nearly entirely disappear.

3) With smaller maps the image will be so small it will be nearly illegible, especially with the player cursor blocking a good bit of it.


Method 2: Direct Representation with Additive Variable.
At this point you might be asking, well is there a way to fix any of those problems?

Yes, we can relocate the image file you use to represent Local Map, by adjusting the X & Y coordinates of the picture placement to a more centered on the screen location, instead of the usual "0" by "0". Which will remove our aesthetics problem, as well as the image file for the player marker being entirely or nearly entirely off screen if the player is too far "North".

However, make sure you keep the image file "origins" as "Upper Left". You'll then need to compensate for the reposition, by adding a second layer of variable control to compensate for the map image file's relocation from "0" by "0". Specifically the coordinates you set for the "upper left" for your Local Map Image. So if you set the "Origin" to "Upper Left" & the coordinates to "X 150" & "Y 150", after you have read your players "X" & "Y" coordinates, you'll then need to add a second value to of 150 to both your "X" & "Y" variable, like so.




Make sure that you add the compensating variables value, after your variables have have been derived from player's "X" & "Y" positions, not before though. Compensating value won't be retained, if you derive the variable value from the player's position afterwards.

However, you will still have the problem of smaller maps, having very little visible detail, because your visual image will still have be at a ratio of one pixel for each tile square.

Additionally, unless all of your maps are the same dimensions, you'll have to layer your variable controls & Player Marker placement into each "Local Map Id" conditional branch eval. Because each Local Map image will have different properties based on where you position it due to the image file's respective size, & by extension the map it represents respective size. Which is going to greatly increase the size & complexity of your common event.

Alternative Methods Part 2:

Method 3: Direct Representation with increased image file size.
Now you might be thinking, okay well is there a way to increase the various Local Map image file sizes so that the details of the map are legible, & perhaps while also having a universal coordinate system to reduce overall complexity of the common event?

Yes, however there will be few requirements. First to increase the image file size of the local maps, while still using direct positioning you'll have to add another layer of variable control. This means that you'll have to set up the initial sync between the variables "X Player Position" & "Y Player Position" & the player's current position just like before.

Then you'll need to add a second variable control where the variable value defined by the players position is multiplied by a set value, like so.


The key point of this particular portion though, & the inherently limiting factor of it, is that the variable control options can't use decimal values in the operations. Ergo, the dimensions in pixels of the image file, must be such that it can be divided by the number of tiles in a given map, without producing a number with a decimal value. Because otherwise that decimal value will be added with each subsequent tile, so that the positioning becomes more & more inaccurate as the player goes "South" & "East" on the map.

& then finally a displacement variable value will need to be added afterwards just like the previous method, to account for the preset deviation from "0" by "0" of the local map image file "Upper Left" corner is anchored to.

Simply put, via variable control three actions must be taken.
Step 1) Variable "X Player Position" = X Player position.
Step 2) Variable "X Playet Position" * (set factor).
Step 3) Variable "X Player Position" + (X value of "Upper Left" position of Local Map image file)

However, to maintain a universal coordinate set, will require that all of your maps are of the same dimensions in tile size. Meaning you either dramatically increase the number of maps by going with smaller maps, or have numerous maps that are unnecessarily large to meet a designated size requirement.

If you don't use a universal map size, each individual Local Map Image, while have its own positioning criteria from the "0" by "0" point, & by extension it's own additive value to for the "X Player Position" & "Y Player Position" variables. As well as their own multiplying factor to increase the dimensions to allow you to increase the image file beyond a 1 pixel = 1 tile ratio.

Which will of course need to be layered into the "Local Map Id" conditionals, thus adding a good bit of complexity to the common event.

Method 4: Conditional Eval of X/Y Positioning.
Finally, you can match the "X Player Position" & "Y Player Position" variable values to the player's X & Y position respectively just like before, & then use conditional branch evals to determine specific coordinates for player marker.

However, this shouldn't be considered a desirable method by any stretch of the imagination. Because, even if you use the same dimensions for all of your image files, & the same map sizes for every single map, it will still be the largest common event out of all the possible options.

A standard issue 50 by 50 tile map will have 2,500 conditional branch eval outcomes to be checked, & a max sized map of 256 by 256 tiles will possess 65,536 possible conditional branch eval outcomes to be checked.

Quest Points/Way Points:

I am not going to go into any great detail here, regarding quests, because how you manage your quest system will greatly influence the ideal way to set up quest markers & way points. I will however provide a couple of examples to consider.

Method 1: Single Quest Line System

If you are using a simple linear quest system where the character goes from one quest to the next, following a set main story line, you shouldn't need more than the following.

Variables:
1) Quest Location Id WorldMap
2) Quest Location Id LocalMap
3) Quest Progress

Common Events:
1) Quest Marker World.
2) Quest Marker Local.

For markers to be seen with the "World Map" common event, simply attach the "Quest Marker World" common event to the tail end of "World Map" Common Event prior to the blank dialogue box, like so.


& then in the common event "Quest Marker World" simply parallel how you've set the Player Marker in your "World Map" common event. Using the Variable "Quest Location Id WorldMap" as the variable to evaluate in your conditional branches. I would also set a "Quest Location Id World Map = 0" conditional branch, that doesn't apply a quest marker, for when you don't have a current active quest.

For markers to be seen with the "Local Map" common event, we will need something more complicated though. I recommend attaching the "Quest Marker Local" common event, to the tail end of the "Local Map" common event, much like we did with the "World Map" event.

Then in the common event "Quest Marker Local", create various conditional branches based on evaluating the value of the "Quest Progress" variable. Just like with the "Quest Marker World" common event, I recommend you have a "= 0" condition for when you don't have an active quest.

Then create subsequent conditional branches evaluating the "Quest Progress" to represent the various points in the storyline as the player acquires quests. With a second conditional branch layered into the "Quest Progress" conditional branches that will evaluate what map the player is on via checking the "Local Map Id" variable, so that the marker only pops up when the player is on the correct local map.

Followed potentially by a third conditional branch if the quest marker will shift across multiple points on the same map, for example a "gopher" type quest between various NPCs in a given town. Or to determine when a quest marker will appear on each of its potential local maps, like so.


This way, the quest marker won't appear on the Local Map Image, unless all of the criteria for the conditional branches are met.

Method 2: Multiple Quest Line System
On the other hand, if you are having the player potentially undertaking multiple quest lines at the same time; for example your project has a primary quest route, but also several secondary quest routes attached to factions like a Fighters Guild, a Mages Guild, a Thieves Guild, etcetera; then we are going to have to undertake a slightly different method.

First, you're going to need to increase the number of variables you have designated for quest marker evals. You can mirror how we used the variables & conditional branches for the "Single Quest Line System" easily enough. But each potential simultaneously operating quest, will need it's own variables to activate the quest marker positions, by conditional branch evaluations.

Then just like with Single Quest Line System, I recommend you attach the "Quest Marker World" & "Quest Marker Local" common events to the tail ends of your "World Map" & "Local Map" events respectively, but prior to blank dialogue boxes & "Remove Picture" component of the event.

However, depending upon the number of quests you have, & the number of factions or recurring quest givers, you might want to consider further subdividing the common event via conditional branches that evaluate triggers.

For example continuing with our hypothetical project of a main quest line, as well as various guilds respective quest lines. Consider creating triggers like "Main Quest Active", "Fighter Guild Quest Active", "Mages Guild Quest Active", etcetera to be turned on when a quest becomes active; & then attaching conditional branches that will check for these triggers being on in the "Quest Marker Local" & "Quest Marker World" events.

Then attach to the those individual subset trigger conditional branches, common events that contain the various conditional branches for only that particular subset of quests. This will keep your common events more compact, & will also have you bypass all the potential evals attached to inactive quests.

Simply put, if your player only currently has an active quests from the "Main Quest Line" & the "Mages Guild Quest Line"; then when the attached "Quest Marker Local" or "Quest Marker World" is called up, all of the conditional branch evals in the "Fighters Guild Quest Line", "Thieves Guild Quest Line", etcetera will be sidestepped because the activating trigger isn't currently on.

Understand though, this isn't intended as a "You must do it this way", but rather a "You could do it this way"; & is highly contingent upon how you have set up your respective quest system to operate. Again, something that should be an entire guide unto itself.

Map Restrictions:

Finally, there is the possibility of making your maps an acquirable item/s, whether through purchase in shops, finding them in loot, as quest rewards, enemy drops, etcetera. The method you decide for your player to acquire them doesn't really matter, you can use whatever you like.

If you are so inclined though, it's actually a rather simple mechanic to set up, using what we've already created.

First, did you create "World Map Id = 0" & "Local Map Id = 0" conditional branches that don't display a map image yet? You'll need those for this to work, as well as the upper left hand corner event that runs as a parallel process that sets the values of "World Map Id" & "Local Map Id" in your maps.

Second, you'll need to set up the first page of the event to set the "Local Map Id" Variable to "= 0", like so.


Third, you'll need to set up a second page of the event to set the "Local Map Id" variable to the desired value, so that the appropriate Local Map Image will display when "Local Map" is called up. & have a conditional of the player having the desired map item in their possession, like so.


It's very important that the "=0" page be the first page; as events with multiple pages will start from the highest numbered page, that all of the checked conditionals are active on. So if our event page where the variable is set up to put the "Local Map Id" value at "= 0", without any conditionals is a higher page number, it will still apply, even after we meet the conditional we set up on the event page that changes the value of "Local Map Id".

You can use this very simple mechanic for none, some, or even all of your maps. Make the world map a quest reward for example, or make local dungeon maps something the player finds by exploring. It's all in how you want to set it up.

Summation:

Understand, nothing in this guide is intended as the be all, end all, authoritative you must do things my way.

It's merely intended to expound upon a potential method, feel free to use some, all, or completely disregard its contents. To use the alternative methods I discounted in place of the method I used. To use plugins instead because you don't want to use so much eventing, etcetera.

It's up to you to decide what best serves your project.

[korawit131]

Thank you for your guide.

[KarlMalonesGhost]

Can you post a link with some footage of it in action?