Closing the Loop
Deathloop, Arkane Studios.
A game genre I’ve recently been trying to get into are immersive sims. As someone with a weakness for stylish game, one of my first forays into the genre was Arkane’s 2021 time-looping adventure Deathloop. Having seen a couple negative reviews, I was surprised by how much I enjoyed the game, even if it takes a while to hit its stride and then overstays it’s welcome.
That said, playing it got me pondering about the nature of loops and learning. A big part of the game is learning information you can use in future time loops to perfect your plans, and even if it feels pretty videogame-y at first it’s actually a extremely common trope in time looping stories like Groundhog Day or Palm Springs.
Although we do not live in an actual time loop, we do “loop” or repeat sequences frequently in life, and can learn a lot in the process… or not! This is actually a topic I think a lot about as it relates to game development and that developers could be better at, especially compared to other art forms. I don’t have the solution… but let me ramble for a few paragraphs.
The Rule of the Loop
The first time started thinking about loops and learning was in Jesse Schell’s classic The Art of Game Design, in which he describes the “Rule of the Loop”:
The more times you test and improve your design, the better your game will be.
Given the iterative nature of game development, this does make sense! I do think you have to consider diminishing returns (which I talked about in a previous blog post) but overall agree with the sentiment.
Schell goes on to list two key questions developers should always be considering:
- How can I make every loop count?
- How can I loop as fast as possible?
The chapter goes on to describe a brief history of software engineering paradigms such as waterfall, Barry Boehm’s spiral and agile, and then continues with practical tips for better and faster loops such as identifying risks and using loops to test possible mitigations to these risks.
All good advice I’ve found useful during my career. But something I’ve realized (and am also guilty of!) is that developers struggle at closing the loop — it’s easy to find excuses and ways to stretch the loop, either by pushing decisions to the end of a milestone or even further milestones, and some cases even delaying projects for the sake of quality.
While frameworks like agile incentivize short loops via sprints and frequent learning with retrospectives, it’s a struggle to put pencils down, especially when you feel like you could do even better work with just a bit more time. If that time is granted, there gradually is less pressure to be efficient with loops. Even if it’s not conscious, people will start thinking “If we got extra time now, why do we need to worry about going faster? Do we actually need to be more efficient?”.
The biggest concern is normally budget: how long can we afford to actually work on this before we have to release it? But I’ve seen projects where the budget pressure is not immediate, which makes it easy to drag out the project indefinitely.
Long Loops And Short Loops
One of the reasons I think about closing loops is because of how often you can see loops being “closed” in other forms of media. Most commercial games are usually multi-year development endeavors, but you can see people who draw and post comics, make YouTube essays or write newsletters doing it weekly, if not even more often.
While not directly comparable of course, and there are other examples with timelines comparable to games (e.g. film and TV), I can’t help but think about how much more these artist are able to learn or adapt thanks to the fact their loops are relatively short and shared with the public. You can see how games suffer from the opposite of this, with projects greenlighted when a trend is hot taking years to be develop and then failing to capture the audience they were counting on all those years ago.
That said, we can see the short loop strategy in games too. Even if the expectations for what “early access” should look like have skyrocketed over the years, it continues to be a valuable process for developers who are able to release continuous updates that incorporate player feedback after each patch. Live-service games also have the benefit (and pressure) to regularly update, which gives developers the chance to learn gradually from what patches or changes resonate with players.
And even if I say games are multi-year endeavors, the truth is that we’re in a “golden age” of indie development where small, quickly developed games like Peak are being played by millions of players, and the learnings from these games do not only serve the developers themselves but also serve as an inspiration and base for other developers to do something similar in the space.
Learning From The Loop
So, I’ve admittedly used loop in a very loose way this post to refer to two very distinct ideas: there is the idea of looping or iterating during development, but I’m also talking about the loops of releasing something to the public and using that to inform future work.
They are very different ideas, but intensely intertwined and important: we can learn and improve a lot from internal iteration, but there are significant lessons that we can only learn by releasing something into the public. To be able to learn from that experience though, developers have to survive the release and be able to apply that knowledge to future projects — there is no loop if there is no “end” followed be a new “start”.
That is a problem way bigger than what any individual developers can solve, but aiming for faster, more efficient and more public loops is a step in the right direction.