Long title is long. I tried a few different titles, and they all failed to convey my intent. But before we get to my intent, some backstory.
One of the biggest hurdles I had to overcome as a system designer was my obsession with “efficiency”. I am a scientist. It defines everything I love about game design. I love knowing that a group of systems has come into perfect balance, and knowing that this balance leads to the funnest experience possible. God, excel can be mind-numbingly boring on a normal day, but I would be lying if said I didn’t seek out and choose tasks that revolve around using it, so as to find some kind of mathematical perfection.
Sometimes, though, it isn’t about the numbers. I have talked about this in the past, but why I am here today is to talk about a corollary to this problem. I hate the blank page; starting from nothing and trying to come up with something “cool” is very much my personal nightmare. I hate it. When I was first starting out, I combatted this fear and hatred with science. I would create rules and guidelines to help me get over this, and one of these rules was, “Focus on the most important feature(s) first, because if you can design that, everything else falls into place.”
This was dumb.
It doesn’t sound dumb. In fact, it sounds quite logical, but that’s the problem with logic and design. They don’t always play nice. Working on God of War I learned that the importance of a feature does not determine the order it gets designed. (Hey where have I read that line before?). Sometimes you get stuck. You can’t think of anything interesting, but you are sure you are supposed to finish this big important chunk, so you spend days thinking of a solution. Focusing on it like this is a great way to end up with logically cohesive systems that have all the excitement of an expense report. Here’s what I learned:
Don’t Force It
When you get stuck, design what excites you, regardless of the importance. If you aren’t pumped about what you design, I sure as hell am not going to be pumped to play it. Fact. The great thing about a well designed system is that all the pieces work together, so even if you are designing a small piece, you are still working on a piece of the whole. What’s more, as you work on these other features you will indirectly design the main feature.
You know what else? Don’t get discouraged if you can’t think of anything. You are not the first person to draw a blank, and you won’t be the last. If you try and force a design, it is just going to come out crappy. You can’t always logic your way to a solution, as much as your brain tells you it can. I cannot stress enough the difference this made in my life. I still hate the blank page. Fucking hate it. But you know what I hate more than a blank page? Designing something crappy.
Addendum: I feel this was not clear – probably shouldn’t write something at 2 in the morning. Starting with the big features is important, but just because it is important does not mean that it MUST be designed first. Becoming fixated on minor systems and ignoring major systems is JUST as bad. You must have balance in all things.
Allow me to give an example. Let’s say I’m tasked with creating monsters for a new game. You are going to have small, medium, and large enemies. The small enemies will have 2 variations, the medium has 5 variations, and the large has 3 variations. By the logic of importance, you should design the medium enemies first. It has the most variations, and will net the largest benefit. Let’s say, however, that you get through 3 of the 5 variations and you are stuck. You have NO ideas for the last 2. Assuming you have done your research, do not sit around waiting to get an idea, and do not try and force a solution. If you have ideas for the others you should immediately go work on those. The goal is not to be come obsessed, as I did, with what is the most important.
The key (IMO) is to always make forward progress. Different things have different priorities for a variety of reasons, but if you can spend some time on lower priority tasks while gaining perspective on higher priority tasks, you may end up being more productive overall.
There are also two axes of priority. One axis is the one which affects internal production, be it fixing crash bugs or making tools better. The other axis is the one which affects shipping the game. A great example showing the difference is the save game handling. You really need to have game saving and loading in to finish the game, and you can’t even sell the game if you don’t pass the various console manufacturers’ requirements, but it’s pretty unimportant to the early development of the game (I’ve personally implemented systems to do this from the ground up in the week before shipping, it didn’t seem to worry anyone that it was put off so long!). On one axis (development) that feature is unimportant, “implement if time.” On the other axis of shipping the game it is A+++ Uber Critical Showstopper.
Priorities of items can also change over the lifetime of the project of course. What is important today may not be important tomorrow, so it’s important that whatever you’re doing, you’re pushing the game (specifically knowledge about what you want it to be) forward. Ultimately there’s little real difference between Very Important Right Now and Kind of Important Right Now, so if working on a slightly less important thing can reinvigorate you, go for it!
I got my start in the game biz as the tools guy on a game team who ended up getting a lot of various gameplay and game system tasks too, so it was nice to be able to take a break from 3DS plugin programming to do some gameplay as much as it was to take a break from game UI to tweak the lighting tool. Variety is the spice of life, so live it up!
First, what’s up Tom! Miss working with you. Second, this is a wonderfully insightful addition, and definitely inline with what I was trying to get across, albiet in my two-left-feet kind of way. I think that there is a 3rd axis, and that is the difference between cerebral and mechanical tasks. The less cerebral and more mechanical the task, the easier it is to brute force the solution. The more cerebral the task the harder and harder it becomes to brute force a good solution, and therefore it begins to increase the likely hood that you should, as you say, side step the problem and gain some perspective.
Hey remember when I was a Tools programmer? Haha. Jailed Games for life.
Funny, I was just thinking about the blank page problem myself last night. I hate it too, it makes me feel like I’m back in the 7th grade trying to write an in-class essay and all I can do is stare at the page. There’s a really great quote about it that I can never remember. It essentially says to embrace the blank page, once you start thinking you are inevitably pulled in a direction. It’s difficult to let go and backtrack from something to nothing – the blank page is the best time to let your thoughts really go in every direction and consider all possibilities before bias sets in. Convincing my boss that I can’t force design though, that’s a serious challenge haha.
That’s why I doodle so often. I cannot stand looking at a blank page, but I find once it has a few squiggles it begins to lose its dementor stare. I don’t think I will ever get over my fear and hatred of the blank page regardless of all the little tricks I use. It is my experience that designers tend to fall into two categories: those who can start from nothing and see a new something, and those that can take a bunch of somethings and combine them in new ways.
I just find that I am the latter and not the former, which is totally fine.