When to start thinking about backend features and database?

backend features and database

It is clear that the social aspect of games has been established as a really important aspect of game development. Improving the game connection, offering balanced play based on the user level, adjusting difficulty based on the analytics of the data in-game.

All these functionalities rely on a secure server setup. When running on your own hardware (e.g. VPS, dedicated) you’ll need to figure out what scalability strategy to follow and take protection measures. Even then, servers will eventually go down.

So when’s the best time to start planning for servers?

Design scalability strategy at the beginning

This way you won’t need to change the server architecture and keep the game offline, or in worse conditions because of it.

It is hard to face it at first. I mean, if you are doing a small game, do you really need all this stuff? Maybe not. But not taking it into account doesn’t come free.

These are some questions you might be asking yourself down the road if you don’t prepare from the start:

  • What happens if my game gets traction?
  • Do I need to test my game live with a huge amount of users?
  • Will the scalability design affect my game design later on?

Sooner or later you’ll reach that point, so why not think big from the start? It’s better (and cheaper) to be safe than sorry.

Handling the data distribution of a game can be tricky. Mainly because this data depends on players which are constantly updating their information when they’re playing. You’ll need a dynamic database that not only lets your game adapt to new data, usually tied to player progress and a logic evolution of the gameplay, but most importantly, it guarantees data will be accessible fast and regardless of the amount of players connected at any moment.

If you design the data server architecture of your game without thinking how you will manage the backend if the game grows or changes afterwards, when you start integrating server side features that consume more bandwidth, the initial design may not cut it. You’ll then need to change it, unless you want to bend backwards to be able to adapt your game to a new structure or any new features you may want to include.

Worse case scenario, the data structure has to change for optimization reasons and you’re left with a database you must migrate in order to work properly for your game. You have to essentially start over again. Architecture design is very important because it can help you develop in a flexible, nimble way, able to adapt to any changes in your demands or serving requirements. Or you could make it all go to waste when you have to introduce important changes to the game.

 

What if you need to make important changes?

What would you rather have?

A server design that allows you to scale if you get a boost of users overnight, able to keep up with the load traffic created by the players. Or having you own servers and when you get popular, having to switch to the cloud to support all the growth? That would not be fun.

Experienced independent developers have learnt not to bother with having their own server architecture to be able to serve game data and offer social elements, now so essential in online games.

It’s the case of BadFly Interactive, the developers of the horror FPS Dead Effect 2. They were able to support hundreds of thousands of players and offer them social login, game saves, custom items, and many more.

See why BadFly added Gamedonia backend features to Dead Effect 2, and how this affected the game’s successful worldwide launch.