I can’t wrap my head around the exact reason, but I feel there’s some inconsistency about the current architecture. We were creating the ActionScheduler so that Fighter and Mover would be independent, but the Fighter still calls the Mover. Also, the the logic about cancelling actions happens both in the PlayerController (for input) and in the ActionScheduler (for updates).
Shouldn’t the Fighter do only the attacking part and Mover do only the moving part?
This way, if a combat command is issued, both Mover and Fighter get called, and if there’s movement command, then only the Mover. (we’d also need the mover to cancel itself on reaching the destination, and the fighter to cancel itself if eg the enemy is dead)
Then we can get rid of the ActionScheduler, since Actions only happen on input (will this always be the case?), and instead keep the list of the issued actions in the PlayerController, and on another action cancel all actions that haven’t cancelled themselves already.
That’s what the player expects anyway: they issue a command and it will either be fulfilled or cancelled by a new command.
It’s definitely not necessary, but it seems that the code would be much cleaner this way.
What we’re after isn’t necessarily that Fighter and Mover be independent, but that they not be cross dependent.
Think of Mover as a utility class. It’s responsible for all movement, whether that movement command is issued by the PlayerController, the Fighter, or perhaps a future class like an item collector or another action. It happens to be an IAction, to manage independent movement, but it can also be used by other classes for movement. No other class is responsible for actually telling the NavMeshAgent where to move.
The Fighter is a specialized class. It’s primary purpose is to… well… to fight. We don’t want it thinking about the details of how movement is handled, just that we still need to move within range or not, as such. If the Fighter is not in range, we need to move within range, but that’s not the Fighter’s job, it’s the Mover’s job, hence Fighter requesting the move from Mover.
Later in the course, we’ll be making some fundamental changes to the way the PlayerController delegates actions (giving objects in the scene the power to determine what action is taken). At that point, the PlayerController won’t even know about the Fighter or CombatTarget, only that an object handled the raycast and click. If nothing handled the raycast, then it will test for movement. Some of those actions will need to use movement, others won’t. The ActionScheduler will help keep all of this straight without having to refactor all new Actions every time you add a new Action to the mix.
Thank you for the clarification!
I was thinking that since Fighter and Mover are both Actions, and they’re called in the same way, then they’re supposed to be on the same level on the depency graph.
But it’s fine to have more complicated actions to be built on top of simpler ones, and the player to still have only one action going on at the same time.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.