Torque 2D Future Plans

#21 I had a feeling it was possible, but there's no documentation or example anywhere. I think it just goes to prove my point though. The post function is missing from the TCPObject and if you want to use post you'll have create your own post function in script. I suggest we modify the TCPObject to include a post function directly.

BTW, I would love to get a look at that post function. If you could put it up in a new thread I'd be grateful. I don't want to hijack this one.

#22 Any desire to see a basic Qt webkit implementation? This would add three features:

1. Interactive GUI controls that can load web content (local and online). Think a GUI control built using HTML or Flash or a control that can load and play YouTube videos.

2. Basic file downloading. The beginnings of an optimized patcher.

3. A "foot in the door" with Qt. While not all features would be implemented, there are a lot of components to Qt. A basic implementation opens the door to future work.

#23 @Mich : I have dreamt of integrating Qt into T2D for a while (mainly as a first step to replace the renderer with OGRE3D as well.

However, I have had the worst luck with Qt and fear that including it in T2D will clutter up a pretty clean structure. Still would like it though.

#24 I've seen two implementations in the T2D framework in the past. Both times were really clean and simple. I'd like to utilize an existing implementation, but I'm waiting on permission. That's putting the cart before the horse, though.

Right now I want to find out who all would consider the feature useful for the engine. In general, it's a good idea to start building up a list of engine features to plan out the roadmap.

#25 HTML rendering and downloading would also be useful for editor work. I don't necessarily mean creating the editor itself in HTML, but having the ability to display video tutorials, a store, and sites related (GG.com, GitHub, etc).

Speaking of editor work, a feature that would a HUGE help would be the ability to spawn multiple Canvas controls in separate windows. I believe T3D can already do this. Thoughts?

#26 Well, I'd like to officially withdraw my request for some sort of auto updater to be built into T2D. I spent the last week or so heavily modifying WinSparkle so that it could be integrated with the game engine. After all that work, actually using it still didn't feel right. The game checks for an update on start up and downloads the new installer (all integrated right into the game) but then the game quits and runs the installer. Once I could see it in action I realized that it still wasn't as smooth as I wanted. I realize what I really want is a nice launcher. I'm going to try Karazeh but I'm really surprised that there's not a more highly supported launcher out there. It seems like most people just end up rolling their own. Maybe it's a testament to the fact that many indie games are never finished and those that are finished are not perpetually updated.

Anyway, my point is that an auto updater as part of T2D is not needed.

#27 @Peter - Good feedback, thanks. When GG was developing 3SS, we went through the same technical process. I was initially in support of an external launcher, like Battle.net and the League of Legends launcher. I believe League uses Pando Media Booster for a lot of the backend, but it wasn't a good fit. It was ultimately decided to have a built-in updater, which presented the technical hurdle you encountered.

This is how the module and asset systems came about. When the user downloaded 3SS, they initially got two or three modules that were core. As long as these did not have to be patched, the editor/game did not have to shut down. New or updated modules could be reloaded easily once acquired. If the core, editor, or updater modules change, then the entire executable had to restart.

I'm still a fan of a patch system in T2D, but more people need to weigh in to discuss the technical requirements and purpose.

#28 If there are no good patch systems out there for independent developers, then having one that works with T2D with minimal effort might be a good way to attract more developers to our engine. Certainly an idea to consider for anyone in the community who is interested in contributing to T2D.

#29 I suppose if there was an update module that could be run before the game starts then that would work. Normally I don't find it necessary to update the executable and the updater module would be mostly a front end for the actual updater running in the executable.

Anyway, there's definitely a hole here. The problem is that most developers don't think about delivery or updates when they first start a game. By the time they get to release they just throw together an installer and call it good. I would like to release games incrementally in the smallest possible chunks which means the way updates are pushed to my users must be solid out of the gate.

If T2D is able to solve this problem I think it would definitely give the engine a selling point.

#30 I've written a basic updater (using AutoIt) and it really just consists of a few basic things:

- A tool that gets run against the most up to date version of your game which creates a manifest with the file name/path of every game file, along with its MD5.
- You upload the most up to date version of your game to a public server, along with the manifest file
- A prelauncher for your game which download's the manifest and for each entry in the manifest, checks to see if the file exists in the game directory. If it doesn't, download it, if it does and the MD5 doesn't match, download it. The prelauncher then launches the now up-to-date game.

It only took me about 4 hours to write in AutoIt, which unfortunately is windows only, but it shouldn't be too much work for someone to write in T2D source.

As far as feature requests, I would like to request a detailed document on how to go from a TGB game to a T2D one. The reason I ask is that I've been working for 4-5 years on a game in TGB and it is an MMO that hopefully will be updated regularly for the next 5 years, but I want to take advantage of the T2D features and don't have the time to invest in rewriting the whole thing. If I had a detailed guide, I feel like I could side-step a lot of the issues I would encounter and the conversion would go much faster.

#31 Taking a TGB game and porting it to T2D isn't a trivial task - writing a guide for that would be equally challenging. In some ways, just making a simple prototype in T2D MIT will give you a good feeling for the amount of work one would need to do to port a finished or near-finished game to it.

Some stuff off the top of my head:

1. First you would have to decide how to package your game within the module system.

2. All assets would need to be converted to use new asset system

• Changing datablocks to TAML
• Keep in mind not all static fields are the same
• Particle effects would have to be completely remade from scratch
• Only WAV audio files are currently supported

3. Every single SceneObject class is different now

• no more t2d prefix
• static and animated sprites combined into Sprite class
• no vector text object, it's bitmap based in MIT
• major changes in the physics system - affects collision shapes, mounting, world limits, link points, etc
• no tile maps or tile layers - have to use the CompositeSprite system instead, A* is also gone

4. TorqueScript will look and feel familiar, but you will have to learn what methods apply to each object

• behaviors work more or less as before, with the addition of behavior connections plus ScriptObjects and Scenes can now have behaviors attached to them

5. GUI objects are pretty much the same, all the new examples use TAML to build GUIs though

I'm sure there's plenty I've forgotten about in this short summary. The more you use T2D MIT, the easier it will be to assess how much effort it will be to port from TGB.

#32 Spot on analysis Mike. Two additional points:

1. Any mouse input you were using should be updated to use the onTouch__ callbacks.

Quote:Particle effects would have to be completely remade from scratch

This is true at a technical level, but if I had a project with lots of particles, I would not make them by hand. I would write a script for TGB that will go through each effect and its emitters, gather their properties, then write out to XML using converted fields/format so TAML could load them in T2D.

That's basically a couple days of tool scripting and testing, as opposed to days and days of hand building and running particles.

#33 Yeah, that sounds a lot better. I had gone through the TGB particle editor, wrote down each property, then hand wrote the TAML file - luckily it was only for about a dozen particle effects. Tedious all the same. When I saw the binary particle files in TGB, it never occurred to me at the time to export it in a different format, good tip!

#34 As somebody who is planning to convert this year I think it would be good to stick the information you just wrote in the wiki. Even if it's a direct copy it will help a lot.

#35 @Mike - thank you for the high-level overview. I agree with Peter. I think taking the pieces of knowledge about the conversion that exist in various steering committee members and other community members' minds and putting it into a public wiki would be a great start. Then people can constantly update it whenever they do a conversion project and hopefully it will be a useful document someday.

#36 Can't even begin to express how much I love automating conversions (of all sorts)! I am fiddling with a d20 Modern based RPG and there are a million tables in the RTF files. So instead of typing them all by hand I wrote an external tool to parse tables from RTF and emit TorqueScript (with the d20 license header text).

I'm tinkering with a GUI to TAML converter, too. The main thing is deciding on the fly how to convert types that no longer exist to compatible types, and how to convert datablocks to appropriate TAML assets.

I think that tools like this will be very valuable to community members who are still using the various legacy products.

#37 @Richard - that's an even better idea. I'd love to have a whole project converter but in order to write one you would need to know what all of the differences are which means something like a wiki would still be valuable. I have quite a bit of experience in automating things and could help out if I knew all of the differences in detail (and had a lot more time).