Well, since the "Making Weapons" topic seemed to provide a lot of good feedback, I thought it''d be good to throw in some ideas on how to design infantry units for a wargame. I''ve come up with two approaches which at first glance, seem extremely similar but which have ease of use or intuitive differences. In my game, infantry groups are made up of a number of men which make up a Team. A Team can be 2 men, 5men, 10men, whatever, though generally speaking, 7-10 is the average. Infantry, like vehicles, have certain functionality that need to be exhibited and controlled. Obviously they can move, but it''s affected more by weight encumbrance, fatigue, and discipline rather than motors and fuel. An infantry group often has offensive capabilities...but each trooper can carry a different kind of weapon which creates a problem. Also, each trooper carries different sets of skills which can be used in the game. For example, you have medics, Communications experts, Forward Observers, snipers, scouts, etc. And then you even have different classifications of troopers, for example: Marines, Airborne, Mountain, Light, Mechanized, Irregular, etc etc. So, how do you combine all of these elements into an Infantry Team? My first thought was you just have a big "lump". This lump identifies, how many men are in the team, it has a record of each kind of weapon, along with how many of each weapon, the skill sets of the team (maybe a Team of 8 has one medic and an Anti Tank specialist), and finally the classification of the Team (Marines, Airborne, Spaceborne, MartialHouse, Light, etc etc). The Lump would also determine group traits, like Equipment loadout (how much food and equipment do they carry on foot), morale, fatigue, discipline, and training. The second thought was actually creating a Trooper class that carried all of the elements listed above, but carried the data himself. Then when he is created, he is plugged into some kind of templatized array (probably a vector) and the Team is defined like that. The first method seems easy enough, and I think it will be quicker to build and design. It also seems like less of an administrative burden, and less of a system resource hog, because the computer deals with the Team as a monolithic whole, rather than in the second method wherein each member has his own seperate data and functions (requiring more function calls and data tracking). In some ways though, the 2nd method is more intuitive. You design the trooper, and you put him into a "squad", much like the real world. Which system seems to make more sense? I''m preferring the 2nd approach because I think it''s more intuitive, and maybe easier to design for players and therefore use. I''m willing to pay the prive for a slightly slower game if conceptually its easier to understand. I see one more problem with the monolithic lump method. Since the game data manager sees the Team as "one" thing, it may be hard to figure out what happens when it gets damaged. For example, let''s say the Team has an anti-tank weapon, but the team takes two casaulties. Do you just randomly determine who gets killed....meaning possibly the AT gunner dies? And if so, how does the Team class determine that it no longer has the AT gun at its disposal? They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety. - Benjamin Franklin

The 2nd approach would also facilitate individual transfers -- when each soldier becomes part of a new unit, he retains his individual knowledge of tactics.

Let''s say that some irregular unit was torn to shreds by the enemy and only two managed to escape. These two are picked up by a Mech. Inf team, that got cut off by an enemy advance, comprised of 3 of its original 5 men team. The two irregulars could fill the positions occupied by the two dead men, but contribute whatever tactical knowledge they acquired as a result of experience as irregulars.

When they get back to base, the knowledge they contributed is cut off from the combined team. This kind of thing is difficult to track without knowledge on the soldier level. Same with equipment. Same with command experience (CO gets killed, 2nd has less command experience, but gains in experience as he commands. If the unit is assigned a replacement CO, the 2nd still retains this extra command knowledge.)

Ahh, and that would also make more sense with my whole concept of reinforcements. My game relies more on reinforcements rahter than building brand new units (though that can be done too), and by having each Trooper encapsulate his own data and functionality, he preserves his attributes.

But then that means the Team class is going to be a different version of my Cluster class, which essentially holds various kinds of different classes at runtime. The Team class will have to have functionality to manage its Troopers that make it up, and understand what kind of functionality and state data it has as a whole.

Okay, I think I''m hooked on doing it this way, even though it''s going to be more complicated, but now that I think about it, how am I going to create new Infantry types with different training and functionality? Let''s say that I want to mod my game to turn it into an 1800''s wargame to do Napoleonics. Now I have to create things like Grenadiers, Fusiliers, Foot line, Guards, not to mention cavalry (Curassiers, Chevaliers, Lancers, Heavy, Hussars amongst others). I suppose I could make virtual functions, so that Team->form(enum line) would have different meaning to a modern 21st century soldier, and a 19th century soldier. Ditto for something like Communicate or Resupply.


They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety. - Benjamin Franklin

quote:But then that means the Team class is going to be a different version of my Cluster class, which essentially holds various kinds of different classes at runtime. The Team class will have to have functionality to manage its Troopers that make it up, and understand what kind of functionality and state data it has as a whole.

*cough*inheritance*cough* If your Cluster class is a template, then inherit from the specialized Cluster.

quote:Okay, I think I''m hooked on doing it this way, even though it''s going to be more complicated, but now that I think about it, how am I going to create new Infantry types with different training and functionality? Let''s say that I want to mod my game to turn it into an 1800''s wargame to do Napoleonics. Now I have to create things like Grenadiers, Fusiliers, Foot line, Guards, not to mention cavalry (Curassiers, Chevaliers, Lancers, Heavy, Hussars amongst others). I suppose I could make virtual functions, so that Team->form(enum line) would have different meaning to a modern 21st century soldier, and a 19th century soldier. Ditto for something like Communicate or Resupply.

Are these developers going to have access to your codebase? If not, are they going to have some scripting? You pretty much have to give access to some sort of programming language in order to be able to create your own behaviors (even in order to modify units to make your 19th century simulation).

There are a number of ways to modify this behavior in C++ code. My favorite would be to have specific function objects that basically encapsulate a function (and so you don''t have to pass parameters each time, it will store the addresses of the additional data, such as that of the calling unit).

As for storing different types of training -- a vector of ints. Each unit would store ints that represent the types of training it has received. (and perhaps the extent of that training, in order to represent warrior-monks who train their whole lives, as well as "elite" units. It could also be used to represent combat experience)

I can''t speak to your specific example because I don''t know what the difference is between those kinds of cavalry. (the only two words I recognize are lancers and chevaliers, but I don''t know what they mean in a 19th century context)

Panzooka-
I''m trying to move away from fixed entities as much as I can. So I want users to be able to decide for themselves how many men make up a Team if they want to. In the single player game, there will be pre-built militaries with their own Tables of Organization and Equipment (TO&E), but for multiplayer, players are free to design to their hearts content.

I''m not doing this just because I have some sort of tweak fetish In strategy, how armies are composed (what units make them up) and how they are commanded (how they are organized) are extremely important. Most startegy games just let you build the building blocks (one unit) one at a time, then you assemble your army without really anyform of management and logical hierarchy. I''m doing away with that and being more like a wargame that does stress military hierarchical organization.

So, maybe you want small sized NATO style platoons versus huge sized Chinese or former Soviet platoons. What my system does is also allow you to go back in history and create other military organizations.

I think the toughest part is going to figure out how to do the training aspect of infantry design, and figure out what kinds of skills each infantry Trooper and Team has.


They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety. - Benjamin Franklin

quote:I think the toughest part is going to figure out how to do the training aspect of infantry design, and figure out what kinds of skills each infantry Trooper and Team has.

Yeah, that''s gonna suck.

You need a solution for each learnable behavior.

Formations are probably a good example. Learning to keep better track of where your buddies are in battle, you fall less and less out of formation. They''re not so important in a futuristic situation on the smallest level, but they''re very important for larger organizations. If your platoon''s orders are "Reach X at all costs", each of the squads (I don''t know what the levels of organization are in armies. Just pretend I know what I''m talking about) must continually try to maintain formation as they advance. Squads must prioritize maintaining formation over finding better cover. Staying in formation in combat involves not only maintaining your relative position with the rest of the squad, but predicting your future ability to do so. If the rest of your squad goes through a canyon, and your relative position would place you on the cliff to either side, you have to go through the canyon even though it places you in the wrong position because otherwise you might be cut off from the rest of your platoon (you won''t necessarily be able to provide cover fire from the cliff because the canyon could split, so unless you know that you won''t be cut off or if you anticipate an ambush, you have to follow your platoon down into the canyon).

Well, outside of combat (combat always throws wrenches into things), the only consideration that would keep you from maintaining perfect position is terrain. An amateur would maintain perfect position to the inch if the desired position is known. A slightly more experienced commander would take into account the future, as per the previous example. An experienced commander would consider the nature of his orders. If his commander''s orders are to minimize the chance of being seen, he''ll avoid hills and go through valleys. If his orders are to engage the enemy as a decoy, he''ll go over hills to increase the chances of seeing and being seen. An excellent commander would take into account the value of his position to the rest of his platoon and seek to maximize that value. If his position is to prevent his platoon from being flanked, he''ll choose terrain that will allow him to have greatest visibility to the side, possibly breaking formation slightly by assigning an ideal position somewhat farther than normal.

All of this can be implemented by taking these things into account in the pathfinding algorithm.

Laying down coverfire is another example. It''s somewhat of a boolean -- either you know to do that or you don''t. However, learning to conserve ammunition rather than using sustained bursts, splurging with the ammo when your enemies are courageous or numerous or when you need to advance quickly, and reserving it when your enemies are few or cowardly, or when you''ve got excellent cover and you are holding position is definately continuous. This can be taken into account by varying the rate of fire chosen. (you have mechanisms for controlling direct vs. indirect fire, the velocity of the round, and so on. Why not one more?) Limitations of the weapon or psychological factors might make you control the rate of bursts in addition to or instead of controlling the actual rate of fire.

My AI system is in a really nebulous stage right now, and I hope that the next series of the Squad Level AI article comes out soon.

I''m thinking that at the Team (and Trooper) level, AI is going to be something of a State Machine, with the set of rules and conditions declared by a Plan of Action. The skillsets, personality and training of the Team will of course influence how it acts. And of course, the training and skills will deeply affect it''s innate "domain knowledge" about how to best utilize its own skills.

In your formation example, the AI of either the Team (or more likely the AI Commander in charge of the Team) has to understand how the terrain affects his Team''s ability to do things.

Right now, I''m concentrating on the MOS (military occupational specialities) that a Trooper will have, along with basic infantry types...though I''m somewhat loathe to do that, since that enforces my game designs on the player (what if a player wants infantry skilled in Zero-G operations, or Spaceborne troops....my game actually has these, but suppose I didn''t, then the player would not be able to create those kinds of troops).

Hopefully by Tuesday when I get back into town, I''ll have worked a little on this and put some of my skeletal ideas up.


They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety. - Benjamin Franklin

quote:In your formation example, the AI of either the Team (or more likely the AI Commander in charge of the Team) has to understand how the terrain affects his Team''s ability to do things.

What I was thinking of is implementing some method of modifying the target coordinate based on each of the considerations and having learning weight the considerations differently (I''m trying to think of some method whereby it''s just some coefficient in some formula. I can''t quite get that far.) I wasn''t very clear about that. Sorry.

quote:Right now, I''m concentrating on the MOS (military occupational specialities) that a Trooper will have, along with basic infantry types...though I''m somewhat loathe to do that, since that enforces my game designs on the player (what if a player wants infantry skilled in Zero-G operations, or Spaceborne troops....my game actually has these, but suppose I didn''t, then the player would not be able to create those kinds of troops).

Well, zero-g and spaceborne operations are somewhat pointless without zero-g operations. Implementing that sort of environment is probably a lot more difficult (and a much more fundamental game design decision) than implementing tactics in that environment. I don''t know if your spaceborne squads are for operations in space or dropped planetside from space. If dropped from space, one needs to implement a space-plane from which one can drop before one can implement the tactics of dropping from one. In order to create such a unit (or a unit with such a difference from your existing selection of units), one probably must have access to your code.

How do spaceborne tactics differ from airborne tactics? How are spaceplanes different from really fast airplanes for the purposes of this (I assume) ground-based RTS?