Overhaul of Torque Frontend
by Michael Perry · in Torque Game Engine · 11/30/2004 (7:14 am) · 24 replies
Hello All. My team and I are using Torque to create a Multiplayer Survival Horror game for our school's final project. Many groups who have used Torque before us have suffered from 3 main problems:
1) Lack of animation.
2) Lack of research and preproduction.
3) Each game looked like the rest.
When asked if they would do another game with Torque or create their own engine, every group preferred to do their own engine. The members in our group do not feel this way. We recognize the potential of this engine and hope to elevate its status in our school. We've solved the first two problems, but we still need to make sure our game doesn't look like everyone else's. The first major obstacle is overhauling the front end (menu system). Instead of having a 2D GUI system, we want to display the menu GUI over a running mission, similar to Warcraft 3 or World of Warcraft. I'll be posting our progress and asking for some assistance other the next three months. If anyone has any questions or suggestions, feel free to post or email me locopeffe1@yahoo.com
--mPerry
1) Lack of animation.
2) Lack of research and preproduction.
3) Each game looked like the rest.
When asked if they would do another game with Torque or create their own engine, every group preferred to do their own engine. The members in our group do not feel this way. We recognize the potential of this engine and hope to elevate its status in our school. We've solved the first two problems, but we still need to make sure our game doesn't look like everyone else's. The first major obstacle is overhauling the front end (menu system). Instead of having a 2D GUI system, we want to display the menu GUI over a running mission, similar to Warcraft 3 or World of Warcraft. I'll be posting our progress and asking for some assistance other the next three months. If anyone has any questions or suggestions, feel free to post or email me locopeffe1@yahoo.com
--mPerry
About the author
Programmer.
#2
2) What, there is plenty of documentation, and prototyping in incredibly fast
3) The look deals with your Artist. I agree the terrain in TGE is very unique, but it doesn't has to be. I you really spend time in the mission editor you can make some good stuff, just look at Poacher in the screenshot of the day.
Finally developing an engine is incredibly challenging, I do not think you under stand the intricacies that are involved. Torque is not only an AAA engine it has excellent net code and is cross platform with games even going to Xbox.
You say you want to build a game for a class project. The engine it self might consume all your time. If you want your game to look unique, learn Torque, get good artist. Use them constructively. Developing a game for any project will be extremely challenging, especially if you do not have an engine to start with. Speaking as a teacher in a Computer Graphics Degree, don't set your expectations too high. We want to see a working polished product, not something halfway complete.
.
11/30/2004 (7:41 am)
1) Torque has a VERY Robust animation system2) What, there is plenty of documentation, and prototyping in incredibly fast
3) The look deals with your Artist. I agree the terrain in TGE is very unique, but it doesn't has to be. I you really spend time in the mission editor you can make some good stuff, just look at Poacher in the screenshot of the day.
Finally developing an engine is incredibly challenging, I do not think you under stand the intricacies that are involved. Torque is not only an AAA engine it has excellent net code and is cross platform with games even going to Xbox.
You say you want to build a game for a class project. The engine it self might consume all your time. If you want your game to look unique, learn Torque, get good artist. Use them constructively. Developing a game for any project will be extremely challenging, especially if you do not have an engine to start with. Speaking as a teacher in a Computer Graphics Degree, don't set your expectations too high. We want to see a working polished product, not something halfway complete.
.
#3
1)Lack of animations has been a problem because students in my program aren't trained in Maya. We usually have a small asset team who may produce 1 or 2 models with a very small set of animations. I'm currently talking to several sets of animation students in the school to assist us with the lack of assets. The second part of the problem is that students usually wait until the first month of development to learn the exporter tools and documentation. I personally learned the Maya2DTS exporter a month ahead of schedule and have successfully exported models and animations (believe me, I realize how robust and gorgeous the TGE animation system is). As far as gathering more models and animations, we are hoping to get as much outside help as possible.
2)The lack of research and knowledge of TGE is easily fixed. Our team has been reading the forums up and down, studying every bit of documentation we can find, and doing so since the first month of the project. Our instructor informed us we are a month ahead of schedule compared to most other TGE users. In fact, one other group dropped TGE for Renderware on the first day of development because they realized they didn't research enough.
3)I probably wasn't clear about the menu system I want to implement. I know I can run a mission and place GUIs over that. I've made working GUI controls and Dialogue boxes. What I've gotten written out for my objectives is as follows:
1)Set up a scripted camera movement system used in cut scenes
2)Stop the transition from GameSplashScreen.gui to MainMenu.gui
3)Instead of MainMenu.gui, load a mission and display basic main menu Buttons on top of that ie Start Scenario, Options, Quit.
4)For each button click, move camera to a separate part of the mission and display a new set of objects and GUI controls.
Hope I'm on the right path. Very very much thanks for the feedback and sorry if I was vague in my first post.
-mPerry
11/30/2004 (9:00 am)
Glad to get replies so quickly. Regarding the 3 main problems, you both quoted what our group said when starting this project. In the Associates Program we have three scheduled months to work on Final Project. The first month is for documentation and the last two are for development. Students have the options of making their own engine, using third party systems such as ODE or RW, or complete engines such as Ogre and Torque. Granted most students can't make an engine of Torque's quality in that time, but some really nice games have been produced.1)Lack of animations has been a problem because students in my program aren't trained in Maya. We usually have a small asset team who may produce 1 or 2 models with a very small set of animations. I'm currently talking to several sets of animation students in the school to assist us with the lack of assets. The second part of the problem is that students usually wait until the first month of development to learn the exporter tools and documentation. I personally learned the Maya2DTS exporter a month ahead of schedule and have successfully exported models and animations (believe me, I realize how robust and gorgeous the TGE animation system is). As far as gathering more models and animations, we are hoping to get as much outside help as possible.
2)The lack of research and knowledge of TGE is easily fixed. Our team has been reading the forums up and down, studying every bit of documentation we can find, and doing so since the first month of the project. Our instructor informed us we are a month ahead of schedule compared to most other TGE users. In fact, one other group dropped TGE for Renderware on the first day of development because they realized they didn't research enough.
3)I probably wasn't clear about the menu system I want to implement. I know I can run a mission and place GUIs over that. I've made working GUI controls and Dialogue boxes. What I've gotten written out for my objectives is as follows:
1)Set up a scripted camera movement system used in cut scenes
2)Stop the transition from GameSplashScreen.gui to MainMenu.gui
3)Instead of MainMenu.gui, load a mission and display basic main menu Buttons on top of that ie Start Scenario, Options, Quit.
4)For each button click, move camera to a separate part of the mission and display a new set of objects and GUI controls.
Hope I'm on the right path. Very very much thanks for the feedback and sorry if I was vague in my first post.
-mPerry
#4
1) This exists, and I think pathCamera is in stock. If not, it's most probably a resource. GG uses it in their demos a lot, you may want to look to the demo scripts for examples.
2) Not hard at all, just do a search in your scripts areas for MainMenu, should point you to the right place(s).
3-4) Interesting concept. Shouldn't be amazingly difficult--again, take a look at the stock demo scripts, they do something very similar.
I know that GG themselves, as well as many of our projects (current/recently graduated students are a -great- pool of talent to pull in team members from) are very interested in TGE being used in education. If you have any questions, don't hesitate at all to ask!
11/30/2004 (9:05 am)
Makes more sense, and no biggie, we just tend to defend TGE when we see folks that don't really understand it (which you obviously do)!1) This exists, and I think pathCamera is in stock. If not, it's most probably a resource. GG uses it in their demos a lot, you may want to look to the demo scripts for examples.
2) Not hard at all, just do a search in your scripts areas for MainMenu, should point you to the right place(s).
3-4) Interesting concept. Shouldn't be amazingly difficult--again, take a look at the stock demo scripts, they do something very similar.
I know that GG themselves, as well as many of our projects (current/recently graduated students are a -great- pool of talent to pull in team members from) are very interested in TGE being used in education. If you have any questions, don't hesitate at all to ask!
#5
12/02/2004 (4:39 am)
Made quite a bit of progress since looking through pathCamera (thanks Stephen). I'm loading a mission and sending a camera moving through it now. All I have left is moving that camera based on GUI clicks and loading in assets as I get them from the asset team. Things are lookin' good.
#6
12/02/2004 (4:47 am)
Good to hear! 
#7
So, if you would rotate the scene with the buttons, it wouldn't look 3d.. but it's rendered in 3d. You get my point. :P
Doing this with Torque (as Michael wanted) should be about as simple as it sounds.
12/02/2004 (5:24 am)
FYI, WarCraft 3 had 3D menu's. Simply planes with transparancy made up of 3d objects. There's information about this at www.wc3campaigns.com/ which is one of the greatest campaigns and modding sites for WarCraft 3.So, if you would rotate the scene with the buttons, it wouldn't look 3d.. but it's rendered in 3d. You get my point. :P
Doing this with Torque (as Michael wanted) should be about as simple as it sounds.
#8
What I consider a "3-D" interface is something like the initial Gui that Dungeon Keeper 2 used. The map selection, saved game, and other "setup" interfaces were literally a set of 3-D scenes, and the camera were do a lot of pathing and rotation to move you around the scenes based on your gui control state. The gui "buttons" were actual 3-D objects in the scene, and you'd click to select them, as opposed to pressing gui buttons.
Now if instead of using Gui Buttons, Michael implements selection of scene objects and then changes the gui control state based on those 3-D click to selects, I'd consider that a "3-D gui"!
It does sound like this may be what he's shooting for, a bit hard to tell for sure.
12/02/2004 (5:32 am)
Fair clarification Stefan, although what I was getting at is how the player interacted with them :)What I consider a "3-D" interface is something like the initial Gui that Dungeon Keeper 2 used. The map selection, saved game, and other "setup" interfaces were literally a set of 3-D scenes, and the camera were do a lot of pathing and rotation to move you around the scenes based on your gui control state. The gui "buttons" were actual 3-D objects in the scene, and you'd click to select them, as opposed to pressing gui buttons.
Now if instead of using Gui Buttons, Michael implements selection of scene objects and then changes the gui control state based on those 3-D click to selects, I'd consider that a "3-D gui"!
It does sound like this may be what he's shooting for, a bit hard to tell for sure.
#9
12/02/2004 (5:37 am)
I'll be sure to check that out Stefan. Well, I've gotten hung up on the transition from splash screen to loading a mission. I think I'm going to take a small break and ponder the error. BTW, I've been chewing on the idea of TGE being used educationally. I anticipate the situation of being hired by a game company and working with their game engine, instead of creating one for them. I feel it's important for programmers to get experience with working with other people's code and becoming familiar with new engines. If anyone has used it themselves in teaching others, what successes and drawbacks have you faced?
#10
There is a forum near the bottom, "Torque in Education" where some of the course intstructors that are actually using TGE in their curriculum hang out, you may want to stop by there (use Edit Subscriptions on the right of the browser window if you don't see the forum).
12/02/2004 (5:43 am)
@Michael: do you mean using TGE to teach game programming, or creating an application using TGE, and using that application to teach other topics (not necessarily game related)?There is a forum near the bottom, "Torque in Education" where some of the course intstructors that are actually using TGE in their curriculum hang out, you may want to stop by there (use Edit Subscriptions on the right of the browser window if you don't see the forum).
#11
Instead of Canvas.setConent(MainMenu.gui) I'm just loading the stronghold mission, just like in startMissionGui.gui
%mission = "stronghold";
%serverType = "SinglePlayer";
createServer(%serverType, %mission);
%conn = new GameConnection(ServerConnection);
RootGroup.add(ServerConnection);
%conn.setConnectArgs($pref::Player::Name);
%conn.connectLocal();
The mission load screen pops up but everything hangs from there. Should I use the loadMission( %missionName, %isFirstMission ) instead, or am I just goofing something up with syntax and imroper calls
12/02/2004 (6:28 am)
I was definitely referring to using TGE to teach game programming. The experience of using a completed game engine is very valuable as I am now finding out. Speaking of which, I've hit this small hang up on my loadMainMenu function. Instead of Canvas.setConent(MainMenu.gui) I'm just loading the stronghold mission, just like in startMissionGui.gui
%mission = "stronghold";
%serverType = "SinglePlayer";
createServer(%serverType, %mission);
%conn = new GameConnection(ServerConnection);
RootGroup.add(ServerConnection);
%conn.setConnectArgs($pref::Player::Name);
%conn.connectLocal();
The mission load screen pops up but everything hangs from there. Should I use the loadMission( %missionName, %isFirstMission ) instead, or am I just goofing something up with syntax and imroper calls
#12
Is the console.log showing anything helpful?
12/02/2004 (6:41 am)
First guess would be you need to make %mission = "stronghold.mis";Is the console.log showing anything helpful?
#13
I'm going through the missionLoad.cs now to see what I can uncover...first impression is file path error, but I guess I'll find out.
12/02/2004 (6:55 am)
During Stage 2 loading the message "Could not find mission stronghold.mis" appeared. I'm going through the missionLoad.cs now to see what I can uncover...first impression is file path error, but I guess I'll find out.
#14
I would probably guess the same as you...the mission file is being handed to createServer as a single filename instead of a path, and it probably can't access it from the current working dir.
Forum Note: Just realized we're in a public forum. I'd suggest moving/copying this thread (create a new one) in the private forums for further assistance--we're not really supposed to talk too much code in the public forums!
12/02/2004 (7:00 am)
From a quick review of the "stock" missing assignment and loading process, it appears that you've cut/paste some code to meet your needs--which is fine, and a good idea for learning how to get something working initially.I would probably guess the same as you...the mission file is being handed to createServer as a single filename instead of a path, and it probably can't access it from the current working dir.
Forum Note: Just realized we're in a public forum. I'd suggest moving/copying this thread (create a new one) in the private forums for further assistance--we're not really supposed to talk too much code in the public forums!
#15
We are working on the mission for our target scenario. We are thinking about setting up an area far away from where the gameplay occurs and displaying the options and character selection there. The camera will move on its path as options are selected, and once all selections are made, move the camera to the spawn sphere in the gameplay area and starting the fun. This means we'll only have to load 1 mission, and the transition would be seemless between options, character selection, and game play. I'm sure we'll have to think this through a little bit more, but the idea seems kinda nifty. What draw backs do you guys think might develop?
12/02/2004 (7:13 am)
Alright, thanks for the info Stephen. I'll probably create a private forum in a little while. I just remembered something my team and I talked about yesterday when discussing the interface. Since we'll be running a mission in the background anyway, we are toying with this idea:We are working on the mission for our target scenario. We are thinking about setting up an area far away from where the gameplay occurs and displaying the options and character selection there. The camera will move on its path as options are selected, and once all selections are made, move the camera to the spawn sphere in the gameplay area and starting the fun. This means we'll only have to load 1 mission, and the transition would be seemless between options, character selection, and game play. I'm sure we'll have to think this through a little bit more, but the idea seems kinda nifty. What draw backs do you guys think might develop?
#16
Basically, once the mission is loaded, you'll have objects "active". You may want to (and this may or may not be a lot of work) set up a new control state in your mission itself called "standby" or something similar, and make sure you aren't processing ticks for all your objects in the game environment during this state.
Of course, if part of the reason you want the selection screens to be part of the mission is that once the player does "go active", the mission state is already evolving, then this could be a good thing!
A clarification example:
Let's say you implement the Day/Night cycles with Seasons resource, giving your game a moving sun. In a normal use of this resource, once the mission is started, the sun starts rising and falling. If this is happening during your player's selection phase, then the "day or night state" of your game is constantly changing, and the player could enter the game at any time of day simply based on how long they took in the selection phase.
I'll leave it to your game design as to if this is a good or bad thing, but it's definitely something you need to think about!
12/02/2004 (8:02 am)
A big one I would think of is that (unless you stop/control it) while your player is taken their good old time doing selection/setup stuff, all the objects in your mission are "active". If, for example, you have AI controlled objects, and they happen to be able to detect the player, they may just try to go after the player during the selection phase.Basically, once the mission is loaded, you'll have objects "active". You may want to (and this may or may not be a lot of work) set up a new control state in your mission itself called "standby" or something similar, and make sure you aren't processing ticks for all your objects in the game environment during this state.
Of course, if part of the reason you want the selection screens to be part of the mission is that once the player does "go active", the mission state is already evolving, then this could be a good thing!
A clarification example:
Let's say you implement the Day/Night cycles with Seasons resource, giving your game a moving sun. In a normal use of this resource, once the mission is started, the sun starts rising and falling. If this is happening during your player's selection phase, then the "day or night state" of your game is constantly changing, and the player could enter the game at any time of day simply based on how long they took in the selection phase.
I'll leave it to your game design as to if this is a good or bad thing, but it's definitely something you need to think about!
#17
12/11/2004 (10:13 am)
So, the menu system is looking pretty good! We've gotten a lot of compliments. "This is done in Torque? This is the best I've seen Torque look." I'm pretty proud of the team I'm in. We are hitting deadlines left and right. I believe we've overcome the #3 problem from my first post. With the exception of the first few splash screens on loading, our game has taken on a unique look and feel compared to all other TGE users in our school. We originally chopped cut scenes from the design document since we thought it would be too difficult, but since I implemented a pathed Camera script for the menu system, the idea doesn't seem so hard anymore. Just gotta say, I love this engine and look forward to future games I'll make with it.
#18
Stephen said:
Just realized we're in a public forum. I'd suggest moving/copying this thread (create a new one) in the private forums for further assistance--we're not really supposed to talk too much code in the public forums!
12/11/2004 (10:51 am)
I'm a bit confused by this. How can anyone in this conversation move it to a non-public part of the forums? With the exception of Anthony, everyone who posted was a "member," not an SDK owner. Members are limited to public forums, right?Stephen said:
Just realized we're in a public forum. I'd suggest moving/copying this thread (create a new one) in the private forums for further assistance--we're not really supposed to talk too much code in the public forums!
#19
There is a difference between being a forum "member", and being a licensed TGE owner!
12/11/2004 (12:00 pm)
@Eric: There are private forums that are only accessable to people who have the TGE license. As a rule, we are not supposed to discuss actual code examples in the public forums.There is a difference between being a forum "member", and being a licensed TGE owner!
#20
I know that I AM wrong. From the conversation, it sounds like both you and Michael have access to TGE source and private forums. I just don't understand HOW I could be wrong. Neither of you is listed as SDK owner. Have I misunderstood the meaning of that title?
12/11/2004 (2:55 pm)
And none of the people in this conversation are licensed TGE owners, right? I am looking at people's titles under their names. I have seen the title "Torque SDK Owner" before, but everyone in this thread has title "Member" (except Anthony, associate).I know that I AM wrong. From the conversation, it sounds like both you and Michael have access to TGE source and private forums. I just don't understand HOW I could be wrong. Neither of you is listed as SDK owner. Have I misunderstood the meaning of that title?
Torque 3D Owner Stephen Zepp
I'm amazed to think that a school project (even at the Masters level) would be able to even come close to duplicating just the basics of TGE in the time it would take to actually figure out how to create an animated model, export it from the application, and then import it into TGE...
With your explanation of 3) as well, all you have to do to accomplish what you want is to edit the playGui.gui using the Gui Editor (F-10). Any gui's that are children of the TSCtrl (which is your main "playing" window) will be available during game play, depending on how you script them.
FYI, neither Warcraft 3, nor WoW use "3-D guis" which is what your description seems to imply--they just have scripted gui's that pop up over the play canvas during game play. The community resource for the RTS Starter Kit (the kit is $49.95 from GG, and requires the TGE license) implements a large portion of the "standard" Warcraft 3 style interface, including examples about how to make a gui to let you hire troops when you click on a building, etc.
EDIT: Looking at your profile, I see you're from Orlando. I assume that you're at Full Sail? If it is the conception of the general student body there that TGE can't do animations, or any of the other things that you list, someone needs to head down there from GG and straighten things up!