Turbulenz

Join our live webcast: Introducing the Turbulenz HTML5 game engine!

Wed, 15 May 2013 17:46:23 +0100

We are holding a live webcast to introduce users to the open source Turbulenz Engine on Tuesday 21st May. It is free and anyone can join. You can receive email updates on the event by registering online. Whether you’re already using Turbulenz, working on HTML5 games or applications, investigating technologies for an upcoming game, or have a general interest in modern game technologies, this session is worth joining. You can even send us questions in advance on the event page here.

The agenda is:

Getting set up with the Turbulenz HTML5 Engine
An introduction to the main features and APIs
Creating an HTML5 app
Getting your app online
Q&A with the Turbulenz development team

Time: Tuesday 21st May at 8am West Coast US / 4pm UK time / Midnight Japan time.

Location: Streamed live online at livestream

Duration: Presentation will last 1 hour. We are leaving an additional hour afterwards for Q&A.

We hope to see you there.

"Thank you!" in response to open sourcing the Turbulenz Engine

Mon, 13 May 2013 12:43:00 +0100

It’s been a really exciting week for us here at Turbulenz and we have been totally blown away by your response to our release of the Turbulenz HTML5 game engine under the MIT license.

It’s always nerve-wracking releasing something into the wild which is why we are so excited that our engine has been trending on GitHub with over 1200+ stars and 140+ forks. It’s great to see so many people trying out the engine, and we’ve even accepted our first pull request.

But it’s not just on GitHub that we have seen plenty of action. Articles on Develop, Gamesindustry.biz, Gamasutra and Gamesbeat have got people talking, with discussions on Slashdot and Hacker News. And we have been really excited about the buzz on Twitter - there have been over 1000 tweets and retweets talking about the open sourcing of the Turbulenz engine.

And it’s not just our open source engine that has been getting your love. Our friends at Wonderstruck knew they would probably get some attention when we made our announcement so they pulled out all the stops to get a new version of Polycraft ready for all our new visitors, including huge new gameplay elements like outposts and a whole range of new enemies. And it looks like all the hard work has paid off as we have had over 7000 new players. If you haven’t had a chance to try Polycraft yet, play it here.

So we just wanted to say a big “Thank You” for all your support and encouragement. But this is only the start for us. We need you to help us to keep on building the best HTML5 engine in the world. Whether you’re asking and answering questions on the engine users forum, reporting bugs and requesting new features, or just saying hi on twitter, we’d love to hear from you!

Turbulenz Engine Goes Open Source

Thu, 02 May 2013 12:12:00 +0100

We’re excited to announce that we have released the Turbulenz HTML5 game engine as open source under the standard MIT license. The open source project is available on GitHub at https://github.com/turbulenz/turbulenz_engine.

You may have seen Turbulenz mentioned somewhere and wondered what it was. Turbulenz provides a game engine that delivers all the building blocks developers need to rapidly create high quality and hardware accelerated 2D and 3D games playable across mobiles, tablets and the web.

Polycraft by Wonderstruck

We started developing the Turbulenz Engine a little over 4 years ago in early 2009, when HTML5 was still in its infancy and before WebGL even existed. We recognized that JavaScript and the web development platform offered a huge opportunity for creating high quality games and as a mechanism and market for dynamically distributing content.

We initially proved this to ourselves by creating the service and engine capable of streaming and rendering the majority of Quake 4. This continues today to be a great test of the engine as it has evolved. You can see it demonstrated by our CTO David Galeano.

Today, the Turbulenz Engine powers the highest quality 2D and 3D HTML5 games online. If you want to see some examples we recommend looking at:

The 2D arcade game Save the Day by Denki - watch the trailer - play the game now
The 3D arcade strategy game Polycraft by Wonderstruck - play the development version now
The real-time 4 way multiplayer shoot ’em up Score Rush by Xona - watch the trailer - play the game now

Save the Day from BAFTA-winning Denki

We have seen a monotonically increasing interest in the engine and SDK since it was first made publicly available.

If you want to take a look, the best place to start is the README which you can find on the Github project page and included in the source. This details how to set up a development environment and includes a short getting started guide on how to use the Turbulenz Engine APIs. From here we recommend going through the Getting Started guide and reviewing all the documentation online.

The engine is also available bundled in an easy to install SDK for Windows, Mac OS X and GNU/Linux. This might be an easier option if you’re looking for a packaged-up and fully QA’d snapshot of the engine. All future SDK releases will contain the open source engine with the associated MIT license. (Earlier versions of the SDK were released with a partially open license which has now been deprecated.) The bundled SDK is available from the Turbulenz developer service.

What Features Does the Open Source Turbulenz Engine Provide?

The Turbulenz Engine contains an extensive range of features and services for creating games. The engine was designed to be a complete Internet generation game engine. By this, we mean a game engine that was conceived, designed and implemented specifically for building games that are played via the Internet using web technologies, rather than as a native application on a console or PC. This is a single suite of technology that spans the client game application and remote game services.

The libraries contain solutions for all sensibly reusable game services, including: 2D and 3D graphics, 2D and 3D physics, 2D and 3D effects, sound, networking, user input, scene graphs, hierarchical animation, movie playback, resource management, server requests, a range of renderers, leaderboards, badges, payments, save game userdata, user profiles, game profiles, multiplayer, metrics, maths and numerous utilities.

The graphics engine is completely shader driven and hardware accelerated using WebGL. It has been implemented to allow games to efficiently dispatch their scenes. The engine comes with multiple renderers which can be selected depending on the features and performance of a user’s device, this includes, a deferred renderer, a forward renderer and a default renderer. There is also a highly efficient 2D renderer for efficiently dispatching huge numbers of sprites and effects.

The 2D and 3D physics engines are particularly powerful in comparison to the procedurally generated ports of currently available.

All the technology has been handwritten as efficient TypeScript and JavaScript to maximise execution and memory performance.

There is a detailed list of all the engine’s features in the repository README and in the documentation.

Why Are We Open Sourcing the Engine?

We’ve had a lot of interest in the Turbulenz Engine via our SDK packages and many of the people who try it out have praised the features and performance. However, two issues that have often come up are any sort of restrictive licensing and the ease of getting things started.

By releasing the Turbulenz Engine as open source under a standard liberal MIT license we hope to ease the adoption costs and ensure that people don’t feel in any way restricted by using the Engine.

What Are the Design Goals of the Turbulenz Engine?

The main design goals of the Turbulenz Engine are performance, modularity and customizability. Users of the engine should be able to build any kind of game without limitations, in an efficient manner and with an end product that performs optimally when loading and during play.

To achieve this target the Turbulenz team followed these rules when writing code:

Modularity

Users should be able to pick what they want and replace what they don’t.
When possible new functionality should be orthogonal to existing one.

High performance

Strict coding standards to keep code efficient.
Keep memory allocations to minimum, reuse existing objects or arrays whenever possible, use scratch pads, combine multiple separate objects into a single one.
Use most efficient storage for each data, Typed Arrays when possible.
Reduce function calls when possible: write functions that handle arrays of objects instead of loops that make a function call per element, games rarely do a single thing to a single object.
Be aware of performance differences between browsers.
Profile often.

Asynchronous loading

No API should block waiting for a response from the server, avoid polling whenever possible, use callbacks or Promises, to notify of data availability.

Data driven

The target should be to make the game a simple dumb player of data, all functionality defined by simple data files.

Simple well documented file formats

Define simple, easy to create asset formats that can trivially be connected to any tool chain.

Scalability

Design interfaces that can be implemented with different level of detail or quality settings in order to scale from mobile to desktops.

Power without control is nothing

Make sure users can do exactly what they want, with a helper layer put on top if required, document performance implications at every level.

Fault tolerant

The engine should keep going even if any type of asset fails to load. The application is able to provide sensible defaults for all asset types making it easier to stay productive and diagnose issues.

Fast loading

Reduce amount of data to be downloaded, compress data efficiently.
Use the browser cache efficiently, use unique file names based on content and tell the browser to cache forever.

Maintainability

Strict coding standards to keep code readable, easy to maintain and debug.
Write unit tests, samples and documentation for every new code path.

Targeted

This is a game engine, for games.

What Have We Made Available?

We’ve made three Git repositories available on GitHub:

Turbulenz Engine - https://github.com/turbulenz/turbulenz_engine

TypeScript and JavaScript implementations of the game engine
Documentation of the libraries, APIs and tools
Code samples demonstrating the engine APIs
Application samples showing how a basic but complete game can be built
Protolib high level prototyping libraries

Turbulenz Tools - https://github.com/turbulenz/turbulenz_tools

Python tools for processing code and assets.
Also available from PyPi as turbulenz_tools.

Turbulenz Local - https://github.com/turbulenz/turbulenz_local

A locally hosted Python development web server implementing the Turbulenz services APIs
Tools for interacting with the Turbulenz Hub
Also available from PyPi as turbulenz_local.

Want to Contribute?

We know there is a large and growing community interested in HTML5 game development and we hope that people will find this project an empowering contribution to game and Internet technology domains. Now that the project is fully available as open source and easily accessible via GitHub all contributions are gladly welcomed. Please send the project a pull request or post a git diff patch on the Turbulenz Engine google group.

Please Help Us Spread the Word

Please help spread the word to your friends and followers by sharing this announcement online. We want to make sure that anyone thinking about making a game with HTML5 is aware of Turbulenz as a free and open source solution that comes packed with high performance features.

Learn More

Sign up for the free WebCast on 21st of May at 9am PST / 5pm BST. This will include an introduction to the technology, show you how to get started, and leave time for Q&A.

Any questions or ideas about the Turbulenz Engine, HTML5 games or anything else, please get in touch.

Happy Hacking!

- James Austin

Turbulenz CEO

TypeScript in focus - getting started with TypeScript Turbulenz

Mon, 15 Apr 2013 10:00:25 +0100

SDK 0.25.1 is a minor update to SDK 0.25.0 and contains a few fixes and updated documentation. If you’ve just updated to 0.25.0 this update should be a breeze.

TypeScript in Focus

There’s now a whole new section in the “Getting Started Guide” that goes into depth about how to build against Turbulenz TypeScript modules. With a walkthrough example and commands that you can use with your own build system. You should be up and running in no time. Future developments will include a standardised build structure, so watch this space.

More and more COLLADA updates

We’re continuously making updates to our dae2json tool; supporting additional features and making improvements. There’s so much going on we can get them out fast enough. See the detailed release notes to find out what’s new.

A fistful of fixes

Fixes in this release include a bug in the soundDevice.listenerGain property on canvas and the correction of a few missing files in the SDK. See the release notes for details.

TypeScript version of Turbulenz Engine now available

Mon, 08 Apr 2013 15:35:22 +0100

Type check… one, two - TypeScript support rocks Turbulenz

SDK 0.25.0 has been a long time coming, but we hope it will be a significant step in helping our developers make awesome games. This SDK includes the first public release of TypeScript versions of our libraries. With improved syntax checking and validation using TypeScript should help you streamline your development process and avoid silly bugs and runtime errors down the line. It compiles to JavaScript and works with other existing JavaScript libraries.

You don’t need to use TypeScript to use Turbulenz, but we now provide type definitions for all of our libraries, which is just one good reason to try it out!

For more information on TypeScript check out: http://www.typescriptlang.org

Features

TypeScript

The SDK now includes tslib and jslib (generated from tslib) as well as TypeScript versions of apps and samples.

This feature is in beta and we need your help to try it out! Make sure to read the detailed release notes and the TypeScript recommendations.

Existing developers: Use the standard jslib as usual. If you have your own modifications, compare your code to the tslib version which has a similar layout to previous jslib releases. Investigate whether TypeScript would help you with your project.
New developers: Start your project with either of tslib or jslib depending on preference.

interesting blog article of his findings during developmentOur TypeScript guru Duncan has written an . Definitely worth a read.

Video support

The GraphicsDevice now supports the creation of video objects that can render video data as a texture. This feature can be used for cut-sequences and other media playback in the game engine. The video sample shows how this can be used in conjunction with audio to playback a video. Check graphicsDevice.isSupported to find out if the browser supports WebM or MP4 video formats.

Physics snapshots

The PhysicsManager now supports snapshots for creating and restoring snapshots of dynamic physics objects on the scene.

Ideal for resetting the state of physics simulations.

Clean-up outstanding API requests

A new destroy function has been added to the RequestHandler to help clean-up outstanding request callbacks and stop them from accessing invalid state on destruction. Make sure to add this to your existing shutdown code.

UV transformation support for the renderers

DefaultRendering, DeferredRendering and ForwardRendering now support uvTransform allowing you to rotate, scale and translate UVs. See the release notes for more details.

Updates for dae2json

dae2json, the COLLADA import tools for models, animations, materials and more has had a number of bug fixes and improvements. It has better support for various exporters from Maya/Max to Sketchup. Notable is the addition of the NvTriStrip command which is a recommended step for optimising meshes.

Fixes

T152 - An issue where deploygame tool was unable to upload to the Hub.
A rounding error for certain values in storeitems.yaml that caused an error on the Hub.
Various fixes to dae2json to avoid crashing and give more warnings for incorrect/unsupported files.
Fixed an issue where JSProfiling was unable to generate array information in the latest Chrome.

See the 0.25.0 release notes for more details.

The SDK is available to download from the developer service at hub.turbulenz.com.

(Mostly) Painlessly migrating a 3D game engine to TypeScript

Mon, 08 Apr 2013 15:32:00 +0100

Introduction

At Turbulenz we are developing a platform for high quality online games. Part of our technology offering includes a JavaScript library of about 100,000 lines of code, covering many areas of game functionality from rendering APIs that wrap WebGL, to an optimized 3D physics engine, and interfaces to online services.

A production-quality game using the engine can run to well over the same amount of code again (Our pre-alpha game PolyCraft already has about 85,000 lines of runtime JavaScript). The burden of maintaining JavaScript projects of this scale is already known to be significant, and this has been echoed in our experience over 3 years of developing our game engine, as well as several 3D and 2D game titles.

Catching coding errors early can make a huge difference to programmer productivity. We regularly use static analysis tools such as jshint, as well as automated testing to try and identify problems as code changes are made. However, the lack of type information in JavaScript limits the class of problems that tools can identify, and automated testing can never feasibly cover all execution paths.

TypeScript is one of several projects that attempt to introduce static typing, allowing offline tools to identify a larger class of errors and to provide richer functionality in the IDE. This article describes the method we used to migrate our JavaScript code base to TypeScript, while keeping development active.

Static Typing Solutions

TypeScript is not the only project that attempts to tackle the problems associated with weak typing in JavaScript. I cannot claim it is better than any of the other solutions out there, but there were a few factors that made us commit developer time to checking out TypeScript.

Ease of migration. As a small company with a reasonably large existing code base, it is difficult to justify and a full port to another language. Even if development resources were not a problem, a full port would be a big commitment to make before being sure our code was compatible with static typing. With TypeScript we were able to proceed in steps, gradually merging changes into the mainline as we went along.
Complexity. This is not so much the code as configurations. A subsection of our engine has multiple implementations. In the default case everything runs directly in the browser using HTML5 and related standards. For older browsers with limited support for modern standards we provide a plugin that includes a native implementation of some of our lowest-level libraries. TypeScript provided a clear way to deal with multiple implementations of the same interface, where one of those implementations was hidden away as native code.
Timing. There happened to be a lot of news and activity around TypeScript just as we were discussing the shortcomings of JavaScript both internally and with external developers. This had some influence on our decision to try static typing at the time we did, and to do it with TypeScript.

Again, I’m not claiming that TypeScript is the only way to address these issues. If conditions had been different we may have been tempted by one of the other available solutions. Particularly if we were just starting out with a new code base.

Migration Path

Initially, it was not clear whether TypeScript would be entirely suitable for our project. Many questions needed answering: Was it stable? Was it compatible with how we define and instantiate JavaScript classes? Was our API and code even amenable to static typing, or had we embraced dynamic typing to the point of no return?

It was important to be able to quickly try it out and catch any show-stopping problems early. At the time there were relatively few public accounts of TypeScript being used in production, so we could not rule out the possibility of later finding either a bug or language feature that made it impossible for us to proceed. In the worst case we would need to revert everything back to pure JavaScript.

We were also keen to eliminate any impact on developers in terms of interface and performance. I was already reasonably sure that we had enough control over the generated JavaScript to avoid sacrificing performance, but it was not clear whether changes to the public API would also be necessary.

Finally, there was the issue of integration. Development of the engine would have to continue while we simultaneously “ported” the code. Handling development changes and keeping merge conflicts (and mistakes) to a minimum would be vital until we were confident enough to adopt TypeScript in the main code line.

As TypeScript is a super set of JavaScript, it seemed to offer as smooth a migration path as we could expect from any solution. After becoming reasonably familiar with the language and the compiler we ended up migrating in the following way, at each stage validating that we were doing the right thing.

Step 1 - A trivial build

The first step I took was to simply rename each of our .js files to .ts and create a trivial build step to convert the each of these new .ts files to JavaScript. The code was left unchanged at this point (apart from a few small workarounds for bugs in the TypeScript compiler), the JavaScript library had the same layout as before and everything could be merged back into the main code line.

The advantage of this apparently trivial step was that regular development could continue while we gradually expanded the type definitions in the same files. This approach is only really viable because TypeScript extends rather than replaces JavaScript, and it’s actually very important. If we were porting to a whole new language we would have to hand pick changes to the original files into the ported version, and could only switch development over to the new files once a port was complete and fully tested. No doubt some static typing solutions allow the port to be done in sections, merging individual modules back to the main line as they are ready, but having an almost effort free way of keeping all changes in the same files meant we could rely on the version control software to handle almost all of the merges automatically.

A secondary advantage of switching to .ts files and introducing a build step was to give developers a chance to iron out any problems with workflow and IDEs. Previously, no build step was required, and for our developers working on the engine the code that appeared in the browser debugger was the original JavaScript source itself

In practice, for various reasons (including limited available time for the project) we ended up keeping much of the work in a branch for long periods of time. In hindsight, we could have integrated earlier, but it felt like too big a leap into the unknown at that stage. Thankfully, git was aware of the file renaming and handled the integrations from the main line extremely well. If the change management and integrations had not been as easy as they were I am quite sure our investigation into static typing would have ended here.

Step 2 - Type checking

As this stage, the build did not catch any errors apart from syntax errors. The next step was to enable all the type checks. When this type checking build passed we could be more confident about the type-correctness of the code in our engine.

For the simple build I added an —ignoretypeerrors flag to the compiler to make it only output error messages and exit with non-zero values if there was a syntax error in the code. For the type checking build I had to add —failonerror, which stops the compiler writing output files if there are type errors in the code. Without this, build systems may not try re-run the compiler during a rebuild after errors have occured. (The default compiler always outputs a .js file but exits with 1 unless there are no type errors. Our custom version is available on Github)

In this stricter mode it was no longer possible to blindly build each .ts file into a corresponding .js file. Since some files relied on types declared in other files, the build had to be aware of dependencies between different parts of the code and build everything in the correct order. As a simple (fictional) example, if the ‘engine’ module references classes in the ‘platform’ module, ‘platform’ must be built (and the ‘platform.d.ts’ file generated) before ‘engine’ can be compiled.

This may seem like an over complicated approach. Indeed, for many projects it would be possible to just build all .js files in a single step. In our case we were forced to divide up the code in this way for a couple of reasons:

Some of the code represented the ‘canvas’ (HMTL5) implementation of the low-level engine that may or may not be replaced by our browser plugin.
Building all the .ts files at once would result in a single huge .js file. It is important that our engine remain modular so that game developers can include only the parts that they need and keep the download size of their final code as small as possible.

This stricter build mode is referred to as ‘modular’ in our system, since it allows developers to express the build as modules and dependencies between them. It then resolves the list of .ts and .d.ts files required for each module and handles building everything in the correct order. As an example of a module specification, the following is an extract from the build files for our SDK:

utilities_src :=

platform_src := platform.ts
platform_deps := utilities

jsengine_src := $(wildcard jsengine/*.ts)
jsengine_deps := platform

From this, the system automatically determines that in order to build jsengine, say, it must generate the type declarations for utilities and platform, and use both of those declaration files in the build command for jsengine.

Step 3 - Adding static type information

After Step 2, we had two builds that could be run side-by-side. A “crude” build that generated the production version of our library (with exactly the same file layout and functionality as the original JavaScript), and a stricter build which would, when it passed, generate .js files and .d.ts declaration files for each module.

Note that the crude build could always be relied upon to produce working JavaScript, so throughout this process all samples and applications could be built, and the generated code could be tested in exactly the same way as before.

As one would expect, the modular build initially failed at a very early stage. I had already added a lot of type information while experimenting with the compiler and adding build steps, but a lot more was required to fix all the compiler errors. So the next step was to get this stricter build to run without errors.

The plan was to make the modular build pass as soon as possible by adding only the minimal amount of type information. We could then enable type checks on the build machine and ensure that at least any new code would be consistent with existing type declarations. Later go back and add more and more type information as time allowed.

It turned out to be a lot of work just to make this build pass, and some of the changes were invasive enough that I decided to keep them out of the main line until the build succeeded. Potentially this stage could have been achieved by just adding ‘interface’ declarations for each of our classes, and I initially start with this approach. However, I quickly switched to doing wholesale conversions to TypeScript classes. This generated much better .d.ts files and avoided a few problems with symbols not being found by the compiler.

The compiler may be much more robust now, but at the time everything was more stable using classes in .ts files. It was something that we would end up doing anyway, and in most cases it was possible to do this without reordering functions within a file, so integrations from the main line remained surprisingly smooth.

The details here may be informative for people who are new to TypeScript, but some may want to skip the remainder of this section.Our original classes took this form:

function MyClass() { };
MyClass.prototype.method = function ()
{
    return this.y;
};
MyClass.create = function()
{
    var myClass = new MyClass();
    myClass.x = 123;
    return myClass;
};

Note that there are two member variables x and y mentioned here. The following is the minimal declarations that will satisfy TypeScript when building the code above:

interface MyClass
{
    x: number;
};
declare var MyClass :
{
    create(): MyClass;
    new(): MyClass;
    prototype: any;
};

(We also needed to make the MyClass constructor function return this.)

The declare statement deals with the global constructor MyClass. Here the static create function and the constructor are declared, as is the existence of the prototype, which at this stage is given type ‘any’ for simplicity. The interface refers to instances of the class. We have had to declare the x member, referenced in the static create function, but not the y member referenced in the method. (This is presumably because the prototype is marked as any and therefore could have any members.)

The advantage of this form is that it can be dropped at the top of the file and does not usually require any changes to the existing body of code. In theory we could just flesh these declarations out as required and keep the TypeScript and old JavaScript separated for the time being. Integrations become trivial and if we decided to move back to JavaScript it would just be a matter of deleting a few lines.

However, the declaration of the global constructor did not make it into the generated .d.ts file, and in some cases TypeScript could not find certain methods or properties when compiling dependent code. This may have been fixed in the latest version of the compiler, but switching to classes was the simplest way to this these problems at the time and made everything much more reliable. The resulting code:

class MyClass
{
    x: number; y: number;
    method()
    {
        return this.y;
    };
    static create()
    {
        var myClass = new MyClass();
        myClass.x = 123;
        return myClass;
    };
};

was a bit more of a commitment in terms of code changes. The main code body has to change slightly, and we now have to declare all members. However, we have not had to re-order any functions, so comparing with the original it’s clear that most upstream changes can be merged with relatively little hassle.

So I made the leap to classes for almost all of our code and by the time the modular build finally passed I had made more changes than I had hoped, but a large amount of the final type information was in place and the whole process had revealed several bugs. The next step was to build our application code against the generated declarations to catch any remaining holes in the type information.

Step 3.5 - IDE support

As it became clearer that TypeScript was effective at catching problems and reducing the cost of code maintenance, we started to look more seriously at the logistics of developing our game engine entirely in TypeScript. Inevitably, the issue of IDE support came up very quickly.

The TypeScript plugin for Visual Studio provides excellent tooling when configured correctly, however our developers work across Windows, Linux and Mac OS X, and use a variety of editors. Editors that provide good support for JavaScript do not always have the same level of support for TypeScript. In many cases TypeScript support is in development for these editors, so we can expect the situation to improve drastically in the future. The TypeScript site has links to integrations for Vim, Emacs and Sublime Text which gives developers a reasonable amount of choice. Our build system can be launched in a syntax checking mode (to builds just enough to validate a given file and output the errors only for that file) which can be used for on-the-fly syntax checking (as with emacs flymake) or for validate-on-save checks.

Debugging is also more difficult with TypeScript since the browser is reading and executing generated code rather than the original source. However the TypeScript compiler can already generate code maps for browsers that support them, so we can expect this situations to improve as well.

So for now there has been a slight decrease in functionality of the development environment for some of our engineers, depending on the editors used, but overall productivity should improve as we have stronger checks much earlier in the development workflow.

Step 4 - Building applications

This part of the process is still going on. We currently have a fairly complete set of .d.ts files that will be shipped with the next version of our SDK, and we are gradually transitioning all of our sample and application code to TypeScript.

It has caught several bugs in the application code, as well as a few missing pieces of the TypeScript declarations. One common problem was optional parameters. A method declared:

method(requiredParam: Type1, optionalParam: Type2): number
{
   ...
};

numberwill not be flagged unless client code tries to call it without the optional parameter. Therefore to actually find many of these issues we must build with as much application and test code as possible.

Now that the our TypeScript declarations are released in the SDK, we hope that developers will try building their games against them and give us feedback. If everything continues to go well then we certainly plan to migrate more of our projects to TypeScript.

Take a look

If you’d like to take a look at the Turbulenz HTML5 game engine and SDK which contains both the TypeScript and JavaScript APIs you can download the latest version (>= 0.25.0) from the Turbulenz Hub.

COLLADA to Unity to WebGL via Turbulenz

Mon, 08 Apr 2013 11:19:00 +0100

Investigation and presentation by Rémi Arnaud from GDC 2013 about getting COLLADA assets out of art packages and into the browser. The title of Rémi’s GDC 2013 presentation was “Experimenting using COLLADA to being content from Unity to WebGL using Turbulenz and Fl4re exporter”.

He spent some time exploring how Turbulenz provides the tools and engine to easily make this happen for 3D art assets including animations and physics. His pipeline took assets via Unity and exported them into Turbulenz to render in the browser.

Definitely worth taking a look at if you want to build a pipeline for getting 3D content into the browser.

His presentation and notes are right here.

So if you’re working with Unity and want to get your game running in a browser without the need of a plug potentially Turbulenz is the HTML5 and WebGL solution for you?

Photo

Fri, 22 Mar 2013 18:29:27 +0000

Errr Ok it’s not quite perfect… Bug in the...

Wed, 06 Feb 2013 17:59:30 +0000

Errr Ok it’s not quite perfect… Bug in the JavaScript VM?

Denki Word Quest on a phone… woo hoo. Zero changes.

Wed, 06 Feb 2013 17:56:43 +0000

Denki Word Quest on a phone… woo hoo. Zero changes.

Automatically play with your friends as we power-up Turbulenz

Wed, 30 Jan 2013 11:19:44 +0000

Auto connect with your friends

Looking for your friends on Turbulenz? When you sign-up to turbulenz.com using your Facebook account, you will now automatically follow all your friends on Facebook that are using Turbulenz, in return they will follow you too. So when you first sign-in, you’re more likely to have friends to chat with and invite to multiplayer games immediately. This was requested by quite a few users.

Internet Explorer even more friendly to play with

We’ve also added a few boring things (other than many bug fixes) to make it easier for games to update on non-HTML5 browsers. So expect games on the site to release updates more frequently! If you really want to know how this has changed, see the developer notes for details, or just go forth and play more games!

Tighter control of engine versions for developers

The Hub has now been updated to request specific engine versions for your projects, when testing the plugin. Previously it would try and play the latest engine you had installed, but now you can ask for engine versions in the form X.Y. This means you can be developing a game that works with 0.24 while still being able to play older games that are built with 0.23. Less switching of engines, should make it easier to go back and forth (with the added benefit you can jump between development and playing games on turbulenz.com).

There have also been updates to how leaderboards and store icons are processed on the Hub (See SDK 0.24.0 release notes for details).

Leaderboards, multiplayer, physics and debugging all bumped up in Turbulenz SDK 0.24.0

Mon, 21 Jan 2013 09:37:06 +0000

It’s a been a busy few months since we released an SDK, so 0.24.0 comes complete with some bite-sized features and everyone’s favourite: bug fixes.

We have for you a new Leaderboards sample demonstrating how to build an in-game leaderboard complete with scrolling/paging, user avatars and a sliding window. Having spent time on the multiplayer system, we’ve added a few tools and a bit of advice about developing multiplayer games. Try out the NetworkLatencySimulator and have a read of the games development tips and tricks. Always sniffing out the best way to help developers make their games as fast as possible, we’ve made a few tool changes to allow you to strip out debug code such as asserts. Leave them in for debugging, remove them for release, simple. See the new ‘debug’ object, which is now automatically removed by maketzjs. Here’s a quick summary of features and fixes.

Features

Engine loading

The new Turbulenz Loader updates should allow multiple engines to run side-by-side. This means games on turbulenz.com can be built to work with different engines. This is ready to support turning on the feature on turbulenz.com very soon.

Networking

NetworkLatencySimulator object can be used to simulate spikes in latency and help with real-world multiplayer testing.

Tools

The maketzjs tools now runs the strip-debug tool, removing specific debug code, such as asserts in release mode.

Node.js is now included in the SDK. Perfect for use with Uglify.

Physics

A new calculateTransform function has been added to RigidBody, CollisionObject and Character.

Contact callbacks have been added for interactions between RigidBody, CollisionObject and Character.

Added the concept of a ‘trigger’ CollisionObject.

Turbulenz Services

The Leaderboards sample demonstrates the best way to create in-game leaderboards.

Input

The inputDevice now has a function isSupported. This can be used to check if pointer lock is available.

Icons

The Hub now supports the automatic re-sizing of leaderboards and store icons. Provide a 256x256 icon and it will be scaled to fit the correct places on turbulenz.com.

Fixes

Corrected the standard deviation in Profile.

T1292 - Fixed crash when not specifying callback in makePublic, updated docs.

T1246 - Fixed Websockets implementation on plugin not handling fragmented messages. Corrected for Windows/Mac.

T1299 - Updated documentation for additional Mac/Linux commands

T1243 - Fixed issue where plugin hideMouse and showMouse didn’t behave as described in the docs

See the 0.24.0 release notes for more details.

The SDK is available to download from the developer service at hub.turbulenz.com.

Denki Word Quest - now live and seeking literate adventurers

Wed, 12 Dec 2012 15:00:18 +0000

Denki Word Quest - an innovative adventure word game peppered with RPG elements - is now live and seeking literate adventures to play on Turbulenz!

Battle your way through a few levels as the courageous Biblio, taking on the minions of Wordor for free. True adventurers can unlock the full quest for only £3 / €4 / $5 using our super-slick new payment system (powered by Amazon).

Our pals at Eurogamer said it better than we ever could:

“the whole thing’s wonderfully warm-hearted and witty, from the seemingly random quest chatter that sends you on your way to the varieties of monsters - including evil kittens and obdurate boneheads - you’ll meet along the path to victory”

Play Denki Word Quest here!

Intern report - 2D and 3D JavaScript physics added to Turbulenz

Wed, 21 Nov 2012 15:23:23 +0000

My name is Luca Deltodesco, intern at Turbulenz for the last four months as part of my four year MSci Maths and Computing course at Imperial College London.

I’ve always been interested in, and worked with in my spare time, the technology behind games; Turbulenz then, was a perfect fit to work with emerging, and powerful gaming technology for the Web. Following my application, and a face-to-face interview at the office in Guildford I felt this is where I wanted to be.

Starting my placement in early June, I began to wrap my head around the development SDK and brushed up on my JavaScript knowledge. Though I had held presumptions about using JavaScript in large projects, I found that the deficiencies of the language can be circumvented through good practices.

Following my induction, my first task was to begin development of the Canvas PhysicsDevice, adding ray-casts and convex-sweep support so that all the weapons in the Quake 4 tech-demo could be used outside of the plugin. After completion of this task, I began to work on the full implementation of the Canvas PhysicsDevice available in the SDK today!

Implementing the PhysicsDevice was a big project, helped greatly by having had previous experience with 2D physics, but there were a lot of new things to learn. A lot of the time was spent working out the most efficient ways of implementing the physics for JavaScript and tuning physics parameters for the best behaviour.

During the implementation, I worked on a side project in Python - which first required *learning* Python - for the optimisation of collision meshes in the Quake 4 tech-demo. This involved a fair amount of computational geometry that eventually found its way into the WebGL PhysicsDevice, optimising convex hull collisions through abuse of the triangulated hull topologies, and ray testing of convex hulls by using the triangulation.

After much perseverance, the PhysicsDevice was completed (Minus some constraints) together with the Physics Benchmark SDK sample.

My next task was the Draw2D library. This library was originally written for the Score Rush game, and required tidying and optimising before being released into the SDK. I made use of Chrome’s profiling to analyse the bottlenecks of the API and was able to make some quite drastic speed improvements. We later had a meeting to discuss changes and extensions to the API which turned into the Draw2DSprite object, and drawRaw interface.

The Draw2D SDK sample was created to demonstrate the capabilities of the library.

Another aspect of the original Draw2D library, was a full-screen bloom and distortion effect. These were generalised and separated from the Draw2D library, and after adding the Gaussian Blur effect, Color Matrix effect and related utilities, the TextureEffects API was born.

Turbulenz now had fully functional 3D physics for both Canvas and Plugin, but with an expected influx of 2D games, including the Save The Day game, it was clear that the Turbulenz SDK should also provide 2D physics. I spent a short time on researching existing solutions including Box2DJS and Box2DHTML5, as well as my own library compiled for JavaScript, none of which proved to be performant enough; it was decided that I should implement a 2D physics library for Turbulenz which would be high performing, and fit in with the rest of the APIs instead. As a formal project, I wrote up a Project Charter and initial API specification that other members of the team could read over and give their input after which I took a well needed holiday.

Returning from my holiday, I had only 4 weeks left to implement the 2D physics; I took a pragmatic approach of breaking down the project into discrete, unit-testable tasks so that I could develop the library quickly, whilst being confident there were no major bugs. With the experience of the WebGL PhysicsDevice and Draw2D, I could see immediately how best to implement the API for speed in JavaScript from the get-go, and everything was completed in time together with the documentation and the three 2D Physics samples.

Looking back, I thoroughly enjoyed my time at Turbulenz and gained much experience and knowledge.

Intern report - biz site reboot and prototyping library added to Turbulenz

Tue, 20 Nov 2012 14:42:00 +0000

I’m Shaan Malik and did an internship at Turbulenz for 4 months, between my 3rd and 4th year studying Computer Science and Maths at Imperial College, London.

When applying for internships, the thing that struck me about Turbulenz was their Quake WebGL Tech demo (a more recent tech demo). It was beyond what I thought was possible with HTML5 and WebGL, given the handful of WebGL demos I’d seen prior to that, and so it piqued my interest. I figured getting to use a game SDK as well as seeing how one was made wouldn’t be a bad way of spending an internship.

My first project was to implement a redesign for the business site. That is, I was given some images illustrating the look of the site, and how it should be structured visually, and had to create a website that followed the design. While I had some experience making websites pre-university, it’s rather different when you’re making something that’s actually going to be seen by people, and scrutinised by work colleagues! So no pressure.

It also involved picking up more libraries than I’d ever worked with before, including: Bootstrap for a CSS grid layout, Sass as a CSS extension to making writing the styling more concise, jQuery for bits of DOM manipulation, and tornado.template as a python templating system.

Of course, there was a purpose to using all of these libraries: Being a business site, cross-browser compatibility was a priority, but it was something I quickly confirmed was challenging to do. The CSS in Bootstrap and the JavaScript in jQuery having been tested in multiple browsers went some way to alleviating these sorts of problems. Using a templating system allowed me to write some python to generate html snippets for things like the section navigation above each section on a page. All that needed to be specified were the section names in a list, and the script would handle some things automatically, like generate i.d’s for hashlinks, and surround the active section with a div tag and a class so it could be highlighted in the CSS. This saved having to write some HTML by hand, as it would’ve been error-prone and tedious to change by hand, and also paid off when I needed to make quick changes coming up to the release date for the site.

A nice thing is that, when I say I worked on making the site, people assume I did the design work too, which I don’t always have to correct them on. But seriously, the reason it looks as good as it does was because of the keen eye of the designer (Thanks Ben!).

My next project, dubbed “Protolib”, involved designing an API to prototype games, by presenting a simple interface that provides several functions to let you perform basic actions like playSound, loadMesh, draw3DLine, etc. The purpose was that it should allow for writing shorter game code, and be faster to learn than the full SDK, by handling some necessary setup code internally.

Of course, before I could start, I needed to figure out how to do all of the things Protolib needed to do using the SDK, and so I just started writing a sample app and tried adding an example of each feature I would need to put into Protolib. In hindsight, I’m lucky for the team’s good humor when I was still getting my bearings, because I was so focused on figuring out the SDK that I didn’t pay any attention to how odd my sample started looking. It involved a tree orbiting above a wooden floor, which disappeared when you pressed space.

I did eventually produce a neater sample while finishing off the Protolib API, with (lots of) advice from Adam Langridge on the game team. The purpose of this final sample was to demonstrate how to use Protolib, showing as many features in as few lines as possible, without sacrificing readability. The intention was that by studying the sample, a developer could quickly figure out how to use Protolib. The final sample was < 200 lines, and included logic for a basic camera controller. With help from James Long on the game team, I refactored the game code into a particular structure which allowed me to handle the game update loop externally from the game code, which simplified the game code further.

To finish off the project, Adam suggested running an office 1 hour game competition: to make a game in Protolib in an hour, with a Wario-ware theme. Since I hadn’t any experience in game competitions, I went for something simple that I could expect to complete in an hour, and went for comedy over substance. The goal was to “Push Coneman off the roundabout”, as I recall writing, and the controls were alternating the Left and Right arrow keys as fast as possible, which made the roundabout spin faster. Almost everyone that played it found it hysterical, which was of course exactly what I was going for.

In all, what was most worthwhile was the experience of working in a team, and getting into the habit of discussing potential solutions to problems, just to gain feedback. I also learnt (too late) that when it comes to refactoring and writing documentation, it’s really not a good idea to just use a text editor (Vim). As I leave to venture forth into the fourth year of my degree, I’ll miss playing Trials Evolution on game nights, which was also a lesson in how to make bugs entertaining rather than frustrating (the sound of a guy screaming while falling off his bike, stuck on a loop after you finished a track is a feature!). The work environment is great, and it was a great introduction to working in the Software Industry, but was most useful in that it showed me how far I still have to go.

Initial response to Save the Day

Fri, 09 Nov 2012 12:19:05 +0000

Denki’s Save the Day has only been live on Turbulenz for a few days and already people seem to be pretty happy with it. Here’s some of our favourite comments from across the web:

“Impressive work, a reference for browser based plugin-free games” - carloslunetta on Twitter
“For a browser based game, it’s err… incredibly awesome! It’s almost console quality” - TangentsLP on YouTube
“I’m not pulling any punches here, you need to play Denki’s ‘Save the Day’ NOW!!!” - StewHogarth on Twitter
“Hats off to the one artist who managed to create and animate all of this so wonderfully. Great fun.” - RoryKdy on Turbulenz
“This game is fun. You should play it. Cos then you will have fun. You do like fun don’t you?” - LukeD on Twitter
“Great game from Denki recommend trying it, really addictive and fun.” - Briamond on Twitter
“Wow, um… that’s actually a lot of fun.” - darabidduckie on Joystiq Comments
“its very good, nice particle effects” - Aphelio on Twitter
“very awesome game, love it.”- tortus on Reddit
“It’s insanely cool.” - iamaaronalex on Twitter

Find out for yourself at ga.me/save-the-day

Play-before-sign-in added to Turbulenz

Fri, 02 Nov 2012 12:33:04 +0000

Turbulenz SDK 0.23.0 is now available on the hub.

The main update in this release is to add support for “Play before sign-in”. This allows users to try games before signing into the game site. The web services are smart enough to then allow users to create accounts later and keep all the badges, scores and their game progress.

New Features

Support for Internet Explorer 10 has now been added.
Support has been added in Turbulenz Services for play before sign-in. Games that are built with this version of the SDK will automatically support play before sign-in, when available on turbulenz.com

Fixed

In previous versions, calls to Turbulenz.setInterval() in plugin mode could generate callbacks at 60Hz independent of the interval value passed in. This has been fixed.
The previous version of the Turbulenz Engine installer (0.22.0) for Mac OS X unconditionally replaces parts of existing plugins, even if a newer plugin is already installed. This has been fixed, but users installing 0.22.0 after later versions of the engine should be aware of this behaviour and should ensure that they (re)install the newest Turbulenz Engine after 0.22.0 if they wish to continue using the 0.22.0 engine alongside newer versions.
Callbacks from the NetworkDevice are now called asynchronously, fixing an inconsistency between the canvas and plugin versions.
Sending of websocket data >8kb was being incorrectly buffered in the plugin (T1221)

The full release notes are available online at docs.turbulenz.com.

Physics and multiplayer technology updated in Turbulenz SDK 0.22.0 release

Mon, 22 Oct 2012 13:32:24 +0100

Summary

Turbulenz SDK 0.22.0 is an update for both the Turbulenz Engine Installer and SDK components.

Full release notes are available in the documentation online.

The SDK can be downloaded directly from the Turbulenz Developer Hub.

The SDK is available for Windows, Mac OS X and Linux.

New Features

Payments

Turbulenz payments for local and the Hub is now supported. To use the Turbulenz payments see the documentation for the StoreManager object. Please note that the game site does not yet support payments. Any games published to the game site should not use the StoreManager object.

Leaderboards

The leaderboards.yaml now takes an optional set of default scores for the leaderboards.

Physics

Physics2DDevice object added for high performance 2D physics simulations with Turbulenz. This is a complete 2D physics engine built from the ground up, and optimised for JavaScript.

Physics2D comes with 3 new samples: Physics2D, Physics2D-Constraints and Physics2D-Callbacks demonstrating the main features of Physics2D and co-operation with Draw2D library.

Math

Added 2D vector types and operations to VMath and the MathDevice.

Badges

Badges now allow you to specify an optional predescription, which if specified is used as the description until the badge is unlocked. See Defining your game’s badges.

Debugging Tools

Added DebuggingTools which allows data breakpoints to be set on object properties and array indices.

Rendering

Transient IndexBuffers are now supported: this kind of IndexBuffer is optimized for dynamic single use geometries.

The only change required to use them is to set as true the parameter transient when creating the IndexBuffer.

Multiplayer

The Multiplayer functionality exposed via the TurbulenzServices object has moved into the MultiplayerSessionManager object, please see the documentation for full details.

The behaviour of the createSession function is different to the behaviour of the old createMultiplayerSession function and will now always create a new multiplayer session. If you want the old behaviour please use joinOrCreateSession.

The new functions queryFriendsSessions and joinAnySession allow you to find friends’ multiplayer sessions or join a friend’s multiplayer session automatically.

getJoinRequestQueue replaces the previous methods for responding to multiplayer join requests originating from the game site.

New user session information can be displayed on the game site. The API to add per-player meta-data is exposed on the GameSession object via the setTeamInfo and setPlayerInfo functions.

Services

The DyanmicUI and BridgeServicesSimulator allow you to easily build powerful dynamic user interfaces and preview your integration into the games site while developing games on the local server or the Hub. A version of these tools is included in the MultiWorm sample provided with the SDK. To try them out in your own project simply copy across the contents of the js folder into your own project, add the file duimanager.js to your scripts directory, add duimanager.css to your css folder and add the following lines to the header of your html template:

Changes

Engine

The engine loader will now respect the engine version specified for your game. This can be done in the Manage tab for the game in the local development server or directly in the game’s manifest file by adding the line (for instance with the current engine version):

engine_version: ‘0.22.0’

For the game to be publishable, this engine version must be a three-part string (of the form X.Y.Z).

Fixed

Fix for a deficiency in Draw2D for Draw2DSprite objects that previously assumed a 1:1 ratio between Draw2D coordinates and screen pixel coordinates. This previously led to a visible slack in updating of rotations when Draw2D viewport resolution was significantly smaller than that of the screen.

The canvas version of SoundDevice no longer generates 404s on Firefox when sound source stop() is called.

Input events now cause all callbacks to happen outside of the game loop in both canvas and plugin modes. Previously canvas and plugin modes were inconsistent with some callbacks being made during the call to InputDevice.update. Note that InputDevice.update should still be called to ensure all events are reliably delivered to the game.

Fix for the leaderboardResult scrolling functions throwing an exception when a callback argument is provided in TZJS and release builds.

Fix for custom objects appearing as functions when passed from Safari to plugin JavaScriptEngine.

6 messages coming from the 2012 Social Gaming Summit in Berlin

Wed, 25 Jul 2012 17:28:33 +0100

While slightly delayed, we have decided to provide a brief recap and our key takeaways from the Berlin Social Gaming Summit back in May. Better late than never!

Arcade vs Resource games

According to Kai Bolik, CEO Game Duell, online Arcade games are doing pretty well. In 2011 they accounted for 50% of total MAUs playing games on Facebook compared to only 10% in 2010. While they don’t monetize as well as traditional online Resource games (APRDAU of 3 vs 5 cents), they tend to have longer lifetime engagement driven by well-known and simple game mechanics as well as higher replayability. While revenues appear to be more evenly distributed among Arcade gamers, 3% of gamers still account for roughly 80% of revenues vs 90% for Resource games. Across all freemium games on Facebook – which includes Arcade and Resource games – it appears that females account for 70% and those aged 50+ account for 46% of all gamers.

Real-time Multiplayer can reduce CAC to $0

One interesting point that was made during the Summit was that gamers don’t pay for features but for value. Apparently, a real-time multiplayer game – still very unique in today’s online gaming landscape – presents a great deal of value to gamers. Jens Hilgers, CEO of Geewa, commented that their most successful real-time multiplayer Facebook game ‘Live Pool Tour’ grew from 0 MAUs to 10 million MAUs in a matter of weeks. Guess how much they spent on acquiring customers? The answer is $0! Apparently viral distribution is still possible but the developer needs to find new ways of adding value to its users.

Frictionless payments are key

I guess we always knew this but it’s good to reconfirm it every now and again. Frictionless payment services are integral to converting active users to paying users. ARPU on iOS is close to 5x higher than on Android for the same game.

Cross-platform has its benefits

Cross-platform games appear to present a number of benefits. Gamers can play 24/7 irrespective of location, developers/brands receive more exposure, there are more CRM touch points, and there is greater ability for cross promotion. In the case of Game Duell, 45% of its gamers are cross-platform today and ARPU and retention are 14% and 25% higher for cross-platform gamers.

Diversify your Consumer Marketing activities

According to Lloyd Melnick from fiveonenine games, Performance Marketing is getting more expensive and less effective. CPC and CPM are up by 41% and 23% respectively from Q411 to Q112. On top of that, click through rates on Facebook are down 8% over the same time period. Among other things, Melnick advises developers to expand their consumer marketing activities and to do a better job engaging users through social marketing campaigns on Facebook and Twitter.

What’s important to developers

I guess it’s no surprise that the industry – the people designing and developing the games – are having a hard time keeping up. There is AAA and there is casual; there is online and there is mobile; there are ‘real’ gamers and there are ‘social’ gamers. With so many moving parts, Jens Hilgers, CEO of Geewa, commented that developers today are most interested in a fixed framework for publishing, monetizing, analysing, testing and iterating their games, while also reaching the largest possible audience. Fortunately, Turbulenz is in the process of addressing all of Jens’ desires.

In conclusion

All in all, we’ve learned a lot during the Social Gaming Summit in Berlin that supports Turbulenz’ vision for the future of HTML5 and browser based gaming. Over the past couple of years we’ve put in place a framework of technologies and services that developers can leverage to:

build high-quality 2D or 3D games,
test and iterate these games in a live staging environment, and
publish, monetize and analyse these games on turbulenz.com, an online gaming destination that supports a completely new generation of unique APIs that span both the Turbulenz game engine and the cloud.

While many initially doubted our ability to deliver on such big ambitions, we’re beginning to see more and more traction with developers and consumers alike. In the wise words of Arthur Schoppenhauer, “All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident.” We are confident that we are nearing the third stage of Schoppenhauer’s prophecy.

"phoenix down" and biz.turbulenz.com is re-born!

Tue, 10 Jul 2012 18:25:00 +0100

biz.turbulenz.com was re-born today with a new look and lots of new information about our products and services.

‘Turbulenz‘ covers all things to do with our consumer game site and it’s awesome social functionality. ‘Developers‘ and ‘Partners‘ have everything you’ll need to know about getting started with Turbulenz, downloading the SDK and project funding. ‘Careers‘ has information about the team and how you can join us and ‘Press’ is a constantly updated resource of all our logo assets, key reading links and press coverage.

There’s more up-to-date information and links to resources across the site now — if you think there’s something missing let us know by email (or tweet us) and we’ll add it.