Game Design Debts Part 2

Better sooner than later

In the last part of this little series I discussed the topic of game design debts and provided some examples. If you haven’t read it you better check it out so you have a clear understanding of what I mean when talk I about game design debts. In this article I will present some more examples where you may face possible design debts.

Providing no good tools for your designers

As soon as your game benefits from content you better invest time to provide your designers tools that are good enough to produce that content. The better the tools the better your content will be. Make it as easy as possible for your designers to build levels, scripts, new spells, or whatever kind of content your game will feature. Content design is also some kind of design and I think that every form of design benefits from iteration. When content creation is easy and fast it is much more likely that your content designers will produce better content as they can iterate thorugh the different versions more quickly. Your tools should provide the possibilities to design and prototype something as quick as possible. Tuning your game until you hit the bulls eye of the different attributs ain't easy. If you have long waiting time between the design of your content and playable prototypes, your content and level designers have a lot less tries to produce high quality content. If your team is able to you should keep this in mind and talk to your programmers about this problem from the very beginning so they can plan their tasks and software architecture the way that content creation in your project is as quick and easy as possible so your designers can iterate as effective as possible.

Programming these tools costs time but it will quickly pay off as soon as your content designers can create content independently from programmers in a quick and meaningful way.

Not planning the tutorial

If your game will feature a tutorial you should keep its unique code and special implementation in mind. Tell your programmers as soon as possible what kind of features your tutorial will probably need. I have already faced it two times that the programmers heard too late about the specific requirements from the tutorial and huge workarounds were needed to implement it the way that we wanted it. We could have saved a lot of time if our programmers would have known about these demands for the tutorial from the very beginning and plan the resulting requirements before the most features were already implemented. The requirements were often so unique that our code wasn’t able to provide these features without huge workarounds. If our programmers would have known about these requirements from the very beginning it would have been a lot easier. From now on we will try to talk about the needed features we for the tutorial as soons as we plan our production code. We didn’t have the possibility yet to see if this approach will work but we hope to save a lot of time in the future this way.

Doing playtests too late

Playtests cost time but they will give you valuable information if done right. When you strive for high quality you better start doing playtests soon enough. That means that your have enough time to react to the information that you gain through your playtests. Doing no playtests can cause a loss of so many possibilities. So plan your playtests as soon enough. Try to know what you want to find out and keep your eyes open for surprises. When you do your playtests too late you may miss the chance to react to the rising information which is already bad enough, if you don’t do them at all you will miss a lot more. Playtests don’t need to be as time consuming as you may think. In the very beginning you can do internal playtests with co-workers. These are fast and easy to perform but sooner or later you should invite players that are part of your target group and let them play your game. There are a lot of information about good playtests on the internet. I will link this article that contains a video and hope that you may find it insightful: How to make your game better with playtests the uncharted way

Doing too little research

Research is important. Research is not about stealing ideas from other games it’s about deleting unknowns as soon as possible. When we made our first f2p game we had no idea about f2p. We had no idea what a good f2p title needs to have a chance for success. We just made what we thought would be fun and when we were done we tried to find a good way to sell ingame items to our players. As you can imagine we failed. Do your research in the very beginning. The more you know about the market and  a lot of different games that you could learn from the better. Don’t do mistakes that can be avoided because you think research is a waste of time or you may already know everything. When it’s done right it can save you a lot of time and money. You even raise the chance that your game stands out as you may see possibilities that you may have missed without doing your research. I already wrote about research for game designers so you may take a look at this article: We don’t know what we don’t know: The power of research.

I hope that you enjoyed this article. I don't know if I'll continue this series but I hope that the already mentioned examples are helpful and protect you from some mistakes.

Game Design Debts - Part 1

Better sooner than later

Technical debt is a metaphor that is used to describe the act of choosing a quick and easy solution for a programming task to save time that may (but doesn't have to) cost you much more in the long run. Sometimes this tradeoff can make sense if you don’t have to live too long with your chosen solution but if not, you will have to pay it back including the interests.

I think that in Game Design you have a similar concept where you sometimes have to pay a lot more for the “interests” by making short-term decisions without thinking about the long-run costs. Sometimes it can make sense to go for the short-term solution but often it doesn’t. My examples won't be exhaustive but in the following blog posts I will try to describe different examples that I experienced so it may help you when encountering them.

Not defining clear goals for your design tasks

Sometimes you have to design things without really knowing what they'll be good for. Their purpose is too vague and was never clearly defined. You think about all the cool stuff that you can add without thinking why you should add it. I think that everything you’re designing should have a clear specific purpose that is formulated so you can control your results. Sometimes you just want a specific feature because it fits the fantasy. Then it may be cool to figure things out but sooner or later you should know why you want the different features in your game and what you’re trying to achieve with their design. So ask the following questions:

• Why do I want this feature?
• What do I want to achieve with this feature?
• How can I achieve these things with this feature?

By answering these questions you can make sure that you do not design features without good purpose. I tend to make a short document where I brief myself about the goals for a specific feature. For further reading check my other blog post about Goals for you Game Design

Going into production without “fun”

To be honest I can’t think about any scenario where this behaviour makes sense so it may be a little off topic but it is so important and I've experienced it myself once and heard about it so often that I have to mention it. Going into full production only because everyone should be working on a project just doesn’t make sense. So many projects start to work with a full team on a game that isn’t fun in its core and finding the fun when already 40 people or more are working on it is really expensive. Finding fun requires iteration and iteration means throwing work away and rebuilding things. And that can be very expensive and really hard to do. It demotivates almost every team member, it costs a lot of money and it is very hard to predict how long you have to iterate until you find the fun in your game. So do your team and yourself a favor and find the fun before going into production. For further reading check the following:

Why Games Fail: Pre-Production

Spore: Pre-Production Through Prototyping

Extra Credits: The Pre-Production Problem

No regular feedback to the developers that are implementing your feature

You may you save time by hoping that the developers will implement your feature as it is communicated in your documentation and if they do you’ll really save some time. But to be honest, chances are high that this won’t be the case. I think that there will never be some kind of documentation that every programmer in the team will read. Or maybe you missed something in your documentation. Or they didn’t understand something the way you meant it. Communicating with the other developers on a regular basis about the features they are implementing may cost time but it will save you a lot in the long run. Just ask them when they are able to show you something. This has nothing to do with controlling their work and you should not communicate it that way. Mistakes happen and it is nothing personal. If they miss something, remind them kindly. If you missed something in your documentation update it and make sure that the developers know about it. Maybe you can see flaws in your design just by taking a look at an early state of your feature or the programmers struggle with the implementation because of a specific requirement and have an idea that has the same result as your desired design and is much easier to implement. There are so many possibilities that you may miss when you don’t communicate with your co-workers that have to implement your designed features. Take your time and and talk to them when you have the chance. Everything will be much smoother and easier. And even if everything is fine and complete you can just praise their work and be happy to see how your design comes to life. Almost everybody likes to hear a compliment and it raises the motivation.

Not thinking about edge cases before implementation

This happens quite often. Your feature is designed, everything is somehow documented and it just needs to be implemented. And then some day a programmer comes to you and asks how something should behave in a certain scenario you didn’t think through. This can happen but it should be avoided as good as possible. Think about all the different possibilities where you may need custom behavior. How does your XP-bar looks like when your player reaches max level? How does your highscore behave when two players have the same score? These things happen often and you should think about a solution before the other developers start to work on the feature. If you missed something and the other developers come up with questions don’t rush and give a quick answer because you want to appear prepared and cover your ass. Tell them that you’re sorry and didn’t think it through. Ask them if they can keep working on the feature and avoid this edge case until you come up with a solution. Just do not rush. Take your time, think everything through, you may talk to your programmers about which technical solution would be the best and after considering all the different aspects you can make your decision. Update the documentation and communicate your solution so the feature can be completed.

These were my first examples where you may face game design debts. I experienced everyone of them in my work and I’m pretty sure that other designers had similar situations. I hope it will help you to not make the same mistakes as I did. The next blog post will featuremore examples that I think are pretty common in game design.