Ice Cream Express — creating a HTML5 game for touch screen displays

One emerging form of digital retail marketing that has been found to successfully engage shop visitors like no other are branded games. Creating a game always brings up many challenges, even if it’s based on relatively simple (like in this case) idea. Check out the development process of our brand new HTML5 game we did for a client from digital signage vertical.

Digital Signage using HTML5

The ability to interact with digital displays around us has quickly become part of our lives. You may have heard experts promoting HTML5 as a next-generation technology for interactive digital signage. We believe the solution for brands willing to enhance physical customer experiences lies in open, modern technologies such as aforementioned HTML5. It’s a well know fact that awesome experiences keep customers coming back time and time again. On average, typical engagement times for branded web games range from 3 to 10 minutes which is great result considering shorter engagements for overwhelming ad video content.

HTML5 itself is great for such purposes thanks to its cross-platform support and ease of distribution. Here at Merixstudio we’re focused on building highly functional and engaging HTML5 applications and games for digital signage.

HTML5-based interactive content (including fully playable games) can be directly streamed on PC, phone, tablet and any other devices including digital touch displays. The development of the game itself does not differ much from a way we create typical mobile or web games. Below, we’d like to reveal more details on the game design workflow and processes.

Key stages of HTML5 game design process

One of the most important stages of the project (if not the most important) is planning the course of the game. During that stage of development the relations between individual game elements and objects are very strong and even further smallest change can have an impact on the entire project. It’s different with websites, where adding images, new contents or even whole inner pages shouldn’t normally disrupt given structures.

The purpose of the game is to compose an ice cream that matches the picture presenting final result (ready ice cream composition). You touch screen to arrange objects in right order. It’s important to do that within limited time and satisfy queuing impatient customers. A big advantage of working on Ice Cream Express was that our Client empowered us with creative freedom in building and modifying the concept of the game. After developing core algorithm responsible for fundamental game logic (ice cream elements matching mechanism), thanks to which we could predict application performance and avoid unexpected situations that might extend the development time, we started full steam ahead.

During preparation we considered various frameworks and approaches to the project in general. Eventually we decided to build a game with HTML5 elements and to program in pure JavaScript. Due to the limited target device performance, we preferred to use as little JavaScript as possible. As a result we avoided the excessive use of device resources. Game runs in the Chromium browser, and to be more specific NW.js, which combines Webkit and the Node.js. Unfortunately, all the Client’s devices support only the older versions of the Webkit and upgrade wasn’t possible in this case. On the other hand, when it comes to the quality, the version of Webkit from 2 years ago does not differ much from its latest version. And it is not even half as scary as Internet Explorer ;)

The basics: starting off with game prototype

At first we sat down to create a prototype, which would include the required core game mechanism of the game.

Application is divided into several key parts:

• shuffle — responsible for shuffling new combinations of ice creams,
• comparison- chooses and compares ice cream compositions,
• view — all styles and animations.

To create shuffle and comparison mechanisms we had to firstly predefine ice cream compositions, thanks to which we could identify components. We came up with the idea that every game level would work as a separate table which will be added to the object representing the current composition.

The shuffle part also created the same object, but in this case the number of elements was determined by the difficulty level of the game.

In the configuration file we defined the range of numbers that the compositions should be drawn from, thanks to what lower levels of the game are less complicated than the higher ones. We just had to make sure that the drawn buttons and their numbers correspond with the current level of difficulty.

If the drawn combination (value and order of elements) matched the one arranged by the player, the game accepted the composition. There are few exceptions to that rule that needed to be noted, such as ignoring the order of toppings — those can be chosen regardless the color combinations of scoops.

Early prototype was initially limited to a bare minimum due to the fact that our Client was still working on the final artwork of the game. Because of that we replaced images with the mentioned above values.

We also created a small panel to be able to control entire game and quickly change the current level that unveils another flavors, toppings and the buttons to shuffle a new composition. Upon receiving the final artwork, we easily replaced buttons with graphics. Additionally, the history mechanism, which allows to undo each action, ultimately was changed to a reset button.

At the last stage of the project was the addition of animation. Avoiding unit calculations of JavaScript, which might slow down the game, we used CSS animations. For additional smoothing effects and animation of characters we used GSAP library (GreenSockAnimationPlatform), which is used in the most advanced projects of this type. It allows us to create fully controlled and dynamic animations with high performance and compatibility with even older browsers.

After the final adjustments came the phase of internal testing. In this part was involved not only our QA department, but also other employees of Merixstudio — no one wanted to miss an opportunity to play games during working hours ;-)!