Digital entertainment creators Goodboy have revealed pixi.js. The company describes it as a fast, lightweight 2D library that’s designed to work across desktop and mobile. The renderer also enables anyone to “enjoy the power of hardware acceleration without prior knowledge of WebGL”.
The engine taps into the company’s philosophy of ‘build once, play anywhere’, and Goodboy strongly believes that HTML5 is becoming a viable tool to achieve that goal. Pixi.js source code will be released on GitHub within the next two weeks, once documentation and tutorials are complete. In the meantime, .net spoke to Goodboy founder John Denton about the engine and how it could benefit web developers.
.net: What’s different about pixi.js? Why will our readers be interested?
JD: It focuses purely on rendering — it's not just a games engine. So it’s great for other rich media experiences. It also works with WebGL, so it’s super fast! With mobile browsers now starting to adopt WebGL, this becomes increasingly relevant, and if WebGL is not available, pixi.js seamlessly adopts a Canvas renderer. The two renderers look the same, and so there are no visual discrepancies between browsers, although we are looking to implement specific additional features to make use of added horsepower, such as filters, displacements and particle effects.
.net: What sort of projects do you see pixi.js as being useful for?
JD: Our aim is to make a useful set of tools enabling easy creation of Flash-like experiences, but across as broad a spectrum of devices as possible. We can't match the performance of native apps, but we can deliver genuinely high-quality app-like experiences to mobile browsers. The Run Pixie Run demo is an example of the visual fidelity achievable on good-spec mobiles.
.net: What have you done to make things easier for developers?
JD: Pixi.js was designed with speed in mind and to shield the user from device-specific issues. The API is also simple to use, abstracting away WebGL/Canvas implementations. So if you get something working in one browser, it should work on them all.
.net: Do you think a ‘build once, play everywhere’ philosophy is realistic?
JD: We follow this philosophy by sticking to three steps. First, we design and concept an experience by considering how it will need to adapt or perform from large screens down to mobile. We then ensure the layout is fluid when required — something increasingly commonplace with websites but less so with entertainment experiences. Finally, we follow the PC games model with the core experience remaining consistent and bells and whistles scaling to fit the hardware.
On that last point, Run Pixie Run degrades and removes some effects on slower browsers. To achieve this automatically, we do a three-second stress test on a device before loading the rest of the game. But we’re not looking for what the platform is — just how fast it runs. We can then go to town, safe in the knowledge that if the hardware’s going to be stressed, you’ll get a version to suit.
.net: You’ve mentioned using tools such as yours for side-stepping the App Store and similar ventures. Do you have any thoughts on monetisation when doing so?
JD: From our perspective, the ability to create interactive mobile content in-browser is of particular use for client applications and, as such, is perhaps less focused on the type of paid/IAP [in-app purchase] revenue-generation apps are good at. We do still make apps when that is the goal, but mobile brand experiences of the kind Flash has been doing on desktops is where we see this deployment model really offering something exciting and new.
Paid content is currently trickier due to the open nature of HTML. However, with pixi.js being built entirely from JavaScript, anything using it can be packaged into an app by using something like PhoneGap.
