- 250
- Posts
- 7
- Years
- Seen Apr 23, 2025
I've often not liked simplistic uses of Speed in turn-based RPGs, where it just determines who goes first each turn, and that's that. I liked ATB (Active Time Battle) systems, since faster characters would get more actions in over the course of the battle than slower characters. Pokémon Legends: Arceus implemented a similar structure to its turn-based system, and I wanted to see if it was possible to implement something similar in pokeemerald. I believe I have accomplished just that! This system should work for both base pokeemerald and pokeemerald-expansion projects, but if there ends up being some sort of a problem due to me not catching a compatibility issue, just point it out in this thread, and I'll try to fix it A.S.A.P.
How it Works:
Acquisition
Help Wanted:
Known Bugs:
None yet, but I'm sure that won't last long.
How it Works:
Spoiler:
At the start of a battle, every Pokémon in battle is given a timer that is set at 0. Every time an action needs to be taken, each Pokémon's timer will increase by a number based on their speed, ranging from 1 to 20, accounting for stat changes, held items, Trick Room, etc. Whichever mon has the highest timer will then immediately take an action. The mon taking the action will have their timer reduced, while all of the other mon's timers will stay where they are. This allows for faster mon's to sometimes get an extra action before their opponent goes.
Ties:
Priority Moves:
Balance:
Ties:
Spoiler:
In the case where two or more mons are tied for the highest timer value, the tie will be broken based on whichever mon has waited the longest to take an action. If there's a tie for that too, then the tie will be broken based on whoever has the better speed stat, accounting for stat changes, held items, Trick Room, etc. If there's a tie there as well, the tie will go to the player's mon. If both Pokémon involved with the tie are on the same team, then whichever mon has the lower index in gBattleMons goes first.
Priority Moves:
Spoiler:
Priority moves weren't really a thing in Legends: Arceus, so I decided to just apply a multiplier to the mon's speed when calculating how far to move the timer until their next action. A priority one move multiplies the mon's speed by 2, priority two would multiply by 2.5, priority three by 3, and so on. Negative one priority moves would multiply the mon's speed by 0.5, negative two priority multiply by 0.4, negative three by 0.333, and so on.
Balance:
Spoiler:
Is this balanced when directly applied to a normal Pokémon project?......No, I don't think so. As much as I dislike the boring process of just deciding turn order with speed, Pokémon actually works fairly well with this system, since party members can drop in one hit quite often, which actually makes going first in a turn very important, unlike games like Dragon Quest or Final Fantasy, where most fights are long, drawn out endeavors. With this battle timer system applied, Pokémon that have above average speed become significantly more powerful than those with below average speed (Think about mons like Alakazam or Ninjask). One would need to go about adjusting Speed stats or entire stat spreads of all Pokémon to make sure faster Pokémon don't just shred slower mons. Or you can just apply this system to your project, knowing faster mons are more powerful than slower ones.
Also, certain priority moves no longer serve the same functionality as they used to, since they only shorten the time till the mon's next turn rather then having them go first in the current turn. For example, the move Protect is a priority three move. This means that, if a mon uses Protect, their speed will be multiplied by 3, making their timer increase much faster, and in turn making the protective feature of Protect effectively null if they end up going before their opponent(s) after using the move. I plan on looking through the list of non-zero priority moves and making some adjustments, but for the time being, some priority moves won't make sense in application. Also, I might still need to fiddle with the multipliers applied to priority moves overall. Maybe I should have priority one moves have a multiplier of 1.5x instead of 2x, and then increase from there? I would appreciate some input on that issue.
This is more of a theory than a known balance issue, but I haven't changed the enemy a.i. in any way to account for this system. I don't think there will be any crashes, but the a.i. won't fully utilize the system. It may even be a little dumber than before, since it won't account for the player or itself possibly having a few actions in a row, but I haven't fully tested that myself.
Also, certain priority moves no longer serve the same functionality as they used to, since they only shorten the time till the mon's next turn rather then having them go first in the current turn. For example, the move Protect is a priority three move. This means that, if a mon uses Protect, their speed will be multiplied by 3, making their timer increase much faster, and in turn making the protective feature of Protect effectively null if they end up going before their opponent(s) after using the move. I plan on looking through the list of non-zero priority moves and making some adjustments, but for the time being, some priority moves won't make sense in application. Also, I might still need to fiddle with the multipliers applied to priority moves overall. Maybe I should have priority one moves have a multiplier of 1.5x instead of 2x, and then increase from there? I would appreciate some input on that issue.
This is more of a theory than a known balance issue, but I haven't changed the enemy a.i. in any way to account for this system. I don't think there will be any crashes, but the a.i. won't fully utilize the system. It may even be a little dumber than before, since it won't account for the player or itself possibly having a few actions in a row, but I haven't fully tested that myself.
Acquisition
Spoiler:
If you want to just pull from my repository, here are the git commands:
Code:
git remote add wiservisor https://github.com/W1serV1ser/pokeemerald.git
git pull wiservisor BattleTimer
Help Wanted:
Spoiler:
Currently, there is no graphical indication to show the turn order for the next couple actions like Legends: Arceus has.
See top right of image above to see what I'm talking about.
This means that the player won't know which mon is going to take their action next until the action is taken, unless they keep track of the timer values themselves, which would be ridiculous to force a player to do. I believe my digital graphics skills are a bit subpar for the task, along with my ability to program this feature into pokeemerald. If any kind, generous, freely available souls would be willing to go about creating the graphics for and writing the code to implement said graphics, I would be incredibly grateful. I can write the code to generate the predicted turn order over the next 6 turns, but the actual displaying and changing of those graphics is beyond me. DM me if you're interested in helping me in this aspect.
Also, I'm not committed to the multipliers that I've given to each priority level. If you think that the multipliers should be less intense, more intense, scale more or less intensely, I'd be interested in hearing your reasoning, and may possibly adjust the multipliers accordingly. You can post here or DM me if you want to voice your opinion on this issue.
![[PokeCommunity.com] Battle Timer System (Legends: Arceus Inspired) [PokeCommunity.com] Battle Timer System (Legends: Arceus Inspired)](https://www.serebii.net/legendsarceus/battle1.jpg)
See top right of image above to see what I'm talking about.
This means that the player won't know which mon is going to take their action next until the action is taken, unless they keep track of the timer values themselves, which would be ridiculous to force a player to do. I believe my digital graphics skills are a bit subpar for the task, along with my ability to program this feature into pokeemerald. If any kind, generous, freely available souls would be willing to go about creating the graphics for and writing the code to implement said graphics, I would be incredibly grateful. I can write the code to generate the predicted turn order over the next 6 turns, but the actual displaying and changing of those graphics is beyond me. DM me if you're interested in helping me in this aspect.
Also, I'm not committed to the multipliers that I've given to each priority level. If you think that the multipliers should be less intense, more intense, scale more or less intensely, I'd be interested in hearing your reasoning, and may possibly adjust the multipliers accordingly. You can post here or DM me if you want to voice your opinion on this issue.
Known Bugs:
None yet, but I'm sure that won't last long.
Last edited: