Key Triggered Limited Speed Boost

[HeyLookAnotherQuest]

Thanks, I'm downloading the file and will give it a whirl. Happy to share any details about my event setup, but not entirely sure what will be useful. I'll just go from the start I suppose. I think the only thing on the rails about my player is the intro and the start line. After the title screen, the game opens up on a separate map that gives a brief scroll over of the course.


Player spawns in an insignificant location as transparent, event is towards the top. Ultimately transfers to the actual race map which is basically identical. While on the subject, perhaps there's a more concise way to do this though that only involves the main map since they're identical anyway? I think my logic was to use a seperate map and autorun event as the next map relies on a different auto run event. On second thought, maybe it's fine just the way it is.

From there the player spawns behind the start line. This area will eventually be full of several 7 man teams of NPCs with fixed route movements. The race begins by the NPC towards the middle of the screen moving up, turning around and starting the race by making the start line passable and starting the clock. The two events in the bottom corner are where I tried out the two parallel events you posted previously.

NPC's route movement setup. No issues here although it's incomplete at the moment as I want to focus on the game mechanics first. The waiting is coordinated with the starter.

"The Starter" NPC whose route movement I posted the other day as well. This is the top of it that was cut off, but as previously posted this starts the race.

The start line is controlled with a switch activated by The Starter. By default through is off for the player, so perhaps that is enough to qualify it as On The Rails?

Once the switch is turned on by the starter, the player's speed is set to 5 and they can move through the line. You may have noticed a line of events several tiles out from the start line. These decrease the player's speed to 4. The idea was to have the start mimic a race with people sprinting for position before settling into their actual pace.


So that is all my eventing for the moment. I appreciate your input on this so much, thanks again. For now, you've given me plenty to play around with as far as the dashing feature is concerned. At this moment, I'm still not sure entirely sure how I want to implement it, but I do know the purpose I want it to serve. I want the player to have to choose when and how much of their boost to use at certain points in the game. Now I just need to figure out how that will fit into the larger mechanics of the game. I think I'll post a new thread regarding how dashing fits into the drafting idea in a few days after I have some time to tinker.

 

[caethyril]

Oh yes, I was thinking maybe you were setting something up so the player always has to be moving forward or something...the demo will probably illustrate what I had in mind more clearly than I can express it in words. xP "On-rails" is just a term used to describe a game where some aspect (typically movement) is out of the player's control, so as to give more focus to, for instance, tactical use of boosts/jumps/shooting/etc. After seeing your screenshots, I don't think that applies here, right?

Regarding the two maps for two autoruns...one option could be to use two pages on the same event:

• Page 1: no conditions, trigger Autorun; Scroll Map to get a view of the race course and then turn on, for example, self-switch A
• Page 2: condition self-switch A is On, trigger Autorun; do the starting stuff, then disable the event, either temporarily using Erase Event or permanently by making a blank "page 3" with Action Button trigger and switching to that page once the race has started (e.g. turn on self-switch B ).

I noticed EV001 (one of the NPCs racing against you?) has its trigger set to autorun, which seems odd. Maybe just an accident? The event trigger only affects when the event contents will run. Autorun events will run repeatedly while active, even if there are no commands in the event, and normal player input (e.g. movement) will be ignored while there's an event queued...even if the event has no commands!

Otherwise I think it all looks good! Hopefully the demo will be helpful; I can be a bit obscure in my verbal explanations, but having a functional project to play around with is great for learning stuff. ^_^

 

[HeyLookAnotherQuest]

Thanks again for all the help with dashing, it's been interesting to play around with and helping solidify the main ideas. I was going to start a new thread, but given how much detail I've already posted here I think it makes more sense to continue this one. Of course if I'm incorrect, I apologize and am happy to appease oh great forum overlords.

So as with any racing game, I'm looking to the gold standard of mario kart. There's another video I'm having trouble locating at the moment, but does a pretty good job of describing the dynamic I'm hoping to achieve. Basically, I want the game to challenge the player to make dynamic decisions as they go along. Unlike mario kart, I do not want to use items, and the course is split into segments but not repetitive laps. The aesthetic and mechanics are meant to mimic the sport of cross country running.

As I mentioned previously, I've been thinking of a "drafting" feature. Specifically, when the player is directly behind an NPC that is dashing, the player will be draft behind and match the NPC's speed without affecting their dash gauge.. Likewise, if the player uses their dash while an NPC is behind them they will take the NPC along for the ride. The layout of the course being grounded in tiles means that there are some paths that are shorter than others. The challenge will be for the player to balance the quickest route vs the opportunities presented by the NPC's dashing vs the dashing ability allotted to the character at the start of the race.

Again, there is a lot of flexibility with how to apply the player's dashing. It could be just one gauge the starts full, empties once and is done. Or perhaps, at specific intervals it refills again, forcing the player to choose when to start using it to make the most of their finite resource before it once again is replenished. That variable is something I definitely feel confident playing with thanks to your examples, but first we need to incorporate the drafting feature.

I know that yanfly has a proximity events feature. I mentioned the activation being directly behind the player or npc, but diagnol could be interesting to try out as well. I imagine getting the NPC or player's speed to change given their distance from one another should be doable, but I was curious how that might affect the NPCs given that they're set on a specific route movement. I'm hopeful that using some sort of pathfinding script (which I do know can be limited), they can be moved forward without having them diverge from their path and get stuck against a tree.

On that same note, the only other factor aside from this will be collision which will deal with the same principle...knocking an NPC off of it's route and having it return without issue. I'll save that for another post, but I figured it was worth mentioning in case it tied in with the other mechanic I'm trying to achieve. Really once those dynamics are locked in and I figure out how to track the finishes of the racers, it should mostly be just a matter of creating tiles, courses, and custom NPCs.

Thanks again for helping me tackle this. Pixel art is one thing, but eventing and plugins are definitely new concepts to me. Please let me know if I can clarify anything.

 

[caethyril]

Yes, this is kinda advanced for eventing, I'm not surprised you're finding it a bit of a challenge if you're new to it. It's like most other stuff, though: practise makes perfect!

Ooh, the drafting idea sounds interesting; it is easier to run behind someone who's acting as a windbreak! Not sure what the best approach would be to implementing it, though...proximity events seems OK for applying the draft effect, but then you need some kind of "leave" trigger to remove it when appropriate, right? I'd consider adding the position checks and speed adjustment to the existing parallel event, since it handles everything else. Depending on how you want to implement the draft speed/dash thing, it may be doable with purely event commands, but I think the logic will be fairly complex either way. Maybe something along these lines (haven't tested, but it might help illustrate the logic):

Spoiler

◆Comment：0) Remove draft effect from player and event by default.
◆Script：$gameMap.event(2).setMoveSpeed(4);
：      ：$gamePlayer.setMoveSpeed(4);
◆Comment：1) Check if "in-line" with event based on direction,
：       ：   i.e. player is directly behind event or vice versa.
◆Comment：Check direction to see which coordinate to compare.
◆If：This Event is facing Down
  ◆Comment：Compare X
  ◆Control Variables：#0002 Compare Coord = 0
  ◆
：Else
  ◆If：This Event is facing Up
    ◆Comment：Compare X
    ◆Control Variables：#0002 Compare Coord = 0
    ◆
  ：Else
    ◆Comment：Compare Y
    ◆Control Variables：#0002 Compare Coord = 1
    ◆
  ：End
  ◆
：End
◆Comment：Compare designated coordinate of player and event.
◆If：Compare Coord = 0
  ◆Control Variables：#0002 Compare Coord = Map X of Scarfie
  ◆Control Variables：#0002 Compare Coord -= Map X of Player
  ◆
：Else
  ◆Control Variables：#0002 Compare Coord = Map Y of Scarfie
  ◆Control Variables：#0002 Compare Coord -= Map Y of Player
  ◆
：End
◆Comment：Process next part only if player is directly behind event or vice versa
◆If：Compare Coord = 0
  ◆Comment：2) Check event's direction then get distance between player & event
  ◆If：Scarfie is facing Down
    ◆Comment：Event Y - Player Y: positive if player is "above" event
    ◆Control Variables：#0002 Compare Coord = Map Y of Scarfie
    ◆Control Variables：#0002 Compare Coord -= Map Y of Player
    ◆
  ：Else
    ◆If：Scarfie is facing Left
      ◆Comment：Player X - Event X: positive if player is to the right of event
      ◆Control Variables：#0002 Compare Coord = Map X of Player
      ◆Control Variables：#0002 Compare Coord -= Map X of Scarfie
      ◆
    ：Else
      ◆If：Scarfie is facing Right
        ◆Comment：Event X - Player X: positive if player is to the left of event
        ◆Control Variables：#0002 Compare Coord = Map X of Scarfie
        ◆Control Variables：#0002 Compare Coord -= Map X of Player
        ◆
      ：Else
        ◆Comment：Scarfie is facing Up
        ◆Comment：Player Y - Event Y: positive if player is "below" event
        ◆Control Variables：#0002 Compare Coord = Map Y of Player
        ◆Control Variables：#0002 Compare Coord -= Map Y of Scarfie
        ◆
      ：End
      ◆
    ：End
    ◆
  ：End
  ◆Comment：3) Apply/remove draft if appropriate!
  ◆Comment：Check who's on first.
  ◆If：Compare Coord > 0
    ◆Comment：Event is in front, now check distance!
    ◆If：Compare Coord ≤ 2
      ◆Comment：Within two tiles, increase player speed or whatever~
      ◆Script：$gamePlayer.setMoveSpeed(4.5);
      ◆
    ：End
    ◆
  ：Else
    ◆Comment：Assuming they're not sharing a tile, then event must be behind player
    ◆If：Compare Coord ≥ -2
      ◆Comment：Within range, apply draft boost to event
      ◆Script：$gameMap.event(2).setMoveSpeed(4.5);
      ◆
    ：End
    ◆
  ：End
  ◆
：End

As you can see, that's a fair-sized chunk of eventing (even if half of it is comments) and it only checks for one event. There may well be a more succinct and efficient way to event and/or script it, though.

Just to note: the player's dash speed is (by default) +1 compared to their normal move speed. By default the player moves at speed 4 so they dash at speed 5...if you set their move speed to 3, they'll dash at speed 4. Also, in case you find it useful: Control Variables > Game Data > Character > Direction retrieves a "numpad" direction, i.e. 2 = down, 4 = left, 6 = right, 8 = up.

Pathfinding is doable in the base engine with a little scripting, but it's only reliable for short distances (on-screen), since it's optimised for player movement (touch input). There are plugins available that simplify the script call a bit, e.g. Shaz's Smart Pathfinding. The distance can be increased (with a simple plugin or code edit) at the risk of performance impact if necessary, but long paths are typically split into a series of waypoints, and the event (known more generically as an "agent") paths to each of those points in turn. This gives you more control over how they move from A to B (e.g. to avoid slowing terrain), but does open you up to quirky behaviour like having an agent knocked or diverted past a waypoint and backtracking to reach it.

Knocking characters off-route, just to quickly address the basics of that here: you could give them each an Event Touch trigger, and use a plugin like Galv's Event Start Types to tell whether the player activated/collided with the event or vice versa, and bump the appropriate character away 1 tile with a move route. Like you say, pathfinding would be necessary with that sort of mechanic in place.