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 or learn how to Submit Your Own Blog Post
Some people think in terms of narrative, some in terms of atmosphere, some in terms of emotions. I think in terms of systems.
Maybe I'm a robot?
This post was originally published at its loving home on the Joy Machine site.
It's no surprise to a lot of the people who have, well, ever talked to me at all or read anything I've ever written that I'm a designer that believes systemic design is, well, not the only way to design a game... But it's the best way.
To preface this, I'll link a few of the archaic remnants of Polycat.net, my former site that I took out back and shot with a shotgun earlier this year. Well, it was more like I just chose not to renew it, but that's hardly dramatic.
The Systemic Integrity of Expression - Me vs. the Traditional Game Narrative. Also Alpha Protocol was great.
Lie to Them - My profound desire for games to figure out mechanical/systemic ways of subverting player expectations.
An Economy of Fun - Game developers can aim higher than canned storylines that, barring clever replay-specific mechanics, don't really warrant playing a game more than one time through.
So, that's my little history lesson for the moment. Essentially, the school of thought I belong to as a designer is one that has its roots in immersive sims (Deus Ex, Thief, System Shock 2, etc.). The odd thing is that, with some exceptions, I don't really love immersive sims. I find that playing them tends to fill me with equal amounts joy and non-enjoyable stress. And I dislike the save game-jockeying. I'm replaying Dishonored: Definitive Edition right now, and one of the scene transition tips is "Save your game often."
I have a better idea: don't. Avoid that temptation to save your game frequently because what immediately follows frequent saving is frequent reloading. Not only does this absolutely throttle any sense of flow you may have going as a gamer (even moreso than death, unless the game is bad about respawning quickly), but it pulls you a little bit out of the immersion that the game works so hard to create. How can you really feel the high-stakes of a risky maneuver or strategy if you always know that if you don't execute it perfectly (adequately is never enough) you just quick load your last save and try again.
To this day, Far Cry 2 is still one of my favorite games -- if not being my favorite game. I played it on my Xbox 360 which means that my saves were isolated to finding one of my safe-houses (the PC version has quick-saves/loads -- it's awful). This resulted in any major enemy encounter playing out with me yelling desperately at a television hoping that "please don't break, please don't break" or "please don't hit the ammo canister I'm standing next to because it would hurt in a deadly way" would somehow impact gameplay. And everything that went down in this encounter, regardless of how ugly and sad my game skills were for it, was borderline "permanent" because my last save was so inaccessible (yes, 5-10 minutes is a lot okay) that everything I did mattered. One of my other favorite games, Monster Hunter, has a similar quality to it. You join a mission (with or without friends/rando-allies) and you have three "lives" to accomplish that mission's goals. And, much like Far Cry 2, the amount of ugly, awful, stupid, ridiculous things you do as a player during those missions is a testament to the strength of the anti-quick-save design of the game.
All of this seems kind of random and aimless, which is not something I'm infrequently guilty of, but the point is this: immersion matters. No matter what the game is, immersion matters for one of two reasons:
You want the player to be immersed in the environment, game, game world, and its consequences.
You want the player to be immersed in the environment, game, game world, and its consequences so you can intentionally pull them out as-desired.
I really cannot think of a game that benefits from not being "immersive". Well, except arguably some mobile games that if they were immersive would result in mass chaos as people lose the ability to walk (or god willing, drive) due to their entrancement with a game. Immersion is ultimately what we aim for. We want players to feel as if they're a part of our worlds, of our stories, and we want all of the actions that we bestow upon a player to not only fit within that game world, but help expound on its authenticity.
I was playing Titanfall 2 the other day and, my lord, the movement mechanics. THE MOVEMENT MECHANICS! So smooth, so free, so powerful. It's hard to think of a similarly-paced game not having that same functionality. And then, completely without understanding the irony, I turned on Battlefield 1 and played an Operation match -- a game which makes you feel every pained movement of the soldier representing you in-game. Here are two dramatically different approaches to first-person shooters. And, personally, I had fun with Titanfall 2, but I get unwaveringly-obsessed and focused on my Battlefield 1 matches.
Just as much as we want to fill out the actions that players have access to with cool, awesome, fluid, amazing mechanics... There is also something to be said about what we hold back. And, in fact, what we hold back, or what we choose to make more complicated, is often more meaningful than things we explicitly grant to players.
Now to get to the reason this post exists at all: why I take a systemic approach to the entirety of Steel Hunters' design.
At its core, Steel Hunters is a cooperative third-person shooter. Full-stop. That's what it is and its entire design reinforces that. The game is not a deep simulation of nitty-gritty mech mechanics, nor are you balancing the mass that's right-heavy on your mech vs left-heavy because each step you take reflects that difference in mass, nor do you have to worry about fueling up mid-game in order to continuously move your mech (I came up with this mechanic just to shoot it down while writing this).
Nope, none of that. Once you (and potentially three friends or complete strangers or whatever) start a mission, you're playing what is fundamentally an action game about taking down bosses that you should have no chance in taking down, what is secondarily a loot-focused gathering game, what is tertiarily a resource-gathering game, and what is finally an adventure game. All of the mid-game mechanics and systems go to reinforce the reality of the environment that you're playing within, assist the mech power fantasy, and make a consistently interesting game simulation that often surprises but never confounds. And just so I mention it here, the depth and breadth of customization that players have over the entirety of their look, feel, and weapon loadout is one of the top-tier design goals of the entire project. I'm not focusing on that here, but it's definitely A Thing.
That sounds like a tall order (and it is, believe me, it is), but it's all very doable with the right mindset applied to pre-production design and prototyping.
The first thing I did when working on the design for this game is break it down into individual, standalone systems:
The ballistics simulation, along with ricochets and pass-throughs depending on the hit physical material.
The physical material application and responses (dirt flies when you hit dirt, glass aurally breaks and falls apart when you hit glass, etc.).
Physically shading the entire scene using proper PBR principles and practices, and ensuring consistent practices throughout the use of all content.
Fire propagation, including doing fire damage to anything that happens to be affected by the spread.
Different aesthetic and functional reactions to being destroyed via a damage-over-time, an explosive, a kinetic, or an energy weapon.
Admittedly, the details of this are still being worked out due to the number of different object/actor types that all have to be taken into consideration. Some semblance of it will be in the upcoming prototype demo, though.
As much logical destruction and associated cause-and-effect as Unreal Engine 4 can handle. This is ongoing, but my goal is to have at least 75% of the scene destructible with objects relying on their actual weight-bearing supports to stay in place.
A full weather simulation. The environments in Steel Hunters are supposed to be volatile, dangerous, and unpredictable, and the gameplay should reflect that constantly. The demo environment, a rural town in the outskirts of Nevada, has random lightning storms (which can greatly affect the stored energy of a player), heavy winds and dust-storms (which dramatically impact visibility), and so on. And everything both graphically and functionally needs to respect the weather conditions at any given time, whether it's simply swaying in the wind, to a heavy storm/tornado that's capable of moving around heavy objects.
There are other mechanics that feed the overarching game simulation designed/developed, but that is generally my go-to list for explaining it. Now, all of those features are good and well, but they don't really mean anything without the agent of chaos himself: the player.
And now we get to the part that is going to cause me the most pain but also, I hope, be the most amazing feature of the game: how customization affects the core mechanics of the mech itself.
First, we have movement. There are three types of locomotion planned for launch:
Biped - Standard "infantry" movement: move forward/backwards, strafe left/right, sprint using tank-mode controls. Requires a degree of continuous movement in a direction to reach max speed. Can handle moderate loadouts without performance being affected.
Quadruped - Can move forward/backwards and strafe left/right at its max speed immediately. Cannot sprint. Can handle heavy loadouts.
Treads - Literal tank controls. Can handle absolutely any loadout at the expense of mobility. Can eventually hit high max speeds, but requires a hefty acceleration period.
As I found out fairly early in development, movement is pretty hard to really: A) do procedurally, B) make responsive. You might assume that to simulate overloaded (in terms of mass) mechs, that you'd greatly increase the amount of time it took to reach max speed. And that is a perfectly valid assumption. I say it's valid because it was my assumption at first.
Well, turns out, that just makes the mech controller feel completely unresponsive and sluggish. Now, don't get me wrong, people adore overloading their mech past capacity, but they hate unresponsive controls. These people are awful, but I am these people, so c'est la vie. The solution I've arrived at is to not ever delay movement, but to limit step distance/time. If a bipedal mech is overloaded with equipment, now it suddenly will take longer to complete a given step -- this has a milliseconds-long delay in movement but, given the amount of steps taken over the course of a mission, it adds up fast. But, most importantly, the perception of input responsiveness is not impacted; there's still an immediate mech response to any input that the player presses, it just affects how the procedural movement simulation plays out.
(I thought that was a pretty clever solution, to be honest).
That entire system is the basis of the Speed vs. Mass axis of player configuration -- this being one of the two first-tier decisions that players have to make whenever they customize their mech for their next mission.
The other major tier is Kinetic vs. Energy vs. Explosive. Which I'll cover another time. Also procedural generation's role in Steel Hunters' production plan. Also also also. Nevermind. For the future.
Read more about:
Featured BlogsYou May Also Like
