Torque 3D Development - GDC Live Edition

#221 @Matt Fairfax: thanks for clarifying a lot of points!

While you are nice and in the answering mode, could you, please, elaborate a bit on the following T3D feature (web deployment): say, I added few custom DLLs to my game (so it's not a vanilla T3D code base) and want to deploy it as a web project - will the web launcher do the following:
1) Can the web launcher use compressed files, so it does not download raw binaries to save bandwidth and user's time?
2) Can the web launcher perform installation of additional DLLs or it's constrained to one executable+resource file?
3) If user has T3D web launcher installed (from someone's else game) - will it download my game or user will have to install my version of the web launcher?
4) If user had previous of my game version installed - can web installer download the missing DLLs (delta update) so he/she can run the latest of my version?
5) Is there a way to sign my binaries so it's secure to the end user and no middle man replacing my binaries during download process?

Thank you!

#222 Torque has been being devoloped for almost 10 years(may be inaccurate:).
TGE - ver 1
TGEA - ver 2
Torque3D - ver 3
So I think Torque should already just be what the demo shows some months ago or one year ago.
I am eager to this day for a L-O-N-G~~~~ time, and now, the day comes, Happy!!!!
Thanx GG, and all who contributes to!!!
Great Day!

#223 I'll have to defer some of these to Josh (who is actually implementing the web deployment but here is what I know):

Quote:
1) Can the web launcher use compressed files, so it does not download raw binaries to save bandwidth and user's time?

The installer will compress your files for you automatically. In addition to this you should be able to use compressed ZIPs inside your game structure to further control the compression. I say should because it has been a while since the Torque ZIP code has been touched and it may need a little love.

Quote:
2) Can the web launcher perform installation of additional DLLs or it's constrained to one executable+resource file?

Yes, one of the powerful things behind our approach is that you can customize the installer to do addition actions like check the DirectX version or prompt the user to install PhysX. Getting to that level of customization will take some work but are all totally feasible.

Quote:
3) If user has T3D web launcher installed (from someone's else game) - will it download my game or user will have to install my version of the web launcher?

The user will have to install your version of the web plugin. I've been led to understand that it will be possible for the user to reuse your plugin if they play another game by you (with some tweaks on your end). This is different from the ubiquitous "players" like Flash but it allows you a lot more personal branding and offsets the dangers of a distrusted/malicious web plugin reflecting badly on you (or GG =).

Quote:
4) If user had previous of my game version installed - can web installer download the missing DLLs (delta update) so he/she can run the latest of my version?

I'll have to defer to Josh on this one.

Quote:
5) Is there a way to sign my binaries so it's secure to the end user and no middle man replacing my binaries during download process?

I know Josh has added some security features like not allowing the web plugin to run unless it is on your domain/server but I am not sure of the full range. Again, I'll defer to Josh on this one.

#224 3) You specify your own MIME type and/or CLSID which avoids collisions... it is easy to tweak the plugin to support multiple games if it is desired.

4) A patching solution (including backend) is outside of the scope of the web deployment release. You can use whatever patching solution you would like... for simple updates, I would generate a MD5 of the files against however you store your files remotely... and then use libcurl or a similar file transfer library.

5) You can lock your plugin to only run from certain domains (which is compiled into the binary and can be toggled during development). Also, there is function level security for specifying exactly which TorqueScript functions can be called from JavaScript (and you can call any JavaScript function from TorqueScript).

- Josh

#225

Quote:@Tyler, well, running PhysX accelerated on any GPU isn't necessarily going to give you the benefit you think it is. Anything that is related to gameplay-affecting physics will not benefit from GPU acceleration, because the round trip* will kill your performance (i.e., player ragdolls, if you want them to affect gameplay, would not be helped by acceleration on the GPU). It does, however, give you a benefit for things like debris particles and the like, that do not affect gameplay (allowing you to do more of them). So, the benefit is pretty minor, really.

So what I'm saying is, GPU acceleration allows you to have more "stuff" but doesn't allow you to have said "stuff" also affect gameplay in a meaningful way. Example: You have a stone building that consists of blocks, each being a PhysX actor. If you want the blocks to influence the player's movement, you're going to be killed in terms of performance because then you're doing CPU -> GPU (update the blocks) -> CPU (do whatever you want to happen when one hits your player) -> GPU (update the blocks based on the result of whatever you just did). Trying to do that in a single frame will tank you.

* - Round trip, i.e., do the physics for a ragdoll, then get the results in order to check something related to gameplay (such as whether or not a projectile hits a certain PhysX actor).

I did not say it would make better gameplay. I said (and quote):

Quote:Better physics = better games.

Never said better gameplay. Only better games. Yet I would like to point out that this is exactly what OpenCL does. It allows the physics to actually have minor effects. Minor of course, but still good enough.

P.S. I highly doubt that someone would create a .dif shape block by block. And then place the buildings throughout the game. That alone would kill the game, no need for physics to do that.

#226 @Tyler, I wasn't responding specifically to your one line there. *shrug*

#227

Quote:I think it's highly unlikely NVIDIA will make a significant push with PhysX in the direction of OpenCL. Mainly because it is from marketing perspective, at the current moment, direct competition for CUDA; also it quite a new standard. Ultimately it is up to NVIDIA. PhysX currently comes with direct hardware acceleration through CUDA drivers and when/if PhysX gets "ported" to OpenCL it will probably require no additional coding to enable, similar how CUDA does it now.

Here are my sources:

games.slashdot.org/article.pl?sid=09/03/29/1621252&from=rss
www.bit-tech.net/news/hardware/2009/03/27/nvidia-considers-porting-physx-to-open...
www.overclockersclub.com/news/24389/
www.madshrimps.be/vbulletin/f22/nvidia-considers-porting-physx-opencl-62564/
www.thetechlounge.com/news/13612/OpenCL-May-Get-PhysX-Port/

There are a few dozen more, just do a search for 'PhysX OpenCL'.

#228 @Matt Dix

I think we're saying the same thing. The code needs to be solid before it becomes widely available for demonstration purposes. That was the main impetus behind my post.

Yes, I would rather have the development team focused on the product, and if running both an alpha and a beta will require too many resources, then I'm afraid that my vote would be to push the beta as late as possible, with feature set as complete as possible, if not frozen.

As Matt F. said in reply, it sounds like it's quite possible (but certainly not definate) that we will get demos that become available at some point after the first (if only) beta becomes available, but before launch, as things become polished. That would be fantastic, as it provides the main point of what I was asking for: to be able to evaluate the demos during the pre-order period of an engine version that is fairly close to shipping level of quality. If GG can do that with only one beta period instead two, then fine by me! It won't affect me anyway; I don't plan on purchasing until the demo is available. ;-)

Ryan

#229 I haven't seen anybody ask specifically about this, so I figured I might as well. ;-) Actually two related issues:

1) There was a mention that TorqueScript execution has been enhanced. Can some details be shared on this, like what has changed, and what kind of speedup percentage has been observed? Has memory consumption and/or heap management been improved?

2) During this work, was TorqueScript integration refactored so that it is:

a) less tightly coupled to the core engine (ie more modular)
b) refactored to more easily allow a different, pluggable script engine impl?

I believe one of Unity's strong selling points over TGEA is that it supports a choice of scripting engines, offers Mono C# scripting, and most improtantly, implementing your own script plugin is straight forward as the plugin architecture was engineered to support this from the start.

A few years back I did substantial research into TGEA code base to replace TorqueScript, and it didn't take long to determine that the way it was implemented, I'd be looking at a MAJOR engine change that I'd never be able to maintain over time with TGEA updates.

Is anything like this happening in T3D, and if not, is it on the roadmap? At a minimum, by the time the component model refactor is done, I think TorqueScript should just be a stock implemetation of the script engine component, and people should be able to write their own and replace it at runtime.

Ryan

#230 I wonder, will it include a Emitter Mesh (in particle system) ?

"Emit particles at any vertex, along any edge, or the surface of any polygon."

Guess most basic way of saying it is, its a particle emitter that emits particles over a object surface (like glued) instead of just spraying it in a fountain.

Would allow for some sweet visual FX..

While at it, did we even see any particle systems in use yet (beside soft particles and a few explosions in the bad video's :P), particles is a big thing these days :) ?

#231 IMHO OpenCL is a temporary solution, much more important looking forward to next-gen pc and consoles designs is swarm/job systems. If you've seen the larrabee api or working on PS3 spus, you're have some idea what I'm talking about. OpenCL is just a cross platform way of solving the easy parallel problems, like physics and graphics.

I'm tempted to implement a job system into Torque3D if it doesn't come with one, as this is IMHO the future of all computation models (at least under C++). FYI the army stuff I did in Heavenly Sword had over 1000 jobs per frame, and that number of items was only limited by memory considerations.
For really parallel systems, things like dependencies, communication and self-hosting are the vital things to worry about. We need to be looking a kilo jobs number per frame in the next 5 years, which really is a paradigm shift..
Would make a good GDC talk...

#232 Well, I assume that OpenCL will be easy to implement into Torque. So even if GG doesn't put it in officially, I would still like to see someone make a resource that enables it.

#233 I think it was in the other previous blog, but in one of the posts it was noted that a number of the TGEA/TGE resources have been added to T3D. Specifically mentioned was advanced camera and support for walk/swim/crouch animations. The poster wasn't sure about climbing.

A couple questions:

1. Is the code for swim animation for swimming on the surface only or does it also support underwater swimming?

2. Is support for climbing included?

3. Is there any melee code included in T3D?

4. Are any of the various A* pathfinding resources included?

5. Is there a list of TGEA/TGE code resources now being included either fully or partially in stock T3D or one of the genre packs that you could share with us?

Thanks in advance...

Peter

#234

Quote:
1. Is the code for swim animation for swimming on the surface only or does it also support underwater swimming?

It supports underwater swimming.

Quote:
2. Is support for climbing included?

No.

Quote:
3. Is there any melee code included in T3D?

Sorry...no. This is high on our list for when we tackle the RPG Genre Kit.

Quote:
4. Are any of the various A* pathfinding resources included?

Not as of yet and probably not by release.

Quote:
5. Is there a list of TGEA/TGE code resources now being included either fully or partially in stock T3D or one of the genre packs that you could share with us?

I'll try to put together this list before release.

#235 @Matt - Thanks for the quick response! A list of included resources at time of release would be greatly appreciated - thanks...

#236 Will all these Genre kits come with seperate SDKs and are they expected to come with merge documentation?

#237 Hope so :P

Consider 3 Genre kits, you need something from all of them, then you will have a hard long time to seperate the code belonging to each..

Kinda hope its "plug'n'play" kits, even if you need to add 2 or 3 into one :P

Or like folders

Engine Src Folder
|->DX9whatever
|->Somewierdthingsrc
|->GenrekitNameSrc
ect..

And then you just cope that folder over in your src folder and read a doc on how to implement it into engine src (what to change).

Well, something like that, else it will quickly become very messy..

Just thinking out loud :P

#238 Until the component refactor is complete, which at best sounds like the T3D 2010 release ~13 months from now, I wouldn't expect this to be any cleaner than it has been in the past. If this is not going to be the case it will be great to hear.

Even if there is excellent documentation, at the end of the day you still have to do the merge yourself, potentially 2-3 times until the next major release (due to mid-year updates). If you are using 2-3 kits, that could be a lot of work you have to keep doing over and over.

I am cautiously optimistic that when we see the component refactor, that most if not all kits (designed to work with that version) can simply either augment, extend or replace standard components within the engine, and source-level merging as it as existed in the past will become, well, a thing of the past. Anything short of that will, IMO, represent a failure of the new model. Kits and their incorporation should be one of the major considerations in driving the new component model. Certainly not the only consideration, but it should be a major one.

If it's done right, it will be a real boon for both GG and kit developers. The reason I haven't built kits for TGE / TGEA is because it's a nightmare to manage and maintain, I don't want to deal with the support headaches. But if there was a proper architecure in place, that would definately change my mind. I can't think I'm the only person with that attitude. So while I'm excited about T3D 2009, I'm *really* expcited about the component refactor hopefully coming no later than T3D 2010.

An interesting thing to keep in mind is that when we do see the component refactor, clearly all existing kits will essentially have to be refactored as well, if the component refactor is going to meet the goals I've outlined above. As such if you buy kits A, B and C for T3D 2009, there is a good chance you'll be looking at completely different versions for the T3D "refactor".

A kit that is code heavy as opposed to art heavy will therefore probably be a significant refactor, and therefore simply handing out new instructions on how to merge a 2009 kit with a potential 2010 refactor simply won't be realistic.

In other words folks, I would get used to the idea of seeing kits being marketed as something like this

"XYZ Kit for T3D 2009"

and not

"XYZ Kit for T3D"

And just like you are going to get dinged a bit each year for the T3D 20xx upgrade, you should budget for the 20xx Kit upgrade as well. It's only fair. Kit developers gotta eat too. ;-)

Overall the new yearly release model and pricing model is going to be a great thing. We're going to start seeing yearly major releases annouced and possibly even available at GDC timeframe. Kit developers can show off their shiny new versions of the kits as well at GDC. And most imporantly, in order to keep that yearly revenue stream up, the developers (whether GG or 3rd party) are going to have to add real, concrete value into the product in order to keep getting that upgrade revenue. People simply won't upgrade otherwise.

I think this would result in not only more 3rd party kit developers, but higher quality ones. There is no better motivation than cash, and people who receive excellent support tend to upgrade more than those who receive crappy support.

Ryan

#239 Hey guys, have couple of questions.
First of all, i have a small studio, here is our web site: http://www.psychozinteractive.com We are finishing our first game and are looking for our next development environment.

- Is Torque 3D a general purpose game engine? Or is just a game with source code and tools? Sorry if am asking this, i tried TGEA in the past and i had very bad experiences from it.
- How different Torque 3D is from TGEA?
- What about the asset integration. How easily can animated characters be integrated into the engine? Is there any limits on rig hierarchy? Bones limits? Mesh limits?
- I heard that collada is supported, that's fine, but what about animated characters imported into Torque 3D with collada?
I don't really care if the engine comes with or without Forest kit. We are looking for a cleaner and decent code to add our own "Game classes and functionality".
Tanks for your time.

#240 I read that T3D will have the ability to create games even without the source(Basic version) I do have pro, but that brings to mind a good question. what will the "out-of-the-box" additions be?

Will there be a dialog system?

A melee system with the expandability like Josh Moore's resource?

A camera system for different effects...fp, 3rd, orbit, Godview, plus controlable lagging?

Optimized shape replicator with alphaLOD, twSurfaceReference, Clustering, mulitple models, already built in?

Optimized foliage replicator with twSurfaceReference, clustering and multiple objects? I've even heard Melv say that it can be optimized...I just don't know how to do it.

Are DTS objects/and DIF for that matter, going to have anything like alphaLOD?

Dynamic Script, texture and object loading. (So you don't have to reload your game each time)

Terrain shaders? Accumulation shaders for all objects...dif, dts, terrain?

Upgraded Projectile system (bouncing off different typemasks, lasers, timed projectiles, sticky projectiles)

A partile editor that can actually save the partiles you create to a .cs?

And the kicker....organized documentation
An organized dictionary..."Torqtionary"...would be great. Basically a Help file with the %randomObject/scriptObject/datablock/feature.dump(); setup in an easy-to-use, alphabitical or search index. With an example that you can easily slap in a cs file and exec it in a mission. It would explain all the fields, tagged fields and functions like your dump does, but also give some context to the item in question. You use this here, for this purpose. See Also... Like old school Qbasic help!!! F1!