A guide to systems-based game development

Above: An explosion from Steel Hunters

Even for a small team like mine, systems-based design has clear advantages. Here’s a more in-depth and practical example, using my in-development project, Steel Hunters, as a case story of sorts.

The entire development and production of a game is dictated by the early decision about what kind of game experience a studio wants. It affects how the programmers implement features, how the designers lay out levels and tune systems, how expensive cutscenes are handled, and so on. As I discussed above, choosing a systems-based game can be risky, in part because it’s hard to judge how long it will take to make effective systemic games.

There was one thing I wanted from our game that was more important to me than anything else: a cooperative game experience in which players have practically endless customization options working together to tackle difficult missions … and then forcing the players into a situation they didn’t predict and having to scramble, regroup, and come up with a new plan on how to not die horribly. This improvisational quality is the heart of the game I wanted to make, and that’s why Steel Hunters is entirely systems based.

Obsessively structured flexibility

One of the reasons I put together this project as a systems-first production — aside from my unwavering conviction that it’s the best way to approach a number of games — is that heavily scripted or limiting mechanics can only take you so far. For us, we don’t need a dozen developers and a handful of designers working throughout the project on separate features (which would still be a small team compared to triple-A studios).

We can get a variety of perceived deep gameplay mechanics that arise out of the result of systems producing interesting, often unexpected results based on the input. It’s a win-win for us. We get to take a concept that we all adore, flesh out what we can for release, and then, explore the entirety of the systemic space that we left open for ourselves post-launch.

Systems-based design as foundation

The best approach to development of a systems-driven game (and likely the one that Arkane tended toward with my Dishonored 2 example from the last piece) is to approach development with a mindset that every system/mechanic has to be able to operate solely in its own space. Once it’s to a point that the design and implementation are solid, that’s when you figure out where to open it up for flexibility and act upon external inputs/events while constantly being mindful to avoid designing yourself into a corner. Design and development should accommodate for this phase as early as possible, but what sounds good on paper (even if it’s sound and solidly proven), doesn’t always equate to actually being good in practice. In short, it’s a more risky, unpredictable, and iteration-focused approach.

After I wrapped up the prototype phase of Steel Hunters, it became time to start implementing everything for realsies. I already had a good idea of the end result that we were shooting for as far as core gameplay was concerned. So, from there, I worked backward. I broke every interaction down to its core components and then had to figure out what the most bare-bones implementation would look like. And then, I’d develop that out, get it working at a simplistic level, move on to the next building block, do the same, and so on. Once all of those pieces were in place, I was able to look at each one from three perspectives:

• What new components need to be added to the base functionality in order to get the systems working cohesively?
• What aspects of the game I need to hold off on until other parts were ready? This requires a more holistic understanding of what existing functionality could result in backing us into a corner.
  • The Behemoths, for instance, are the focus of our game’s missions. They’re large, complex, adaptive bosses that have to be deep and unpredictable enough to make for an interesting four-against-one scenario. But it’s impossible to earnestly start on the actual implementation of the Behemoth until we know, in very exact and practical terms, how to best structure and develop the core of the game: the mechs controlled by players.
• What, if anything, needs to be torn out of a given component and put into some other (or completely new) mechanism?
  • When working on weapons/projectiles, I ended up completely refactoring (redesigning/redeveloping) both systems to make weapons and projectiles wholly independent from each other. Then, I put what was necessary for a weapon to know about a projectile into an intermediary structure that serves as the “delivery mechanism.” The benefit here is that the weapon becomes isolated after its performs its function instead of having the weapon manage its projectile — the projectile exists on its own without being continuously controlled by the weapon.

Why do this to yourself?

No matter how you approach a game, it’s a hell of an endeavor. I chose this method of design and development because it ends up resulting in a world where a variety of events can unfold from say, a simple stray projectile. Say, recoil takes your aim off balance, letting loose an imprecise projectile that hits a ubiquitous red barrel, which blows up near an ammo dump, igniting all the bullets it contains, sending bullets everywhere around it, potentially killing everyone in a nearby radius. Now, that’s an exciting collision of systems!

We take the brunt of the design, architecture, and workload for new features up front, but if the result is a fully realized dynamic world then we have succeeded in one of our most important goals: making every decision matter. The projectile system is a small detail, of course, but it’s a prolific one in a shooter. We also have other gameplay systems, which are more pronounced, but all exist and operate on the elements that make up the environment in ways that aren’t dissimilar from the projectile/material example above.

The small details of interactions in the core combat gameplay may not have the pronounced and flashy power interactions like in Dishonored 2, but they bring a very unique quality to our combat model. Planning how to take down a major boss is one of the pillars of our game. Players will get ready, analyze various environmental factors, remember (or be prepared to learn) the “personality” of the boss, and eventually formulate their plan of attack. The world at that point is largely an inert sandbox. It’s upon the point of executing the plan that the agent(s) of chaos — the player(s) — start changing things. And if the world is reacting to every action, the underlying systems, that are not at the forefront of players’ minds generally, are operating and collectively responding to every choice and event.

At some point in that flow of gameplay, something unexpected can happen which forces players into a situation where their plan is no longer viable. In the heat of the moment, they have to call an audible, change things up, communicate with each other, and make things work in their favor.

And when the mission is complete, either through success or failure, we want players to be able to tell the story of what happened to others — like my friend and I would do at the end of every one of our NCAA Football sessions in college. And that story is only worth telling when it’s unique because if it’s not, then you’re just telling stories people already know. The best thing I could hear from people who play our game is, “I didn’t even know that was possible.”

Trent Polack is founder & CEO of Joy Machine, currently directing, designing, and developing Steel Hunters.