A few thoughts on game design methods

Introduction

Last year on Digital Dragons I had the pleasure of listening to a lecture by two of my colleagues on quest design in Witcher 3. Being a producer by trade and a wannabe designer by heart, this lecture raised a lot of questions in my mind, and I thought to myself that it would be great if I could talk to my colleagues for couple of hours on their approach to game design. So I shared this idea with them and couple of other designers after the lecture, and together we came up with the concept of a design panel. I invited Jakub Rokosz and Karolina Kuzia (Fool’s Theory), Marta Przystolik (Yager), Błażej Zając and Maciej Izworski (IMGN.PRO) and Damian Wyśpiański (Anshar Studios) --all game or level designers with years of experience--to my cabin in the woods (literally), and we had a great discussion on the current state of video game design, trends, good practices and so on, for over five hours. Of course we covered many standard conclusions, techniques and observations--the kind that you can find in many “do’s and don’ts” on video game design, such as the benefits of bottom-up design vs top-down design, the importance of clear vision, which is usually provided by one person, and so on. At the same time, however, we tackled several fresh and interesting topics as well. Below you will find a list of these topics, but keep in mind that this is a stream of thoughts and one point will not necessarily follow the other in succession. Nevertheless, all of these observations were made by experienced people in the industry who know what they are talking about.
 

The design talk at Digital Dragons that inspired the panel

Scope framework

After preproduction, when you already have a pretty good idea of the story and the core mechanics of your game, it is time to determine the scope of the game. When you approach a new project, there is always this uncertainty of how big of a game this is actually going to be. Therefore it is a good idea to slice the scope of the game into manageable pieces. Many games have those pieces automatically defined by genre; for example, a platform game has levels, a RTS game has maps or missions and a storytelling game can be cut into chapters. Even if your game is about a guy walking down a long corridor, at one point you must decide how long this corridor is going to be, slice it into pieces and create a design for each piece. Assuming you are slicing your game into more or less same-sized pieces, you can then estimate the size of your game and how much time you need to create it. You can playtest each piece and so on. This is the only way to have a solid grasp on the scope. For instance, when I was working on a HOPA genre game for CI Games a couple of years ago, we sliced every project onto logical bubbles, which were usually geographical locations. Since each location had a couple of hidden-object screens, we could work our way from estimating the time we needed to create a single screen and then to create a location, to determining the number of locations we wanted in the game. In this manner we were able to estimate how much work was required to complete the project. Such pieces can be locations, characters, missions, quests, maps or whatever logical element fits your game best. You can do it with any genre, though some are tougher than others to cut into pieces, but in the end you need to do this if you want to have any control over the scope of the game.

Fallback implementation

CD Projekt RED presented an interesting approach to feature creep during the creation of Witcher 3. Though the main character’s basic abilities were established early on (he can fight, use witcher signs and senses and talk to people), a quest designer would often come up with a great idea for a new feature that would fit perfectly into the story. For example, one of the designers thought it would be cool to add an ice skating mechanics to a boss fight while playing Ciri; the team even implemented a prototype of such functionality. However, the team decided to cut this mechanics in the end and not add it to production, so the fallback for this special feature was simply a normal fighting mechanics during that particular boss fight. When you come up with such an idea, it’s hard to let go. After all, you want your quest to be the best possible experience. So the feature goes on the task list, but you have no guarantee that it’s going to make the cut. The deadlines are harsh, and many other things are waiting in line, so you must implement the quest with the assumption that the special feature will not be made. You therefore implement your quest with the standard mechanics of talking / fighting / using signs / using witcher senses that you are sure will be in the game. It sounds redundant, but it’s actually amazing production-wise. It’s not that time-consuming to use the same mechanics like every other quest, and if the special feature actually gets made, you can incorporate it into your quest. And if it doesn’t make the cut, then you are covered because you already have the fallback implementation. The important thing to remember is that, even though the fallback implementation won’t be extra awesome, it should still be of the same high quality as the core mechanics. The fallbacks are usually all the mechanics you already have in the game and they revolve around your core game idea. And your core gameplay should be cool anyway, right?

Creation by exasperation

It sounds harsh but it’s actually a very subtle technique of influencing other team members and making sure that everyone is aware of the state of the level design, to be specific--the missing pieces of it. When you come to a place in your level design, in which you are missing an art piece or a programming feature that everybody already agreed is required for this level, put a big box, for example in a shiny red color, with text on it like “Here should be the dragon fight scene”. It doesn’t matter if it’s a big yellow sphere or a big red box; what is important, is that it becomes the elephant in the room, explicitly pointing out missing components. You are planting a seed. Everybody sees the box in every review, everybody knows that there will be a dragon fight there, and everybody expects the dragon fight scene to appear there someday, and even during crunch time, during tight deadlines, someone at some point will become exasperated from seeing this big red box and will deliver the art piece or feature, for which he knows that he is responsible. And there you have it, creation by exasperation. Techland actually used green- colored boxes for this technique during Call of Juarez production.

Focus tests done wrong

Nobody can argue the positive impact of watching gamers play your game and then asking them about their experience. However, the problem with some focus tests, especially when you hire other companies to do them for you, is that the designer of the game is not included in any way in the process. Usually it’s a production and sales thing. The design people do not get to create any questions for questionnaires and they do not have the opportunity to interact with the player during or after focus tests. From a designer’s perspective, the test results are rarely surprising, since such focus tests are intended only to make executives and salespeople feel better about the future of the product.

Usually it goes like this: you receive feedback that players did not enjoy a particular element on your level, and your response as a designer is, “You don’t say! I also get frustrated every time I play that part.” The reasons differ: maybe as a designer you are waiting for a feature, or you didn't have time to fix it, or you were overruled by somebody and prevented from fixing it. Usually however, you know which parts of your game are bad and which are good, because you play your game A LOT, and if somebody is frustrated with an element while playing your game for ten minutes, imagine how frustrated you are as a designer when you have been playing that part dozens of times.

Don’t get me wrong; I’m not saying that focus tests are useless. They are indeed a very powerful tool, but only if the designers are included in the focus test preparation process, so that the results will not be like something from “Captain Obvious”.

Play your game

It sounds simple and obvious, but the extent of it may surprise you. You can even spend up to fifty percent of your work time playing the game you are making, and that’s okay. It’s not an exact science, for the time you spend playing your game depends on the genre, but playing your game should always be a meaningful percentage of your development time. This goes back to the previous point about focus tests: the reason why focus test results are usually obvious to designers is that the designer is playing the game a lot. He knows exactly where the most frustrating moments of the game are, because he is frustrated himself every time he needs to play through them. Playing your game a lot gives you the gamer’s perspective and helps you determine if the player is going to have fun. From my experience, game designers hate to play their own games--I know I haven't finished any of the ones I’ve worked on--but you must force yourself to do it, not only to quickly test if the thing you are working on right now works, but also to put yourself in the player’s shoes every day, not just during milestone reviews.

Drop yourself from a cliff

One of the most interesting conclusions of this panel was the answer to my questions: "How do you know that your game design is good? Do you do focus tests? Peer reviews? How can you be sure of your idea no matter what others say?" The truth is, at the time I was a noob creative director of our project "Detached" and I was looking for confirmation that our project made sense. That’s actually one of the main reasons I organized this panel, and the best part is that my charade did not work, because the conclusion was that you usually don't know. There are hints of success, though. If your team is passionate about what they're doing and they discuss and argue how to make the game better, you are probably going to have at least a solid title. If focus tests and peer reviews are overwhelmingly positive you probably have a hit on your hands. Of course there are genres that are harder to examine in a short period of time, like storytelling-based games, e.g. in The Vanishing of Ethan Carter playtest it would be hard to appreciate the story, so you could probably only judge the art. For some games it's easier: there is a rumor that Blizzard senior executives were sure of Hearthstone’s success because they had to order teams not working on the game to NOT playtest it during office hour--nobody got any work done; everyone was playing. That's a very good indicator of upcoming success. If you're having fun just playing a white box prototype, it's probably only going to get better. But those are just hints, and especially if you're doing something very fresh and innovative, you can have very few success indicators other than sheer belief in your own idea. You simply need to drop yourself from a cliff and do it; just remember to have fun (and work very hard) along the way. As a developer you are usually already a hardcore gamer who plays a lot of different kinds of games. You may be frustrated with your project because you have put so much work into it, but if you are still having fun playing your game in spite of that, you are on the right track.

Stop complaining about lack of tools (or at least complain less)

It’s always awesome to have good tools. On the other hand, lack of tools can be a problem. Nowadays, however, with technologies like Unity/UE4, visual scripting and a lot of free software, mods and expansions available, it's becoming harder to use “lack of tools” as an excuse for laziness. Sure, programmers are still very important, and some situations simply can't be handled well without a good tool, but there is SO much you can do on your own these days - so just do it. Iterate, prototype and expand on features using tools available to you, learn a script language if you have to, but don't stand around waiting to be served by a programmer. Try to go forward yourself. But the tricky part is to know when you are savvy and self-reliant, and when you are hacking the system and making a mess. When in doubt, consult a programmer if you are on the right course; he will be glad to help you out, if not out of goodness of his heart, then because of the fact that he will have less work to do developing tools for you, when you are handling it on your own.

There is no true innovation

Everything has already been done, if not in video games, then in movies, books or other media. Your ability to be totally innovative is usually hampered by lack of awareness of your own inspirations. Don't be afraid of inspirations and do a solid research of the topic you are designing. Research books, movies, games, comics and any other media that revolve around the topic of your game. For example, if you wanted to create an action game based on Batman IP, you would read the comics and novels and review the movies and other games. Then you would think about the best parts of Batman IP and try to incorporate them into your game, while also trying to improve the parts that weren’t good. Last but not least, remember that you can also draw from your own experiences. Have a funny memory of a drunken party as a teenager that fits right in the storyline of your game? Use it. Those authentic experiences can add an incredible flavor to your game because you can incorporate the exact emotions you had when experiencing them.

Obvious but maybe useful list of hints

As I mentioned before, we talked for a few hours and many conclusions seemed quite obvious, but as a noob designer I still find such a list useful, without having to explain each point in depth:

Thanks to Jakub Rokosz and Karolina Kuzia for helping me put this text together, and to the rest of the panelists - Maciej Izworski, Marta Przystolik, Damian Wyspiański and Błażej Zając, for accepting my invitation and having this great discussion.