I''m working on filling out a design idea for a massive RTS game. Instead of having a small play area for a large number of missions like in most other RTS''s, mine would be the same place the whole time, only the place is absolutely gargantuan(spelling, anyone?), so there''s always somewhere new to explore. I know that I''ll have a problem with keeping track of game data. I think I''ll have the info stored on the hard drive. Then, the data surrounding where the player is watching would be in RAM. This will be hard enough- for example, how would you handle an animated computer controlled character whose data is only on the hard drive? Even harder would be things like guard towers and controlling the player''s units who are only on the hard drive, but have been given commands. You could have all the active units in RAM, but this has the possibility of causing a crash if you had many teams involved in fighting/building at once. Does anyone know how this could be implemented? I think I''ve seen an article about this type of thing somewhere, but I can''t remember exactly. Do you know of any good articles? Thanks!

Im not the best person to talk to when it comes to memory management, but why wouldnt you just keep all active units in RAM? Just how big of a world and how many units are you talking about here?

You are basically making Civilization into a RTS, right? I think that would be great, although besides memory management, you would have to deal with speed.

And I think you spelled gargantuan right.

I think that since you are still designing it, you would have to ignore the details of the engine for now.

In any case, you would need a way to limit the amount of info provided. For instance, in Starcraft, each unit could have its own HP, armor, etc. Upgrades could be the difference between one player''s unit from the same unit on another player''s team.

In Total Annihilation, each unit had its own HP and armor, but there was no such thing as upgrades. Every type of unit had its own armor. One less thing to keep track of for upwards of 200 units at a time.

You might design your game around even more limited data to allow all of it in RAM. For instance, all units are the same so it is a matter of other factors, like your leader''s charisma, that wins the battles.

You will have to balance between the huge-ness of the world compared to the individual screen size and the detail of the units as well as the number of units.

Thanks for all your suggestions! (BTW: Although I''ve never played Civilization, so I wouldn''t know if that''s what my idea''s like, it''s nice to know that someone else thinks I have a good idea!)

You could divide your map into 1/8ths or something and when the player nears a another section it''s loaded from the hard drive into RAM while sections that the player is moving away from would be taken out of RAM and onto the hard drive.

That''s actually what I was trying to say in my first post, but I''m not all that great with words. The problem with that is that there are going to be a lot of units off the screen that still need to be processed; for example, the player is attacking in two far away places at once. I was just thinking, and shdaga''s idea to keep them all in RAM may not be that bad. Even if there was, say, 20,000 units, and each had 32 bytes of info, there would still only be about 650kb of info. Wait a sec- is that math right? But that''s not counting images stored in system memory or anything like that. Could a pro game say a computer should have a min. of 128mb RAM- I know that''s what SimCity 4 has. I''m also still trying to decide how to keep the game up to speed.

What you can try to do is make a testbed or prototype.
Basically you make a small program and try to mimic your engine''s capability for the specific part you want to test.
In this case, you don''t care about the actual game graphics or anything. You just want a very high overview, maybe show some pixels light up if there is a battle, have certain spheres of influence drawn out by colors, etc.

Anyway, make up units that you can see using in your game. For instance, if you make a tank unit, define its armor, health, speed, etc for the unit.
Then in the game, make it randomly make more units of each type for each "player" that will be controlled by the CPU.
Determine if there is a significant lag in having the CPU control all of these units.
If your algorithm has all of the units linearly making decisions, that might be too slow. You might decide to divide the forces into thirds or fifths, so that only so many are making new decisions at any given time.
In fact, they don''t have to make new decisions every frame so you can even further subdivide the main groups so that only so many are making decisions per frame. That might get complicated.

So your main game engine will simply make calculations on the battles among other things, such as hit points inflicted, while the AI is broken down so that only so many units make decisions at the same time frame.

If you don''t know what I mean, did you ever see a game where the units are moving in a certain direction, then you give them a command, and they continue on that direction for maybe a second or two but then turn around? I imagine that what I described is the reason for that phenomena. You obviously don''t want to make that delay longer than it has to be...don''t want the player getting frustrated at units that don''t appear to be listening!

As you can imagine, this is a significant undertaking. You not only have to deal with the big decisions that a regular player does, like upgrade armor or move group to position, but also the little decisions, such as how the individual units get to that position (usually the A* algorithm, right?).
I can see a dedicated server for such a game. Having the client run as well as a server on the same machine might be difficult.
But it is doable if you limit the data to be computed. For instance, i know of a game called Liquid War where the individual units are just small germs or something. You move the mouse and they all try to move towards it. The opponent does the same. When they collide, the germs or whatever start to eat each other away.
It is open source as far as I know, but I don''t know offhand what data is kept about each unit.
I hope this helps. You basically have to think about how much detail you want. If you want something like Starcraft or Empire Earth, only on a larger scale, you might have a problem compared to a large scale Liquid War.

quote:
I was just thinking, and shdaga''s idea to keep them all in RAM may not be that bad. Even if there was, say, 20,000 units, and each had 32 bytes of info, there would still only be about 650kb of info. Wait a sec- is that math right? But that''s not counting images stored in system memory or anything like that.

I think you have stated the answer. Each units info should not be that big and you should be able to store it all in memory. the problems will come with a.) images and b.) AI

Solving the image problem is relatively easy, after all the only images you need in RAM are for the units actually on the screen. you can make all the calculations concerning movement, battle,health without any reference to the image

The AI problem is a bit more tricky but has already been thoroughly addressed by GBgames. I think one key point is that you don''t have to recalculate every frame. For instance a firing animation may take 5 frames. Meaning after the AI has decided that a unit should fire, it doesn''t have to give that unit any other instruction until after the 5 frames have passed, and that time could be spent dealing with other units

That sounds like a very interesting idea

to note that about upgrades in starcraft: that''s done very efficiently, as once you get the upgrade, all your active units are instantly equipped with it. It isn''t tracked ''per unit'', but ''per player''.


I think you should add some way of progress that keeps it interesting instead of ''just another enemy'' all the time. There should be in-game developments (it would be a complete waste to leave the current game for a mission screen then continue, as it goes against the concept).

Another thing is that you should make distances periodically smaller. If you played Deuteros, an old amiga/atari game, you would know what I mean. I''ll assume you haven''t and explain it.

In Deuteros you start on earth and train researchers/marines/builders. Then those are set to work and you get an animation while you pass the time. After the first few things are researched & built, the animation gets boring. However your researchers/builders will have improved to a next skill level (there are three for each type). This increases their working speed.

Then you build your first orbital factory. You have to fly all the resources you want there up and down manually. You get to see the inside of the cockpit. You are thrilled about building a factory. Then as the factory is finished, your researchers think it might be a good idea to install an automation module in your spaceships, to automatically ship resources.

Then when you are mining on many planets alien technology allows you to transport things from planets to each other near instantly (no fuel spent!). Whenever something starts to get boring, it is automated. At first going to the moon is a huge undertaking, while later going to anywhere in the Sun galaxy is very short. This is what I mean with reducing distances.

(Sorry for taking such a long time to explain)

Anyways how I think you should include this in your RTS:

You should start with only one or a few units who have some goal. Maybe their plane crashed, maybe a sabotage mission, something. This should just give the player time to get used to the controls. Then maybe after a succesful sabotage/assassination mission, the unit(s) have to flee to a specific point (a logical point, maybe there''s a lot in persue). Here are some combat reinforcement units, they can be used to fend off the persuers and maybe counterattack. Then if the player manages to raid the base they can gain control of the ''contstruction yard/townhall'' structure as well as the ''income'' structure. If not they have to run again and decide to set up their own base and build units to destroy the previously mentioned base.

Then after a while they have to secure a larger area
Then once there''s a large attack and the player is forced to defend
Then once there is power outage and fog of war creeps in because of a shortage of light and you get attacked again
Then you get access to building planes to drop off your units at far off spots (and build air support there to get them back).
Then a lab raid gives you a new technology that allows units to go way faster and explore further sections of the map....etc. etc.


One thing you should make sure off, is that there is no impenetrable defense against your AI. If 20 towers in lineup and a couple of repairmen can hold of any attack, the challenge is completely gone for the player.

Thanks a lot for your help! I''ve thought a lot about keeping up the speed as well. I thought the AI could be handled by a central processing unit for each team. For example, each unit could check maybe once every ten frames to see if it had seen an enemy unit. If so, it is added to a central list of AI things to process. Massive attacks would be handled by the central AI as well, and not micro-processed by each unit. I like Taco''s idea of gradually making certain things easier while creating new problems. Thanks for everyone''s positive feedback!