Noob Question
by Dina Adams · in Torque Game Engine · 08/12/2005 (3:22 pm) · 38 replies
I'm using the RTS starter Kit, and I want to create and update the position of units programatically based off information in a database. I just trying for a quick hack right now, it doesn't need to be an elegant solution, and it doesn't need to work multiplayer. I was thinking about puting my update calls in main.cc inside of DemoGame::processTimeEvent. Does this seem like a reasonable place to put a database querry for positional updates?
Also, how do I define a bot programatically so that it will still play nice with the mini-map and selection controls? I know I need to create a dataBlock for it, and I'm thinking I would need to add it to the system using Container::addObject, although I'm not sure on that one. I also don't know which object the bot is... Is it an instance of player.cc? Even in the RTS where a single player has multiple units?
TIA
Also, how do I define a bot programatically so that it will still play nice with the mini-map and selection controls? I know I need to create a dataBlock for it, and I'm thinking I would need to add it to the system using Container::addObject, although I'm not sure on that one. I also don't know which object the bot is... Is it an instance of player.cc? Even in the RTS where a single player has multiple units?
TIA
#22
08/23/2005 (9:57 am)
I'm sure. Unfortunately my company spent a bunch of money on several commercial copies of this package, with the concept that we would be able to do rapid prototyping with this engine, and I'm the one on the hook to do it. I'm already behind schedule, and I've been given another two weeks to get this done. A rapid prototype in our world is 2 to 4 weeks working at .25 time, so really 5 or 6 days spread out, and it seems like this is not as simple a task as people expected, which means I'm the one who's going to be on the firing range. I am very used to working with legacy code. I do that on a regular basis, but even in our 2 week throw away prototypes we have lots of comments in the code. I'm not used to totally uncommented code (one of the selling points for us buying the engine was the "full code documentation created right from the code using...." which turns out to just be a bunch of function headers. Kind of a joke. And this is a really large project to weed through considering there isn't even a simply architecture diagram. BTW, I was serious in my question. I don't see GuiMapHud anywhere in the project. Where is it?
#23
08/23/2005 (10:15 am)
BTW, of course I am running in Debug mode. I would have to be pretty brain dead not to. And sure I can spend the next month trying to trace every code path, but I don't really have that sort of time. I was hoping someone would be able to look at my code and say, "oh no wonder why, you aren't setting the X data field properly", or something like that, but its seems that the guys who wrote the code aren't the same as the guys who sell and support the code, so I guess I'm SOL :( I guess I'm the only one who is really looking at this part of the code :( It seemed like it would be a common thing people would want to do with the code, but I guess I was wrong.
#24
Save yourself the headache and realize there is no way you'll have a prototype ready in two weeks from ground zero. Two weeks might be more realistic if you were familiar with the code base, but going from brand new torque programmer to completed prototype in 2 weeks.. That's insane!
My advice for you www.monster.com.. You've got 2 weeks! Get surfing! LOL
B--
08/23/2005 (10:39 am)
If I had the RTS kit I'd try and help you, but I don't. I was kind of shocked reading your post. Does your company have any experience in the field? Seems a bit naive to assume you can throw a full blown game engine into the lap of a programmer who has spent little to no time with it, and expect you to walk on water or something.Save yourself the headache and realize there is no way you'll have a prototype ready in two weeks from ground zero. Two weeks might be more realistic if you were familiar with the code base, but going from brand new torque programmer to completed prototype in 2 weeks.. That's insane!
My advice for you www.monster.com.. You've got 2 weeks! Get surfing! LOL
B--
#25
08/23/2005 (10:45 am)
LOL. Well we did it with Ogre3D pretty easily, so I guess we were thinking this would be similar, but its really a different animal. The Ogre3D engine is built to be modified by programmers, while this engine is built to be modified by artists... We did it with the old quake engine too... Actually we've done that sort of thing quite a few times, but always with engines built for programmers, not artists. And Torque is really a big engine in comparison to most of the graphics engines I've worked with in the past. I mean I wrote a whole 3D engine from scratch in two weeks using OpenGL, but when you're trying to muck through 1000s of files with no idea whats up from down it just gets plain frustrating.
#26
B--
08/23/2005 (11:55 am)
I agree, I also found it difficult at first to wrap my head around this engine. For me it was the fact that so much of a framework was already there. I was more used to dealing with a core API vs a working skeleton. The good news is that it does sink in after a little while, and is quite enjoyable to work with after that.B--
#27
08/23/2005 (11:58 am)
Yeah. I think thats the core of the problem. Its a huge working skeleton, but somehow they managed to avoid writing a single line of comments in their whole implementation :( Even just one simple class document would have gone a long ways in helping people see how this whole thing fits together. It seems somebody was snoozing during their software engineering classes ;)
#28
You stated that you want to create units "programatically", which is done with just a few lines of script in /server/scripts/core/gameConnection.cs, in the function RTSConnection::onClientEnterGame(). The example code there creates 16 units in a small square, iterating over the 3 stock unit types provided with the starter kit. As you can tell by the code, you don't need to change a single line of source code to do this type of thing, but you certainly can.
There is also a very large mod available as a resource for the RTS-SK, which demonstrates a large amount of more advanced unit, building, resource manipulation, and other RTS genre functionalities, which is written entirely in script. It shows some additional techniques on how to dynamically create RTSUnits of whatever type you wish.
Updating unit positions is slightly more tricky, since you imply that you want them to both maintain their 'selectable' status as player controlled RTSUnits, but also do positional updates based on database value changes. My suggestion here would be to write a script function that receives the update notification from the database, uses whatever indexing information you've stored for the unit you've created (object ID in a hash table of some sort sounds like a good initial implementation), and then change the moveDestination persistent field of that particular unit, and let the tick processing system handle the rest. That way the unit will start to move to the updated position, but will also be able to have the move destination changed by the player if they elect to do so.
Regarding the documentation questions/concerns that you have, you may note that a large majority of the documentation is in the header files for most of the core classes. I'll readily admit that the RTS-SK could have been better documented in the source, but there is an extremely helpful private forum area dedicated to the RTS-SK itself, with a wealth of information. To access these forums, go to the nav bar on the left of this web page and click on the "Edit Subscriptions" link, and scroll down until you find the RTS-SK private forums, and select them.
Finally, you are correct...it is a completely different style of development using Torque--Torque isn't a set of libraries or a rendering engine like the products you've used in the past, but a fully functional networked simulation. It takes time to recognize and learn to use the massive amounts of functionality that exists, as well as to be able to research and determine when you need to implement new functionality.
Dina: I noted that you didn't populate your profile information, so I wasn't able to send you an email. If you would, please contact me at stephenz-at-garagegamesdotcom so we can get a better feel for your needs to get you over this short term stumbling block.
Stephen Zepp
Torque Education and Commercial Support Director
EDIT: Should learn to spell my own name!
08/23/2005 (3:09 pm)
Honestly, I think you are making this a lot more complex than it needs to be:You stated that you want to create units "programatically", which is done with just a few lines of script in /server/scripts/core/gameConnection.cs, in the function RTSConnection::onClientEnterGame(). The example code there creates 16 units in a small square, iterating over the 3 stock unit types provided with the starter kit. As you can tell by the code, you don't need to change a single line of source code to do this type of thing, but you certainly can.
There is also a very large mod available as a resource for the RTS-SK, which demonstrates a large amount of more advanced unit, building, resource manipulation, and other RTS genre functionalities, which is written entirely in script. It shows some additional techniques on how to dynamically create RTSUnits of whatever type you wish.
Updating unit positions is slightly more tricky, since you imply that you want them to both maintain their 'selectable' status as player controlled RTSUnits, but also do positional updates based on database value changes. My suggestion here would be to write a script function that receives the update notification from the database, uses whatever indexing information you've stored for the unit you've created (object ID in a hash table of some sort sounds like a good initial implementation), and then change the moveDestination persistent field of that particular unit, and let the tick processing system handle the rest. That way the unit will start to move to the updated position, but will also be able to have the move destination changed by the player if they elect to do so.
Regarding the documentation questions/concerns that you have, you may note that a large majority of the documentation is in the header files for most of the core classes. I'll readily admit that the RTS-SK could have been better documented in the source, but there is an extremely helpful private forum area dedicated to the RTS-SK itself, with a wealth of information. To access these forums, go to the nav bar on the left of this web page and click on the "Edit Subscriptions" link, and scroll down until you find the RTS-SK private forums, and select them.
Finally, you are correct...it is a completely different style of development using Torque--Torque isn't a set of libraries or a rendering engine like the products you've used in the past, but a fully functional networked simulation. It takes time to recognize and learn to use the massive amounts of functionality that exists, as well as to be able to research and determine when you need to implement new functionality.
Dina: I noted that you didn't populate your profile information, so I wasn't able to send you an email. If you would, please contact me at stephenz-at-garagegamesdotcom so we can get a better feel for your needs to get you over this short term stumbling block.
Stephen Zepp
Torque Education and Commercial Support Director
EDIT: Should learn to spell my own name!
#29
On the down side, frozen custard is Vastly Superior to frozen yogurt. Do yourself a favor and track some down as soon as possible.
Sadly www.google.com/search?hl=en&lr=&c2coff=1&q=frozen+custard+eugene+oregon&btnG=Sea... didn't turn up much. But good luck to you.
08/23/2005 (4:14 pm)
@Ben: You sir, are one disturbed individual. The world is a brighter place with you in it.On the down side, frozen custard is Vastly Superior to frozen yogurt. Do yourself a favor and track some down as soon as possible.
Sadly www.google.com/search?hl=en&lr=&c2coff=1&q=frozen+custard+eugene+oregon&btnG=Sea... didn't turn up much. But good luck to you.
#30
Here's a good place to start:
In your Visual Studio project, look in the game folder, then scroll allll the way to the bottom and open up the RTS folder. That's the code you should be concentrating on at first. It's pretty well documented and is at the crux of your project.
The search on this website is driven by a Google box, so use the normal Google style searching. If you want to find something in code, use the Visual Studio search (CTRL-SHIFT-F), and change the "Look in" to include RTSStarterKit\engine and RTSStarterKit\example, and make sure you include *.cc, *.h, *.cs, *.gui, *.mis when you're searching everywhere... obviously limit to *.cs, *.gui, *.mis if you want to find something in script, etc.
Scripts are grouped into three categories... client, server, data. Most of your scripting will probably take place in server.
To answer the questions that haven't been answered... in the Game/RTS folder, guiMapHud*.* are files you should concentrate on for the MiniMap code. I think the script portion is in example/starter.RTS/client/scripts/mapHud.cs, but there's really not much to see in there.
For moving, I'd look at rtsConnection.cc , but I'd also look at AIPlayer.cs for an example of how to queue tasks. Now, that's not exactly the right way to do it with the RTS kit (it'd probably be better to modify the RTSUnit class to send a RTSEvent for when it's reached it's destination so a new destination could be programmed.
There's also a A* pathfinding resource that's recently been posted that you might want to use. The default pathfinding isn't that great.
Good luck.
Edit: Oops, AIPlayer isn't part of the RTS starter kit... make sure you download the main Torque code too... it has the FPS starter kit in it and is a good resource. AIPlayer.cs is in there.
08/23/2005 (4:16 pm)
@Dina: Wow, you really don't sound like you're enjoying your job... sorry. I'd have to disagree about the documentation... some of the code isn't documented, granted, but the RTS stuff is well documented (except maybe the RTSConnection class).Here's a good place to start:
In your Visual Studio project, look in the game folder, then scroll allll the way to the bottom and open up the RTS folder. That's the code you should be concentrating on at first. It's pretty well documented and is at the crux of your project.
The search on this website is driven by a Google box, so use the normal Google style searching. If you want to find something in code, use the Visual Studio search (CTRL-SHIFT-F), and change the "Look in" to include RTSStarterKit\engine and RTSStarterKit\example, and make sure you include *.cc, *.h, *.cs, *.gui, *.mis when you're searching everywhere... obviously limit to *.cs, *.gui, *.mis if you want to find something in script, etc.
Scripts are grouped into three categories... client, server, data. Most of your scripting will probably take place in server.
To answer the questions that haven't been answered... in the Game/RTS folder, guiMapHud*.* are files you should concentrate on for the MiniMap code. I think the script portion is in example/starter.RTS/client/scripts/mapHud.cs, but there's really not much to see in there.
For moving, I'd look at rtsConnection.cc , but I'd also look at AIPlayer.cs for an example of how to queue tasks. Now, that's not exactly the right way to do it with the RTS kit (it'd probably be better to modify the RTSUnit class to send a RTSEvent for when it's reached it's destination so a new destination could be programmed.
There's also a A* pathfinding resource that's recently been posted that you might want to use. The default pathfinding isn't that great.
Good luck.
Edit: Oops, AIPlayer isn't part of the RTS starter kit... make sure you download the main Torque code too... it has the FPS starter kit in it and is a good resource. AIPlayer.cs is in there.
#31
I think Stephen has covered most everything there is to cover on GG's official stance. I will add this - a good find in files utility will save you loads of pain. I actually found GuiMapHud by using Visual Assist, which is an awesome program, but you can get the same effect by using the class view in Visual Studio, or any find in files utility (grep, wingrep, the find in files in textpad, etc. etc. etc.).
If you're trying to modify the engine source, be prepared to have to read and understand it. :) You're trying to do something that's normally done from script, so naturally it's going to be a little tougher than it would otherwise be.
Best of luck getting your project done, and naturally, I'm sure that Stephen would be delighted to get in contact with you as a commercial user of Torque.
Ben
08/23/2005 (4:17 pm)
Dina,I think Stephen has covered most everything there is to cover on GG's official stance. I will add this - a good find in files utility will save you loads of pain. I actually found GuiMapHud by using Visual Assist, which is an awesome program, but you can get the same effect by using the class view in Visual Studio, or any find in files utility (grep, wingrep, the find in files in textpad, etc. etc. etc.).
If you're trying to modify the engine source, be prepared to have to read and understand it. :) You're trying to do something that's normally done from script, so naturally it's going to be a little tougher than it would otherwise be.
Best of luck getting your project done, and naturally, I'm sure that Stephen would be delighted to get in contact with you as a commercial user of Torque.
Ben
#32
I well aware of the AIPlayer class, and the location of the different scripts, and the Crtl-F functionality in VC6, and I would think it would be obvious from my code snippets that I have pulled most of it from RTSConnection::onClientEnterGame(). BTW, AIPlayer is part of the RTS kit, that was where I first started to try and look through the code.
I don't have event access from the db, and am just pulling from it, and I was planning to just do it on a timer in the processtick function. Its a very small db, so I don't forsee problems with that. And I really don't think this should be a big task, thats why I'm so frustrated. I pretty much just need to get past the sticking point of actually creating units in the main.cc class that will show up on the map and mini-map. I'll try contacting Stephen directly. Maybe he can help me get through that chunk of code.
08/24/2005 (8:17 am)
Thanks for the replies. I well aware of the AIPlayer class, and the location of the different scripts, and the Crtl-F functionality in VC6, and I would think it would be obvious from my code snippets that I have pulled most of it from RTSConnection::onClientEnterGame(). BTW, AIPlayer is part of the RTS kit, that was where I first started to try and look through the code.
I don't have event access from the db, and am just pulling from it, and I was planning to just do it on a timer in the processtick function. Its a very small db, so I don't forsee problems with that. And I really don't think this should be a big task, thats why I'm so frustrated. I pretty much just need to get past the sticking point of actually creating units in the main.cc class that will show up on the map and mini-map. I'll try contacting Stephen directly. Maybe he can help me get through that chunk of code.
#33
The dOxygen documentation on SimObject is pretty detailed regarding the underlying things you have to do.
Regarding your db access, I personally still wouldn't be modifying the polling loops in main.cc whatsoever--instead, I would implement a new object class derived from GameBase, and implement the db tests as part of your processTick(). Alternatively, if you have the ability to have a stand-alone application that can watch for db events and package up any notifications that your Torque simulation will need, you can isolate even further and have this standalone application send updates via TCP/IP to a Torque TCPObject within your sim.
As a couple of people mentioned above, you can either work with Torque's systems, or work against them! As a fully functional simulation, successful Torque projects are normally ones that work with the systems that are already available...and that's how you can do extremely rapid prototyping. Trying to re-create things from scratch will not only take longer in total implementation time, but will also cause frustration as you run into design differences from your personal implementation and possible conflict against the underlying Torque systems.
08/24/2005 (9:56 am)
If you -really- need to create the units in c++, then you'll need to study the requirements associated with registering your objects within the simulation (SimObject functionality), as well as making sure that all of their persistent fields are populated properly so that the higher level functionality (teams, visibility, etc.) are all taken care of as well.The dOxygen documentation on SimObject is pretty detailed regarding the underlying things you have to do.
Regarding your db access, I personally still wouldn't be modifying the polling loops in main.cc whatsoever--instead, I would implement a new object class derived from GameBase, and implement the db tests as part of your processTick(). Alternatively, if you have the ability to have a stand-alone application that can watch for db events and package up any notifications that your Torque simulation will need, you can isolate even further and have this standalone application send updates via TCP/IP to a Torque TCPObject within your sim.
As a couple of people mentioned above, you can either work with Torque's systems, or work against them! As a fully functional simulation, successful Torque projects are normally ones that work with the systems that are already available...and that's how you can do extremely rapid prototyping. Trying to re-create things from scratch will not only take longer in total implementation time, but will also cause frustration as you run into design differences from your personal implementation and possible conflict against the underlying Torque systems.
#34
I don't think I'm really working against the system, I'm just trying to figure out how to use the system. The network approach might work ok, but I had to strip out most of that stuff for security reasons, so I've been staying away from that one. I was really just looking for someone to tell me what was wrong with the code chunk I created for creating an RTSunit. If no one knows how to do this, I guess I'll just have to figure it out, and then I'll be the only one. Maybe you guys can hire me to do your support then ;)
08/24/2005 (11:38 am)
I misspoke in my previoius email. I was planning to use the processTick() in GameBase. There isn't actually a process tick in main.cc I don't think I'm really working against the system, I'm just trying to figure out how to use the system. The network approach might work ok, but I had to strip out most of that stuff for security reasons, so I've been staying away from that one. I was really just looking for someone to tell me what was wrong with the code chunk I created for creating an RTSunit. If no one knows how to do this, I guess I'll just have to figure it out, and then I'll be the only one. Maybe you guys can hire me to do your support then ;)
#35
I would think your problem could be solved in a similar manner. If you're not already using the 'enhanced debugger' and Torsion, or TDEV, I would recommend that as well to understand the scripting side of things. When I started stepping through script one line at a time, everything started making sense. I also used the step line script debugger to help trace down what C++ routines are getting called, and when. Quite useful!
B--
08/24/2005 (12:43 pm)
I've never looked at the RTS kit, but I did a similar thing creating dts shape objects from C++ instead of script. I just had one line of script call my C++ routine to do all the work. I figured out what to call in C++ by tracing down what C++ routines were called when Torque Script created an object.I would think your problem could be solved in a similar manner. If you're not already using the 'enhanced debugger' and Torsion, or TDEV, I would recommend that as well to understand the scripting side of things. When I started stepping through script one line at a time, everything started making sense. I also used the step line script debugger to help trace down what C++ routines are getting called, and when. Quite useful!
B--
#36
You may want to use the console tree(); function to see if you are getting the unit created and registered with the simulation properly, and then progress from there--it will help to narrow down where any issues may still lie.
08/24/2005 (12:43 pm)
Well as I mentioned, the problem is that you are using a tactic that isn't recommended, so it's difficult to determine exactly what the difficulty is! As I mentioned in the email, I'm starting to think that the issue might be a vis manager one, in that you aren't seeing the unit because you aren't on the right team, and therefore it isn't being sent to the client side of the process.You may want to use the console tree(); function to see if you are getting the unit created and registered with the simulation properly, and then progress from there--it will help to narrow down where any issues may still lie.
#37
08/25/2005 (9:59 am)
What is this "tree()" you speak of? 
#38
You should now see a gui control tree of the objects.
08/25/2005 (10:10 am)
Run Torque, open the console and type "tree();" and press enter.You should now see a gui control tree of the objects.
Torque 3D Owner Brandon Maness
@Dina: I didn't get that from the post at all. I think it's just Ben getting creative with a concept of discovery that has been emphasized many times in this community, but seldom sinks in. You're not stupid, or slow; this stuff is not easy, everyone struggles with it especially at first, but I'm sure you'll eventually get it! Just keep at it.
B--