Daily news, dev blogs, and stories from Game Developer straight to your inbox
Sponsored By
Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.
A Systemic Approach to Game Design: Part Three
Sometimes, a CEO/Technical Director/Creative Director/Rendering Dev/Engine Dev/Game Designer just needs to talk about making a holistic systems-first design process on a mech-based video game.
15 Min Read
This post was originally posted at its lovely home on Joy Machine's website.
Hopefully I did an adequate job of conveying that this series would be a very, very slow burn. It’s basically my once-a-month entry that will go through a whole lot of the details of our game, Steel Hunters, but it’s going to be a fairly long ride. There’s just so much wonderful ground to cover while we build up to the really good stuff.
And, really, I’ve been dying for a more detailed dissection of holistic system-based game design that goes beyond numbers and charts and spreadsheets into the motivation that really drive systemic game design: the player’s experience.
Previously on…
The Important Part
To really kick this one off, it’s important to understand one thing: designing an entire game around a series of complex, dynamic, and highly-configurable systems and then ensuring that all of these systems are woven together into such a cohesive experience that players don’t ever have a chance to differentiate between the varying systems individually is… Well. It’s not easy? I think that’s one way of putting it.
Another way might be to say this: essentially, what you’re doing is taking apart a Swiss Army Knife, making each of those little, itty-bitty tools into their standard individual sizes. And then you start juggling all of those disparate bladed edges. And the end result is that when you toss up all of those individual tools into the air for the final time, they all land perfectly in place and slot into their respective areas on a larger, but still usable, Swiss Army Knife XL. And then you give that knew XL knife to the player and say: “okay, here, we think these all work together flawlessly.”
To say this analogy is a stretch is a remarkable kindness, but it arrives where it needed to arrive: the player has a finely-honed tool, not a little chintzy, barely-usable pocket knife, but an unfolding toolbox of destruction to unleash upon their enemies. And what tool they choose to use is irrelevant to us, as designers/developers, because we know that it doesn’t matter to the game simulation: every tool will work. It’s just a matter of how the player chooses to use it.
Where Do You Start?
I’m already about a page or two ahead while writing this, so I need to note something: this will all end in a very practical, real-world example.
So, bear with me.
You start where it makes the most sense to start: the foundation. And that’s going to be the most difficult part of this entire process (well, until it comes time to polish and tune things). While you’re laying the foundation for your project, you have to have laser-dedication to ensuring that what you’re doing is not a quick prototype. It’s not a dash-and-done standalone feature you can show off to people. It’s not going to make great screen shots, and it’s definitely not going to make killer game footage.
And, yet, you are going to design, develop, test, redesign, refactor, redevelop, start over, design, develop, test, redesign, refactor, and so on until you’re so immersed in your foundational task that it’s almost hard to see the light at the end of the tunnel. Which is fantastic, because it means you’re so involved and so immersed in ensuring that the foundation is exactly what it needs to be — and nothing more — and, no matter what you throw at it later on in production, that it’s as solid and bulletproof as anything you’ve ever worked on before.
And, No, It Still Won’t be Perfect
Part of the reason that it’s so important to think through everything that goes into your foundational layer, vigorously and ruthlessly cut what it doesn’t really need, and iterate on that is because: hey, it’s not going to be exactly what it needs to be throughout your project’s entire production and post-launch time. It’s going to need to get tweaked and tuned (likely frequently); which is why it’s so critical that you keep it simple, flexible, expandable, and doing only exactly what it needs to do: hold up everything that is to come.
Because once production is rolling and you’re in the heat of milestones and deliverables and demos and all of that the other fun stuff we’re accustomed to in games, the amount of mechanics and systems that you’re going to heap onto that foundation will grow and it will grow and it will grow and you can never know when those systems will be very well-designed and thought-through or when they’ll be pretty rough-and-tumble implementations of ideas you need to convey but aren’t yet ready to truly design and develop in a future-proof way.
And when things start going wrong (and they will, and it will be wonderful — system-oriented game design by its nature astounds developers and players alike with what a real-world game state can produce), you need to know that no matter what: your foundation won’t crack. And it won’t be what’s causing bug after bug after unexplained phenomena after bug after bug after bug. Because if you start having doubts as to whether these newly-added systems are flawed or if it’s actually your foundational layer, it’s going to be maddening.
The Foundational Layer of Steel Hunters
When we started this project and it was still in its R&D phase of pre-production, we quickly knew a lot of what was our critical core feature set:
Customization — Customization of look and feel and style. Customization of speed. Customization of acceleration. Customization of mass. Customization of weapon load out. Customization of that crucial “backpack” slot. And what kind of play style the player who customized this beast of a mech was actually intending.
Flexibility — This may end up being my most-used word for this entire series but, yeah: flexibility. As you go through production, you’re going to find emergent gameplay crop up out of the unique interaction between systems that you may (or may not) have predicted. And once you find that amazing, “natural” result of cross-system interaction, you’re never going to want to let go of it. And this means that as you turn a random (or designed) reaction into a first-tier mechanic, the rest of the game simulation needs to hold steady.
The Player Experiences — No matter what ungodly creation a player may let loose into the world of Steel Hunters, it’s of paramount importance to us that players never feel penalized for thinking outside the box of trying combinations that were completely unthinkable to us. In fact, that’s the exact goal of this whole thing: we want to play the hell out of this game throughout development to figure out what we find, and then the first week it’s in player’s hands, our satisfaction with the project is entirely dependent on how quickly players can astonish us with strategies and play styles that they uncover.
On some level, that’s a fairly trivial-seeming list. Yeah, we want customization and flexibility and we want players to have a good experience. But, the players have a Swiss Army Knife XL in their possession, and maybe they find that the unnecessarily-large nail file and the super-scissors (well, at that size, probably more like hedge clippers) are where they want to eat. What does that mean in a practical sense? How do we prepare for that?
The answer is: we prepare for everything assuming that we know nothing about how the game will evolve once it’s live. Our dream scenario is that players quickly subvert what we thought were great strategies and sound mechanics, and within weeks after launch have created an entirely new meta game layer over the game that we’ve been playing throughout production. And that evolution never stops.
So, How Do We Design for That?
There are still a lot of mechanics that we have at our disposal internally that I’m not going to delve into right now (partially for intrigue, partially because they wouldn’t really fit in this article… okay, mostly for intrigue), but where we chose to put out foundation isn’t even in most of the really cool mechanics that we’re hoping to show at GDC this year.
Yes, Quick Side Note: We’re Demoing at GDC This Year
So, hey, if you want to get your hands on a pre-prototype (hopefully prototype, but until that GDC build is out, I’m calling it a pre-prototype), be sure to e-mail us at [email protected]
Sorry. Had to Do That. Where Was I?
Oh, yes, so mechanics not ready to discuss blah blah blah. Our foundation: the run-time assembly of a mech from procedurally-generated parts. And, yeah, after all that build-up, that might sound like a bit of a let down, but hear me out.
The Mech
As you’ve likely gathered by now, we’re really big on player customization of their mechs. And we provide eleven different part slots on player mechs that can be fitted with whatever generally-qualified for that slot. The slots:
Locomotion — This is the base building block of the mech; the locomotion type defines the base parameters of your play style. Will you choose a biped with fairly standard third-person controls (move, strafe, backpedal, sprint)? That will offer the most flexibility in your play styler, but does that mean it’s the best choice? Because you can also choose a quadruped locomotion rig that can instantly hit its max-speed in any direction as soon as you press a key down, making you a nimble spider-bot capable of running circles around the less-nimble behemoths enemies you face. Of course, a quadruped rig has pretty substantial overhead — it’s heavy, its max speed isn’t /astounding/, and it has roughly the same mass tolerance for all the other combined part weight as bipeds. Which could lead you in the direction of treads; make your mech a roving tank capable of easily wielding a heavy mass load on top of its existing heavy mass. You can hit the highest max speed of any mech in the game, but you’re sacrificing quick mobility and reaction time given the more vehicle/tank-like nature of treads. Anyway, what I’m saying is that locomotion matters a bit.
Chassis — The chassis connects directly to the Locomotion part and, essentially, serves as the hub for the remaining nine parts that you can outfit your mech with. The chassis will determine your base health, your base energy, in addition to a lot of supporting parameters that can impact your choices for your remaining parts substantially.
Arm Weapons (Separate Left and Right Slots) — Arm weapons are going to be your gatling guns, your grenade launchers, your kinetic rifles, your energy beams, your sniper rifles, your personal shield, homing rocket launchers, and much more. They’re your bread and butter weapons, and they’re mapped to the left/right mouse button so you can fire ‘em off in rapid succession or, hey, just go full-auto on both until you deplete your ammo supply.
Shoulder Weapons (Separate Left and Right Slots) — While you’re gunning down what remains of civilization in your full-auto-frenzy, just tap the Tab button to switch to your shoulder weapons. They’re also mapped to your left/right mouse buttons. And they’ll consist of things like gauss cannons, rocket silos, swarm missiles, homing missiles, rocket-propelled grenades, plasma cannons, mine droppers, and all sorts of other weapons that were too far down my main design doc to keep naming.
Processor — This is a non-visual part, but that doesn’t make it any less useful. Your processor is going to determine how quickly you can acquire locks, how fast you can recover from EMPs, the speed at which you can analyze parts of the massive Behemoths, whether or not you have auto-regenerating health and energy (and, if so, how quickly?), your ability to compensate for weapon inaccuracy, etc. It’s, well, your mech’s core processor.
Backpack — The backpack slot is basically the “X factor” for your mech. We haven’t really pinned down our launch list of backpacks yet, but these are things like: boosters that can have you speed across the ground at rapid rates or, if your mech is light enough, take you right into the air. Or, maybe, you want to toss a mobile artillery cannon on your back — once you’re in position and your friends are guarding you, you can deploy it and become like a Starcraft siege tank on-demand. Or toss a rail cannon on there that has to be powered up like the delightful Neon Genesis Evangelion sniper rifle in the first few episodes (maybe it won’t take a city-wide effort to power it. hopefully. or maybe we’ll make a mini-SimCity sim. who knows? we’re wild. we’re crazy, we… well, we won’t do that). We’re also talking about things like large-area mobile bubble shields your co-op partners can take advantage of, or a mobile repair base, or a drone launcher. Basically: this won’t be your moment-to-moment slot like the arm/shoulder weapons, but it’s going to fundamentally impact how you play the game.
Attachments (Two) — The attachments are where you’re going to find a lot of supporting/auxiliary functionality and mechanics that can help you diversify your mech’s capabilities, reinforce the ones that you want to stress, or simply compensate for what the rest of your mech is lacking in. These are things like radars, nanobot factories (for minimal, though constant, self-repair), auto-deploying countermeasures, lock-on ability once you get a certain Behemoth subsystem in your sights, additional armor plating to guard your cockpit (more on that in a second), or simply additional health boosts or energy recharge/storage boosts. Or, hell, maybe just more bullets.
Cockpit — The cockpit is where your pilot lives. So, it’s simultaneously one of the most important and also most vulnerable parts of your mech. We have chassis and cockpit combinations that allow you to build your mech in such a way as to establish a fortress of steel around your cockpit to limit the damage it is vulnerable to because, when the cockpit is hit, that’s a guaranteed critical hit. Behemoths have weak points like this as well. Critical hits can really happen anywhere in the current design, but we may limit this to cockpit hits to ensure consistent player hit feedback — this kind of thing won’t be known until further into production when we’re ready to solicit tuning and design changes, as opposed to just troubleshooting technical issues. Point being: your cockpit brings a host of small additional features, potential weaknesses, boosts where you need it but don’t have anywhere else to spare, or, if the part is rare enough, unique abilities that can be passive, proc, or actively activated.
Admittedly, that was more detail on the individual mech slots than I intended to go into, but as tends to happen when I talk about our game: I ramble. The point is this: as you can see from what I outlined above, we intend our mechs to be some of the most meaningfully-customizable player avatars to ever see a third-person action/shooter.
The Difficulties
With this incredibly wide range of possibilities purely arising from a single player’s choice of part load outs. And in case I haven’t mentioned this before: our parts are dropped from Behemoths or crafted and all have a Diablo-esque loot flair to them. They have a spectrum of rarities, a range of possible buffs/debuffs, “faction” bonuses (set piece items, essentially), and, on the rarer items, entirely new abilities that can be triggered.
So, if you’ve worked on any game with procedurally-generated loot before, the issues that can arise from this degree of unpredictability are… Substantial. And couple that with the kind of game Steel Hunters is: an action/adventure third-person shooter. We’re not doing floaty Shooter/RPG stuff with our weapon and ballistic systems either: we’re going pixel-accurate aiming, hit response, and whatever the hell else the bullet happens to do from there. Those bullets. They crazy. So, there’s a lot of possible room for failure.
Hence: the Foundation
To minimize those issues, the first thing we decided to focus on was the absolute basics: mech customization, run-time mech assembly, the moment-to-moment input response, intense hit feedback, pixel-perfect hit detection (which wasn’t… super delightful to implement in third-person), and all of the other fundamentals that are necessary for a good shooter.
And then we iterated, redesigned, refactored, re-implemented, and drove our mech customization//assembly system through the grinder to ensure that no matter what gets slotted on a mech: it works. And it works 100% of the time, even when we try to toss edge cases at it. And then we make sure that, sure, it works, but does it still play like a tight, intense shooter? (Note: this is why we talked about F.E.A.R. 3 last entry).
Spoilers: we think so.
What’s Next?
Well, to be honest, the next installment is going to be centered around whatever part of the game is the most fun to talk about when I write this piece again next month at 3am. But, each new article in this series is going to build off of what was discussed before, constantly moving alongside the game’s production process and finding whatever we’ve worked on that best-exemplifies the next major part of this holistic, systems-first design process.
Read more about:
Featured BlogsAbout the Author(s)
You May Also Like
