AirConsole Dev Diary: Our first Local Multiplayer game for AirConsole

Connect your smartphone to play party games on AirConsole

This article was originally featured in the Making Games magazine in January 2016 under the title "AirConsole: Local Multiplayer Reinvented".

The writer, Alice Ruppert is a game developer for N-Dream AG, the newly founded company behind the AirConsole platform and some of its games. She started working for N-Dream in late June 2015 right after graduating from Zurich University in Arts in Game Design. In the roughly two months between starting work and the AirConsole’s launch day, she made a game called ‘HitParade’ with her colleague Martina Hugentobler, with whom she’d previously worked on Panakeia, their Bachelor graduation project at Zurich University of the Arts.

The Basics: What is AirConsole?

AirConsole is a virtual console - a completely free, completely web-based gaming environment, where smartphones are used as controllers while a PC, tablet or TV serves as the screen.To connect their smartphones to a big screen, players go to in their browser on both devices and enter a code they see on the big screen into a number pad on their smartphone.

AirConsole is free for players and developers. We’re currently focusing on growing our user base and providing the best local multiplayer experience. Eventually, the platform will be monetized by ads shown between game sessions. The platform itself and the games we currently have are developed at N-Dream AG in Zurich. The majority of our team has started working on it in June 2015.

People playing AirConsole
Locally Social
We here at N-Dream see AirConsole’s main potential in local multiplayer games - thousands of smartphones can easily be connected to one screen at a time. This multi-screen gaming experience encourages and sometimes requires people to interact with others sitting right beside them.

Local Multiplayer has been steadily disappearing from the big consoles for years - although there are exceptions of course. Games that support more than two players on one couch are already rare, whereas games for more than four players in the past five years can probably be counted on one or two hands.

Accessibility: Software

Connecting to AirConsole is kept as simple as possible
It is of great importance to us that AirConsole and its games are as easily accessible as possible. As such, we focused a lot of our efforts on the first few seconds within the player’s arrival on our site.

All players need to do before they can play is go to on their PC and smartphone and enter a short code on the latter. This process takes less than half a minute. A Smartphone App does exist for comfort, but to try out the platform, no downloads, plugins or registrations are required.

Ideally, our games will share this philosophy and are easy for the player to get into quickly - even if some may be hard to master.

The fact that nothing needs to be downloaded happens to be an advantage not only for players but also for developers, who then don’t have to worry about players using outdated versions of a game.

Accessibility: Hardware

Be it on a PC or console: one of the main bottlenecks that keep people from playing local multiplayer with more than one or two friends is the high acquisition cost of additional controllers: Playing a game with 8 people on an Xbox One for instance, means about 400$ worth of controllers, not counting the one that came with the console. That’s not the sort of money most people can or want to spend on a quick game.

AirConsole doesn’t share this problem: In Western and Northern Europe for example, between 60 and 90 percent of the population between 18 and 24 years of age owns a smartphone. For us, that means almost everyone in our target group already has the required hardware and carries it around all the time. As for the ‘big screen’ device: For most AirConsole games, an average laptop or even tablet will suffice, no expensive gaming rig is needed.


A reaction to the general concept of AirConsole that we’ve gotten a couple of times is something along the lines of: “Why would you want to use a smartphone as a controller? Pressing buttons without haptic feedback suck!” Yes, it does. It works with one or two large buttons, but having to press several small buttons in a game where timing has any importance at all is terrible on a touchscreen. Thankfully, that is not what we have to rely on. The AirConsole controllers don’t have to directly compete with a regular gamepad.

One option would be to remove the ‘timing’ factor: card games or turn based RPGs would all work perfectly fine with buttons on a touchscreen, because you don’t have to press the buttons blindly, but can instead take the time to look down at your controller and aim your finger at the pixels you want to press.

But since working without timing greatly limits your game design options, let’s consider the alternative: Don’t use more buttons. Smartphones offer a variety of inputs that most gamepads don’t: swipes, shakes, and tilts for instance. Keep in mind a smartphone also has one or two cameras and a microphone which we can technically make use of for AirConsole development.


In the AirConsole store overview players can choose what to play next

On our launch day in the first week of September, the AirConsole store had six games, plus a NES emulator. We got a lot of comments along the lines of “This is super cool, but you need more games”. Well, yes we do. Our team of six people is working hard to create more awesome content, but to eventually have a full library of great and diverse games, we are working with third-party developers and are trying to give them the best possible tools to develop for our platform: AirConsole has a public API and offers plugins for Construct 2 and Unity3D.

In addition, we decided to launch a competition for game developers. To keep the competition and our platform as accessible as possible, we allow ports as well as original games, and offer support for interested game designers.

Our First Game

My colleague Martina and I were hired as a team and knew we would continue to work together as a duo within the bigger AirConsole team. That had the advantage that we have pretty well established knowledge of each other's skills and competences and generally get along really well.

For Hit Parade, our first game with AirConsole - and really our first multiplayer game together in general - we wanted to keep it simple. We knew we only had roughly nine weeks until release. In these nine weeks our team of two was to not only make a mini game from scratch, but also to get familiar with AirConsole first, to get to know WebGL along with its advantages and disadvantages, to learn how to properly optimize a game for Web, to develop a visual style to use for this and future games, to create 8 different characters (respectively character skins) and make the game playable for 1-8 people. In short: we had a ton of stuff to do in very little time.

We did release a version at launch, but it took us four more weeks of development until we were comfortable calling the game ‘done’ - for now.

Getting to know AirConsole

HitParade Controller PreviewBecause I lack proficiency in HTML5, JavaScript and any development of online components, really, a freelancing developer and former University colleague was hired to create a Unity Plugin for AirConsole. After a week or two of making prototypes controlled by keyboard, I was able to start using the newly developed plugin.

For our first AirConsole game, I wanted to keep the inputs as simple as I could: no need to complicate things by working with smartphone inputs I had absolutely no experience with, right? Especially because until this spring I had only ever developed standalone games for PC/Mac, controlled by mouse and keyboard. I didn’t know any JavaScript and had never made a game for mobile devices.

To compensate for this lack of knowledge and to keep it manageable, we planned to use two buttons, each taking up half the controller’s screen. While that did work out for the game’s first version, I ended up using swipes for navigation in the launch version nonetheless and implemented shake controls within two weeks of initial release.

I didn’t write those myself, but implementing JavaScript libraries into my controller.html’s proved relatively simple once a colleague showed me how.

The concept of HitParade

Play HitParade on AirConsole
HitParede Screenshot
To give a brief overview of the game we ended up making: HitParade is a minigame for 1-8 players. Players move on an elliptic path, its size depending on the number of players. Next to the path the players move on, there are thorny fruits that appear small and green, grow to yellow and orange and eventually explode red. Every player carries a large hammer and taps their screen to smash the thorny fruit while they’re small to get the most points.

When a player hits at the wrong time, they fall off the path and are vulnerable to be hit by other players and thus have their points stolen. To get back on the path, the player now shakes his or her smartphone for a moment. The first player to win a specific number of points wins the round.
My skill and lack thereof

Working at N-Dream is my first job after graduating from Zurich University of the Arts (ZHdK). At ZHdK I did learn what I know about coding, but I would still hesitate to call myself a ‘programmer’ - even though programming is about 80% of what I’m doing at the moment.

Panakeia Art Work
The AirConsole product HitParade and our graduation game Panakeia are two very different projects - one is a visually intense roguelike shooter using around 12 different keys for input, the other is a cute-looking one-button casual party mini-game for 1-8 players. Safe to say, there were quite a few new challenges for us.

The only ‘Multiplayer’ Game I’d made before HitParade was TypeFight - a fighting game for two players on one computer. Making a multiplayer game for players with separate devices, or making anything with an online component to be precise, was something that I’d always considered too complicated for a relative beginner like myself. Thankfully, my job at N-Dream doesn’t require me to handle servers and connections.
Developing for AirConsole

For most of the time, when working on the basic mechanics, making a Unity game for AirConsole is pretty much the same as making a standalone game. There are however, plenty of things to be considered, especially on the technical side.

Game Design

While nothing really keeps anyone from bringing a single player game to AirConsole, it’s strength and appeal definitely lies in quickly accessible local multiplayer games, or ‘party games’.

Controller/Screen Communication

The AirConsole API lets you send messages from screen to controller and back. For example: each time a button is pressed on the smartphone, the controller script sends a message to the screen containing an identifier and in some cases a timestamp. The screen - that means one of my C# scripts in which I listen for AirConsole events - then decides what to do with that input, such as calling the Hit() function on the player script belonging to the device from which the message came.

The messages I send from screen to controller include things such as what to display on the controller right now, or which character image to use for this specific player. Some messages that concern all controllers are broadcast, others sent to a specific device only.

I try to put as much of my code as possible into my C# scripts and avoid doing any calculations on the controllers themselves - partially because I like to have it all in one place, but mostly because I still lack JavaScript proficiency.


The question of latency is often the first one addressed when developers hear about the concept of AirConsole. Yes, there is a certain delay between the tap on your controller and the moment that the message is received in your screen script. Thanks to AirConsole using Google Cloud infrastructure, we are able to keep the latency at a minimum however: We usually have delays of around 80 milliseconds.

HitParade Gameplay on AirConsole A tenth of a second isn’t a lot of time, but depending on the pace and design of your game, that can be very noticeable already. If the devices that are part of a game support WebRTC, the AirConsole API automatically uses that, which reduces latency drastically. Unfortunately, WebRTC isn’t supported by all browsers yet (e.g. iOS Safari) and therefore we can’t rely on it in our game design.

For our game HitParade, we sneakily hide the latency within an animation: The nasty thing about latency is that it’s never exactly the same. With the same internet connection and the same devices, the latency will still fluctuate. In a game based on timing - which applies to HitParade - this can quickly lead to frustration for the player, because there is no way for them to accurately assess the right time to tap the button.
HitParade animation

The solution for us was to make sure that the time between the player’s tap and the caused effect - meaning the point of impact of the character’s hammer - would always be exactly the same, regardless of latency.

The AirConsole API has a synchronized clock. When the player taps their controller, I send a message to the screen containing not only the type of input (“hit”), but also a globally synced timestamp of when the message was sent. As soon as the screen receives this message, I can measure how much time has passed since said timestamp and receive the exact latency. I calculate how long the ‘Hitting’ animation has to be in order for animation + latency to equal my standard value of 0.5 seconds and modify the animation playing speed accordingly.

Thus, with the entire action always taking precisely half a second, the player can time their hit input accordingly and can learn to get a feeling for the game. This is of course a specific solution for this particular game, but similar measures can be taken for timing-based games to work despite varying latencies.


Making our first AirConsole game run smoothly was one of my main focal points during development. For previous projects, I’d always been glad as soon as something worked at all and I mostly neglected making things work very efficiently. Since I am now developing for WebGL, I can’t afford to ignore performance anymore.

Even though the Unity3D forum and documentation is a valuable resource in matters of optimization, I probably learnt the most about it in a roughly two-hour crash course by Goran Saric, a co-graduate who not only has ten years of programming experience on me, but also happened to have just finished his BA project with a special focus on optimization in Unity - a mobile casual Game called ‘Panda lost in Space’, which is currently still in further development.

Now, these may be old news to experienced devs, but they were some of the most valuable tips for me: Don’t regularly instantiate or destroy GameObjects. If possible at all, Instantiate them in the beginning and then hide their Mesh Renderers (and Colliders, if you’re using them) while you don’t need them. This is called Object Pooling - creating a pool of objects and then reuse them. One very fitting application would be the bullets in a shooter: a lot of performance can be saved by hiding, replacing and then showing objects again instead of instantiating and destroying.
In HitParade, no object gets destroyed, everything is reused: From smashable fruit to particle systems Cache variables. Don’t declare new variables in loops. Declaring variables takes up performance, referring to them less so. In most of my scripts, all variables used are declared at the top of the script.

Do as little as possible in the Update() Function. Put things into the FixedUpdate instead, where you know how many times a second it is executed - and you can modify the Fixed Timestep value to call the function only as often as is necessary. If anything can be done 10 times a second instead of 50, don’t put it in an Update.

Incidentally, I ended up having a lot of fun with optimization and now laugh at my old, inefficient code. I’m even enjoying diving back into Panakeia’s code and optimizing the crap out of it.

HitParade’s mechanics were designed from the very beginning to be light on performance. For instance: We do not use any collisions or physics whatsoever. Additionally, basically all regular calculations are not done in 3D really, but instead on a one-dimensional path, which makes the core gameplay very light on performance.


Even with a lot of effort put into optimization, there are certain limits to what type of game makes sense for AirConsole. With one of our core foci being accessibility, we want AirConsole games to run on all sorts of machines, not just powerful gaming PCs. AirConsole can be run on tablets and old laptops and its games should run with acceptable frame rates on devices that are a couple years old.


As I’ve mentioned, my programming experience so far has been limited to Unity3D and C#. Now, the biggest part of game development still happens inside the engine with AirConsole, but not all of it. On the smartphone controller, we aren’t running a Unity Build, we merely display a HTML page and make it look nice with CSS. The implementation of special Input methods is handled in JavaScript.

This may be obvious and no issue to a web developer, but still: For anyone who hasn’t done any web development, that’s three new syntaxes to learn and work with. Thankfully there are a ton of JavaScript Libraries and scripts which are openly available and thus greatly facilitate the implementation of smartphone-specific inputs like Swipes and Shakes.


The ability to build to WebGL / HTML5 with Unity3D is still a relatively new feature and is still under development. Unity’s documentation itself states that their WebGL builds are currently a “early-access preview release”. As such, the exact features of WebGL can change drastically with every Unity update. Here, it’s important to have an eye out for patch releases and read changelogs thoroughly.

Device Handling

The AirConsole API and Unity Plugin take a lot of complicated stuff off my hands where the handling of controllers and inter-device communication is concerned. There are still various things to be considered. AirConsole assigns a device ID to each connected controller. Assigning a player number or other identifier to said device is the ‘game’s’ job, however. I had at first used device-ids as player numbers which quickly bit me in the backside once devices connected in different orders, or disconnected and reconnected.


For visual design, we also took a couple of drastic steps to improve performance: Early on, my colleague tested various shaders and decided on using an unlit toon shader, which made it possible not to use a single Light in the entire game. The downside of this is that a slight change in camera angle will change the fake shades and highlights on models, which isn’t always fitting. Since we were planning to work with a static camera anyway, it worked for this game however. In the Unity documentation, there are tons of additional optimization tips to be found, of course.

Lessons Learned: Game

We had thought that we had a pretty simple and straightforward concept on our hands with HitParade: You walk in a circle, you hit things when you’re next to them. As it turned out, a lot of people have more problems getting the mechanics of the game than we’d anticipated. Especially people who don’t play a lot of video games need a better explanation than the pictographic tutorial screen we currently have in the game.

Tutorial screen for AirConsole HitParade party game
Tutorial for HitParade
We have also noticed that HitParade gets chosen less often than our other games on AirConsole, which led us to redo our cover art.
HitParade Cover Art

Keeping an eye on our analytics, we quickly noticed that the most popular games in the AirConsole store were the NES emulator and Tic Tac Boom, which functions similarly to Bomberman. To test a new platform, people seem to like playing games they are already familiar with.

For our second game, we have therefore decided to go with more established mechanics that the player doesn’t have to learn from scratch.


We’ve been able to draw some valuable conclusions from HitParade and our audience’s reactions to it, and are of course looking forward to see if and how the game’s reception will change as AirConsole grows. Our team is working on four new games and we already see prototypes by third party developers pop up here and there.

Hit Parade is the first game which I worked on that has actually been released. I’ve worked on countless concepts and ideas and on several prototypes which I gladly show around and let people download, but this is the first time one of “my” games is completely out in public. I consider that a sort of milestone for me personally, if nothing else.

In a way, our firstling has been a bit of a ‘learning by doing’ thing for the new platform - I made a lot of mistakes and learned even more from them. While this process is incredibly interesting and eventually rewarding, I am now looking forward to starting the second project with a somewhat better understanding of what I’m working with - and to finding new mistakes to make and things to learn.

Play HitParade on AirConsole now.
Next PostNewer Post Previous PostOlder Post Home

1 comment:

  1. Hi Alice,
    very nice post thank you. happy to see your game as well.
    I would like to know if you could share a little bit more on the technical aspect of how you built your game (C# script) part of it with unity for buttons. I found out about AirConsole not long ago and been very keen on releasing some titles on there. And for the first one that i am working on, I am having an error once i am trying to have more then two buttons. For example left,right,up & down. only left & right work, and when pressing up & down, I get an error. this would be very nice to know as i would like to contribute and also share for those who might want to know more. I haven't seen much tutorials or documentation on that for Unity.
    Your help would be appreciated