Units and Maps

Dec 24, 2008 at 6:18 PM
Here's a more interesting question<evil grin>

I assume that there's a UnitType and a Map. I would reccomend also a GraphicsMap and GraphicsUnitType class that derives from the obvious and knows how to draw them. That way, as XNA evolves, it's going to isolate the potential issues.

How do you know how much it costs for a unit to move over the map? When checking for movement costs and whether a hex can be entered, is it the responsibility of the UnitType to know about the Map internals, or the Map to know about the UnitType internals, or should there be another class involved (MoveCost???)

I think that classic design suggests that the MoveCost class may be needed, although since that should be a small number of methods, it's also possible to add methods to the Map or the UnitType class that takes the other class as a paramter. There are probalby other solutions possible as well. I like the MoveCost solution, but it seems also a bit like overkill for this game. It's going to make the movement algorithms easier to program, though.

How far do you take this? Combat is another area that touches multiple objects. How much should the combat routines know about the UnitTypes and the Map, and where are the divisions there?

Ralph

Coordinator
Dec 24, 2008 at 6:49 PM
Good questions Ralph.  I've thought a little about these issues but not yet enough.

I believe there will be a separate class (like you suggested) that cross-references the unit's UnitType, the hex's terrain type, the weather, and any other variables (i.e. engineer bridging a river) and comes up with the movement points to enter the given hex.

I imagine something similar for the combat algorithm.

Regarding graphics, I think each Unit should be able to draw itself if given a SpriteBatch reference and screen x,y location.

Time to finish Christmas shopping!

Troy