ubiqvisuals

Login Form




3D Action Adventure Kit Level Design

Overview

This document will be covering a handful of various subjects surrounding the topic of Level Designing for the 3D Action Adventure Kit.  Some of these subjects include action adventure level design process, camera techniques, checkpoint system implementation, and triggers.
Assumptions
This document will be assuming you understand how to create 3D assets such as .dts and .dif models and how to place these assets in the editor. If you do not know how to do this, there are plenty of resources found on the Garage Games Wiki that will be able to help you (http://tdn.garagegames.com/wiki/Torque_Shader_Engine).

Note: This documentation is specific to TGEA, not the newest T3D build. Most of the workflow is still relevant but specific lines of code called out or editor shortcut keys may no longer be relevant.

Ubiq Visuals Level Design Process

If you have never designed a game level before, it may seem like an easy task.  As soon as you sit down to start, it may seem like an overwhelming task.  To be honest it is quite a big job and so much more goes into level design that 99% of the players will not even notice.  And that's the whole point.  As a designer, you want to immerse the player in the world you have created for them.  Anytime the player feels like they are in a "designed" space, or something appears to not belong in the world they're in, it will break their suspension of disbelief and they will no longer be immersed in the experience.  Here at Ubiq Visuals we want to share some of the design processes we used to create the 3D Action Adventure Kit Demo Level.  We hope our techniques and experience can be passed on so you may start building your own worlds as quickly and effectively as possible.

Always Start On Paper
Every good design starts out in the best medium for the rapid formation of ideas: pencil and paper.  It is important to get into the habit of sketching out your ideas on paper, because it is by far the fastest way to transfer ideas from inside your head and into the real world so that others may see.  Far too often individuals will go straight to 3D or building assets in the engine.  There is nothing wrong with this approach; however it is a much slower design process.  The reason it is slower is that when you are establishing your high level concepts, building 3D assets and placing them in 3D will naturally take longer than sketching.  Another great advantage of paper is that you can write in little notes or small diagrams of where the player might be traveling, and it can all be done with just the scribble of a few lines.  In 3D this would take a considerable amount of time longer.  After all, at this first stage you are only starting to get a feel for the flow and design of the level so there's no need to get caught up in moving stuff around in 3D yet.

Once your high level game flow has been designed on paper, the next step would be trying it out in the game engine using rough building-block assets to get a sense for the scale and pacing of your design.

design_sketches

Rough Out the Terrain
Depending on the nature of your design, you may need to do less or more terrain landscaping. All I can say for this step is don’t spend too much time editing the terrain. To get the terrain really polished requires a great deal of massaging and time. It’s best to just rough out the terrain and come back to polishing it up at the very end.

Rough Building Blocks (Who Doesn’t Love Lego?)
The easiest way to prototype in Torque once you've sketched out your level design on paper, is to use basic shapes to block out the level design.  The image below shows all the pieces used to prototype our demo level.  As you can see, it is basically made out of only a handful of simple textured shapes.  If you have a rough idea for the art direction, texturing these basic shapes can really help you get a good feel for what the final space will be like.

rough_assets

The next few pictures show what our demo level looked like while we were designing it using the simple shapes shown above.  You can see some parts of the demo remain unchanged in the final version, while other parts were modified drastically or scrapped.  Make sure to focus on the player flow through the level.  Make sure to write down notes (don't just keep mental notes as details are often forgotten) about the pacing, difficulty ramping, vantage points, anticipation, and confusing spots in the design.  Make sure you do not to get caught up in the details as the purpose of this step is to just rough out the general "feel" of the level.  The specific designs of the architecture or props can be left for later.

eg1

eg2

eg3

Play Test - Throwing your Baby to the Wolves
Before you get too far into your level design, make sure to have people play it! After all you’re making a game for other people to play, so having other people play your creation is a great way to receive early feedback on what parts were awesome, and which parts need rethinking. Any good designer’s creed goes something like “design, user test, start over, design, user test, start over again, user test… etc.” It is simply too easy to get caught up in your own design and not be able to see it from a 1st time players perspective. One part of the level you find extremely easy or intuitive, others may never be able to do or figure out how to solve.

Some best practices we live by:

  • The earlier in the design process that you can have people play something, the better. This will help you nip bad designs at the bud.
  • Interrupt the play tester as little as possible (if possible, do not interrupt them at all). Anytime you give the player a hint, you are undermining your design. Remember that you won’t be there when strangers are playing your game on their computers at home.
  • Video Record the play test. Having access to the video files that allow you watch your players play through to see where they got stuck or what they tried to do and failed is invaluable. It is guaranteed you will not be able to jot down everything you watch while observing the play test first hand which is why you will want to have it recorded for the records. We use CamStudio (open source) which works well for real-time video capturing.
  • In addition to video recording, it is also useful to set up a microphone and have the player narrate their thoughts while they are playing (if possible, have this audio sync with the video you are recording). These internal comments can give you additional insights into what the player is thinking that may not be evident from their actions on screen.
  • At the end of the play test, have a 1:1 conversation with the play tester. Ask questions such as “what part did you find the most fun? What part did you find the most frustrating? If you were to pick the top 3 things that needed work, what would they be?” It is important to record these answers and share them with your team. It’s a great motivational boost after months of work to hear what players playing your game have to say about it.
  • We highly recommend you read this wired magazine article titled “Halo 3: How Microsoft Labs Invented a New Science of Play”. The article goes in depth into the multitude of ways Microsoft gathers play test data and if you want to become a great game designer, you need to understand that there’s much more to game design than you think. http://www.wired.com/gaming/virtualworlds/magazine/15-09/ff_halo

Iterate, Iterate, Iterate – Don’t Be Afraid to Kill Your Darlings
After your observations from the play tests, more than likely you will need to scrap a lot of your design or change a great portion of it. Don’t be scared! That’s completely normal. Any design in any medium always takes a great deal of iteration. The important lesson here is to rapidly produce a design, have people try it, keep what’s good, and get rid of what’s bad. Don’t become too attached to any particular design because if it’s not working, it’s best to just scrap it and start over, rather than try to patch up a failing design.

Wash, Rinse, Repeat
Now that you’ve made your design iterations from the first play test it’s time to play test again. If possible, have a new sample of play testers try out your design (as the ones who have already played your game will now be biased). Continue to repeat this process until your play testers are able to easily progress through your level design and have positive feedback for you.

Okay Now it’s Time to Make Things Look Pretty
Once your design is solid you can start creating your final art assets. Break down your level into smaller chunks and build these chunks in whatever 3D authoring program you choose. Replace these chunks one by one as you build your level until all your final assets are in. Be sure to read the tips regarding asset creation at the end of this document.

Save the Terrain for Last
Now that all of your 3D models are in place in the game, you can polish your terrain based on where the 3D models are placed. The terrain can be the hardest thing in Torque to fine tune, so you want to make sure that all your level geometry positioning is final.

Sit Back and Enjoy
Congratulations, you’re finished! Level Design is not the quickest or easiest journey in the game industry but watching another person play through something you’ve created can give you some of the greatest satisfaction that can be had in the industry.

Screenshots taken of the polished demo level from the same camera angles that you saw the earlier “building block” versions of.

final1

final2

final3

Special Triggers

There are a handful of new triggers that have been implemented with the 3D Action Adventure Kit. Let’s take a look at what they do.

saveTrigger
If you look at almost any adventure games made after 1984 you will find the ability to load a checkpoint upon death is a standard feature. We wanted to include this feature as well. We have kept consistent with the Trigger based implementation and you will use a saveTrigger datablock for this type of trigger.

The saveTrigger works is essentially a checkpoint system. As soon as you enter a saveTrigger, the code will record your player’s exact position and camera position in the level. The next time your player dies, they will be returned to the last checkpoint positions they passed through.

Something you need to be thoughtful of is that saveTriggers do not save what camera mode you are in. It will spawn your player using the default camera. If you want to have it return to the camera mode appropriate for that area, you will need to create the appropriate camera trigger and place it directly under your saveTrigger so that when the player spawns, they will immediately fall into the cameraTrigger and the appropriate camera mode will be enabled.

climbTrigger
We wanted to make it easy for designers to control what surfaces can be climbed and what cannot be climbed. Climbing is controlled using a climbTrigger. Any geometry inside a climbTrigger can be climbed on by the player. This allows the designer to specify if they want only a small portion of an object to be climbable or they want everything in the level to be climbable (this could be done by surround the entire level in one large climbTrigger). It is possible to turn on/off climbing on specific pieces of geometry individually and this will be covered in the Geometry Specific Controls section (below).

killTrigger
The killTrigger is used to keep the player from going places they shouldn’t be. As soon as the player enters this trigger they will die instantly. There are times where you may not want the player to die instantly, but to die the next time they touch something (for example if the player falls off a cliff you wouldn’t want them to die in mid air, you’d want them to die when they hit the ground). For this, you can add the Dynamic Field nextCollision and set it to 1. What this does, is as soon as the player enters the killTrigger, the next piece of geometry they touch will kill them.

damageTrigger
The damageTrigger is used to simulate damage over time. This could be used if the player walked into an acid lake or was affected by poison. While inside the trigger, the player receives 10 pulses of damage per second. You will need to specify the amount of damage using a Dynamic Field with the label damage. The minimum and default value is 0, which would apply no damage. The value has no maximum but the player has 100 health by default so you can do the math and figure out that any number higher than 10 will result in a very quick death.

Wall Hug PhysicalZone

The way Torque’s bounding box system works will allow the player to walk on anything as long as 1 pixel of the bounding box is touching a surface. Unfortunately you may want to require your player to navigate along a small ledge using the wall hug and this bounding box issue will prevent that. If you want to “cheat” the effect and make the player “fall off” a ledge, you can do so by implementing a PhysicalZone. The PhysicalZone can be found under Mission Object>Mission>PhysicalZone (right underneath Trigger).

castLightmapShadows

You may come across a circumstance where you want to block the player from going to a specific area by using an invisible wall. You create an invisible object and place it in the map. Unfortunately you will find that when you relight the scene, Torque still casts shadows for these invisible objects. We have created an object attribute called “castLightmapShadows” which can be found in any object’s attribute list. If this attribute is enabled, the object will not cast any shadows.

Geometry Specific Controls

There may be times when you want to turn off the ability to perform specific player actions on a piece of geometry. For this reason we have created three checkboxes that are part of all mission objects. These attributes allow you to turn off/on the ability to climb on a surface, grab the ledge of a surface, and hug against that object.

HUD messages

Often when it is the players first time playing a game, you need to communicate messages to them (e.g. How to play). The tutorial HUD system makes displaying messages easy.

The tutorial HUD system that we have implemented in the kit uses the TutorialHUDTrigger datablock to display HUD messages. When a player walks inside of this trigger, the HUD will display the appropriate HUD message. The message displayed is controlled by the Dynamic Field tutorialType. The value of this field is controlled in script and you can set it to be whatever you’d like. The script for controlling this is found in \scriptsAndAssets\server\scripts\triggers.cs. If you scroll down in the triggers.cs file, you will find a section labeled TutorialHUDTrigger. Inside this section of script is the function:

TutorialHUDTrigger::onEngerTrigger(%this, %trigger, %obj)

Inside this function are a handful of if statements. What these if statements are checking for are the Dynamic Field values for the tutorialType field.

For example, if there is a TutorialHUDTrigger with the Dynamic Field tutorialType with a value of move, the script will display the move.png image.

 if(%trigger.tutorialType $= "move")

{
tutorialHUD.setBitmap("~/client/ui/tutorial/move.png");
}

If you want to create your own HUD messages you just need to add another if statement and point it to your new image. You will want to make sure the image is the same height and width as the current tutorial HUD images.

General Editor Tips

We’ve spent a lot of time in the editor and before we finish up here’s a few tricks we’ve been using to make our lives easier.

Deleting Objects
Sometimes you may notice that the Torque Editor has trouble figuring out which objects you have selected. This can get especially frustrating when you select an object, hit delete, and then it deletes more objects than you wanted to delete. Also the fact that there is no undo for deleting objects can increase frustration when this happens. To avoid this, we have found that when deleting an object, simply name it something easy to remember such as “delete me” and then move it to some arbitrary far away position in your scene. Next, whenever you close your mission file, you can open up the .mis file in a text editor and do a search for the “delete me” object. When you find that object’s block of text you can simply delete it. Any objects named this, you know you can simply delete them and not have to be worried that you will be deleting any unnecessary objects by accident.

Reducing Relighting Times
It can be very easy to end up with a scene that is heavy with geometry. The more geometry in your scene, the longer your relight will take, and the worse your frame rate can become. Something we have found useful is to keep all the major “sections” of your level in Sim Groups. Once a section is done and you do not need to worry about designing it anymore, you can open up your .mis file in a text editor, and cut out everything that is included in that particular Sim Group that you are no longer working on. Now when you relight your mission you don’t have to repeatedly relight a section of your level that you are not concerned with at that moment. Make sure when you cut out the Sim group that you paste it into another text file so that you can paste it back into the .mis when you want to see everything back together again.

Relighting inside the Mission Editor
If you are inside the editor and you are happy with a particular level design and want to see it relight, quit the mission and reload the mission instead of relighting from inside the editor. The reason for this is that if you relight the scene inside the mission editor and liked what you see, the next time you open your map you will have to relight again (even though you didn’t change anything!).

Remove the Water Block
If your scene has a Water Block underneath the terrain that you aren’t using make sure you delete it. It can be quite a resource hog even if it’s not visible.

Proper Naming
Do yourself a favour and name the objects in your scene. When your scene starts getting messy and it’s hard to select objects (because there are so many other objects and triggers in the way) it will make it much easier if you can see the name of the object you want to select, and find it in the object list rather than trying to pick it from the editor by moving your camera around.

Don’t Use Too Many Separate DIF’s
We have found that having too many separate .dif objects in a scene can cause significant frame rate drops. To help correct this, consolidate as many .dif objects as you can into 1 .dif.

Stairs and Ramps
You may or may not have noticed that all of the stairs in the 3D Action Adventure Kit have invisible ramps on top of them. The reason for this is the player model, when it finds a new height will “pop” up to the new height. This can look very unpleasing and for this reason, we have used invisible ramps and placed them over the stairs. This way, we get the visual illusion of having stairs but without the player “popping” up the steps.

Constructor Split Epsilon, Split Tiny Epsilon, and Alternate HSR
If you are having trouble with .dif faces disappearing when you export your Constructor .dif files, you may want to play with these settings in the Export preferences. Turning up the Split Epsilon to something like .8 and the Split Tiny Epsilon to .9 can sometimes help alleviate fragile faces breaking. Also, sometimes turning on Alternate HSR can fix broken faces that you can’t seem to fix manually.

Conclusion

Hopefully after reading this document you have a better understanding of level design, and how to use the 3D Action Adventure Kit specific objects. If you have further questions feel free to post them on the Ubiq Visuals Support Forums. Happy Level Designing!