Torque 2
by Martin Schultz · in Torque Game Engine · 10/11/2007 (7:29 am) · 75 replies
Hey guys,
interesting article over at Gamasutra about yesterday's introduction of InstantAction and esp. about what the Torque dev team says about the next evolution of Torque called "Torque 2".
From what Clark Fargot said I won't expect Torque 2 before mid 2008.
Anyway, interesting stuff.
Martin :-)
interesting article over at Gamasutra about yesterday's introduction of InstantAction and esp. about what the Torque dev team says about the next evolution of Torque called "Torque 2".
From what Clark Fargot said I won't expect Torque 2 before mid 2008.
Anyway, interesting stuff.
Martin :-)
Thread is locked
#42
Doh? Just quickly searched over the employees page. Pat and Ben are still employees, but Brian Ramage is not there anymore and his profile says now associate. Has he left? Seems like. How sad.
10/11/2007 (11:13 pm)
From Marc's post above regarding TGEA: Quote:they lost their "head of R&D"
Doh? Just quickly searched over the employees page. Pat and Ben are still employees, but Brian Ramage is not there anymore and his profile says now associate. Has he left? Seems like. How sad.
#43
Giving my guesses at how the tech works - solely from watching the demo. I know as much as you guys about this, so dont take my word as truth. Stephen - feel free to chime in.
As I saw the demo, the tech is basically 3 things
* various backend services with webservice(?) interfaces that you hook your game up with
* a game shop/community browser system in a browser alike XBLAs game shell
* a download mechanism that hooks into the browser much like steam - just in a browser
So what does this mean - if I guessed right that is.
You develop your game using ANY engine or tech that can interface with the backend services. Want achievemenst? Hook into that. Need login? Hook into that.
The backend could have maybe 10 base services. With maybe 2-3 required to get the core system working. Your needs then decide what you use apart from that.
My guess at webservices is based on that they are fairly language independant (not really, but almost - standards constantly shifting and implementation differences).
So you can have a flash game, a Torque TGE game, a TGB game, a XXXX based game - doesnt matter as long as it can hook up to the webservices. If you could get e.g. Halo 3 to hook their game up on the core services, you could play that in IA.
You then bundle this all into a download package in some format specified by IA, and GG can make it available through the shop part.
The "steam" like service inside the shell does then handle sending the bundle out to your PC, unpacks it, installs it locally on your PC (most likely inside some internal repository only accessible through the browser game shell) and starts it up.
So it will LOOK like it runs inside a browser - controlled by the browser - but it is really running on your PC like any other application.
The really neat thing here is the game shell + the backend services. Who cares if it runs inside or outside the browser itself. Download mechanism is also a "who cares" part. If you can make community services in the game shell that work, if the backend services provide you with valuable services for your online community - great!! You dont have to code those yourself (I've tried, and its not easy to do it all yourself).
So think a XBLA like API providing your game with what XBLA provides on the 360 - just on the PC.
I wouldnt be surprised, if you also get a "game shell" that doesnt run in the browser - a "player" program, that hooks up on the repository to start the game from there.
So if I guessed right - again I only saw the demo like you guys did - then IA is XBLA+steam outside a console.
The main point of this? Its not about the tech - which is all neat. The question to ask is, if GG + IAC can get enough good games into this and attract the end users. All the other stuff is icing on the cake - "another portal" so to speak.
All about critical mass again.
Just my 2 euro cents worth of guesses.
10/12/2007 (3:24 am)
OK - stealing a Torque 2 thread to talk about IA.Giving my guesses at how the tech works - solely from watching the demo. I know as much as you guys about this, so dont take my word as truth. Stephen - feel free to chime in.
As I saw the demo, the tech is basically 3 things
* various backend services with webservice(?) interfaces that you hook your game up with
* a game shop/community browser system in a browser alike XBLAs game shell
* a download mechanism that hooks into the browser much like steam - just in a browser
So what does this mean - if I guessed right that is.
You develop your game using ANY engine or tech that can interface with the backend services. Want achievemenst? Hook into that. Need login? Hook into that.
The backend could have maybe 10 base services. With maybe 2-3 required to get the core system working. Your needs then decide what you use apart from that.
My guess at webservices is based on that they are fairly language independant (not really, but almost - standards constantly shifting and implementation differences).
So you can have a flash game, a Torque TGE game, a TGB game, a XXXX based game - doesnt matter as long as it can hook up to the webservices. If you could get e.g. Halo 3 to hook their game up on the core services, you could play that in IA.
You then bundle this all into a download package in some format specified by IA, and GG can make it available through the shop part.
The "steam" like service inside the shell does then handle sending the bundle out to your PC, unpacks it, installs it locally on your PC (most likely inside some internal repository only accessible through the browser game shell) and starts it up.
So it will LOOK like it runs inside a browser - controlled by the browser - but it is really running on your PC like any other application.
The really neat thing here is the game shell + the backend services. Who cares if it runs inside or outside the browser itself. Download mechanism is also a "who cares" part. If you can make community services in the game shell that work, if the backend services provide you with valuable services for your online community - great!! You dont have to code those yourself (I've tried, and its not easy to do it all yourself).
So think a XBLA like API providing your game with what XBLA provides on the 360 - just on the PC.
I wouldnt be surprised, if you also get a "game shell" that doesnt run in the browser - a "player" program, that hooks up on the repository to start the game from there.
So if I guessed right - again I only saw the demo like you guys did - then IA is XBLA+steam outside a console.
The main point of this? Its not about the tech - which is all neat. The question to ask is, if GG + IAC can get enough good games into this and attract the end users. All the other stuff is icing on the cake - "another portal" so to speak.
All about critical mass again.
Just my 2 euro cents worth of guesses.
#44
10/12/2007 (4:20 am)
I'm not sure if I got all of that but if it just looks like it is running in a browser and it is actually downloaded and running on your PC then does that mean you're limited to play on only one PC, so you couldn't just log-in and play games on any PC with a browser?
#45
10/12/2007 (7:21 am)
Best guess - something like steam. Where you log into the steam client, and it then can download to another PC.
#46
That's actually a perfect example. Of course, the first couple of iterations will be using TorqueScript, but exactly as you describe, part of the modular nature of the architecture is that yes, you can provide modules for whatever scripting language you wish, as long as they meet the interface requirements so they can talk to the other modules.
Additional scripting language modules are certainly on the table at this time.
Too big to quote in turn, but most of what Thomas said is pretty accurate. Some points I'll cover below:
Ultimately, this comes down to semantics. From the user's perspective, everything they interact with is browser based--the game shell, the back end services, and the game itself--all directly interfaced via browser.
Yes, there are multiple processes running, and yes, one of the "background" (in that the user doesn't interact with it directly) processes is YourGame.exe, but unlike normal Torque games, you aren't interacting with this directly--you as a player/user are interacting with your browser at all times.
Thomas, I personally understand fully what you mean here, but it's important in my mind to rephrase what you are saying so it's more accurate--instead of saying "who cares" about running in browser and how it's downloaded, I think it's much more accurate to say, "game developers and game players don't need to care about (running in browser, download mechanisms)--IA takes care of all that for a seamless developer and user experience".
Because when it comes down to it, the fact that the single user interface is a browser, and the download mechanism is a staged system where the developer can download their game in chunks based on priority to get the fastest "time to in game" metric they need for their game is the core of the "software console".
To give a semi-hypothetical use case (this works internally, but not ready for external yet): Let's say Thomas and myself are playing MBU on IA.Com, and Phil Carlisle comes online. Thomas can pop out to the game shell (stays in game, but new screen comes up), and email Phil a URL link of our currently running party/game instance. Phil can click on his link in his email, and after IA starts up, can jump right in to our game directly. We might then decide that we want someone else we know to play with us who has never played MBU on InstantAction before--get them the URL (email, PM, whatever), and after they log in to IA, it will automatically set up what they need, and feed them right to our party and game without spending massive amounts of download time and then having to search for us through a non-unified matchmaking experience.
The marketer in me doesn't approve of phrasing it this way, but IA does include many of the functionalities and capabilities of both of those services.
Absolutely you can. If the (new) computer you are on hasn't played that particular game before, then the back end will chunk stream the data you need on the new computer (which will also be cached for future use for what it's worth).
10/12/2007 (7:28 am)
Quote:
Anyways, a question I have is what scripting engines (it may be too early) are you all considering for Torque2? I do like using existing languages such as C# (learning curve) and the MMO guys love python and there's still quite a bit of support for TorqueScript. Is this a part of what you may refer to as modular? Possibly one or two official scripting implementations and the ability to plug in community-built scripting modules?
That's actually a perfect example. Of course, the first couple of iterations will be using TorqueScript, but exactly as you describe, part of the modular nature of the architecture is that yes, you can provide modules for whatever scripting language you wish, as long as they meet the interface requirements so they can talk to the other modules.
Additional scripting language modules are certainly on the table at this time.
Quote:
Lots of stuff from Thomas
Too big to quote in turn, but most of what Thomas said is pretty accurate. Some points I'll cover below:
Quote:
So it will LOOK like it runs inside a browser - controlled by the browser - but it is really running on your PC like any other application.
Ultimately, this comes down to semantics. From the user's perspective, everything they interact with is browser based--the game shell, the back end services, and the game itself--all directly interfaced via browser.
Yes, there are multiple processes running, and yes, one of the "background" (in that the user doesn't interact with it directly) processes is YourGame.exe, but unlike normal Torque games, you aren't interacting with this directly--you as a player/user are interacting with your browser at all times.
Quote:
The really neat thing here is the game shell + the backend services. Who cares if it runs inside or outside the browser itself. Download mechanism is also a "who cares" part. If you can make community services in the game shell that work, if the backend services provide you with valuable services for your online community - great!! You dont have to code those yourself (I've tried, and its not easy to do it all yourself).
Thomas, I personally understand fully what you mean here, but it's important in my mind to rephrase what you are saying so it's more accurate--instead of saying "who cares" about running in browser and how it's downloaded, I think it's much more accurate to say, "game developers and game players don't need to care about (running in browser, download mechanisms)--IA takes care of all that for a seamless developer and user experience".
Because when it comes down to it, the fact that the single user interface is a browser, and the download mechanism is a staged system where the developer can download their game in chunks based on priority to get the fastest "time to in game" metric they need for their game is the core of the "software console".
To give a semi-hypothetical use case (this works internally, but not ready for external yet): Let's say Thomas and myself are playing MBU on IA.Com, and Phil Carlisle comes online. Thomas can pop out to the game shell (stays in game, but new screen comes up), and email Phil a URL link of our currently running party/game instance. Phil can click on his link in his email, and after IA starts up, can jump right in to our game directly. We might then decide that we want someone else we know to play with us who has never played MBU on InstantAction before--get them the URL (email, PM, whatever), and after they log in to IA, it will automatically set up what they need, and feed them right to our party and game without spending massive amounts of download time and then having to search for us through a non-unified matchmaking experience.
Quote:
So if I guessed right - again I only saw the demo like you guys did - then IA is XBLA+steam outside a console.
The marketer in me doesn't approve of phrasing it this way, but IA does include many of the functionalities and capabilities of both of those services.
Quote:
I'm not sure if I got all of that but if it just looks like it is running in a browser and it is actually downloaded and running on your PC then does that mean you're limited to play on only one PC, so you couldn't just log-in and play games on any PC with a browser?
Absolutely you can. If the (new) computer you are on hasn't played that particular game before, then the back end will chunk stream the data you need on the new computer (which will also be cached for future use for what it's worth).
#47
10/12/2007 (7:44 am)
Hey - cool! Do I get a prize for guessing it right? :-D
#48
10/12/2007 (11:09 am)
Hehe, Thomas, you've been for a long time now in the IT industry so your guess are always pretty accurate! :-)
#49
10/12/2007 (1:56 pm)
But the user still has to install something on their computer? A one time only stub or and install for each app (i guess the former)?
#50
10/14/2007 (1:45 am)
GLSL shaders, Motion blur, Depth of field, yay cant wait!
#51
10/14/2007 (5:09 am)
I would suggest a "contest" to make a product name for it that has some more market appeal and an gamer touch to it. So we don't have to go thru the TSE or TGEA cloud of consfusion (for noobs not hardcore).
#52
Take a look at TGE and TGEA's collision code. It's all polygon oriented. The only place we actually explicitly use any BSP traversal is in the interior code and that's just for raycasts and zoning queries. You can drop in polysoup and it works fine with the existing code - players collide, vehicles collide, raycasts work, etc.
Kabus mentioned to me that Atlas raycast is one of the fastest he's worked with, and Atlas is entirely polysoup.
BSP is a fine technology but it's not the only game in town by any means. Torque 2 will certainly go further in the direction of polysoup but even as is in code we're shipping today, we're entirely polysoup compatible - just a question of where you get your data from.
10/14/2007 (3:55 pm)
Just a random potshot on the BSP/polysoup issue...Take a look at TGE and TGEA's collision code. It's all polygon oriented. The only place we actually explicitly use any BSP traversal is in the interior code and that's just for raycasts and zoning queries. You can drop in polysoup and it works fine with the existing code - players collide, vehicles collide, raycasts work, etc.
Kabus mentioned to me that Atlas raycast is one of the fastest he's worked with, and Atlas is entirely polysoup.
BSP is a fine technology but it's not the only game in town by any means. Torque 2 will certainly go further in the direction of polysoup but even as is in code we're shipping today, we're entirely polysoup compatible - just a question of where you get your data from.
#54
10/14/2007 (10:23 pm)
"Polysoup" usually refers to systems that can take an arbitrary mesh - say from 3d studio max - and use it without special requirements. As opposed to a CSG/BSP approach where you have to build with a special editor - like Hammer or Constructor - and obey a lot of special rules about how your world is built.
#55
Regarding the Thomas/Stephen IA discussion, does this mean that we won't have a native Torque web component? It sounds like you're aiming for something closer to Steam than Flash -- is that correct?
This all sounds very exciting. :) I really appreciate the commitment to growth -- especially with things like transparency of development / plans, etc. It's a bit scary, but ultimately I'm still on the GG bandwagon and I look forward to seeing where this all goes.
Thanks a lot for your candor!
--clint
10/17/2007 (1:19 pm)
Very informative thread, thanks!Regarding the Thomas/Stephen IA discussion, does this mean that we won't have a native Torque web component? It sounds like you're aiming for something closer to Steam than Flash -- is that correct?
This all sounds very exciting. :) I really appreciate the commitment to growth -- especially with things like transparency of development / plans, etc. It's a bit scary, but ultimately I'm still on the GG bandwagon and I look forward to seeing where this all goes.
Thanks a lot for your candor!
--clint
#56
10/17/2007 (2:09 pm)
@Clint - Its not a player like Flash, Shockwave, WildTangent, or Unity.... which is also why IA is compatible with any game engine.
#57
It's sounding more and more like this is effectively closing the door on an officially GG-signed web-plugin for TGB.
10/17/2007 (2:18 pm)
@Tom - So just to spell things out plainly, this also implies that any Torque web distribution will have to be exclusively through IA's portal, right? It's sounding more and more like this is effectively closing the door on an officially GG-signed web-plugin for TGB.
#58
10/17/2007 (2:25 pm)
@Clint - I suspect that's the case.
#59
10/17/2007 (3:01 pm)
InstantAction is literally what it says--a "software console". It is a gated publishing platform (we approve the games) with social, accounting (purchasing/billing), gameplay, and distribution services.
#60
Also i think if the GUI was HTML based it would be a cool, so you could photoshop your interface and then add the relevant links to the functunality later. I think this would save alot of problems as many people already know HTML/CSS.
10/17/2007 (3:11 pm)
Will Torque 2 be DX10 based?Also i think if the GUI was HTML based it would be a cool, so you could photoshop your interface and then add the relevant links to the functunality later. I think this would save alot of problems as many people already know HTML/CSS.
Torque Owner Kevin Keathley
Non-Default Studio Name
Anyways, a question I have is what scripting engines (it may be too early) are you all considering for Torque2? I do like using existing languages such as C# (learning curve) and the MMO guys love python and there's still quite a bit of support for TorqueScript. Is this a part of what you may refer to as modular? Possibly one or two official scripting implementations and the ability to plug in community-built scripting modules? I'm not really trying to get too many details as I know it's early, but I guess rather throwing in a piece of brainstorm matter :-)
anyhow, good work and thanks...