Epiphany: Use of T2D within a TGE project idea
by Stephen Zepp · in Torque Game Builder · 03/05/2005 (11:01 am) · 17 replies
First, let me say that the T2D draw has been so amazingly tempting that I've been trying for weeks and weeks to come up with a use for T2D within our existing project, without completely distracting our entire vision...the things that everyone is coming up with in days and even hours is amazing!
So I was playing around with the idea of "mini-games" within a 3-D world as a means to use T2D within our vision, and really couldn't come up with a compelling reason to use the tech--mini-games just don't really fit into our project as a whole, although they will probably be added in in much later stages if it makes sense. So I was frustrated about all the cool stuff, and how I couldn't come up with a way to use it!
And then it hit me: I took one look at Nauris Krauze's latest .plan (if you haven't read it...do so RIGHT NOW. You won't regret it!), and realized in a single heartbeat how T2D will handle a major design problem we've been ignoring until now: World, Strategic, and Tactical Command Maps!
Pretty much every game existant now that has a 3D world has a world map to give basic information to the players about where they are, what's around them, etc. Since our project is not only a "first/third person" persistent world, but also has strong need for dynamic and easy to use interfaces for both strategic and tactical command of RTS-style troops, we had to come up with some way to implement a series of interfaces that are basically in 2D that would allow commanders to handle logistics, trade, diplomacy, troop mobilization, reconaissance reports, and other command style requirements. Enter T2D!
Since T2D can be easily run within a GUI object inside TGE, we've got an almost instant tech implementation to provide all the functionality we wanted, in an easy to develop and modify platform, instead of having to try to implement all the functionality in TGE...we can use T2D to render a 2-D projection of the 3D world, including all of the necessary representations for battle commanders to do their jobs.
It's going to be quite a while before we're ready to work on this functionality, but I wanted to share the idea early on in case anyone else was looking at similar requirements, as well as to see if anyone had any other ideas along these lines!
So I was playing around with the idea of "mini-games" within a 3-D world as a means to use T2D within our vision, and really couldn't come up with a compelling reason to use the tech--mini-games just don't really fit into our project as a whole, although they will probably be added in in much later stages if it makes sense. So I was frustrated about all the cool stuff, and how I couldn't come up with a way to use it!
And then it hit me: I took one look at Nauris Krauze's latest .plan (if you haven't read it...do so RIGHT NOW. You won't regret it!), and realized in a single heartbeat how T2D will handle a major design problem we've been ignoring until now: World, Strategic, and Tactical Command Maps!
Pretty much every game existant now that has a 3D world has a world map to give basic information to the players about where they are, what's around them, etc. Since our project is not only a "first/third person" persistent world, but also has strong need for dynamic and easy to use interfaces for both strategic and tactical command of RTS-style troops, we had to come up with some way to implement a series of interfaces that are basically in 2D that would allow commanders to handle logistics, trade, diplomacy, troop mobilization, reconaissance reports, and other command style requirements. Enter T2D!
Since T2D can be easily run within a GUI object inside TGE, we've got an almost instant tech implementation to provide all the functionality we wanted, in an easy to develop and modify platform, instead of having to try to implement all the functionality in TGE...we can use T2D to render a 2-D projection of the 3D world, including all of the necessary representations for battle commanders to do their jobs.
It's going to be quite a while before we're ready to work on this functionality, but I wanted to share the idea early on in case anyone else was looking at similar requirements, as well as to see if anyone had any other ideas along these lines!
#2
T2D would provide for any level of complexity we want in managing massive (100's to 1,000's) of troops at a strategic commander level, instead of a tactical "battle leader" level, across any size terrain, as well as easy to manage representations of both strategic, tactical, and geographic conditions.
Yes, you could certainly use the RTSMapHud and expand it, but you could also use TGE to re-write everything in the RTS-SK without buying that--it's a matter of (in my opinion) leveraging extremely powerful technology instead of trying to squeeze functionality out of a module that was designed/implemented to do something slightly (or greatly, in our case) different.
03/05/2005 (11:19 am)
The RTS mapHud is a very simple rendering of the entire mission space with the only user input interface primitive being the ability to move the camera to a new location based on a click, or move units via a click. It's not designed at all (nor should it be--it does it's job extremely well) as a real user interface for complex tasks.T2D would provide for any level of complexity we want in managing massive (100's to 1,000's) of troops at a strategic commander level, instead of a tactical "battle leader" level, across any size terrain, as well as easy to manage representations of both strategic, tactical, and geographic conditions.
Yes, you could certainly use the RTSMapHud and expand it, but you could also use TGE to re-write everything in the RTS-SK without buying that--it's a matter of (in my opinion) leveraging extremely powerful technology instead of trying to squeeze functionality out of a module that was designed/implemented to do something slightly (or greatly, in our case) different.
#3
03/05/2005 (11:28 am)
I'm doing something similar, but I'm also using T2D as an interface and a mini-game control. Hopefully I'll get more done and have something to show other than the Bravetree car rolling around on the 3D-Digger's steets. 
#4
Certainly is a great idea, are you already using the rts pack then?
03/05/2005 (11:41 am)
Well when u put it like that who am i to argue :DCertainly is a great idea, are you already using the rts pack then?
#5
03/05/2005 (11:47 am)
Yes,we are using the RTS-SK extensively, and it's quite nice! 
#6
Keep us posted on your game progress!
03/05/2005 (11:52 am)
Awesome Stephen, great idea. :) Glad T2D will be useful to your game, and not just a pleasant distraction. Very cool.. yeah, T2D on it's own is just great, but then throw in the fact that you can use it to enhance your 3D games and just... man, people are going to be doing such cool stuff!Keep us posted on your game progress!
#7
on a more serious note, isnt it gonna be a big undertaking to render an overview of the 3d world into t2d, then u gotta render all the extra info u need into the world view. would it be just as easy to let the over view component that comes with rts sk do that much and then use t2d to overlay on top of it with the additional info u need?
03/05/2005 (11:53 am)
Makes me wish i could use tge, i feel so backwards :'(on a more serious note, isnt it gonna be a big undertaking to render an overview of the 3d world into t2d, then u gotta render all the extra info u need into the world view. would it be just as easy to let the over view component that comes with rts sk do that much and then use t2d to overlay on top of it with the additional info u need?
#8
As I mentioned, it is really great as a warcraft style "see the entire map at once" display, and does all the things you would expect for that kind of game, but it's tailored specifically to do that exact functionality, and nothing more.
Regarding how we would probably implement the T2D rendering portion (and this is a REALLY loose design guess on my part, just came up with the idea today!) is that we would grab terrain tile indexes directly from the primary material blend from the TGE terrain block, and then set the tiles that are rendered in the T2D scene appropriately.
We would then have additional tile layers that represent things like squads, companies, battalions, etc., and tile based images that would overlay the terrain. This would allow us to have the commander click to pick a specific 2D tile that represents a command-able set of units, and issue a command directly. The command would then be passed back to the TGE layer, and propagated as a net event most likely to the server, for further transmission to the appropriate team members. (For those that are familiar with how the RTS-SK does things, this would be the equivalent of having pre-defined selection groups, and sending the command to a particular selection group on the server. Not the exact same implementation of course, but similar in nature).
Another example would be a recon report from the field that would come through the TGE layer and sent to the T2D layer (I can see that we'll need to come up with some form of event posting back and forth between the layers, but that's not difficult) to be represented on the tactical map. If we were to want to do this in the rts MapHud, we'd have to re-write the entire processing of that module to be able to handle "fuzzy" representations--for example, what if the recon report was issued by a scout unit that was very low skilled--the position report would be "adjusted" by our code to give a "mostly accurate" down to a "wildly inaccurate" position report. This would be done pretty easily if we add the T2D representation layer, but would be very difficult if we tried to do that in the mapHud.
In other words, we want to leave the mapHud to be 100% accurate (based on what is actually seen by a specific player), while allowing for intel reporting and command issuing at the T2D command map layer that can factor in false reports, inaccurate reports, etc.
03/05/2005 (12:48 pm)
The rtsMapHud actually grabs the image of the screen itself for it's rendering, and this can cause problems if the player is running in windowed mode. It is also (currently) D3D only IIRC, but I could be wrong about that.As I mentioned, it is really great as a warcraft style "see the entire map at once" display, and does all the things you would expect for that kind of game, but it's tailored specifically to do that exact functionality, and nothing more.
Regarding how we would probably implement the T2D rendering portion (and this is a REALLY loose design guess on my part, just came up with the idea today!) is that we would grab terrain tile indexes directly from the primary material blend from the TGE terrain block, and then set the tiles that are rendered in the T2D scene appropriately.
We would then have additional tile layers that represent things like squads, companies, battalions, etc., and tile based images that would overlay the terrain. This would allow us to have the commander click to pick a specific 2D tile that represents a command-able set of units, and issue a command directly. The command would then be passed back to the TGE layer, and propagated as a net event most likely to the server, for further transmission to the appropriate team members. (For those that are familiar with how the RTS-SK does things, this would be the equivalent of having pre-defined selection groups, and sending the command to a particular selection group on the server. Not the exact same implementation of course, but similar in nature).
Another example would be a recon report from the field that would come through the TGE layer and sent to the T2D layer (I can see that we'll need to come up with some form of event posting back and forth between the layers, but that's not difficult) to be represented on the tactical map. If we were to want to do this in the rts MapHud, we'd have to re-write the entire processing of that module to be able to handle "fuzzy" representations--for example, what if the recon report was issued by a scout unit that was very low skilled--the position report would be "adjusted" by our code to give a "mostly accurate" down to a "wildly inaccurate" position report. This would be done pretty easily if we add the T2D representation layer, but would be very difficult if we tried to do that in the mapHud.
In other words, we want to leave the mapHud to be 100% accurate (based on what is actually seen by a specific player), while allowing for intel reporting and command issuing at the T2D command map layer that can factor in false reports, inaccurate reports, etc.
#9
03/05/2005 (1:10 pm)
I presume in tge u could have multiple cameras, could u not have a seperate camera that could ignore eveything except the terrain and place it high above the terrain to grab an image? this would give a nice snapshot of the terrain would it not and make it a little easier, i.e u could zoom in on it etc.? or am i talkin rubbish
#10
03/05/2005 (2:03 pm)
Your points are fine, but they won't accomplish the functionality that is needed for our interface! In fact, what you describe is basically what the rts mapHud does.
#11
Stephen, your implementation is a good idea yep. I wouldn't use tile layers for the squads, but you guys will do a good job figuring that stuff out when you come to it, like you always do.
Gavin, yeah, you could do this in TGE too, but Stephen is just recognizing that doing a quick 2D overhead render and setting it up as a tile map in T2D, and then using all T2D's handy-dandy functions to handle user input and scroll the tile around would be quicker and easier than doing it all on his own. And that's true. Knowing what Stephen's contracting rates go for.... if it takes a half-hour less total time to do this in T2D than it would to code it up in TGE, then he'll have made his money back on T2D right there alone. ;)
03/05/2005 (2:46 pm)
(note on the RTS SK Map HUD, it's actually OGL only atm.. though we do plan to fix this :)Stephen, your implementation is a good idea yep. I wouldn't use tile layers for the squads, but you guys will do a good job figuring that stuff out when you come to it, like you always do.
Gavin, yeah, you could do this in TGE too, but Stephen is just recognizing that doing a quick 2D overhead render and setting it up as a tile map in T2D, and then using all T2D's handy-dandy functions to handle user input and scroll the tile around would be quicker and easier than doing it all on his own. And that's true. Knowing what Stephen's contracting rates go for.... if it takes a half-hour less total time to do this in T2D than it would to code it up in TGE, then he'll have made his money back on T2D right there alone. ;)
#12
Then I got thinking...hmmm my game has wizards and magic in it. Wouldn't it be cool if my cursor (a magic wand) could have a little sparkly emitter follow it around on the screen? Should be pretty simple right? Just get the cursor position and move the emitter to that spot, voila, magic wand complete with sparkles. Then I got dreaming that I could use the super-duper particle editor to create all kinds of effects when buttons are pushed or as background effects for dialogs, etc...
Now, the very first problem I run into is that the T2D control does not let the controls below it handle mouse events, (e.g. mouse over, left-click, etc..) I am sure there is away to do this can anybody point me in the right direction?
Secondly, please let me know if this is a dumb idea. I really don't think so, I mean basically every interface gui is 2D, this just seems like a cool way to add spectacular effects to interfaces. But if I am being overly excited let me have it.
03/14/2005 (8:34 pm)
OK guys, awhile back I saw a little demo that Melv did that showed T2D windows running along with the TGE demo mission. As soon as I saw that I had a flash of inspiration similar to Stephen's. I thought why not overlay the T2D control over the mini-map (RTS game) and I could use the awesome particle effects to show things like beacons, ally being attacked, track heros etc... I wasn't thinking about trying to put the actual map in as tiles but just overlaying the map with a see-through T2D control.Then I got thinking...hmmm my game has wizards and magic in it. Wouldn't it be cool if my cursor (a magic wand) could have a little sparkly emitter follow it around on the screen? Should be pretty simple right? Just get the cursor position and move the emitter to that spot, voila, magic wand complete with sparkles. Then I got dreaming that I could use the super-duper particle editor to create all kinds of effects when buttons are pushed or as background effects for dialogs, etc...
Now, the very first problem I run into is that the T2D control does not let the controls below it handle mouse events, (e.g. mouse over, left-click, etc..) I am sure there is away to do this can anybody point me in the right direction?
Secondly, please let me know if this is a dumb idea. I really don't think so, I mean basically every interface gui is 2D, this just seems like a cool way to add spectacular effects to interfaces. But if I am being overly excited let me have it.
#13
I'm seriously considering using T2D for -all- of our "lots of action" guis, like city planning/placement, troop positioning, etc...as you said, it's 2D, so why try to reinvent the wheel? We just have to make sure the initial prototype command T2D gui works as expected...something I'm hoping to get on in the next couple of weeks!
Regarding passing events back and forth between TGE and T2D...you'd most likely have to code it, but again I don't see any reason why you couldn't do it at all. It may be as simple as making sure that your gui that has T2D in it doesn't have first responder, and knows how/where to pass any click-through events. That's not trivial probably, but it's not monumental either.
03/14/2005 (9:31 pm)
I don't have enough experience at all to say if T2D within a gui would work just like this...but I don't see anything that says it couldn't either!I'm seriously considering using T2D for -all- of our "lots of action" guis, like city planning/placement, troop positioning, etc...as you said, it's 2D, so why try to reinvent the wheel? We just have to make sure the initial prototype command T2D gui works as expected...something I'm hoping to get on in the next couple of weeks!
Regarding passing events back and forth between TGE and T2D...you'd most likely have to code it, but again I don't see any reason why you couldn't do it at all. It may be as simple as making sure that your gui that has T2D in it doesn't have first responder, and knows how/where to pass any click-through events. That's not trivial probably, but it's not monumental either.
#14
I had the same sort of Idea about using a control as map of sorts. The only difference being that it would be a mirror in t2d as an overhead of the entire level.
I'm planning out a overhead type game but with a main player and the ability to control other team members. I figured the overhead would be a good way of telling people where to go.
I haven't tried it yet so I don't know how much of a hit it would be.
It's going to be fun to figure out though
Edit: Replaced fund with the proper word fun at the end there.
03/14/2005 (9:56 pm)
Stephen,I had the same sort of Idea about using a control as map of sorts. The only difference being that it would be a mirror in t2d as an overhead of the entire level.
I'm planning out a overhead type game but with a main player and the ability to control other team members. I figured the overhead would be a good way of telling people where to go.
I haven't tried it yet so I don't know how much of a hit it would be.
It's going to be fun to figure out though
Edit: Replaced fund with the proper word fun at the end there.
#15
Disclaimer: I still haven't even "unwrapped" T2D--been way too busy :(
The basic design we are working on right now is the concept of a "City Planning" super-gui using T2D within TGE, specifically with the RTS-SK. The main idea is to be able to display a real time 2.5D version of TGE terrain, overlayed with a grid that the players can use to place new buildings. These building placement commands would be handed back to TGE, and then the RTS-SK code would "take over", and perform the standard building construction functionality.
A couple of questions/requests for design review:
1) We are thinking that we will write a "3D Terrain Projection to 2.5D" access method that would be called from within T2D to the terrain engine in TGE, and get back a spew of tile ID's that should be displayed based on the terrain's height, and blended texture map weights. T2D in turn would use these tile ID's to figure out which tile to render at a specific grid coordinate, and then dynamically build a tile layer that represents the terrain.
Is this a good way to handle this concept, or is there a better way in T2D?
2) We would then do some sort of container search in TGE to report back to T2D what buildings are in the current area, and T2D would render this information as sprites on top of the terrain tile layer. Does this make sense?
3) Finally, we would develop a scrollable icon list of the buildings the player can build, and allow them to drag and drop a building from the icon list, and place it onto the T2D gui. The T2D gui would take care of detecting collisions with other buildings, terrain slope issues, etc. and if a building placement is valid, pass that information back to the TGE layer for actual construction. Once again, thoughts?
Anyone, please feel free to jump in, I'm hoping to get a free-form brainstorming discussion going!
03/26/2005 (10:03 pm)
I wanted to revive this thread now that a lot of folks here have some good experience with T2D.Disclaimer: I still haven't even "unwrapped" T2D--been way too busy :(
The basic design we are working on right now is the concept of a "City Planning" super-gui using T2D within TGE, specifically with the RTS-SK. The main idea is to be able to display a real time 2.5D version of TGE terrain, overlayed with a grid that the players can use to place new buildings. These building placement commands would be handed back to TGE, and then the RTS-SK code would "take over", and perform the standard building construction functionality.
A couple of questions/requests for design review:
1) We are thinking that we will write a "3D Terrain Projection to 2.5D" access method that would be called from within T2D to the terrain engine in TGE, and get back a spew of tile ID's that should be displayed based on the terrain's height, and blended texture map weights. T2D in turn would use these tile ID's to figure out which tile to render at a specific grid coordinate, and then dynamically build a tile layer that represents the terrain.
Is this a good way to handle this concept, or is there a better way in T2D?
2) We would then do some sort of container search in TGE to report back to T2D what buildings are in the current area, and T2D would render this information as sprites on top of the terrain tile layer. Does this make sense?
3) Finally, we would develop a scrollable icon list of the buildings the player can build, and allow them to drag and drop a building from the icon list, and place it onto the T2D gui. The T2D gui would take care of detecting collisions with other buildings, terrain slope issues, etc. and if a building placement is valid, pass that information back to the TGE layer for actual construction. Once again, thoughts?
Anyone, please feel free to jump in, I'm hoping to get a free-form brainstorming discussion going!
#16
It seems reasonable. However, if the height of terrain matters in some way (for placing buildings or whatever), then you're going to have to think about some things. Chief among them is how to select the proper image that tiles appropriately across the landscape. This is going to require taking in information about the neighboring terrain and selecting a tile image that fits with that terrain. You're going to need lots of tile images as well as a way to tell the system which images can go next to which other images.
I suppose. However, it'd be easier to just spawn T2D objects at the same time (and location) as you spawn TGE objects.
Once again, it seems OK.
The main thing I don't understand is... what's the point? Really, if the user is capable of functioning under TGE for the game, what is the T2D version of the map for?
03/27/2005 (12:33 pm)
Quote:Is this a good way to handle this concept, or is there a better way in T2D?
It seems reasonable. However, if the height of terrain matters in some way (for placing buildings or whatever), then you're going to have to think about some things. Chief among them is how to select the proper image that tiles appropriately across the landscape. This is going to require taking in information about the neighboring terrain and selecting a tile image that fits with that terrain. You're going to need lots of tile images as well as a way to tell the system which images can go next to which other images.
Quote:Does this make sense?
I suppose. However, it'd be easier to just spawn T2D objects at the same time (and location) as you spawn TGE objects.
Quote:Once again, thoughts?
Once again, it seems OK.
The main thing I don't understand is... what's the point? Really, if the user is capable of functioning under TGE for the game, what is the T2D version of the map for?
#17
T2D inherently allows for much more complex manipulation of information than the stock TGE gui system does, and can act as a tightly controlled user presentation format. For $100 ($80 at the EA level) plus a couple of hours of integration work, you can gain the incredibly easy development power of T2D, while leaving the TGE layer of the game itself alone (except for some access methods on both sides).
For example, the implementation of the relatively simple act of selecting a building to build (RTS-SK), positioning it in the 3-D game world (including rotation about the Z axis), and then synchronizing it back to the server, and then back to all the clients is a functionality that covers 2 source code files, 2 GUI files, and about 5 script files in the RTS-SK...and that's just for one very basic functionality. Multiply that by, say, 75 different user actions, and you are looking at spaghetti code from hell. T2D implementation of the user input primitive is (from what I can tell so far) a matter of probably 15 lines of script, some artwork, and the access methods to duplicate in the TGE layer.
Based on the implementation speed and efficiency for quality product we've seen from T2D so far, adding in a T2D super-gui layer will be extremely cost-effective when balanced against twisting the TAP standard GUI interface (which is nice, don't get me wrong here) into highly complex input/output primitives.
03/27/2005 (12:56 pm)
Interesting idea about keeping the T2D object instances tightly coupled to the TGE layer, instead of replicating when the super-gui is opened.T2D inherently allows for much more complex manipulation of information than the stock TGE gui system does, and can act as a tightly controlled user presentation format. For $100 ($80 at the EA level) plus a couple of hours of integration work, you can gain the incredibly easy development power of T2D, while leaving the TGE layer of the game itself alone (except for some access methods on both sides).
For example, the implementation of the relatively simple act of selecting a building to build (RTS-SK), positioning it in the 3-D game world (including rotation about the Z axis), and then synchronizing it back to the server, and then back to all the clients is a functionality that covers 2 source code files, 2 GUI files, and about 5 script files in the RTS-SK...and that's just for one very basic functionality. Multiply that by, say, 75 different user actions, and you are looking at spaghetti code from hell. T2D implementation of the user input primitive is (from what I can tell so far) a matter of probably 15 lines of script, some artwork, and the access methods to duplicate in the TGE layer.
Based on the implementation speed and efficiency for quality product we've seen from T2D so far, adding in a T2D super-gui layer will be extremely cost-effective when balanced against twisting the TAP standard GUI interface (which is nice, don't get me wrong here) into highly complex input/output primitives.
Torque 3D Owner Gavin Beard
Byte Logic