CHAPTER 21
CREATING THE GAME MISSION
Let’s take a moment to step back and see where we are.
In the first chapters of the book you learned the basics of programming and how to apply those concepts to real things that can be done with a modern game engine. In the process you learned how to use Torque to try out your ideas. You saw that Torque has a powerful script system and the things you can do with it are almost limitless.
We then moved on to artwork, starting with textures and graphic images. You learned about a couple of new tools—Gimp 2 and UVMapper—and how to apply them to the task of skinning 3D objects and GUI screens.
Then we got into modeling 3D objects, using a few more tools—MilkShape and Constructor—to create the models using different techniques. Animating our objects using MilkShape helped bring static models to life.
After that it was on to some nifty things like creating skyboxes and images for weather effects, such as lightning and rain.
Then it was sound effects, recording them and using them in a game in different ways.
Now you might think that all of this is leading somewhere. And you would be right!
GAME DESIGN
Okay, enough typing and programming for now. It’s time to examine some higher-level issues, like game design.
Start with a vision.
You have an idea. It canbeanamorphous,gee-I’m-not-really-sure-but-something-like-this idea, or it can be concrete, specific, and detailed. Using that as your reference, start asking yourself questions, write them down, and don’t worry about answering them…yet.
Requirements
There are a myriad of questions you can ask yourself when considering the design of your game:
What will the genre or play style be like?
Will this be a single-player or multiplayer game?
If it is to be a multiplayer game, will it be an online game or a split-screen type of multiplayer game?
Does the game relate to real-world activities?
Does the player play as a creature-character (human, animal, alien, and so on) or as some sort of machine?
If the player isn’t a creature or a machine, is he some sort of higher-level being that directs or controls a multitude of game entities?
What are the player’s goals?
How do we measure player success, and what are the scoring mechanisms?
What are the challenges that the game presents to us as players?
Will the challenges be designed (planned by the game developers), or will they be random?
What is the backstory (the narrative that describes the world the game takes place in), if any?
What is it about the game that will make people want to play it?
What is the one skill or skill set that the game requires the player to master in order to succeed?
What other skills will contribute to player success?
What mechanisms can the game offer that will help players develop those skills?
How much game enhancement of skills is too much help?
Feel free to add more questions of your own.
As you can see, the list is big, and we’ve only scratched the surface here. By answering these questions, and any others you may want to add, you can build a list of requirements. It is important to generate at least this list—the requirements specification—in order to know where you are going with your design and how to measure your progress toward completion.
Software design is a big-ticket item, and hundreds of books have been written about it and the various design methodologies that have been proposed. It’s an industry unto itself. There are dozens of different ideas about the best approach to take—and much disagreement. The one area everyone seems to agree on, however, is the need for the requirements to be determined and recorded in a meaningful way. Functional specs, test plans, schedules, and the like may or may not work for you, but you will get nowhere fast if you don’t know what it is you are trying to accomplish.
Some of the questions lead to other questions. Some answers may need to be deferred until later when you have more information. Even if your list of questions exceeds your list of answers, it is still an important activity. Keep the list nearby, return to it regularly, and update the answers. See where it leads you. Perhaps you can see that you are wandering away from your original vision. The list may uncover things you’d never considered before, that really are important, and prevent you from wasting time on a mistaken approach.
When you work your way through creating the questions, try hard to stay general—steer away from specifics until they can’t be avoided any longer.
At some point you will want to ask yourself, “What technology should I use to create this game?” Don’t ask this question at the very beginning. In most cases you should wait until you know the answers to the bulk of your questions—in other words, wait until your requirements are starting to look meaty and useful—before you ask yourself technology questions.
Constraints
We usually have to accept that there are constraints that can arbitrarily force us to move in particular directions or prevent us from moving in others.
The design should drive the technology and not the other way around. However, in a low-budget development shop, this is often an unaffordable luxury. There are budgetary constraints caused by available funds that will force us in certain technological directions. In our case, because this book is about making games with minimal expenditure and using the Torque Game Engine to help us achieve that goal, we will have to accept that constraint and monitor the effect it has on our design as we build it up.
Again in our case, because we already know the technology we are going to use, we should examine it for its limitations and measure our constraints starting there.
As mentioned elsewhere, Torque is designed for online, multiplayer, first-person shooter-style games. This means that whenever implementation tradeoffs had to occur when creating the game engine, the developers always tried to make their decisions in a way that favored efficient and fast networking, first-person perspective 3D rendering, and multiplayer support.
One of things that Torque, right out of the box, doesn’t address in its design is massive multiplayer support. Torque can easily handle 64 players logged in to one session. It can even handle more than 100. In fact, there is no hard-coded limit to the number of players that could log in to the same server. But because of its design, Torque really starts to lose its shine when you exceed the realm of about 100 players.
Massively multiplayer games require the ability to have thousands of players playing the same game together. Torque just doesn’t handle this kind of load.
So the server load is a constraint. While Torque’s ability to handle 100 players at once is better than most, if not all, other FPS-style games out there, that still doesn’t translate to thousands. We must keep this in mind.
The tools we have available can dictate other constraints. It’s fine to decide that you will have a certain feature, but it may require an expensive 3D modeling tool to create and thus sit out of reach. So make sure you can create the things you want.
Koob
Let’s go about listing some requirements for Koob, the game we are making. Feel free to add your own, but the list of 29 items here will serve as a starting place.
1. First-person and third-person perspective play.
2. Internet multiplayer game play.
3. Global in-game chat.
4. Ability to use at least one weapon.
5. Ability to get in and out of vehicles.
6. Ability to drive vehicles.
7. A road or track in the world to drive on.
8. Trees and other foliage.
9. Powerups: health, energy, ammunition, coins (for points).
10. Buildings that serve as hiding places and storage locations for powerups.
11. All other players are enemies.
12. All point values configurable from a setup file.
13. 1 point per enemy killed.
14. 3 points per vehicle destroyed.
15. Ability to race around the track and score 5 points for each lap you lead.
16. Laps can only be scored in the car.
17. A 10-lap race with no time limit.
18. A 10-point bonus for winning the race.
19. On-screen scorecard.
20. Scores retained at the end of each race restored when player resumes the game.
21. Each player gets an account at startup and must use a password to log in to the game.
22. Track must be clearly marked on the terrain.
23. Checkpoints along the way to measure progress and ensure the player stays on course.
24. Laps can only be completed when all checkpoints are completed for that lap.
25. Checkpoints must be completed in sequential order.
26. Coins of three denominations will be randomly scattered around the maps. The values will be 1 point, 10 points, and 100 points for copper, silver, and gold, respectively.
27. Some nice burning objects to admire as we play.
28. A waterfall to admire just for the heck of it.
29. When one map is finished, cycle to the next in the list.
So as you can probably gather, Koob is a kind of death-match scavenger-hunt game. The player tries to win the race, accumulate some loot, and, at the same time, stop his enemies from winning.
As we progress from here to the end of the book, we’ll check back against this list of requirements to make sure we’ve covered all the items.
Right off the bat, we can check off item 1. A few of the other items are definitely doable because we’ve chosen the Torque Engine to create the game, but we have some programming yet to do to make them happen.
Prepping Koob
As you’ve done recently, you should copy your previous version of Koob to create the basis for the version for this chapter. I still encourage you to do that, but from now on I’m going to step back from using the chapter-specific names for Koob. So I will refer to a path as Koobassets, or Koobcontrol or whatever. You just need to insert the number in your mind to match the chapter you are working in.
I’ll admit that this is to make things easier for me. As we add items and code, it becomes more and more complex to ensure that the code in the book matches up with the code and other assets in the RESOURCES folder.
To sum up, you should be working with a new copy of your project, now called Koob21, while I refer to plain old Koob. Do the same for the next two chapters as well.
TORQUE WORLD EDITOR
You’ve already been exposed to the World Editor—a little bit here, a little bit there—in the various tutorials in earlier chapters. As you’ve seen, the World Editor contains several subeditors: the Object Editor, Terrain Editor, Terrain Painter, Material Editor, and Mesh Road Editor to name but a few. The main point of this section is to place objects in the game world and adjust them as required. To do this we will mostly use the Object Editor, which has two components: the Scene tree and its partner, the Object Inspector.
In the World Editor the normal movement keys can be used to control both the player and the camera. The right mouse button is used to rotate the camera or adjust the player’s view.
File Menu
Disk and file operations are carried out using the items in the File menu, as shown in Table 21.1. These include opening, saving, importing, and exporting.
Edit Menu
As is standard with windowed applications these days, there is an Edit menu that houses a variety of object and item editing commands. As you can see in Table 21.2, in addition to the ubiquitous Cut, Copy, and Paste functions, there are also commands used to access various settings for the editors.
Object Menu
Use the Object menu, as described in Table 21.3, to manipulate and move objects.
Caution
The Reset Transforms, Reset Selected Rotation, and Reset Selected Scale commands in the Object menu appear to be buggy in this Demo version of T3D. The functionality seems to be intermittent and not reliable. Instead of using these commands, use Undo instead (Ctrl-Z).
In the Transform Selection … command’s dialog, the “relative” checkbox for each of the transforms does not reliably perform relative operations. You are best advised to use manual movement (click-drag on an object’s axis gizmo) to perform relative transforms.
Camera Menu
Use the Camera menu, as described in Table 21.4, to change camera modes and adjust the camera fly mode speed.
Other Menus
The Editors menu is available by default and contains commands that invoke all of the available editors in the World Editor. We’ll be looking at some key ones shortly.
The Lighting menu allows the selection of Advanced or Basic lighting as its primary function. It also lets the user invoke a relight pass (not usually needed) and to toggle ShadowViz on and off. If you have a light selected (one with castShadows enabled) and you toggle ShadowViz on, you will be able to see the light map for that light.
The Help menu is pretty straightforward, so it doesn’t require a table to describe its functions. It is used to invoke online and offline help.
Object Editor
The World Editor provides a view of the 3D world on the left side. Objects in this view, like structures, interiors, shapes, and markers, can be manipulated with either the mouse or the keyboard.
When the Object Editor is open, we have access to the Scene tree in the upper portion of the panel at the right, and the Inspector in the lower portion.
Scene Tree
The Scene tree view is displayed in the upper frame in the panel on the right in the World Editor. This tree displays the hierarchy of the mission data file, also known as the scene graph as discussed in Chapter 3. Objects selected in the Scene tree view will also be selected in the main world view on the left. Objects in the Scene tree view can be organized into groups called SimGroups, which are akin to folders on your hard drive.
There is a special group selection traditionally known as the instant group. This is the group in the Scene tree view where newly created or pasted objects are placed. Objects created from the library are also placed in the instant group. To change the current instant group, right-click on a group in the Scene tree and choose “Add New Objects Here”.
Inspector
The Inspector lets you examine and specify properties of mission objects. When you select an object in the Scene tree, that object’s properties are displayed in the Inspector frame at the lower right of the screen.
After editing an object’s properties, the changes are automatically committed into the scene. You can press the Enter key to make sure that your changes have been committed into the scene, if you like. This is not normally needed, but every now and then I encounter the need to press that ol’ Enter key.
Dynamic properties can be assigned to objects with the Dynamic Fields Add button. Dynamic fields can be accessed via the scripting language and are normally used to add game-specific properties to objects.
Library
The Library lives in a tab next to the Scene tab. The Library tab contains a mini-browser that provides access to all objects that can be created in a mission. Selecting an object via this browser creates a new instance of the object and drops the new object at the center of the screen (by default) or as specified by the selected Drop Location command in the Object menu, which is shown in Table 21.5.
You can use both the mouse and the keyboard for editing, as shown in Table 21.6.
Gizmos are the visual representation of each object’s three axes. When you select an object, gizmos will appear centered on that object’s local origin. Each gizmo’s axis arrow points in the direction of the positive side of that axis.
Gismos can be clicked and dragged (as described in Table 21.7) in order to modify the object to which they are attached.
Terrain Editor
We use the Terrain Editor to manually modify the terrain height map and square properties by using a mouse-operated brush. The brush is a selection of terrain points or squares centered around the mouse cursor. When the Terrain Editor is active, it populates the Settings toolbar (the one below the menu bar) with its own set of tunable settings. Table 21.8 describes the settings available in the Settings toolbar.
Table 21.6 Mouse and Keyboard Operations
Table 21.8 Terrain Editor: Settings Toolbar
When we use the Terrain Editor, we can modify the terrain as if we are piling dirt onto it or shoveling holes into the ground. Table 21.9 shows the actions available in the Terrain Editor via the Action toolbar, which displays at the left side of the screen.
Table 21.9 Terrain Editor: Action Toolbar
Terrain Painter
The Terrain Painter uses mathematical techniques to assist the user in “painting” terrain materials onto the terrain in the world view. The editor has two main interface elements on the right side of the screen: the Material Preview pane and the Material Selector pane.
The Terrain Painter also provides its own settings in the Settings toolbar, for the terrain designer to use to constrain the surfaces to be painted.
Terrain materials are created using the New Layer button at the bottom of the Material Selector pane. Materials are painted onto the terrain surface according to the constraints in the Terrain Painter Settings toolbar, whose options are shown in Table 21.10.
As you paint, the material is applied in real time. You may on occasion need to perform a manual relight of the scene by choosing Lighting, Full Relight.
Table 21.10 Terrain Painter Settings Toolbar
Other Editors
There are, of course, many more editors, which I will describe in brief. If you want to fiddle with these editors, then you would be better served to run the T3D demo game itself, rather than the Koob game. Supporting the broader set of editors in Koob requires additional code and preparation that would greatly increase the size of this book (and it is already very large). So go ahead and use the T3D demo if you like, to explore these other editors.
The Material Editor is where we find and define materials, as we’ve seen in earlier chapters.
The Sketch tool is a simple 3D shape–making tool that allows you to create simple cubes and oblong shapes in the 3D world, and to modify them in a limited way. You can assign a material to such shapes, but be aware that you can’t fiddle with the UV coordinates of the material, and you will also have only one material for all faces of the shape. It’s a useful tool, but obviously somewhat limited.
The Datablock Editor allows you to modify all of the datablocks that your game knows about, without having to exit the game to edit the datablocks in code. If you define a datablock in, let’s say, assets/myInterestingThing.cs, then the revised data-block code will be written out to that file.
However, if you use the Datablock Editor to create a new datablock, then the datablock code will be written out to a file called managedDatablocks.cs, which by default will be put in the art/datablocks folder, if it isn’t already in there. You can choose to save the managedDatablocks.cs file anywhere you like, using the Save Datablock to a New File button (looks like a pencil on the right side of the screen in the Datablock pane).
The Decal Editor lets you create flat images that can be “pasted” onto any surface in the world.
The Forest Editor lets you create huge forests with hundreds of different kinds of trees. First you import tree models (shapes: either .dae or .dts file types), then you create “brushes” using the imported trees. You take a brush and go around and paint on terrain, adding trees as you go. You can tweak a huge number of parameters that will dictate things like the probability of a given tree being painted on in a given area, the scale of the tree, how “deep” into the terrain it sits, and so on.
The Mission Area Editor defines regions in the game that are used to constrain player travel. If we use mission areas in a game, we normally give warnings or disqualifications if a player leaves a mission area. Of course, you can probably find other uses for such a feature. This editor is really only a viewer, allowing you to see the bounds of the Mission Area outlined in red wireframe in the world view.
To edit the mission area: select the Object Editor, open the Scene tree view, and locate the TheMissionArea object in the tree. Then change the values of the area field, the flightCeiling property, or the flightCeilingRange property.
The values in the area property define the east, north, west, and south boundaries of the Mission area.
The flightCeiling and flightCeilingRange properties are designed to affect flying vehicles, limiting how high they can go, and how far they can go when at maximum height.
The Particle Editor is discussed in more detail later in this chapter.
The Mesh Road Editor is used to dynamically create roads as 3D shapes in the scene. Using 3D shapes for roads allows you to easily place roads on mildly rough terrain, while still keeping the road surface smooth.
The River Editor is similar to the Mesh Road Editor, except that it is used to place flowing water in a linear fashion, just like a creek or river.
The Road Editor provides a tool for creating “splined” paths that mobile objects in the game could follow. It has the additional capability of letting you define the path to be a decal road, which creates an alternate form of road that hugs all the ups, downs, and other bumps of a rough terrain, without the performance penalty of inserting more 3D objects in a scene, like the Mesh Road Editor does.
The Shape Editor provides a rudimentary editing tool for 3D models. With it, you can mount shapes to each other, modify the position of nodes, and other aspects of 3D models. I find it most useful as a tool to view the animation sequences of a model, for the purposes of debugging a model.
BUILDING THE WORLD
Let’s get to work building the game world, and let’s start with items 27 and 28 from our requirements list. I’ve chosen the fire and the waterfall to start with here because we haven’t really looked at particles much yet, and with particles we get to touch on various topics we’ve covered in this chapter, like easing into using the World Editor, the Scene tree Library, and the Inspector. And besides that, particles are cool.
Particles
Remember the raindrops in Chapter 18? Those were particles. Particles are basically single-faced polygons that are generated in bulk by a game engine to simulate a variety of somewhat-related real-world phenomena, such as rain, smoke, wispy fog, splashing and spraying water or mud, fire, and flames. Particles can be used to simulate any sort of constantly changing fluid- or gas-like entity. Even a swarm of mosquitoes can be generated using particles.
What I’ll do in this section is show you how to use the Torque particle system to make a campfire and a waterfall.
Particles are made of three parts:
Particle. The actual things we see.
Particle Emitter. The thing that causes the particles to come into existence.
Particle Emitter node. The object that the emitter is attached to.
If you attach the word data to the end of each and remove the spaces, you’ll have the formal names of the datablocks that define those terms of the particle system:
ParticleData ParticleEmitterData ParticleEmitterNodeData
Particles can live in the game world in one of two ways: as freestanding particles or as attached particles. Freestanding particles are defined using all three of the datablocks just mentioned, while attached particles only require defining the ParticleData and the ParticleEmitterData. The nodes aren’t needed, because we are attaching the particle to some other object that supports particles. The object classes that support particles are players, weapons, projectiles, and all vehicle types. As noted already, Rain is a specialized object that has a built-in particle capability.
So in the case of freestanding particle emitters, one more definition of interest is required for placing emitters in the world:
ParticleEmitterNode
We’ll look at freestanding particle emitters a bit more shortly.
Campfire
To make a campfire, we’ll need two particle definitions: one for the flames and one for the smoke. The particle types used will be freestanding, so we will need to define all three particle datablocks for both the smoke and the flames.
First, copy the image files 3D3ERESOURCESCH21flame1.png and flame2.png to KOOBassetsdataparticles.
Next, create the file KOOBcontrolservermiscparticles.cs, and add the following code to it:
datablock ParticleData(myCampFireParticle1)
{
textureName = "assets/particles/flame1";
dragCoefficient = 0.0;
gravityCoefficient = -0.3;
inheritedVelFactor = 0.00;
lifetimeMS = 500;
lifetimeVarianceMS = 250;
useInvAlpha = false;
spinRandomMin = -30.0;
spinRandomMax = 30.0;
spinSpeed = 1;
colors[0] = "0.6 0.6 0.0 0.1";
colors[1] = "0.8 0.6 0.0 0.1";
colors[2] = "0.0 0.0 0.0 0.1";
sizes[0] = 0.5;
sizes[1] = 0.5;
sizes[2] = 0.9;
times[0] = 0.0;
times[1] = 0.5;
times[2] = 1.0;
};
datablock ParticleData(myCampFireParticle2)
{
textureName = "assets/particles/flame2";
dragCoefficient = 0.0;
gravityCoefficient = -0.5;
inheritedVelFactor = 0.00;
lifetimeMS = 800;
lifetimeVarianceMS = 150;
useInvAlpha = false;
spinRandomMin = -30.0;
spinRandomMax = 30.0;
spinSpeed = 1;
colors[0] = "0.8 0.6 0.0 0.1";
colors[1] = "0.6 0.6 0.0 0.1";
colors[2] = "0.0 0.0 0.0 0.1";
sizes[0] = 0.3;
sizes[1] = 0.3;
sizes[2] = 0.3;
times[0] = 0.0;
times[1] = 0.5;
times[2] = 1.0;
};
datablock ParticleEmitterData(myCampFireEmitter) { ejectionPeriodMS = 15; periodVarianceMS = 5; ejectionVelocity = 0.25; velocityVariance = 0.10; thetaMin = 0.0; thetaMax = 45.0; particles = "myCampFireParticle1" TAB "myCampFireParticle2"; };
datablock ParticleEmitterNodeData(myCampFireEmitterNode)
{
timeMultiple = 1;
};
Now open KOOBcontrolserverserver.cs, locate the function OnServerCreated, and add the following line to the end of the function, before the closing brace (“}”):
Exec("./misc/particles.cs");
To figure out which mission file you are loading and spawning into, open KOOBcontrolclientclient.cs and look in the LaunchGame function for the call to the CreateServer function. The second argument to that call is the path to the mission file you are opening when you run Koob.
Next, open your mission file (assetsmapsook_ch6.mis, KoobA.mis, or whatever your mission file is called, as long as it is based on one of the mission files used for Chapter 5 or 6 and uses the same terrain), and add the following before the closing brace and semicolon pair of the file:
new ParticleEmitterNode(myCampFire) {
active = "1";
emitter = "myCampFireEmitter";
velocity = "1";
dataBlock = "myCampFireEmitterNode";
position = "3.19285 -4.72361 179.162";
rotation = "1 0 0 0";
scale = "1 1 1";
canSave = "1";
canSaveDynamicFields = "1";
};
Okay, save your files, and then launch Koob. Turn to the right when your player spawns in, and you should see a little fire burning just in front of you—at the edge of the gully there—as shown in Figure 21.1.
The flame is the glowing object just above the cross-shaped cursor in the middle of the screen in the figure. Now let’s add the smoke. We’ll do it slightly differently. We’ll begin by defining the particle and emitter as before, but then we’ll place it in an easier way using the World Editor.
Open up the KOOBcontrolservermiscparticles.cs file you created earlier, and add the following:
datablock ParticleData(myCampfireSmokeParticle)
{
textureName = "assets/particles/smoke";
dragCoefficient = 0.0;
gravityCoefficient = "-0.05";
inheritedVelFactor = 0.00;
lifetimeMS = "5000";
lifetimeVarianceMS = "500";
useInvAlpha = false;
spinRandomMin = -30.0;
spinRandomMax = 30.0;
colors[0] = "0.496063 0.496063 0.496063 0.0944882";
colors[1] = "0.59842 5 0.598425 0.598425 0.0944882";
colors[2] = "0.598425 0.598425 0.598425 0";
sizes[0] = "0.497467";
sizes[1] = "0.747726";
sizes[2] = "1.4985";
times[0] = 0.0;
times[1] = "0.498039";
times[2] = 1.0;
animTexName = "assets/particles/smoke";
spinSpeed = "0.146";
};
datablock ParticleEmitterData(myCampfireSmokeEmitter)
{
ejectionPeriodMS = 20;
periodVarianceMS = 5;
ejectionVelocity = 0.25;
velocityVariance = 0.5;
thetaMin = 0.0; thetaMax = 90.0; particles = myCampfireSmokeParticle; }; datablock ParticleEmitterNodeData(myCampfireSmokeEmitterNode) { timeMultiple = 1; };
Save your work, and then launch Koob.
Tip
If you haven’t created the key bindings for switching between Player Camera and World Camera (or “camera fly mode”) then you should probably do that. However, if you don’t want to bother with that at the moment, then there is a work-around: open the World Editor by pressing F11, and then press Alt-C. This will toggle you back and forth between the two camera modes.
If you do want to create the key bindings, then go ahead and open control/client/misc/presetkeys.cs. At the bottom of the file add these three lines:
PlayerKeymap.bind(keyboard, "F8", dropCameraAtPlayer);
PlayerKeymap.bind(keyboard, "F7", dropPlayerAtCamera);
PlayerKeymap.bind(keyboard, "alt c", toggleCamera);
The first binding, F8, will move the World Camera to the location of the player, and then switch you to viewing through the World Camera. This is also called “camera fly mode.”
The second binding, F7, will move the player avatar to the position of the World Camera, and then switch you to viewing through the player’s eyes. It’s basically the opposite of F8.
The third binding, Alt-C, will simply toggle back and forth between the two view modes.
Locate the campfire, and face it in camera fly mode (press F8). Open the World Editor (press F11), and then enter the Object Editor (press F1).
Before placing the particle emitter node, make sure that the new objects will be placed in front of you by choosing Object, Drop Location, Screen Center.
Next, browse the Scene tree until you locate Library, Level, Environment, ParticleEmitter. Click it to place another particle emitter.
You will get the Create Object: ParticleEmitterNode dialog box. Using the illustration as a guide, choose myCampfireSmokeEmitterNode from the datablock list, and then choose myCampfireSmokeEmitter from the Particle data list (see Figure 21.2).
After the smoke appears, move it with the cursor until it’s positioned directly over the campfire. Press F11 to get out of the editor, grab some s’mores, and get cookin’!
Tip
Lookin’ and Movin’
When placing particles in the world (or anything for that matter, but especially particles), you might find it easier to use one or more of the orthogonal views for the World Camera. What I do is use the Top view (Camera, View, Top, or Alt-2) to align the fire and smoke over top of the campfire location, and then Front view (Alt-3) or one of the side views to adjust the vertical position of the particle in question.
Also remember that, in order to move the objects around, you need to be in the correct transformation mode, which is Move Selection (the second one down in the toolbar on the left while in the Object Editor). You can click on its icon to go into Move Selection mode, or simply press the 2 key (not the number key pad version though).
You need to have the arrows at the end of the axis lines in order to move the object along those arrows.
As you can see, ParticleEmitterNodes are useful for creating nodes that are stationary but animated. Place them in your world by adding a datablock and emitter references in your mission file, either through the Torque World Creator or by directly editing the mission file.
Table 21.11 describes the significant properties of the ParticleEmitterNode data-block. This describes the actual node object that is inserted in a mission file for a freestanding particle emitter.
Table 21.11 ParticleEmitterNode Properties
Now, if you look at Figure 21.3, you’ll see the relationship between the various data-blocks involved in particles. The items in rectangles need to be defined somehow—you’ve seen how to do this. The one gotcha in the diagram is that the items in the dashed rectangles only need to be defined when placing freestanding particles in the game world. When you attach particles to objects like the player or vehicles, only the datablocks shown in the solid rectangles (ParticleData and ParticleEmitter-Data) need to be defined.
Figure 21.3
Particle system elements.
Note that a ParticleEmitterNode object is only defined in a mission file.
Table 21.12 describes the significant property of the ParticleEmitterNodeData datablock.
There is only one parameter in this datablock: timeMultiple. You can create any number of these datablocks with different settings and names.
Table 21.12 ParticleEmitterNodeData Property
Table 21.13 describes the significant properties of the ParticleEmitterData data-block, although we won’t be using them all here. Those that we don’t use will be assigned default values by Torque.
Table 21.14 describes the significant properties of the ParticleData datablock. Again, we don’t use all of these properties in the campfire, but we do use most of them in the waterfall, which is in the next subsection.
Waterfall
As promised, we will build a waterfall. Add the following particle system datablocks to your particles.cs file:
datablock ParticleData(MyFallsParticle)
{
textureName = "assets/particles/waterfall.png";
animTexName = "assets/particles/waterfall.png";
gravityCoefficient = "0.598291";
sizes[0] = "0";
sizes[1] = "14.9973";
constantAcceleration = "0";
sizes[2] = "6";
sizes[3] = "0.5";
lifetimeMS = "3000";
times[3] = "3";
useInvAlpha = "0";
colors[0] = "1 1 1 0.556";
colors[1] = "1 1 1 0.498";
colors[3] = "1 1 1 0.51";
};
datablock ParticleEmitterData(MyFallsEmitter)
{
particles = "MyFallsParticle";
blendStyle = "NORMAL";
ejectionVelocity = "3.5";
velocityVariance = "0"; thetaMax = "10"; ejectionPeriodMS = "146"; softnessDistance = "1"; orientParticles = "1"; softParticles = "0"; lifetimeMS = "0"; ambientFactor = "0"; alignParticles = "1"; alignDirection = "0.707107 0.707107 0"; };
Table 21.13 ParticleEmitterData Properties
Table 21.14 ParticleData Properties
datablock ParticleEmitterNodeData(MyFallsEmitterNode) { timeMultiple = 1; }; //------------------------------------------------- datablock ParticleData(MyFallsSprayParticle) { textureName = "assets/particles/mist.png"; animTexName = "assets/particles/mist.png"; dragCoefficient = 0.0; gravityCoefficient = "1"; // rises slowly inheritedVelFactor = "2"; lifetimeMS = "2000"; lifetimeVarianceMS = "1500"; useInvAlpha = "0"; spinRandomMin = "-84"; spinRandomMax = "167"; colors[0] = "0.992126 0.992126 0.992126 0.015748"; colors[1] = "0.992126 0.992126 0.992126 0.00787402"; colors[2] = "0.984252 0.984252 0.992126 0"; sizes[0] = "22.914"; sizes[1] = "27.083"; sizes[2] = "39.5807"; times[0] = 0.0; times[1] = "0.494118"; times[2] = 1.0; colors[3] = "0.984314 0.984314 0.984314 1"; spinSpeed = "0.3"; constantAcceleration = "1"; };
datablock ParticleEmitterData(MyFallsSprayEmitter)
{
ejectionPeriodMS = "10";
periodVarianceMS = "4";
ejectionVelocity = 0.25;
velocityVariance = 0.10;
thetaMin = 0.0;
thetaMax = 90.0;
particles = "MyFallsSprayParticle";
blendStyle = "NORMAL";
reverseOrder = "1";
softParticles = "1";
ejectionOffset = "2.083";
};
datablock ParticleEmitterNodeData(MyFallsSprayEmitterNode)
{
timeMultiple = 1;
};
Next, locate waterfall.png and waterfall2.png in the RESOURCESch21 folder and copy them to koobassetsparticles.
Save your work, and launch your game. The area where you want to make your waterfall is shown in Figure 21.4; the annotations show where I think is the best place for a waterfall. Anywhere along the water will do, though.
To get there, press F8 to get into camera fly mode, and fly straight up for a second (do this by looking straight down at the ground and pressing the W key to go backward and up). Then turn 180 degrees away from the direction you were facing when you spawned, and fly over to the area shown in the figure.
Figure 21.4
Locating the falls.
Once there, use the same methods you used when adding the campfire smoke in the earlier section. For the top and bottom parts of the waterfall, use MyFallsEmitter-Node with MyFallsEmitter. Then for the splashing effect at the water surface, use MyFallsSprayEmitterNode with the MyFallsSprayEmitter.
For best results, after placing the topmost emitter in the World Editor, clone the emitter by selecting it and then holding down the Shift key while dragging the emitter to one side using the movement gizmo. Jockey the two emitters around, side-by-side, until you get a respectable-looking torrent of water landing on the ledge that’s about half way down to the bottom.
Place the bottom emitter slight above that ledge, where it can be hidden by the water from above. And then clone it like you did with the topmost emitter.
Then place a spray emitter appropriately on the ledge somewhere, and another one at the bottom pool.
You should get something that looks like Figure 21.5.
You can refine your waterfall by using three nodes for the top—one each for the left, right, and center of the falling water—and perhaps two at the bottom. You’ll notice when you look at some real waterfalls that the center stream of water has a different character than the outer fringes—hence the use of three particle emitters. Also, when the water hits the pool at the bottom, there are typically two observable phenomena: splashing and spraying of fine mist.
The mist we’ve got covered using the spray emitters, and by using a bit of creative smoke and mirrors, you could simulate the splashing using, oh, I dunno, maybe a rain storm or something like that. A really small one, with the splash sizes set larger than normal, and the boxWidth and boxHeight properties set really small, say 10 units or so. And the followCam property would be set to false. The numDrops property might need to be dropped down to a manageable number, like a dozen or so.
If one were to position such a teensy-weensy little storm at the bottom of the waterfall….
The Terrain
I’ve prebuilt two terrains—KoobA.ter and KoobB.ter—for use in Koob. Of course, you are free to make your own. Each of these terrains has a different—in fact, a somewhat opposite—appearance.
KoobA.ter is a bit claustrophobic in places, with much of the action happening in and around canyons and riverbeds, as you can see in Figure 21.6.
KoobB.ter, in Figure 21.7, is more wide open, driving around a series of foothills and mountains.
In both cases, as I laid out the track, I wanted to make sure there was no way to grossly cheat and find a shortcut that would allow someone who knew of the shortcut to obtain a huge advantage. In fact, I designed KoobB.ter to have two built-in shortcuts that may or may not be quicker than staying on the track. See if you can find them!
Also, the specification that says that checkpoints must be used will help minimize shortcut use as cheating.
The KoobA terrain is quite similar to the test terrain we’ve been using with Emaga6 and earlier revisions of Koob. KoobB is entirely new. If you want to check them out, then copy the files KoobA.mis, KoobA.ter, KoobA _basetex.dds, KoobA. mis.decals, KoobB.mis, KoobB.ter, KoobB _basetex.dds, and KoobB. mis.decals, from 3D3E RESOURCESCH21 and deposit them in the KOOBassetsmaps directory.
Next, you will need to open the file KOOBcontrolclientclient.cs and find this line:
createServer(“SinglePlayer”, “assets/maps/book_ch6.mis”);
You can edit this line by replacing the mission file name to whichever mission file (and thus terrain) you want to look at—KoobA.mis or KoobB.mis. Now I know this seems to be an awkward way to select missions. We will be addressing this issue in the next chapters.
Items and Structures
Go ahead and set up Koob to use KoobB. Once that’s done, copy the folder 3D3E RESOURCESCH21STRUCTURES, and put it in KOOBassets. If you are asked if you want to replace existing files, click the Yes To All button.
Then, from 3D3ERESOURCESCH21 copy the folders rocks, lanterns, campfires, and trees into KOOBassetsmodels.
When that finishes copying, launch the game and go into camera fly mode after you’ve spawned. You should be in the middle of a big parking lot surrounded by low hills.
Enter the World Editor (press F11), select the Object Editor, and browse the Scene tree Library until you find Meshes, Assets, Structures. Then look for the startfinish item and the checkpoint item, placing one of each in the game world, using Figure 21.8 as a guide.
Figure 21.8
The start/finish line.
When you insert new structures, which are CSG objects, the lightmap for the scene needs to be regenerated, otherwise the structures show as all black with no textures. If you are in Advanced Lighting mode (look under the Lighting menu in the World Editor) then Torque 3D automatically regenerates the lightmap for you. If you are in Basic Lighting mode, then Torque 3D does not automatically regenerate lightmaps, so to regenerate the lightmap, choose Lighting, Full Relight.
The startfinish item has a checkered flag across the top, both front and back, and more checkerediness (I just made that up) on the pylons on the side. The checkpoint item has a row of arrows along the top pointing down, but only on one side. The other side is black.
To rotate an object, select it, press the 3 key (the normal one that’s just above the W and E on the keyboard), and hover the cursor over one of the gizmo axis curves (X, Y, or Z) of the item. When the axis curve highlights in yellow, click and hold. Then drag your cursor left or right, up or down, to cause the item to rotate around the chosen axis.
Tip
The Object Editor in the World Editor allows you to select the different transform operations merely by pressing the number keys 1 to 4, very similar to the way it was done in Constructor back in Chapter 17.
Key Operational Mode
1 Select Arrow
2 Move Selection
3 Rotate Selection
4 Scale Selection
This does not work with the number keypad numbers.
If you happen to be in some other sub-editor in the World Editor, and you find you need to go back and adjust an object already placed, press F1 to switch to the Object Editor to select and adjust the items.
To move an item, select it, press the 2 key, hover the cursor over one of the axis gizmos, and click and drag in the direction you want to move.
To scale an object along an axis, press the 4 key, select the axis as before, and then drag the cursor. The checkpoint object will have to be scaled a bit horizontally and vertically to fit it inside the startfinish object, as depicted earlier in Figure 21.8.
To define the track, you can use a number of other structures, like barriers (see Figure 21.9) and direction signs (see Figure 21.10).
You should place checkpoints at the locations indicated in Figure 21.11. There will be a total of five checkpoints: one at the start/finish line and four more around the track.
Figure 21.11
Checkpoint locations.
Place barriers (barrier1) strategically to prevent access to certain areas, and use the direction signs (arrowsign) to assist players in understanding which direction the track will be heading.
You should also place a tommy gun and crossbow accompanied by an ammo box for each somewhere in the vicinity of the start/finish line.
Select a healthKit from the Meshes list under Meshes, Assets, Models, Items, and place it somewhere near the start/finish line as well. Also place a healthPatch object near each checkpoint. You can use a block structure (block1) from the Structures list to put these items on to improve visibility. Make sure to sink the block low enough into the ground so that the player can jump up on it.
Also from the structures list, locate the hovels, and place a few around the track, near it but not too close. Make sure there is a way for a player to get to the hovels, and perhaps provide enough space to hide a vehicle behind them.
Select some trees and rocks from the Meshes list found in Meshes, Assets, Models, Trees, or Meshes, Assets, Models, Rocks. Place them around your map at visually appealing as well as strategic locations—you want to provide places for people to hide during an ambush (like rocks to hide cars behind and so on).
Go on and do the same sorts of things for KoobA. There is a waterfall in a canyon near where you currently spawn (it’s actually to your right as you spawn in), with a bridge leading across the river nearby. This is where you could put your start/finish line. The direction of travel will be to head from the start directly across the bridge and on from there. You probably won’t need more than four checkpoints (other than the start/finish line) to complete the route. If you find you need to adjust the terrain to accommodate a building or something, by all means do it.
Don’t worry about placing the coins. That is something we will handle with program code in the next chapter.
MOVING RIGHT ALONG
Well, things got a little more hectic in this chapter. As you saw, designing a game is about answering questions. Often, the answers are the easy part—coming up with the questions can be tougher at times. Creating a requirements specification for your game is not only useful, it’s almost a mandatory activity.
There are things that constrain our design, and we need to keep those constraints in mind. Every project will have different limits. One example you saw was that you probably shouldn’t consider using Torque to make a massively multiplayer game, at least not with the current version of T3D, version 1.1.
We then looked at the World Editor in a certain amount of detail. You can use it to place and align all the objects that will inhabit your game world. We used it to place some particle effects, in the form of a campfire and a waterfall, as well as some structures that will be useful for game play.
Let’s examine our requirements again. We checked off item 1 right from the get-go. Now we can check off a bunch of other items: 4, 5, 6, 7, 8, 10, 22, 27, and 28. We’ve also done parts of 9, 23, 24, and 25, but they need some programming as well to make them reality.
In the next chapter we will delve into more server-side game play issues, like spawning the player into random locations, getting a vehicle into the world, and triggering events.