On Independence Day, former colleague and game design intern at W!Games, Adriaan de Jongh, posted an interesting article about what he discovered were common game development pitfalls. When I read it the first time, I was impressed. Another colleague, a producer, also responded very positively to Adriaan’s post. When I took a look at it a second time, to see if I could come up with something he missed, I decided to write something about his article.

Now, Adriaan is still attending the same school as I went to, the Utrecht School of the Arts, which is why I was pleasantly surprised by his in depth observations on game development. And this is not just making obvious remarks, it really shows that Adriaan experienced these pitfalls first hand and that he has learned from them. Given that he has come to these conclusions so early in his career, and based on my collaboration with him at W!Games, I’m sure that Adriaan will come a long way in the industry.

On to the list then. Before I discuss all points separately, here’s an overview in the order Adriaan used:

• Entering production without something fun
• Start big, end up small
• Peer reviews not taken seriously
• Starting too late with playtesting
• Not enough games played
• Too much importance on design documentation
• Not taking advantage of placeholders
• Not keeping design documentation up-to-date
• No external playtesting

Before you continue reading, I suggest you take a look at what Adriaan said about these topics. I will not repeat everything he wrote, but rather focus on some aspects and add my own thoughts on why these pitfalls occur and how they can be avoided. Also, I arranged the order a bit so they fit my story better.

Entering production without something fun

Adriaan states that games that are not already fun before they enter production, will struggle to become fun during that stage. I think this is the most important pitfall of them all. If not for the primary reason of knowing that people will want to play your game because it is fun, then for all the secondary effects on the development process Adriaan mentions, specifically those regarding to the lack of a unified vision. Of course, creating that fun experience is the hardest task for a game designer and putting a time constraint on that creates the risk of stepping into this pitfall. The problem is, if you don’t, many people of other disciplines might end up having to wait, delaying the project. But isn’t that a risk worth taking, if the result is a cool game you can actually sell? I mean, if you can’t prove a game is going to be fun, you shouldn’t be making it in the first place.

Start big, end up small

The project’s scope is indeed usually bigger at the start than it is at the end. Especially during school projects, I noticed that people had the tendency to just put all the cool ideas in there, increasing the game’s size to unrealistic proportions. There’s nothing wrong with being ambitious, and coming up with cool features can be very motivating, but not if you’re going to end up having to remove have your game. Contrary to what Adriaan says, I think you should start big. It’s the creative director or lead designer’s job to prioritize and to set a clear starting point. That should be that ‘something fun’ as mentioned above, supported by a scope document describing a game that is up to par with the competition. If your design is modular and you have tech to match, you might not end up removing half your game. You could be adding cool stuff everybody was motivated to work towards. That is, of course, if time and budget wouldn’t put a stop to that.

Starting too late with playtesting

I can not stress this enough. The first thing I got to do when I started at W!Games, was set up regular user tests. Weekly, eventually. This indeed led to a more stable version and better end results, as Adriaan says and no one would argue, but I would like to put the focus on the very start of the project. The most common excuse I’ve heard is that there is nothing to test yet. Not true. There is always something to test, even if it’s just presenting your concepts to a focus group, or playing paper prototypes. Early playtesting is key to creating that ‘something fun’, with and for people that will buy your game. How do you know  for sure that your game is fun if the only ones who believe that are the ones making it? Another excuse is that there are too many things not done yet, assuming that the obvious will obscure any useful results. Also not true. Many testers will also look through the obvious, either because they know it’s not done or because they don’t care, and go right to the core of your game. And even if they don’t, I’m sure they’ll have something useful to say about the things that aren’t done yet. So, start early (if you have something to show your colleagues, you have something to test) and don’t stop until you have a Master build.

Peer reviews not taken seriously

I know the feeling of being too absorbed in your own work to see what’s going on with the rest of the game. That’s why it’s a good thing that most of my fellow designers notify me and others whenever they’ve made good progress or just have something cool to show. I try to do that as well, because I respect my colleagues and appreciate their input. If you’re not doing user tests, at least take your colleagues seriously. They’ve been hired for a reason, they play games, they know stuff. Put your ego aside and ask for reviews regularly if they’re not part of the development process already (they should be), both from your equals and superiors. You’re making a game together, so if they have ideas on how to improve it, you should listen. You might even become a better designer yourself.

No external playtesting

The examples Adriaan gives might seem funny, but he is absolutely right. Of course you assume that, as the greatest designer that ever lived, your design implementation works. Maybe it does, but after working on it for some time, you get used to it and lose the fresh view of a player new to your game. By bringing in external testers, with varying experience and characteristics but still somehow in your target audience, you get so many more and diverse views on your game. Maybe they’re not the observations of a professional designer, but they don’t need to be. You can get those using peer reviews, but what you need here is feedback on how actual gamers perceive and interact with your game. You need to test things like difficulty and pacing ‘in the wild’. The more data you have, the more you can distill from that. Your testers are not making your game and you’re still calling the shots. If you end up not using anything or just getting confirmation, that’s useful as well. And there’s another use for it I experienced first hand. Ever had to convince other people, other disciplines, that changes needed to be made to improve the game, without getting through? If your external testers come to the same conclusion, confront your colleagues with those results. User testing is not just for mechanics, interface or controls, it’s for your whole game. That means art and sound as well, even to see if your tech holds up.

Not enough games played

I agree strongly with Adriaan that especially designers should have played and continue to play a lot of games. You can actually see what works and what doesn’t, honing your design intuition and allowing you to give examples when necessary. Varied examples, preferably. I strongly dislike people that always refer to the same game or same developer when trying to make a point. Carefully noting all the factors involved in a design issue and knowing what game to learn from, both good or bad, is a very useful and required skill for a designer. You should be able to communicate all that verbally or on paper, but playing those games with the team is a good way to easily demonstrate what you’re talking about. I try to play as many games in as many genres as I can and I notice how I benefit from that in my daily job. If designers don’t have adequate experience playing games, you risk ending up reinventing the wheel or stepping into pitfalls that could have been avoided. Not only does a lot of gaming help you with specific design solutions, it also gives you a better view of the current market and your direct competition. In my case, I consider myself to be the target audience for most projects I work on, which helps a great deal in setting guidelines for my design work.

Too much importance on design documentation

Adriaan is talking about the start of the project here. The focus should be on trying out new ideas and proving a core mechanic, not on fleshing out an entire game on paper. It’s extremely unlikely that a designer will indeed get it completely right the first time, just by sitting in an ivory tower and crunching out a purely theoretical design document. As Adriaan states, doing and experimenting will not only prove or disprove your ideas, it can also lead to new ones and to what he calls ‘happy accidents’. That’s a pretty funny term. What he means by that, is that you may find your ‘something fun’ in something you didn’t design on purpose. As a designer, you should know what emergent gameplay is. Maybe it will pop up in your prototypes and if it’s cool, you’re still able to alter your design to better facilitate it. Setting up and maintaining design documentation is of course a good thing, especially when the team and the project get bigger, but that’s just for reference and should be based on experience rather than assumptions. Base your documentation on the first things you make, not the other way around.

Not keeping design documentation up-to-date

As mentioned above, design documentation should be usable as a reference. It communicates to every team member how things are expected to work and how the game will turn out. People losing faith in it is something you just can’t afford. If that happens, a lot of time has gone to waste and it will cost you even more. First because you’re going to have to catch up, second because people are going to ask you to explain it to them in person. Of course, it’s always a good idea to go through a new part of the design documentation with the people involved, so you know they understand and they know where to find the information they need and have a good starting point. But the game will develop and change, so the documentation will have to lead the way but follow as well. When deadlines are tight, updating documentation usually loses out to actually making the game and that’s when things could go wrong. Time should be alloted to work on proper and recent documentation, because what’s even worse than people not using it, is people using outdated information to build the wrong thing. To make it easier on yourself, just include the minimum information you need to eliminate any room for interpretation, using visuals and bullet points rather than walls of text. Leave out unnecessary details, like your views on how your design should be implemented technically. You’ll have less data to maintain and leave some much appreciated freedom for your colleagues. If how it should work is clear, leave the rest to them.

Not taking advantage of placeholders

I don’t have anything to add to Adriaan’s point here, other than how to avoid this pitfall. Designers just need certain ingredients to be able to test their theories and create initial implementations of their design. The more they can do on their own to iterate on certain parts of the game, the better. You don’t need finished models and animations to see if a certain mechanic works, as long as it has the ability to do what it has to do within the game. Sometimes that might indeed require specific visuals, possibly because the way something looks is part of the mechanic or the abilities of an object. So if artists won’t provide placeholders, either because they refuse or there isn’t any time, get the tools and learn the skills to do it yourself. You can also shop for something useful within all the assets that are already available.

Wrapping up: my own two cents

Adriaan’s list of pitfalls is quite extensive and useful for any game developer, not just designers. He covered pretty much all the pitfalls I’ve experienced and know about myself, except for one. I’m not surprised Adriaan didn’t mention it, because he probably hasn’t come across it yet and it’s not something school projects focus on. If you’ve read my comments carefully, you might be able to guess what it is. I’ve mentioned selling your game and your target audience a couple of times, so I would like to sign off with a pitfall specifically about that. And I must say that it’s getting more dangerous every day to step into this one.

Selling your game is just as important as making it

The game development process is very much goal oriented. At the end of the schedule, the game needs to be finished and shipped. But nowadays it’s not sufficient anymore to just put your game out there and hope for the best. Of course, quality will get you a long way and should always be a requirement for the game you’re making. But there’s so much more you can do to possibly increase awareness and sales, way before the game is even finished. Exposure is key. The more people know about your game before it comes out and know that it’s awesome, the more you will sell. How to get that exposure and fanbase is a whole different story, but the pitfall is to not account for this during the development process. By selling I don’t just mean getting people to make that transaction, I mean the entire process of them wanting and playing your game. There’s more than enough material you can use to get out there, start a community, and to get and keep people excited about your game and your studio. Your players are the key to success, not just the game. The more you involve them in the conversation, the more they will reward you. While it’s only logical to focus on production, with schedules and budgets and all, that conversation needs to be an integral part of the development process. Ignore your players, and you might have an even bigger challenge than delivering a game.