Refactoring
I think two days ago, I kind of half-implemented the logic to "undo" an action in battle, in case you change your mind about what a battler should do before the round is finalized. You can't take back an entire round, but for example, if you have three party members, and you've chosen actions for the first two but not the third, you can "undo" and choose new actions for the first two.
Yesterday, I was sick with a fever and chills and spent a lot of time in bed. I became really sweaty.
Today, I finished the "undo" implementation. It was way easier than I thought it would be, to the point where I'm kind of suspicious that it's incorrect.
- There is an "undo stack" which stores historical copies of the action queue.
- When you submit an action to the queue, put a copy of the previous action queue on top of the undo stack.
- When you undo an action, restore the action queue to the previous version, which is the one on top of the undo stack.
- Because it's a stack, you can keep undoing repeatedly to keep going back to previous action queues, all the way to the start of the round.
- The undo stack resets at the end of each round, so I don't need to worry about weird bugs caused by it carrying over.
Now that I think about it though, this only works correctly because right now, all player-controlled battlers submit their actions before all enemy-controlled battlers. If the order was mixed up, then you wouldn't be able to undo past an enemy's action. But it doesn't seem hard to either (1) always enforce this order, or (2) make undo skip past enemy actions. If it becomes a problem later, I should be able to fix it.
Because that didn't take a long time, I started "refactoring". This is when you move code to a new location. In this case, all my code for things like "selecting an action from a menu" was in a specific "player-controlled battler" object. I decided to move all that stuff to the more generic "battler" object that can represent both players and enemies.
This way, enemy battlers will also be able bring up an action menu, which allows me to implement the idea I had for the CHARM status effect where you can actually directly control the behaviour of CHARMED enemies. It could also be useful for other fun things, like maybe you could have an enemy join your side in the middle of a boss fight and you would be able to command them.
The refactoring process was pretty mundane. Only three interesting things happened.
- Instead of the skill menu being hardcoded to always have the same four skills, I made it so all battlers have a list of skills, which by default is empty. The skill menu is generated from this list.
- Instead of the main battle menu being hardcoded to always have the same four options,
I made it populate the menu with a different set of options depending on circumstances.
- For example, if the list of skills is empty, then the Skill option that opens the skill menu will not appear.
- For another example, if the battler is in the player's party, they get an option called Bleed which inflicts damage on the self. If the battler is an enemy, they instead get an option called Guard which does nothing (later it will defend against damage, maybe).
- Because the main battle menu has an option to run away, I implemented the ability for enemies to run away.
To test the changes, I set up a battle scenario in which all enemies start with the CHARM status.
Then, using my ability to control the enemies, I commanded all of them to run away, and I won the battle.
Ha ha ha....
- ← Previous
Cursor Memory