Smashing Virus

Interactive Game

Immersive Motion Gesture Game Development for DDB Remedy & Gilead for Use at the World Renowned American Society of Addiction Medicine (ASAM) Conference in Abu Dhabi.

Summary

DDB Remedy Approached Antiblanks to Pitch as a Development Partner to Deliver a Fruit Ninja Style Smashing Virus Gesture Control Game Which Was to Be Powered by Motion Detection Technology.

The solution would be used at multiple high profile conferences to act as a talking point on a trade stand for a Hepatitis C cure created by a leading pharmaceutical company; the first conference was dated only eight weeks from the point we received the brief. The project deadline was tight, the technical complexity presented challenges and there was little margin for error. DDB Remedy felt confident in our initial scoping and our proposed development timeline and so we were hired to deliver the application.

Backstory

We Were Introduced to DDB Remedy by a Mutual Contact Who Was Working on Various Projects for Gilead at DDB.

After DDB Remedy presented the brief and made clear the requirements they had from a technical partner, we drew their attention to some of our more recent projects to highlight the range of skills we have at Antiblanks and some of the enterprise solutions we had success in delivering for both web and mobile using technologies such as React, Angular, Swift, ElasticSearch and working with Big Data.

We felt we made a good first impression, our skills aligned nicely with the requirements of the project and it was clear that we could deliver. It was three weeks later that we heard from DDB Remedy with an offer to do the work.

Problem

The Challenge Was to Develop a Complex Piece of Software in Just Six Weeks That Would Withstand Continuous Play From Multiple Players Over Long Periods of Time Without Being Disrupted by Background Interference in a Busy Environment Over Four Days.

1. Technology

Selecting the correct technology to use for motion detection. Ensuring that the technology chosen was reliable, wouldn’t create too much of a development overhead and wouldn’t be interfered by bystanders or poor lighting.

2. Quality

Building a product that would comfortably deliver a seamless experience running consecutively for four days given any number of potential players.

3. Playability

Making a game that would be both enjoyable and engaging for a wide group of practitioners from all ages within the healthcare industry; i.e: (without meaning to stereotype) not your typical gaming types.

Solution

Considering Time Was Not on Our Side Selecting the Right Technology Was An Important Decision as There Was No Scope to Build Or Test a Range of Proof of Concepts (POCs) Which Would Have Been Our Preferred Approach. Instead We Had to Get the Technology Right First-Time and Whatever POC Work We Could Do, Would Need to Be Completed Rapidly. Our Team Spent Two Days Researching, Hacking and Testing Potential Solutions. Our Tests Were Carried Out on Three Variants:

Implementing our own browser based custom motion detection powered by OpenCV.

Implementing our own browser based motion detection built on top of an existing third party prototype with RevealJS.

Implementing a hardware based solution using the XBox Kinect sensor.

Implementing our own motion detection would have been lightweight, portable and more accessible. Powering the solution using a typical webcam would have been more cost effective, and the end product could have been played on any device with a camera. From a programmatic point of view we would have more control over a custom implementation and we could have customised the gesture control to suit our needs.

The XBox Kinect powered solution would have been less portable and we weren’t sure whether we could connect the hardware to a browser based application. Having a fixed hardware dependency could have restricted the lifespan of the application and would have brought risk in that the application’s success would have been reliant on a third party device that if found not fit for purpose could not have been tweaked or improved.

After Comparing Our Three Prototypes We Opted to Use the Xbox Kinect Sensor to Power Our Motion Detection. The Decision Was Made for Two Reasons:

1. Time constraints

We were concerned that though we favoured a custom solution in the long term, we didn’t have time to get it right and the POC work we’d completed had proven the detection to be unreliable and would require significant improvements to deliver the quality and playability we needed to deliver.

2. Unity

Our researcher knew from a previous project that Unity had a reliable SDK for working with XBox Kinect. The Kinect sensor was mature and reliable and using Unity made the 3D development more attainable within the given time frame.

Quality

At Antiblanks we pride ourselves on delivering high quality solutions for all of our clients. Our reputation is based greatly on the quality of our work driven by the adoption of enterprise delivery processes to produce well architected and well tested code. Out architectural approach and unit testing strategy on this project were key in producing a bug free application.

Architecture

We combined our extensive and varied experience in web, mobile and Smart TV applications and games development to deliver a modern reliable solution.

Based on the reliability and testability of a single immutable state architecture and the success we’ve had with these patterns in our enterprise fintech projects, we opted to use Redux to structure our application. We couldn’t find anything as mature for Unity as the Redux library we’d used in our web projects, so we improved an open-source framework and ported our mature tried-and-tested reusable in-house ReactJS based web component framework comprising of pages, page frames, dialogs and popups to underpin our application and fast-track development.

Testing

Typically we would recommend nothing less than 75-100% unit test coverage in any complex application but faced with time constraints we had to be more creative with our unit test approach to achieve maximum reliability. Our architecture allowed us to dramatically reduce bugs by limiting our unit tests to cover only anything that directly influenced the data which was put into state for display in the game scene. By doing this we could verify with a high level of confidence that gameplay would work correctly without having to rely on time consuming manual play-testing.

Failsafes

Though our architecture and unit test strategy heavily reduced the chance of bugs occurring in the first place, the reality is that programs can break occasionally and in this scenario our application would need to recover with minimal disruption to the user experience. Despite not finding any bugs during our rounds of quality assurance and user testing, we implemented hotkeys to remedy an imperfect state if required. Given our chosen architecture this was very quick to achieve at little cost to the client and having these failsafes meant that if anything did go wrong with our system, a non-technical stand operator could fix it promptly.

Playability

Making a game playable requires creativity and a deep understanding of the psychology behind what drives user engagement. We broke this into three challenges: Attracting new players, engaging players to complete the whole game, and driving players to return and play again.

Gesture Control Configuration

Nothing attracts more interest than a person waving their arms about and throwing wide shapes around their body. Sensor placement and configuring the correct tracking area with a carefully considered algorithm played a big part in creating this experience - To hit a virus in the top corner of the screen we didn't want the user to move their hand slightly, we wanted the user to have to stretch their arm really high and wide!

Not-so Random Virus Spawning

We invested a large amount of time in testing numerous algorithms to get the right frequency of virus spawning and the travel speed for the viruses in each level. Utilising hotkeys to alter these properties allowed us to tweak both during live gameplay while play-testing to find the sweet spot that would create stickiness. We found fluctuating clusters to be the most addictive, giving the user room to breath in between bouts of high energy swiping.

Short and Varied Levels

We invested a large amount of time into play-testing and tweaking the duration of each level to create maximum playability. We deeply considered the incremental difficulty over the levels and across each level start-to-finish to make the experience gradually more challenging and more addictive.

The Outcome

We Picked the Right Technology, the Right Architecture and the Right Unit Test Strategy to Comfortably Deliver a Highly Reliable and Playable Game Within a Tight Deadline Without Breaking a Sweat.

4 Days of Continuous Use at the Conference

100s of Players and 1000s of Games Played

0 Game Bugs or System Crashes

Increased Footfall to the Trade Stand

Our application ran successfully and received outstanding play statistics from enthusiastic participants over the four days with no bugs and no crashes. Our game has gone on to be used at more pharmaceutical conferences and internal meetings without the need for on-site technical support.

The reusable architecture, reusable utilities and robust custom gesture control framework we put in place that can be adapted to work with various inputs such as VR with Oculus Rift or Samsung Gear has allowed us to develop similar games and experiences in less time and at a lower cost.

+ See More of Our Work

Start a Project?

Working on the UX/design of a mobile app

General Enquiries

e: info@antiblanks.com

New Projects

e: projects@antiblanks.com

Antiblanks Limited

w: https://antiblanks.com