Advise Please 2.0

[a10e29]

Edit: It might be a better idea to start with TheIdeasMan first post

> I've moved the functionality (non gratuitously, disabled the other classes until I feel I have one well behaved and well manner class) from derived Pieceto their components (Element) and eliminated one of the poltergeists (the only structural change so far).

Hi,

Just further on this, you say you have moved functionality from one class to another. That might be alright if the class tree is valid, but so far I am not sure what you had in those classes to verify that validity. Maybe you could post the code you have now (Just the 1 class) in the forum, then everyone can look at it and give their opinions on how it should be organised.

Hey guys,

Looking for advice on:
Structure
Style
Things to improve upon
The stupid things I've done


Thanks

[TheIdeasMan]

Hi,

Good to get the discussion back in the forum again :+) Note to everyone else: I think it is much better to have the discussion here, where the OP has access to everyone's knowledge, rather than just rely on my comparatively small experience. I always say this to anyone who PM's me.

@a10e29

I can understand how you are reluctant to make your whole project public, but what about just the Element class ? The idea being that we will start there with fixing things up. The CombatFormation class is not really helpful to others at the moment.

I can see from your PM, the Element class is a Soldier (could you rename it that?), and you want to have formations of them (A Squad, Section or Troop?)

In your Element class, you have lots of enums that describe it's experience level (Veteran, Regular etc.); it's role (Spearman, swordsman etc.); it's traits (dual_wield, two_weapons, herobrave, brave etc.); it's race (human, undead etc.)

Some things are best stored as an attribute (member data), but other things might be better as an object stored in the class (HAS A) then you can call functions that belong to that object. I guess it depends on what functionality there is going to be.

I wonder what the other members think?

Your class has lots of member variables, but the constructor only takes 4 arguments. The ctor should initialise all the member variables. Member variables should be private, provide interface functions to use them. Maybe there is too much stuff in this class?

The class has some items which you moved from the Formations class, but as I suspected that inheritance isn't really valid : A Formation is not a Soldier, rather a Formation is a collection of Soldiers. When I said to push things up the class tree as high as is validly possible, that implied that the inheritance tree was correct to start with.

Just wondering what you thought of my Idea of starting with this:

class Actor;
class Player : public Actor;
class Enemy : public Actor;

class Resource;
class Medical : public Resource; // for a MediPack say
class Weapon : public Resource; 
class Tool : public Resource;

A Soldier "IS A" type of Player.

Some other ways to think about this whole idea of classes:

A class should contain some private data about the object (aka some attributes) and interface functions which allow others to interact with some of that data, and nothing else. For example a Person class shouldn't have functions like DriveCar, ShootGun etc. Car and Gun are separate classes and have their own functions which allow their use. There might be a function external to a class : DriveVehicle(Person * , Vehicle * ); Design patterns might help a lot with many to many interactions.

[TheIdeasMan]

Hi,

Another bombshell:

Limit your functions to 40 LOC or less, including main().

Functions should do one conceptual thing, if it is a complex task then call other functions to do the individual parts.

Compound statements, such as the bodies of loops, switch cases etc are all good candidates for functions.

With main(), put functions declarations before main, and the definitions after main. That way main is at the top of the file, we don't have to go looking for it. I eventually found main on line 285 in the file.

Really try to avoid using goto, you most likely don't need it.

If you have 9 levels of conditionals and loops, then there is probably a better way. The code will be slow if you have lots of nested loops.

As a matter of style, if you have lots of arguments to a function, consider formatting them like this:

hexGrid.push_back(new Hex((hexGrid.at(i - 1)->xPos + 168), (hexGrid.at(i - 1)->yPos), hexGrid.at(0)->tool, hexGrid.at(0)->type));

hexGrid.push_back( new Hex((hexGrid.at(i - 1)->xPos + 168),
                  hexGrid.at(i - 1)->yPos, 
                  hexGrid.at(0)->tool, 
                  hexGrid.at(0)->type)
                  );

Can do the same for function declarations.

[a10e29]

what about just the Element class ?

Element.cpp and .h:
https://www.dropbox.com/sh/3abxvn3wyf4wazp/AAAzAIjS4Jol8aXdtsIBF3xWa?dl=0

could you rename it that?

class Element; //I need a better name for this I know

I will, it causes quite a bit of chaos.

A Formation is not a Soldier, rather a Formation is a collection of Soldiers.

std::array<std::unique_ptr<Element>, 120> elements;
You are correct.

you want to have formations of them (A Squad, Section or Troop?)

Yes, Element/Soldier should be the smallest unit of interaction/exchange within Squad, Section or Troop Squad, Section or Troop should be the level of interaction the player moves them about.

Your class has lots of member variables, but the constructor only takes 4 arguments.

Also correct. The ctors call helper functions which assign other members their value based on the four arguments, the idea of switch statements in the ctors seemed a bad idea at the time.

Maybe there is too much stuff in this class?

So I should take level, role, traits, and race and make a class Personality out of them?
And std::unique_ptr<Item> items[8]; should be made into a class Kit?

Really try to avoid using goto, you most likely don't need it

.
When it is not possible to break out of a nested loop by using return what are some better alternatives?

bool conditionMet = false;
for()
{
   for()
   { 
      if(blah) 
     {
       //do something
       conditionMet = true;
       break;
      }
   }
   if(conditionMet)
   break;
}

???

Just wondering what you thought of my Idea of starting with this:

I appreciate any and all suggestions you give me. As a starting point for something small scale (

A Soldier "IS A" type of Player.

) I'd guarantee that it would be a great start. Unfortunately for me I'm a dreamer "A Soldier IS A small part, but still important, piece of the puzzle"

[TheIdeasMan]

First up, I don't think I should be the only one giving advice here, hopefully some of the other members will be willing to help out :+)

Element.cpp and .h:

Great, that will help others comment on your design :+)

Rename Element to Soldier

I will, it causes quite a bit of chaos.

I know it's a pain to rename a base class like that - there are probably references to it thorough the code. But having looked at the rest of your code, I think there will be major changes. As dhayden says, starting again. So I wouldn't attempt to re-factor it through your current code-base. Actually do you use version control? I would look at starting a new branch or even start a band new project.

The ctors call helper functions which assign other members their value based on the four arguments, the idea of switch statements in the ctors seemed a bad idea at the time.

OK, but those helper functions should be private.

When it is not possible to break out of a nested loop by using return what are some better alternatives?

This goes back to the lack of functions, and the fact that you have so much nesting everywhere. If the body of the if statement or it's enclosing loop was a function, then you could return a value.

Unfortunately for me I'm a dreamer "A Soldier IS A small part, but still important, piece of the puzzle"

The trouble is that you have a relatively large project (25 KLOC is more than trivial) with lot's of complexity, but you have major drama everywhere, not just the design, the code as well. So my suggestion was to start out small and trivial, get that working, then gradually add more features.

With the code, some other things that make it awkward to understand are things like abbreviation of function and variables name, and perhaps inappropriate names - or rather lack of meaningful names. Good names means self documenting code, one should be able to read it and have a good understanding of what is happening. Here is a comical example of what I mean: http://www.cplusplus.com/forum/lounge/176684/#msg872881

I might wait to see what other people have to say before I mention anything else :+)

[a10e29]

Rename Element to Soldier

Soldier.cpp and .h
https://www.dropbox.com/sh/kdkx90s0ukkqjwf/AAD82MxTb1-4-eCru-1oGVJXa?dl=0

Limit your functions to 40 LOC or less, including main().

reworked main
https://www.dropbox.com/sh/nh5vbf9qyzae2iw/AADw-AbiewLfAQZtwilPjsgya?dl=0

All .h's
https://www.dropbox.com/sh/y9dmz50ulyok3gv/AACNVeP7YadqKU-MM07qMJdza?dl=0

I can understand how you are reluctant to make your whole project public

I'm a bit reluctant post a link here for it, however if you really do want to see it send me a PM.

[TheIdeasMan]

Ok, good work :+)

But a note of caution though: there is still going to be massive changes, as I said earlier I would hold off on altering your existing code. Seriously consider starting a new project, gradually build it up from scratch.

About what should be a class and what shouldn't:

Say a Soldier has a rank of Sergeant. In a simple scenario, that might exist only as private member variable of type std::string or as you have it an enum. However, if it is going to have some responsibility or functionality, then it would need to be a class. A weapon (or any type of resource) is a good example of something that should be a class. The Soldier can "OWN" them: "HAS A" with member variables.

Now I am not saying you should go and create 20 classes representing weapons or armour say. A Gun class might still only have basic info like it's name and calibre, but at least you have taken that info out of the Soldier class. It's the same thinking as a Person doesn't have a PushBrakePedal function. One can still have 20 Gun objects with different names etc, but we have just the one class for them.

About complexity:

One of the not so obvious things about OOP design is how all the classes interact with each other. If one has a bunch of complexity in a class, then one has to define how that is going to work with everything else. If the complexity exists in a class and is not implemented in terms of the other classes, then we may as well not have it: it doesn't do anything.

So that's another reason to start simple: adding something seemingly innocuous like 10 different Armour types might have quite a large effect on the complexity for the whole application. Those implications on the design need to be managed.

What are we going to have in our Soldier class?

With the Soldier class (indeed any class), we have to ask ourselves: What attributes does it have? ; What things does it own? ; What actions can it do? So we need to careful about anything external to Soldier, we have to allow for interaction with external things, but we don't want any external logic in our class. That means anything to do with fighting or battle or tactics, a Soldier should perhaps only have an UpdateHealth function, all the logic for battle should be elsewhere.

So can you write down what you want to have in your Soldier class? Try not to put in too much. We can then see how that is going to fit in the scheme of things.

One thing you could do: create an Actor, Player and Enemy classes:

class Actor;
class Player : public Actor;
class Soldier : public Player
class Enemy : public Actor;

Think about what variables and functions are going to go in each of those classes, what variables / functions can be pushed upwards? We can call base class functions from the derived class.

In my mind, we haven't yet finalised what is in our class, but here is some observations on the existing code, again I would be reluctant to rush in and change it.

With those enum's, I would be inclined to pull them out of the class and have them available in the scope that calls the class constructor, you can put them in a header file. The enum value would then be an argument to the ctor call. IMO scoped enum's are better, they don't decay to an int:
http://en.cppreference.co/w/cp/language/enum

They also make things easier to read, as in : Race::Human

With your ctor's consider using a member intitialization list:

Soldier::Soldier()
    : // colon introduces member initializer list
    baseAtt (1) ,  //direct initialize
    baseDef(1) ,
    armor (2) ,
    tatics(1) , // high number represents more advanced tactics ie more effiecent
    support (0) ,// support represents it's ability to handle many situations
    numberOfAttacks(1) 
 
{}

http://en.cppreference.com/w/cpp/language/initializer_list

Before the compound statement that forms the function body of the constructor begins executing, initialization of all direct bases, virtual bases, and non-static data members is finished. Member initializer list is the place where non-default initialization of these objects can be specified.

With the names of things, don't abbreviate them and use something meaningful. You are right, items is not a good name, call it what it is: BattleKit or something else equally descriptive.

What do these mean?

int baseAtt;
    int baseDef;
    int armor;
    int support;
    int tatics;
    int inia;

Class member variables should be private, and provide functions to use them. It may not be necessary to have get and set functions for every member variable. We only need functions for the member variables we want to expose as the interface for the class. We only need set functions if the value changes (in an external sense) after construction.

There we go more stuff to think about :+)

[TheIdeasMan]

I pointed this out to the OP in a PM, I look forward to replies from others :+)

TheIdeasManPM wrote:

I should point out that I am still a backyard coder myself, I can't profess to know everything about how this should be done in the best possible manner. This is why it would be good to get some input from some of the other members, maybe some of them are having a long Easter break?

At the moment I am thinking ahead about how to simulate a Soldier with a weapon versus an Enemy with no defences - real simple: each time the weapon is fired, the Enemy's Health is reduced. Probably an external function which uses the Mediator Pattern

[dhayden]

a10e29, can I see your code? Send me a PM with a link. I'll look it over and try to offer some advice.

[dhayden]

Thanks. One thing that strikes me about the code is an awful lot of code where you should data instead. For example, consider Monster::assignByIdentity().

void::Monster::assignByIdenity()
{
    struct Params {
        Solder::role r;
        int type;
    };
    static Params typeMap[] = {
        { Soldier::swordsman, Soldier::Veteran },
        { Soldier::spearman, Soldier::Regular },
        { Soldier::ranged, Soldier::Levy },
        { Soldier::greatSword, Soldier::Regular },
        { Soldier::swordsman, Soldier::Regular },
        { Soldier::axeman, Soldier::Regular },
        { Soldier::spearman, Soldier::Regular },
        { Soldier::axeman, Soldier::Regular },
        { Soldier::battleaxe, Soldier::Regular },
        { Soldier::spellsword, Soldier::Regular },
        { Soldier::spearman, Soldier::Regular },
        { Soldier::swordsman, Soldier::Regular },
        { Soldier::spearman, Soldier::Regular },
        { Soldier::axeman, Soldier::Regular },
        { Soldier::maceman, Soldier::Regular },
        { Soldier::ranged, Soldier::Regular }
    }

    Params *p = typeMap[identity.type];
    for (int i=0; i<20; ++i) {
        soldiers[i] = std::make_unique<Soldier>(p->r, p->type);
    }
}

Even better would be to put this table in a config file.

[a10e29]

Even better would be to put this table in a config file.

I like it. quick question if you don't mind.
When you get the data out of the config file how would you store it?

struct Param {
	Soldier::role; r
	int type
};

std::array < Param, 20 > preDefinedParams;

???

[a10e29]

This is a background conversation I've had and I believe it is important to part of this topic:

a10e29:

I've been thinking about how to answer that. Thinking in terms of crunch and fluff.

 double hits;
int support;
	int tatics;
	int iniative; // how fast
	int chanceOfHit;
	int chanceofBlock;
	int armorSave;
	int chanceToCounter;
  

are crunch. In other words these must be there for Soldier to function properly IMO. support and tactics are crunch because they are multipliers (they crunch values on both ends of duel()), the rest are crunched from these:

	int baseAttack;
	int baseDefence;
	int armor; 
race genome;
	qualityofType qualityOfSoldier;
	role type;

are fluff. Where I'm stuck is how do I get the fluff to get the crunch? In otherwords they are a one off ordeal to get the crunch

TheIdeasMan:

In other words these must be there for Soldier to function properly IMO.

Remember we are trying to keep external things out of this class. There are other ways to interact with external things, without storing that info in the Soldier class.

Soldier has these members and I'm going to break them down philosophically, what I think they should be doing and then propose where they should go:

	double hits;
	int baseAttack;
	int baseDefence;
	int armor;
	int support;
	int tatics;
	int iniative;
	int chanceOfHit;
	int chanceofBlock;
	int armorSave;
	int chanceToCounter;
        std::unique_ptr<Item> kit[8];

double hits;
This is a measure of toughness before dying, I think it should stay in this class

int baseAttack;
	int baseDefence;
	int armor;

These represent the most basic attributes and are supposed to be a reflection of kit[]. They should not stay here, I'll get to where I think they should go in a bit.

int support;
In my head this is a measure of "how much more difficult it will be to kill me". Why would that be? Chiefly from other soldiers. I think the classes that have soldier as a data member should have this, it would be applied at battle time and be a measure of both their numbers and gear(a bow would offer more support than a spear ect, 120 bowmen would offer more support than 1 bowman)

int tatics;
In my head this is a measure of efficiency. Does soldier have tactics? no they use tactics. Does the formation have tactics? no they are a collection of soldiers there for they use tactics as well. Do factions have tactics? yes it is an understanding of who goes where and why they are there.

it is an understanding

this opens up the possibility for tactics being part of tech tree!!! but one thing at a time.

int armorSave;
"Ah ha!!! you scored a hit but did no damage!" this clearly belongs elsewhere, I'll get to that in a moment.

int chanceOfHit;
	int chanceofBlock;
int chanceToCounter;

These are composites of most of the aforementioned members, "skill" would be a good way to sum them up. These should stay.

Now for some more boring dia...But A! you forgot std::unique_ptr<Item> kit[8]; and int iniative; sure haven't.

A pikeman is a soldier but he is only a pikeman because of his pike (std::unique_ptr<Item> kit[8]) and his ROLE is pikeman. it should be a has a relation.

iniative is how fast or how smart (at the same time) "I should be running away because..." and "I can beat you there". clear as mud? This value should be in the polymorphic classes of Soldier. What would make a soldier faster or smarter against another soldier? experience.

So one idea I had was making derived classes out of
enum qualityofType

Regular: public Soldier {};
Veteran: public Soldier {};
// ect 

To sum up which parts should go where:

Soldier { 
int chanceOfHit;
int chanceofBlock;
int chanceToCounter;
Kit myGear;
}
Verteran: Soldier
{
 int iniative;
}
Piece
{
int support;
int getSupportFromNearbyPieces();
int getMyFactionsTactics();
}
Faction { int tatics;}
Kit{
struct sumOfmyGear
{
int armorSave;
int baseAttack;
	int baseDefence;
	int armor;} gearSummerized;
std::unique_ptr<Item> itemsInMyKit[8];
}

Does this seem reasonable?
Well back to work implementing dhayden's advice.

[dhayden]

When you get the data out of the config file how would you store it?
vector<Param>. That way if you add a new type you can easily handle it.

As for the other stuff. Consider a soldier named Bob:
- Bob starts out as a regular soldier.
- At some point Bob gets a pike and becomes a pikeman.
- Later he looses his pike.
- 5 years later he retires and becomes a Veteran.

It seems to me that whether you're a regular soldier or a pikeman or a veteran are attributes of being a soldier. In particular, when you become a veteran, you don't become a different class any more than a double becomes an integer when you assign 5.0 to it.

[TheIdeasMan]

dhayden wrote:

It seems to me that whether you're a regular soldier or a pikeman or a veteran are attributes of being a soldier.

Yes, I was just about to say the same thing :+) So these regular, pikeman, veteran are really a type of Rank - like Sergeant say. They could just be an enum or std::string as a private member of the Soldier class. As I was saying earlier, how is that going to be effected in terms of the others classes? ; if it isn't implemented, then it not worth having it: it doesn't do anything. If we are going to have it, then it is a further complication - it is going to alter the behaviour of other objects. I don't think we need that right now. However, it might alright to have it if you just want to print: "I am a Veteran" .

To sum up which parts should go where:

I think that you are wanting too much stuff for this early stage. It has the effect that you are wanting to put stuff into the class that doesn't belong there. We could have a Weapon, some Kit, Rank, Armour: these are reasonable things for a Soldier to own. All the other stuff is external - especially in relation to Piece (Platoon, Squad whatever), Tactics and Factions - those things are all quite big complications.

I was going to start simple, and only have the soldier owning a weapon. Then create an enemy, followed by a way of fighting with it.

So with that in mind I would create these classes:

class Actor;
class Player : public Actor;
class Soldier : public Player;
class Enemy : public Actor;
class Troll : public Enemy;

class Resource;
class Medical : public Resource; // for a MediPack say Optional right now
class Weapon : public Resource; 
class Gun : public Weapon;
class Tool : public Resource;        // Optional right now

See how you go with that. Question: where does the health variable go?

I said there would be massive changes: they start here :+)

The next mission is seemingly simple: repeatedly fire the Gun at the enemy until it dies.

I said it was seemingly simple, but alas consider this:

http://www.marco.panizza.name/dispenseTM/slides/exerc/eventNotifier/eventNotifier.html

It might seem platinum plated and a lot of work to implement, but consider the benefits:

It can be used for a host of things, not just the combat. There can be more than one event service. Consider orders and co-ordination of Soldiers. The Enemies might have their own Coordination;

There is decoupling, flexibility, filtering, and a variety of ways to subscribe;

It should take a lot of mess out of the code: we have a consistent interface for doing things.

What do you think about that?

[a10e29]

What do you think about that?

I've skimmed over it, definitely going to reread it when I have more time.
In your option who would be the publisher?

Question: where does the health variable go?

Soldier and Troll then provide interfaces in Player and Enemy

Even better would be to put this table in a config file

I want to pursue this however it's turned into a sea of unresolved externals (most like because I'm not doing something in project properties, in the little demos that came with the parser libraries). What would you say about using passive data structure/"plain old data"?

#ifndef
#define
struct combination
{
Soldier::role 
//ect
};
struct Params {
std::vector<combination> allPossibleCombinations
}
#endif 

Or something like that. Going to be AFK for a while again.

[a10e29]

Goals for the weekend:

It might seem platinum plated and a lot of work to implement, but consider the benefits:

I'm going to branch off the project and give this a try. I'll post links of the new classes in the OP, with dates, for the public and I'll PM the code Sunday night/ Monday morning to everyone who's been participating.

On the Data front I'm waiting for criticism on the POD, I'll give the Config4cpp and libconfig another try though.

Regards,

-A

[TheIdeasMan]

Soldier and Troll then provide interfaces in Player and Enemy

Disagree :+) IMO it and it's functions would go into the Actor class. That is one of the whole ideas of inheritance: things get inherited, so we only write them once. And that is why the Actor class was created in the first place, both Player and Enemy have a health value, so we pushed to up to the Actor class. Even though Actor is abstract, note that it can still have data and functions we can use: we get at them from the derived class, never mind that we don't ever create an instance of Actor.

In your option who would be the publisher?

So my idea for this was to first create a Combat class, each Actor can own a pointer to one of these objects. The Combat class would be both a publisher and subscriber to CombatAction events. Would need to decide what events we are going to have and set up a class hierarchy of them. These events would need to have arguments for the Sender & Receiver and how much damage is intended. So this is slightly different from the original intent of the Event Manager, the Receiver does need to know who the Sender was, in order to retaliate. The Combat class ctor would need pointers to the Actor, it's Weapon, Armour or anything else that might be necessary to enable interaction with other objects for this activity.

The idea that an Actor has a Combat object is consistent with allowing the class to have an ability to do something, but the details of it are elsewhere. We could also have a Move object, this could come in handy for when we have Command events. The Commander (maybe the user) sends a MoveForward event say, and all of the members of a Squad receive and carry out that message. A Fight event could also come from a Commander. But that is in the future, implementing it might have it's own problems / effects.

Cheers :+)

[a10e29]

Disagree :+) IMO it and it's functions would go into the Actor class

I need to stop thinking of inheritance trees as the trees I'm used to seeing. The bottom is on top.

These events would need to have arguments for the Sender & Receiver and how much damage is intended.

My idea on this was
std::vector<bool>
signaling a possible hit for the input and changing the std::array<> soldiers to std::vector. when otherSoldier (the one being attacked) returns false use .pop_back() forgoing the need for symmetry code.

Is there a way to control (with out having to go back and hard code (iter<20)) the size of std::vector other than using
const unsigned int maxVectorSize?

[TheIdeasMan]

My idea on this was

Not sure that you need to do any of that :+) Pretty sure we don't want to be maintaining any vectors of who is being hit, let the Filter system do it's work :+) I gather that it's an OOP principle to let individual objects do their work, and not to have some global container of who did what to whom. Not to say that there is isn't a role for static or dynamic tables, but this isn't it IMO.

On the web-page, in the code section there is some Java code for the Subscriber, showing how it handles an event. The arguments to the function which publish an event is central to the whole idea of the system.

...when otherSoldier (the one being attacked)....

When I said "Actors own a pointer to a Combat object", that means it applies to Players and Enemies in general.

....forgoing the need for symmetry code.

The Event Notifier is supposed to be very flexible and agile, I can't help thinking that to try to avoid symmetry code will ruin that. Let's not sabotage it before we start :+) Sorry for partially quoting your words.

Some other things to note:

I am not sure if my original idea of making the Combat object both a Publisher and Subscriber will work, might need to have 2 classes here to cope with that. Am going to start working on this myself, haven't ever implemented one of these before - will give it a Larrop just to see if I can figure it out :+)

With the Java code, I know very little about Java - probably enough to get me into trouble ! But it would be good if we could avoid using new and delete, try to use the STL as much as possible, or smart pointers where necessary. Another issue is the use of exceptions, while not a bad thing, if we are going to have them we would use them everywhere.

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html#S-errors

CppCoreGuidlines wrote:

E.1: Develop an error-handling strategy early in a design
Reason

A consistent and complete strategy for handling errors and resource leaks is hard to retrofit into a system.

CppCoreGuidlines wrote:

Note

But what do we do if we are writing a program where exceptions cannot be used? First challenge that assumption; there are many anti-exceptions myths around. We know of only a few good reasons:

We are on a system so small that the exception support would eat up most of our 2K or memory.
We are in a hard-real-time system and we don’t have tools that guarantee us that an exception is handled within the required time.
We are in a system with tons of legacy code using lots of pointers in difficult-to-understand ways (in particular without a recognizable ownership strategy) so that exceptions could cause leaks.
We get fired if we challenge our manager’s ancient wisdom.

There is a bunch of good reading in that document by Bjarne & Herb.

Is there a way to control (with out having to go back and hard code (iter<20)) the size of std::vector other than using
const unsigned int maxVectorSize?

Use an std::array if you know something will be a fixed size. I only use array if I know that is going to be the case, my philosophy about the other STL containers is "It has how many things that it has" . For sizes, I use std::size_t because that is what STL size() functions return, and it's easier to type than unsigned long

In terms of what container we use for a Squad, I haven't thought about that yet - plenty of other things to do first.

[dhayden]

Regarding POD - go for it. My main point was that the current code is a sea of data manipulation that could be table driven. Ideally the tables would come config files, but hard-coded data is fine.