Build some classes to facilitate handling attacks.
First up is an Attack class which really serves as a recordkeeping class. It is instantiated with the attacker and defender and we can derive some basic information like range and store it as well. Once the attack is acted upon we can start doing things like attaching a dicepool object to it and keeping track of modifications to the dicepool etc.
Second up is an Attackable interface. As you might have surmised an object implementing this interface can participate in an attack and contribute dice, take damage etc. At first blush this includes squadrons, hullzones, and an occasional obstacle down the road someday. I'm currently holding off implementing the interface because I want to separate Squadron rendering from the actual object. (MVC pattern and all that, plus having the same thing for M and V has lead to wonkiness in testing and code that I don't like.)
I opted to go with an interface because we really only have 2 ways for a lot of these to be defined, and they are radically different, so doing an extends and overriding something for one case wouldn't really save much effort.
Potential Tasks
[x] Connects to #72
[x] Meets the DefDone of the linked issue
Any other pertinent information
Intended use case is something like adding the interface to squadrons and then populating the individual functions appropriately. In the case of squadrons collectValidAttacks is something like check for squadrons, if squadrons, are they all heavy, if not, compile a list of squadrons in distance 1. Otherwise compile a list of ships at distance 1. Totaling damage is counting hits, but if its a bomber and the defender is a ship, include the crits. Things like that.
Interface definitions are fairly fluid depending on what makes sense when we get to actually coding things up.
Goal of Pull Request
Build some classes to facilitate handling attacks.
First up is an
Attackclass which really serves as a recordkeeping class. It is instantiated with the attacker and defender and we can derive some basic information like range and store it as well. Once the attack is acted upon we can start doing things like attaching a dicepool object to it and keeping track of modifications to the dicepool etc.Second up is an
Attackableinterface. As you might have surmised an object implementing this interface can participate in an attack and contribute dice, take damage etc. At first blush this includes squadrons, hullzones, and an occasional obstacle down the road someday. I'm currently holding off implementing the interface because I want to separate Squadron rendering from the actual object. (MVC pattern and all that, plus having the same thing for M and V has lead to wonkiness in testing and code that I don't like.)I opted to go with an interface because we really only have 2 ways for a lot of these to be defined, and they are radically different, so doing an extends and overriding something for one case wouldn't really save much effort.
Potential Tasks
Any other pertinent information
Intended use case is something like adding the interface to squadrons and then populating the individual functions appropriately. In the case of squadrons collectValidAttacks is something like check for squadrons, if squadrons, are they all heavy, if not, compile a list of squadrons in distance 1. Otherwise compile a list of ships at distance 1. Totaling damage is counting hits, but if its a bomber and the defender is a ship, include the crits. Things like that.
Interface definitions are fairly fluid depending on what makes sense when we get to actually coding things up.