====== Crit 2 ======
This critique summarizes the work done since the initial [[people:lucas_nunno:project:introduction|Simulating Tribal Warfare in the Movable Feast Machine]] introduction. 

**My personal goal for this milestone**: demonstration of complex behavior. Including:
  * Base cohesion.
  * Smarter infantry movement.
  * Killing foreign tribes!

===== What's been demoed before =====
  * **AbstractTribal_Element**: Base class, provides the tribe slider for all subclasses.
  * **Mine unit**: spews out a bunch of Res.
  * **Base unit**: Floats around gobbling up Res and spawning both Bases and Infantry.
  * **Infantry unit**: Diffuses everywhere, doesn't do anything else.

===== What's done? =====
  * Bases have a "stability factor" where they avoid moving if they are in a structure.
  * Infantry units have a "move direction" attribute and have an element parameter that dictates how often they change direction.
  * Infantry units can kill foreign (tribal) units.

===== Ideas =====
==== OO Abstraction ====
I might pull the following element parameters into the AbstractElement_Tribal class:
  * Kill Odds
  * Move/Kill Radius

It's possible that units may share similar behavior and should therefore all inherit from the same Abstract base class. They could then override Kill Odds and Move/Kill Radius as appropriate.

This would make adding new units fairly easy, you could just subclass the overlying abstract class and override the Kill Odds and Move/Kill Radius. The Behavior function may not be needed to be overwritten for similar unit behavior with different strengths. However, this may not be the most interesting since you could just tweak the parameters for Infantry and have a similar effect.

==== "Exhausting" Mines ====
Mines have a finite amount of Res that they can produce. After all the Res are exhausted they become destroyed.

From my abstract:

''Using the Movable Feast Machine as an
Artificial Life development platform, this study analyzes the
interactions of hostile groups of populations in an environment
with limited resources.'' 

I haven't really fulfilled the **limited resources** part of the abstract. Competition should emerge from a scarcity of resources, like it does in the real world.

==== A "Miner" unit ====
This unit takes a number of steps and then creates a Mine, sacrificing itself. Note that all tribes could use the resources produced by this Mine.

===== What's left? =====
  * Allowing units to move through atoms in the same tribe.
        * Sometimes units get stuck in the base structure, and there's no reason why this should happen, it's not interesting.
  * Determining what's going to make the paper interesting.
        * There might be a couple of scripts in the pipeline that build a 1-tile egg drop per tribe and have them go at it.
        * The default behavior needs to be nailed down to get an inkling of what behavior is interesting.
  * Adding more unit types
  * Data collection