In the third part of the GDC 2015 takeaways, Eric discusses some lessons learned in the Game Design Case Studies seminar, hosted by Eric Zimmerman, where game designers Tanya Short, Dan Cassar, and Bennett Foddy dug deep into one of their game systems to show the process behind arriving at the one that ended up in the final game.
I’ll admit, I wasn’t too sure how useful this seminar would be, given that the game designers were going to focus on the details from one specific game system in a previously released game, but all three designers rewarded attendees with some interesting insights.
Game designers are rarely given a chance to see another designer’s thought process; that’s one of the reasons I’m doing what I’m doing on Blue Tengu’s Live Game Development Show. With online tutorials, finished products, post-mortems, interviews, etc. you only get to hear about the past, and, by the time the past is the past, everyone has had time to decompress and the results seem so simple in hindsight, yet when we try to make a game, it’s mostly stress with a healthy dose of trial and error.
All three designers in the Game Design Case Studies lectures went further back, before they arrived at a working game system, to show all of the steps that took them from game designs that didn’t work to polished final products. And, although the host of the seminar, Eric Zimmerman, promised there would be no theorizing, no inspiration, and no takeaways, I went away with the understanding that I’m not the only game designer who struggles with getting things right, and I was inspired by the designers and their efforts to make better games.
First, Tanya Short went deep into the procedural level generation that went into her game, Shattered Planet. Procedural generation is a misunderstood solution that sounds great on the surface but often turns into more work than the alternative of making everything by hand. Because it’s random, rules need to be added to shape the results into something pleasing to a human player, and those rules grow complicated. (For a quick example of how difficult the problem of shaping automation for human consumption is, imagine trying to design an AI that can produce pleasing music that a record company would want to sell.)
In Tanya’s example, she went through the following steps with the procedural generation system for Shattered Planet:
1) Making a list of possible room shapes
2) Selecting possible doors from one room into another
3) Picking one of those possible doors
4) Extending the level
5) Connecting the rooms via the doors and decoration
6) Eliminating dead ends
7) Adding entities (enemies)
8) Adding a fog of war element
But when everything was generated, her team had to deal with some of the problems that cropped up like: explosions destroying bridge pieces and causing dead ends, keys being spawned right next to locked doors, very linear procedural pacing, and a randomness to the space (rooms not feeling functionally connected).
Some of the problems, like the explosion problem, were things they could address, while the pacing and randomness problem were things the team left for the future.
Although procedural generation is something I tend to shy away from because of the pitfalls, seeing how a team went about it was informative. Even little things like creating broken tiles the player can’t step on as decoration to rough up the final output make the difference in how “mechanical” a stage feels and could even be extended to games that aren’t procedurally generated.
A lot of times, the polish of a game is actually “unpolishing” the game – making it more organic. For example, when you see a Unity game in its early stages, you can almost always tell it’s a Unity game (even without Capsule-Man running/floating around). They have that bright, crisp, virtual feel to them, and the games that succeed in not looking like Unity games are the ones that manage to muck up that perfection. Exploring ways to muck up Project Spaghetti without ruining the world feel is something I’m always trying to do as I continue on with the game, and Tanya’s talk gave me a useful reminder about just how important it is.
The next speaker, Dan Cassar, wasn’t a video game designer but a tabletop game designer. As I’ve never had a chance to talk to a tabletop game designer before, getting to hear what he went through for his card game Caveman: Quest for Fire was fascinating.
Dan came from a programming background that shared some overlap with mine (we both started programming with the C-64), and allowed him to design some tools to expedite the design process for his game.
His tool was XML-based, allowing him to feed the data for his card game into whatever programs he needed and allowed him to track the change history for his game – something not a lot of tabletop designers have probably figured out how to do well. With that change history, he was able to pinpoint the source of new problems that popped up during live testing with players.
The example he gave was a problem that cropped up in later variations of his game where no one was bidding to go first. In Cavemen: Quest for Fire, players are supposed to compete in an auction system to obtain cards, but at one point he overbalanced the game so that no one competed (they just settled into one of three equally viable strategies and left each other alone until someone won).
His solution: cut the costs for some of the more valuable cards, so that everyone would want them, or at least try to prevent other players from getting them. Like Tanya’s example, his solution was another example of “unpolishing” a game to make it better.
The third speaker, Bennett Foddy focused on the steps he took to make his game Pole Riders feel right. He even had some older versions of the game to show the audience, and seeing how the game evolved demonstrated the impact that struggling to get things to feel natural to a player can have.
When he started, the input was very digital, resulting in a game that felt stiff and created the potential for a standoff, as players could block the goal by relying on that “perfect” digital input.
He described the classic skateboard game 720 as an inspiration for his final control scheme. With the 720 arcade game, the controller swiveled around the center in a full circle (imagine a hand crank laid on its side), and, as a result, the in-game results matched the physical direction of the controller; they achieved parity between the game and the input device.
Although the 720 arcade game designers were able to use weights and feedback to help ensure players didn’t get into situations where the stick and skateboard directions were mismatched, they also did a few clever things to make sure that players who forced their way out of that parity ended up crashing their skateboard. (exactly the kind of thing that would happen if you didn’t have your skateboard pointing in the right direction when coming down from a jump in real life)
With Pole Riders, Bennett did what he could using existing input devices to make sure players always felt parity between the controls and the on-screen results.
The lack of parity in many games is one of the reasons people who haven’t grown up with the language of video games can’t get into them. Even for gamers who are familiar with the language of video games, lack of parity causes problems. Ever picked up a game you put down for a few weeks and forgotten how to play? That’s from lack of parity. Why does the right button throw a grenade? It just does. Why does double-tapping the left stick cause the character to dodge? It just does. The more of those “it just does” that pile up, the less approachable the game and the higher the learning curve. Less approachable games tend to scare off newer players and result in long tutorials for advanced players (and when you go back to it two weeks later, you end up forgetting everything from that long tutorial).
There are few games that could ever achieve in-game parity with the monstrous amount of buttons on an Xbox or PS3 controller, which is why many people who enjoyed games back when there were only one or two buttons have given up on games. However, finding ways to make the game match the input can go a long way towards making it more fun for everyone, and the methods Bennett used to reach that parity were informative.
For one, he focused on linking the poles themselves to the controller, rather than linking the character holding the pole to the controller. After all, if the pole is doing all of the game work, it makes sense for that to be the focus of the controls.
Unfortunately, because he also had to deal with physics, he couldn’t get the pole to match the input controls exactly, so he added a nice additional touch: making the pole riding character’s elbows respond instantly to the player’s input while the pole had a chance to catch up. For the most part, players could expect the pole to match their controls, but for those moments when the physics needed time to catch up, they could at least confirm their input was having an effect by checking the character’s elbows. Brilliant.
Bennett’s focus on achieving parity between a control scheme and the in-game results is something I’ll do my best to remember when designing games in the future. In Project Spaghetti’s case, the arcade-style, instant response of the character to the controls means there isn’t much disparity to address, and, unlike Pole Riders, there are no physics to deal with, so it’s fine where it’s at, but if I do make a game with physics in the future, remembering the pole rider elbow example will help nudge me forward.
For being promised no takeaways, I took plenty away from these three talks.