Start-up guide to social games development

Fat client social game development seems to have bought the industry full circle. With the low barriers to entry it is again entirely reasonable for a single coder to develop a game in their bedroom with no commercial development tools.

Perhaps the only bar to entry is the high expectations of games savvy customers, and with new audiences brought to the games table by social media, even that obstacle is less significant.

So what kind of challenges does the coder face in this new era of games development and how do the tools measure up to the task?

Bringing your product to market

It might feel like putting the cart before the horse, but deciding on how you are going to make your money will strongly influence your choice of solutions.

Say you want to go for free-to-play with micro-transactions then you will either need to select a platform that supports this model – Kongregate, Facebook, Chrome etcetera – or you are going to have to provide some of that infrastructure yourself.

You are always going to have to serve your web app from somewhere, so in many ways you are missing a trick if you do not offer services over and above the minimum that a social network provides. For instance, Facebook only supports a single high score, whereas many games want to record much more than that.

Facebook also pushes some of the invitation management responsibilities onto your server. You need to accept that some server side development is going to be needed. So Ruby, Python, PHP, JavaScript: Pick one and expect to be surprised at how large your code base will grow – good coding practice will pay dividends here.

If you accept that you are going to be running a server, then what flavour? In general think about what happens at scale. Apache is a natural choice, and scales well with a traffic manager.

Node.js has the advantage of a single language on client and server that might be appealing to small development teams that want to concentrate expertise but is not widely proven at scale.

If you are consuming cycles on a server then you are presumably going to want to record state and that means some means of data storage. If you are going for high volume (micro transactions), then again consider what happens at scale.

MySQL is a natural fit and comes as part of the LAMP architecture but your data sets can rapidly outstrip the single terabyte range, so be sure that you are comfortable managing tables that spread across clusters of machines.

Cassandra and other schema-less variants are in the ascendancy and are again free to use but keep in mind that this is new technology and is still evolving. One attraction is that there are several commercial players in this space now (DataStax, Acunu) giving you an escape plan if managing your data corpus becomes a time sink.

A second attraction is that the schema-less nature is very developer friendly, though keep in mind that this could be read as "easy to misuse".

On the client side, things are not as resolved as you might think, JavaScript and HTML offer a fairly standard development environment, but the attraction of HTML5 complicates things somewhat, especially if you are working in some of the fringe elements such as video or canvas.

Whilst the attraction of the canvas to game developers is strong, there is a lot that can be achieved with DOM elements under HTML4 and you will find that drawing to the canvas without the benefits of WebGl extensions can be frustratingly slow.

Of course, if you are going for WebGl then you are closing off a set of distribution platforms, and if you are going to do that then think again about taking the JavaScript route at all. Why not go Flash, Unity or even Android?

Sticking to the bedroom development theme, and selecting a free to market platform, your IDE is the next choice. There is no shortage of options here. I prefer Eclipse, but others in the studio go for NetBeans, there are many alternatives.

What is clear though is that debugging will happen in your browser. Chrome, Firefox (with FireBug) and Internet Explorer all have excellent debugging and profiling facilities built in.

There are constant advancements. I suspect that the browser manufacturers (at least the commercial ones) recognise that if they can lure the developers to work with their client, then it is their client that will be best supported.

One of the developments in HTML5 that is not widely discussed is its access to local file storage. What this opens up is the possibility of storing state on a local machine – it is entirely possible to create an application within JavaScript and with no server support.

Whether this is route offers any commercial viability is doubtful but it does offer an excellent tools development language. It also offers a very simple starting point to try out JavaScript development with nothing more than a web browser and an IDE.

—

If you would like to learn more about the tools and tech on offer for social games developers, you can read our in-depth feature on the subject here.