Why is the command queue not unified?

[RCIX]

I'm a hobby .NET programmer, and if you don't mind i'm curious: why isn't your command system unified already? The logical way i can see creating a command is having an abstract Command class (or ICommand interface) which all commmand types derive from then having a Queue<Command> on each ship that orders are sequentially taken from and executed.

[x4000]

The player command queue is unified, and always has been.  So is the AI command queue.  So are the network transport messages, etc.

What is not unified is the queued future commands on individual units: for multiple attack targets, repair targets, movement waypoints, etc.  Why not for those?  Because in original designs for the game, no more than a single one of those sorts of commands could be issued at a time -- there were no waypoints or queuable attack targets of any sort until very late in alpha. 

Part of that stems from the fact that the game was originally designed as a turn-based game, where those sorts of things make less sense.  Part of that was the fact that most of my past games that I've coded have been action games, and so queued future commands were not something I'd ever had to think about before.  And, part of it simply comes from a lack of thinking ahead about how those differing systems might interact together -- I've played RTS games for years, but this was the first one I've ever coded.  In most RTS games I do not tend to make a whole lot of use of future-queued commands other than movement or attack separately, so that's how I coded this one.  It wasn't until much later, when other people started wanting to mix the two, that it ever occurred to me that this might be something to even consider.

[RCIX]

sorry that's what i meant. The part i don't understand is what sort of class architecture would lead to not being able to mix command types. Of course i understand if you don't want to give out the details of your code, i was just curious.

[x4000]

There's no class architecture at all for these sorts of commands.  There's simply a List<Unit> list for attack targets, and a List<Point> list for movement points, etc.  And there's no way to queue repair/transport commands at all at the moment, so those are just properties.

The other game commands, etc, are a single class with a factory-pattern parser handling operations, and that's what I'm moving to for my new partially-complete UnitCommand class, which will replace the above subsystems as the unified command queue.  Generally speaking I'm a not a huge fan of doing lots of class/interface inheritance unless there is really a reason to do so.  Earlier games I have coded in C# had an individual subclass for every type of enemy and object, and it was a nightmare to maintain.  So Alden Ridge, and later AI War, were both implemented with some different design patterns -- there is only one class for all "foreground objects," for instance.  This works exceedingly well and is very flexible in most ways.

Times where I feel like inheritance is a must:  differing implementations of the same thing.  So for example, Alden Ridge used to support two different rendering modes, a GDI mode and a DirectX mode.  I had a central IRenderer interface, and then a Direct3DRenderer and a PaintRenderer, both with wildly differing implementations, and that was very successful.  I would do the same sort of thing in the future again, given a similar multi-target situation.  AI War, even though it is DirectX-only, is still coded from a premise that would make swapping in that sort of thing fairly easily.

In general, I'm a big follower of most OOP principles, but also the higher-level principles of Design Patterns.  And so generally I follow whichever design pattern is the most relevant at any given time.  Until post-release, I never saw the "future commands" of the individual units as being anything related, just as being discrete properties of "am I doing this?"  Not the best way to think of that, but there's going to be chinks in any sufficiently-large design.  Generally speaking, AI War is vastly more sensibly designed than that.

[RCIX]

aah, now it makes sense! I also generally avoid inheritance except where it's necessary. Thanks for the explanation!

[x4000]

No problem!