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:
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.
No comments:
Post a Comment