RTS Pack Integration to existing code comments
by Stephen Zepp · in RTS Starter Kit · 11/14/2004 (2:26 pm) · 8 replies
Well, in true EA tradition, Greg and I crunched the hell out of this weekend. Pretty much since I grabbed the pack at 3PM on what was it, Thursday? (it's been a blur), I've been eating, breathing, sleeping, dreaming, and drinking TGE and RTS.
We're 90% finished with the integration. Our project has made some major changes from stock, mostly in the direction of directory management and client/server separation (we have two completely different SVN repositories, one for server-env and one for client-env, each drawing common resources such as art and mission info from an external SVN module repo, as well as a source code repository that only licensed team members have permissions for).
--As an aside, if anyone is interested in discussing repository organization strats for a medium sized project, some with licenses and some without, we are relatively happy with how Greg set it up with, of course, the exceptions noted below.
On the whole, I would say that at least 90% of the "difficulty" (and it wasn't really difficult at all for experienced TGE developers--which we aren't quite yet) was related to decisions we had made previously regarding directory structure, trying to re-work the login sequence to be more appropriate for a persistent server, and resolving conflicts in functionality and design between the Pack and our code.
The pack itself was pretty much a breeze to integrate--I was very happy to see not only did it keep things as separate as possible from stock TGE code, but it even expanded the "starter kit" mentality to be a decent to strong stucture to build projects off of.
For example, in stock TGE, your directory structure (even though it looks really complex) actually is a touch primitive, especially down at the bottom of trees. All scripts are set in one directory, all images, regardless of what they are for are in another (single) directory, etc. The pack did a very nice job of breaking things out in a more modular directory structure, which was nice to see.
The 10% of the "difficulty" can be listed in one word: paths.
Right up front, I don't have a solution for the issues we ran into, so don't take this as a criticism, just something that I hope gets handled better (or at least documented better) in the future--maybe TSE, maybe other packs. In general, paths are hard coded -everywhere-. At one point in the process I was doing a "search in files" for './', it was that difficult to nail them all down. Unfortunately, with the current implementation/techniques of how paths are used in torque to point to files, and the relatively stringent structure created by stock TGE, it was a royal pain to catch each and every issue.
It got especially bad towards the end, when dealing with the MainChatHud/ChatHud stuff, because instead of getting "missing texture/missing file" in the console, we were getting a very uninformative fatal assert (guiScrollCtrl.cc, line 90: AssertFatal(result, "Failed to create the bitmap array");
). I know that as a developer that's done the exact thing I am critiquing now, this assert was probably pretty useful to the coder that first wrote/debugged this code, but it was pretty frustrating to someone that wasn't familiar with that section of the code--ok, so a bitmap is bad, that means probably a missing texture, but what bitmap? what texture? what control? By the time I got to this point I was so fried I didn't have a clue as to how to figure it out besides repeatedly searching script/gui files for paths, so Greg came to my rescue:
Just that simple little bit of information from someone that knew the code (and/or was fresh and could research it quickly) made the last bit of integration go very sweet.
(cont)
We're 90% finished with the integration. Our project has made some major changes from stock, mostly in the direction of directory management and client/server separation (we have two completely different SVN repositories, one for server-env and one for client-env, each drawing common resources such as art and mission info from an external SVN module repo, as well as a source code repository that only licensed team members have permissions for).
--As an aside, if anyone is interested in discussing repository organization strats for a medium sized project, some with licenses and some without, we are relatively happy with how Greg set it up with, of course, the exceptions noted below.
On the whole, I would say that at least 90% of the "difficulty" (and it wasn't really difficult at all for experienced TGE developers--which we aren't quite yet) was related to decisions we had made previously regarding directory structure, trying to re-work the login sequence to be more appropriate for a persistent server, and resolving conflicts in functionality and design between the Pack and our code.
The pack itself was pretty much a breeze to integrate--I was very happy to see not only did it keep things as separate as possible from stock TGE code, but it even expanded the "starter kit" mentality to be a decent to strong stucture to build projects off of.
For example, in stock TGE, your directory structure (even though it looks really complex) actually is a touch primitive, especially down at the bottom of trees. All scripts are set in one directory, all images, regardless of what they are for are in another (single) directory, etc. The pack did a very nice job of breaking things out in a more modular directory structure, which was nice to see.
The 10% of the "difficulty" can be listed in one word: paths.
Right up front, I don't have a solution for the issues we ran into, so don't take this as a criticism, just something that I hope gets handled better (or at least documented better) in the future--maybe TSE, maybe other packs. In general, paths are hard coded -everywhere-. At one point in the process I was doing a "search in files" for './', it was that difficult to nail them all down. Unfortunately, with the current implementation/techniques of how paths are used in torque to point to files, and the relatively stringent structure created by stock TGE, it was a royal pain to catch each and every issue.
It got especially bad towards the end, when dealing with the MainChatHud/ChatHud stuff, because instead of getting "missing texture/missing file" in the console, we were getting a very uninformative fatal assert (guiScrollCtrl.cc, line 90: AssertFatal(result, "Failed to create the bitmap array");
). I know that as a developer that's done the exact thing I am critiquing now, this assert was probably pretty useful to the coder that first wrote/debugged this code, but it was pretty frustrating to someone that wasn't familiar with that section of the code--ok, so a bitmap is bad, that means probably a missing texture, but what bitmap? what texture? what control? By the time I got to this point I was so fried I didn't have a clue as to how to figure it out besides repeatedly searching script/gui files for paths, so Greg came to my rescue:
if (!result)
Con::errorf("Failed to create bitmap array from %s for profile %s", mProfile->mBitmapName, mProfile->getName());
AssertFatal(result, "Failed to create the bitmap array");Just that simple little bit of information from someone that knew the code (and/or was fresh and could research it quickly) made the last bit of integration go very sweet.
(cont)
#2
In the mission file, specify a texture_base path, then in the terrain file just the name of the texture, then when you go to load the texture build the path and attempt to load from there.
Say in the mission file:
textureBase = game/data/terrain/texture
Then in the terrain file:
grass
Build the path
game/data/terrain/texture/grass and toss that at the resource manager to load.
Thats what I intend to try if I can puzzle out _how_ this stuff is loaded in the first place ;)
11/14/2004 (3:25 pm)
Ideally the paths should be set up as parts. In the mission file, specify a texture_base path, then in the terrain file just the name of the texture, then when you go to load the texture build the path and attempt to load from there.
Say in the mission file:
textureBase = game/data/terrain/texture
Then in the terrain file:
grass
Build the path
game/data/terrain/texture/grass and toss that at the resource manager to load.
Thats what I intend to try if I can puzzle out _how_ this stuff is loaded in the first place ;)
#3
I'm glad you've been able to hack everything together, too... makes us feel like we've made a useful pack. ;)
Are you naming the connections ServerConnection? There are some places where the script depends on that.
One of the things I'm thinking about for 1.4 and beyond is how to fix that sort of a problem... it's tricky stuff. :-/
11/14/2004 (10:06 pm)
Good observations, Stephen. Thank you very much for sharing them with us! :)I'm glad you've been able to hack everything together, too... makes us feel like we've made a useful pack. ;)
Are you naming the connections ServerConnection? There are some places where the script depends on that.
One of the things I'm thinking about for 1.4 and beyond is how to fix that sort of a problem... it's tricky stuff. :-/
#4
11/15/2004 (2:20 am)
Hmm...probably not actually, let me take a look at that today. 
#5
11/16/2004 (3:31 am)
Stephen, good observations here, thanks for sharing. Sometime when we have some free time, I'm sure Ben and I would love to "sit down" with you in IRC or via email and figure out some of this final polishing / structural stuff for the RTS pack. Really appreciate all your feedback so far.
#6
11/16/2004 (3:42 am)
@Josh: Sounds like a plan--I'm available pretty much whenever you guys want. I just finished up a 6 month project, so the next several months of "Indy" dev are funded, and I have no other major comittments!
#7
And that marks the completion of our integration of the RTS Pack to our project.
From this point on, we'll be delving into the pack's scripting capabilities and features, hopefully learning how to use all this amazing functionality GG has passed along.
Thanks again guys!
11/18/2004 (2:17 pm)
Ahh, how sweet it is...Quote:
Author: gregm
Date: 2004-11-18 18:28:42 -0500 (Thu, 18 Nov 2004)
New Revision: 260
Added:
tags/base-1.0/
Log:
RTS Pack Integration Base
Copied: tags/base-1.0 (from rev 259, rts-engine)
And that marks the completion of our integration of the RTS Pack to our project.
From this point on, we'll be delving into the pack's scripting capabilities and features, hopefully learning how to use all this amazing functionality GG has passed along.
Thanks again guys!
#8
04/13/2010 (1:37 pm)
Nice going guys -- you left the hard coded paths in the RTS starter kit builds ... even after pointing out the issue and possible fixes. 
Torque 3D Owner Stephen Zepp
It got one worse though--at least all these were in script. The last hardcoded path that we found was particularly sneaky: it was hiding in terrData.cc!!
Greg made me laugh out loud when he finally found it, and I saw his commit email:
As I said above, I don't have a solution, but if there is a major TGE subsystem you guys want to work on to make things easier for developers, I'd suggest a better way to organize and maintain paths.
All in all, the integration to existing code went very very well. After 3 days of solid work (the two of us working on different areas in parallel), we've gotten to the point where it is working client-dedicated server, with a large majority of our implementations as well. After I get some sleep I'll try to give some more specific feedback on trouble areas.
Now, if we can just figure out why multiple connections are trying to control the same units...