Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
[RMVX ACE] FULLY AUTONOMOUS MONSTER EVENT (F.A.M.E) ENGINE
Posts
Pages:
1
CrazyRob
0
CrazyRob
View playlists
CloseThis is just something I cooked up out of necessity. I have a custom game over, but random encounter party wipes won't trigger it. Hence, I needed my overworld random encounters to be events.
In my dungeons, I have a "Monster God" event that dictates what each monster event will do in terms of pursuit, combat, and death. It's pretty straightforward- get within a certain range, the monster pursues until you leave that range. On contact, battle is engaged. Once the monster dies, the only way it will respawn is if you leave the dungeon.
But on the overworld, having an event handle hundreds of monsters would be taxing on me and the game.
This is where F.A.M.E. comes in.
Image 1 shows a simple "Radar" system that has served me better than anything else I could find for event pursuit purposes. With the x and y settings as they are, it checks constantly in a 7x7 square grid, centered on the monster event, for the player.
That condition satisfied, it flips switch A on. (Note: Yes, the script call is inefficient. I was testing to make sure it works and left it in.) Everything below the cutoff of the event window is branch ends- you're not missing anything.
Image 2 shows a simple event touch setup for combat. Processes for Win, escape, and defeat. 2b shows the movement used for the chase- speed 3 for four steps, speed 4 for 1 quick step- enough to catch an unwary player off guard, but not one that knows what they're doing. After that, switch a shuts off, back to page 1's radar evaluation. From my tests, the processing occurs so quick no noticeable delay occurs if the player is still in range, but the chase ends if they escape the radar range.
Page 3 is where the monster remains dead for 300 frames/five seconds. Enough time to make a getaway, but not so much to disrupt farming.
Of course, adjustments could be made to the event. The frequency of movement is best kept at a maximum for smooth moving, but speed and range of radar could be adjusted to create a short sighted but fast moving monster, or a slow-moving one that would follow you to the ends of the earth. (Or at least until the region block.)
I am almost certain that someone has developed something like this, or has done it better, but for those who want something that doesn't require scripting knowledge, here it is. Credit is nice, but not necessary.
In my dungeons, I have a "Monster God" event that dictates what each monster event will do in terms of pursuit, combat, and death. It's pretty straightforward- get within a certain range, the monster pursues until you leave that range. On contact, battle is engaged. Once the monster dies, the only way it will respawn is if you leave the dungeon.
But on the overworld, having an event handle hundreds of monsters would be taxing on me and the game.
This is where F.A.M.E. comes in.
Image 1 shows a simple "Radar" system that has served me better than anything else I could find for event pursuit purposes. With the x and y settings as they are, it checks constantly in a 7x7 square grid, centered on the monster event, for the player.
That condition satisfied, it flips switch A on. (Note: Yes, the script call is inefficient. I was testing to make sure it works and left it in.) Everything below the cutoff of the event window is branch ends- you're not missing anything.
Image 2 shows a simple event touch setup for combat. Processes for Win, escape, and defeat. 2b shows the movement used for the chase- speed 3 for four steps, speed 4 for 1 quick step- enough to catch an unwary player off guard, but not one that knows what they're doing. After that, switch a shuts off, back to page 1's radar evaluation. From my tests, the processing occurs so quick no noticeable delay occurs if the player is still in range, but the chase ends if they escape the radar range.
Page 3 is where the monster remains dead for 300 frames/five seconds. Enough time to make a getaway, but not so much to disrupt farming.
Of course, adjustments could be made to the event. The frequency of movement is best kept at a maximum for smooth moving, but speed and range of radar could be adjusted to create a short sighted but fast moving monster, or a slow-moving one that would follow you to the ends of the earth. (Or at least until the region block.)
I am almost certain that someone has developed something like this, or has done it better, but for those who want something that doesn't require scripting knowledge, here it is. Credit is nice, but not necessary.
Seems like a real mess to put all that stuff in every event. If you make any kind of changes to the system then you have to apply it to every event as well. Try to put as much as you can into a common event (though, this would be way more easily solved with a script). When you call a common event in VX Ace, does it have any information about what event called it... or can you give a common event some information when calling it, like the entity's position and what not?
CrazyRob
0
You can just copy and paste an event, editing the details as need be.
I've used a single event on multiple maps to govern monster movements, so it's possible to use the self-switch call trick to handle everything.
If done in a common event, however, a lot more tweaking is necessary. A solo event is capable of identifying itself as "this event". A common event would need to be retooled for each individual monster event on a map.
I've used a single event on multiple maps to govern monster movements, so it's possible to use the self-switch call trick to handle everything.
If done in a common event, however, a lot more tweaking is necessary. A solo event is capable of identifying itself as "this event". A common event would need to be retooled for each individual monster event on a map.
BlackWolf1992
234
Honestly, a script would be a lot more simple to use, but hey, if this works for you then that's all that matters.
Jude
Seems like a real mess to put all that stuff in every event. If you make any kind of changes to the system then you have to apply it to every event as well. Try to put as much as you can into a common event (though, this would be way more easily solved with a script). When you call a common event in VX Ace, does it have any information about what event called it... or can you give a common event some information when calling it, like the entity's position and what not?
in my experience, CEs know everything about the calling event, to the point where you can even flip their self-switches.
I made a Proximity Detection event system in RM2k3 back in the day. I wrote a tutorial here: http://rpgmaker.net/tutorials/16/
I used it extensively in this game: http://rpgmaker.net/games/146/
You might be able to make use of it, and streamline it better in RMVXAce as events have self-switches and by making use of common events like Jude suggested. When I implemented this, it was initially for a 2 week contest that scrambled together a working prototype. Copying the event for every single monster and assigning new variables, switches, and values was tedious af. Keep that in mind if you decide to pursue your F.A.M.E.
I used it extensively in this game: http://rpgmaker.net/games/146/
You might be able to make use of it, and streamline it better in RMVXAce as events have self-switches and by making use of common events like Jude suggested. When I implemented this, it was initially for a 2 week contest that scrambled together a working prototype. Copying the event for every single monster and assigning new variables, switches, and values was tedious af. Keep that in mind if you decide to pursue your F.A.M.E.
Infinite
2103
In my action adventure game Ascending Dreams I had to program each enemy event for every map. Doing the copy/paste method, and redoing each of them any time i made a change. It sucks.
Since then I've learned how to script a little bit, and modified a script called
"Duplicate and Auto-Untint Events v1.00 by AdiktuzMiko", which can make clones of any event from any map. From there, I added methods and variables to the Game_Event and Game_CharacterBase classes for things like enemy HP...
(not the complete script, just a small example)
So doing this allows me to have 1 main/prime/master event for any enemy i want to spawn.
Something you may want to check out is the "near_the_player?" method in Game_Event.
I edited this to
So now I can use that method, combined with the @vision variable to increase or decrease the enemy's vision. So if I said @vision = 5, then when the player is within 5 blocks it returns true.
Since then I've learned how to script a little bit, and modified a script called
"Duplicate and Auto-Untint Events v1.00 by AdiktuzMiko", which can make clones of any event from any map. From there, I added methods and variables to the Game_Event and Game_CharacterBase classes for things like enemy HP...
(not the complete script, just a small example)
class Game_Event
attr_accessor :hp
attr_accessor :ap
attr_accessor :name
attr_accessor :hitable
attr_accessor :switch
attr_accessor :id
attr_accessor :move_type
attr_accessor :make_steps
attr_reader :killed
def set_stats
if self.name == ("Armor")
@hp = 50
@ap = 1
@drop = 101
end
end
alias :old_update :update
def update
@brainclock += 1
self.priority_type = @s_priority_type if self.name == ("Bat")
self.anime_count += @s_anime_count
old_update unless @stun_time > 0
check_hp if @hitable == true
@hurt -= 1 if @hurt > 0
check_hits if @ap > 0
check_status_effect
stepsound if @make_steps == true && !@mute_steps
enemy_ai if @killed == false && @stun_time < 1
end
So doing this allows me to have 1 main/prime/master event for any enemy i want to spawn.
Something you may want to check out is the "near_the_player?" method in Game_Event.
def near_the_player?
sx = distance_x_from($game_player.x).abs
sy = distance_y_from($game_player.y).abs
sx + sy < 20
end
I edited this to
def near_the_player?
sx = distance_x_from($game_player.x).abs
sy = distance_y_from($game_player.y).abs
sx + sy < @vision #how far the event can see
end
So now I can use that method, combined with the @vision variable to increase or decrease the enemy's vision. So if I said @vision = 5, then when the player is within 5 blocks it returns true.
Pages:
1
