A Systemic Approach to Game Design: Part Two

This post was originally lovingly posted on Joy Machine's site (check it out, sometime?).

About this time last month, I broached the wide, wide subject of system-oriented design. That was intended as a very high-level piece to kind of set the tone for posts-to-come, and this is one of those... Posts... That is... Well... Here now by the time you're reading this. Intros were never my strong suit.

Being that I'm starting Joy Machine from, essentially, nothing (other than experience and a couple of the most talented people I've ever known), approaching Steel Hunters from a systemic design perspective first and foremost and primarily and critically and what I'm saying here is that it was the only real option in my mind. System design is just about the most difficult up-front task in the grand life sphere of Game Design. I don't think it's too much of a stretch to consider it a step removed from software engineering. After all, the first step for a software engineer is designing a product/system and then designing the implementation. So, yeah, not too far off-base. I'm going to get hate-mail from software engineers for this analogy, I know it already.

A STUDY IN F.E.A.R. 3

A while ago (well, in 2011), I wrote about systems design in F.E.A.R. 3. The thing about writing about F.E.A.R. 3 is that, well, no one really cared about an article about F.E.A.R. 3 (or ffthrir as I think I called it in the post -- UPDATE: totally nailed it without even looking). But that's partially what is interesting about low-level design: it really doesn't make a game for most people. It enhances good experiences and makes them become great. With that said, poor low-level design can absolutely tank an otherwise great game. If the fundamental systems that drive a game are poorly planned, implemented, tuned, or shallow, then suddenly there's nearly nothing that can save a game in the mind of a player.

For a lot of games -- especially action games, some flavors of adventure games, all shooters, and basically anything that relies on somewhat quick response-time from players -- those low-level interactions with a game are the foundation of the entire experience. And it's not a conscious and it's especially not a glamorous aspect of game development, but the "inner loop" (as I've mostly heard it referred to as by my best bro, Josh Sutphin) is crucial to holding a player's attention and sense of place (I promise I won't say this often) in your world and, in general, their immersion in your game.

Going back to ffthrir (I much prefer this name), it was actually a really solid game. Its story was garbage, its level design did its job, the engine was overall mediocre, but the game was just really fun to play. It was not the franchise I'd have chosen to make into a co-op score-based competitive game... Or... Anything remotely like that. But, there it was: a co-op score-based competitive game. The gunplay felt good, the progression was right, the controls and hit responses were tight, and, well, it was just all there.

BRINGING IT BACK... SOMEHOW

When it comes to designing and layout out the critical systems, exposed parameters (simple tweakable variables), fuzzy tweakable parameters (values/parameters that may change based on different contexts), curves for interpolation/tweening, curves as movement profiles, curves, curves, tables, data, numbers, infinity, limits, numerology, pi... Well, "more is better" is not actually true. More is never better. More is more that can go wrong, get corrupted, get accidentally changed by an intern and silently change the feel of the entire game for weeks before someone realizes what happened. So: fight more.

Instead, what you want to expose early, provide debug displays for, and make data visualization, tweaking, and A/B testing as easy as possible are the parameters and structures and profiles that define your game's very core. The things that, without them, your game actually loses meaning to you as a creative endeavor and just becomes a piece of software.

So far, I've had a lot of people tell me that I don't go into the "kinetic vs. energy" bullet point in the Steel Hunters feature list. And, to be honest, that's because I haven't fleshed it out to the point where I can say anything interesting about it. I know it's a key component of the moment-to-moment gameplay as well as the high-level mech loadouts that player choose. I know that it telegraphs well. I know that there are neat things that can be done with physical vs. ethereal weaponry. I know all of these things. But, to be honest, they're not critical at this stage of development to have fully worked out because I don't know what concrete mechanics from the possible (and endless) cloud of ideas are really going to make an impactful change on the core game sim.

And that's what it comes down to. Every single time I go over the Steel Hunters high-level design, core tenets, key mechanics that absolutely must exist, etc., I narrow things down or re-frame concepts so that everything fits. It doesn't always fit neatly (if it does it's usually serendipitous, for me, anyway), but it all fits. Everything has its purpose, everything has its place, and you're left with this toolset of mechanics, concepts, parameters, and, yes I'm going to say it: systems.

And then you get to making the game out of that toolset in a way that builds upon all of those core principles you've been pruning and tweaking and stressing over, and that's when the real fun starts. Because as any system designer will tell you: systems amaze, surprise, and astound gamers, developers, and general audiences in the results of the underlying simulations.

CONCLUSION

I'm actively trying to not make these posts incredibly long diatribes so I can space them out over time and let Steel Hunters really help evolve the way I talk about system design. But, I hope people out there kind of dig where these posts are heading.

Believe me, there is no dearth of content in my brain to draw from.