Game Development Reference
Interview with Exploding Barrel: Give Them
What They Want—cont'd
SB: It's comparative, not competitive. It is how people play social games,
rather than the hardcore “I wanna shoot my friends in the face” mental-
ity of a lot of 18-year-olds playing Xbox; people want to compete, but it
is generally less malicious. I'm sure if games had a feature where I could
come in and wipe out your farm with a nuke, then a lot of people would
say, “That's it. I'm never playing this game again.” People don't want
that. They want to look good and be able to show off their progress to
their friends, rather than compete directly.
Q: Tell us about the technology you guys have built to create social games.
JH: Probably the biggest thing is that we've built ourselves new technology
that scales a lot better than a lot of the old technology. A lot of the older
social media developers are stuck on an old LAMP system, which basically
means they are using PHP and SQL to drive their stack. The problem with
these technologies is that they aren't really built out of the box to scale up
really fast. There's a lot of work you need to do to handle the scaling prob-
lems. There have been a lot of new technologies in the past year that have
made this a lot more possible, and that's what we're built on. This is our
backend I'm talking about here.
SB: This is why we decided to build our own backend. We were using a
third party before to do all our hosting. We've just found that for a bunch
of reasons, we were better off to spend the money and build our own.
JH: There are two big reasons: scalability and cost. And these are pretty
big factors. The cost is important, especially with free-to-play games,
because every additional dollar I'm spending to host the game is counting
against my revenue. It needs to be as cheap to run as possible.
Second, we're a small company, so we can't afford huge capital
costs to buy huge servers and data centers. We have to build things for
the cloud. Scalability is huge. If you look, you'll see some social games
that go down for a day or more undergoing maintenance, because they
weren't ready for their demand and because they hadn't planned for
scalability at the social level. These games can go zero to hero in just a
few days, so you need to be ready for that kind of scale. If you haven't
planned for that, you can have a lot of problems.
So first, we're built on the cloud, for the cloud. We use a solution that
abstracts the cloud for us and handles a lot of the scaling. It will figure out
what the load is over time, and start up new servers as needed. This is nice