Terrains are covered and tested, next is a unit class and everything around it.Units are data stores, they don't contain rules, an example of rules:

When a Unit of the Air ArmyBranch has run out of supplies it crashesGround troops(Tanks, Artillery) can no longer move when they run out of suppliesWhen Naval units run out of fuel they sink to the bottom of the ocean.

Instead we store an army branch field as integer and a UnitRules class can then use that field change to determine if the unit should destroy or stop moving when out of supplies.

But how does UnitRules know that the state of the current supply level has changed? Using the Observer pattern we can inform listeners of the change so they can take an action. I've reused the PropertyChangeSupport and added it to the top object in the game GameObject. Each GameObject can notify observers of a Property aka Field change.

A unit performs some actions:supplying, healing, capturing, attacking, defending, transporting units, move over tilesBut it does not know about it surroundings. A Unit has a Location and that's it.

Each time a Turn ends the supplies 'lost' each turn are subtracted from supplies aka the daily use of the unit.

Removing a Unitdestroy()this will garbage collect the unit because all references to it are removed.

TransportingThe unit is acting like a location you can add and remove units to/from it.

Dynamic/static fieldsDynamic fields are those that change like hp, ammo Static fields are maxHp, maxSupplies they are never changedDynamic fields are put last in the declarations.

Copy Constructor and creating unitsA unit contains many fields, instead of filling those in each time we need a new unit, we create a copy from a UnitFactory. Using a static method. UnitFactory.get(8) where 8 is the unitID and index in the unit image sheet.UnitFactory is loaded up with units once from xml. The UnitFactory.get(8) method internally creates a new Unit using a copy constructor.Units only have a constructor for tests.

move/attack zoneEach unit always has the correct zones.When a unit moves and wait is clicked we have to recalculate all unit zones.the reason to always store them is convenience.You can always ask a unit if a click was within it's move zone. The downside is that units have a tiny delay when they 'wait'

Who is online

Users browsing this forum: No registered users and 0 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum