Future Proof Games

In early November, I attended and gave a brief talk at DevOpsDays Charlotte 2015, a conference dedicated to exploring ideas around the modern movement of operations informed by and possibly run with development practices.

The typical, most obvious example of devops is the automation of builds and deployments of websites or software. Not moving files to servers via FTP and manually running a stack of database scripts (or worse, editing files on the server itself!), but having a system where you can push a button and roll out a new version… or roll back a broken version.

The philosophy is broader, however. It's taking the same design approach to processes as one would to develop an app/game/website. That design approach includes things like:

• Finding what the repeatable actions are and commonize them within a project and across multiple projects
• Clearly exposing errors in your code and processes
• Iterating and revising your processes
• Exposing the status of your work and the environment it's happening in
• Using and/or building tools that facilitate your processes

To be clear, the "processes" I'm writing about are everything about how you:

• share code among teammates,
• prioritize work and pick which project you're working on,
• break projects into workable chunks,
• estimate work,
• create builds from everyone's work combined,
• provide builds to distribution channels,
• handle “branches” of your code,
• test for regressions,
• measure success in projects, business development, etc.,
• communicate among teammates,
• handle emergencies (e.g., showstopper bugs in live code)

Devops is most often discussed in the context of web development (and was at the conference). That's a subindustry with lots of money, time, and mid-sized groups of people who can put their heads together and innovate. With less desperation to survive than the indie game dev scene, they have more luxury to try stuff that might not work.

As a web developer by day, I want to help bring some of these processes to game development, and the conference gave me a lot of ideas to improve upon what we're already doing. In my talk and in conversations with other people, I really pushed the idea of doing this on a shoestring budget. I bet lots of us indie devs are using shared hosting, for instance, which a web dev company would tend to scoff at. Some of us might not even be using Agile or sprints or kanban for managing our work.

I've written indirectly on some this process refinement already in my post on getting indie dev services to talk to each other. I want to build on this and talk about the system of continuous improvement that we should be striving for.

I don't at all promise I can always propose free options if I discuss tools. Sometimes the free options just aren't the best. But what I will propose will generally be within our budget as a team with one game that didn't sell amazingly (Ossuary) and a game in alpha with nothing to buy in it yet (Exploit: Zero Day).

This is going to be a series, posted every other week (roughly) that covers different areas in devops as applies to game development.

This post will get updated with links as I write them, or you can follow the devops in game dev tag.

1. The Beginning (this post)
2. The Philosophy
3. (Blameless) Retrospectives
4. Project Planning
5. ChatOps for Real