I recently started developing my next game, Shade. The fundamental gameplay was outlined by Lost Garden but there are still a lot of unknowns. The truth is, for any game there are a lot of problems which will not be fully understood until further in the development process. For instance, in Shade the player moves around obstacles to collect mushrooms. The mushrooms only grow in shade cast by the obstacles. What should the obstacles look like? What makes collecting mushrooms fun? Where is the challenge? Sure, you can take a shot at answering these questions on paper, but it’s incredibly hard to say which answers will be fun and which will be boring. At times like this you should consider adopting an iterative development cycle.
The goal of an iterative development cycle is twofold; reduce the amount of planning you do upfront since it will prove useless anyway and close the feedback loop as much as possible. The first point is really straightforward. Games are complex, too complex to correctly plan for ahead of time. Obviously, it is possible to plan some things ahead of time. (Ahem, design patterns help.) However, experts have been saying for a long time that we regularly misestimate the costs of software development. If you accept that your best efforts at planning are likely to be moderately flawed then the natural conclusion is to spend less time laying out a complex high level design and factor additional time into your schedule for responding to errors and feedback as they arise.
And feedback is really the key to everything. How do you answer the above questions? You start out by picking the best possible answer and implement it as cheaply as possible. If it holds up empirically then invest more time improving it. However, more often than not an idea doesn’t pan out. In that case at least you failed quickly. Since you’ve identified the problem early you can fix it before it becomes embedded into the larger system.
Real World Example
That said let me give you an example of how this plays out with a real game.
This is the first mock up for Shade. At this point I had a really rough idea of what I wanted things to look like. Mostly, I was working off of the mock up provided by Lost Garden. I knew that I wanted shadows, some sort of score counter, and several different game objects. However, a quick glance reveals that this is going to be one boring game! Still, I learned several things.
- Shade takes place on one screen
- The perspective is pseudo 3d
- Lost Garden’s mock up had a lot of things I didn’t want
- More obstacles are needed to create a better shadowscape
- Rectangles are easy to draw but boring, I needed some more shapes
- If the player was really going to try to stay in the shadows I needed to enable that in the shadowscape
Not surprisingly, I wasn’t satisfied with the last mock up. So I went back to the drawing board. I also wanted to improve on the perspective. I moved the viewpoint slightly to the right which I think greatly improved the game’s look. Probably the biggest improvements in this mock up is the fence. Fences help break up the monotony of the green objects, have an interesting shadow, and create runs of shadow. I also really liked the dome-like objects. Once I completed the second mock up I was really happy with the look of things — I wanted to get coding! However once I started thinking about the perspective and the shadows I realized I probably can’t code this!
Since I have to be able to code this game I decided to try again. This time I wanted to simplify things technically. So I opted for a top down view. At first I thought this was going to be terrible. Top down? Boring!
However, once I started putting down shapes I thought things might work. I brought some of the best ideas from the previous mock ups with me, including fences and cool domes. I also started to experiment with some more interesting shapes. It turns out it was easy to combine shapes for a fun effect. In addition, during the course of this mock up I started to think about how the level should work when played across each axis.
Until this point I had been thinking about the gameplay mostly along the north-south axis. However, now I realized that when the sun was at a different stage the shadows would be along the east-west axis. In this case the shadowscape would be totally different and potentially no fun at all! With that in mind, I tried to create a world where the shadowscape would be interesting along both axes.
Conclusion
So where are we? The final mock up is pretty good, but there’s a lot of unanswered questions. Most important is whether the layout of the obstacles will lead to a fun challenge. However, before I start in on a fourth mock up I need to write some code. At this point I’ve gotten my return on investment with mock ups and I need to test things empirically. After I’ve settled a few questions about layout I can continue mocking up additional gameplay mechanics. What about clouds? Does it ever turn to night? What about bushes and other types of plants? Before exploring these avenues I should verify that the fundamentals outlined in the mock up are fun.
One Last Thing
If you’re interested in Shade and want to help with the development process in any way please come on down! Shade is open source and the code can be checked out and modified by anyone. There’s also a wiki documenting Shade’s gameplay, so if you think you know how to make Shade better then leave some feedback!
Related Posts
Hello, my name is Alex Schearer. I grew up in New York and currently live in Seattle.
Game Design and Iterative Development
I recently started developing my next game, Shade. The fundamental gameplay was outlined by Lost Garden but there are still a lot of unknowns. The truth is, for any game there are a lot of problems which will not be fully understood until further in the development process. For instance, in Shade the player moves around obstacles to collect mushrooms. The mushrooms only grow in shade cast by the obstacles. What should the obstacles look like? What makes collecting mushrooms fun? Where is the challenge? Sure, you can take a shot at answering these questions on paper, but it’s incredibly hard to say which answers will be fun and which will be boring. At times like this you should consider adopting an iterative development cycle.
The goal of an iterative development cycle is twofold; reduce the amount of planning you do upfront since it will prove useless anyway and close the feedback loop as much as possible. The first point is really straightforward. Games are complex, too complex to correctly plan for ahead of time. Obviously, it is possible to plan some things ahead of time. (Ahem, design patterns help.) However, experts have been saying for a long time that we regularly misestimate the costs of software development. If you accept that your best efforts at planning are likely to be moderately flawed then the natural conclusion is to spend less time laying out a complex high level design and factor additional time into your schedule for responding to errors and feedback as they arise.
And feedback is really the key to everything. How do you answer the above questions? You start out by picking the best possible answer and implement it as cheaply as possible. If it holds up empirically then invest more time improving it. However, more often than not an idea doesn’t pan out. In that case at least you failed quickly. Since you’ve identified the problem early you can fix it before it becomes embedded into the larger system.
Real World Example
That said let me give you an example of how this plays out with a real game.
Since I have to be able to code this game I decided to try again. This time I wanted to simplify things technically. So I opted for a top down view. At first I thought this was going to be terrible. Top down? Boring!
Until this point I had been thinking about the gameplay mostly along the north-south axis. However, now I realized that when the sun was at a different stage the shadows would be along the east-west axis. In this case the shadowscape would be totally different and potentially no fun at all! With that in mind, I tried to create a world where the shadowscape would be interesting along both axes.
Conclusion
So where are we? The final mock up is pretty good, but there’s a lot of unanswered questions. Most important is whether the layout of the obstacles will lead to a fun challenge. However, before I start in on a fourth mock up I need to write some code. At this point I’ve gotten my return on investment with mock ups and I need to test things empirically. After I’ve settled a few questions about layout I can continue mocking up additional gameplay mechanics. What about clouds? Does it ever turn to night? What about bushes and other types of plants? Before exploring these avenues I should verify that the fundamentals outlined in the mock up are fun.
One Last Thing
If you’re interested in Shade and want to help with the development process in any way please come on down! Shade is open source and the code can be checked out and modified by anyone. There’s also a wiki documenting Shade’s gameplay, so if you think you know how to make Shade better then leave some feedback!
Related Posts