Torque Development Plans

#1 Sounds great!

Will these changes eventually migrate into the TSE codebase?

#2 Thanks Ben for creating this thread. As I see, it has been mentioned that there is going to be big changes changes in the COM, scripting, interface, etc. I would like to know if there is a description (at least at a general level) of the major changes planned to be made.

The purpose of that, is to help us to evaluate the best strategy to keep developing our projects with a minimal impact. Also this milestone roadmap will help us to being able to identify which resources will continue to work and for how long.

#3 @Ben
I think i come pretty far in my devlopment ,does this mean i need to worry about all changes in 1.4 .
Or do you suggest that i still go with the version i use ?
This could save time if i only knew some of the common changes.

Any answer is great !!

#4 We have internal plans for the next several (minor) versions of Torque. But as a matter of policy we're only going to be releasing firm information about the current version in development, and tentative plans for the next version. We don't want to promise more than we're going to deliver, and long range plans like that tend to change pretty dramatically.

As I've mentioned a few times before, we are going to be trying to do a new release every three months. So you should be seeing three to four versions per year. This means that each version is going to be pretty tightly focused:

For 1.4, our focus is on editors and ease of use.
For 1.5, our focus is on the component system.

There's lots of miscellaneous stuff happening, and we'll be fixing bugs as we can, but those are the main driving goals in our development for the next two versions.

In terms of concrete development, I'd say - 1.3 is good. If you develop a serious game on Torque, you will find bugs. As with any large piece of software, doing real work on it will reveal limitations the developers never knew about. If you develop a serious game on unreal or quake, you'll find bugs. If you do a serious web app you'll find flaws in your server software. The same holds for Torque.

So I'd say, pick a stable version and start writing your game. If you find a fix or feature you need, be prepared to port it in. If your project will be longer term (longer than a year or so) you will probably want to budget some time so you can upgrade or at least backport features and fixes from newer versions of Torque. Though this is not necessary. ThinkTanks, for instance, runs on a way old, heavily modified version of Torque, and it does pretty well. Orbz and Lore only update occasionally.

Summary: Pick a version of Torque. Write your game on it. When your game is done, consider whether you need any of the new features. Realize that the merge process will take a while and require more QA work. If it's worthwhile, then do it. Otherwise, don't. Each game is different and there are succesful games that have gone either way.

As far as resources go, what I would like to see is some sort of system where people mark them as working with different versions of Torque (ie, ,"this resource works with 1.2 and 1.3" or "this resource is 1.4 specific"). Eventually having the website do this would be snazzy but there's no reason people can't just say what version of Torque they developed against... and you often find in the comments people explaining how to update to work on newer releases.

As for TSE, we do regular merges with TGE, usually when we label new versions. We aren't going to keep TSE/TGE 100% in synch, and we aren't going to move fixes over as they're made, but we will try to keep them within a month or two of one another. This will be more of a priority once we're out of EA mode - ie, once the heavy infrastructure work is done.

#5 Billy, if you've come pretty far in your project's development, you don't need to worry about changes in 1.4.

If 1.3 is getting the job done for ya (and it will for most everyone), then stick with it. You might want to backport a fix or feature or something from 1.4 later on, but it's nothing major to worry about.

That basic advice applies for everyone. 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. And, you'll almost never *have* to. If you just *want* to keep entirely up-to-date, that's fine too, but it's not like you're being forced to by any stretch of the imagination.

As far as costs for updating go, the only people that really have to worry about that kind of stuff are our third-party Torque developers, who create extensions of, content for, tools on, or documentation of Torque. People like Clark Fagot, John Kabus, Justin Mette, Dave Wyand, Melv May, Ed Maurina, Ken Finney, etc who need to make their product work with each new version of Torque. But, we will work very closely with those guys to help make new upgrades as easy as possible for them. Both Ben and I will devote energy to helping them make the transitions as smoothly as possible, since it's in all our best interests to have the third-party products stay up-to-date.

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. The same advice will always apply, no matter the current version of Torque. On your next project, you can happily know that there's a new stable version of Torque with lots of enhancements and fixes that you can use as a base for the new endeavor.

#6 Well said, Josh.

You never _have_ to update. Do what makes sense for your project.

#7 Superb guys !
I really happy about all information you both gave me !
This is very helpful in my way to move forward .


Thanks both !!!

#8 Can you post some info about features of 1.4?

#9 I can give a little bit of an overview. After the RTS Pack has shipped, I'll be posting some .plans talking about what we're doing in detail. But in gross, we are working on building up a lot of editor infrastructure. This sort of thing is needed for several of our upcoming products, so we decided to do it at the start. So, new GUI controls for editors, some work on IDEs, and so forth. We're also preparing for the component system, which involves lots of little changes to the engine - mostly moving away from assuming ShapeBase.

There are also lots of incidental fixes that will happen - little fixes and upgrades here and there. Better error reporting and handling. Overall, we want a much cleaner, friendlier Torque when we're done with 1.4.

Beyond that, best to wait for my .plans. They'll go into much more detail.

#10 Thanks Ben for creating this thread. As I see, it has been mentioned that there is going to be big changes changes in the COM, scripting, interface, etc. I would like to know if there is a description (at least at a general level) of the major changes planned to be made.

The purpose of that, is to help us to evaluate the best strategy to keep developing our projects with a minimal impact. Also this milestone roadmap will help us to being able to identify which resources will continue to work and for how long.

#11 Huh, I could swear I had posted a reply to this yesterday. Wait... scrolling... up I find that I did. :)

#12 Sorry about it....Looks like when I refreshed my screen I sent the message again.

#13 No worries. :)

#14 So Torque 1.4 will be closer to a "Torque Game Studio" IDE ?

#15 With the new component model, would it be easier for me to work on the streaming interiors than it is now? It's mainly an organization question since I don't *have* to have streaming interiors for what I'm doing now (I'm building my interiors in pieces for future implementation, but for the time being it doesn't matter. Streaming the interiors is an immersion factor, not a gameplay factor for me. If it will be easier to find the necessary pieces to put together than it currently is, then I'll wait on that. I have enough work to keep my busy until 1.5 regardless (and then I would know the exact content that I'm going to be streaming).

I have a feeling that while writing this, I just made up my mind. But I'd still like to know from an organization standpoint. I'd especially like to know if it would make integration of products like the RTS pack and Lighting pack easier by compartmentalizing the code. There are a lot of people who have trouble implementing the lighting pack though John has taken some time to write up very clear documentation. I think that a lot of the problem comes with a huge sourcebase that's confusing to sort through (as is the case with any large source base).

#16 @Bruno: More or less... We're still going to sell the engine as a source license, but for some of the other projects we want to release (like T2D) we need good editors, so that's the driving motivation.

@David: No, the component model won't really affect that. It's a code organization change more than any sort of functionality change. The biggest win from it is that code is packaged in more manageable chunks, so it's easier to write content packs and reuse code.

The component system does not address the issues with the lighting pack.

It will make the RTS starter kit a more viable product, though.

Basically, the component system will address the same issues that ShapeBase does, but more elegantly.

#17 What kind of improvments are planned for the player and vehicle classes?

#18 Sounds good. I'm all for elegance. I'll keep looking through the source with the interiors in mind, though I may move that to a later point and layout my maps with it in mind. If I end up seeing that a good portion of my work will be with the shapebase source, then I'll probably wait on it while I work on the rest.

It will be nice to have new editors. I'd love to see a cross-platform map editor that's not Radiant (but of course, I wouldn't love to see it enough to actually make one myself).

Sounds like some very good news down the road, though!

#19 @Josh:

Ever, or in 1.4/1.5?

@David:

I strongly advise you and everyone else not to wait for future Torque releases to do your game. There's always good stuff just around the corner. You could very reasonably make the case that you should wait for Torque 1.8 or further before you start your game, but that would mean a year and a half wait before you could even begin... Time is a luxury indies don't have.

#20 Oh, I'm not waiting to work on it. If I did that, no progress would be made. I was just wondering if waiting for release x would help me be able to better assess how to work with interior streaming. That was all.

I'm creating all of my interiors in pieces in Quark right now and loading them into the 1.3 base with the lighting pack. The streaming interiors are simply an immersion tool that I prefer to load screens, but they're not necessary. If they are easier for me to sort out and organize with the 1.5 shapebase organization, I'll wait until then to work on that part. But I've got enough on my plate currently to work on without dealing with interiors in that way. My prototyping is based on the default mission loading that's been there forever. It's more than adequare for my prototyping needs whether it has all the bells and whistles of streaming that I'd like or not.