---

Intro…

Have you gotten tired of doing the boring move events and calculations yourself? Want to make a TBS on rm2k/rm2k3 but can’t control movements? Well, now you can with this new tutorial series. The aim of this tutorial is to familiarize you with basic movements of an AI and why they move when they need to. Through testing, I have found a way to make an A.I. that actually calculates its movements and chooses the best path. This tutorial won’t really get into that, but it’ll start you thinking about how it all works.

Note: If you already know the basics, skip this tutorial and wait for the more “advanced” ones...

Tutorial: A.I. Pathfinding I
Tutorial Subtitle: Pathfinding Basics
Compatibility: RM2k/RM2k3/RMXP
Coding Difficulty: 2/5
Basic Knowledge: switches, labels, change event positions, forks conditions, variables
Customizability: 1/5

Required Variables/Switches:

Create four variables:

xxxx: Pathfind_X
xxxx: Pathfind_Y
xxxx: Target_X
xxxx: Target_Y

Create two switches:

xxxx: AI_Finder_ON
xxxx: AI_PURGE_ALL

Literary Terms (as used in this tutorial):

Basic AI Model:

An A.I. that can move around on its own isn’t all that hard. In fact, it can easily be done in just one event. What makes it so hard then? Obstacles. Things get in the way and stop the A.I. from getting to point B from point A. Most of the time the A.I. would just freeze there because its coding doesn’t call for it to do much of anything else. Let’s test this out.

Point A ==> Point B:

Create a map with no obstacles whatsoever and then begin creating our AI “model”, or test subject. Create a new event selecting a basic character graphic and making it parallel process (turning on only if switch xxxx: AI_Finder_ON is active). Now we create 4 change variable codes. These will be used to store the position (x , y) of the A.I. and the (x , y) of the target the A.I. must reach. So an example of one of the change variables would be:



You can see that the X coordinate of the AI Model event is being “set” into variable: xxxx: Pathfind_X.

Do that for xxxx: Pathfind_X, xxxx: Pathfind_Y, xxxx: Target_X, and xxxx: Target_Y. Let’s make the “Target” the Hero. So far we should have something along the lines of:



All we do now is a few fork conditions and move events and we’re done! How will the A.I. know if it is above, below, or to far to one side of the target? Fork conditions (no else case) will check for us and commence what we code them to do! Let’s look at an example fork condition:



Let’s break it down. If Pathfind_X is bigger than Target_X, it means the AI is too far to the right. If Pathfind_X is smaller than Target_X that would mean the AI is too far to the left. The same goes for Pathfind_Y and Target_Y. If Pathfind_Y is bigger than Target_Y, then the AI needs to move up. If Pathfind_Y is smaller than Target_Y, the AI moves down! I know that was for the most part redundant, but someone might find it useful. Do what I just explained and you should end up with:



Save your work, place your hero’s starting position anywhere, place the AI’s event anywhere, create an event that turns the switch on at the beginning of the game, and test it.

It easily came to the hero didn’t it? Even if you move around, the A.I. will continue to follow you. Now put a few obstacles in the way (boulder field?) and test it again. The results will vary depending on your “obstacle course”, but the A.I. might not even get close to you now.

Summary:

We created our parallel process model and put in some coding. This coding allowed for continuous checking of they (x , y) of the A.I. and the (x , y) of the target (in our case the hero). We then forked our move events so that the A.I. would move in a certain direction only when needed to.

Stopping Upon Arrival:

This will teach you how to make the parallel process stop if the A.I. is right next to the target. Don’t use this if the target is moving.

Add another page to our AI Model. This should be activated if switch xxxx: AI_PURGE_ALL is ON. Make the start condition whatever you want to happen when the A.I. reaches its target.

Create one more parallel process event (turning on only if switch xxxx: AI_Finder_ON is active). Create another page that is push key, and turns on if switch: xxxx: AI_PURGE_ALL is ON. Go back to our first page. Do our 4 variable changes that stored the coordinates again:



Okay, but how are we going to check if the AI Model is next to the hero? Easy, you add or subtract 1 from x and y. Let’s start by adding one to xxxx: Pathfind_X.



Now we fork (no else case) to see if xxxx: Pathfind_X is equal to xxxx: Target_X. If they are equal, inside create another fork condition to check the y values. If these are equal also, the A.I. is right next to the target! Now inside this new fork, turn on switch xxxx: AI_PURGE_ALL.




Do this for subtracting 1 from xxxx: Pathfind_X, adding 1 to xxxx: Pathfind_X, subtracting 1 from xxxx: Pathfind_Y, and adding 1 to xxxx: Pathfind_Y. Make sure before each fork condition, you have the 4 change variables reset the correct coordinates. If you don’t do this, the next fork will go off of the wrong (x , y)’s.



Once again, save your work, place your hero’s starting position anywhere, place the AI’s event anywhere, create an event that turns the switch on at the beginning of the game, remove any obstacles, and test it.

Once it has reached you give it a few seconds and then move. It should stay exactly where it is (provided you gave the second page of the AI Model a character graphic!).

Summary:

We created a new parallel process event that allows the continuous function of the A.I. to cease when it has reached its target. We check coordinates and tried to figure out if the (x , y)’s could easily be the same by adding or subtracting 1 to the AI Model’s (x , y)

Closing…

And now you’ve learned a few basics to A.I. Pathfinding! I’m skipping intermediate and going straight to Advanced in my next tutorial. A.I. Pathfinding II will cover getting around obstacles using a technique I recently found….

Problems? Comments? Suggestions?
P.M. me and I’ll try to help. Advice and criticism is welcome!

*However, don’t P.M. me with a question that I’ve already answered in the tutorial.*

—ExaltedLegions—

——An ExL Team Production——

Very interesting and helpful, I'll have to try it out

Not bad, but most of it pretty obvious and "noobish" for most of UI's RPG designers.

True, but even if it will only help one person, I'm still going to write it.

You weren't wrong to write it. Thanks for contributing. x3