This is the fourth part in a series on applying devops principles and practices to game development. The first post in the series is here, and the entire series can be found under the devops in game dev tag.

In our post on retrospectives, we wrote about taking note of lessons learned (good and bad) after emergencies or breakpoints in your project—after you deliver a feature, or at the end of a sprint or some unit of time. But how do you know what a good breakpoint is? How do you actually incorporate what you've learned in a retrospective into your future work?

Through effective project planning.

We've updated Exploit: Zero Day as part of our Alpha Two phase of development.

Changes:

• Reworked the experience of sharing clusters and systems to be clearer in intent and more compliant with mobile accessibility guidelines.
• We added tracking of invalid address submissions on the store form.

If you're seeing this ...

Ossuary is part of the Steam Summer Sale and will be 25% off until July 4! If you haven't had a chance to play yet, it's only $7.50 (USD). If you've played and liked it, we'd be thrilled if you wrote a review on Steam to let us know.

What ...

We've updated Exploit: Zero Day as part of our Alpha Two phase of development. A lot of these are improvements we devised from watching people play EZD at the East Coast Game Conference a couple of weeks ago.

Changes:

• Login links will redirect back to the page the player was ...

We've updated Exploit: Zero Day as part of our Alpha Two phase of development.

Changes:

• Link to friends' account pages from friends list
• Major SEO improvements — proper page titles and descriptions, some microdata
• Show a message for when there are no jobs in the job list

If you're seeing ...

We've updated Exploit: Zero Day as part of our Alpha Two phase of development.

Changes:

• Scryp implementation for solving home cluster systems.
  • Players will earn scryp when playing systems in others' home clusters.
  • The creators of home cluster systems get a kickback when other players solve them.
• Fix system timer ...

(This is part 3 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.)

In our post on devops philosophies, we emphasized the continuous process of learning and revising, and said that a good place for that to happen is in retrospective (or post-mortem) meetings.

So what is a retrospective?

(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.

We've updated Exploit: Zero Day as part of our Alpha Two phase of development.

Changes:

• Upgraded Django (our web framework) to 1.9.
• Fixed a notification system issue that prevented the rest of the queue of emails from sending if one failed. Existing players, you may receive notifications from jobs ...

2015 was a weird year. Somewhere in that year is a typical tale of an indie game studio underestimating project timelines and changing directions based on surprises and things they learned.

But I want to talk about budgets.