RTS Design doc programming questions

The best bet would be to have him explain in detail what he means. If you don't understand what he's saying, that's a failure in communication on his part, not on your part. It's professional to ask for clarification. It's not professional to pretend you know what he's talking about and the run around trying to get other people to interpret for you.

That said the data structure most likely means the set of data for each unit:

hitpoints
damage
resistance
movement speed
etc

but ask him for clarification. Otherwise you're just playing a bad game of telephone.

-me

thanks,

that is good advice. I thought that maybe it was something I should know regardless. Now I see it's a question of the programmer assuming too much on the part of the designer. I get the same happening at work with web design, lapsing into tech lingo that we forget to put in laymen's terms.

An unit is defined by TWO sets of data:
* constant data
* instance data

Constant data are properties that applies to an entire category of units (let's say rifleman). Here goes maximum hit points, rate of fire, damage, height over ground.

Instance (per unit instance) data are properties that are modified during the game and they are kept PER INDIVIDUAL UNIT. These are damage taken (substract damage taken from max hp and you get current hp; when taking damage you do DT = DT + damage received on hitl; when healing you do DT = DT - healing received; damage taken is NEVER negative), buffs for rate of fire or damage. I would call those modifiers. They all interact in a way with constant data to produce instant unit data. Position and orientation are instance data.

Instance data should be saved and loaded. Constant data are taken from game pack or from map (let's say you play a custom map with modified values, others than standard).

The same goes for triggers or whatever systems you have for your game.

A piece of advice for some people around:
This is part of the design too, a more technical task then establishing races, stories and units. Most people get bored at it. Get used with it or programmers will design your game and you'll have a heart attack at first running version :).

GL.

You might want to familiarize yourself with the term base object. Like a vehicle is a base object and car and truck derive from it. Derive meaning taking the properties of the base class and expanding them for a specific object. This can help a programmer a lot.

For instance in an RTS, you have a building base object. Then you have main base, barracks, tower, and everything derived from it.

So the base object building would have hitpoints and so on, while a tower might have firing range, damage, projectile type, AOE damage and stuff.

As for unit, you'd have a base object called unit or something, then derive rifleman and such from it. Also to help with the basic idea of the DD you can list the kinds of units that can be built from the certain buildings and the resources it takes and how long of a time it takes (like short, medium, long, very long time nothing specific).

You get the idea.

I do not agree with Sirisian because:
* the engine should not know the differences between rifleman, tower and HQ base.
* the engine should allow for adding parameters in unit definition (best with an XML file) - each parameter should add a certain functionality in engine. If you have 30 gameplay parameters you can't have 30! (factorial) (1x2x...x29x30) classes to take care. You have behaviors implemented for each parameter or set of parameters. Behaviors can be: movement, aim, produce, hangar.
* Sirisian example is good for programmers learning class inheritance but that will really hurt designers freedom. In real life practice, more efficient paths are required.