Making a mini-map with your player represented is one of the earliest things we learned how to do with RPG Maker, but how would you make a mini-display that detects the location of NPCs on the map?
Difficulty: High
Requires: Maniacs Patch
Required knowledge: Variables, a strong understanding of Basic Arithmetic
You will need the following:
Display:
[image: Display.png]
Red Dot:
[image: Red_Dot.png]
Red Dot 2:
[image: Red_Dot_2.png]
Reticle:
[image: Reticle.png]
Set the reticle as your main party member.
To start, make a 40x40 map. Why? Because that's what I'm using and that's what all of my numbers are adjusted to. Once you've learned how to do this, THEN start fiddling with numbers and map sizes.
Common Event 1: Player Tracker
In order to track an NPC, the system needs to know where the Player Character is.
Name Common Event 0001: “Player Tracker”
Set it to Parallel Process.
Do not assign a Condition Switch.
In RPG Maker 2003, a Parallel Common Event without a Condition Switch runs continuously and cannot be turned off.
In the body of Player Tracker, create Control Variable 0001: PX.
In Operation, tick “Set”.
In Page 1 Operand, tick “Event”.
In the first drop down menu, select “Player”.
In the second drop down menu, select “X Coordinate”.
[image: 1745880497676.png]
[center]This sets the system to constantly track your player based on its X-axis position on the map.[/center]
Next, create Control Variable 0002: PY.
Repeat steps 5-7.
In the second drop down menu, select “Y Coordinate”.
This sets the system to track your player based on the Y-axis position. And this completes the Player Tracker event. Since a step counter is not required for a functional RADAR system, it is not included here, but if you were to make a step counter, you would include it in this common event.
[image: 1745867819636.png]
Next, you will need an onscreen event: NPC 1
Since a RADAR tracks the NPCs, you will reasonably need something tracking your NPC. In the NPC's active page, set it to Parallel Process, and in the main body, repeat the process you went through creating the Player Tracker.
Create Control Variable 0003: NX
Create Control Variable 0004: NY
Repeat steps 4-11 from the Player Tracker.
Assign the Event Operand to either “This Event” or the specific NPC.
[image: 1745868255621.png]
Time to Create the NPC 1 RADAR common event:
Start by naming Common Event 0002: “NPC 1 RADAR”, and once more setting to parallel process. Since you want to be able to turn your RADAR on and off, assign Condition Switch 0001: RADAR to this common event. Begin by setting RADAR display. You need not follow my example. You can set it to any position you like. I merely set this 31x31 image to the position 16x16 because it's easy to remember. Then set a second image at 2, your first red dot also set at 16x16.
[image: 1745877892477.png]
Now, that the system is tracking both the Player and the NPC, we need to note the difference in location. So create Control Variable 0005: DiffX.
In Operation, tick “Set”. Ignore the second drop-down menu; it should say "Or".
In Operand, page 3, set drop-down to “Sub”.
Set both Arg to “Variable” in their drop-down menus.
Set Arg1 to “3”, “0003: NX”.
Set Arg2 to “1”, “0001: PX”.
[image: 1745882110574.png]
The reason you're setting NPCX to the first argument and PX to the second is because NX is what you're tracking. You're not trying to find out how far you are from it, but rather how far it is from you.
At this point, your first thought is to simply make DiffY now and try to track positioning with a nested Conditional Branch that is tracking both DiffX and DiffY, but this won't work. The reason is that no matter what you do, it will never track both at the same time. It will first check whichever Condition it meets first, and then check the second condition, in order, so it will only ever display the second condition. If the first condition is DiffX, and the second condition is DiffY, then your RADAR will only ever display the Y position and never the X position, and vice versa.
Control Variable 0006: DiffY is, indeed, your next step, but what you're using it for will be a bit more complicated. Create it the same way.
For 0006: DiffY, follow DiffX steps 1-3.
Set Arg1 to “4”, “0004: NY”.
Set Arg2 to “2”, “0002: PY”.
At this point, your NPC 1 RADAR common event should look like this:
[image: 1745882223794.png]
Now, it's time to actually start tracking this on the screen. We're going to go through the entire process before showing anymore pictures.
Create Control Variable 0007:R-Dot_OffsetX.
In Operation, tick “Set”.
In Operand, page 1, tick “Variable” and select 0005: DiffX.
Next command:
Set your DiffX positioning: Make another Control Variable using 0005: DiffX.
In Operation, tick “Mul”.
In Operand, tick “Constant” and input 6.
Make another Control Variable using 0006: DiffY, and in Operation, tick “Div”.
In operand, tick “Constant” and input 15.
Create a third one of these, and set it to "Sub", 1.
This is setting the range of the Dot based on a scale to the size of the screen. Larger numbers are better since they're more precise. *11/33is better than *1/3, etc. The -1 is being used to compensate for a strange offset in which, if the display is on the left of the map, the dot will want to go slightly off of the left side. And if it's on the right of the map, it'll want to go off the right side. The same issue exists with the Y-axis. If the RADAR display were in the center of the Screen, this wouldn't be an issue.
Repeat all of this 0008:R-Dot_OffsetY, setting all variables to 0008:R-Dot_OffsetY and DiffY.
Now, it's time to start actually positioning the dot. There are four control variables using the final two variables in our system.
Create Control Variable 0009:R-Dot_ScreenX.
In Operation, page 1, tick “Set”.
In Operand, tick “Constant”.
Set constant to 17.
Repeat Control Variable 0009:R-Dot_ScreenX.
Operation, page 1, “Add”.
Operand, Variable 0005: DiffX
Finally, two more Control Variables; Control Variable 0010:R-Dot_ScreenY.
Repeat steps 12-17, switching all variables for the Y variable.
This sets the position of the graphic. Since the RADAR display is 31x31, and we are using a 30x30 range, and since these are set at 16 pixels, which assumes 32x32, from the borders, I initially thought that the center should be 16 for each variable. However, in practice, it's off by one, so 17 centers the dot on the screen. No matter where you start on the screen, the dot will always follow the NPC so it will only be in the middle if you are in the same space as the NPC.
Move Picture command, Picture two:
Display position, in the drop-down menu, Variable.
In the second drop-down menu, Center.
In the first Variable option, 0009:R-Dot_ScreenX.
In the second option, 0010:R-Dot_ScreenY.
Set wait time to zero.
And finally put a wait command 0.0 at the end to take care of any errors.
Finally, we can show an image of what's going on.
[image: 1745887210245.png]
Now, in practice, you're going to notice something. On a 40x40 map, if the NPC is in the middle, and you go out to the edge, her dot's going to stay within the middle to secondary area of that RADAR screen. This is because her position is scaled against yours and you can only get half of the full distance from her. Once she's at the edge of the map, only then will you see her go all the way to edge. Because of this, not only does the RADAR give you her direction, but her general vicinity on the map. But let's say that you'd like to target her and you want to know when you're on the money! Well, that's where the little plus sign dot comes in. Open the NPC's event, and let's get to work. There's only thing left to do, and you can use a nested conditional branch for this one.
Beneath your NPC tracking variables, create a conditional branch: If variable 0001: PX equals variable 0003: NX.
Inside of that branch, create a second branch: If variable 0002: PY equals variable 0004:NY.
Now, simply show picture 3, Red Dot 2.
In both else handlers, place the command, Erase Picture: 3.
[image: 1745887732231.png]
I did make a video, but you can barely see the RADAR.
I have attached the project file.
vvvvvvvvvvvvvvvvv
RADAR Tutorial.zip
^^^^^^^^^^^^^^^^^^
Note: An RMN user suggested that in a larger process, NPCs should be tracked via parallel process in common events, and I would agree, except in the game I was making this for was using the RADAR for space ship combat.
Essentially, you would use the same parallel process logic, but in a common event tracking all the NPCs, which would simplify processing by streamlining it in a single event, and leave you free to event the NPCs however you like. I mention this because that is absolutely a better approach and I would have loved to use it. But for what I made, it wasn't a viable approach.
There was a glitch I encountered where trying to track them via a separate parallel process that DID work, but I couldn't, no matter how hard I tried, get the weapons interactions to work properly. No matter what I did, it kept glitching badly. Here was what I said in reply:
This RADAR took a week and a half, maybe more of experimentation, and forcing things to work. It was made for a spaceship combat game. In that, I don't need to interact with the NPC. I need it to react when I touch it so I know I'm locked on, and then I need it to blow up with a key reaction. That all works best with parallel processes, so there's nothing to interact with. In that situation, having the NPCs control the parallel processes themselves makes them easier to keep track of.
In short, for a system like that, I still wouldn't follow this suggestion, largely because I tried it, and the logic became too complicated to handle in a short game jam. When you need key activations to work, with this process, it becomes too difficult to differentiate the NPCs, and what I found was that no matter what I did, one of three things would happen:
Targeted NPC would blow up properly, but the other NPCs would unspawn.
Targeted NPC would blow up properly, but the other NPCs would no longer be interactable (but still actively firing on you! Unwinnable combat.)
All NPCs would freeze the moment I used the key command. (This was least common)
However, there are scenarios in which you would want to target the NPC and then interact with them. For that, your method would be fine, because that's not a key command. If you've got an external parallel process tracking the NPC and you just want to go up and talk to them, that shouldn't interfere with anything. (And I tested that! When I ran the external parallel process, and I just had the space ships run text that says "I'm supposed to blow up, now!", that worked just fine. But when I wanted to make them do actually do it, I couldn't make it work right.)
