How do you learn game design?

My question is how does a beginner learn game design? There are so many resources on the technical side of making games but so little in actually designing a game. Are there any good resources on this topic?

To learn this skill is it more about making as many small games as possible and just learning from your failures?
It took me 3 months to finish my last project and during that time I realized that I only learnt about game design the first 2 weeks of designing the levels. After that it was just polishing it until completion. Is it a waste of time to take a game to completion if you want to learn more about design? Should I focus less on polish and more on prototyping small games with set rules?

Sorry for all these questions but I think a lot of people new to making games are in the same boat as me. It gets confusing when most beginner tutorials are based on learning a language or a game engine completely skipping the design side of games.

Comments

  • I think you're asking the right questions and thinking about things in a good way! Let me try answer your questions...
    flobar said:
    To learn this skill is it more about making as many small games as possible and just learning from your failures?
    There is more than one way to learn game design, but this is IMHO the best way. Make a lot of small little things and learn with each one. Try ask a question and answer it with the prototype; then after it's been made, do a mini post-mortem and try see if you can answer the question. Basically, you want to be doing deliberate practice (there are a lot of resources on the net on this idea). If you learn something from a prototype then it's not a failure! Bonus points for approaching this like a science experiment :). Don't expect to make any money from any of these - they're learning experiences. Hopefully this is fun, designing games and making prototypes is basically what game design is - without a prototype you can never be sure a design is worth the paper its written on.
    flobar said:
    It took me 3 months to finish my last project and during that time I realized that I only learnt about game design the first 2 weeks of designing the levels. After that it was just polishing it until completion. Is it a waste of time to take a game to completion if you want to learn more about design? Should I focus less on polish and more on prototyping small games with set rules?
    If you want to learn to be a better designer in the shortest amount of time, then you should stick to just making small prototypes and seeing what you can do in a week or two. Just think, instead of 1 game in 3 months, that could be like 6 or more prototypes! As you get better you'll probably be able to get more done in less time too!

    Polishing a game is an important skill, but it's a different skill to game design. It also often runs counter to efficient game design, because as you polish something it becomes more difficult to make small changes. If you stick to just circles and squares, and you game is still fine like that, just imagine how much more fun it'll be when you polish it!

    As you start churning out prototypes, I predict you'll tend to gravitate towards a certain type of game that you enjoy making and seems to resonate more with players (don't try force this, it might take some time). You'll be able to re-use parts of earlier prototypes in newer ones, so naturally your prototypes will also tend to be more and more polished, but it won't take you more time or effort than earlier prototypes.
    flobar said:
    My question is how does a beginner learn game design? There are so many resources on the technical side of making games but so little in actually designing a game. Are there any good resources on this topic?
    There is no substitute for making prototypes yourself. However, sometimes a change of pace is nice, so here are a few resources I can find off the top of my head, but you're encouraged to do a bit of searching yourself and find what you like and is useful for you ;) Looks for the designers of games you think are well designed. Look for game reviewers that are able to dissect games and analyse them. Look for whatever you enjoy consuming, cause there's enough great stuff that it doesn't need to be a chore!
  • flobar said:
    It took me 3 months to finish my last project and during that time I realized that I only learnt about game design the first 2 weeks of designing the levels. After that it was just polishing it until completion. Is it a waste of time to take a game to completion if you want to learn more about design? Should I focus less on polish and more on prototyping small games with set rules?
    You basically answered your own question. If your goal is to learn game design, finishing a game is less effective a way to go about that specific target.

    There are many different and smaller goals in making games. And bigger ones too, that comprise of many smaller ones than it itself. Knowing which one you're looking to level up on is hard enough, once you (think) you know, it pays to focus.

    Many game making tutorials and such focus on technical things because one simply cannot practice game design without being able to make a game. Or, without being able to test their ideas. If you're rich enough to pay people to make your ideas for you, sure, jump straight into learning about game design only. But the rest of us has to start somewhere.

    Also, so many courses out there focus on not programming and technical skills first year. Most of them make boardgames first. It's a far easier technical hurdle to jump making bits of cardboard by cutting them out, than programming. And it's not a new concept - design institutes don't start first year teaching with Photoshop. They don't touch the computer for the first year and focus on fundamentals of drawing, observation and having an eye for critical design.

    Both making games and drawing/designing share the same DNA in that they're creative practices, and that means just writing about what you want to make and telling people is not going to be able to convey the thing you have in mind. Most of the time one is not even sure if the exact thing one might have in mind, but more importantly, being able to TEST creative output against real people other than yourself is the basis and key of iterative design.
    Thanked by 1flobar
  • edited
    Just wanted to add to this already excellent advice.

    I think @FranciousVN's response is almost perfect, and while I couldn't write a better response, I think there's a point he didn't emphasize enough.
    FrancoisVN said:
    Hopefully this is fun, designing games and making prototypes is basically what game design is - without a prototype you can never be sure a design is worth the paper its written on.
    A prototype is something that can be tested, and in order to test a game-prototype we generally get people other than ourselves to play them and we record their responses. Without a shit-load of experience its impossible to predict how people will react to our games (I still rely on lots of testing to make design decisions). The first thing I'd like to say is that if you're the only person who has seen your prototype, you probably haven't tested it.

    The other thing I want to bring up is that I believe the process, when most optimized for learning game design, is iterative.

    The best goal is to make a small prototype quickly, then to test it by getting other people to play it (particularly people who are inclined to give honest critical feedback) and then to try use that feedback to make it better.

    Of course, this will have diminishing returns, in terms of learning. As the game gets larger the adjustments will take longer and be of less consequence. You'll have to judge whether improving the prototype one step further is polishing it, or learning how to solve a new problem.

    A lot of the problems you'll have to solve in game design don't present themselves in the most minimal prototype of the game. A lot of the problems are in the interplay of more developed systems. Like, as a crude example, learning to make a well-crafted platformer doesn't teach you how to give the player satisfying progress through the platformer, and you almost have to have the platformer working before you can practice designing the progress.

    The point I'm making is that it's impossible to test your prototype without getting critical people to play it, but, even then, they're only likely to critique the most glaring problems in front of them. And you want to learn to fix not just those problems, but also the problems that will present themselves after the initial problems are out of the way.

    Put another way. Making a prototype and getting people to play it could be considered a test of your idea. But I think the more crucial thing to learn is how to fix the problem, and in order to do that you have to alter the prototype and get more feedback to test whether you've improved it.

    Just making a prototype and testing it and then scrapping it WILL NOT teach you how to fix it. It'll just teach you whether or not the initial prototype worked.

    Again, this iterative approach will eventually lead to polishing the game (as @francoisvn defines it). As the problems you're solving get smaller and smaller you'll be getting less reward for them. If you're trying to optimize learning you don't want to do any work that you've already practiced elsewhere and have already mastered, and you ideally want to learn to solve the most crucial problems first.

    I do believe the beginning stages of a game's development are the most crucial to master if you're trying to become a good game designer. There's no point in polishing a turd and all that. So you've got to learn first how to not design turds so you have something worth polishing.

    But it's very possible (even common) to turn a good initial prototype into a turd by making subsequent bad design decisions. So I suggest that you also practice learning to incorporate feedback (but be very precious with your time and try not waste it).
    Thanked by 2francoisvn flobar
Sign In or Register to comment.