They way I think I''ll do it is simmilar to the windows message queue. Every time something happens that would effect a unit, like damage, you send that unit a message to respond to however it thinks it should. The problem with this is that every unit will have to do the processing for adjusting damage because of armor type, damage type, etc. You could solve that by making a conversion object that takes an amount of damage, damage type, amount of armor, and armor type to make only one thing that has to know about the different types.

I'm too lazy to put up the source code right now Also, since I'm still not sure if I should use vectors in my Cluster class to hold the unit objects, or create a Template that can hold the unit types. I'm still a bit fuzzy about Templates although Template functions make sense, but from what I understand about Templates, they seem to go against OOP practices....probably because I'm not understanding them correctly. Unfortunately, since I'm self-taught, other than forums like these if I don't understand a concept I don't have anyone to turn to for help.

Tazzel-
Why would it be bad for another object (for example your DamageClass object) to manipulate the data of another object? I'm still fuzzy about a lot of OOP details, but I thought the concept of OOP was to make sure you delineate your public and private interfaces. If you make a public method of a Unit class called DetermineDamage you could do something like?

class MyUnit{public:  DamageClass create_DamageClass(int uDamageValue)  void Attack(Unit* Targeted_Unit);  void DetermineDamage(Unit*, DamageClass);  void setHealth(int uHealth) {Health = uHealth; return Health;};  int getArmorClass() {return ArmorClass;};private:  int Health;           int ArmorClass;  int uDamageValue;}DamageClass MyUnit::create_DamageClass(int uDamageValue){return DamageClass(int uDamageValue) //call the DamageClass constructor} void MyUnit::Attack(Unit* Targeted_Unit){this->create_DamageClass;Targeted_Unit->DetermineDamage;return}void MyUnit::DetermineDamage(DamageClass WeaponDC){if( (WeaponDC.getDamageValue) > (this->getArmorClass)  this->setHealth((WeaponDC.getDamageValue)- (this->getArmorClass))return;}//the DamageClass object can be generated by an Attack() of the firing unitclass DamageClass      {public:  DamageClass(int);  //constructor that takes int to set DamageValue  ~DamageClass;  int getDamageValue() {return DamageValue;};private:  int DamageValue;}DamageClass::DamageClass(int uDamageValue){int DamageValue = uDamageValue;}c/* I hope I did that right.  Also, I didn't do anything facny with the DamageClass object, like determine a setDamageValue function which looks at the Offensive capabilities of a unit, and sets the DamageValue accordingly*/    

ohhh, if there's any errors, please point them out, since as I keep beating the point to death, I'm new at programming

Hopefully though what I wrote made sense (I made this up on the fly, and I know I didn't include a lot of necessary details, but then it would have made the code that much longer). When the firing unit calls its Attack() function, it returns a DamageClass object. The Attack() function in turn also calls the Targeted Unit's DetermineDamage(), and the DetermineDamage function takes the DamageClass object as an argument. Then it calculates what it needs to know, and sets the Health attribute of the Targeted vehicle accordingly.

I tried doing it at first where the DetermineDamage function was a private class, and the DamageClass object was a friend and held a function pointer to it, but that got messy really quickly, though I'm sure it's possible. Really though, I think it'd be easier to do this without having an intermediary Object which gets passed from the Attacking unit to the Defending Unit. I think all you have to do is have a function pointer in the Attacking unit that calls the DetermineDamage function in the Defending unit. I'm not sure if there's an advantage in having an intermediary object? The advantage of having function pointers is that you have to ask for the address of the function in the defending unit first...if this fails (for example, the firing unit missed completely) then it can not call the DetermineDamage function in the defending unit at all. If I cn, I'll try to post the function pointer version to see if it's any clearer.

I was thinking of the function pointer route myself, but if someone can point out advantages of having a middle object encapsulate the damage effects of a weapon, I'll think about that too.

[edited by - dauntless on February 2, 2003 11:23:29 PM]

Arrgghhh, the code tag isn't working for me...wonder if it's Opera7 stripping out the tags? Be back in a flash....

[edited by - dauntless on February 2, 2003 11:25:02 PM]

Nope, still didn't work. Tried it with IE and still did the same thing. Maybe the Moderators took out the

{/code] tag?[edited by - dauntless on February 2, 2003 11:29:43 PM]    

hmm, I just realized the following code should be:

void MyUnit::DetermineDamage(DamageClass); //it shouldn't need a pointer to a unit class

and

void MyUnit::Attack(Unit* Targeted_Unit)
{
Targeted_Unit->DetermineDamage(this->create_DamageClass)
return;
}

since DetermineDamage requires as an argument a DamageClass object.

I think I may have messed up the the this pointer too, but not positive (I can never remember that if you use the this pointer, if it must also include in the parameter list, a pointer to the object itself, or since this is implicit, I don't need to put it in the parameter list)



[edited by - dauntless on February 3, 2003 4:06:01 AM]

How about if you tell a cluster to do something stupid, they send a message back like ''Um, sir, we can try, but I don''t think our pistols will work very well against those main battle tanks''

anonymous-
Yeah, I need to give some kind of feedback to the player to let him know that what he attempted to do wasn''t possible. I remember in Close Combat when you tried to tell a unit that was pinned down to advance or to attack a tank they''d yell, "are you crazy!!"

It''d really be cool if the Commander object could give advice to the player on what to do, but that kind of AI would be pretty hard to do I would imagine.

The more I think about it, I think that Tazzel''s comment on the AI needing to know how the unit works is very important. It''s more than just having an order passed to a Commander and the Commander passing the order on to the appropriate unit (if possible). The AI in the Commander objects have to be able to understand the very capabilities of the units and its functionalities. Since the game allows for custom designed units and even to some degree the functionality of the units themselves, you can''t hard code required data for the AI to work on (since the units and weapons and defenses, etc. aren''t pre-defined).

Personally, in my game, I''m going to have several sets of pregenerated armies as well as basic weapons and hull types that players can play around with (by plugging the various weapons, engines, defenses, electronics etc.) into the Unit objects. At least since the modules have been predefined, the AI doesn''t have to worry about calculating how to use them (you could hard code certain pre-defined action rules based on hardware capabilities).

For example, if the Commander knows that a M201 Tank has a standard issue 120mm binary propellant hyper velocity kinetic penetrator, then he knows that the Max range is 3kilometers, and that the DamageClass is an 8, and that it can penetrate 800mm of Laminate armor out to 1000km with standard APFSDS ammo. But what if the player designs his own gun? Then I''d have to create a system where the Commander knows not just how to use the weapon (simply call the Attack function), but he also has to know its capabilities. Aferall, a Commander knows that his Infantry rifle squads can''t attack tanks because rifle rounds can''t penetrate tank armor.

If you REALLY want to get fancy with the AI, the AI would have to develop an understanding of what units are good for crossing what terrain, of what weapons are good for attacking what kinds of targets, of understanding how to integrate different units together to maximize their potentials (for example extending infantry scouts ahead of slowly moving armored patrols), etc. This requires a more abstract level of "thought" which would be nice to capture, but I''m not sure how diffucult it would be since I know very little about AI programming techniques.

You''ll have to excuse my laziness but I don''t have the time to sit down and read 4 pages of posts right now but have any of you looked into Impossible Creatures? A know the genre is a little off but it may give you a few ideas. You basically pick two or so creatures and merge them to create unique units. You''ll then form armies out of these monsters and use them to fight RTS style. I don''t know much else though.

Impossible Creatures looks interesting...especially the script interface that lets you determine what two animals you want, and in what locations of the body. However, I think by only being able to chose from 2 animal types its somewhat limiting.

From what I''ve read of the reviews, there are "tech levels" that introduce new animals and therefore new capabilities. I presume this is how the designers answered the balancing question. Also, by limiting the choices to (I think it was) 50 animal types, and by hard coding the functional capabilities of each animal, I think the permutations of unit types is less then you''d think there was...and indeed, one review said that even though 40,000 combinations are possible, the overlap of functionality was so common, that there were really only about 40 or so truly unique unit types.

I''m also very impressed with how they visually represented the combinations....I''m not sure how they did it, but very interesting indeed. This is one area that I have absolutely no idea how to implement in my game.

I also am not possitive on how I will represent all of the customly created unit types. Though I believe I''m going to use the same FSm that I create to classify the types of units to classify what model to use... It would be very hard to make custom models for each custom unit...

Tazzel3d ~ Dweil

Sorry, I''m new at programming (just opened a book on C++, I like Web Design and art better), but to display the different types, you could have it separated into head, body, and lower region (or more more more types) and had an animals appearance just suit a trait (lots of strength=lion). To create units the player could gain "points" or something, that could thus be sued to create monsters and add points to strength, speed, sight, and armor. After creating it, the player could build it. And to balance it out a little, the more points it takes, the longer build time occurs and the more resources it takes. This might be impossible, but its just an idea.

Also, certain hidden combinations could be made (just for fun) suck as a lions head with a goats body and snakes lower region could create a chimera, which might have a little extra power (and take a while to build). Don''t kill me if any of this doesn''t work. It would also take a lot of time.

___________________________________________________

So...how does this "reproductive system" of yours work? -Anonymous

Tazzel3d-
By FSM are you going to create a switch statement that checks the ID type of the unit, and then selecting what model it will use to represent it?

I think you might be better off using polymorphism to do this. By creating a base class with a virtual method...say, virtual ID_type chooseUnit(Model);

Then in all of your derived classes, you can override the chooseUnit function and have the function of the derived unit call the function to select what model it uses. The reason I think this is better is because if you introduce new Unit types, you will have to recompile the FSM (the switch logic loop) for each new addition. If instead you use polymorphism, you can introduce new Unit types by putting the class definition inside a shared library...that way no new recompiling is needed.

I suppose you could create a linked list (or some other dynamic container) that held pointers to each Unit type. The switch statement then uses the array (actually node) element as its argument and you can call the model type that way too. Since its a dynamic container, you can just add a new node with a pointer to the new class type that is defined in a shared library.