Torque Game Engine DocumentationVersion 1.3.x
| Torque Game Engine Documentation Version 1.3.x |
At this point, you have a working, first-pass at your gameplay design. That is a big step, and you should be happy about it.
Now, you have decisions to make. You have to harshly evaluate your game design. Does your prototype have potential? Can you see it growing into a truly fun, engaging game? If not, don't feel bad-- sometimes it takes ten crumby game ideas before striking gold.
If you can see that your game idea will be fun just by playing a mock-up prototype, then it's time to celebrate. You're well on the way to creating a successful game.
Next, you'll start iterating through these development steps again, working toward the final game.
What does it mean to iterate your development? To iterate means to repeat. Essentially, you'll need to go through the steps in this guide many times. Once you have your first prototype, you'll need to re-visit your game design, and make any necessary adjustments. Then, you'll need to do a more detailed pass at identifying what technologies will be required to build a more detailed and refined prototype. With that in mind, you'll have to figure out the best way to build those technologies again. Then you'll need to build your second prototype, and continue on again from there.
Let's take a little closer look at this idea:
Refine--
The fact that you got to a prototyping stage very early means you can start refining your gameplay right away. If you do just one prototype and discover that your original gameplay designs play perfectly, you are either delusional or extremely lucky.
In any other case, your first prototype will help you begin understanding which parts of your game design work, and which don't. With a working prototype to build from, you can much more quickly test out other gameplay ideas.
Begin iterating--
Most projects have to go through the steps outlined in this chapter a number of times, getting more detailed and refined with each pass.
Each time you prototype an idea or technology, you'll have a better and better idea of which parts of your design work and which don't. You'll know which parts are most essential, and which you can do without. You'll discover new things you absolutely need, and cull things that you really don't.
This process will help you make your gameplay better, and the same process will benefit your technologies-- you can try out multiple code designs and implementations, and see which works best, refining and polishing with each pass. The same benefits will be conferred to your art content, and all aspects of your game.
Finalize--
Finally, after prototyping, testing, and refining many times, you will arrive at a gameplay design that plays well at the prototype stage and is supported by solid technology.
This process of repeatedly testing and refining ideas through rapid prototyping is an example of iterative design. This development model is powerful, especially for Indie game developers, where getting the fun factor down-- and getting it down as quickly as possible-- is extremely important.
Once you reach the point where your gameplay is very solid in the prototype, realize something pretty amazing: you have a game you know you can make fun. You'll have working proof.
With that, you can confidently move forward, building the final versions of your code and other assets, assured that your game will be fun, and so will have the best chance at success it can. As you develop your game, you'll move through the standard game development phases, incorporating alpha and beta tests, finalizing art content, identifying and killing bugs, and finally... shipping!
Iterative design was absolutely essential to Marble Blast's rapid development. At each stage, we critically evaluated the game and constantly asked what was core to the gameplay, and what was just getting in the way.
As discussed above, multiplayer was cut from the game design after the first prototype. This was an example of a gameplay idea that probably would've been very fun, but that would've taken too much work to really pay off. As such, we decided to cut it entirely, even though it was painful to do so.
We made revisions in later iterative passes as well. At the second prototype, several things got cut.
Gameplay revisions:
Terrains:
We had terrain-racing in the first prototype, and it worked well. By the second prototype stage though, we started to question the idea of racing on terrains. The curvy DIF surfaces we prototyped were proving much more fun to race on than terrains. We decided that the game would be better off without support for terrains, even though it would take almost no development time to finalize the terrain-racing technology.
As it turned out, this decision offered a surprise benefit. With no terrains to worry about, we were able to unconstrain our level design. Suddenly the idea popped up... "hey, what if our levels were set way up in the sky?" We prototyped a sky-high level, and the fun factor was obvious. Part of Marble Blast's excitement comes from racing through levels that are poised high in the sky, where the risk of falling off the tracks seems scary (even if you are just a marble).
Cutting terrain helped us come up with this idea, and we didn't lose anything because prototyping revealed that racing on terrains just plain wasn't as fun as racing on the DIF surfaces.
 Terrain racing was possible in our earliest prototype. |  But racing on terrains didn't look like it could ever be as fun as racing on the crazy DIF-formatted geometry we could create. |
Checkpoints:
We cut another gameplay system in the second prototype stage as well. Originally, Marble Blast was designed to include checkpoints. When the player reached a checkpoint, their progress would've been saved, allowing them to choose to begin again from that point.
The checkpoints could've been used as in many arcade racing games as well, where the player had to reach each checkpoint in a certain amount of time. This seemed like a great idea, we could create long, complex levels, and we could use the checkpoints to make failure less frustrating, and give beginners some mini-goals on each stage.
After the second prototype though, we started to question the usefulness of this system too. As with terrains, the checkpoint functionality was easy to implement, so development time wasn't a concern. We just began wondering whether the checkpoints and saves would be more fun than shorter, tighter levels. We decided to prototype again, using shorter levels without save points.
This prototype was much more fun, the gameplay was simpler-- checkpoints added unneeded complexity. The system without checkpoints also lent itself more readily to fast-paced, action gameplay. We decided to go with shorter, faster levels that didn't require save points at all.
Iterative design and prototyping led to another major change in Marble Blast. We originally failed to recognize a pretty important technology change that was needed in order to give Marble Blast the kind of feel we wanted, and that it needed. As our prototyping progressed, we discovered that we needed to modify some of our rendering technology.
Marble Blast really didn't feel right using the stock rendering in Torque. The lighting on the levels wasn't bright enough, and we wanted contrasts to be sharper. About half-way through the project, we decided that we needed to devote the time to modify some rendering routines.
Rendering changes:
Gourad shading:
We implemented gourad shading on our level geometry. Torque previously supported flat vertex shading, but we wanted full gourad support for Marble Blast. We thought that this shading model would provide the brighter, more detailed look we were after. Our gourad implementation analyzed level geometry during mission load, and averaged nearby vertex normals, yielding exactly the look we wanted.
Stencil shadows:
The soft shadows used in standard Torque didn't have the crisp, clean look we wanted for Marble Blast either. In order to get the look of shadows in the game right, we decided to try implementing stencil shadows. This was a great fit-- the fact that our geometry was simple, and that our levels had only one light source made the game well-suited to this technique. The stencil-shadowed look provided exactly the kind of crisp detail we wanted.
Table 2.1. Rendering Comparison
 Torque's standard rendering scheme didn't have the bright, crisp look we wanted. |  The rendering changes proved to be very important to the look, and more importantly the feel, of the game. |
The result of both of these rendering changes was a look much better-suited to the game's fun, arcade-y feel.
Besides rendering changes, the camera system required a lot of work during prototyping and throughout development. But this was another area we failed to note as key to the game during our very first technology identification pass.
It took a long time to get Marble Blast's camera to behave as well as it does. Torque's camera capabilities are very flexible, so we didn't need to change or add new core technology coding in order to implement our camera system. We just needed to change the way the camera behaved.
We began testing ideas for the way the camera responded to input during the first few prototypes, and continued until past the midpoint of the project. We finally ended up with an easy to use system that plays well and that most people find very natural.
Figure 2.9. Marble Blast - Midpoint Camera System
Tweaking the camera took a lot of work. This picture illustrates a prototype of the camera system, before our rendering changes were complete. By this point, the camera could track the marble well, even through tight spaces such as tunnels. It would take several more weeks of polish before the camera would be totally satisfactory. Devoting the time to polish this system was very important to the overall feel of Marble Blast's gameplay.
Coming back to the marble physics, which really represented the absolute core of the gameplay, we consistently tweaked the feel of the physics and the marble behavior throughout each prototype. We did many, many mini-marble physics prototypes, testing various behavior tweaks on different kinds of geometry, and eventually with many different kinds of power-ups.
While we did many mini-prototypes, the marble physics system really took shape in three major passes:
This system of constant revision and improvement resulted in the well-tuned marble physics system the game shipped with.
That all sounds fine, but what if we'd done a couple prototypes and weren't having success making the marble fun to play with?
If this had been the case, we would've cut our losses and stopped production of Marble Blast right away. This is another powerful lesson for Indie developers to learn: just because you spend time working on a game idea or feature does not mean you should finish it. As Mark says, "If you add a feature-- even if it took a while to create-- don't be afraid to cut it. Be harsh. Anything that doesn't make the game a lot more fun should go. Start working on something that will make your game better, not just bigger. And if your basic game idea just doesn't hash out and start playing well, then abandon ship. There are a million game ideas out there; you can move on to a better one."
You can see from Marble Blast's story just how powerful iterative development models can be for rapidly producing quality games. Marble Blast would never have turned out so well, nor been so successful, without this general approach to game development.
