(This is part 2 of a series on applying devops principles and practices to game development. The main post is here and all posts can be found under this tag.)
If nothing else about this series proves directly useful to you, take this one thing home:
Don't get stuck in a local maximum.
—Michael DeHaan, creator of Ansible
Keep moving and keep improving.
Very often, we find a system for ourselves that works and stick with it. We just get used to things that are initially annoying or rough, even if we know there might be a “fix” for it. As a result, we accept failure in some areas, telling ourselves “that's just how it is.”
We shouldn't just accept those irritants and move on. We should continuously reassess whether those need to continue to be rough spots.
Here's an example: let's say we deploy an update to Exploit: Zero Day every week. We have the deployment process automated through a tool that also does our test builds. Essentially, we tag and push to a particular git branch, and the site deploys.
But a few times a month, the deployment fails because the build server runs out of memory. It's not that a big deal to log onto the server and restart the tool and/or the server, but:
- There are other things running on the server that are important,
- It interrupts the deployment, and
- It can delay the process of building/deploying a site or game by 5-20 minutes.
Finding a solution, though, will cost time and possibly some money, and you don't have much of either.
It's fine, of course, to reboot that box once a week—or better yet, write a cron job to do it—but don't forget that you still have a problem on that server.
Whenever something about your workflow is annoying or slows you down, write it down. Have your team keep a shared list. Revisit it when you do your retrospectives and ask yourself and your team, "Is there anything we can do about this now? How much time and morale will we save if we put some time/money into this now?"
The answer this week (and the next) might be that there's nothing to be done or that it's not worth it. But two months down the line, there might be a new version of the build software with better memory management. Or in six months, you might have steadily increased your income and can afford to beef up that server a little.
In much the same way artists tend to develop an "eye" that shifts how they view the world, practicing this process of refinement can become intrinsic to how you work. Your situational awareness of your work processes and work environment will improve and you'll get more adroit at recognizing problems and being creative in finding solutions.
This won't happen, though, if you just accept all those annoyances. They stack up. They cost time and money. They make your job less pleasant. They lead to stress and burnout.
So in summary:
- Keep a team list of process/environment annoyances
- Periodically check for solutions
- Revisit that list in retrospectives and decide if it's worth fixing now
If you aren't meeting to talk about process problems and solutions, stay tuned for the next post in the series, which will cover retrospectives.
Our Games
Exploit: Zero Day is our browser-based puzzle game about hacktivism. It's in closed alpha for the moment, but you can get access by joining the mailing list. You'll receive an access code in the next monthly newsletter. YouTubers, streamers, and press, request a copy from distribute().
Our first release, Ossuary is available on Steam, itch.io, Humble, and IndieGameStand. Press-like people, you can also request a copy of Ossuary from distribute().
View on YouTube
