Design Deep Dive - So What's a Game Designer Anyway? (Part 2)

In yesterday’s blog post I explained how a good game designer is always looking for interesting questions to ask the player. When a game designer stays focused on the players, the game usually turns out better. I shared examples of games I made when I was younger to illustrate how games that don’t challenge players with interesting decisions get boring quickly. And finally I hastily hammered out some examples of the challenging questions that great games of various genres ask their players. But as I stated in part one of this Design Deep Dive, a designer is not only responsible for asking consumers interesting questions but also needs to have all the answers during development.

Game designer Liz England provides a helpful depiction of game design in her article called “The Door Problem.” I highly encourage you to read through it when you have some time—it’s not a long read. The super-condensed takeaway from this “Door Problem” is that even the most mundane element of a game—such as doors—actually requires a ton of answers and explanation during development. A game designer is there to solve these issues and move development forward.

Image found here on Wikipedia

In addition to keeping development running smoothly and quickly, a competent designer also keeps the game cohesive and coherent. Some of the “door problems” that Liz England mentions could likely be solved by the artists, programmers, or level designers as they encounter them. However, when one door problem is closed in such a way, a new door problem will very likely be opened up. Then you have revolving door problems—not good. With one person (or a design team in larger companies) answering all the design questions, the answers that make it into the game will all fit together better.

I’m not sure we’ll have many doors in Alkanaur, actually. But I thought I’d give you some examples of the kinds of answers I’d need to provide during our game’s development. For an equally mundane example, let’s talk about rocks.

•         Are there going to be rocks in this game?
•         How big can rocks be?
•         If we want big rocks, how will players see characters behind the rocks?
•         Can players interact with the rocks or are they simply visual details?
•         If the answer is both, how would we distinguish between rocks that can roll and rocks that can’t?
•         Can computer-controlled enemies “see” players behind rocks?
•         Can they fire ranged weapons or spells at players behind rocks?
•         How many rocks should be in any given level?
•         What happens if a player tries to target a rock with an attack?
•         If a character can tunnel underground, can they pop up in a space occupied by a rock?
•         If a character can fly, can they go over a space occupied by a rock?
•         What happens to a rock if a character uses an ability that alters terrain on that space, such as creating impassable walls or rivers?
•         Should our rocks blend in with the spaces they rest on, or should they “pop out” like our characters do?
•         Should characters get any type of bonus for being in a space adjacent to a rock?

As a tactics RPG, Alkanaur is a fairly complex game. But even the simplest games will still need a designer to step in and answer those questions. I think that’s part of the reason why I’ve always been drawn to game design in the first place. Design blends artistry and problem solving. I love posing fun challenges for players, and I also love the challenge of solving complex design issues in an elegant way. Hopefully these two blog posts cleared up any questions you might have about game design, but if you’re still puzzled or just want more info about game design feel free to reach out to me through our Facebook page or Twitter.