Posted On: 2017-01-16
Today I will write a bit about the general approach I use when creating a prototype. While I never followed this pattern exactly, it has served as good baseline which can then be adapted and expanded upon as needed.
The first step is an idea of a mechanic that I think would be fun or interesting. Many of the concepts for my bi-weekly prototypes are documented on the games' pages (available on the Design tab). I have a tendency to collect mechanic ideas in my day-to-day life, but for my prototypes I try to pick one that is within the scope of my technical abilities.
Before I can start developing the prototype itself, I have to create a basic skeleton for it. I try to focus on the bare minimum for the skeleton (an entry point into the application, a class for a level/background and a class for the player character, colored squares as placeholders for art) rather than a more complex architecture that will support everything I will need (save that for when I actually know what I need.) I am sometimes able to use a previous game as a template (for example, each of my prototypes made in Flixel used skeletons based on the previous game, with the original being based on the EZPlatformer tutorial, one of the first I read when starting with the framework.)
Once the application exists and when I run it I can see my placeholder character and background (solid color on solid white/black), I start working on how to control the character. For platformers, I usually don't yet have gravity, so if I do implement jumping, I avoid using it for now (requires restarting the game to get the character back on screen). For other games, I stick to whatever input is appropriate for that game type (for example, in Progress the "character" was a tile, and I coded clicking to select it at this stage.) While most/all of this code will get thrown away very soon, this stage is very important to do as soon as possible, both because control allows you to feel the game (rather than observing it) and also because control helps with debugging.
This is the good part. Everything up to this point can theoretically be copied from previous games (although less so if the player control changes), but this stage is where the game will start developing its own identity. All development at this point is centered on the single, fundamental core mechanic. Often, the core mechanic is something simpler than the mechanic concept (in TableFlip it was the flipping mechanic, but in A Robot Named What it was moving a robot composed of several smaller parts). During this stage, I am trying to achieve the core mechanic, but I will always keep a critical eye on when the mechanic is not working. If I am running into a ton of bugs or if it is just not feeling the way I want it to, this is my chance to throw out my assumptions and iterate on what does work. Even if the core mechanic changes, even if the game is no longer what it was supposed to be, this stage is only complete once I smile during a play test.
Now that the core mechanic works and at least feels slightly good to use, it is time to refine it. This can be directly changing the code of the mechanic itself (for example, adjusting acceleration) or changing some supporting system (such as adding platforms to the background level). This stage also can see some minor tweaks to the placeholder art as well (for example, adding a simple animation to telegraph timing). The goal of this stage is to get the mechanic to the point where it definitely feels right, no matter what needs to be added.
This is the first of the optional stages, but it is still a very important and powerful one. For this stage, I create a sprite for the player character (if applicable) and a tileset for the background. While my artistic skills are limited, I try to focus on communicating the visual aesthetic. This is important, because the visual aesthetic needs to complement the mechanical aesthetic: the way the player feels looking at the game will play a role in how they feel while controlling it, and it is important that they work together to create the right experience. It is also worth mentioning that I recently realized this stage is important even if you have an artist to support you: there are a variety of visual aesthetics that the game can support at this time, and this is an excellent way to communicate which you think best complements what the game wants to be.
The second optional stage: at this point I typically add levels, powerups, and enemies. The goal of this stage is two-fold:
In platformers in particular, I find this is an excellent stage to add multiple levels, to get a feel for how deep the existing mechanics are. (For example, in TableFlip I added quite a few levels, and discovered that the design space was surprisingly deep, but difficult to harness. The tighter and more challenge-focused level design was difficult to get right, but allowed for a much deeper experience than I expected. The more open and expressiveness-focused level design was easier to create, but felt less satisfying to play. It turned out the goal was an important design element, one which the challenge-focused design embraced. This insight is something I intend to build upon as I turn this prototype into a complete game.)
I often forget this stage until I am preparing to put the game on my site, so I am including it here. While not necessary for investigating mechanics, I have received feedback on a few occasions that not being able to exit or pause is detracting from the experience, so I am trying to remember to include these features. Ideally, I could have these available as part of the skeleton template, but since I am still experimenting with different frameworks, the opportunities to do that are limited.
That is my prototyping process in a nutshell. As mentioned before, I have never quite matched that process exactly (stages would sometimes bleed between each other, or I would leave out an optional stage.) Hopefully my process is helpful or at least interesting.