Torque 3D goes for a web plugin
Torque 3D looks to be challenging Unity for the 3d game in a plugin market; check out this feature on their home page:
Deploy any Torque 3D project from the World Editor to a web browser in seconds with our web publishing options. Torque 3D supports all major browsers and operating systems, including IE7, FF3, OS X and Chrome. Games perform at 100% native speed, with no performance cost, completely in your browser.
Both solutions, of course, require that the plugins that host the native client be widely deployed, which is the biggest challenge. The gap between something like Flash or Javascript, and something like this, is measured in the hundreds of millions of installs. Of course, what you get for the native renderers in the plugins is desktop quality graphics.
The push on the other side, of course, is to upgrade the graphics in a form basically native to the browser, so you don’t need a plugin at all, or if you do it’s one you already have (because you visited YouTube once).
11 Responses to “Torque 3D goes for a web plugin”
Sorry, the comment form is closed at this time.
They have to play catch up to Unity3D which is really taking off. And if someone finally creates a great 3D engine for Flash then that will be another possibility as well. I wish something like o3d would take off http://code.google.com/apis/o3d/
http://o3d.googlecode.com/svn/trunk/samples/beachdemo/beachdemo.html
The tough part isn’t getting a 3d app to run in a browser – it’s getting a 3d app to act like people expect browser apps to act (short loading times in particular).
If I’m not mistaken, the Torque web publishing option means that you create a custom plugin _per game_. So you always start back at 0%, no matter how many succesful torque games have existed in the past. Unity’s webplayer model is like flash’s, where Unity creates the player, and its customers create the content it plays back.
The in-browser Javascript 3D stuff is already coming along nicely, isn’t it?
And for the life of me I can’t find the relevant link. I think it was some Google Chrome experiment — really, really beautiful in-browser 3D rendering.
Using these proprietary plugins isn’t very different from downloading a complete, pre-compiled standalone app, right?
@Andrew: We’re not trying to catch up to Unity on the web deployment front. We we think chasing proprietary plugin penetration (the Adobe route) is a losing proposition given what’s happening in web technology. The “Unity Player” has <1% plugin penetration and isn’t on pace to catch even something like Shockwave or Java in 5 years. A much better route is to let the content drive the plugin conversion for rich 3D web apps. For example, this is what id is doing for Quake Live, a single game. A similar approach could be applied to a whole portfolio of games across multiple web properties with the Torque 3D system, the way InstantAction.com works.
You make a really good point about watching for emerging standards in this space though. Demand for rich content is outpacing the browser technology to support it, so we’re in a pretty weird transitional phase right now between people playing rich games as desktop apps, but spending more and more time in the browser where high end content still requires a plugin. Google might blow past all this with O3D in Chrome, just as Mozilla might do something similar for Firefox. Microsoft has yet to indicate whether they have anything to add here, but a standard, or multiple standards will emerge. What are the chances that the “Unity Player” is anywhere to be seen in this mix 24 months from now? Probably pretty low considering the pace things are moving.
With Torque, we’ll be adopting any emerging web standard that shows promise. This looks like O3D (perhaps paired with Native Client for security) right now, but the landscape might look very different in a short trip forward. Torque, right now, can target every major distribution channel. All the major consoles, PC, Mac, Web, iPhone. Having a consistent, powerful toolset to target these channels is our primary goal.
@Matt: That’s a good point. Right now, browsers are really clunky at handling this sort of thing, even with a plugin like Flash. I think the browser standards (HTML5) will need to catch up to these demands for richer content in the browser that behaves in the smooth, stable fashion people expect of a desktop application. It also has to do this securely, that’s where Native Client becomes so important.
@Lucas: The Torque 3D web publishing option lets developers brand the plugin allowing their game to be played in the browser any way they want. It can run just one game, or multiple games across multiple web properties. This is FAR more flexible than the Unity structure where every Unity game must conform to the Unity web player in order to run in the browser. This is limiting in that, even if Unity were to license source code to game developers (which they don’t), any source code modifications would make throw a wrench into web player compatibility. Even using the “C / C++ Plugin Support” option with Unity to achieve some customization for your game (could be rendering optimizations, custom game logic that’s too slow implemented in script (e.g. AI), some native library, etc.) would break compatibility with the Unity Web Player.
In many cases then, you’d end up having to branch your game for the web vs. desktop using Unity. Certainly not an ideal solution for game developers. In contrast, Torque 3D which is licensed with source code, allows developers to make any source modification they want all while targeting the web browser and desktop (on both PC and Mac) with one version of their game. We certainly could go the Unity route with a binary-only version of Torque and a rigid “Torque Player” for all web deploys, but building a game without access or modification to source code is unfeasible for most developers making rich, sophisticated games. In my opinion, developers making simpler games probably have better options if they’re aiming for the web (Flash).
@Sebastian: Using a proprietary plugin *can* be different from downloading a complete compiled standalone app, but it depends on the plugin. InstantAction.com’s plugin basically manages the content that’s needed on a user’s machine at any one time in order to play the game, so content can be chunked, games can be “patched”, new content can be pushed all without a new download or install or traditional patch. This does make playing a rich, 3D multiplayer game in the web much more like a “web experience” than a desktop experience. It’s faster and much more accessible.
You do have a point though in that it’s not nearly as smooth yet as it should be, and it’s not easy for a developer to make a game and provide all these web-specific optimizations with any existing technology. Bitraider has cool stuff for “streaming” games down the client to be run on the client machine, so that’s a potential solution, but there’s no question that it’s a problem that’s looking for a clear solution in the next 12-18 months. Games *want* to be in the browser, or in the same place where people are used to consuming browser content (Google Wave?), so this will be solved. By us for sure and probably by others in the long run as well. Developers will have the tools and simple deployment options to reach the browser audience without having to implement complicated, custom technology. They will be able to focus on making great content, not worrying how to get it in front of their audience.
I am not sure to understand. What does Youtube?
YouTube is responsible for driving the rapid adoption of new versions of Flash, because it’s so popular.
Unless a developer is willing to work with a new set of best practices, no plug-in technology is going to be the magic bullet for browser based MMOs. Sherwood Dungeon with Shockwave, Runescape with Java, Fusion Fall with Unity – this has been tackled successfully many times with all different sizes of development teams. You can’t just flick a switch and expect a boxed MMO to succeed in a browser. As Matt said the load time is key and sometimes this requires some hard choices or a radical rethink of your architecture. 3D model and animation compression is also very important. The browser has been capable of pretty remarkable 3D for a LONG time, but we’ve had to make some hard choices. Delivering a small vertical slice of gameplay or a graphical demo is very different than making a fully functional, profitable MMO. As bandwith improves, so has visual quality. Both Sherwood and Runescape both look much better today than they did in 2003, with technologies that really haven’t changed that much since then.
@Gene: I agree. No magic bullet exists yet, and I doubt one will appear in the next 12-18 months. I think this is an awkward, but promising transitional period for games one the web / games in the browser. The streaming problem is a big one to tackle technologically, but there are good solutions for that. You can play WoW right now with very few interruptions or hiccups as it downloads. Bitraider lets you do this with a lot of games too. It’s not really pretty yet, or turn key, but we’re getting there and this is obviously the space to be in for the future.
“No magic bullet exists yet, and I doubt one will appear in the next 12-18 months.” Making a functional, profitable 3D MMO in a browser is not some vaporware from the future. It’s been done already many times – just don’t treat it like a boxed product when you’re building the game. People keep looking for the next great 3d plug-in technology and old, crusty, trusted technologies like Java and Shockwave are the ones that keep delivering the goods.
“I wish something like o3d would take off.” I’m not that encouraged by o3d. Google’s beach demo is over 18 mb. Considering what you get and at what fps, I don’t get all the excitement. Unless the art was make in a very inefficient fashion, with the exception of the water reflections, Shockwave was able to deliver the same quality at far smaller than half the download size back in 2000 – nine years ago.