Developing a future-ready game experience
Coming up on its third anniversary, HAMA Universe was designed with our “Games as a Service” initiative in mind. Games are no longer simply released and forgotten, they live and evolve with support and commitment, making sure that user interest and market value are retained.
We’re proud to announce the 7th update of HAMA Universe, presenting a new Traffic Island, and invite you to join us for a technical dive into the challenges we met on our journey, and the foundation that secured the game’s longevity.
Tasked with bringing HAMA beads to digital life on mobile devices, it immediately occurred to us that we would have to dig deep to achieve the required performance. Not only would we have to draw a lot of beads on screen at interactive frame rates to ensure a good experience, the design also called for the beads to be presented in 3D and viewed from multiple angles. In addition, we knew that children usually play on old devices, handed down from their parents.
"We would have to support hardware that’s several generations behind what’s sold in stores today."Peter Asmussen Hou, Programmer
With all of that in mind, we looked at what would technically be a “worst case scenario”. The largest pegboard available was able to hold 841 beads, with each 3D bead consisting of 98 vertices (points). In addition, the pegs on the board were 3D as well, each peg consisting of an additional 50 points. So, we were looking at drawing 1600+ objects totalling 100.000+ points. To add to this challenge, we needed to display a melted version of the beads after ironing, which had even more detail – but the real challenge would turn out to be the 1600+ individual objects.
One bead to rule them all
In 3D graphics, it’s faster to render 10 objects with 1000 points than 1000 objects with 10 points. The reason for this is that each object issues a resource-intensive drawcall to the graphics processor. We needed to limit the number of drawcalls to keep performance up.
One way of doing that would be to merge all static geometry and we decided to take this approach with the pegs since they would never move once they’d been instantiated on the board. However, merging presented another challenge as the design called for pegs with different colours, guiding the user by displaying the pattern they would be creating.
To get the best results, we decided to use vertex colours, a technique where colours are embedded in the geometry of each peg, and then apply a single material with a shader to display these colours. With just a single material present, we could merge all pegs into a single mesh, eliminating the need for several expensive drawcalls.
To optimise the beads, we ended up using a similar approach, although we couldn’t simply merge every bead as they would have to move individually. We relied on instances of a single bead using vertex colours and batching to minimise drawcalls.
Good things come in small packages
Having optimised realtime performance, we were now tasked with storing all this data as efficiently as possible to keep both the size of the app as well as loading time to a minimum.
We looked at different approaches, experimenting with mesh serialisation and compression yielding both benefits and drawbacks according to our test results. In the end, we decided to simply store the position and colours of each bead, instead of storing the actual mesh data. Upon loading the data, we would then use instances of the bead mesh combined with the positions and colour from the data file to restore the geometry. This meant that we could make the files incredibly small and since there was no need to make them in a human-readable format, we used binary serialisation to achieve file sizes of just a few KB.
Keeping it real
With an efficient system in place, we needed content. And not just any content, we wanted to get the client involved to ensure accuracy.
At Funday Factory, we build a lot of tools for internal use to make sure that our game designers and artists are able to be as hands on with the end product as possible. The last thing we want to do is make our programmers a bottleneck in production. In this case, we wanted to do something similar by allowing Malte Haaning Plastic A/S (producer of the Hama bead) to create the patterns, but we had to be careful not to over-engineer the solution.
We could have made a detailed editor tool in Unity, but that would have required Malte Haaning Plastic A/S to use Unity. We could also have made an external tool or program for them to use, but that would require maintenance to keep it up to date with any changes made to the game.
Instead, we decided to simply use the game as a tool. Since the game is all about playing with digital beads, why not use it to create the patterns? It made perfect sense, and all we had to do was add a component that allowed Malte Haaning Plastic A/S to share the data with us by simply pressing a button. The component would then gather the necessary data and send it to us via e-mail.
We took a similar approach to accuracy regarding the pegboards. Instead of having to recreate them from scratch, we wrote a simple parser which we used to generate the pegboards based on actual CAD data that Malte Haaning Plastic A/S was able to share with us. This ensured that every peg ended up in the right position.
The road ahead
Three years and seven updates later, what largely kept this project together was the focus on a simple structure. Basic rules, such as making sure that 2D graphics for each island were atlassed in a single 2K texture, kept memory consumption in check and helped guarantee a smooth update pipeline with almost no unpleasant surprises. However, the world doesn’t stop moving and even a well structured game has to react to changes.
Did we anticipate the technical advances Unity has made in recent years? No, the game could benefit from several of the new features introduced to improve both size and performance. Did we anticipate the latest trend of adding a notch in the screen? No, of course not. We had to react by adjusting our UI just like everyone else. Did we anticipate all feature requests our designers and the client would throw at the game? No, we had to adapt and update part of the data structure along the way.
And that’s what’s so great about games as a service. Modern games live and are able to evolve as the world changes. They are able to adapt and improve along the way.
A new island to the world of beads
Whether you are into high speed vehicles or skating on the pavement, Hama Universe’s Traffic Island has it all.
About Hama Universe's Traffic Island
For the seventh time since the launch of Hama Universe in November 2015 we are updating the digital play experience with beads. The update comes in the shape of a new island - a traffic island - which will make you turn on your creativity and design exciting stories.
Join the helicopter for a ride, help out the police and fire brigade or bring together a group of friends on bikes, roller skates, scooters and skateboards. You can play out your own traffic jam, be the superhero who saves the princess from a dino on the loose or make colourful cabriolets as presents for your loved ones.
Each of the nineteen patterns comes in three different variations. Once all three patterns have been designed with beads, the pegboard will appear in white, thereby leaving it up to you and your creativity to decide on colours, design and expression.