This is not a free engine for HTML5 games. You are required to sign up to release a game on their proprietary * distribution platform* and give them 30% of your net revenue. Very misleading headline.
From the page:
"We supply your team with the Turbulenz HTML5 JS engine and all the Turbulenz APIs, free of charge. You bring a great game that embraces the way the web works; dynamic, social, and connected. We provide engine technical support, payment processing, analytics, game marketing services, and in some cases we may fund or co-fund the development of your game.
"The end result is a direct revenue stream, full control over the marketing of your game, and your game reaching millions of game players on many different devices and web destinations. Developers retain 70% of all net revenues."
Oh, and their platform seems immediately awful too, considering that you need to sign in to even SEE a single game they're offering.
A shame, too. Was hoping for a nice, free alternative to the Impact Engine (http://impactjs.com/).
You don't have to release it via their distribution platform - you're free to distribute it as you like. They only take the 30% cut if you distribute it via them, which I'd say is pretty reasonable. FYI I'm not in any way associated with Turbulenz - I'm just at a conference where they demoed it.
EDIT: As I mention in a reply below, this is now working for me after force enabling WebGL in chrome for ATI cards. My apologies to David and the team for jumping the gun.
----
I get "Turbulenz is not currently supported on your platform, but we're working on it!" running Chrome under Ubuntu.
Sure, Linux gaming isn't a big market, but surely one of the big points of HTML/web gaming is cross-platform support?
I wish these guys luck - I actually interviewed there a while back, and the technical members really know their stuff - but I think they've got a few more barriers to cross first to get to 'it just works'.
Most of our developers use Ubuntu and I just tried to play Score Rush and it worked fine for me on Chrome under Ubuntu. Perhaps the browser is black-listing your video card and not supporting WebGL? If I can get more details about your system I can try to help.
I am a bit disappointed, they promised a lag free network stack, but they just use websockets, so that's an empty promise. You can't have realtime multiplayer without UDP.
I think we need to update that bit in the whitepaper, it was written long before we developed our WebGL stack which as you pointed out now uses WebSockets. We are working on a multiplayer version of Score Rush that would be available on our website for everyone to try.
The technology and features of the engine and platform look awesome! That quake demo is really slick (and seems it was released 2 years ago, would be nice to see some newer videos).
I'm worried about the pricing model though, you say it's free but on the developers page it mentions that Turbulenz is able to put any game developed with it on their site at any time they like. That doesn't sit right with me and perhaps you could improve that in some way to attract more developers to use the engine (I can see you're following in apples footsteps but you really don't have the market power apple has).
Also when I went to the main website it's telling me Javascript is disabled even though it's not. I'm running Chrome V22 (the latest beta) on Windows 7 and have whitelisted the domain in adblocker to no avail.
Perhaps they were not comparing the performance, but just trying to explain their product? However, it also says in the paper:
"Originally we created a technology demo using the Quake 4 assets. The demo created an FPS on top of the standard Turbulenz Engine but implemented a modern deferred renderer in place of Quakeʼs original forward renderer. Once we had this multiplayer demo running at over 60 fps with particle effects, full screen effects, character animations, a full physical environment, 3D audio, networking and the deferred lighting solutions, we decided that JavaScript was absolutely capable and suitable for creating modern games."
Sorry if we did not get the message across correctly, sometimes is hard to find a good simple example to explain what your product can do. As asadjb said it was just a way to say that our product allows development of complex 3D games, as we demonstrated by our game demos and our FPS demo.
I love how all the people trying to sell the latest and greatest HTML5 game engine solutions don't seem to understand what matters to actual developers:
First, the pipeline for actually building the game - what's the workflow like, what's your build system like, how easy is it to integrate with existing tools... If you're going to compare yourself to the goddamn Unreal engine, you had better at least have an answer to the utterly AMAZING tools they provide for artists, programmers, and other developers. Real game developers don't give two flying f--ks about whether you have Tumblr integration if they have to write a bunch of JSON to build levels and integrate into your build pipeline (and it's probably being generous to assume that their tech is sophisticated enough to use JSON files).
Second, the experience for players - sure, you've got a deferred renderer and a network stack. How much latency does your network stack introduce on top of the actual round-trip latency between the player and the server? How efficiently is your network stack able to use bandwidth (and is your prediction good enough to let me send less traffic for state updates?) How much memory and video memory do your demos use compared to a somewhat equivalent native app - will my players need a machine that's twice as beefy just to run a game in the browser using your tech? What are the average framerates like on an average machine - the canned videos suggest the framerates are bad, but actual runtime performance isn't even mentioned. How do you handle deploying assets for a game with a large amount of assets - is the player going to have to download 250MB of game textures and sounds into his cache every time he plays because you haven't done anything to cache them locally?
Toy demos like the one in the demo footage (http://www.youtube.com/watch?v=gjLaNjkYnrI) are basically only useful for demonstrating that it is possible to run toy demos. In the real world, you need to actually prove that you can run real games on your technology by running real games. It's all the more insulting that this toy demo seems to have repurposed assets from one of id's games in order to promote a product that these guys are trying to sell to you - I hope they got id's permisssion...
How about instead of trying to compare yourself to Unreal, you start with a lower target: Unity. Can you provide performance comparable to Unity across various target platforms, along with something approaching their ease of development and distribution? If you can't even compete with something as cheap/affordable as Unity on those points, then what is your unique value add that makes you a look? If the answer is nothing, well then, good luck - hopefully you have enough VC funding to burn that maybe you can be competitive before you run out of money.
EDIT: Oh, that's sneaky. If you dig into some of their documentation, it turns out that they require a custom binary plugin to support some unknown subset of their feature list because 'browsers don't support them yet'. So this isn't even technically an HTML5 engine; it's more like a native engine with partial HTML5 fallback.
[+] [-] avolcano|13 years ago|reply
From the page:
"We supply your team with the Turbulenz HTML5 JS engine and all the Turbulenz APIs, free of charge. You bring a great game that embraces the way the web works; dynamic, social, and connected. We provide engine technical support, payment processing, analytics, game marketing services, and in some cases we may fund or co-fund the development of your game.
"The end result is a direct revenue stream, full control over the marketing of your game, and your game reaching millions of game players on many different devices and web destinations. Developers retain 70% of all net revenues."
Oh, and their platform seems immediately awful too, considering that you need to sign in to even SEE a single game they're offering.
A shame, too. Was hoping for a nice, free alternative to the Impact Engine (http://impactjs.com/).
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] rheeseyb|13 years ago|reply
[+] [-] colinshark|13 years ago|reply
If a player can play for free on Turbulenz (with ads), then I'm going to have a hard selling my game elsewhere for $10.
And if I can't sell a $10 game with this platform, then we won't see AAA titles either.
[+] [-] Malcx|13 years ago|reply
And don't think you need my email or facebook login before I've seen what you offer and whether it's any good.
[+] [-] kitcar|13 years ago|reply
[+] [-] kitcar|13 years ago|reply
[+] [-] NickPollard|13 years ago|reply
----
I get "Turbulenz is not currently supported on your platform, but we're working on it!" running Chrome under Ubuntu.
Sure, Linux gaming isn't a big market, but surely one of the big points of HTML/web gaming is cross-platform support?
I wish these guys luck - I actually interviewed there a while back, and the technical members really know their stuff - but I think they've got a few more barriers to cross first to get to 'it just works'.
[+] [-] davidgaleano|13 years ago|reply
[+] [-] tinco|13 years ago|reply
[+] [-] davidgaleano|13 years ago|reply
[+] [-] TimJRobinson|13 years ago|reply
I'm worried about the pricing model though, you say it's free but on the developers page it mentions that Turbulenz is able to put any game developed with it on their site at any time they like. That doesn't sit right with me and perhaps you could improve that in some way to attract more developers to use the engine (I can see you're following in apples footsteps but you really don't have the market power apple has).
Also when I went to the main website it's telling me Javascript is disabled even though it's not. I'm running Chrome V22 (the latest beta) on Windows 7 and have whitelisted the domain in adblocker to no avail.
[+] [-] davidgaleano|13 years ago|reply
https://code.google.com/p/chromium/issues/detail?id=136381
[+] [-] jamesaustin|13 years ago|reply
[+] [-] teamonkey|13 years ago|reply
"As a comparison, the Turbulenz Engine is equivalent to the Unreal engine."
Really?
[+] [-] asadjb|13 years ago|reply
"Originally we created a technology demo using the Quake 4 assets. The demo created an FPS on top of the standard Turbulenz Engine but implemented a modern deferred renderer in place of Quakeʼs original forward renderer. Once we had this multiplayer demo running at over 60 fps with particle effects, full screen effects, character animations, a full physical environment, 3D audio, networking and the deferred lighting solutions, we decided that JavaScript was absolutely capable and suitable for creating modern games."
[+] [-] davidgaleano|13 years ago|reply
[+] [-] shoo|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] bazookaBen|13 years ago|reply
[+] [-] davidgaleano|13 years ago|reply
[+] [-] kevingadd|13 years ago|reply
First, the pipeline for actually building the game - what's the workflow like, what's your build system like, how easy is it to integrate with existing tools... If you're going to compare yourself to the goddamn Unreal engine, you had better at least have an answer to the utterly AMAZING tools they provide for artists, programmers, and other developers. Real game developers don't give two flying f--ks about whether you have Tumblr integration if they have to write a bunch of JSON to build levels and integrate into your build pipeline (and it's probably being generous to assume that their tech is sophisticated enough to use JSON files).
Second, the experience for players - sure, you've got a deferred renderer and a network stack. How much latency does your network stack introduce on top of the actual round-trip latency between the player and the server? How efficiently is your network stack able to use bandwidth (and is your prediction good enough to let me send less traffic for state updates?) How much memory and video memory do your demos use compared to a somewhat equivalent native app - will my players need a machine that's twice as beefy just to run a game in the browser using your tech? What are the average framerates like on an average machine - the canned videos suggest the framerates are bad, but actual runtime performance isn't even mentioned. How do you handle deploying assets for a game with a large amount of assets - is the player going to have to download 250MB of game textures and sounds into his cache every time he plays because you haven't done anything to cache them locally?
Toy demos like the one in the demo footage (http://www.youtube.com/watch?v=gjLaNjkYnrI) are basically only useful for demonstrating that it is possible to run toy demos. In the real world, you need to actually prove that you can run real games on your technology by running real games. It's all the more insulting that this toy demo seems to have repurposed assets from one of id's games in order to promote a product that these guys are trying to sell to you - I hope they got id's permisssion...
How about instead of trying to compare yourself to Unreal, you start with a lower target: Unity. Can you provide performance comparable to Unity across various target platforms, along with something approaching their ease of development and distribution? If you can't even compete with something as cheap/affordable as Unity on those points, then what is your unique value add that makes you a look? If the answer is nothing, well then, good luck - hopefully you have enough VC funding to burn that maybe you can be competitive before you run out of money.
EDIT: Oh, that's sneaky. If you dig into some of their documentation, it turns out that they require a custom binary plugin to support some unknown subset of their feature list because 'browsers don't support them yet'. So this isn't even technically an HTML5 engine; it's more like a native engine with partial HTML5 fallback.
[+] [-] davidgaleano|13 years ago|reply
All our tools and pipelines are explained and documented on our SDK, online docs at:
You are free to download the SDK and try it for yourselves, but we will try to provide more specific details in the future.