State Pattern : Part 1.5

Not the full follow up I promised, but I've taken a few minutes out from a busy couple of days to look further into the state pattern that I discussed last week.

The core concept at the heart of this is that each Unit should know what it can and can't do, and the game "engine" shouldn't know, nor care about the exact mechanisms at work. For example, and Archer can attack ranged - we know this, but the engine doesn't need to know. What I've very briefly looked at is something like:

1. User has an Archer selected, and clicks on an enemy unit 10 hexes distance
2. The game engine creates a command object with the target hex and target unit in it and passes this to the ExecuteTurn method of the Unit
3. The Archer examines the command object, sees an enemy unit and forwards this to the Attack state, which in this case supports ranged attack.
   

I'm going to aim to build in some more flexibility, in that some of the states themselves take a command with the relevant units and weapons, which will allow for weapons to be upgraded, as well as units themselves being upgraded.

One thing I'm not wholly clear about is that, say we have a unit like a Rifleman - he can attack hand to hand and also ranged. Do I then provide an Attack state which supports both hand to hand and ranged, or two separate states? I think probably a single state which supports different attack types. Therefore,

Rifleman - attack state which supported ranged and hand to hand
Archer - attack state which supported ranged
Pikeman - attack state which supported hand to hand

This passes some responsibility onto the attack states - they need to examine the range and see if they support it, and I'm beginning to think that the Unit itself should perform this check, before passing anything to the state. I guess the best way to figure it out is to start doing some coding!

Also, this brings to mind another "issue" - say a Peasant Unit supports no attack in the early game - if it is passed a command object which contains an enemy unit, what do we do? Do we have a "null attack state", or does the Unit itself simply do nothing? I guess the Unit should know this.

I think this subject serves to highlight just how many concerns there can be for something quite simply in development.