At King, we work together to make great games. To make this possible, we need to involve a lot of people, and when many people need to work together towards a common goal, communication is key. Communication is a hard problem to solve. If I need to contact some other people for some task, I could:
- Email them.
- Initiate a chat dialogue using Hipchat.
- Call them.
- Go to their desks and poke them.
Having long email dialogues takes a long time. Busy people that are using email to discuss something complex can take weeks, maybe even months of calendar time.
Chat conversations using Hipchat or similar is a lot faster but typing is always slower than talking. So you might get something else in focus while the other is typing.
Calling is a more efficient medium for communication. When you want to talk to someone, you don’t always have the phone number, and even if you did, it would feel weird to call someone in the same office, possibly just meters away. Besides, calling everyone for everything is not really part of the working culture at King, at least not in my world.
Talking to each other live is how humans are designed to communicate and that’s what evolution has optimised us for. When talking face to face, we even get to do faces and gestures for higher bandwidth in order to communicate feelings and attitudes.
The only problem with this is… where can I find the people I need to talk to in the office? There are many people around the office and they all have different seats, and many of them also seem to be roaming the office while working. People just don’t always sit still at their desk – they go to the ping pong table, they sit in the library and read books, they walk around and talk to other people, or they might even be lying in the giant hammock:
This makes it harder to find them when they’re needed.
But at King we’re trying out a solution.
The following video showcases the Kingster app, developed by the R&D team, that allows you to find and track other people around the office. The app displays the whereabouts of your colleagues who have also downloaded the app.
By the way, the R&D Chronicles is a series of internal videos the R&D Team at King makes to promote new things that’s been going on in the team. There’s no art or video team involved and the video is edited and recorded by just the programmers of the R&D Team. Hence the programmer art. This video was initially made to try to convince our colleagues to use the app.
The Tech Stack
So, how did we build this app? We’ve placed iBeacons around the office, built an app for Android and iOS that runs on our own game engine Defold, extended that game engine with more functionality so that the app can sense the nearby iBeacons and report back to a server, which then shows the map of everyone on big screens around the office.
iBeacons – Estimate beacons have been placed in the ceiling. The Bluetooth beacons have a unique ID that is broadcast every second. It takes just a few milliseconds, and the beacons have a battery life of approximately two years (in theory).
Backend – To keep things simple, we created a Jetty-based web application, with a servlet for each main function, and MongoDB as database. All communication is HTTP-based and JSON is used on every level of the stack. This is a nice way to get results fast. The application keeps an in-memory list of all avatars seen on the map, with their current location.
All map navigation uses pathfinding. The 1920x1080px map is divided up into a 160×90-tile grid where each tile has a cost associated with it. It can be either walkable (cheap), walkable (expensive), or non-walkable (wall). The expensive tiles are used for areas where we want to avoid walking through if there is a preferred route around it, for example, no walking through the library. For the actual pathfinding, we use PathFinding.js, which implements several pathing algorithms. After we performance tested all of them for our specific use case, we chose the bidirectional A* algorithm (with additional path smoothing on the output). Since there may be many paths to calculate, one for each tracked person, we wanted to amp up the performance. This was done using web workers, when available, to do the heavy lifting in calculating the paths.
Mobile application – We’ve made apps for both Android and iOS. All graphics and animations are powered by the Defold game engine. The app scans for beacons and compiles a list of the approximate distance to each of them. The list of beacons is sent to the backend, which then determines the approximate phone position based on these distances, together with the known locations of the beacons.
Android – Besides the Estimote SDK, only stuff in Android SDK API is used. The API level is set to 18 to support all required features.
iOS – We’ve used a number of additional iOS Frameworks. CoreMotion for motion detection to avoid scanning when the phone is not moving. Photos for selecting photos on the phone. AVFoundation for previewing and taking photos from the phone camera. UIKit for the embedded browser. Estimote SDK on top of CoreLocation and CoreBluetooth for bluetooth management.
Defold – Besides using standard features of Defold, we’ve also extended it with more features that we needed for this app.
Bluetooth extension – This extension lets the app scan and detect iBeacons around the phone. Powered by Estimote SDK, it lets us scan for beacons and determine the distance to the beacons in order to trilaterate a more precise position. Most often though, only one or two beacons are detected, so doing proper trilateration is not possible and we’re falling back to simpler calculations. Even if three beacons are found, they may not always form a useable triangle.
Motion detection – We use the accelerometer to determine if the phone, and hence the phone’s owner, is moving or not. If it is, we scan every 7 seconds and if not, we scan once every minute. This is an optimisation to reduce battery consumption.
Device camera – We extended Defold to be able to handle camera and permissions. It can be used to take a picture for your avatar.
Image handling – We also built an extension to give it the ability to select images from the phones’ Photo Library/Photo Gallery.
On Android, it was straight forward to run the Bluetooth scanning and reporting in the background as a service. The service is passive when not within office WiFi reach.
On iOS though,
Despite being a perfect fit for the requirement of background applications at the first glance of it, we still needed to use a number of hacks in order for the app to stay alive and scan in the background. The hack requires:
- When executing the background, always keep a background task running. Change this task every minute, so that the two tasks overlap.
- Start CoreLocation every minute despite the fact that it’s already running.
- Request permission to use iOS location services, every minute, despite that the documentation says that it’s only needed once.
Without this behaviour, iOS would quickly suspend the app, denying it any execution time until the user foregrounded the app again, and we wouldn’t be able to scan for beacons.
Doing this hack, however, causes iOS to drain a lot of battery. It’s not acceptable that the app consumes a lot of battery when the phone is not in the office.
To avoid being a stalker app, we’ve taken great consideration to make this application as non-invasive as we could. First of all, it’s optional to install the app, and if you do, it’s optional to have a name and picture. Also, we do not persist anyone’s location, it is only kept in-memory on the server and the web client. We also do not keep track of any location history, just the current approximate location. Whenever the app is closed or you leave the office, the data is deleted from the in-memory list when the avatar disappears from the map. We also made sure not to place any beacons close to the restroom areas.
We do keep track of the app total usage time (the total number of minutes an avatar has been visible on the map). This data is used for the top list.
Despite being a cool tech, this is not a very popular app used at King. We believe that it may be the case that the app consumes more battery on iOS than we’d want it to do, or maybe people actually don’t need this functionality. When it was launched, we had 25-30 simultaneous users, ~50 daily active users out of approximately 400 people at the office. But it didn’t reach critical mass, so it hasn’t gained enough gravity to self-maintain a stable user base.