I''d like to point out a few more strategy games where it is possible to design your own units. First I''d recommend you to take a look at the space empire building games Space Empires 3 and 4. There you can design almost an infinite number of spaceship designs, based on the many hundreds of components availble to research in the game. I actually enjoyed SE3 very much although it had outdated graphics even when it was published. Their website is:

www.malfador.com

Also the old 3D strategy game Warzone 2100 features the unit design you are talking about. You can select different hulls, different means of transport (wheels, halftracks, etc.), and a large number of different weapons. Although this game quickly got boring (the 3D world was a largely uninteresting "post nuclear war" one), it can be worth to check out. I think the main website for Warzone is:

http://www.strategyplanet.com/warzone2100/

yeah, to continue on my last post and some others that I read:

instead of having an FSM deside which model is best for the unit, you could have an FSM that would deside which gun to use, which body to use, ect. You would want to be sure that you include a lot of possible combinations other wise it would probobly be easier to just create models for every combination than to figure out how to create the models on the fly.

I think that I definately will implement the idea where the user might only be able to see very prominent features when the unit is viewed from a long distance. I think that I might also have a few different modes such as radar and heat. This way, at night, the user can sneak around with otu being ''seen'' as long as they don''t generate much heat or radar cross sections(through stealthy materials and or shape)

I really like this idea. what do you guys think?

Tazzel3d ~ Dwiel

I don''t think I''ll do it for my game, but I think its a good way to have automatically generated models. It would make LOD easy to implement as well because you could just not draw the extra models when they are far away.

For the heat and radar images, I would just use a form of cell shading where the image is red on the outside and blue on the inside, or all green for the radar image. NeHe has a tutorial on cell shading using a grayscale texture, and it shouldn''t be hard to change the colors to make it look nightvision, radar, infrared, etc.

nother couple design issues... for balance... so that one player can''t create a unit with the biggest gun and the most armour go to a somewhat modular system.

first you specify the chassis, the more you spen on your chassis the more weight it can carry and the more strength you have, of course, this comes at the cost of weight and hence speed. by making each "component" have advantages and disadvantages to it you can bring in balance. this doesn''t require a component based system. it could be as simple as the bigger the gun you put on it the less weight you have left to install engines suspension and armour. I THINK this would help maintain balance.

other thing I thought of is supply lines. you can''t have a tank working all alone deep in enemy territory. you need to be able to supply it, specifically fuel and ordanance. I don''t know how I''d do this but some how bring in supply lines. you might want these managed in the background by the computer, have it just make sure that there are no enemy units that can interdict a friendly unit. then your units get cut off and they start losing effectivness, if you can manage to break thru to them and re establish a line of supply then you can recover them, other wise eventually they''ll be over run. it might make sense to do something similar with lines of communication. I''ll think on that a bit more before I post it tho.

Yeah, The main disadvantages that I am incorperating to keep the units balance include:

the mass wil be determined by based on the specs of the unit.
mass will effect acceleration/max speed/power consumption/ and terrain coverage
Also, more powerfull weapons and things that generate heat such a large power supply to power the monsters, large weapons, large engines, large lasers. ect. There will be a mode in the game which displays the map as heat which would be color coded. This way at night, if your units generate a small amount of heat and or can disipate and or keep it trapped in well enough, it will not be as noticable on the map if at all. Large engines produce a large amount of heat which would be very easy to see on this type of map. Hence they have absolutely no way to be stealthy. In dayligh, they are amssive and so easy to spot, they are very slow, they, at night, they have a large radar cross-section and heat field.

These are the disadvantages that larger units would have in real life and so they are the ones I have chosen to implement in my game.

Thought/comments/ideas are welcome

Tazzel3d ~ Dwiel

I like the heat thing... it one of the things that most games don''t take into account, like I said earlier, I''ve been thinking communications alot lately, and how to model them in an RTS. I don''t think it should be as easy to restablish communication with a unit as it would be top supply them. while a unit is out of communication it would behave erratically, not sure exactly how, but not really trusting anything it hears. would introduce the possibility for units that would jam comms to an area and/or order enemy units to do things YOU want them to do... would bviously have to be an expensive ability. other thing thats becoming more and more of an issue in todays battlefield is secure comms. you might be able to model a "comm map" sort of the intensity of enemy com traffic at a location. based on this you could then possibly find otherwise stealthy units. if you have a recon unit that has little or no heat signature and no radar signatur, but is always talking with its comand structure you could then see it because of the com traffic. of course... on the front lines their com traffic would be over whelmed by other com traffic, and if you want to get real involved, model signal propagation based on terrain. rasies interesting strategies for hiding your "chatty" units too. set up a high powered transmitter and blanket the area with random garbage messages overwheling the signal from your own. it would be an influence mapping problem. something I think I''m gonna think about some more.

wow, I really like your communication ideas. I might just have to implement something similar in my game On ething that might be fun would be to be able to say jam the enimies signals to their units, and at the same time, send them your own signals to leave the area. You''d have to be subtle about it though otherwise they might relize that they arn''t talking to their own. I also thought that an interesting twist where if you catch an enimy recon unit, you get all of the information that it has collected so far. Also maybe, becuase every unit in my game is a robot, there could be a way to ''convert'' enimy units by damaging the movement/weapon ablities and taking it to base and repair it for yourself. Or maybe be able to reuse parts from yours or enimy''s units that weren''t completely destroyed. Just some possible twists Again, I do like the communication ideas. One thing the user could do would be to send out a million little droids, each broadcasting a lot of ''white noise'' so that the comm density maps are over whelmed and the unit that the enimy really wants to destroy is hard to find because there are so many just like it. Ofcourse this kind of saftey precaution would only be needed in missions where the recon units COULD not be found or you would be in trouble.... wow... lots of twists with the comm idea. Very good!

I''ll think about it more and reply again when I get to school...

Tazze3ld ~ Dwiel

Dauntless: possible solution to the unit representation problem for your game is to use a "realistic" display for the real time portions, which doesn''t immediately convey all relevant information, but gives a general idea; in the turn based portions, use (user-defined) icons (possibly overlaid on the map) to represent various units - the icons would be chosen for the ability to readily distinguish between them, and detailed information would be available either in a pop-up window or on the status bar (whichever fits the game better) in a similar format to that used for friendly troops but with unknowns indicated somehow (wildcard unit icon?).

On the original question (only having read the last page or so of responses so far... might get round to the rest later): in real life, it can be quite tricky to distinguish between two tanks (eg) with only minor differences in actual capability. My initial feeling is to have the chassis determine the general outline, probably model external features (external guns, ports, etc) but not explicitly model to distinguish internal features (engine power, ammunition storage, crew complement, fuel tank, inertial guidance system), then assign a paint job to each distinct model - probably let the player design their own instead of forcing the default - and allow dummy features to be built in - that way, the player can, eg, fit all their tanks with (cheap) satellite dishes while only the command tank actually has the (expensive) GPS and comms equipment or put a 9-inch barrel with a laser cannon mounted inside, etc, so the player can decieve opponents about his units capabilities - keeping track of his own units becomes his problem - though selecting friendly units should always offer full information.

Pretty much off track for the discussion so far, but I have a design document lying around which (in addition to a more standard "human" race) calls for two races with unusual unit design (names subject to change):

"Hivers" are built around swarms - each swarm has a mix of various individual insects and unit design comes in two flavours - breeding new types of bug, and mixing existing bug types to create new swarm types. There are also heavy units which can form the nucleus of a swarm or can move independently (like the anti-aircraft bugs in Starship Troopers)

"Robots" are modular units - each sub-unit has (potentially) the most basic weapon and movement, but by linking with other sub-units, aggregate units can be formed - eg a sub-unit with high mobility and a sub-unit with heavy firepower could link up to create a relatively mobile heavy weapon platform.

I have more detailed designs, but I think you get the general idea.

Hello, I was working on my game rules, so that I could implement an AI, and I was stumped when I was forced to come up with an equation that would come up with the mass and other derived attributes of units based on the other indirect attributes the user decides upon. How hvae you or do you plan on generating this equation and others like it? Do oyu just start with something basic and modify it until you have a good equation or what? I believe that testing it myself right now is out of the question because that would mean I would need to do a lot of other graphic things. My plan was to create a ganeplay dll which would hold all of the gameplay data and would do all of the simulating. Another dll which would be a player would send the gameplay dll commands which are executed by the different units/buildings ect. The player dll would also have a derived class residing in a different dll which would send commands to the gameplay dll based on the descions of the AI instead of the input by the user. I would then have a rendering dll which would get data from the gameplay dll and render the simulation.

I can''t deside how the render dll and the gameplay dll should communicate. SHould the gameplay dll send the render dll all of the data to render? It seems that this would have the gameplay dll implementing algos to only send the necessary data, yet it is a gameplay dll and I don''t want it doing this kind of thing. The render dll should handel all of the algos that deal with the rendering of the simulation. MY best idea so far, in my opinion, is to have the gameplay dll keeptrack of all of the units/buildings ect (which it should be doing already). The render dll should have a pointer to the part of this structure which holds all of the rendering information. THis way it can acess all of the units/guildings and keep the gameplay dll form doing the work that the rendering dll should be doing?

What do you guys think about these things?

Tazzel3d ~ Dwiel