Torque Development Plans
by Kyle Carter · in Torque Game Engine · 11/04/2004 (12:00 pm) · 45 replies
Based on the discussion at www.garagegames.com/mg/forums/result.thread.php?qt=19187, I thought it might be good to break the discussion about Torque dev into a seperate thread.
To clear things up a little, 1.4 will break some things, backwards compatibility wise, but it will hardly require a rewrite. Consider how much functionality is in Torque. :) It would take a year for us to touch all that, not just a few months. :)
Anyway, if anybody has questions about the new development process or has concerns about what we'll be addressing in upcoming releases, feel free to post in here. I'll try my best to answer your questions. And hopefully we can move the discussion from that other thread into a more on-topic place, ie, here.
To clear things up a little, 1.4 will break some things, backwards compatibility wise, but it will hardly require a rewrite. Consider how much functionality is in Torque. :) It would take a year for us to touch all that, not just a few months. :)
Anyway, if anybody has questions about the new development process or has concerns about what we'll be addressing in upcoming releases, feel free to post in here. I'll try my best to answer your questions. And hopefully we can move the discussion from that other thread into a more on-topic place, ie, here.
#22
Yeah, if anyone looking into making a game with torque, waiting around for the next big thing will get you no where, because, of course, there will always be updates, till' the day Torque powers nearly 99% of all human processes and even our brains, and GG dominates the entire nature of life! :P
11/06/2004 (3:32 pm)
Hmm, and so if we want to add later things to the game, would you suggest we use a program like winmerge? Yeah, if anyone looking into making a game with torque, waiting around for the next big thing will get you no where, because, of course, there will always be updates, till' the day Torque powers nearly 99% of all human processes and even our brains, and GG dominates the entire nature of life! :P
#23
11/06/2004 (4:03 pm)
Yes, if you're planning on doing serious work with the C++ side of Torque, having a good working knowledge of how to do code merging and differencing is invaluable. 
#24
As Ben stated, learning to use tools such as winmerge effectively is invaluable. I have actually found that using internal tools such as CVS or Subversion is also extremely helpful because you can roll-back as needed if you break something horribly. Learning these tools may seem to take a while or be confusing at first, but once you learn them and integrate them into your workflow you'll be much more productive and wonder how you lived without them before. At least that's been my experience since I'm constantly yinkering with the source and breaking things I'm trying to learn. It's nice to be able to roll-back my engine shattering coding abilities. Some groups may find CVS or SVN to be overkill on a project, but if you're making heavy modifications to the engine, being extremely familiar with differencing tools and techniques will allow a much cleaner integration with future source bases.
11/07/2004 (7:33 am)
@CameronAs Ben stated, learning to use tools such as winmerge effectively is invaluable. I have actually found that using internal tools such as CVS or Subversion is also extremely helpful because you can roll-back as needed if you break something horribly. Learning these tools may seem to take a while or be confusing at first, but once you learn them and integrate them into your workflow you'll be much more productive and wonder how you lived without them before. At least that's been my experience since I'm constantly yinkering with the source and breaking things I'm trying to learn. It's nice to be able to roll-back my engine shattering coding abilities. Some groups may find CVS or SVN to be overkill on a project, but if you're making heavy modifications to the engine, being extremely familiar with differencing tools and techniques will allow a much cleaner integration with future source bases.
#25
11/07/2004 (8:42 am)
I don't think that SVN/CVS is overkill for ANY project. I can't stress enough how many times it has saved my ass. Source control is essential, as is knowledge of a Winmerge/Beyond Compare.
#26
Version control when used properly can be amazingly powerful. It's well worth learning if you plan on doing any sort of serious work with text files. It's the difference between making them do what you want, and making them sing while they do it...
11/07/2004 (10:28 am)
Absolutely true. I know of companies where they keep every document, not just code, in version control. It lets them avoid issues along the lines of "I lost business plan X!" or "My hard disk crashed and now I can't get to my docs!" All they have to do is a checkout and they're back in business.Version control when used properly can be amazingly powerful. It's well worth learning if you plan on doing any sort of serious work with text files. It's the difference between making them do what you want, and making them sing while they do it...
#27
11/07/2004 (10:34 am)
Not to mention that svn also does a fine job of managing binary resources, eg. art assets of all kinds...
#28
11/07/2004 (6:49 pm)
I've decided to fix up the player class, starting with crouching and proning.
#29
11/07/2004 (6:56 pm)
Viva la 1.5!
#30
I've done that and I currently have an almost complete inventory system and other features that rely heavily on ShapeBase.
Now the plan is to eventually move to TSE. But if the TSE gets rid of ShapeBase, then what happens to all the work already done? Two choices, stick with TGE or port to TSE and re-write a lot of code.
Don't get me wrong though, I wan't TSE to be the best game development platform just like everyone else does, and if I have to re-write a lot of code I'll do it, I just want your input on this since it hasn't been discussed and this seems like the right place to do it.
Nick
11/15/2004 (10:43 pm)
Ok, I have a concern here. While I fully agree with Ben's and Josh's posts in the beginning of the thread...Quote:"If you already have a project that is based heavily on 1.3, don't worry about updating to 1.4 if you don't have to"
"So, no cause for concern for most people here. If you have a stand-alone project (like a game) that's working on Torque 1.3, stick with 1.3."
"So I'd say, pick a stable version and start writing your game."
I've done that and I currently have an almost complete inventory system and other features that rely heavily on ShapeBase.
Now the plan is to eventually move to TSE. But if the TSE gets rid of ShapeBase, then what happens to all the work already done? Two choices, stick with TGE or port to TSE and re-write a lot of code.
Don't get me wrong though, I wan't TSE to be the best game development platform just like everyone else does, and if I have to re-write a lot of code I'll do it, I just want your input on this since it hasn't been discussed and this seems like the right place to do it.
Nick
#31
We now have repositories for:
art
audio
engine source code
server side scripts
client side scripts
standalone scripts (for editor use)
distro-win
distro-mac
distro-linux
design docs
Additonally, we used a capability of SVN to allow for external modules that can be assigned as part of a "master checkout"--if, for example, an artist checks in some new work, everyone that checks out a client env (or updates their working copy) automatically gets the new art as part of their client environment. The repositories are also set up by access requirements: developers have access to the engine source code (licensed TGE owners only of course), and the server/client side scripts, while a level designer might only have client/server side scripts, and art. A GUI artist is only concerned with client side scripts and art, and a project manager/marketing guy would have the design docs and a selected distro.
To top it all off, we have email messages sent every time something is committed to a particular repository, and can selectively send this emails to the appropriate people who need the information.
Another thing that is simply amazing is the ability to branch off code lines, and merge them back in later. Pretty much anyone that uses a version control system eventually has some work that they have to stop to handle something with higher priority, or possibly have a very experimental thing they want to try without causing undue stress on the rest of the team. For example, I'm working on getting the Terrain Manager up to TGE 1.3 capability, and it is a 5,500+ line merge over dozens of files--and something that could break just about everything everyone else is working on in the progress of implementation.
To handle this, we created a branch off our main development line where I can break things to my heart's content without having to worry about anyone else getting the main development line taken out of commission. I was even able to pause working on the tpager branch when the RTS kit came out, and integrate that back into our main development line, completely bypassing the tpager stuff, with the intent of merging the tpager branch back into the main line (which has the RTS stuff already) automatically.
Yeah, I can't see how anyone working on a project in a team environment, especially with remote folks could deal with not having version control.
11/15/2004 (11:06 pm)
Quote:I had experience using CVS in the past on a large project, but nothing in comparison to the tricks we've learned with SVN.
Absolutely true. I know of companies where they keep every document, not just code, in version control. It lets them avoid issues along the lines of "I lost business plan X!" or "My hard disk crashed and now I can't get to my docs!" All they have to do is a checkout and they're back in business.
Version control when used properly can be amazingly powerful. It's well worth learning if you plan on doing any sort of serious work with text files. It's the difference between making them do what you want, and making them sing while they do it...
We now have repositories for:
art
audio
engine source code
server side scripts
client side scripts
standalone scripts (for editor use)
distro-win
distro-mac
distro-linux
design docs
Additonally, we used a capability of SVN to allow for external modules that can be assigned as part of a "master checkout"--if, for example, an artist checks in some new work, everyone that checks out a client env (or updates their working copy) automatically gets the new art as part of their client environment. The repositories are also set up by access requirements: developers have access to the engine source code (licensed TGE owners only of course), and the server/client side scripts, while a level designer might only have client/server side scripts, and art. A GUI artist is only concerned with client side scripts and art, and a project manager/marketing guy would have the design docs and a selected distro.
To top it all off, we have email messages sent every time something is committed to a particular repository, and can selectively send this emails to the appropriate people who need the information.
Another thing that is simply amazing is the ability to branch off code lines, and merge them back in later. Pretty much anyone that uses a version control system eventually has some work that they have to stop to handle something with higher priority, or possibly have a very experimental thing they want to try without causing undue stress on the rest of the team. For example, I'm working on getting the Terrain Manager up to TGE 1.3 capability, and it is a 5,500+ line merge over dozens of files--and something that could break just about everything everyone else is working on in the progress of implementation.
To handle this, we created a branch off our main development line where I can break things to my heart's content without having to worry about anyone else getting the main development line taken out of commission. I was even able to pause working on the tpager branch when the RTS kit came out, and integrate that back into our main development line, completely bypassing the tpager stuff, with the intent of merging the tpager branch back into the main line (which has the RTS stuff already) automatically.
Yeah, I can't see how anyone working on a project in a team environment, especially with remote folks could deal with not having version control.
#32
11/16/2004 (5:54 am)
@Nick: Like I've said... We're going to keep ShapeBase around until 1.5. This is a pretty big amount of time. And even when we stop officially supporting ShapeBase, it's still probably going to work just fine. _And_ TSE will be following that same dev pattern, so there will be a time during which it will support ShapeBase as well. So if you need TSE, go for it. We're trying to keep TSE and TGE on the same playing field insofar as non-graphics features go.
#33
Nick
11/16/2004 (6:06 am)
Thanks Ben! I already have TSE. So I'll stick to plan and port to TSE sometime in the next couple of months.Nick
#34
I've used CVS in the past and have my stuff there now. Can you recommend any good resources/books on transitioning to Subversion? Have any internal SOP's (standard operating procedures) for setting it up that you would share?
11/16/2004 (12:42 pm)
@StephenI've used CVS in the past and have my stuff there now. Can you recommend any good resources/books on transitioning to Subversion? Have any internal SOP's (standard operating procedures) for setting it up that you would share?
#35
I thught TSE was an add-on for TGE...to add better new shader support, normal mapping and maybe all DX9c features to TGE.
But from some post it sounds like TSE is a stand alone new version of Torque?
help :)
11/19/2004 (7:26 am)
Getting a bit confused, new to Torque sorry.I thught TSE was an add-on for TGE...to add better new shader support, normal mapping and maybe all DX9c features to TGE.
But from some post it sounds like TSE is a stand alone new version of Torque?
help :)
#36
11/19/2004 (7:38 am)
TSE includes TGE as it's base, but improves on the render pipeline.
#37
Torque Shader Engine.
Yes its an engine, and yes theirfore its standalone from TGE.
11/19/2004 (8:02 am)
Read it as it sounds..Torque Shader Engine.
Yes its an engine, and yes theirfore its standalone from TGE.
#39
11/21/2004 (12:55 am)
I hope TSE will have some good physics on most game objects when it's out of EA. The Source engine seems to be the best engine out there, and it has a full SDK to create almost everything you would use in a game(XSI, Hammer, FacePoser, ect). I'd reallt like to see TSE be compareable to the Source engine. 
#40
I've worked with Havok numerous times on stuff for retail... it's out of range for most/all independent endeavors...
-J
11/21/2004 (1:30 am)
The Source engine uses Havok physics which was $50,000 to license that last I heard...I've worked with Havok numerous times on stuff for retail... it's out of range for most/all independent endeavors...
-J
Associate Joseph Euan