RTS Experiments
by Jeff Leigh · in RTS Starter Kit · 12/08/2004 (12:17 pm) · 25 replies
I'm going to post some experiments I'm doing with the RTS kit in this thread for everyone's information. First up:
Experiment #1: Ant Hill
This is just to see how many RTS Units I could get running around and the frame rates it would create. Below is a graph of the results pitting the number of units in the game and the frames per second. This is on my:
- P4 Mobile 2.2 GHZ CPU
- 512 MB RAM
- GeForce 420 Go 32MB Graphics Card
[Image]www.yucatech.com/ggames/stats.JPG[/Image]
This was created adding one unit every 2 seconds and ALL the units moving at once from one random setMoveDestination to another. The spike in the lower area was when I started to move the camera around. Obviously the less items in view the higher the frame rate. There was one spot on the map that had few units on it that I went through.
And here is a shot of the anthill at 500 units and a low (13.5 but still very responsive camera) frame rate:
[Image]www.yucatech.com/ggames/anthill.JPG[/Image]
Experiment #1: Ant Hill
This is just to see how many RTS Units I could get running around and the frame rates it would create. Below is a graph of the results pitting the number of units in the game and the frames per second. This is on my:
- P4 Mobile 2.2 GHZ CPU
- 512 MB RAM
- GeForce 420 Go 32MB Graphics Card
[Image]www.yucatech.com/ggames/stats.JPG[/Image]
This was created adding one unit every 2 seconds and ALL the units moving at once from one random setMoveDestination to another. The spike in the lower area was when I started to move the camera around. Obviously the less items in view the higher the frame rate. There was one spot on the map that had few units on it that I went through.
And here is a shot of the anthill at 500 units and a low (13.5 but still very responsive camera) frame rate:
[Image]www.yucatech.com/ggames/anthill.JPG[/Image]
#2
Nevermind, got the counter for both now. Just didn't show up in a version I'd fiddled with.
12/08/2004 (1:43 pm)
Cool. Missing the FPS/Unit counter though. Otherwise works great. Fun watching them all run around like ants. ;)Nevermind, got the counter for both now. Just didn't show up in a version I'd fiddled with.
#3
When I happened to notice here's the screen shot from it. Can you say 'Overload!'.
4500+ units and a whooping 0.7 frames per second :-o
[Image]http://www.yucatech.com/ggames/overload.JPG[/Image]
12/08/2004 (4:04 pm)
Oops, I forgot I turned off the game duration to get a high unit count and left a machine running that way.When I happened to notice here's the screen shot from it. Can you say 'Overload!'.
4500+ units and a whooping 0.7 frames per second :-o
[Image]http://www.yucatech.com/ggames/overload.JPG[/Image]
#4
I'm quite happy with the rendering performance. Torque rocks. :) We thought we'd have to do some hefty optimization to get these speeds on lower-end machines, but it's great to see a couple hundred units running around at playable framerates on a lowly GF 420 Go (not to diss your card or anything ;).
I was amazed by the videos for the Lord of the Rings RTS game before it shipped... seemed they had such awesome rendering performance. But playing it on my machine at home... it hitches pretty bad on a 9700 Pro and Athlon 2500+ with just a couple hundred units on-screen. Of course, I'm not saying our performance is better, since it's clearly not an apples-to-apples comparison (they have AI and other stuff to calculate). But... dang, we are at least close. Great stuff for indies.
All that said, there are still a lot of rendering optimizations that could be done, and perhaps we'll release some in the future. If so, I'll look forward to seeing some kickass comparison performance tests like this. Good job, formal tests like this are very useful.
12/08/2004 (4:59 pm)
Haha... very, very cool Jeff. I'm quite happy with the rendering performance. Torque rocks. :) We thought we'd have to do some hefty optimization to get these speeds on lower-end machines, but it's great to see a couple hundred units running around at playable framerates on a lowly GF 420 Go (not to diss your card or anything ;).
I was amazed by the videos for the Lord of the Rings RTS game before it shipped... seemed they had such awesome rendering performance. But playing it on my machine at home... it hitches pretty bad on a 9700 Pro and Athlon 2500+ with just a couple hundred units on-screen. Of course, I'm not saying our performance is better, since it's clearly not an apples-to-apples comparison (they have AI and other stuff to calculate). But... dang, we are at least close. Great stuff for indies.
All that said, there are still a lot of rendering optimizations that could be done, and perhaps we'll release some in the future. If so, I'll look forward to seeing some kickass comparison performance tests like this. Good job, formal tests like this are very useful.
#5
This implementation prevents units from travelling onto terrain types with a certain "intensity" of designated textures. It's a mutated version of something James Holmes did a long time ago adapted to the RTS version and made more flexible.
The current design allows you to set a threshold on the alpha channels of the blended terrain and detect when the unit will be moving onto that type of terrain and stop them before they do.
Anyone wants the code to do this just replace the appropriate files in an unmodified stock standard RTS Starter Kit with the ones in this zip or WinMerge it into your own modified version (sorry can't help you with it if you take that route) and off you go.
The password for this zip file is:
jwl-rts
Again, please DO NOT share this code or password with anyone outside of this private RTS forum per previous threads.
After you do this replacement, start the standard RTS mission, select all the units, then tell them to go to center of the big patch or rock in the lower right corner of the screen. You'll see they stop at the edge as in this screen shot. The higher you set the intensity check near the bottom of player::processtick() the more particular the units are about crossing onto it. That is, if the terrain is truly only rock and the threshold is set to like 200 or above then the units won't go onto it. If the terrain is a blend of say 30% grass, 30%, rock, and 30% scorched then the units will still go over it even though it contains rock. That's why you'll see a couple of the units ventured onto it. They happened to be on a section that was less rock and more of a blend than what the others ran into.
Edit: Fixed links
12/10/2004 (7:12 pm)
EXPERIMENT2 - Don't Go There!This implementation prevents units from travelling onto terrain types with a certain "intensity" of designated textures. It's a mutated version of something James Holmes did a long time ago adapted to the RTS version and made more flexible.
The current design allows you to set a threshold on the alpha channels of the blended terrain and detect when the unit will be moving onto that type of terrain and stop them before they do.
Anyone wants the code to do this just replace the appropriate files in an unmodified stock standard RTS Starter Kit with the ones in this zip or WinMerge it into your own modified version (sorry can't help you with it if you take that route) and off you go.
The password for this zip file is:
jwl-rts
Again, please DO NOT share this code or password with anyone outside of this private RTS forum per previous threads.
After you do this replacement, start the standard RTS mission, select all the units, then tell them to go to center of the big patch or rock in the lower right corner of the screen. You'll see they stop at the edge as in this screen shot. The higher you set the intensity check near the bottom of player::processtick() the more particular the units are about crossing onto it. That is, if the terrain is truly only rock and the threshold is set to like 200 or above then the units won't go onto it. If the terrain is a blend of say 30% grass, 30%, rock, and 30% scorched then the units will still go over it even though it contains rock. That's why you'll see a couple of the units ventured onto it. They happened to be on a section that was less rock and more of a blend than what the others ran into.
Edit: Fixed links
#6
12/10/2004 (10:39 pm)
Great stuff, Jeff! :)
#7
Small suggestion: Since we don't have a resources forum yet, you may want to break this out into it's own message thread, in the resource section if you feel it's "done" (or close), or another general discussion thread if it's still a work in progress.
12/11/2004 (1:13 am)
Very sweet! I have something very similar on my todo list (although I was more focused on terrain gradient/slope than terrain material/texture)--will be a great stepping stone, thanks a ton!Small suggestion: Since we don't have a resources forum yet, you may want to break this out into it's own message thread, in the resource section if you feel it's "done" (or close), or another general discussion thread if it's still a work in progress.
#8
I'm actually intending these to be just short proofs of concept (i.e. that it can be done). Like the pathing stuff a lot of these will have wide variations for actual implementations so they're really half (actually much less) baked resources. Given that, do you think I should put them over there anyway, or just break them out into separate threads here? Don't want people to claim my resources suck because they don't understand they're only to get people started.
I looked at terrain slope as well but opted for the texture approach since there really isn't a random terrain generator yet (i.e. someone needs to create the maps anyway). So as long as the designer uses textures appropriately I figured this was an efficient CPU method of keeping units from just walking up mountains and such. Which, by the way needs work. The "depth" and angle of checking the terrain texture in the code above needs adjustment. You'll notice that the units will still scamper straight up the face of a cliff even if it's only rock. Looking down it doesn't always see that.
12/11/2004 (4:52 am)
@StephenI'm actually intending these to be just short proofs of concept (i.e. that it can be done). Like the pathing stuff a lot of these will have wide variations for actual implementations so they're really half (actually much less) baked resources. Given that, do you think I should put them over there anyway, or just break them out into separate threads here? Don't want people to claim my resources suck because they don't understand they're only to get people started.
I looked at terrain slope as well but opted for the texture approach since there really isn't a random terrain generator yet (i.e. someone needs to create the maps anyway). So as long as the designer uses textures appropriately I figured this was an efficient CPU method of keeping units from just walking up mountains and such. Which, by the way needs work. The "depth" and angle of checking the terrain texture in the code above needs adjustment. You'll notice that the units will still scamper straight up the face of a cliff even if it's only rock. Looking down it doesn't always see that.
#9
You've got a good point regarding which implementation--especially with the fact that you give more control by doing it via terrain type (as well as being able to enhance it by making movespeed limited by terrain features!).
To be honest, I'm going to have to delve deeply into some form of a pathfinding algorithm for units before I can make a good decision as to which method (terrain material/texture vs gradient)...my guess is that as long as you can give a movement weight/cost to a particular height coordinate pair, it won't ultimately matter which you use (or both).
12/11/2004 (5:01 am)
Probably just separate threads in general section--I know how you feel about RTS SK resources :)You've got a good point regarding which implementation--especially with the fact that you give more control by doing it via terrain type (as well as being able to enhance it by making movespeed limited by terrain features!).
To be honest, I'm going to have to delve deeply into some form of a pathfinding algorithm for units before I can make a good decision as to which method (terrain material/texture vs gradient)...my guess is that as long as you can give a movement weight/cost to a particular height coordinate pair, it won't ultimately matter which you use (or both).
#10
01/24/2005 (7:01 pm)
I am having problems learning what files to move where and what text files to edit, so where exactly do I put this file to get it to work?
#11
There are no new files in this resource, so just put each of the files that are in the zip file in the exact same place that each already is (replacing the existing files).
You have to start with the Stock RTS Starter Kit though, if you've modified anything I can't say it will work still.
01/25/2005 (10:35 am)
@PunkkidThere are no new files in this resource, so just put each of the files that are in the zip file in the exact same place that each already is (replacing the existing files).
You have to start with the Stock RTS Starter Kit though, if you've modified anything I can't say it will work still.
#12
I am very interested to this type of experiments. I would love to create a RTS with the possibility to create cities and armies ambiented in the ancient roman world. A good average of units, considere allies and ennemies, should be around 200 or 300. I have modified the starter RTS in order to have 12x12=144 units created when the game starts, but the game was very slow and it was impossible to command units ... Did I do something wrong, considered that somebody created up to 4500+ units ?
thank you and best regards
Angelo
08/26/2005 (2:06 am)
Hello,I am very interested to this type of experiments. I would love to create a RTS with the possibility to create cities and armies ambiented in the ancient roman world. A good average of units, considere allies and ennemies, should be around 200 or 300. I have modified the starter RTS in order to have 12x12=144 units created when the game starts, but the game was very slow and it was impossible to command units ... Did I do something wrong, considered that somebody created up to 4500+ units ?
thank you and best regards
Angelo
#13
08/26/2005 (3:29 am)
How many polygons are you rendering per unit? :)
#14
thank for the reply... In fact I am just doing some tests with the standard RTS package, so I am using the RTS unit delivered with the package. I mean, those types of units, the robot and two others. May be this is where I am doing the wrong assumption. My units should be very simple, even if I am planning to create few types (centurions, legionnaires, archers and eventually chevalry) and of course some type of ennemy (or just the same with different colors...dunno yet).
I have Lightwave and a rainy week end in front of me, I will try to create a very low poly unit and check what happens.
Just to clarify, my idea is to create a game like Caesar III, but with some more "battle thrilling" (like testudo for soldiers, possibility to put them in formation depending on the "skills" developed in the cities, etc), so the army is an important element of the game. If I can create an army with only 20 soldiers, the game could result somewhat na
08/26/2005 (5:51 am)
Hello,thank for the reply... In fact I am just doing some tests with the standard RTS package, so I am using the RTS unit delivered with the package. I mean, those types of units, the robot and two others. May be this is where I am doing the wrong assumption. My units should be very simple, even if I am planning to create few types (centurions, legionnaires, archers and eventually chevalry) and of course some type of ennemy (or just the same with different colors...dunno yet).
I have Lightwave and a rainy week end in front of me, I will try to create a very low poly unit and check what happens.
Just to clarify, my idea is to create a game like Caesar III, but with some more "battle thrilling" (like testudo for soldiers, possibility to put them in formation depending on the "skills" developed in the cities, etc), so the army is an important element of the game. If I can create an army with only 20 soldiers, the game could result somewhat na
#15
Also keep in mind that my test units were 100% AI driven. I did not experiment with how that affected the user's ability to interact with the units.
The linked zip file from the second post will give you the code I used to generate the 500 units (which was still in the mid-teens fps wise). Compare that to your code with 144 to see what you may be doing different and how user interaction may have worked in my test scenario.
Good luck...
08/26/2005 (9:16 am)
I think you misinterpreted the 4500+ post above. That was an example of bringing the system to it's knees (the frame rate it caused was only 0.7fps - you should stay around 30fps to be reasonable).Also keep in mind that my test units were 100% AI driven. I did not experiment with how that affected the user's ability to interact with the units.
The linked zip file from the second post will give you the code I used to generate the 500 units (which was still in the mid-teens fps wise). Compare that to your code with 144 to see what you may be doing different and how user interaction may have worked in my test scenario.
Good luck...
#16
One of the things we decided to do because of these tests was to completely re-write the visManager (again!), and there are probably some additional optimizations you can make in the long run, but for now I'd probably suggest working from the art side--coming up with lower poly but better (more artistically designed) textures, etc. Even though the units given with the RTS-SK are "low poly", 144 units * 800-ish polys per unit adds up quite quickly.
08/26/2005 (1:10 pm)
I've done tests with my project where we had 200-ish units interacting fully (combat, auto-attack, etc.) on a dedicated server with 3 clients remotely connected, and the FPS was down to about 25-ish, but playable on my high end machine, not so much on my secondary testing machine.One of the things we decided to do because of these tests was to completely re-write the visManager (again!), and there are probably some additional optimizations you can make in the long run, but for now I'd probably suggest working from the art side--coming up with lower poly but better (more artistically designed) textures, etc. Even though the units given with the RTS-SK are "low poly", 144 units * 800-ish polys per unit adds up quite quickly.
#17
*update*
Nevermind I'm an idiot, yeah there are no GUI based tools that I'm aware of to uncompress a password protected Zip, however simply issuing unzip at the command line, does do the trick.
11/06/2005 (3:38 am)
I would LOVE to check out the code, and replicate these tests. Only problem is your ZIP is password protected and I can't seem to find anything under linux that can decompress a password protected ZIP. Any chance of getting a copy of the sources in non password protected form? Thanks!*update*
Nevermind I'm an idiot, yeah there are no GUI based tools that I'm aware of to uncompress a password protected Zip, however simply issuing unzip at the command line, does do the trick.
#18
1-100 = 180fps
100-200 = 100 fps
200-300 = 80 fps
300-400 = 50 fps
400-500 = 30 fps
500-600 = 20 fps
600-700 = 15 fps
After the framerate drops below 15 fps the game is no longer really playable however.
700-800 = 8fps
800-900 = 5fps
1000 = 3fps
Test machine
AMD Athlon 2200+XP
1GB DDR Ram
ATI 9200SE w/ 256MB VRAM
SuSE 10.0 with ATI Binary Driver
Pretty awesome results though, I'm impressed.
Also I noticed if I comment out the "Arrived" line I experienced 10fps at 1000 Units, the difference scales from 1-10fps from 500-1000 units with about +2fps difference per 100 units, it's negligible before 500 though. I think this is because it gets so spamtastic after about 500 units, and so it's one less thing for the engine to do.
Thoughts?
11/06/2005 (4:31 am)
Ok, well here are my results1-100 = 180fps
100-200 = 100 fps
200-300 = 80 fps
300-400 = 50 fps
400-500 = 30 fps
500-600 = 20 fps
600-700 = 15 fps
After the framerate drops below 15 fps the game is no longer really playable however.
700-800 = 8fps
800-900 = 5fps
1000 = 3fps
Test machine
AMD Athlon 2200+XP
1GB DDR Ram
ATI 9200SE w/ 256MB VRAM
SuSE 10.0 with ATI Binary Driver
Pretty awesome results though, I'm impressed.
Also I noticed if I comment out the "Arrived" line I experienced 10fps at 1000 Units, the difference scales from 1-10fps from 500-1000 units with about +2fps difference per 100 units, it's negligible before 500 though. I think this is because it gets so spamtastic after about 500 units, and so it's one less thing for the engine to do.
Thoughts?
#19
You may want to activate profiling (pretty easy, do a search for "profiler" here on the forums, and start analyzing it.
11/09/2005 (12:03 pm)
As part of the final testing for the new RTSVisManager class my team is developing, we've been doing generic profiling on the RTS stuff as a whole--and we've found that even with our new manager (which is MUCH more highly performant), you start hitting limits on the processTick() of the RTSUnit itself...even though it's lightweight, the stuff it does do starts to add up.You may want to activate profiling (pretty easy, do a search for "profiler" here on the forums, and start analyzing it.
#20
11/10/2005 (4:08 am)
Actually I'ld be happy if I could just start seeing where my enemies are ;) 
Torque Owner Jeff Leigh
YucaTech Studios
The password for this zip file is:
jwl-rts
Please DO NOT share this code or password with anyone outside of this private RTS forum per previous threads.
In case anyone wants to manually examine the changes they are delimited by these markers start and end:
Next experiment - not sure yet...