Collision,triggers and updates to RTS

#1 Collisions are currently disabled due to AI requirements (collision adds a slew of requirements for path finding, contact/collision resolution, etc). I would assume that since collision itself is bypassed, that may be affecting triggers as well.

I know that Josh is very very close to a fully working AI that will allow collision, but it's not quite finished yet, and they didn't want to delay the pack release for it specifically.

#2 First, welcome to Torque! It's great to see people picking up the engine and playing with the RTS SK right away. Are you planning on making a game, just checkin stuff out / learning, or something else? In any case, welcome aboard.

Next, thanks for the question. Helps to get a lot of these questions out there and answered quickly. It's Saturday night and I'm on personal time, so I'll take a chunk of time here and do a long-winded post in reply. :)

The RTS SK definitely isn't beta. :) It is a "starter kit" though, which means it doesn't implement every feature under the sin. A lot of what you see in the code comments or out in the forums reflect the fact that the RTS SK doesn't do every possible thing that an RTS game could do. There are tons more features and whatnot that we could've provided and that I'm sure people would want. However, incorporating everything we possibly could've would mean that the kit wouldn't be done for a year, and it'd cost $500 when it was finished :)

So, we tried to pick truly the core features that the largest number of people would need to create strategy / RTS-style games, and we tried to implement them in such a way that people could easily customize, change, or extend our way of doing things as they saw fit for their game design.

As to AI stuff, I'm not sure whether I'll release it or not, and I'm so busy that it definitely won't be any time soon if so. I certainly want to release it, but I have to be realistic about how much time I have to devote to polishing it.

To answer the original question, the RTSUnits don't have a collision scheme. Triggers rely on collisions, so they don't work in the stock RTS SK (with RTSUnits). Thanks for pointing this out to people. :)

If you want to get them working, you can, but it might be something to wait on until you're more familiar with Torque.

If you want to take a crack at it, there are at least four approaches you might consider:

---------------------------------

1) Hack away. :) If what you want is the ability to define areas in a mission that trigger events... you could just script a check to determine if units enter into specific hotspots that you define. Hacky, but it'll get you where you want to be quickly and easily.

2) Take the above a step further and create an custom Trigger-like object which works with RTSUnit position changes, instead of the collision system. To do so, you can check out and adapt the default Trigger class' code. If you feel comfortable with C++, you should pretty quickly see how to adapt it to simply work on RTS unit updates as opposed to relying on collision info. You'd define the overall structure and interface similarly, with an internal vector list of objects inside the trigger area, and methods to test whether objects are inside, add them to the list of objects inside, and, remove objects from the list when they exit the trigger area, etc, complete with script callbacks as per the standard Trigger class.

I don't mean to trivialize the work involved there... it's pretty easy to see how to create a custom Trigger class like this, but I'm not trying to say actually doing it would be a total breeze. Especially
if you're brand-new to Torque, I'm not saying this'll be a quickie.

(continued...)

#3 3) You could implement generalized collision on RTSUnits, using a simplified system. Most RTSs really don't need full-on Torque-style collision on their units. If they do need collision at all, it's usually just radius-based collision detection, perhaps sweeping the collisions for networked games or fast objects. But most RTSs probably don't even worry about tunnelling like that. Implementing such a system could work with either of the above options for triggers.

4) Enable standard collision on RTSUnits. RTSUnits already have bounding boxes, and you can query the standard SceneObject collision information as-is. Incorporating full ShapeBase-style collision is also possible. Matt Fairfax made a great tuturial for creating collidable objects in Torque that will be useful to you, if you go with anything along this route.

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). If your design requires quite detailed collision, but less complex than what Player offers, the Item class actually has simpler collision processing. Depending on your game design, it could make more sense to pull collision code from there (/engine/game/item.h, item.cc, shapecollision.cc). This really depends on your game design... how many units you want to have, and how accurate their collisions need to be.

-----------------------------

As you can see, the decision about whether and how to incorporate collision with the RTS SK isn't as simple as it sounds. One thing is for sure: the reason it's out is not because we just didn't have time or didn't care. We thought about all of this very carefully, and we hope we made the best overall decision. We could've included a default collision scheme in the RTS Starter Kit, but then, I promise, I'd be here providing a similarly detailed explanation of why we chose the collision scheme we did, even though it's either total overkill / performance-drain or total underkill / not-robust-enough for somebody's particular game design. :)

If we were going to include one particular collision style in the RTS SK, it would probably be option #3 above, because that's what most RTS games do. However, a lot of different game styles can fall under the category of "RTS" and we absolutely do not want to encourage or force people to follow the typical, over-done, seen-it-a-billion-times RTS game design by including design-specific implementations.

We created and market a "Starter Kit" because it is just that.. a place to get started. The RTS SK gives a place to start building an actual game from. We cover the generic stuff you need, and try to make it easy and clear to hook in custom stuff. For design-specific things, you'll certainly have to do some custom work, but we try to minimize the amount of work there, and make it as clean as possible when you have to add stuff in.

Hope that helps a little bit. I know you were just asking about triggers, but the discussion seemed to be heading toward a more general discourse. Thanks as well for the offer to beta test any future updates, we'll keep it in mind. :)

As for future updates, they'll appear in your My Garage at first, and hopefully we'll set-up a CVS server for RTS SK owners soon.

By the way, I hope none of the above comes off like I'm upset that you asked the questions you did or anything. They are completely valid, and I'm glad to have the opportunity to explain this stuff in detail. Thanks for picking up the RTS kit, and good luck with your project. As you can see, the forums here are already flowing with good information, and it's barely been a week since they started.

#4 Wow Josh, thanks !!! (especially for taking personal time, I know how that is).
Long winded but very informative (appreciated also !!!). I think all I really need is the simplified version that checks to see if a unit is within another units visibility or firing range. (have a need to have buildings or base defenses (AI) defend against units), almost sounds like the visibility code may be able to play a role.

If you do not decide to release the AI into the RTS kit please consider releasing it as sample / knowledge base code (I know its early for a decision like that) but the more we have to look at the easier it is....

Again, thanks, I'll be hacking away.....

#5 Would that simplified version (method 3 outlined above) include collision checks between DIF structures. I am quite new to Torque, and have not enough C++/C experience to modify the engine much, and would like to know how difficult it would be to have units able to collide with DIF structures. For example in a game I am thinking of developing I would like to be able to have units walk across the occasional bridge over a river which would be a DIF model.

Can anyone suggest a work around solution for something like this?

#6 Without trying to throw cold water on your idea (it's a good one!), the difficulty is not really with the collision aspect at all, but with the pathfinding to be able to have the units move with some concept of intelligence across the bridge.

For example, to use something like this, you would basically have to guide each and every unit (and not a formation of units, I mean each unit within the selection group) across the bridge by hand, due to the lack of current path node generation. Since the two ideas are basically "do both or neither, but not just one!", I think that the ai pathfinding side is the more "critical path" of the two (obviously--as Josh mentioned, all of the stock collision stuff is available).

#7 Thanks, I hadn't thought of it like that. Hopefully it won't be too long before some kind of ai module is released for the RTS pack.


Does that mean that physical zones do not function at the moment either?

#8 I can neither confirm nor deny that there will be a pathfinding resource available eventually for the RTS SK. Ahem.

Take that for what it's worth!

I honestly don't know about physical zones, mostly because I've never messed with them! I know that triggers do not work out of the box, but since they don't actually have collision avoidance to worry about, they can be activated with little pathfinding issues.

#9 Was this the final word? No collision included?

#10 There is a full out re-write of the vis Manager in development right now, with extensibilty of the algorithm to be able to handle high performance collision detection/avoidance easily set up once the binning system gets fully debugged. I can't give any promises on timelines, but we do plan on being able to give demonstration code for a way of implementing higher performance collision handling for the RTS-SK in the future!

#11 Stephen you make my job to easy

#12 Wow ask and ye shall receive. Wonderful response, thank you!

#13 Any chance it is released within the upcoming 1 or 2 months? :)

#14 @Rutger it's doubtful that the entire system will be ready by the end of the summer, but depending on progress we may be able to release an alpha of the bin system and vis manager for extended testing.

One of the reasons that it is taking so long (and will appear extremely complicated at first glance) is that the system is designed to be completely asynchronous...with the intent that making it threadsafe in the future should be trivial. However, that adds some pretty hefty complexity to the design, so we want to make sure we are doing things right!

#15 I understand - it's just that i'm trying to make a game-prototype/demo for my Masters Project here in the UK and it has to finished by September. So i'm currently trying to draw out what can be implemented by then =)

#16 Wow ask and ye shall receive. Wonderful response, thank you!

#17 I havn't given pathfinding much thought yet. My initial thoughts on collisions, however, would be to use, for lack of a better term, "multiple radius" based collion processing. Using a wider radius to warn the unit that it's about to collide with another object and the smaller as the actual collision event. Am I thinking in the right direction?

#18 So I just have one very large waterblock, and a very detailed ship hovering over the water (Very Similar to Cruise Ship Tycoon). When I dropped the units over the deck, they fall right through and down into the water.

To solve this problem, I made the water very shallow and set the mHoverHeight of all the units so that they hover far enough above the terrain so that they are up out of the water and appear to be walking on the deck. Unfortunately the selection circles still appear on the terrain, deep under the water. At first I thought this was a collision problem. I thought that with collision the units could stand on top of the ship. However, it is also due to the fact that the units do not use a z coord, and are bound to the terrain.

Any ideas how to have my units stay above the deck? Or as someone above asked, have them walk over a bridge without falling through the bridge and water.

I may also need some simple collision detection to keep the units from walking through each other as they traverse my waypoints.

#19 This is more than just height/collision, they would also have to move with the ship, almost like a mounted object does.

I would probably look at processTick and grab from a datablock or dynamic variable the id of the ship they are on, then use that object's position as the base translation for the object's position.

I'm not sure if the player class has built-in functionality for things like moving/sliding platforms, but the functionality you are looking for is the same concept.

#20 BTW, the code that moves the player to the ground can be found in RTSunit.cc, processTick, in the PROFILE_START(RTSUnit_Z) section.