iDream Interactive Scaling with Nakama

Scaling is hard. At least, it is if you make it your problem. Find the right back-end, though, and you can focus on building gameplay and let someone else worry about serving your growing playerbase.

That’s what iDream Interactive did. I chatted to their Technical Director, Dave Wiper, to learn more about their journey and to understand how they came to select Nakama as their preferred backend.

It started with (a) Flash

Today, iDream Interactive focuses on mobile games but they started in 2006 as a small team building educational Flash games. Over the past thirteen years their journey has seen them adopt new technologies, deliver their games through new channels, and serve an ever-growing audience of players.

On the back-end of those mid-2000s Flash games were PHP and MySQL, which served them well until they shifted strategy and began making games for Facebook. According to Dave, that was where they faced their first scaling challenges:

“Our second Facebook game was a slot based adventure game called Slot Universe. It did really well. But scaling was always an issue. So we jumped into things like horizontally scaling with read replicas and Memcached as a caching layer.“

“Eventually, we heavily leaned on Redis as our core data store. That resolved a lot of the scaling issues but there were still devops challenges. So, every time something would go down or something would break it was awful.”

Finding innovative answers to their scaling issues were core to the approach that Dave and his team took. To simplify their stack, they stripped out anything that was unnecessary. That included moving from an off-the-shelf Flash-PHP communication layer, called Zend AMF, to directly calling their own custom API endpoints from the Flash games.

Parse from Flash

By 2014, Flash’s days as a mainstream platform were numbered and iDream Interactive began to reconsider their entire development stack. That’s when they came across Parse.

“We were working on a new match-3 game called Recipe Rescue. I was researching tech we could use and came across Parse.“

“I really liked the concept of just being able to flip a few sliders and not having to worry about dev ops. If I needed to scale, I just moved a slider.” However, external events meant that Parse wasn’t a long-term option for iDream Interactive.“

“We started using Parse and shortly thereafter it got acquired by Facebook. For a couple of years, Parse was pretty successful for us but in our second year of working with it Facebook announced that they were gonna be shutting it down. Thankfully, it was a very light integration; we were saving data, reading data, and we were using it as a login authentication system.”

With the open sourcing of Parse it seemed the future was more certain but it brought back the dev ops challenge, one that Dave looked to solve by deploying on AWS’s Elastic Beanstalk.

“We had all sorts of issues with Elastic Beanstalk. It would scale up automatically but then sometimes it just wouldn’t. And response times were awful.“

“So, then we moved to Heroku and mLab as the back-end for MongoDB. Both worked fine, but the open source Parse was not the fastest thing in the world, either. And the whole set-up was expensive. Considering what we were using it for, it was more expensive per request than it should have been.”

Managing costs

Over time, Dave and his team experimented with other back-end options.

“PlayFab was pretty good. I like its simplicity but it became expensive very quickly. We realised it wasn’t for us on one particular project. We were producing a slots game for a vendor and when we scoped out how much we’d use the back-end, it turned out that our bill from PlayFab would’ve been more than the total the vendor was paying us for the entire project.”

So, the search for a solution was on again. iDream Interactive needed a back-end that was easy to develop against, flexible, scalable, and affordable. Would it be possible to get the dev ops simplicity of a managed back-end with the affordability and flexibility of an open source solution?

That’s where Nakama came in

Dave came across Nakama and made some calculations. He realised that by switching their Recipe Rescue game from Heroku and mLab to Nakama they could cut their costs by 75%.

“We found that two small Nakama servers behind a load balancer in Digital Ocean, working with their managed PostgreSQL service, was ideal for us.”

And while iDream Interactive are self-hosting the open source version of Nakama today, they could easily transition to Heroic Labs’ Heroic Cloud or enterprise managed service with no change to their game code.

iDream Interactive’s story mirrors that of many games developers and publishers. The search for a low-touch, affordable, and scalable back-end has previously seemed like an impossible quest. With Nakama, though, developers large and small can focus on creating gameplay experiences and know that their back-end will see them right through the lifecycle of their titles.