Developing Connected TV Games
Challenge: Many Platforms and Many Games…
We are often asked, what technology do we use to develop multi-platform Connected TV games for:
- Smart TVs (Samsung Tizen and Orsay, LG webOS and NetCast, Hisense, VESTEL, Vizio, Panasonic, NetRange, Foxxum, Chromecast, etc.)
- IPTV/cable set-top boxes (Arris, Albis, etc.)
- Multiple versions of HbbTV standard
Considering the number of platforms and games we support, we defined four principles we adhere. We have discovered and fine-tuned them “on the go”, sometimes in a pretty painful way full of mistakes. Those principles are:
- Automatic games building and deployment
- Building games from a single source for all platforms
- Unifying source code structure (until certain extent) across all games
- Handling technology and performance limitations of TVs
All TV platforms are based on JavaScript language, so in theory there are plenty of frameworks to build games on… However TVs have many (often hidden) technology restrictions and performance limitations, so soon we have discovered that every framework has issues on certain platforms and we need transpilations, workarounds, etc. In the end, despite of a large diversity of JavaScript frameworks and libraries, we ended with vanilla JavaScript used for big portions of the game code.
We also realized that it is very hard to create the real multi-platform TV game from scratch without having:
- Good experience with TV development (we have been developing TV apps for over 7 years)
- Large amount of test devices (we have over 200 TVs for testing, while on daily basis we use around fifty of them).
Welcome to reality…
Our Approach
For automatic builds we use Jenkins and webpack — we build game packages and deploy them automatically to the origin hosting server (all games are hosted in a similar way as web pages). Automation is crucial: Imagine that you have to provide update for 20 games and 10 platforms — it is 200 packages in total, so everything needs to be automated.
All our games are built on the top of tiny abstraction layer, which hides the differences between various TVs and middlewares specifics and their APIs. When a new TV platform has to be supported we update the abstraction layer, add new platform to the automatic build process and start testing. Process of porting to a new platform takes around 1 week.
Having the unified source structure is also must: First games were built in various ways based on developers’ experiences. Later we came up with a template, which handles various aspects of the game (menu, high score, etc.) and unifies the way game scenes are prepared, screen elements are manipulated, etc. Having a template enormously simplified maintenance: It allowed our developers quickly understand the game code they never saw before and deploy changes across all games in a timely manner. We have updated the game template many times (and it is still subject of constant changes) and we were even forced to completely rewrite some games.
Pixi.js
The hardest part is however rendering and performance — some TVs do not support HTML5 canvas, some have problems with WebGL, some platforms cannot use either one of them and therefore we are forced to directly modify DOM elements… So all games must be able to render in all three ways in order to work everywhere. After trying many frameworks we ended up with Pixi.js — a lightweight rendering library which allows us to have WebGL and Canvas at once. This is essential in our multi-platform TV environment. Pixi.js surprisingly works on almost all platforms except some older legacy devices.
Currently, we have over one million game launches per day on 10 platforms and all of those are powered by Pixi.js.
Our complete devstack contains: JavaScript ES6, HTML5, pixi.js, flow, babel, webpack, jest, sass and node.
We love TV Games development but as you can see there are many troubles on the way…
