How AWS Game Tech helped three indie devs launch a game-as-a-service

This guest blog is authored by Shaun Randall, Product Lead and Developer, Edenic Era LLC.

Edenic Era LLC started in 2018 with three friends who dreamed of releasing a game together. After playing PUBG upon release, we knew within three days that the genre would become a mainstay in gaming. Even though none of us particularly enjoyed shooters, we still loved playing the game together. Being big fans of League of Legends, we decided to make a battle royale around spells.

The big problem? We had never released a game. Back in 2016, even large companies often were stricken with server issues upon launch, especially games with a lot of players connecting to one server. Even if we could make a fun game, how could we handle ensuring solid stable servers for such a network intensive game? How could three new developers to the scene possibly hope to avoid this fate?

Prototyping the Game

First, we needed to make the game. The first prototype, which had a dedicated server running with a few healthbars and abilities, took roughly eight months. After that, we wanted to get the game in front of friends and family as soon as possible to start getting feedback.

The first playtest was rough to say the least. Running the server on our local machines was unreliable, and we had no way to get the game out to friends and family easily. The playtest for the next week was already scheduled, and we were sweating bullets about how we were going to have the second playtest be less disastrous. That’s where AWS first came through for us.

Using an Amazon Elastic Compute Cloud (Amazon EC2) instance to host the server and Amazon Simple Storage Service (Amazon S3) to host the file we could give people fast downloads and a reliable server to play on during playtests. Due to the low cost of S3 and the free tier of EC2, we paid around $1.50 a month to host playtests for hundreds of players. Great for our shoestring budget. On top of that, it only took us a single day to get it going. The next playtest (and future ones) of the technical alpha went much more smoothly.

Our next big milestone was launching on Steam behind closed beta keys about 16 months into development. We made dozens of new abilities, created a larger map, and acted on all the feedback we had received. Yet we still needed to do a lot around the game, like character skins and earnable currency. While Steam’s services can handle a lot, there are still components you need a secure server to do, such as granting currency and so forth. We looked for solutions again, still wanting to keep our budget low since we were making zero revenue.

The best solution ended up being AWS Lambda and Amazon DynamoDB, as the ability to scale down to 0 when we weren’t running playtests with no extra effort on our side was great. We figured once we went live and had a lot more players, we might need to do some work—but spoiler alert, it scaled seamlessly with our initial settings. Any API we needed to stand up, even if it required persistent storage, was now a breeze. We just had to write the code and hit deploy. Plus, because it could scale to 0, we incurred no additional costs to run a complete staging environment.

Launching the Game

We were now about 21 months into building the game, and close to opening it up to all players. Yet we hadn’t touched matchmaking or server scaling. We estimated that this might take us anywhere from six to 12 months and were dreading it. As a team, we were about to spend an equal amount of time not making the game to ensure a stable and successful launch, and even then, we expected to make mistakes.

We had heard of Amazon GameLift but weren’t sure it could fit our needs. To our delight, after signing up and using the service, we were contacted by the Game Tech team to help us out. They assisted us every step of the way and helped troubleshoot and answer our questions when we ran into problems, even letting us talk to multiple Senior Engineers on the team when things got really detailed.

With their help, we accomplished not only matchmaking and server scaling, but also ported our server from Windows to Linux for better performance and about a 90% reduction in server costs. We were shocked at the attention and care they gave a small studio such as ours. Combined with Multiplayscape’s UE4 plugin, we were able to accomplish all that in just around three months.

Graph of new players by day. Peaks are Early Access and 1.0.0 Launch.

From there, we received the flurry of Early Access on Steam. We improved our matchmaking ruleset with their help, patched dozens of times seamlessly, and had over 50 patches and not a single minute of server downtime. The few times we launched game-impacting bugs, it took only seconds to swap back to the previous version on GameLift. Not once did we have to manually resolve service outages. They helped us handle varying amounts of concurrent users and more than 175,000 players trying the game out for the first time, seamlessly scaling the servers up and down without us needing to touch anything. It was a somewhat surreal experience to watch it just work. By the time we were heading into round two for the launch out of Early Access into v1.0.0, all nerves about scaling were gone.

Patching and Maintaining the Game

The simplicity of patching with zero downtime deploys cannot be overstated. With GameLift you can ssh into servers to directly look at logs with ease. This made resolving players bugs incredibly quick. There were many bugs we had resolved and patched back out in 1-2 hours. The player would inform us of the bug, we’d use a terminal to access the server logs to pinpoint the error message, fix it, and have a server and client packaged and deployed. Any ruleset and scaling changes can happen without a deployment so those could be addressed nearly instantaneously. Even as I was writing this blog, I decided to try increasing the number of game instances per server by four as an experiment, which could lead to additional cost savings.

From a network reliability standpoint, we were golden. Since we were unsure how player numbers would fluctuate, we decided to start in just the US-West Zone, figuring our players would mostly be playing from China and the United States based on wishlist numbers. Our deployment scripts could easily be duplicated for other environments in minutes if needed. Our technical lead had worked miracles and created an experience that felt great with up to 250ms latency. This required the server to be on a very reliable network. Fortunately, Amazon GameLift delivered once again and players around the globe talked about how they felt they had no lag and questioned if we had put the servers in their home country. If you watch our trailer on Steam, you’ll see a clip “TheHakon” playing from Germany with around 200ms (it says 49ms because we didn’t realize yet that UE4 reported only ¼ of the actual ping.) Anyone who has played a competitive action game knows how important latency is, and the results of our partnership floored us.

Outside of that, the rest has been simple. Billing has remained steady and the servers have stayed up and healthy with no manual actions on our part. It just works. Anytime we launch new APIs or servers, Amazon CloudWatch has helped us spot errors we missed early and give us the information we need to zero-in. Anytime we need a new service, AWS has had a solution for the architecture we need. If we were to do this all on our own, we’d likely have to shut the service down as we attempted new projects, but with how easy and inexpensive they make it, we can run Valgrave for years on end.