Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Get the latest Education e-news
 
  • Practical Tools For Game Designers

    [01.21.20]
    - Alvaro Salvagno
  • Get some pen and paper, we're about to get some work done. As you read this article, write down all ideas that pop into your mind. I'm asking you to do this because I'd like to instill in you one core belief: game design is something you do, not something you think about. And, as meta as it might sound, learning about how you work is vital in becoming a more effective game designer.

    If you have a brand-new notebook, please scribble on the first few pages. It's now ruined and no longer sacred. It can now contain bad ideas. Awesome!

    Here's a thought: all writing about game design that is not highly opinionated is useless - see what I did there?

    I'm obviously being facetious and mean-spirited, but the truth is that unless you're an academic interested in game design as a subject of study, most writing fails to help designers in their practice. I personally find that books and articles about game design assume that there is a right way to go about it, a formula, a how-to... where in truth, no one has any idea what they're doing. More importantly, the value of designers is that they work in unique ways. There's many different angles and approaches, and not every designer is fit to fix the same type of problems.

    Through these articles, I want to help you find your voice and style as a designer. This one's about the fundamentals: turning you from an idea-guy to a problem-solver. The former is fun, the later is a paid job.

    This particular article is divided in two parts. The first one explains the philosophy I'd like to share with you. The second one contains the actual tools you can use as a basis to develop your own workflow. If I were you, I'd skip the first section, jump to the second and get started on some actual work. But some people like guidelines and theory, go figure.

    At this point, I'm inclined to ask you a question : Why read yet another article about game design, when there's so many resources out there? If you stop reading right now, please just leave knowing this: Motivational videos are motivationalYouTube videos are game-analysisPost-mortem talks are made after the fact. The work you need to do is in the present : you need to sit down in front of a computer and just do it. Inspiration as something you wait for is not productive, costly and too unreliable.

    So, if you'd like to read my thoughts against thinking, here we go.

    Part 1: Game design is a practice.

    There's this joke amongst mildly to highly experienced game developers about idea-guys. It's about how beginners have these big ideas for games they want to make, but are not aware of the work it takes to get them done. We've all read the kid that wants to make an MMORPG and is looking for programmers, artists, composers... and has written one or two paragraphs about a game that is simply a declination of games that he plays.

    To some extent, I find this joke funny and I agree with it. It is highly true that ideas in themselves have no value if they are not executed upon, unclear or too ambitious. I disagree with it, however, in the sense that any idea, no matter where it comes from, can be the nugget that allows a designer to develop a neat game.

    Ideas in themselves are not a solid foundation to build a game on, though. But they might be good enough to get started. In the end, all that matters is that the idea allows you to get to work. Notice the sentence there : the idea allows you to get to work. It is not the work itself.

    Thinking about game design is pointless.

    Unless you're into wasting your time, I truly believe thinking about your game ideas outside of work-hours is wasted time. Ideas are fuzzy and, when held within your mind, they're most likely excellent. The moment you put them down on paper, you start seeing their faults, where they lack detail, things that are fundamentally wrong - case in point, the idea for this article was really good, and look at it now!

    Let ideas flow into your mind, for sure, but as soon as you think they're worth putting some serious thought into them, turn them into concepts.

    In practical terms, what does all of this mean? Simple : write your ideas down. That's why I asked you to get a pen and some paper. If you didn't do so yet, please, take a second to do it.

    The Concept

    The moment you put down your idea on paper is when you're doing the work. You are first faced with an uncomfortable and painful truth: ideas don't flow as well when put into words. That's where your work begins. You're about to turn an idea into a concept.

    A concept is a high-level description of what your idea is. You're trying to pin down its moving parts without necessarily digging into the details. You identify prerequisites, features, interactions and so on until you think you've dug through the idea itself deep enough. This is your initial concept.

    Example (based on https://tictac.io)

    Idea: What if tic-tac-toe played in real-time?

    Initial concept: Players are assigned a symbol (X or O), and they choose which one they're controlling by pressing R or L in the gamepad. The rest of the rules is just tic-tac-toe.

    Problems:

    - Readability. It's hard to know which piece you'll be controlling next.

    - Players can very quickly get into a stalemate, which is undesirable.

    Revised concept: Players are assigned a symbol type (X or O) and they control a hand that is coloured the same as the pieces. They can pickup any piece using the hand. The rest of the rules is just tic-tac-toe.

    As you can see, the revised concept solves stalemate and allows for readability. I would not have found this solution if I hadn't broken down the problem and then prototyped it, play-tested it and revised it.

    Design

    A design is a detailed description of a concept. Here, you detail every moving part as it will be implemented. Digging into each part of your concept will bring up questions and issues, once again, which you should be able to solve as you develop a better knowledge of the systems you're trying to build.

    A good general idea is to never reach out of your design space for new ideas, but instead, look into what the design itself already offers and move parts around, iterate them, play around with parameters. It's cheaper and faster. Generating completely new ideas to fix an existing problem just creates a whole new set of issues to solve, expanding the cost of transforming a simple idea into pixels that move on the screen.

Comments

comments powered by Disqus