Should pawns on tracks have a class of its own?

[Itangalo]

There is a bit of information connected to pawns on tracks – space id, space index and sometimes path as well. If they were a class of their own, it would probably be cleaner.

Two other advantages:

• If pawn id matches a player id, a reference to the pawn could be added to agent.trackId. (It would mess things up if there also is a track with the agent id, though, so perhaps agent.pawns.trackId is better.)
• If a game would like a to add properties to pawns, which is quite possible when thinking about games like chess, it makes sense to make objects out of them.

Not something to do right now, but to keep in mind.

[Itangalo]

Yep, I really think pawns should be a class of its own. Probably worth fixing to 1.1 -- waiting will only cause more changes to existing code.

[Itangalo]

And: It should still be possible to not add pawns in advance, and just start moving them (if 'assumePresent' is true).

[Itangalo]

Mind dump:

Pawns have

• id
• space (reference)
• path (if grid movement is on)
• default number of steps?
• resolver method
• move method

When created, they are put on start space by default. And added to the track (myTrack.pawns[pawnId]. If ID matches one of the agent's, what happens? Probably agent[trackId].pawn, which would for example be agent.board.pawn or agent.culture.pawn. Makes sense.

[Itangalo]

I have come more than half way through this refactoring. Pawns and tracks become much more clear and easy to work with. Good decision.

[Itangalo]

Tests left. And the bug fixing.

[Itangalo]

Done!