A NEW QUESTION

I can't believe I am writing this because if you are asking this sort of question you probably won't understand the tutorial but:



The easiest and lamest method:

- Put down "on touch" events that teleport the hero back to the start or whatever. This creates the illusion of the sentry spotting your hero but is not very flexible.


PROBLEMS WITH THIS METHOD:

- It sucks.

- It is extremely tedious to add new sentries.

- Your sentries are immobile.


BENEFITS WITH THIS METHOD:

- It's really easy to do but it still sucks and limits your game design so much you might as well not even bother.




The most effective method that is still pretty easy to make and will create sentries that can move around:


PROBLEMS WITH THIS METHOD:

- The sentry will see through walls and crates and such. Incorporate this into your map design. Make your walls several tiles wide and do not put a bunch of things on the map that it would seem as if the player could hide behind. If you do want to put down some crates, make sure it is a huge bunch of crates many tiles wide and tall.

- The sentry is not entirely modular and will require you to edit each event that you copy down on the map. However, these adjustments are very minor and insignificant compared to setting down touch events manually for every sentry.


BENEFITS TO THIS METHOD:

- Your sentries can walk around.

- It requires much less manual editing to copy than a sentry that relies on events.

- While a few variables need to be edited for each sentry as RPGMaker does not support local variables, all commands will be contained to just one event so it will be much neater. Also, your game won't start to lag from having a million events.

- It does require you to use a lot of event commands but does not require you to code in RGSS.


HOW TO DO IT:

- Set the sentry to be a parallel process event. Make sure you add a wait at the end so that your game doesn't get stuck in a loop (0.0 or 0.1 frames or whatever depending on your iteration of maker).

- Call a common event. Put all the rest of these commands inside of the common event page. Each sentry will need its own common event. To make it easy on yourself, set up 5 common events called sentry1, sentry2, etc, so that your system will support five sentries on each map. You can add more if you please.

- Set variable hero x to equal the hero sprite's x location.

- Set variable hero y to equal the hero sprite's y location.

- Set variable sentry1 x to equal Current Event x location (your sentry is the NPC who is looking for the hero; note that each sentry will need its own variables)

- Set variable sentry1 y to equal Current Event y location (again note that each sentry will need its own variables or you will have really odd bugs)

- Set up variables sentry2 x, sentry2 y, etc up to sentry5 x and sentry5 y.

- You'll now have to create a check that will establish whether or not the sentry notices you. In most stealth games the sentry can see in front of him, so we'll create a box where the sentry can see. We'll set the visibility range to 4 tiles so that your sentries can't see through really thick walls. It is probably dark where your characters are sneaking so it makes sense that the sentry can only see a few yards in front of him. Plus, if you've ever played Metal Gear Solid you are probably familiar with how completely blind and deaf video game sentries are (it's more fun to sneak up on and kill stupid people I guess)Illustration:

The "o" is the location of the sentry and the exclamation marks represent the tiles where the sentry can see you.

xxxx| . . . . . . . . . |xxxxxxx
xxxx| . . . . . . . . . |xxxxxxx
xxxx| . . . . . o . . . |xxxxxxx
xxxx| . . . ! ! ! ! ! . |xxxxxxx
xxxx| . . . ! ! ! ! ! . |xxxxxxx
xxxx| . . . ! ! ! ! ! . |xxxxxxx
xxxx| . . . ! ! ! ! ! . |xxxxxxx
xxxx| . . . . . . . . . |xxxxxxx
Sentry can see in front of him.

xxxx| . . . . . . . . . |xxxxxxx
xxxx| . . . . . . . . . |xxxxxxx
xxxx| . . . . . o . . . |xxxxxxx
xxxx| . . . ! ! ! ! ! . |xxxxxxx
xxxx| . . . x x x x x . |xxxxxxx
xxxx| . . . ! ! ! ! ! . |xxxxxxx
xxxx| . . . ! ! ! ! ! . |xxxxxxx
xxxx| . . . . . . . . . |xxxxxxx
Note that the sentry can see through walls. This is a limitation of this script. Solution:

xxxx| . . . . . . . . . |xxxxxxx
xxxx| . . . . . . . . . |xxxxxxx
xxxx| . . . . . o . . . |xxxxxxx
xxxx| . . x x x x x x x |xxxxxxx
xxxx| . . x x x x x x x |xxxxxxx
xxxx| . . x x x x x x x |xxxxxxx
xxxx| . . x x x x x x x |xxxxxxx
xxxx| . . . . . . . . . |xxxxxxx
Make your obstacles large so that the sentry cannot see through them. If this limitation really bothers you then learn how to program and make an RGSS script instead of using this lame event crap like I do. Anyway, this method will be suitable for areas such as hallways or wide open fields.


- Now, create a condition that has four branches: one for the current event facing up, one for facing down, one for left, and one for right. In older RPGMakers these were called "forks" so you might have one of those.

- Add nested commands inside of those conditions that perform that actual check as to whether or not you have been spotted. This is the important part. Your script will end up looking sort of like this:

NOTE: Variable commands in proper programming and in new RPGMakers use a kind of shorthand.
+= means "add to current value"; e.g. if x = 10, x+=5 means "10 + 5 = 15" or "x already equals 10, and now I want you to add 5"
-= means "subtract from current value"; e.g. if x = 10, x-=5 means "10 - 5 = 5" or "x already equals 10, and now I want you to subtract 5"
== means "set to this value"; e.g. if x = 10, x == 26 means "change x to 26 regardless of what its current value is"

NOTE: If a conditon is indented it means it goes inside the other condition. EG:

Condition: blah
Condition: blah

The second condition is inside of the first condition.


FOR SENTRY EVENT:

Event start, Parallel Process
Call Common Event: Sentry1
Wait: 1 Frames/0.1 Seconds
Event Close



FOR COMMON EVENT: SENTRY1

Event Start
Variable Sentry1 X == Sprite Location Current Event X
Variable Sentry1 Y == Sprite Location Current Event Y
Variable Hero X == Sprite Location Player X
Variable Hero Y == Sprite Location Player Y
Variable Sentry1 X -= Hero X
Variable Sentry1 Y -= Hero Y
Condition: Current Event is facing DOWN
Condition: Sentry1 Y < 0
Condition: Sentry1 Y > -5
Condition: Sentry1 X < 3
Condition: Sentry1 X > -3
This is where the failure event occurs
End
End
End
End
End
Condition: Current Event is facing RIGHT
Condition: Sentry1 Y < 3
Condition: Sentry1 Y > -3
Condition: Sentry1 X < 0
Condition: Sentry1 X > -5
This is where the failure event occurs
End
End
End
End
End
Condition: Current Event is facing LEFT
Condition: Sentry1 Y < 3
Condition: Sentry1 Y > -3
Condition: Sentry1 X < 5
Condition: Sentry1 X > 0
This is where the failure event occurs
End
End
End
End
End
Condition: Current Event is facing UP
Condition: Sentry1 Y < 5
Condition: Sentry1 Y > 0
Condition: Sentry1 X < 3
Condition: Sentry1 X > -3
This is where the failure event occurs
End
End
End
End
End
Event Close



Copy and paste all of this into 5 separate events, incrementally increasing the numbers each time. Common Event Sentry2 will refer to variables Sentry2 x, sentry2 y, etc. The variables Hero X and Hero Y do not need to be changed for each common event because the location of your hero will always be the same regardless of which event is referencing it, so it is not a problem that many different scripts are always changing the value (they will change the value to the same thing).

IMPORTANT: Each sentry on your map must refer to a separate sentry common event or you will encounter strange bugs. Make sure you keep track. If you want more than 5 sentries, than you can easily add more common events. You can reuse your common events on the next map, but not on the current map. So if you teleport to a new map, you can just copy and paste your old sentries over.

NOTE: When you have an event call a common event, all "current event" commands refer to the event that called it. That's why the common event calls "current event" all the time.

NOTE: You can set your sentries to have specific movement paths, to wander randomly, whatever. As long as they have that one line that refers to a common event, they will have an AI that will do all the legwork for you. This is how efficient game making works.

NOTE: You can increase the sentry visibility by increasing the absolute value of the greater than/less than checks in the AI portion. For example, changing the checks to:

Condition: Current Event is facing DOWN
Condition: Sentry1 Y < 0
Condition: Sentry1 Y > -13
Condition: Sentry1 X < 4
Condition: Sentry1 X > -4
This is where the failure event occurs
End
End
End
End
End

Will result in a range that looks more like this:

xxxx| . . . . . o . . . |xxxxxxx
xxxx| . . ! ! ! ! ! ! ! |xxxxxxx
xxxx| . . ! ! ! ! ! ! ! |xxxxxxx
xxxx| . . ! ! ! ! ! ! ! |xxxxxxx
xxxx| . . ! ! ! ! ! ! ! |xxxxxxx
xxxx| . . ! ! ! ! ! ! ! |xxxxxxx
xxxx| . . ! ! ! ! ! ! ! |xxxxxxx
xxxx| . . ! ! ! ! ! ! ! |xxxxxxx
xxxx| . . ! ! ! ! ! ! ! |xxxxxxx
xxxx| . . ! ! ! ! ! ! ! |xxxxxxx
xxxx| . . ! ! ! ! ! ! ! |xxxxxxx
xxxx| . . ! ! ! ! ! ! ! |xxxxxxx
xxxx| . . ! ! ! ! ! ! ! |xxxxxxx
xxxx| . . . . . . . . . |xxxxxxx

Do not change the zero values, though; those are important in determining that the sentry only sees forward. If you were to change that value so that the script looked like this:

Condition: Current Event is facing DOWN
Condition: Sentry1 Y < 2
Condition: Sentry1 Y > -5
Condition: Sentry1 X < 3
Condition: Sentry1 X > -3
This is where the failure event occurs
End
End
End
End
End

xxxx| . . . . . . . . . |xxxxxxx
xxxx| . . . ! ! ! ! ! . |xxxxxxx
xxxx| . . . ! ! ! ! ! . |xxxxxxx
xxxx| . . . ! ! o ! ! . |xxxxxxx
xxxx| . . . ! ! ! ! ! . |xxxxxxx
xxxx| . . . ! ! ! ! ! . |xxxxxxx
xxxx| . . . ! ! ! ! ! . |xxxxxxx
xxxx| . . . ! ! ! ! ! . |xxxxxxx
xxxx| . . . . . . . . . |xxxxxxx

. . . your sentry will have eyes in the back of his head!





So, this should probably work really well. There might be bugs or something so if you use this method let me know and I can help you out. Either way, this is probably the best way to make robust sentries with admitted limitations that does not require sophisticated coding. As long as you build your map design and sentry behavior around the idea that your sentries can see through thin walls and small obstacles, you should be able to make an entertaining and convincing sneaking scene. You could with minor adjustments extend this script to your monsters so that your monsters wander around blindly until they see the hero and then rush at him. Hope this helps!

Also holy shit I just typed a lot.

woa Brandon... Im no way as good as you
this is how I would do it in a simple way


make a parralell proccess

put the guard (event 1) into the middle of screen

make an event box
then make a new page in page 2 set a switch operation called Alert or something.... then in page 2 put shake screen, flash screen red type "i see you!"
tint screen then teleport back to start
copy that and paste it all around the guard (the visiblity spots)

then go back to the parallel procees and put wait 10 seconds switch proccess Alert ON
face event 1 down wait 8 seconds face evnt 1 up switch Alert OFF

then just keep adding to that
mayby add a few crates to bump into (switches Alert ON)(makes event 1 follow you)

Can add a custom movement to the guard just gotta time the parralel proccess right...