In my senior year at the University of Michigan, one of my roommates and I had a nightly tradition: playing NCAA Football 2005 (it was 2007). We played every night because we were constantly learning each other’s strategies, adapting, and trying to come up with new ways to surprise each other. One of us would eventually win, but we would be able to talk about and dissect our match for a solid 15–30 minutes after we were done. Every night. We don’t think of EA Sports games like we do Deus Ex, but you can’t say that’s anything but a purely systems-driven game. The goal of this article is to really help clarify the benefits and results of systems-based design for players and then to discuss the development side of achieving those experiences and why my small team is creating a systems-based game.
When we talk about a game having good systems, we are essentially saying that it has deep mechanics. That’s not inaccurate, but it does skip over the larger point: a game having good systems means that the game itself is a good simulation. Simulation in this sense is the result of a “holistic systems-based game design” and not games considered to typically be in the simulation genre.
A simulation, by definition, is … well, pardon the cliche but according the shockingly relevant Dictionary.com definition, it is “the representation of the behavior or characteristics of one system through the use of another system.” In that sense, a systems-based approach to design (which is what I’ll call it, as “simulation” is an overloaded term in games) is not a single mechanic — regardless of its complexity or perceived depth — but is instead a series of mechanics in which the game reacts to player interaction using its initial design stance. That is, standard player actions lead to complex game reactions. A system’s integrity (or fun/complexity/depth, whatever you’d like to call it) is only as good as the systems that affect it and, in turn, are affected by it.
System designer versus systems design
In treating a game’s systems (mechanics) as ecosystems in which a player is free to use the mechanics at their disposal in a game world that is fully capable of reacting to them with depth and consistency (which, as counterintuitive as it sounds, often ends up creating interesting unpredictability for players), we start seeing games as true worlds for players to discover not just visually and thematically but in play as well. It is, in essence, removing the invisible walls that contain players in some worlds with the endless expanses of open worlds.
June 5th: The AI Audit in NYC
Join us next week in NYC to engage with top executive leaders, delving into strategies for auditing AI models to ensure fairness, optimal performance, and ethical compliance across diverse organizations. Secure your attendance for this exclusive invite-only event.
A “system designer” is a common role in games. While every studio has different ideas what that role actually means, it generally involves designing individual mechanics/systems and ensuring that they’re balanced, fun, so on and so forth. “Systems design,” on the other hand, is a more holistic, project-wide approach to how a game is designed and developed (and typically taken on by a creative or design director). Systems-based games are everywhere but most commonly associated with the “immersive sim” genre. This is equally vague in concept, but in practice, it’s a specific type of deep, intricate first-person game. (Deus Ex is the poster child for the genre.)
Video games right now are at the point in their capabilities and level of complexity where I believe game developers would benefit heavily from re-evaluating how their core mechanics and systems are approached. It’s important to discuss that both players and developers benefit from quality systems. Players benefit from a more dynamic and varied game experience, and developers benefit through less rigid implementations of the core of their games.
The impact of systems-based design
The decision about what kind of game experience a studio wants with its project comes early because the entire development and production of the game is dictated by that single decision. It affects how the programmers implement features, how the designers lay out levels and tune systems, how the expensive cutscenes are handled. Those are just a few examples, but there’s a heavy cost associated with how much freedom is allowed. Historically, games that open up the possibility space for how a game unfolds tend to be much more difficult to accurately schedule.
Sports games, for instance, tend to get the short end of the stick when, really, they’re the most consistently popular forms of imparting players with these kinds of systemic stories. There’s no predicting with 100 percent certainty what will happen in a single game when you start it. It’s all about the players, their style/strategy, and how they react to one another.
Whenever EA puts out the yearly iterations in their sports franchises — FIFA, Madden, NCAA Football (RIP), etc. — an unbelievable amount of time and energy go into taking data from the prior game and figuring out where to focus development time to make dramatic improvements (no, they’re not just roster updates and a new UI). Given the ubiquity and demographically diverse nature of these franchises, there’s a lot of analysis and pressure for all changes made every year that must be incredibly well-informed with both in-game and real-world statistical analysis. Point is, simulation/system-based games can be hard to make.
Dishonored as pure possibility space
I recently finished playing Dishonored 2. Its two protagonist characters provide a great example of systems-based design. The first Dishonored established a player character, Corvo Attano, with specific skills working within the world Arkane Studios created. In Dishonored 2, Arkane introduced another player character, Emily Kaldwin, with a radically different skill set from Corvo and then — and this still amazes me — presented players with the opportunity to play the entire game with either character.
Above: Emily Kaldwin from Dishonored 2.
In other words, Arkane had enough room within their game framework and universe to create two totally different sets of actions for the player to use while playing — and had it function both ways. It speaks volumes to the effort that went into designing Dishonored that their original ability set can coexist alongside their new character/ability set in Dishonored 2 and maintain the same level of internal systemic integrity of the original.
And, oh, that new skill set! Emily had an ability called Domino, which can chain enemies together so that if one suffers or dies, so does the rest of the chain. She also has a Bloodfly Swarm ability that makes any slain enemy explode into flesh-eating blood flies. If you do this to a killed guard near one other guard, it’s likely that the remaining guard will be able to kill the swarm. However, if you use Domino to chain together three to four enemies that are relatively spread out and use Bloodfly Swarm on one, that ends up affecting the whole chain. Now, four swarms of blood flies can then spread outward, kill, multiply, and bam, you’ve mastered biological warfare. You monster.
That sounds like fantastic systems-based design, but here’s the thing, compared to most games of its scope/budget, Dishonored has a fairly meager offering of tools. There are only five to six powers of consequence, plus a sword, a pistol, and a crossbow (and traps). Relative to the odds you’re up against, that’s a dubiously small number. But the interaction between your arsenal and the game’s commitment to ensuring that the player can make unconventional ideas work when coupled with an intense dedication to world coherency and accuracy makes every encounter a test bed for your next combination idea. This is the benefit of great system design.
The drawbacks of brute forcing system design
There are two possible approaches to achieving the degree of systemic cross-power synergy shown in Dishonored 2. One such approach, and likely not how Arkane approached their games, is to treat game mechanics as a combinatorial exercise of making all conceivable actions specifically react to the subset of remaining actions. Basically, brute force the hell out of your systems to achieve the perception of smooth cross-mechanic interactions. This path doesn’t tend to fare very well:
- It entails a large cobweb of design and code solutions to ensure each interaction is accounted for. And that creates a buggy mess that implodes when QA gets their hands on it.
- It makes inconsistent interaction (or, at the other end of the spectrum, rigid interactions) a real concern. If every system is set up for explicit responses to events, there’s no guarantee that the results will be repeatable. And that is worth repeating: if the result of a systemic interaction is not consistent given an exact recreation of inputs, the player can never achieve any real reward or incentive for further experimentation. Always aim for the unexpected, but never aim for the inconsistent.
That all said, this is all doable. And it’s doable to a more predictable degree so long as you throw enough development/design/testing time at it, making the production schedule more of a certainty. That tends to be where the game industry’s comfort zone is. I see postings for systems designers frequently in the industry, and they’re generally mid-level positions entailing the design and balance of a large feature. That is not systems design. That is the definition of any game designer.
Systems design is simultaneously very low-level to ensure simulation-level consistency, high-level oversight into the resulting goals of what is produced by the team, and an intense focus on architecture to promote expansion of any given system without having to explicitly update every aspect of the product to accommodate. And that’s a win-win for everyone involved.
Next, I’ll talk about why my small team is making a systems-based game and how to design true systems like those in Dishonored 2.
