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] MAP SKILLS TO INTERACT WITH OBJECTS - A BETTER WAY?
Posts
Pages:
1
QZProductions
2421
QZProductions
View playlists
CloseHey all, so my latest game has a system where each character has a special "Map Skill" that can be used on the map to, say, break boulders, light torches, etc. My current system TECHNICALLY works, but because it relies a lot on the correct collision between the player and the object in order to set a switch and variable that allows the common event to run, my beta testers sometimes struggle with getting it to work without a lot of readjusting the characters. So, it's playable, but definitely rough around the edges.
Essentially, Number Hotkey -> Common event -> if skill switches are on (usually by Player Touching the affected event), the skill triggers and the object is broken/burnt/etc. I can provide some event examples if needed.
What I want to know is whether there's a way to "interact" with objects in this way that bypasses the need for finicky and unreliable collision detection. While the current game is playable I feel like this would be a HUGE improvement on the map skills mechanic. Any suggestions would be appreciated!
Essentially, Number Hotkey -> Common event -> if skill switches are on (usually by Player Touching the affected event), the skill triggers and the object is broken/burnt/etc. I can provide some event examples if needed.
What I want to know is whether there's a way to "interact" with objects in this way that bypasses the need for finicky and unreliable collision detection. While the current game is playable I feel like this would be a HUGE improvement on the map skills mechanic. Any suggestions would be appreciated!
I have discovered that for having the players triggering stationary events by walking into them, it's almost always better to not use actual event box collision triggers at all. Instead, create the effect in a common event and have the event wait for your player to enter a specified set of coordinates. The way this is done:
I find when doing finicky work like what you're describing, this is significantly better than using the event box triggers. The system doesn't get nearly as confused about what it's supposed to do using coordinates as it does when using the built-in event triggers. I'm actually doing that now for a racing game I'm making. Since it's an obstacle course and since it's a runner, similar to snowboarding games, I don't want the character to just get stuck at an obstacle: I want the obstacle to interact (basically, penalize the player by backing up a space and forcing you to wait for a second.), and the basic event triggers won't react when you've got the game set to force him to run to the bottom of the screen. Using coordinates instead entirely solved every problem I was having and the game is reacting almost exactly the way I want it to.
@>Control Variables: [0001: coordinate X] Player's Map X
@>Control Variables: [0002: coordinate Y] Player's Map Y
@>Conditional Branch: Variable [0001: coordinate X] == (number at X)
@>Conditional Branch: Variable [0002: coordinate Y] == (number at Y)
@>Trigger the effect you want triggered.
: Branch End
: Branch End
I find when doing finicky work like what you're describing, this is significantly better than using the event box triggers. The system doesn't get nearly as confused about what it's supposed to do using coordinates as it does when using the built-in event triggers. I'm actually doing that now for a racing game I'm making. Since it's an obstacle course and since it's a runner, similar to snowboarding games, I don't want the character to just get stuck at an obstacle: I want the obstacle to interact (basically, penalize the player by backing up a space and forcing you to wait for a second.), and the basic event triggers won't react when you've got the game set to force him to run to the bottom of the screen. Using coordinates instead entirely solved every problem I was having and the game is reacting almost exactly the way I want it to.
When it came to the Wand of Blasting, collision detection had the potential to be wonky when it came to initiating encounters. Players could shoot at a monster, and the bullet "misses" it because the event had technically moved out of the bullet's path. The bullet would then proceed to travel until it hit a wall (or other like impassible object), something it could interact with, or the edge of the map. Whichever came first.
QZProductions
2421
author=pianotm
I have discovered that for having the players triggering stationary events by walking into them, it's almost always better to not use actual event box collision triggers at all. Instead, create the effect in a common event and have the event wait for your player to enter a specified set of coordinates. The way this is done:
@>Control Variables: [0001: coordinate X] Player's Map X
@>Control Variables: [0002: coordinate Y] Player's Map Y
@>Conditional Branch: Variable [0001: coordinate X] == (number at X)
@>Conditional Branch: Variable [0002: coordinate Y] == (number at Y)
@>Trigger the effect you want triggered.
: Branch End
: Branch End
I find when doing finicky work like what you're describing, this is significantly better than using the event box triggers. The system doesn't get nearly as confused about what it's supposed to do using coordinates as it does when using the built-in event triggers. I'm actually doing that now for a racing game I'm making. Since it's an obstacle course and since it's a runner, similar to snowboarding games, I don't want the character to just get stuck at an obstacle: I want the obstacle to interact (basically, penalize the player by backing up a space and forcing you to wait for a second.), and the basic event triggers won't react when you've got the game set to force him to run to the bottom of the screen. Using coordinates instead entirely solved every problem I was having and the game is reacting almost exactly the way I want it to.
Could I add a condition where the player also has to be facing a certain direction? that way if you're directly under the stone pillar and facing left, using Stonecleaver won't work.
In conditions you can set which way the player is facing.
This is how you can program boulders to move, for example.
Are your events player touch? (same as / below.)
Screenshot might help explain what your trying to do.
Yeah, just nest another branch.
Also, Kory's right. If we could see what you were trying to do, we could give you more specific info.
@>Control Variables: [0001: coordinate X] Player's Map X
@>Control Variables: [0002: coordinate Y] Player's Map Y
@>Conditional Branch: Variable [0001: coordinate X] == (number at X)
@>Conditional Branch: Variable [0002: coordinate Y] == (number at Y)
@>Conditional Branch: Player Facing Up
@>Trigger the effect you want triggered.
: Branch
@>Conditional Branch: Player Facing Right
@>Trigger the effect you want triggered.
: Branch
@>Conditional Branch: Player Facing Down
@>Trigger the effect you want triggered.
: Branch
@>Conditional Branch: Player Facing Left
@>Trigger the effect you want triggered.
: Branch
: Branch End
: Branch End
Also, Kory's right. If we could see what you were trying to do, we could give you more specific info.
QZProductions
2421
Here's an example of a stone that can be broken with Stonecleaver. The first page makes the skill usable with a switch and also gives the object its ID variable (so the game knows which stone to destroy). The second page is a parallel process that looks for whether the player turned on the "Used" switch by using the skill (linked to a common event) or has stepped away from the object, which SHOULD (but not always) resets the switches/variable. When the skill is used, it's supposed to trigger the self switches that proceed through the animation. The issue is that the collision does not always turn on the switches or change the variable, or stepping away doesn't always reset the switch or variable, so you can sometimes not activate the event when you should be able to or activate skills while not next to the event.
Pages:
1
