What should "own" the battle state in combat between the player and NPCs?

Question

I have a Map, a Tile, NPCs and the Player. When a player enters a tile in the map, a moveTo event is fired, which calls for any NPCs associated with that tile to be "activated". Those NPCs may be antagonists, and wish to start a battle. The battle state (rounds, initiative, alive/dead, add and removing combatants) seems like it should all belong to the Tile, but that seems too tightly coupled... maybe it should belong to the Map? Thoughts on that?

Answer 1

Battles are entirely separate things from any of the objects you mentioned. Yes, they take place on a Tile (and, naturally, within the Map), and happen between NPCs and the Player, but none of these object is the Battle.

I would suggest creating a new object, Battle, to maintain battle state. Hand it the participants and any terrain info it might need (e.g. maybe some NPCs/Players have bonuses on swamp Tiles, or maybe ranged attacks are penalized in forest Tiles), then encapsulate all your battle state logic within the Battle object.

Another approach I've seen (but that I don't like as much; YMMV) is to make the battle a method within either the Player or NPC objects. Hand this object the opponents (if you always only have one Player in a fight, put this method in the Player object and hand it the antagonistic NPCs; this gets really tricky to figure out, though, if you can have multiple participants on both sides), and then let it handle the battle state logic. This feels too tightly coupled to me, though, and personally I much prefer the battle logic living in its own Battle object. This also scales better if you add complexities like different tactics to your battle rules -- you can quickly find yourself maintaining a massive amount of code to represent your complex fights, and having that in its own separate object makes that a lot easier to manage.