Social Point Blog

Published: 6 years ago


As the guys at Microsoft once said: the only thing that’s better than writing code, is not having to write code. Right?

If you work in gaming, you’ll know that things change. Fast.

User behavior, expectations, tastes and the technology itself are in an almost constant state of flux and evolution. Keeping up and ahead of the game means finding best practices in efficiency and making full use of your resources to save time and to focus on what’s important. At Social Point one of the ways we do this is by re-purposing existing code. We took a pew with Dragon City lead backend developer, Adán Lobato, to find our why – and how – we do this, to optimize the development process. This is what he said.

Adán, we’ve made a number of hit games for Facebook and now mobile. Fill us in on what the pressures are in keeping one step ahead of the game in backend.

Tastes and preferences change constantly amongst players. The audience is continuously evolving. This means that a game that is super popular one month, might fall out of fashion  the next.

In practical terms it also means that your team has to evolve as quickly as audience tastes. So we have to invest our time in the really important stuff to avoid simply reinventing the wheel over and over again, trying to keep up.

An efficient team has to know where to save time in certain processes in order to devote time to those areas where we can make real progress, fast. Something we do at Social Point is look at how to shave time off coding across our different games, so we can focus on the other stuff.


“Coding is a bit like cooking games – it’s about having the right ingredients to make different batches when you need them.” Adán Lobato.

So you look at creating code that can be leveraged and re-leveraged across the entire portfolio, right?

That’s the idea. Really it’s all about good practices.

Here’s how it works.  We look at the problem we need to solve. And we ask ourselves if it’s a generic problem that might conceivably affect all of our games – not only the specific game we need to “fix” or update in some way. If so, we start to look for a generic solution that can be applied to the whole portfolio, meaning that we will save time if the same need arises elsewhere.

The next step lies in creating a small, decoupled, single-responsibility and well-tested library of code that will satisfy all requirements. And the simpler this is, the more likely it is that we will re-use it. And save time.

Think of it like cooking games – and having all the requisite ingredients, or pieces, to make different batches when you need them. It’s like keeping your kitchen well stocked with the basic, common ingredients you need to make your different recipes.

So in terms of coding, it’s about creating bits of coding that can be re-purposed to use with different games? How do you do this?

Well, we use Composer basically. We split our code into small parts which can either be low-level components, core libraries or game-specific libraries for features. Each package is configured as a Composer package, with its own dependencies.

We host our libraries on Github private repositories and for the packages we have set up our own private version of Packagist. And that’s it!

The only additional thing we need to do is enable our own repository on Composer, the rest is easy as pie.

Why Composer?

Our backend is built on top of Symfony2. Since the launch of the 2.1 version, Symfony has migrated dependency management for its dependencies to Composer. And, for the time being, Composer has become the de-facto tool for dependency management in the PHP world.

Are there other tools apart from Composer? Yes, there are but they’re far from perfect. Composer is the most complete PHP-specific tool that exists nowadays.

Have any challenges shown up when you split what was a simple project into more and more “libraries”?

Initially all our private repositories were pointing directly to Github. It worked perfectly at first but, as the number of repositories and development branches grew, Composer started getting slower and slower, making it really difficult to work with.

We decided to set up our own private repository with satis (a small version of packagist) to try to cache Github metadata and boost composer usage. But satis is not the best solution when you have lots of packages to manage. It takes too long to update its information.

The only solution was to move to Packagist. And that’s where we are now. We have our own Packagist version which manages more than 50 private packages. And it works fine most of the time.


We just had to enable our own repository on Composer, the rest is easy as pie.

We encountered another issue related to not following good practices when we released our own code.

When we only had  Dragon City under development it wasn’t a problem to work directly with the master branch. But as we produce other games, it became difficult to upgrade games  - without breaking them, due to the changes in these other games.

The solution was just around the corner, in the event. What we found we needed to do was to introduce giflow and Semantic Versioning into our development cycle.

With gitflow we feel confident right across the release cycle because it supports features, releases and even hotfixes by default.

Finally, we started tagging our releases the way Semantic Versioning recommends. By doing this we can develop our games in some specific versions of our components, without having to worry about whether a newer version has been released or not.

It is now the game team who decides which dependencies to upgrade and when, in a controlled way.

Both solutions helped us a lot in our daily work and really improved performance across backend.

A personal question for you Adán. It sounds like you get to learn a lot in your role and team. Is this an element of your work that you particularly enjoy?

I love the challenges. We have to deal with a huge amount of concurrent users. So we have to design our software and the architecture behind it, to be ready to support this huge load, possibly more. And for doing this, you have to always keep in mind the worst possible scenario  and be ready to code a solution.

We also have an excellent backend team and I’m continuously learning from my partners. It really motivates you when you get into a room with some colleagues with a problem that, at first sight, seems  really difficult to solve. After brainstorming we come up with an amazing solution: clean, simple and accurate.


The team here at Social Point is growing. If you relish a challenge, you’d like to work in an office with views of the Sagrada Familia, and you share our love of making killer mid-core games for engaged users all over the world, maybe Social Point is the place for you. Why not take a good look at our Jobs page and see if you can find a fit.

Some HTML is OK