Minecraft sky — realtimerendering.com

New order of Cloud Game Dev

Game development is becoming increasingly integrated with online services and real-time communication. Traditional game developers may need to step into the mindset of web developers to make sure their games survive in this new ecosystem.

Note: Audio narration available on Soundcloud

Historically game developers didn’t have to worry about the “real” world. Instead a video game was a contained environment and the focus was to try to make it as interactive and believable as possible. Fast forward to today and many games seem to be using the Internet in various ways. To change the state of these virtual worlds from contained to dynamic there needs to be a re-calibration in some of the basic development practices that have been established in previous decades. Web developers can assist in this area with their experience, as they have spent a lot of time and effort as a community to make their tools automated, network-based and dynamic. Among other benefits that’s what allows them to be so efficient, and a web app made by a handful of people can target a mainstream audience.

So what can game developers learn from web developers?


Responsive design

This has almost become a catchphrase but it is trying to describe a real practice as it’s very common in web development to deal with a plethora of screen resolutions and there is the expectation that an application will work everywhere — with graceful fallbacks in some cases. This is in contrast to the default practice of changing the display to a fixed resolution and enforcing the presentation in a definite way, without considering the variables of each device.

Although game developers are really good at simulating contained worlds, and physics, animation, textures, meshes… everything is very precisely calculated and presented, the reasoning that a fixed resolution will ensure that the game “plays” properly in those devices may need to be revisited.


Components

Excerpt From “Secrets of the JavaScript Ninja” by John Resig:

JavaScript developers commonly rely on collections of reusable JavaScript code—written by themselves or by someone else at their company. Alternatively, they rely on code from a third party.

As most projects have common requirements, creating reusable components makes absolute sense. Yet in game development there’s the mentality of a framework that “does it all” rather than a set of dependencies that are independent from each other. Module distribution speeds up development and as a real world example, the success of Node.js has made older languages like PHP move to the same model.

Abstraction to create reusable components is an art of its own and can change an existing codebase significantly. There’s also additional tooling required, like a dependency loader that will monitor versioning and updates. But the effort for de-coupling the components from the core app is absolutely worth it as in the long run this practice guarantees fast paced prototyping and shorter rounds of development and maintenance.


Open source

The main argument for open source has forever been that if more eyes see the code there’s a better chance of producing a robust product. And even if this has been proven time and time again, especially for server technologies, it still hasn’t been broadly accepted as a good business practice. Openness is good, yet till this day people still confuse the terms open source and free — when there is absolutely no restriction making commercial products with open source software.

Although there is some open source available for video games it’s nowhere near how web developers treat open source, united as a community. The difference is even more obvious with larger companies, as open source is respected by web platforms like Facebook and Google Play, whereas gaming platforms like Xbox and Playstation are heavily enforcing a proprietary mentality in development.

Making development toolkits open source and available to everyone will ensure the improvement of the technologies in an organic way, lowering development costs of each individual studio and improving the tools for the whole industry. By switching the focus of the business from the tooling to the content the end-users may enjoy better product, produced at a faster pace.


Collaborative Coding

The practice of code sharing in game development is rarely exercised and when it is it’s not done in an elegant way. It’s very common to see devs posting huge chunks of code in forums trying to solve their problems. Needless to say that’s inefficient and not re-traceable. Web programmers have tools like gist, jsfiddle, codepen to easily share code — and that’s only scratching the surface.

Practically, these days it’s expected that everything is a (git) repo. That simple fact enforces better coding practices, preserves a history log and encourages a constant commit stream that builds up the communication during development and a more solid ground for product development. Better code sharing speeds up the coding processes and ultimately shortens the development cycles.


Build to scale

Using the Web as a platform comes with the unprecedented opportunity to target a massive audience with virtually no extra development cost. Although distribution is only part of the “scaling”.

Most web services that scale allow user content creation, which is critical for returned visits and viral marketing. There’s still a lot to do in integrating the aforementioned snapshots of contained virtual worlds with real world activities. Dynamic content is key to a vivid virtual experience.

By targeting the mass and expecting a shift in the user behaviour when consuming the content, in a more gradual and ongoing pace, there needs to be a change in the pricing model of the content as well. It is a known “secret” in web development that growing an established user base supersedes any short-term revenue goal — it’s better to ask $1 from 100 people than $100 from 1 person.


Elastic Web Infrastructure

Following the previous mindset, setting the goal of addressing a broad audience brings in requirements of availability and network response. A content delivery network (CDN) for asset distribution becomes essential and a server armada with load balancing for processing the user requests is definitely beneficial. These are just two of many server-side architectures available for expanding networks, and are disciplines of their own deserving more in depth analysis — possibly the subject of another article.

This is probably the weakest point in today’s game development stack. To this day many games have only basic web presences. Un-intuitive UIs, disregard to any web standards and no foresight for dynamic content distribution is (unfortunately) the norm. Discussion about the need of CDNs and load balancing is almost humorous in an industry that will still release game sites that use iframes (or even frames!) in their markup.


Continuous delivery

Also known as continuous deployment or continuous integration, this practice alone may redefine the concept of what we call a video game:

Excerpt of “Continuous delivery” from Wikipedia:

Techniques such as automated testing, continuous integration and continuous deployment allow software to be developed to a high standard and easily packaged and deployed to test environments, resulting in the ability to rapidly, reliably and repeatedly push out enhancements and bug fixes to customers at low risk and with minimal manual overhead.

When a video game’s attached to physical media there’s no way to have continuous deployments. So creating sequels makes sense and it’s a tradition that derived mostly from movies. In online software you’ll rarely come across sequels — no one is waiting for Gmail 2. Instead the expectation is that the online app will continuously be improved and all users will have the latest version deployed. Even browser vendors have started applying this practice.

Development under these conditions is an ongoing process and the right approach is to cultivate a culture of ongoing commits using semantic versioning. Ultimately the users may enjoy a longer relationship with a game by constantly being entertained with a number of new features, progressively added to the product.


This was simply an outline of development practices web developers are mostly familiar with and game developers may need to touch base with to make sure their creations survive this technological wave. These practices can radically change the end product, the distribution models and the revenue streams.

Compiling a toolkit of web technologies to create video games that are intertwined with online services in order to achieve more vibrant, real-time experiences is a safe bet and if we start treating game development more like web development everything else will fall into place.

Cloud computing is not just a buzzword and online distribution is clearly the successor of digital distribution. Setting up CDNs, coding in a modular fashion and endorsing the open source philosophy are just a few of the things game developers can start doing today to be ready.

And always remember: Commit, Commit, Commit :)

References

Article originally published in the August issue of Software Developer’s Journal