Progress on my RTS
by Geom · 03/20/2006 (5:19 pm) · 20 comments
Here's some progress on the RTS I've been working on. All models and textures are just stand-ins at the moment. I'm focusing more on functional behavior before I worry about the art too much.
Each base has its own local supply of resources. This is shown when you hover over or select a base building. The tree icon shows the number of resources, and the worker icon shows the number of workers harvesting for the base.
I'm using the "building planning marker" (is that its name?) that came with the RTS SK. I constrain the marker's position to always be aligned to world tiles, so you always know exactly where a building will get built. I'm currently using a world tile size of 8 meters (the default), but eventually I'd like to go finer to something like 4 meters. Though I understand there are still issues with that and water blocks.
The game is smart enough to not let you build on top of existing buildings and other illegal places (prev image). A green marker indicates an ok spot to build. For the red and green markers, I'm just using a flat green/flat red texture with no details in them whatsoever. I thought it came out looking ok.
For the animating the building process, currently I just scale up the Z scale. So the building rises out of the ground. This is an older screenshot where the worker is standing in the middle of the building to build it (so you can't see him). I've changed it so that he now walks to the perimeter before building it.
Viola! Two bases. I allow multiple buildings to be multi-selected if they're the same type, as shown here. That way the player can queue production orders or set rally points faster. Yeah! Take that, RTS micro-management.
Got some walls and towers going on...
More walls and towers. The walls are kind of rediculously thick at the moment.
You can now tell soldiers to attack specific targets. Here's a soldier attacking a tower.
Options on the start-server GUI. ("HFW" is just the internal project name if you were wondering)
More details about this project are on our website,
Red Brick Games
Each base has its own local supply of resources. This is shown when you hover over or select a base building. The tree icon shows the number of resources, and the worker icon shows the number of workers harvesting for the base.
I'm using the "building planning marker" (is that its name?) that came with the RTS SK. I constrain the marker's position to always be aligned to world tiles, so you always know exactly where a building will get built. I'm currently using a world tile size of 8 meters (the default), but eventually I'd like to go finer to something like 4 meters. Though I understand there are still issues with that and water blocks.
The game is smart enough to not let you build on top of existing buildings and other illegal places (prev image). A green marker indicates an ok spot to build. For the red and green markers, I'm just using a flat green/flat red texture with no details in them whatsoever. I thought it came out looking ok.
For the animating the building process, currently I just scale up the Z scale. So the building rises out of the ground. This is an older screenshot where the worker is standing in the middle of the building to build it (so you can't see him). I've changed it so that he now walks to the perimeter before building it.
Viola! Two bases. I allow multiple buildings to be multi-selected if they're the same type, as shown here. That way the player can queue production orders or set rally points faster. Yeah! Take that, RTS micro-management.
Got some walls and towers going on...
More walls and towers. The walls are kind of rediculously thick at the moment.
You can now tell soldiers to attack specific targets. Here's a soldier attacking a tower.
Options on the start-server GUI. ("HFW" is just the internal project name if you were wondering)
More details about this project are on our website,
Red Brick Games
About the author
My email address is my GG handle, at redbrickgames.com.
Recent Blogs
• Orcs vs. Martians - updated video• Orcs vs. Martians November update
• Milestone!
• The Burninating
• Victory flags
#2
I assume that means your work can't really be released as a community resource?
Also curious if you are planning on allowing the RTS units to walk on top of the walls?
03/20/2006 (6:43 pm)
Fantastic progress Geom, sure whish I had you working on my current project. I noticed that you posted on your web page that you are converting torque script to C++I assume that means your work can't really be released as a community resource?
Also curious if you are planning on allowing the RTS units to walk on top of the walls?
#3
thanks, I've been working 50-60 hours a week on this so that helps with the progress. I've got to slow down, I know I'll burn out if I keep that up.
@Todd
not at all, I could share resources, the C++ would just need a ConsoleFunction wrapper in order to be called from TorqueScript. I was thinking to release the pathfinding code as a resource, but the problem there is that my pathfinding uses STL and STL conflicts with the Torque memory manager. As a temporary solution I've turned off the Torque memory manager in my game, but I have a feeling that's not a good solution and I'm going to have to revisit this problem again in the future.
It would be kind of cool to allow units to walk on tops of walls. They could get a range bonus or something. I have a feeling it might be rife with technical problems, though. It might require me to make the walls be .dif's instead of .dts, and that in turn might have a performance impact.
03/20/2006 (9:57 pm)
@Ianthanks, I've been working 50-60 hours a week on this so that helps with the progress. I've got to slow down, I know I'll burn out if I keep that up.
@Todd
not at all, I could share resources, the C++ would just need a ConsoleFunction wrapper in order to be called from TorqueScript. I was thinking to release the pathfinding code as a resource, but the problem there is that my pathfinding uses STL and STL conflicts with the Torque memory manager. As a temporary solution I've turned off the Torque memory manager in my game, but I have a feeling that's not a good solution and I'm going to have to revisit this problem again in the future.
It would be kind of cool to allow units to walk on tops of walls. They could get a range bonus or something. I have a feeling it might be rife with technical problems, though. It might require me to make the walls be .dif's instead of .dts, and that in turn might have a performance impact.
#4
Here is a pic
03/20/2006 (10:25 pm)
Yup, you are right about the wall walking, it is potentially a mine field of trouble. I did it in an RTS game I worked on a couple of years ago, and it came out pretty well, but the walls were all paced by me in the map building stage and could not be placed by the player, so it simplified thing a good bit.Here is a pic
#5
It looks like you're doing a great job so far. Very nice.
@Todd
Nice pic! What game was that for?
03/21/2006 (1:03 am)
@GeomIt looks like you're doing a great job so far. Very nice.
@Todd
Nice pic! What game was that for?
#6
I just love RTS games, so naturally i hope something good comes of this :)
03/21/2006 (4:12 am)
Great progress!I just love RTS games, so naturally i hope something good comes of this :)
#7
But looking at Geom's stuff, I am getting really excited. He is one of very few to make significant progress with an RTS project in the GG community. I can't help but start thinking what I could do with his game from and art stand point right now.
03/21/2006 (8:44 am)
Thanks Aaron, it was shovelware ...*cough* eerrr ...a "Budget Title" developed in a couple of months from start to finish. It was actually pretty robust, but needed another month of polish and balance testing.But looking at Geom's stuff, I am getting really excited. He is one of very few to make significant progress with an RTS project in the GG community. I can't help but start thinking what I could do with his game from and art stand point right now.
#8
that screenshot looks very nice. Only two months really?
I like your environment pack, it looks awesome. But this first RTS of mine will have a cartoon-ish theme, do you have art assests in that vein?
@ Aaron, James
thanks! Well I hope I can write something you'll like. I like playing RTS games too and it's really cool to think I have the opportunity to combine my favorite gameplay elements from different RTSs, into a single game.
03/21/2006 (12:14 pm)
@Toddthat screenshot looks very nice. Only two months really?
I like your environment pack, it looks awesome. But this first RTS of mine will have a cartoon-ish theme, do you have art assests in that vein?
@ Aaron, James
thanks! Well I hope I can write something you'll like. I like playing RTS games too and it's really cool to think I have the opportunity to combine my favorite gameplay elements from different RTSs, into a single game.
#9
Thanks very much.
At the moment, I don't have any usable cartoony rts stuff, but I am working on some stuff that will lean in that direction. I'll send you some screens when the stuff is a little further along.
Can you give me an example of the style you are looking for? How cartoony? Are you talking about cartoony in just shape and proportion, super bright colors, or both?
Have you seen Canon's RTS content stuff?
03/21/2006 (12:36 pm)
Geom,Thanks very much.
At the moment, I don't have any usable cartoony rts stuff, but I am working on some stuff that will lean in that direction. I'll send you some screens when the stuff is a little further along.
Can you give me an example of the style you are looking for? How cartoony? Are you talking about cartoony in just shape and proportion, super bright colors, or both?
Have you seen Canon's RTS content stuff?
#10
If anyone's curious, the cartoony style isn't really "my thing" per se, but since I'm planning on making two RTSs, I was thinking this would be a great way to differentiate them. The 1st will be cartoony and aimed at a somewhat casual audience, the 2nd one more realistic and aimed at more sophisticated gamers.
03/21/2006 (1:22 pm)
It's all tenative at this point, but cartoony in exaggerated proportions (though not greatly so) and yes bright colors. I did see Canon's stuff, that's the style I want to go for. However he doesn't have any sci-fi stuff (I asked) so I'm keeping a look out for cartoony sci-fi buildings. Maybe of in the vein of the backdrops to Marvin the Martian (the Warner Bros. character)If anyone's curious, the cartoony style isn't really "my thing" per se, but since I'm planning on making two RTSs, I was thinking this would be a great way to differentiate them. The 1st will be cartoony and aimed at a somewhat casual audience, the 2nd one more realistic and aimed at more sophisticated gamers.
#11
Any advice would be greatly appreciated,
- Lachlan.
06/13/2006 (5:21 pm)
Hi Geom, I know this is an old post, but I am just starting up with the RTS pack. I am having trouble getting water to work properly as the RTSPack seems to prefer world tile size of 5. I switched it to 8 to fix the shoreline allignment issues, but now the engine seems to crash (while either trying to render the minimap or the water block). I was just wondering if you did any tweaks to get your water blocks working so nicely? I notice that you mention that you put it back to the default 8, but how do you avoid the crashes? Did you port the RTS to TGE 1.4, or are you still in 1.3?Any advice would be greatly appreciated,
- Lachlan.
#12
I am getting that crash in rendering the minimap, too. Mine is in fluid::CalcVertSpecular. For me the crash has been pretty intermittant. Its likelihood seems to depend on how much water is in the world. Up to now I've just been ignoring it. It's good to know somebody else has seen it too, I'm going to see if I can figure out what's going on and will post if I find a solution.
The minimap renders a pretty big part of the game world so I'm wondering if the crash is caused by too much data for something in Torque's rendering pipeline. I notice that the RTS-SK splits minimap rendering into four quadrants; I wonder if they did that to try to address this problem?
Still on Torque 1.3.
06/19/2006 (5:43 pm)
Hi Lachlan,I am getting that crash in rendering the minimap, too. Mine is in fluid::CalcVertSpecular. For me the crash has been pretty intermittant. Its likelihood seems to depend on how much water is in the world. Up to now I've just been ignoring it. It's good to know somebody else has seen it too, I'm going to see if I can figure out what's going on and will post if I find a solution.
The minimap renders a pretty big part of the game world so I'm wondering if the crash is caused by too much data for something in Torque's rendering pipeline. I notice that the RTS-SK splits minimap rendering into four quadrants; I wonder if they did that to try to address this problem?
Still on Torque 1.3.
#13
Haven't figured out a fix yet tho...
06/20/2006 (12:32 am)
Bingo, that does indeed seem to be the problem (i.e. the data set is too big). The problem has to do with the data member fluid::m_pIndex. It's an array of vertex indices, each index a 16-bit signed int. In my test case that crashes, the indices are getting up to about ~45000. 45000 does not fit in a 16-bit signed int. So the larger values get interpreted as negative numbers, then the negative numbers get added to an array offset, and the memory access goes the wrong way into la-la land. That causes the crash.Haven't figured out a fix yet tho...
#14
Thanks for the reply mate. I actually fixed this myself. Sorry for not posting the solution straight away. Yeah, I came to the same conclusion as yourself. It occurs as m_pIndex[i] passes into the negative. How I fixed this was simply to get the absolute value here. Obviously this won't get the correct index, but it will fix the crash and I doubt you'd notice the annomalies in the render anyway.
So ok, the fix (I did) was to change line 833 in fluidRender.cc to:
vertex *vert = m_pVertex + abs(m_pIndex[i]);
That's it! Taking the absolute value puts the index back into acceptable ranges. Obviously it isn't a "fix" as such (I'm not going to go around changing the datatype they used, I suspect it was only 16-bit to save on space and with good reason!), but it removes the crashes.
Hope this helps! Cheers,
Lachlan.
06/20/2006 (3:27 am)
Hi Geom,Thanks for the reply mate. I actually fixed this myself. Sorry for not posting the solution straight away. Yeah, I came to the same conclusion as yourself. It occurs as m_pIndex[i] passes into the negative. How I fixed this was simply to get the absolute value here. Obviously this won't get the correct index, but it will fix the crash and I doubt you'd notice the annomalies in the render anyway.
So ok, the fix (I did) was to change line 833 in fluidRender.cc to:
vertex *vert = m_pVertex + abs(m_pIndex[i]);
That's it! Taking the absolute value puts the index back into acceptable ranges. Obviously it isn't a "fix" as such (I'm not going to go around changing the datatype they used, I suspect it was only 16-bit to save on space and with good reason!), but it removes the crashes.
Hope this helps! Cheers,
Lachlan.
#15
So if we take the amount it overflows by and add it to the maximum value of a short int (SHRT_MAX), we should get the right index, right? Of course, this time we avoid the whole problem by chucking it into an unsigned int.
Ok, so here is the new fix (still in fluidRender.cc). Firstly, this fix needs SHRT_MAX to be defined. So you can either #include "limits.h" at the top of the file, or just add: #define SHRT_MAX 32767 somewhere.
Next move the definition:
vertex *vert;
to the top of the function (line 809) as we're now assigning it in a condition.
Lastly, instead of
vertex *vert = m_pVertex + m_pIndex[i];
at line 833, we change it to:
if(m_pIndex[i] < 0)
vert = m_pVertex + (unsigned int)(m_pIndex[i] + SHRT_MAX) + (unsigned int)SHRT_MAX;
else
vert = m_pVertex + m_pIndex[i];
I've tested this and it still runs fine. It should also, however, pick up the correct index now.
Hope that wasn't too cryptic. Feel free to hassle me if you want to discuss it further.
Cheers,
Lachlan.
06/20/2006 (4:05 am)
Ok, after thinking about my "fix" for a few minutes more, I realised we could fix the negative issue and still get the correct vertex index. Ok, so once the value goes past the short's limits it passes into the negative right?So if we take the amount it overflows by and add it to the maximum value of a short int (SHRT_MAX), we should get the right index, right? Of course, this time we avoid the whole problem by chucking it into an unsigned int.
Ok, so here is the new fix (still in fluidRender.cc). Firstly, this fix needs SHRT_MAX to be defined. So you can either #include "limits.h" at the top of the file, or just add: #define SHRT_MAX 32767 somewhere.
Next move the definition:
vertex *vert;
to the top of the function (line 809) as we're now assigning it in a condition.
Lastly, instead of
vertex *vert = m_pVertex + m_pIndex[i];
at line 833, we change it to:
if(m_pIndex[i] < 0)
vert = m_pVertex + (unsigned int)(m_pIndex[i] + SHRT_MAX) + (unsigned int)SHRT_MAX;
else
vert = m_pVertex + m_pIndex[i];
I've tested this and it still runs fine. It should also, however, pick up the correct index now.
Hope that wasn't too cryptic. Feel free to hassle me if you want to discuss it further.
Cheers,
Lachlan.
#16
Dude, you live in Sydney? That's a coincidence, I was there on vacation just 6 days ago. I stayed in Granville with a friend of mine.
06/20/2006 (2:07 pm)
Makes sense to me. Only, I'm a little concerned about that fix introducing visual artifacts, even if it doesn't crash. After all we're feeding the renderer wrong vertex indices. Having said that though, I tried it out and everything seems to look fine.Dude, you live in Sydney? That's a coincidence, I was there on vacation just 6 days ago. I stayed in Granville with a friend of mine.
#17
Well, in *theory* the fix in my second post should be getting the correct vertex indeces. So it shouldn't have any artifacts. Of course, someone could find a problem with my fix. Still, I didn't see any artifacts either. I have one gripe about the minimap and that is that it shows artifacts if your water uses specular lighting. Unfortunately, the only way to get rid of that is to remove the specular.
As an aside, the code I posted above is not quite as efficient as it could be. To save on an add or two, replace:
vert = m_pVertex + (unsigned int)(m_pIndex[i] + SHRT_MAX) + (unsigned int)SHRT_MAX;
with
vert = m_pVertex + (unsigned int)m_pIndex[i] + (unsigned int)65534;
65534 is just SHRT_MAX * 2.
Yep, Sydneysider all my life. Hope it wasn't too rainy for ya, we had a bit of a rainy spell over the last month (although we weren't complaining, being in drought and all).
Anyway, how's the project going? I must admit, I was quite inspired when I saw that you've quit your job to finish it. Unfortunately, I'm not that courageous yet. Maybe once I have something looking closer to being finished I'll do the same.
Happy coding!
06/26/2006 (5:08 pm)
Hey again.Well, in *theory* the fix in my second post should be getting the correct vertex indeces. So it shouldn't have any artifacts. Of course, someone could find a problem with my fix. Still, I didn't see any artifacts either. I have one gripe about the minimap and that is that it shows artifacts if your water uses specular lighting. Unfortunately, the only way to get rid of that is to remove the specular.
As an aside, the code I posted above is not quite as efficient as it could be. To save on an add or two, replace:
vert = m_pVertex + (unsigned int)(m_pIndex[i] + SHRT_MAX) + (unsigned int)SHRT_MAX;
with
vert = m_pVertex + (unsigned int)m_pIndex[i] + (unsigned int)65534;
65534 is just SHRT_MAX * 2.
Yep, Sydneysider all my life. Hope it wasn't too rainy for ya, we had a bit of a rainy spell over the last month (although we weren't complaining, being in drought and all).
Anyway, how's the project going? I must admit, I was quite inspired when I saw that you've quit your job to finish it. Unfortunately, I'm not that courageous yet. Maybe once I have something looking closer to being finished I'll do the same.
Happy coding!
#18
Anyway - the project is going pretty well. The out-of-game setup screens ended up taking a lot of time, and still aren't completely finished. I doubled the size (scale) on the RTS units and that makes the game look vastly better. I've gotten the game optimized enough to where I can now get about 50 units before the game starts to lag. I'll probably need to get that up to about 500 when all is said and done.
I still haven't really gotten to writing the "gameplay" proper; the gameplay I've got now is only a simple stand-in while I build up the game's infrastructure.
All told I figure I'm about half done at this point.
06/28/2006 (7:14 am)
The weather was clear the day I arrived in Sydney, and then it rained every day for the next seven days. Poor timing for me. Fortunately it was still pretty easy to get around by train and umbrella. I liked Sydney's train system, though it seems expensive. Where I live (Austin, Texas), we just voted to begin construction on a city commuter rail system, so I was kind of interested in that. Americans love their cars so there's consternation over whether Austin's rail system will catch on.Anyway - the project is going pretty well. The out-of-game setup screens ended up taking a lot of time, and still aren't completely finished. I doubled the size (scale) on the RTS units and that makes the game look vastly better. I've gotten the game optimized enough to where I can now get about 50 units before the game starts to lag. I'll probably need to get that up to about 500 when all is said and done.
I still haven't really gotten to writing the "gameplay" proper; the gameplay I've got now is only a simple stand-in while I build up the game's infrastructure.
All told I figure I'm about half done at this point.
#19
The unit scale changes really does seem to help, good idea. Also the mini map is looking MUCH better.
06/28/2006 (8:14 am)
Geom,The unit scale changes really does seem to help, good idea. Also the mini map is looking MUCH better.
#20
Sorry to hear that about your trip. The trains in Sydney are overpriced and sometimes not very reliable either. That is mainly due to poor management by the local government. However, cost wise, it beats driving hands-down.
I'll have to second Todd, the new scale is much more pleasing on the eye. The issues with numbers of simultaneous units is a bit of a concern to me as well. How often are you running the AI checks? Unfortunately my torque RTS project is on a bit of a backburner atm. My game would prefer to be pushing in the order of hundreds of units, with quite a large percentage of those on-screen at once. I'm not sure if torque is going to fit the bill for that, or if I'm going to end up "rolling my own". Looking at torque has inspired me to do some more work on one of my other engines, so I'm pretty happily steaming-along on other stuff.
Keep up the good work mate! Looks like yer on a good thing.
07/03/2006 (7:34 pm)
Hi Geom,Sorry to hear that about your trip. The trains in Sydney are overpriced and sometimes not very reliable either. That is mainly due to poor management by the local government. However, cost wise, it beats driving hands-down.
I'll have to second Todd, the new scale is much more pleasing on the eye. The issues with numbers of simultaneous units is a bit of a concern to me as well. How often are you running the AI checks? Unfortunately my torque RTS project is on a bit of a backburner atm. My game would prefer to be pushing in the order of hundreds of units, with quite a large percentage of those on-screen at once. I'm not sure if torque is going to fit the bill for that, or if I'm going to end up "rolling my own". Looking at torque has inspired me to do some more work on one of my other engines, so I'm pretty happily steaming-along on other stuff.
Keep up the good work mate! Looks like yer on a good thing.
Torque Owner Ian Roach