coderx75-
I''m already in way over my head I learn best when I just jump in and start mucking with things. Look before you leap isn''t one of my stronger suits when it comes to learning things. Actually, it''s why I chose my nick. You''re right, this is exceedingly diffucult, and it''ll probably take me years to master, but as they say....the journey of a thousand miles begins with the first step. Honestly, I''m learning more about object oriented design methodologies by trial and error (and the extremely helpful people here on this forum) in the last month than I have in the last 4-6 months of just trudging through my text books and coding their examples.

As for your suggestions, on question #3, I was sort of thinking of your idea of containing all the units into one container class, but I had two problems. One was that I wasn''t quite sure how to group together units that belonged to the same Organizational Unit (actually I borrowed this term from M$ terminology for creating active directory objects...you have forests, trees, organizational units, etc in which to group units based on a common theme). I didn''t really think of the Unit ID thing though. But I like your idea of linked lists better....like you say, it should cut down on search time. The only trouble there is....can you make linked lists grow? I know arrays are of fixed size, and I couldn''t remember if you could insert nodes into linked lists...the reason that would be necessary is in case you decide to reinforce an Organized Unit, and of course by adding units during the game.

As for question #2, why would a scripting engine be diffucult? That''s one of the reasons I was browsing through Python because I was thinking of making a script engine that would allow players to tweak their units. I was thinking of creating a Python script that I could hook into a DLL (well, actually, I''m going to design this for Linux first...so a shared library). Actually, this unit creation part is not seriously high on my priority list, as I can see my game existing without it, but it would be very nice to have, and does play a part in how I envision the game to make the player think about "the right tool for the right job" mentality necessary in warfare.

As for part 1, well, like I said, I''m already digging my own grave here But at least it''s fun (in a frustrating sort of way) trying to learn while I''m doing it. I''m starting to see where I''m biting off more than I can chew....so I''ll pare it back some, just so I can at least see a prototype of how I''d like my game to be. In fact, I''m already concocting a tiled hex-based, turn based game that will implement some of my ideas. What I find absolutely critical and essential to my game are the following though:

1) No god like control of your units...you have to access them just like a real commander
2) Morale
3) Logistics
4) an order system that goes beyond, "Move, attack, retreat, form"
5) a template based organizational structure....no "pizza style" ordering of units
6) Control of all units is done via officers rather than through direct manipulation by the player

And that''s pretty much it. I don''t really care much about graphics at this point...a tank could be an X on a black console for all I care. I mean 3d worlds with free form cameras and full tracking would be nice, but not my concern now. AI is important to me, but I know that that subject is WAAY beyond me at this point (other than some really simplistic finite state machine type algorithms).

silvermyst-
ever play car wars or battletech (the board game)? I think it was just as much fun designing your vehicles as it was playing the game!! That''s a part of what inspired me to create modifiable units, but the other part was that I wanted the player to have complete control over the creation of his country (I call them factions). Actually more important to me is the concept of how you organize your units. Is it better to have 4 platoons of 30 men each, or 3 platoons of 40 men each? Is it better to create a tank company composed of 3 platoons of medium tanks and 1 platoon of heavy tanks, or 4 platoons comprised of 3 medium tanks and 1 heavy tank per platoon? Even more importantly....you don''t "buy" 3 medium tanks and a heavy tank...they come as "bulk purchases". The base units are there as building blocks, but you have to buy the complete set, not its individual parts (the only time individual sets are created are as replacements for casualties).

Doolwind-
Thanks for the compliment I started playing wargames when I was about 8 years old when my dad would play Panzer Leader with me. I eventually moved on to miniature games like Johnny Reb and Fire and Steel (American Civil War and Napoleonic era miniature games respectively). During my teen years, I got side tracked into roleplaying games, and of course now I play computer games. But I still fondly remember strategy games and I miss a lot of the elements that exist in those board and miniature games that are missing in today''s computer games. I''m sort of an odd gamer in that I can hang around old-school grognards and the D&D crowd at the same time (they usually hate each other''s guts....you won''t find them anywhere near each other at game conventions), so I think I borrowed a heavy dose of game philosophy from both sides.

I like the realism and attention to detail of the wargamers, and I like the creativity and spontaniety of the role players. That''s why my initial game background will be in a near future setting (what role players would like), but with the attention to detail and more realitic form that wargamers prefer. Whether I''ll wind up just disappointing everyone is anybody''s guess, hehe.

As for your code suggestion, I''ll study it tomorrow morning, right now I''m too sleepy for it to sink in (and yup, that''s the level of coding skills I have right now...give me about 30-60minutes, and I''ll figure out what you''re trying to do ) I''ll give you my take on it tomorrow morning. Thanks for the help btw!

Doolwind-
I think I see what you are saying. A pure virtual class is basically something that you never instantiate since it is an abstracted idea (I guess Plato would have called it a "form"). However, from this virtual base class, you make more concrete types of classes....instead of class vehicularUnit, you create class Tank. Can I make another abstracted class from this though? Say for example I create a pure virtual class called:

class vehicularUnit
now let''s say I want to derive two other abstracted classes:

class armoredUnit : vehicularUnit
and
class flyingUnit : vehicularUnit

You still don''t create specific objects of armoredUnit, or flyingUnit, but you in turn use these as "forms" to build your actual concrete types of objects. Is this legal?

But I can see the power of doing this now, although I''m still fuzzy on vectors. I''m actually reading up on them right now.

Hey,

Yeah you can have as many abstract classes as you like. Now you can see how powerful all of this is . I must sleep now, but ask away with vectors, I have been playing around with them a lot over the past few weeks....trying to get A* working was rather interesting . I would definately suggest you have a great understanding of them before you start anything like the A* algorithm (if you plan to use it)

Doolwind

quote: Original post by Flarelocke
Personally, I''d use a tree. In other words, you''re the commander-in-chief, so you have pointers to all the top groups(battalions?) underneath you(not necessary for them to know who their peers are because they can just link to you. Perhaps they have a pointer to the commander-in-chief, perhaps not).

Would you have officer classes that would hold pointers to the container classes and base units? Or the other way around? It would seem that since the officer has to pass order tokens to the units (the token will be a class that represents the embedded order..i.e. function calls...it has to be a "physical" token and not merely a system call, because I want the game to be able to interrupt the actual token itself), the officer class would need pointers to the units and unit-holders.

quote: Original post by Flarelocke
The limitation of this is that you''d be unable to have, say, two squads of four men each and two artillery units in a platoon, usable as needed. You''d have to have four men and an artillery in a squad, and two squads per platoon. To avoid that, I''d probably derive both unit and unit-holder from some token(as in, trivial) class, and hold pointers to that (token) class.

I don''t think I understand this. Why would there be a limitation on what base units you can put in the container classes? I sort of see the container class and it''s derived classes as like template (not a c++ template). Let''s say you have container A, B and C:

Container A comprised of //assigned an officer class A
4 slots.

Container B comprised of //assigned an officer class B
3 Container A''s
4 slots

Container C comprised of //assigned an officer class C
3 Container B''s
4 slots
and so on and so forth

Slots are for the individual base class units. Container A is essentially a class composed of 4 base unit classes. Notice that I picked these numbers out of the air. If possible, I''d like to have the player chose how many slots, and how many container classes make up each container class.

quote: Original post by Flarelocke
If, when a unit dies, it hands off(calls some function and another class stores the address of a pointer which the object previously controlled) its equipment to its platoon, the container class will need to be able to store equipment as well. If, when a unit dies, it simply drops its equipment, some sort of world class will need to acquire a pointer to the equipment.

See the wonders of polymorphism?

Ahh, I think I get it now. If an object dies, but that data is stored on the freestore, and if I have a world class that also points to that data....even though the object dies and the pointer to that data "dies", the world class still has the pointer to that memory. I suppose that the delete call would have to come from the world class then and not the base unit class.

quote: Original post by Dauntless
Look before you leap isn''t one of my stronger suits when it comes to learning things.

I pretty much learned the same way. However, back in the day, I didn''t have access to such a great forum as this one. YOU LUCKY BASTARD! =) HAHAHAHA

quote: As for your suggestions, on question #3, I was sort of thinking of your idea of containing all the units into one container class, but I had two problems...

I think we''re thinking along two different lines. You seem to be creating a turn-based game, and I''m thinking about moving in real time. I''ve derived EVERYTHING off of the parent class so that collisions can be detected on all game objects with the same bit of code.

quote: As for question #2, why would a scripting engine be diffucult?

You are obviously less of a beginner than I thought. =) A scriping engine could be cool but I think it would be overkill for your project. Might be a nifty feature to add later on tho.

quote: As for part 1, well, like I said, I''m already digging my own grave here... ...What I find absolutely critical and essential to my game are the following though:

1) No god like control of your units...you have to access them just like a real commander
2) Morale
3) Logistics
4) an order system that goes beyond, "Move, attack, retreat, form"
5) a template based organizational structure....no "pizza style" ordering of units
6) Control of all units is done via officers rather than through direct manipulation by the player

This sounds so interesting! Can I beta test?!?! =) I played Mechwarrior 2 (one of my favorite games). I spent so many hours designing mechs. One mission required me to destroy a power generator and then escape the city. So I created a mech that ran about 500 km/h with no armor and only a small laser. I was in and out before the enemy could get to me =)

quote: And that''s pretty much it. I don''t really care much about graphics at this point...a tank could be an X on a black console for all I care.

Excellent! I''m taking the same approach. I''ve put a bunch of rinky-dink squares on my screen with DirectDraw. Different units are different colors and the square itself is the collision area. I''m only interested in the game system itself. Once I have actual content, I can worry about making it look pretty.

You might be biting off a little more than you can chew, but you seem to be doing a lot of things right. Perhaps, we can help you enough to actually get the game complete. Personally, I''d love to play the game that you are describing. =)

- Jay

There''s an old saying in Tennessee... well, it''s in Texas but probably in Tennessee too. It say''s, "Fool me once, shame on... shame on you... uh... ya fooled meh uh can''t get fooled again."
- George W. Bush

Get Tranced!

quote: Original post by coderx75
I''m only interested in the game system itself. Once I have actual content, I can worry about making it look pretty.

Whoa.. no wonder we''re in the designers forum.

quote: Original post by Fuzztrek
Whoa.. no wonder we''re in the designers forum.

Yes, I realize we are in the wrong forum. =b

- Jay

There''s an old saying in Tennessee... well, it''s in Texas but probably in Tennessee too. It say''s, "Fool me once, shame on... shame on you... uh... ya fooled meh uh can''t get fooled again."
- George W. Bush

Get Tranced!

quote: Original post by Dauntless
Would you have officer classes that would hold pointers to the container classes and base units? Or the other way around? It would seem that since the officer has to pass order tokens to the units (the token will be a class that represents the embedded order..i.e. function calls...it has to be a "physical" token and not merely a system call, because I want the game to be able to interrupt the actual token itself), the officer class would need pointers to the units and unit-holders.

Officer class would have a pointer to its underlings.

quote: I don''t think I understand this. Why would there be a limitation on what base units you can put in the container classes? I sort of see the container class and it''s derived classes as like template (not a c++ template). Let''s say you have container A, B and C:

Container A comprised of //assigned an officer class A
4 slots.

Container B comprised of //assigned an officer class B
3 Container A''s
4 slots

Container C comprised of //assigned an officer class C
3 Container B''s
4 slots
and so on and so forth

Slots are for the individual base class units. Container A is essentially a class composed of 4 base unit classes. Notice that I picked these numbers out of the air. If possible, I''d like to have the player chose how many slots, and how many container classes make up each container class.

I suppose you could do it like that. I was thinking that you''d only have one type of pointer in the class, so you''d have to have two classes at least. I suppose you could have a vector of container pointers and a vector of unit pointers, but this would make operating upon all of the elements of an organization a little more difficult. It would allow you, though, to simply have an empty container vector when the organization is comprised completely of units, and have an empty unit vector when your organizaiton is comprised completely of organizations. I just didn''t think of that.

quote: Ahh, I think I get it now. If an object dies, but that data is stored on the freestore, and if I have a world class that also points to that data....even though the object dies and the pointer to that data "dies", the world class still has the pointer to that memory. I suppose that the delete call would have to come from the world class then and not the base unit class.

Yes, just make sure you don''t delete the pointer in the destructor. Having to keep track of when you need to delete things is why smart pointers were invented because it gets rather complicated in a large project. If, for some reason, the platoon needs to destroy the equipment, delete the pointer and set it to zero, and then make sure not to add this pointer to zero to the vector where you keep all the dropped equipment.

Hey everyone,

I''d just like to thank everyone for all their help and comments, I really appreciate it. So to Oluseyi, Flarelocke, Coderx75, Doolwind, Sandman, RolandofGilead and anyone else, thanks for all the help. I''ve really gained alot of insight into some OO methodologies.

Well, I''m at work while I''m typing this...so it''s back to studying polymorphism and vectors while I''m at it. I''m already getting some ideas on how to implement some of my game logic.

ohh btw....coderx75, trust me, I''m a beginner. I''m at a point where I can sort of understand other people''s code if you give me enough time, but if I have to come up with it myself, that''s where I have trouble. Kind of like spoken languages when you can understand easier than you can speak it.