RTS Starter Kit and Collison
by Univ. of Michigan Dearborn (#001 · in RTS Starter Kit · 03/02/2006 (10:22 pm) · 31 replies
I'm working on an RTS with the starter kit. I need collision detection with the rtsunits. My plan is to take the collison code from the player and put it into the rtsunit, as was one of the solutions I've found on the forums.
Before I start plugging away at it, however, I was wondering if anyone has already done it. If so, is the code available anywhere? And/or do you have any advice for getting started? Is is an easy enough change to make?
Thanks in advance,
-Nick
Before I start plugging away at it, however, I was wondering if anyone has already done it. If so, is the code available anywhere? And/or do you have any advice for getting started? Is is an easy enough change to make?
Thanks in advance,
-Nick
About the author
#2
"Depending on your game design, your implementation may vary. If you need extremely robust, accurate collsion, you could check out and adapt the Player class processTick, updatePos, and findContact methods (/engine/game/player.h and player.cc)."
This is kind of what I've been looking at. Though I'm banging my head against the wall trying to figure it out.
-Nick
03/03/2006 (2:30 pm)
This is a quote from this forum post: http://www.garagegames.com/mg/forums/result.thread.php?qt=23286"Depending on your game design, your implementation may vary. If you need extremely robust, accurate collsion, you could check out and adapt the Player class processTick, updatePos, and findContact methods (/engine/game/player.h and player.cc)."
This is kind of what I've been looking at. Though I'm banging my head against the wall trying to figure it out.
-Nick
#3
-Nick
03/03/2006 (2:51 pm)
My main hope is/was that someone had already added collison for the rtsunits and I could use their code as opposed to recreating it. Or at the very least get some input from them. Mainly just to save time.-Nick
#4
03/03/2006 (3:47 pm)
Well I have created a simple pathfinding solution, the units will avoid buildings and you could use flocking for unit collision. If you describe what you are planning to do, maybe I can give better advice.
#5
03/03/2006 (4:20 pm)
Haven't done it myself Nick, but if you get it going I can help you work through trouble spots.
#6
I'm taking a class, Game Design and Implementation 2, and working in a team to create a game using the Torque Game Engine. There are 11 of us in the team, 6 art members, who are working with us from a different university and providing the art for the game, the units, buildings, map objects, etc. Then there are 5 of us working on the programming/software engineering part of the project. This is the first time any of us have worked with Torque so we're still learning, but so far things are going well. There's the background.
Now the game we're trying to make. It's an RTS game called Insect Wars. Basically the game involves a war between the inside bugs living inside of a house, verse the outdoor bugs trying to invade. There is no resource management, and no base management. The only base structures in the game are Main Bases, and Secondary Bases. Each side starts at a predefined point on the map, with all their insects already made. Each side also has one Main Base. The goal of each level is to capture the Main Base of the opposing side. The Secondary Bases start out as neutral and can be captured during the game.
As I said, at the start of each level all the insects are already spawned. Once an insect dies it is put on a queue. Insects are then taken off the queue and spawned at the Bases, after a certain length of time. The more Bases you control, the more insects you can have spawning at once. After each level you gain a certain number of points you can use between missions to buy new insects. All your previous insects also carry over to the next level. That's the game in a nutshell.
Now the problems. We bought the RTS-SK because we thought it'd give us a good starting point for our game, and for the most part it has. However, this Wednesday we discover that it's missing collision detection in the rtsunits. We figured we'd have to figure out how to do path finding, but we didn't know it didn't come with collision detection. We need the collision detection so we don't have units walking through walla, each other, bases, map objects, etc. One of our levels, for instance, is a sandbox. We've got the sandbox walls that bound the level, and various objects, a shovel, a ball, a sand castle, that exist in the level. Not to mention that we need triggers working to get the bases and various other things implemented.
So, we need some form of collision detection in the game. Then we need some path finding, doesn't have to be perfect, just needs to be decent. And finally a opponent AI. So you know, nothing too big. :|
So where the project stands right now. Most of our units are created, being animated, and being added to the game. The objects are being created and added. The art area of the project is going well. But the programming portion of the game is lacking. Without collision detection implemented, there is a serious limit as to what we can do with the game at this moment. So we're working on trying to add collision detection to the rtsunits. Which is what I'm now trying to do. But I'm severely limited because of my lack of understanding of the Torque Game Engine C++ code, etc. So I'm working through the code and trying to figure stuff out as best I can.
If you have any input, suggestions, criticisms, etc. they would be greatly appreciated! Originally I was hoping that someone(s) had already added collision detection to the rtsunits, but sadly no luck. But anyway, any help anyone can give me would be very helpful and much appreciated!
-Nick
03/04/2006 (8:30 pm)
Well here's what I'm involved in.I'm taking a class, Game Design and Implementation 2, and working in a team to create a game using the Torque Game Engine. There are 11 of us in the team, 6 art members, who are working with us from a different university and providing the art for the game, the units, buildings, map objects, etc. Then there are 5 of us working on the programming/software engineering part of the project. This is the first time any of us have worked with Torque so we're still learning, but so far things are going well. There's the background.
Now the game we're trying to make. It's an RTS game called Insect Wars. Basically the game involves a war between the inside bugs living inside of a house, verse the outdoor bugs trying to invade. There is no resource management, and no base management. The only base structures in the game are Main Bases, and Secondary Bases. Each side starts at a predefined point on the map, with all their insects already made. Each side also has one Main Base. The goal of each level is to capture the Main Base of the opposing side. The Secondary Bases start out as neutral and can be captured during the game.
As I said, at the start of each level all the insects are already spawned. Once an insect dies it is put on a queue. Insects are then taken off the queue and spawned at the Bases, after a certain length of time. The more Bases you control, the more insects you can have spawning at once. After each level you gain a certain number of points you can use between missions to buy new insects. All your previous insects also carry over to the next level. That's the game in a nutshell.
Now the problems. We bought the RTS-SK because we thought it'd give us a good starting point for our game, and for the most part it has. However, this Wednesday we discover that it's missing collision detection in the rtsunits. We figured we'd have to figure out how to do path finding, but we didn't know it didn't come with collision detection. We need the collision detection so we don't have units walking through walla, each other, bases, map objects, etc. One of our levels, for instance, is a sandbox. We've got the sandbox walls that bound the level, and various objects, a shovel, a ball, a sand castle, that exist in the level. Not to mention that we need triggers working to get the bases and various other things implemented.
So, we need some form of collision detection in the game. Then we need some path finding, doesn't have to be perfect, just needs to be decent. And finally a opponent AI. So you know, nothing too big. :|
So where the project stands right now. Most of our units are created, being animated, and being added to the game. The objects are being created and added. The art area of the project is going well. But the programming portion of the game is lacking. Without collision detection implemented, there is a serious limit as to what we can do with the game at this moment. So we're working on trying to add collision detection to the rtsunits. Which is what I'm now trying to do. But I'm severely limited because of my lack of understanding of the Torque Game Engine C++ code, etc. So I'm working through the code and trying to figure stuff out as best I can.
If you have any input, suggestions, criticisms, etc. they would be greatly appreciated! Originally I was hoping that someone(s) had already added collision detection to the rtsunits, but sadly no luck. But anyway, any help anyone can give me would be very helpful and much appreciated!
-Nick
#7
03/05/2006 (1:07 pm)
Well, hang in there and I will have a look tomorrow. I can't promise anything, as I'm no C++ coder, but I've mucked my way through some changes here and there.
#8
buildConvex, findContact, buildPolyList, queueCollision, notifyCollision, onCollision.
One thing that bugs me, is that since RTSUnit is type player already, from:
(
class RTSUnit : public Player
{
typedef Player Parent;
.....
and the collision functions are implemented in player... why doesn't RTSUnit inherit the collision functions from the player class? Is it because they are not declared in the .h, or would I need to copy all of the collision functions and related variables over to the RTSUnit class?
I know this is a basic object inheritance question, but I don't want to copy and past if it's unnecesary.
03/06/2006 (8:43 am)
Ok, I've started looking into this, and earmarked a bunch of Player functions that would need to get implemented in RTSUnit.buildConvex, findContact, buildPolyList, queueCollision, notifyCollision, onCollision.
One thing that bugs me, is that since RTSUnit is type player already, from:
(
class RTSUnit : public Player
{
typedef Player Parent;
.....
and the collision functions are implemented in player... why doesn't RTSUnit inherit the collision functions from the player class? Is it because they are not declared in the .h, or would I need to copy all of the collision functions and related variables over to the RTSUnit class?
I know this is a basic object inheritance question, but I don't want to copy and past if it's unnecesary.
#9
www.garagegames.com/mg/forums/result.thread.php?qt=34401
03/06/2006 (10:38 am)
I just found this post, which was immediately useful:www.garagegames.com/mg/forums/result.thread.php?qt=34401
#10
FYI, link isn't a valid markup tag, but it should look like:
[ url=http://www.garagegames.com/mg/forums/result.thread.php?qt=34401 ] RTS Collision Post[ /url ]
but without the spaces next to the [ and ].
03/06/2006 (6:12 pm)
Great catch...I just got an email from Eric this morning in response to my request about what he did, and he pointed me to that post...came here to link it, and you have it there!FYI, link isn't a valid markup tag, but it should look like:
[ url=http://www.garagegames.com/mg/forums/result.thread.php?qt=34401 ] RTS Collision Post[ /url ]
but without the spaces next to the [ and ].
#11
Ok I tried it. No luck. The units still walk right through each other and other objects.
-Nick
03/06/2006 (6:17 pm)
Hmm... interesting... Has anyone tried it? I'll have to give it a go tomorrow and see. If that works that could be the solusion I've been looking for.Ok I tried it. No luck. The units still walk right through each other and other objects.
-Nick
#13
1) Valador has already demoed this functionality to their commercial customers, and there was a snapshot of the day posted a few weeks (a week?) ago that showed a screenshot of exactly what this project did, and
2) The RTS-SK didn't completely remove collision, we just disabled it due to not having a strong pathfinding/steering implementation to go along with it.
Now, I will say that Eric is one of the most capable Torque engineers I know, and he may have glossed over a few things that probably appeared trivial to him but might not be obvious at first glance (please note that isn't intended as a slight to anyone on the forums: I personally spent a while trying to get collision activated myself and didn't have much luck either--Eric is really that good is all I'm saying!)...hopefully if he gets some time he can flesh it out a bit more in detail, or others can take up the challenge. Honestly, I wish I had time myself to get back to work on this given his leads, but boot camp and GDC (plus a commercial custom training session next week) has me tied up from now until April :(
Stephen
03/06/2006 (11:13 pm)
Actually, it could!1) Valador has already demoed this functionality to their commercial customers, and there was a snapshot of the day posted a few weeks (a week?) ago that showed a screenshot of exactly what this project did, and
2) The RTS-SK didn't completely remove collision, we just disabled it due to not having a strong pathfinding/steering implementation to go along with it.
Now, I will say that Eric is one of the most capable Torque engineers I know, and he may have glossed over a few things that probably appeared trivial to him but might not be obvious at first glance (please note that isn't intended as a slight to anyone on the forums: I personally spent a while trying to get collision activated myself and didn't have much luck either--Eric is really that good is all I'm saying!)...hopefully if he gets some time he can flesh it out a bit more in detail, or others can take up the challenge. Honestly, I wish I had time myself to get back to work on this given his leads, but boot camp and GDC (plus a commercial custom training session next week) has me tied up from now until April :(
Stephen
#14
If you look above, I saw that the collision functions were there in player.cc, but weren't implemented in rtsunit. They usually hook into updateMove, updatePos, and/or processTick for player class, and RTSUnit class doesn't use updateMov or updatePos, it replaces those basic functions in processTick.
What he did essentially was disable some of the basic routines in RTSunit processTick and override them with the player class equivalent. Because RTSUnit inherits player class, this seemed like it could work. It's exactly what I was trying to do, and wasn't sure how. The fact that it was so easy just means I know less about object inheritance than I thought!!
You could also take a *good* look at what he did and use it to model any other changes with collision that you need.
03/07/2006 (6:07 am)
Yes, I did try it before posting the link, and it gives some immediate collision.If you look above, I saw that the collision functions were there in player.cc, but weren't implemented in rtsunit. They usually hook into updateMove, updatePos, and/or processTick for player class, and RTSUnit class doesn't use updateMov or updatePos, it replaces those basic functions in processTick.
What he did essentially was disable some of the basic routines in RTSunit processTick and override them with the player class equivalent. Because RTSUnit inherits player class, this seemed like it could work. It's exactly what I was trying to do, and wasn't sure how. The fact that it was so easy just means I know less about object inheritance than I thought!!
You could also take a *good* look at what he did and use it to model any other changes with collision that you need.
#15
You might not see some collision on objects that don't have collision meshes. The units that are in RTSKit don't seem to have collision meshes. Try walking through a building. I'm not sure what the difference is in terms of collision, but there *is* a difference.
I can see that the datablocks for both buildings and units have bounding boxes defined, and they both are type RTSUnitData. I just checked the .DTS for the foundry, and no collision mesh seemes to be defined.
Still looking...
[edit]
Ok, hehe the units don't move through each other at all, thought I did see this yesterday, but they definitely COLLIDE! At the defined bounding boxes too. The only problems I see now are related:
1) You don't see selection circles on the units above certain z-locations
2) The z-locations of the units are messed up. that part of the code in processTick was disabled in order to make the collisions happen, so you can mess around with the z-position code, write your own based on the disabled code, or look into Player::updatePos to figure out why Z locs aren't working.
So aside from z-loc side-effect, the collision is now working....
03/07/2006 (6:09 am)
Nick-You might not see some collision on objects that don't have collision meshes. The units that are in RTSKit don't seem to have collision meshes. Try walking through a building. I'm not sure what the difference is in terms of collision, but there *is* a difference.
I can see that the datablocks for both buildings and units have bounding boxes defined, and they both are type RTSUnitData. I just checked the .DTS for the foundry, and no collision mesh seemes to be defined.
Still looking...
[edit]
Ok, hehe the units don't move through each other at all, thought I did see this yesterday, but they definitely COLLIDE! At the defined bounding boxes too. The only problems I see now are related:
1) You don't see selection circles on the units above certain z-locations
2) The z-locations of the units are messed up. that part of the code in processTick was disabled in order to make the collisions happen, so you can mess around with the z-position code, write your own based on the disabled code, or look into Player::updatePos to figure out why Z locs aren't working.
So aside from z-loc side-effect, the collision is now working....
#16
03/07/2006 (8:36 am)
Oh I thought the collision code was gone not just disabled that would explain it.
#17
If this works *crosses fingers* then you've all helped me a HUGE amount! Even if it doesn't work you've all helped me a huge amount! lol
Thanks Again!
-Nick
03/07/2006 (11:05 am)
Ok cool! I'll have to take a better look at it. I made the changes and tested it out really quick and it didn't seem to work. I'll take a better look at it. Unfoturnituly I don't have the time till later this week. Part of the project's due Wenesday and I'm busy working on it. I'll take a closer look at it towards the end of the week.If this works *crosses fingers* then you've all helped me a HUGE amount! Even if it doesn't work you've all helped me a huge amount! lol
Thanks Again!
-Nick
#18
It *will* work! Tested and verified. But... post any troubles you run into...
Stephen-
Have fun at GDC and the training and bootcamp! If it's any consolation, I would gladly do any of those things instead of the application, database and web development :) Speaking of which, maybe I should get back to work....
03/07/2006 (11:19 am)
Nick-It *will* work! Tested and verified. But... post any troubles you run into...
Stephen-
Have fun at GDC and the training and bootcamp! If it's any consolation, I would gladly do any of those things instead of the application, database and web development :) Speaking of which, maybe I should get back to work....
#19
03/08/2006 (8:25 am)
Ok I think you just need to send a ray from the units position to his destination, that way you can find objects in the way and find a path around them.
#20
03/08/2006 (8:33 am)
Robert, In principle that might be good, but what happens when there is a traversable hill between the unit and his destination?
Torque 3D Owner Dave Young
Dave Young Games
I haven't done it, but I would check out the differences between a default 1.4 player.cc and rtsunit.cc. This will show you the differences made for RTS. I see a lot in packUpdate and unpackUpdate.