http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660If anyone is still interested, I posted my own thoughts on this on my blog: "Spearmen, Javelin Throwers, and the State Pattern. Oh My!" [www.squaredroot.com/.../spearmen-javelin-throwe...](http://www.squaredroot.com/2009/08/15/spearmen-javelin-throwers-and-the-state-pattern-oh-my/)http://ayende.com/4100/let-the-fighting-commence#comment10http://ayende.com/4100/let-the-fighting-commence#comment10Sun, 16 Aug 2009 01:41:28 GMTAs others have hinted / said, I would consider wrapping things like Attack, Move, etc. in some IAbility interface, and let each Unit have some collection of these which can be added to when an Upgrade occurs (that's a feature of the game, right?). Depending on the desired features of the engine, I would also consider using the flyweight pattern to distinguish between a unit type and a unit instance. For example: // behavior and data that are true for all unit types (e.g. the Heavy Tank has a Max HP of 100). interface IUnitType { Abilities InitialAbilities; // other data. } // behavior and data that differ within instances of a given unit type (e.g. one Heavy Tank might have an HP of 75, and another might have only 50). interface IUnit { IUnitType type; // useful for, e.g., ensuring that a Mechanic will bring up a HeavyTank's HP only up to 100, no more. int CurrentHp; int CurrentSpeed; IAbilities Abilities; // whatever other behavior units have a runtime. } // loading the game: UnitTypes unitTypes = {new UnitType("Tank", ...), ...}; // creating a unit during the game: // The unitType has all initial state data. aTank = MyUnitFactory.CreateUnit(theTankUnitType); So that demonstrate Enginey stuff. More Gamey extensions might include (if you need them): class TankType ... class Tank ... In place of the flyweight pattern, you could instead use prototypes describing the start states of the IUnits, especially if that ends up being the only thing you describe in your IUnits (as may be the case with Upgrades, etc.). http://ayende.com/4100/let-the-fighting-commence#comment9http://ayende.com/4100/let-the-fighting-commence#comment9Mon, 10 Aug 2009 18:47:21 GMTSomething like the following, this is unfinished BTW.. interface IAction { Execute(); } interface IAttack : IAction {} interface IMove : IAction {} IUpgradable Upgrade(IAbilities) interface IAbilities { IAttack Attack; IMove Move; } interface IUnit : IUpgradeable { Upgrade(IAbilities); Attack(); Move(); } class Unit : IUnit { IAbilities _abilities; Unit(IAbilities abilities) { _abilities = abilities; } Attack() { _abilities.Attack.Execute(); } Move() { _abilities.Move.Execute(); } Upgrade(IAbilities abilities) { _abilities = abilities; } } class RangedAttack : IAttack { Attack() { FireBowAndArrow(); } FireBowAndArrow() { } } http://ayende.com/4100/let-the-fighting-commence#comment8http://ayende.com/4100/let-the-fighting-commence#comment8Thu, 06 Aug 2009 16:50:18 GMTI would recommend that you look at your object model a bit differently. Let me explain. The difference between the archer, clubman and peasant in terms of the engine code should be negligible. They will all behave in a similar manner having actions such as attack, move, etc. However, the difference between these units in terms of the game could be vast. The way they attack, their movement rates, etc. Therefore, try to create a separation between the elements of your design which are engine focused versus elements that are game logic focused. I found this distinction to be helpful every time I’ve dabbled with game programming. http://ayende.com/4100/let-the-fighting-commence#comment7http://ayende.com/4100/let-the-fighting-commence#comment7Thu, 06 Aug 2009 08:41:56 GMTVery interesting solution, and something I'm going to look into today. I had looked into using Strategy, but I found I was ending up with the game engine becoming a God Engine. I'd also looked into "applying" upgrades to the base unit (my basic solution was having a list of IUpgrades on each unit), but this was a vast oversimplification and didn't allow for anything other than modifying the base unit properties. http://ayende.com/4100/let-the-fighting-commence#comment6http://ayende.com/4100/let-the-fighting-commence#comment6Thu, 06 Aug 2009 07:44:23 GMTIt would be very flexible if the unit were to have a set of weapons, and each weapon had a set of commands. http://ayende.com/4100/let-the-fighting-commence#comment5http://ayende.com/4100/let-the-fighting-commence#comment5Wed, 05 Aug 2009 21:59:07 GMTPmlarocque, Strategy pattern isn't very good here, it doesn't provide for state management, and you need it here. State & Strategy are closely related, but state allow changing itself http://ayende.com/4100/let-the-fighting-commence#comment4http://ayende.com/4100/let-the-fighting-commence#comment4Wed, 05 Aug 2009 21:40:39 GMTI could imagine an extension mechanism that is inherent to every unit. Extensions are many, can act as composite, can be merged (e.g. Power-Ups) or removed again (e.g. LifeCount). In a cycle, a Unit responds by letting all its extensions participate in the Unit's reaction. http://ayende.com/4100/let-the-fighting-commence#comment3http://ayende.com/4100/let-the-fighting-commence#comment3Wed, 05 Aug 2009 20:09:41 GMTThe strategy pattern used like in the head first design pattern would be good, attach new attack strategy at runtime. http://ayende.com/4100/let-the-fighting-commence#comment2http://ayende.com/4100/let-the-fighting-commence#comment2Wed, 05 Aug 2009 18:51:44 GMTIn my opinion, the state machine pattern is one of the most elegant, simple solutions to most problems. For some reason, a lot of people seem to miss it, or not even realize it's available for them. Good post. http://ayende.com/4100/let-the-fighting-commence#comment1http://ayende.com/4100/let-the-fighting-commence#comment1Wed, 05 Aug 2009 16:11:43 GMT