Torque Game Engine DocumentationVersion 1.3.x
| Torque Game Engine Documentation Version 1.3.x |
At this point, you are well on your way. You have a design that seems reasonable. You have an idea what content and technology you'll need. And you have an idea which pieces of technology will need to be newly created, and which can re-use or modify existing components. The next step is to do a quick and dirty prototype for your game.
Prototyping. I don't think we can stress enough just what a good idea it is to prototype your game, and especially your core gameplay. Prototype early and often, and your game will have a much better chance of success.
As we'll see, early, frequent prototyping was key to Marble Blast's development, and it really is to any large, modern software project. It is important that you understand what a prototype is, and how it should work. There are several important points to keep in mind when doing a prototype for a game:
Keep the art simple--
At this point, don't worry about eye-candy, or how your prototype looks. You will burn too much time creating nice art before you even know whether your game will actually be good. The whole point of prototyping is to rapidly get a mock-up of your gameplay going. The point here is to test whether your game design ideas will actually play well.
So, get a mock-up going! You will be amazed at how much revision of a game's design can be done very early on. Get a prototype of your game going as quickly as possible. You will use this prototype to begin examining your design, and identifying areas that need to be fleshed out, changed, or removed.
By creating a prototype early and critically evaluating your gameplay systems, you'll have a better chance of identifying what works and what doesn't, before you invest time implementing complete versions of systems or content that end up getting tossed later in development. Even if your gameplay is heavily graphics-dependent-- for example, if you're doing a stealth-action game-- you should not worry about nice-looking art at this point. Get the rendering components you need for gameplay mocked up, and leave the polishing for later.
Don't worry about perfect--
Your art certainly doesn't need to be perfect, and neither does your code or gameplay behavior. We're harping on it here, but it's important: get stuff working in a basic fashion. That is all you should be worried about on the first pass at a prototype.
If you want to get your game done as quickly as possible, and end up with solid, fun gameplay, you'll want to allow yourself maximum time for revising and polishing your game. So, getting the first prototype up and running as quickly as possible is very important.
As development moves along, and you iterate over your design and prototypes, completing and polishing your systems and their behavior and content will happen naturally. Read on in Step 5 for some tips on iterating, and to see how prototyping helped Marble Blast's development.
Use a simple GUI--
Just like everything else at this stage, you should not spend much time on your GUI yet.
You can and should be thinking about clever, efficient, elegant GUI designs and control schemes, but you should not be sprucing up your GUI, in terms of how it looks. Your initial prototype certainly can, and often times it should, mock-up and test your interface's functionality, and control scheme, but don't spend time on the way it looks yet.
To see some examples of just how quickly and simply you can get prototype games going, check out Game-In-A-Day events in the GarageGames community. The Game-In-A-Day events were started by GarageGames community members, and they provide organized events where game designers, programmers, and artists can see what sorts of prototype games they can make over a weekend, often using the Torque Game Engine.
With just one programmer on the task, it took us 3 weeks to move from our initial game concept to the first Marble Blast prototype. We built this first prototype exactly the way most people who license Torque do-- by modifying the FPS starter kit.
Just like any other team would do, we used Torque's GUI editor to get a stripped-down GUI that worked for a Marble Blast prototype. Just like any other team, we used Torque's mission editor to put together our prototype levels, and continued to refine them throughout development. Like anybody else, we used QuArK to build our prototype level geometry, and continued to use it throughout development. We built the marble very simply in 3DS Max, and like any Torque-based team, we could've used any supportive 3D modeling software. We painted our textures in Photoshop, and again could've used any 2D software common amongst Torque developers. Most of Marble Blast's gameplay coding was prototyped in TorqueScript, and remained scripted throughout development; so our programming process looked just like any other Torque team's would as well.
Figure 2.6. Marble Blast - First Prototype's Menu
We built an extremely simple mock-up menu and GUI for the first Marble Blast prototype. Don't spend time polishing aspects of your game in the initial prototyping phase. You need to devote all your energy during this period to testing out, refining, and improving your gameplay designs.
As mentioned, our top priority in the first prototype was to get marble physics mocked-up, so we could start tweaking and refining them. Mark Frohnmayer, a senior engineer, tackled the problem and got the first prototype of the physics up and running in the starter kit mission.
Mark built the marble physics all himself, knowing it was simple enough that leveraging third-party physics software wouldn't be necessary. He represented the marble as a simple point-radius sphere, and used a custom line-swept spheres collision detection algorithm for determining when physical interaction with the marble needed to be simulated.
For the physics simulation, Mark implemented a simple Newtonian system. Many people get scared off by the idea of programming physics, but there wasn't anything too genius involved even in Marble Blast's complicated physics. Mark simply recalled the basic physics he learned in high school. When worst came to worst, he just googled for the physics formulas he couldn't remember.
Mark coded all the marble physics in the C++ marble class, which derived from Torque's ShapeBase class. The decision was made to derive from ShapeBase because it offers much of the basic 3D functionality we needed, but is general enough to be easily customized. ShapeBase provides built-in support for loading and displaying 3d shapes, playing audio, and it offers compatibility with Torque's mission trigger functionality. With all that, it is still general enough that it doesn't include any extra cruft, or make restrictive assumptions about how a 3D object will behave. If you're doing a game where "characters" aren't humanoids or vehicles, deriving them from ShapeBase is usually a good idea.
During the first prototype, the marble physics were very cool-- we could tell we'd have a fun game on our hands, eventually. But the physics needed a lot of polish before the game would become really satisfying to play. Prototyping this system so early on gave us plenty of time to test and refine the physics system.
Figure 2.7. Marble Blast - First Prototype's Marble Physics
Our first model of the marble physics proved that our basic game idea could be fun, but there was a lot of polish to do later in development. During the first prototype, the marble got caught on edges (pictured), behaved improperly with high momentum, was finnicky about jumping, and got stuck easily. That was all fine-- at this first prototyping stage, we simply wanted to mock-up and test our basic gameplay idea. It was easy to see that the basic premise for the game could be successful.
Prototyping the game levels wasn't hard. We used DIF-formatted objects, since Torque supports good collision on large, complex DIF objects out of the box (for more information on what DIF-objects are, check here and here). And again, we started just like anyone else would, taking stock Torque example missions and modifying them with our custom-created DIF models.
This first prototype also included terrains. We thought it would be fun to be able to race around on both big, twisty levels and complex, rolling terrains. The marble physics system seemed to do fine with the terrains, but as you'll see in the next section, we quickly decided to do without them.
As for multiplayer, prototyping so early helped us a lot here as well. With the marble physics system prototyped, we started to realize how complex it might be to support in a multiplayer setting. Accounting for precise marble physics over a network began to look much more challenging than we originally expected.
At this stage, multiplayer capability was still on the plate. We kept Torque's solid networking core, but we had the first shadow of a doubt as to whether multiplayer gameplay would really be feasible.
Doubting whether mutiplayer gameplay would be feasible led us to question whether it would be necessary to ending up with a great game. If it were truly necessary to the gameplay, it would be essential to work out a complicated system that could fully support the kind of marble physics we wanted. On the other hand, if it seemed the game could stand on its own in single-player, we could nix the multi-play capability, save all that development time, and make the core game that much better.
With this first prototype in hand, we could see the game's potential, and became confident that it could, in fact, stand on its own as a single-player game. We knew that multiplayer would certainly be cool in the setting of Marble Blast, but our best estimates told us that the cost to implement it would be much higher than the possible benefit it could offer to gameplay.
As such, we made the painful decision to cut multiplayer from the game's design. Not everyone on the team wanted to go this way, but in the end, everyone agreed. It was an extremely difficult decision, but it paid off very well in the end.
The only reason we were able to make this decision so early on, consequently saving ourselves a lot of development time, was because we focused on getting an early prototype of the game up and running absolutely as quickly as possible. If we had waited longer to prototype we would have burnt design and development time on a feature that ultimately would be cut.
