I've noticed there is a lot of discussion about designer's end results and how it effects their current game-play. It's great, however I feel we are missing out on some very important discussions about game design as a whole. The process of how you get there is just as important as your final decisions on design. I myself have my own style of going about things, but It leads to roughly the same outcomes. Sometimes even a change in the way you go about designing and the thought processes behind it can lead to things you never knew you could come up with. So, what is your design process like?
I believe there are 3 core things to game design:
1 - Ideation
2 - Organization/Streamlining
3 - Macro-level
I generally tend to do them in whichever order fits the project I'm currently in (knowing fully that am constantly revisiting all 3 until the design is entirely completed and most likely, the project is done).
1 - Ideation, to me, is a lot about finding new ideas for mechanics or content of areas (objectives and functions) I've identified during another phase of design (generally in 3 - Macro-Level).
It is important to me that the very last thing I did before going to bed the day before is anchor that question to my mind, without any expectation (my short-term memory assimilates the problem, and through sleep, I'm able to turn that short-term memory understanding into a mid-term memory grasp).
On the following day, after taking care of whatever else, I reserve some time to do a specific activity that is not intrinsically productive, but that allows me to bring along a piece of paper and a pen. I allow myself to do what it is I do, focusing on it as needed, but I also allow myself to "have ideas" and I let them run their course. Sometimes, this will turn up an idea for whatever I'm trying to achieve. I'll write it down, as a bullet point, not trying to go any further than this (the bullet point should be enough for me to conjure up the idea later when I need to). More often than not, I end up with a piece of paper that lists some questions I'm trying to find an answer to, and a number of lines leading to bullet points on how to solve it (half of which are mere qualifiers, and the other half which are likely questions in the form of "Could this fit here?" or "Would this mechanic solve this sub-problem?"
Watching a new movie or TV series tends to work well here, because it forces me to look at various themes. I tend to make sure that whatever I end up watching has nothing to do with what I'm doing (not watching a space sci-fi tv series if I'm making a space game for example, I'd rather see a serial murderer drama to make sure ideas clash). Some things will stand out and can lead to a lot of "ignitions" in my brain. Preferably, I'll watch this from the living room, not on my computer screen, just so I can get a change of scenery (changing context is a good way to make one's brain creative).
I find that putting my brain in a context of "listening" instead of "thinking" is a good way to relax and let it naturally heal its creative juices. Because of my (human?) nature however, it doesn't take long before thoughts flow in organically.
2 - Organization/Streamlining
This is actually the best part of the work for me. When I know I'll be able to work for an hour uninterrupted, I sit down in front of my monitor, put earphones on and start looking at all these pages of ideation I've been producing. I pick them apart and slowly make a writeup of everything, as organized as possible. If I start to get a bigger idea of how these elements fit together, I draft up this idea, include these elements, and scratch them off the individual sheets.
I do this until I have a document that has a few pages, and nothing left to transcribe from these pages.
Then I start eliminating elements I feel are out of place, not necessary, are good ideas but don't answer one of the objectives, etc.
Oftentimes, the end result looks a lot like a new feature or two that I could implement, or a revised flow or control scheme for example.
This is screen-time at its most epic.
3 - Macro-Level
Once in a while, I gather up all of these streamlined feature documents, and I find a way to integrate them in the greater documentation of the project (GDD, or FDD). I do this perhaps once a week, and flush everything to a new iteration of that GDD (passing from v 1.3 to 1.4 for example). I ask myself a lot of questions, end up killing a lot of features, and generally feel very satisfied by the end result, no matter how much of the information I actually end up using: I like to think of it as a moment where I've killed a lot of questions regardless, and feel that much closer to the end product by doing so.
I tend to do Macro-Level on paper first, by looking at the individual documents I've produced (I print them, and I feel bad about the forest everytime, but it does work better) and once I have laid things out, then I go about making the actual edits directly in the GDD (most likely with a few annotated documents in hands).
I've obviously left out the "laying out the original skeleton" part, but I'll admit I'm not sure how this happens. When I was younger, I've been thinking about so many games that, for the past 10 years, everything has basically been a re-thinking of something I once wanted to do even when the concept doesn't come from me.
I do however have a steady progress towards a finished product. I don't tend to get stuck in the "doubt your creation" loop too long. I do challenge previous ideas when new ideas come in, but most of the time, it ends up with tweaks, not re-design. I'm open to let the idea flow of its own to make sure everything fits, but I'm also very specific about the components I'm missing and this provides me with clearer guidelines for design (and I feel more constraints makes it easier to be creative than the other way around) which limits my ability to go too far off the original intent.
Besides, there's only so much I'm willing to leave up to theoretical design itself, and I value gameplay programming and iterative development too much to spend too much time in design. Once I have a good idea of the general game concept and mechanics, we get to work and see, and tweak. I do my playtests in two different ways:
- Play on my own (at my home if possible, while everything is quiet and I can replicate my gamer experience setup)
- Watch people play (AFTER I've played myself, as I will have questions in mind I need answers to) - This can happen virtually anywhere there's a potential playtester.