Torque 3D | Products | GarageGames.com

Now What?

You've downloaded and installed Torque 3D and your mind is racing with ideas for incredible game designs. Now what?

Start the FPS Tutorial

Working through our 8 lesson FPS Tutorial is the best place to get started...

Get Familiar with this Web Page

Everything you need is accessible from the navigation bar above, without ever leaving this page...

Read These Documents

Get an overall sense of the Torque 3D SDK by reading these documents first...

Jump into the Community

It's huge, and it's there to help you with encouragement and technology...

As a new developer, one of the best ways to gain knowledge and learn the ins and outs of Torque T3D is from the GarageGames community. They are people just like you, with all ranges of experience from beginner to expert.

Forums - Our forums are very active! You’ll find the community is friendly and always ready to help beginners. GarageGames employees are part of the community, so don’t be surprised if company developers answer questions for you.

IRC - IRC (Internet Relay Chat) is a great place to ask questions or help others in a real-time (more ‘social’) chat room setting. Here are some simple instructions for accessing the IRC using Chatzilla, a free Firefox extension, or mIRc, a browser-independent program:

Chatzilla Instructions

Click here to install Chatzilla
After you restart Firefox, go to Tools->Chatzilla
In the command line, type: /attach irc.maxgaming.net
When the IRC connects, type: /join #garagegames
To change your nickname, type: /nick (where “nick” = the name you want)

mIRC Instructions

Download and install mIRC
Open mIRC and go to "Tools>Options”
Under "Connect” Category of mIRC options select your Nickname and an alternative
Select "Servers" under the "Connect” Category and click on the "Add” button
Enter in the following Information into the "Add Server” dialog box:

Description: MaxGaming
IRC Server: irc.maxgaming.net
Ports: 6667

Click the "Add” button to save the IRC Server to your list
Highlight MaxGaming and click the "Select” button to set to your default connection
Select "Options" under the "Connect” Category and click on the "Perform” button
Enter the following information into the Perform commands text box:

/join #garagegame

Click the "Enable perform on connect” checkbox
Click "ok” on Perform and mIRC Options dialog boxes
Click the connect button(Lightning bolt) located under the "File” menu bar

Important Torque 3D Game Engine Concepts

There are some important concepts that all Torque 3D developers should understand. If you are an experienced developer, but new to Torque, a review of this article will save you considerable time (and effort) getting up to speed. If you are new to game development altogether, a few of these concepts may seem intimidating now, but they will make sense once you’ve worked through the Torque User Guide.

Client/Server Architecture

Torque 3D employs a client/server architecture, even for single player games...

Datablocks

In order to facilitate the sharing of data between the server and connected clients, Torque uses what are known as datablocks...

Exec’ing TorqueScript

TorqueScript files, including all the definitions for GUI screens, datablocks, actual gameplay logics, and game assets must be ‘exec'd’ before the engine can use them...

GUI System

Torque 3D includes an extremely robust hierarchical system for game interfaces with complete font and customization support...

User Input

Torque 3D includes a flexible system for capturing input devices and mapping the input to game functionality...

A Beginner's Guide to How Games are Made

What does it take to make a video game - and successfully publish it?

If you are new to game development, this article is for you. Even if you are an experienced developer, there still might be a few tips worth reviewing. For more information on how to use Torque 3D to make a specific kind of game (FPS, RTS, etc), check out our Genre Example articles (in the left sidebar) after you've read this.

Decide on an Idea

Keep it simple. Focus on fun. Your game development will be faster, less expensive, and most importantly, your game will be better...

Establish a Budget

Taking all potential costs into consideration, do you have the budget to execute on your game idea? Chances are good that you will need to purchase some tools or art assets...

Team Considerations

The benefits of a team are clear. It increases your capabilities, helps get a game done faster, and improves QA. But the management of a team brings unique challenges...

A lot of Indie games start as a one-man project, but grow into a team effort (through volunteers, paid contractors, etc). Doing a good job managing the transition can mean the difference between a successfully completed game, and a project that goes nowhere. Team considerations:

Clear Leadership. Interested people working on a project will come with their own ideas and contributions. It can be difficult to stay on course. It will be up to you to be respectful while still being firm on an overall design.
Project Management. When a team is involved, you should expect to spend a lot of time managing people and schedules. Doing this effectively will keep the team working efficiently. Project Management is discussed further in the next section of this article.
Source Control. Source control is discussed at greater length later in this article. An online solution is required for teams.
Communication. Your team will die off if you don't maintain good and regular communications.
Design Documentation. You will need a clear design document. Documenting desired features, art, and other expectations up front is critical. Make sure your team understands your vision.
Business Considerations. How will your team be compensated? How will you share revenue when your game ships? Make sure this is clear to everyone - before they do any work.

Project Management

Set a series of small, achievable, deadlines to keep you moving...

Source Control

Game development involves a lot of experimentation. A source control solution is a must...

A source control solution will allow you to test code, and then quickly revert back to an earlier version of your project. In addition, source control can help track down the exact moment a bug was introduced into your code base. For teams, there are several options available, including Mercury, Perforce, or Subversion. If you are working alone, an auto-archiving solution like Dropbox may be sufficient.

How source control works (Subversion)

Subversion is a good example of a source control solution. It works by keeping a ‘repository’ of your project on a server. As you work, you manually ‘commit’ changes or additions to code (and art) to the server. With each commit, you will be prompted to add a few brief comments describing your work. Other people with access to the repository can see your changes (and your comments) and update their own code base to match (even comparing changes file by file). It is possible to undo something that a team member has committed to the repository at any time, branch into separate code repositories, and much more.

Auto-archiving (Dropbox)

Though not designed specifically for software development, an auto-archive system like Dropbox is a viable alternative to a proper source control solution. With Dropbox, files are mirrored on an internet-based storage cloud. You can setup Dropbox on several machines anywhere, and they will all synchronize any time a file is added or changed. While it does keep a revision history that allows you to go back to an older version of a file, you can't add notes to changes you make. Also, reverting to previous versions of your code, especially when multiple files are involved, is not as automated as a proper source control solution. An auto-archive solution like Dropbox is not well-suited for a team, but it is free (up to 2GB) and easy to setup. For a solo developer, it will ensure that your work is backed up and safe.

Testing and QA (Quality Assurance)

Test early and test often to find bugs and improve gameplay. Painful but absolutely necessary...

Polish

Once you’ve got the major bugs fixed from the QA process, add some polish to your game. Make sure to budget time and money to polish art and sound...

Distribution

Once your game is polished and ready, there are several means of distribution at your disposal...

Marketing

Often overlooked by Indies, marketing is very important. There are free marketing strategies an Indie can pursue, but if possible, save some money in you budget...

As a point of reference, professional game studios often budget more for marketing than they do for actual game development. All too often Indies hope that if they just build a really good game and post it to a popular game portal, people will find it. Unfortunately, this is rarely the case.

Build an audience during development

Ideally, you will start marketing well before your game is complete and ready to ship. You can begin to build an audience early by blogging about your process - what are you working on, what technical challenges have you overcome. Make it interesting by posting screen shots and videos that demonstrate your progress (and don’t be afraid to drop links to those videos in various forums, including GarageGames). You should also consider setting up a Twitter account and a Facebook page. Getting involved in social media may be painful for some, but it is a marketer’s lifeblood. While the number of your followers may be small, when your game finally ships they will be the people most likely to spread the news by word-of-mouth.

Keep marketing after development

Once your game is available to the public (see Distribution above), there are numerous low cost ways to market your game:

Advertise. Facebook ads are cheap and you can target very specific groups of people to create small targeted ad campaigns for your game.
Send your game to some reviewers or prominent review sites. This can be a double edged sword, but if you aren’t ready to do this, then your game isn’t ready to ship. At some point in time you will need to let your baby into the world.
Get involved with your local IGDA chapter. Ideally you’ll have done this before your game ships, but it is never too late to network with other game developers in your area. They will be proud that one of their own has a product to show.
Ask people to help you promote your game. Don’t be afraid to ask people to retweet or share your posts on Facebook. Ask them to play your game and give you an honest review.
Make a promotional video. Make it spectacular and put as much time into it as you can. A catchy video can be just as important as the game itself.
Post on GarageGames. We love to see the games our users are making, and there are thousands of people who feel the same way!

Making a First Person Shooter - Overview

If you have not read How Games are Made, we recommend you start there first.

This article is intended to help new developers understand the scope of work involved in making a First Person Shooter (FPS) with Torque 3D. It is a non-technical overview of the issues involved, including some helpful tips to get you started.

If you are new to Torque, the First Person Shooter genre is the best place to start. Torque 3D comes pre-configured as a multiplayer FPS. A simple 'deathmatch' game should be fairly easy to get up and running quickly (see 'Game Modes' below).

Be sure to check out the new comprehensive tutorial available for free from within our site! It was designed from the ground-up to work with Torque 3D and includes not only basic how-to information, but also design segments to help push your FPS designs to new heights!

Art Considerations

An FPS is expected to run fast. Much of the gameplay's strength is in the ability to respond quickly and accurately to challenges. To accomplish this on a variety of hardware, you will need to carefully consider the artwork used in an FPS. Consider these tips:

Try to keep the mission areas small, broken up by large obstacles which block visibility.
Large open spaces containing many objects are the most taxing on the resources of a video card. Turn down the draw distance and break up large open spaces.
You can use higher-polygon counts (3000-5000) in the player models, because the player does not see his own model during most of the game.
LODs (levels of detail) are essential to performance for all 3D models (player models, objects, buildings, etc.).
Try to keep your collision meshes simple on buildings.
When designing an FPS level, carefully consider map edges and hiding places which may grant an unfair advantage. Players will explore every inch of your map and find ways to break things – a good reason to test early and test often.
Use plenty of vertical space to pack the action in closer. It's easier to find opponents on a smaller map.
Pay attention to little details like signs, vegetation nuances (flowers), fire hydrants, broken vehicles, debris, etc. Build some objects in the scene to explode when shot, like barrels and gas cans. This will all help your game maps feel more immersive to the player.

Camera Controls

By default, Torque 3D is set up for a first person camera so your work is already done. Because the camera is mounted at the eye level of the player the player model itself is not usually visible - we only see hands and weapons.

Torque's default configuration also supports the popular 'Third Person' view where the camera follows behind the player, showing their full body. If you want to include the third person view in your final game, keep in mind that when not showing the player model, you are removing 3000 – 5000 polygons from the rendering pipeline, which will speed up performance.

Game Modes

There are numerous game modes associated with First Person Shooters. The most common are listed below. Expand each for more detail.

Deathmatch

Team Deathmatch

Capture the Flag

Conquest

Single Player Campaign

Unlike the multiplayer modes described above, story telling is essential to a successful single player campaign. Crafting a good story may not require writing a single line of code, but it is still one of the most challenging aspects of making a game.

One way to approach the telling of a story in an FPS is to think of each mission/map as a ‘chapter’ in a book. When the map conditions are met (objectives completed), you can progress to the next chapter by loading a new map. A branching story line can be created by changing which map loads next based on specific conditions, such as objectives accomplished or failed.

Pay close attention to the pacing of the chapters overall, as well as pacing within each chapter - you will want to give players a break in the action from time to time.

Special requirements:
- Logic branching script for story
- Mission briefing screen(s) which outline mission goals
- A mission success or failure screen
- Display of mission objectives and messages as they are completed or failed
- Optional: triggers for pre-rendered or in-game cinematics to assist in story telling

Weapons

A lot of the fun of First Person Shooters comes down to 'cool' weapons, and lots of them!

Balance.
The trick is balance. If any one weapon is overly powerful, multiplayer games can turn into a pointless melee or a mad scramble to get to that single weapon. Of course this can be fun at times, but it can also lead to games which are effectively over in the opening minutes, with players just waiting for the game-clock to end (if they don't leave first).

In general you should strive to balance the strengths and weaknesses of every weapon: accuracy vs. damage vs. repeat rate vs. reload time vs. clip size, etc. Plan to spend a considerable amount of time testing and tweaking your weapons until you get the balance just right. Ideally, you will use outside testers to give you feedback.

Placement.
Careful map placement of weapons and ammo is just as important as balancing the power of your weapons. Again, plan to spend a lot of time play testing your maps to ensure placement is ideal. This is as true for single-player missions as it is for multiplayer.

Secondary fire.
Consider creating secondary fire modes for your weapons. This could be an aiming reticule that zooms in, a special firing mode, or a special type of limited ammunition.

Particle effects.
Great particle effects can make a boring weapon seem cool, but you should not worry about particle effects in the early stages of development. Once you've gotten the right balance and placement, you can begin to think about polishing your effects. When you get to this stage, there are numerous add-ons and resources available for Torque 3D that are well worth looking at.

Weapon swapping.
Cool weapons are not much use if they are difficult to swap. It is probably worth looking at some popular FPS games to see how they do it. It is very likely you will want to tweak the default scripts that come with T3D to suit your needs. Here are some suggestions:

When the player already has a weapon, require a hotkey to pick up and swap to a new weapon that they are in close proximity to. Alternatively, you can have the player pick up the new weapon automatically, but do not switch to that weapon without a deliberate key press by the user.
If the player does not have a weapon at all, the opposite is true. Automatically pick up and equip the weapon when the player is in close proximity.
If the player is in close proximity to ammunition (which is usable by the weapon(s) he is carrying) pick it up automatically.
When a weapon runs completely out of ammunition, swap to the next weapon. If no other weapon with ammunition is in the player's inventory, switch to some backup weapon (knife/fists/pistol) that does not require ammunition.

Persistence

If you want to track character stats and advancement over time, or add features like skill badges (aka 'achievements') and unlockable weapons, you should consider hooking your game up to a persistent database. Some of these features can be achieved without the use of a database, but a database will give you much more flexibility, and ultimately be more efficient.

Special requirements:

Database. Use MySQL or Postgres, with perhaps a PHP middle layer to communicate back and forth to T3D. Store wins/losses and experience associated with a character.
Implement unlockable features, like special skills or weapon parts players can add on to their weapons.

First Person Shooter Checklist

This list will help you start planning for what you'll need to make your own FPS. Many of these items are included with Torque 3D... FPS Checklist

2D Art

Game Icon
1 or more initial loading screens (company/game logos)
Menu buttons
Main Menu background
Launch Menu background
Map/Level Game load screen
Health bar or number
Weapon selection
Ammo counter
Game Over screen
Various particle effects (cheap but good special effects)

3D Art

Animated player model (run, jump, die animations)
Additional player models to add player selection and team capabilities
Enemy models
Weapons (depending on theme)
Environmental scenery (trees, grass, bushes, rocks, terrain)
Buildings/Indoor levels
Props (chairs, barrels, cars, lights, paintings, furniture)

Sounds

Interface sounds (button clicks, etc.)
Menu music
In-game music
Weapon sound effects (often come with weapon graphics)
Explosion sounds
Pain sounds

Code. You will need code to handle the following features:

Input Handling
Player Controller
Camera control
Match create/join
Player scoring
Ammunition counter
Enemy AI (artificial intelligence) and pathfinding
Weapon swapping
Health pickups
Weapon damage
Player/enemy death
Game over conditions

Comprehensive FPS Tutorial

Now that you have a handle on the basics of what it takes to design a FPS, you should read the comprehensive FPS Tutorial that is available for Torque 3D. The best thing about the tutorial is that you can jump through all of the hoops without purchasing the engine!

Developer Tools

You can do a lot with the art, example projects, and script samples that come with Torque 3D, but if you're serious about making your own game, you'll need the tools of the trade.

For your convenience, we've compiled a list of links to some of the most common tools. Prices are estimated and may change over time. Note that students may be eligible for special rates from their college and university bookstores. These versions usually have EULA restrictions but otherwise provide full access to the software.

Code IDEs and Debug Tools

If you are going to write and compile C++ source code, you will need an IDE (Integrated Development Environment). If you are only going to use TorqueScript, then almost any text editor will do.

Visual Studio Express (free) - The best choice for T3D PC development.
Xcode (free - $4.99) - The only choice for Mac OS X development.
Torsion ($39) - Useful for writing, editing, and debugging TorqueScript.

2D Art

Tools for creating textures, menus, buttons, icons, etc.

3D Art

Tools for creating and animating 3D models. T3D prefers the Collada (.DAE) file format for model assets. .DTS is supported as well, but Collada exporters are much easier to find for the for all the tools below.

3D Studio Max (30-day trial, $3495) - Digital content creation tool for 3D models and animations. The game industry standard.
Maya (30-day trial, $3,495) - An alternative to 3DS Max.
Blender (free) - A popular free alternative to 3DS Max or Maya.
Ultimate Unwrap 3D ($49 - $59) - Extremely useful for UV Mapping and format conversions.
Fragmotion (30-day trial, $50) - Cheap but highly functional animation processing tool.
Milkshape 3D (30-day trial, $35) - An easy 3D content creation tool for beginners.

Sound Tools

Tools to create and edit sound effects and music tracks.

Source Control

It is always a good idea to backup your work, but a good source control solution will allow you to test changes made to code, then easily revert to an early revision if needed.

Subversion (free) - If you are part of a team, it’s likely you will want to use a source control solution like Subversion (SVN).
Dropbox (free) - If you are working alone, you should consider an auto archive system like Dropbox to store revisions of your project.
SmartGit/Hg (free) - SmartGit will help you manage all your Git resources. This cross-platform application will allow you to easily manage merges, clones, branches and more all from one application.

Making a Real Time Strategy Game - Overview

If you have not read How Games are Made, we recommend you start there first.

This article is intended to help new developers understand the scope of work involved in making a Real Time Strategy Game (RTS) with Torque 3D. It is a non-technical overview of the issues involved, including some helpful tips to get you started.

Art Considerations

RTS games have large art requirements because they need an abundance of units to deploy and multiple teams to choose from. In addition, you need icons to represent each unit type and the abilities assigned to buildings and units. To maximize performance, the quality of an RTS model can (and should) be much lower than in an FPS because the units are much smaller on the screen. Textures can be smaller as well. Try to keep the number of bones in animations low, and the poly count low (<500).

Camera Controls

While RTS camera controls are not the default in Torque 3D, there are some great add-ons, resources, and forum discussions on the topic of camera control and minimap displays (also referred to as 'Commander Map'). These are well worth looking at for game developers of any level (see 'Add-ons' and 'Forums' in the Navigation bar above).

An RTS camera usually has a locked view angle of about 45 degrees. Typically, the camera is allowed to pan in any direction across the map, and can zoom in or out on areas of interest. Normally there is a corresponding minimap displayed in one corner of the screen. Clicking on the minimap will jump the camera to that location. Also, clicking on any unit will jump the camera to that unit's location. Keep in mind that part of the fun of an RTS is not being able to see everything at the same time. Allowing the player to zoom too far out and see everything will remove that factor. Conversely, allowing them to zoom too far in will cause you to need more detailed models, effecting performance.

Data Handling

In Torque 3D, you can keep all of your unit and building definitions in datablocks or generic objects which inherit from each other. This will let you make many unit definitions quickly and accurately, and tweak things easily.

Some developers take the extra time to create editors for their RTS game data. You can read some of their blogs on our site to examine different approaches to data management.

Resource Management

In an RTS, players will need to scramble to gather resources and build units, as well as upgrade existing buildings and units. You should build a reusable data-driven system that allows you to tweak the costs and benefits of upgrades. Do the same for research trees, which are used to unlock unit-specific upgrades. This will allow you to build any size game you like and spend the time you need to balance it. An RTS requires a lot of balance and tweaking to find the right mix of resource harvesting, time management, and unit economy. For the actual resources, you can use standard fare like metal, rock, wood, or make up your own exotic materials. Part of the fun of playing an RTS is in amassing wealth, even though it will all be gone when the game ends.

Game Balance Through Population Control

One method of controlling the balance of the game in terms of total in-game unit strength is to use the concept of population capacity. Base the total population each player can have on housing units/buildings. The players must build housing units in order to increase their population cap, and it should never be allowed to go over a total predetermined number. On the unit data side, assign a population number to each unit type, except buildings. As the player builds units, their population will count towards the total available population slots. This means stronger or more powerful units will take up extra population slots, and go a long way towards maintaining the balance in a game. In particular you will want to adjust unit costs, attack and defense strengths, and population caps until all the units seem fair and balanced.

Maintain some global counters in TorqueScript for each team's population to keep track of these limits and current states.

Fog of War

Because an RTS is an explore/discovery/build type game, you should also consider implementing 'fog of war.' This is a term which describes hiding unexplored areas of the map, allowing opposing players to build and prepare in secret. The ability to toggle fog of war on and off during the game will be useful during development (to help you balance the game) and may also serve as an ‘easy mode’ for new players as they learn the game.

Real Time Strategy Checklist

This list will help you start planning for what you'll need to make your own RTS. Many of these items are included with Torque 3D... RTS Checklist

2D Art

Game Icon
1 or more initial loading screens (company/game logos)
Menu buttons
Main Menu background
Launch Menu background
Map/Level Game load screen
Unit Information icons (icons which represent your units)
Resource bars
Unit/Building Build Menu
Game Stats screen
Game Over screen

3D Art

Unit models (low poly, only a few animations like move/attack/die)
Building models (low poly, sometimes a build/destroy/use animation)
Environmental scenery (trees, grass, bushes, rocks, terrain)
Buildings/Indoor levels
Props (chairs, barrels, cars, lights, paintings, furniture)

Sounds

Interface sounds (button clicks, etc.)
Menu music
In-game music
Weapon sound effects
Situation alert sounds (base being attacked, etc.)
Explosion sounds
Pain sounds

Code. You will need code to handle the following features:

Camera Controls. Pan, zoom, perhaps rotate
Input Handling. Unit selection and grouping, commands
Unit movement routines and path-finding
Unit selection (drag rectangle to select units)
Unit health and status display
Unit commands (giving waypoints or attack/defend/move orders to units)
Group commands (filtering commands common to all members of a group or selection)
Hierarchical build/unit improvement system (build/upgrade units and buildings)
Enemy AI (artificial intelligence) and path-finding
Mini-map (displays large area)
Fog of War (Hides areas of the map unexplored by the player)
Resource gathering (mining, harvesting, etc.)
Game over conditions
Spawn points. The ability to specify where newly created units will appear for each building
Population cap. A total available number of buildable unit slots.

Documentation. Players will want to see which teams and units are available:

Team backgrounds. Explain the motivations and special background of the teams
Unit descriptions. Describe the unit's abilities and costs and individual upgrade paths
Building descriptions. Describe the purpose and complete upgrade paths of the building, any units it builds, and the upgrades it can unlock.

Making a Role Playing Game - Overview

If you have not read How Games are Made, we recommend you start there first.

This article is intended to help new developers understand the scope of work involved in making a Role Playing Game (RPG) with Torque 3D. It is a non-technical overview of the issues involved, including some helpful tips to get you started.

Art Considerations

An RPG's art requirements are similar to those of an FPS. A major exception is that in an RPG, a player is more concerned with exploring environments. Players will be spending a lot of time in those environments performing quests and interacting with NPCs, and they like to have a lot of area to explore.

Consider these tips:

You can have large mission areas, but you will need to fill up that area with content. Try using a smaller mission area, and twist the main path around on itself and through large canyons, forests, city blocks, etc. to create the feeling of a much larger space.
Use Torque 3D’s Decal Editor to add detail and grit to your game maps. They’re effective and cheap in terms of processing power needed.
Use Torque's Shape Replicator instead of placing the same object in a level numerous times. It will greatly improve performance.
Use Torque's Ground Cover instead of a 3D model with lots of grass or trees attached.
Carefully consider the use of lighting when designing an area. Too many dynamic lights will cause a scene to run slowly, but baking in lighting (static lighting) is cheap (less taxing on system resources) and very effective.
Large open spaces containing many objects are the most taxing on a video card. Turn down the draw distance and break up large open spaces with large terrain pieces, environmental features, or buildings.
Because most RPGs are not multiplayer, you can use higher polygon counts (5000+) for the player models. For models that appear in large groups on the screen at the same time, like a horde of monsters, you should use a lower poly count.
Take advantage of LOD (level of detail) on the player models and buildings.
Try to keep your collision meshes simple on buildings.
If players will be exploring the insides of buildings, consider placing interiors under the terrain and enclosing it completely in a box. This will let you avoid the problem of having too many objects to display and manage indoors. When the player opens the door to a building, teleport them into your “fake” interior under the terrain.
Carefully test your map edges for places the player can break through. Players will explore every inch of your map and attempt to fall through the terrain, go over buildings, or into areas you didn't plan on them being able to reach.
Pay attention to little details like signs, vegetation nuances (flowers), fire hydrants, broken vehicles, debris, etc. You will need very detailed areas to show up in screenshots for your game too. Don't try to decorate every inch of the world, but be sure to create visual interest points.

Camera Controls

RPGs use both first and third person cameras, usually controlled completely with the mouse. Torque 3D comes with everything you need by default - a first and third person toggle camera (as well as the ability to zoom and rotate). While some successful RPGs have been first person only, a third-person camera gives the player the ability to rotate their view while running, without changing direction of movement – something players will often do when running from place to place to check out the scenery.

Combat Mechanics

By default Torque 3D is set up as an FPS so you will need to write some simple combat mechanics for your RPG. You can take advantage of certain FPS features like projectiles for spells or arrows (or even guns if your RPG is a modern/future one). Otherwise it will be easy enough to determine if your target is in front of you and within an acceptable range to attack. If so, you can write your own flavor of combat mechanics and play the attack animation, apply the damage as appropriate, and repeat.

Inventory

One of the most important gameplay mechanisms in any RPG is the management of inventory. Players like to manage their inventories to seek the perfect combination of equipment. You will need to provide an easy-to-use GUI for them to decide what they own, what is equipped, and view the statistics associated with their items. Torque 3D's GUI system is perfectly capable of handling and organizing lots of data in scrollable containers and slots, which makes your work easier.

Skills and Abilities

When designing skills and abilities in Torque 3D, you can use datablocks or even generic Object definitions to store them (using inheritance too). Keep in mind that you will need to create some logic or effect for every skill and ability the player will use. Some of them will be a simple line of text added to the chat GUI, while others might be complex arrangements of particle effects, player animations, and inventory changes. Watch for opportunities to reuse code you've already written when building large systems like this.

Difficulty Levels

You should think about how you want to implement difficulty levels early in the development of an RPG. Anything involving game calculations, from player and enemy health and armor attributes to weapon statistics, should be adjustable to allow changes in difficulty while keeping the game in balance. In an RPG you will likely want to give players a solid challenge without overwhelming them repeatedly, so you should consider building in dynamically-controlled difficulty adjustments to avoid frustrating players (as well as a player-controlled global difficulty setting).

Highly Customizable

The variety of options in both actions and player customization is what draws players to RPGs. For these reasons, you will need to plan for an abundance of items, skills, and abilities. The more unique creatures and characters your player has to interact with in the game world, the longer they will play your game.

Particle Effects

An RPG will usually make use of many different particle effects. These are used for everything from player footsteps to spell effects to rainfall, waterfalls, smoke, fire, teleporting beams, insect clouds, etc. Torque 3D ships with a fantastic particle system editor that you can use to build some truly amazing special effects. These go a long way to making your game world an interesting and spectacular place. You may want to take a look at 3rd party add-ons like ArcaneFX under 'Add-ons' in the Navigation bar above.

Data Driven

You will need to spend a good amount of time building robust systems to keep track of data associated with the topics discussed above - and to help balance your game. RPGs tend to be more data-driven than other types of games. It can be overwhelming, so it is essential that you think carefully about how many (or how few) options you have the time and desire to create.

You should probably hook your game up to a persistent MySQL or Postgres database with a PHP middle layer to communicate back and forth to T3D.

Role Playing Game Checklist

This list will help you start planning for what you'll need to make your own RPG. Many of these items are included with Torque 3D... RPG Checklist

2D Art

Game Icon
1 or more initial loading screens (company/game logos)
Menu buttons
Main Menu background
Launch Menu background
Map/Level load screen
Character Information screen
Health and Energy bars
Equipment or Skill slots
Icons which represent skills, abilities and equipment
Store screen
Inventory Management screen
Skill panel
Quest panel
Dialog screens
Various particle effects (cheap but good special effects)

3D Art

Player model (The more options you provide, the better)
Environmental scenery (trees, grass, bushes, rocks, terrain)
Buildings/Indoor levels
Props (chairs, barrels, cars, lights, paintings, furniture)
Monsters to fight
NPCs to interact with
Weapons to hold

Sounds

Interface sounds (button clicks, etc.)
Menu music
In-game music
Weapon sound effects
Special ability effects
Pain sounds

Code. You will need code to handle the following features:

Input handling. Usually mouse to select/interact things, sometimes to move also
Third person camera controls. Rotate around the player, zoom in/out
First person camera control. Optional, but sometimes popular
Area map (shows player where they've been)
World map (shows player the entire game world)
Skill use and advancement
Inventory management
Item use
Combat mechanics
Player level and experience handling
Spells and abilities
NPC interaction
Enemy AI (artificial intelligence) and pathfinding
Dialog handling
Quests
Treasure and item pickup
Health and Stats
Save Game/Load Game

Documentation. You may need online help or documentation for some items, though it can be handled in the screens where these things appear via the user interface.

Character creation. Explain what each option is so the player can make educated choices
Equipment. Show an item's full description, bonuses, and effects
Skills. Show the effects of every available skill when selected

Making a Racing Game - Overview

If you have not read How Games are Made, we recommend you start there first.

This article is intended to help new developers understand the scope of work involved in making a Racing Game with Torque 3D. It is a non-technical overview of the issues involved, including some helpful tips to get you started.

Racing games come in all shapes and sizes, but T3D gives you the building blocks with a built-in vehicle class and multiplayer framework.

Art Considerations

Above all a racing game must run fast. To accomplish this, think about where you need to show detail, and how best to do it. Here are some tips:

Vehicles are almost always on the screen, so use good detail and poly count on them.
Remove collision from your models where it is not needed. This is a simple toggle in Torque 3D's World Editor.
Buildings don’t need to be more detailed than simple textured rectangles. In many cases they go by too quickly for players to notice. Use a facade approach wherever possible. Unless it is a free-form racing game where the players can go anywhere they like, you have control over the angles at which things will be shown. You may not need to build rear walls or roofs, for example.
Keep your vegetation and scenery extremely simple.
Use simple fences/walls/jersey barriers with minimal collision shapes to limit where the players can travel. Make use of the Shape Replicator and a small number of the same model many times, rather than a large number of unique models.
You can use billboard effects in many places for cheap detail.
If using road segments, make them as low poly as possible for fast collision.
Make use of generous particle effects for smoke, dust, tire burning, etc.
Build a detailed dashboard model for your vehicle if you want to support a ‘Driver’ camera mode.
If you are doing a stadium race game, the audience can be a mix of simple models and textures.

Camera Controls

In a racing game, the player needs to be able to see around their vehicle. Torque 3D comes with most of the camera functionality required to allow this. Many developers don’t take the time to learn about the camera system, but it is quite easy to use. Changing cameras is a simple call, and you can have multiple cameras in a scene to support different camera modes. These modes are usually assigned to easily accessible hotkeys to switch back and forth while playing.

Typically players have the following camera modes available:

First person mode. In this mode they don’t see much of the vehicle at all, but see the necessary speedometer and other dashboard GUIs.
Driver mode. This mode shows the hood of the vehicle, a model of the steering wheel which may be linked to the wheels, and the dashboard.
Follow mode. This places the camera above and slightly behind the vehicle so most of the vehicle is visible onscreen.
Rearview mode. A mode often assigned to a toggle key to quickly see what’s going on behind the vehicle.
Drive-by mode. This mode places the camera up ahead where it can watch the vehicle approach and then pass. This requires you to build predetermined vantage points into your levels.
Rearview mirror. Not so much a camera mode as it is showing the view of the rear facing camera on the surface of the rearview mirror mounted inside the car.

Racing Physics

The built-in Vehicle class in Torque 3D gets you most of the way there in terms of racing physics. If you are building a game with a wide range of vehicles which have their own unique physics and driving characteristics, you have many options at your disposal. A Torque 3D vehicle is comprised of wheels with attached logical springs. You can make copies of and modify wheel datablocks to create many different configurations.

Single Player and AI

Creating AI opponents to race against the player is a great way to add single player functionality, and to practice offline. For this, you would create waypoints inside the track, and have your AI opponents move from waypoint to waypoint, introducing some random variability to their speed and horizontal offset from the waypoint.

Interface ‘sizzle’

Racing games tend to be flashy, with more effort spent on glossy interfaces and heart-pounding sound effects. If you want to stick with tradition, plan to dedicate some extra time designing a snazzy interface with its own animated transitions - and make great use of sounds even when in the menus!

Unique Challenges

While making a racing game can be as simple as laying down a terrain and creating a finish line, there are some unique challenges. For example, you will need to come up with a good way to establish a track the players and AI can follow, and know when they are going in the wrong direction. You will want to create checkpoints that extend the race time and, most likely, some kind of recording system so you can play back a race to the player.

Players will inevitably try to find ways to get off of the course and flip themselves over. You will need to be able to detect when these things happen and be able to respawn the player at an appropriate location.

Racing Game Checklist

This list will help you start planning for what you'll need to make your own Racing Game. Many of these items are included with Torque 3D... Racing Game Checklist

2D Art

Game Icon
1 or more initial loading screens (company/game logos)
Menu buttons
Animated menu graphics
Main Menu background
Select vehicle screen background
Map selection graphics
Race Load screen
Spedometer with moving needle
Countdown timer
In-game steering wheel/dashboard display
Game Over screen

3D Art

Vehicles (need to be specially created as per Vehicle class in T3D)
Racetrack or Stadium
Environmental scenery (trees, grass, bushes, rocks, terrain)
Props (signs)

Sounds

Interface sounds (button clicks, etc.)
Menu music
In-game music
Engine sounds
Braking sounds
Crash sounds
Win/lose sounds
Audience cheering sounds

Code. You will need code to handle the following features:

Input Handling
Player Controller
Camera control (usually have a few different camera modes: first person, third person, drive by, chase cam)
Match create/join
Player scoring
Lap Counter
Checkpoints
Enemy AI (artificial intelligence) and pathfinding
Pickups (speed boost, extra weapons, etc.)
Player/enemy crash and respawn
Race win/loss conditions
High score/Best lap counter
Save/Load functionality to preserve which courses have been finished
Optional customization functionality for vehicles

Making a Massively Multiplayer Online Game - Overview

If you have not read How Games are Made, we recommend you start there first.

This article is intended to help new developers understand the scope of work involved in making a Massively Multiplayer Online Game (MMO) with Torque 3D. However, if you are truly a 'new developer' we strongly recommend against tackling an MMO. MMOs have been built using Torque, but it is a highly complex endeavor. Having said that, we believe that everyone, including the absolute beginner, will benefit from an understanding of what it takes to build and MMO.

Note: MMO is a term used to describe any kind of large persistent online game. It could be an RPG, RTS, FPS, etc. Therefore, to get a complete picture, you should refer to the other 'Genre Example' articles in the left sidebar.

Art Considerations

Creating enough content to populate the massive virtual worlds typical of an MMO is almost always the biggest (and most expensive) challenge in the making of an MMO. In terms of poly counts, how to handle interiors, etc., refer to the ‘Making an RPG’ article in the left sidebar (regardless of which genre underlies your target MMO). In addition, keep these concepts in mind:

Build your characters as multimesh models. This technique is one which calls for all pieces of a player’s wardrobe and armor to be built directly onto the main player model. When the game is running, all of the extra pieces are hidden except for the appropriate pieces. This will allow players to customize their avatar with different armor, clothing, etc. Torque 3D natively supports this technique (known as multimesh/mesh hiding).
Create a wide variety of materials for the player to use for additional customization. The customizations can be selected at character creation time or as the player finds or purchases items in the game. You can swap out the materials using Torque 3D engine calls to change materials at runtime.
Carefully balance your texture size with detail. You can make use of Torque 3D material properties like normal maps and specularity to add detail to lower resolution textures. Remember that the more players being drawn onscreen with separate materials on them, the more textures the video card will need to manage.
Consider allowing the inclusion of guild and/or faction logos on capes/shields/flags. Although these require an additional draw call, they go a long way to making a player feel immersed in your world. Torque 3D supports this through the use of decals, or additional material layers atop normal materials.

Camera Controls

Camera controls in an MMO are going to depend on the type of MMO being built, so refer to the underlying genre articles in the left sidebar. You may also consider more aggressively limiting the draw distance of a camera in an MMO to speed up performance. Better yet, make an option for the player to reduce the camera view distance.

Server Architecture

A crucial consideration when building an MMO is how to setup the architecture for your servers. This is a complex task that is far beyond the scope of this document and will require extensive planning and research by anyone attempting to build an MMO. You will need to make use of an internet-based server to tie all the players together, and run a database to store all the player and game data. Load balancing, live backups, database redundancy, scalability, and security are just some of the important considerations.

More than one instance of Torque 3D can be run on the same physical server in dedicated server mode. This will allow you to run multiple maps (one per instance) from a single server simultaneously.

Optimize

In an MMO, many players and monsters may be in a small area. Therefore extra steps should be taken to optimize code to make it as fast as possible. For example, where possible developers should move code into the engine using c++ rather than relying on TorqueScript. Additional performance improvements mean reducing the number of unique textures and their sizes used on objects, taking advantage of shape LOD (Level of Detail), optimizing collision meshes to use as few polygons as possible. It’s a careful balancing act, as we want variety and detail, but it needs to be thought out carefully.

Data Handling

You will need to create efficient ways to transmit data to and from a server when building an MMO. Think about when you will need to retrieve a lot of data and how you are going to manage it. An example of this is when the player’s stats, customizations, skills, abilities, quest log, and inventory first need to be retrieved from the server as they are spawning. If you show the player right away before this data has been retrieved, they will very likely experience some stuttering or hiccups as the game client processes a large amount of logic. One way to counteract this is to show something like a ‘spawning in’ particle effect while the player is spawning or by showing a loading GUI.

Similarly, you can create an animated loading screen when loading a new map area and streaming in players and objects that will need to be shown when the player first spawns. Torque 3D includes all the needed control types (images, text blocks, progress bars, buttons) you will need to build something entertaining for the player to look at while the map is loading. Including a gameplay tip or a bit of game lore on a loading screen is also a great use of the space.

Torque 3D provides useful data structures for you to use in the form of Datablocks or Script Objects. Users have posted additional data structures (ex. advanced array implementations) on GarageGames Resources page (you can find Resources under 'Add-ons' in the Navigation bar above).

Persistence

Storing and retrieving data is a defining element of an MMO. Common approaches involve the use of a server-side database such as MySQL, SQL Server, SQLite, or Postgres. Some users have built data layers into Torque 3D’s engine directly. Other approaches use Torque's built-in HTTPObject to access web pages or web services to handle data transactions. Whichever way you choose depends on your comfort and skill level. Some of the most efficient and stable methods include an event-driven database layer built into the server to handle lots of data transactions, mixed with client-side HTTPObject access layers to get basic information like account authentication and player lists.

While there are many different opinions and preferences on the ‘best way’ to handle persistence, your players only are concerned that they can log in and out of your game and that all their items and stats are intact when they do.

User Input Customization

An MMO might have a very large number of onscreen widgets, hotkeys or macros assigned to various gameplay functions. Skilled players take the time to learn them and often wish to reassign keys and controls to suit their needs. Torque 3D has an extremely robust command mapping system you can use in-game to allow the player to do this. It will take extra time for you to setup your commands to be mappable, but it is well worth it.

MMO Checklist

Refer to the checklist for the underlying genre of your MMO, in addition... MMO Checklist

2D Art

Game Icon
1 or more initial loading screens (company/game logos)
Menu buttons
Main Menu background
Launch Menu background
Map/Level Load screen
Character Information screen
Health and Energy bars
Equipment or Skill slots
Icons which represent skills, abilities and equipment
Store screen
Inventory Management screen
Skill panel
Quest panel
Dialog screens
Various particle effects (cheap but good special effects)
Social grouping panels for guilds, fellowships, etc.

3D Art

Player models (The more options you provide, the better)
Environmental scenery (trees, grass, bushes, rocks, terrain)
Buildings/Indoor levels
Props (chairs, barrels, cars, lights, paintings, furniture)
Monsters to fight
NPCs to interact with
Weapons to hold

Sounds

Interface sounds (button clicks, etc.)
Menu music
In-game music
Weapon sound effects
Special ability effects
Pain sounds

Code. You will need code to handle the following features:

Input handling. Usually mouse to select/interact things, sometimes to move also
Third person camera controls. Rotate around the player, zoom in/out
First person camera control. Optional, but sometimes popular
Area map (shows player where they've been)
World map (shows player the entire game world)
Skill use and advancement
Inventory management
Item use
Combat mechanics
Player level and experience handling
Spells and abilities
NPC interaction
Enemy AI (artificial intelligence) and pathfinding
Dialog handling
Quests
Treasure and item pickup
Health and Stats
Chat, private chat, chat filters
Persistence (Saving/Loading of character and world information)
Area transitions (portalling/jumping to other maps)
Friend functionality
Grouping
Guild functionality
Stores
Ability to customize the user interface/hotkeys
Emoticons and social animations (bowing, waving, etc.)

Documentation. You will want to have most of this information available on a website which is used in conjunction with your game. This is important as both players and potential players will want to explore aspects of your game beforehand and even after becoming players.

All character skill/class/ability descriptions
World area descriptions. Use images and place descriptions as well as suitability for levels of experience
Monster descriptions
User Interface. Lots of images showing the user interface

An Overview of Torque Multiplayer

This article expands upon topics discussed in Important Concepts. We recommend you read that article first.

Torque’s networking model is famous and has been optimized for highly performant multiplayer games. Right out of the box, any Torque game can be a multiplayer game! Almost all of the details for setting up a multiplayer game are handled for you already. With stock Torque 3D, you can easily make a game that can act as a host for other players, connect to a hosted game, or run in ‘Dedicated Server’ mode.

Joining a game

When a player first joins a multiplayer game, there is a complex loading and staged synchronization process that occurs between his client and the game server. The client is told what the current map is, and how many players are on it. The server sends down all the datablocks to the client, which then loads the map definition and, if necessary, performs any lighting tasks that need to take place. Once all this is done, the client notifies the server that it is ready to join the game. The server then spawns the player, and tells the client that it now has control of an object (player, car, starship, etc.) in the game.

Server Authoritative model

From here on in, the client is doing a combination of telling the server what it would like to do, and making educated guesses about what is going on in the game. Ultimately, the server is the final authority on what is allowed and what in fact is occurring in the game. If a client ‘guesses’ wrong, it will make corrections when it receives updated information about the game state from the server. This is called a ‘server authoritative’ networking model.

Example:
When a player presses a key to move forward, his client will tell the server that he would like to move forward. The client assumes that the server won’t have any issues with that, so it immediately begins to display that forward movement on screen. In the meantime, the server receives the move request, determines where the player moved to, and tells all the connected clients (i.e. all the players in the game) where the player now is. All clients get this information and update the scene accordingly. The original client who requested the move will make any corrections between its original guess and what the server is telling the client it actually did.

Doing the math...
All this happens an average of 33 times per second or faster, across multiple network connections, and is repeated millions of times during a game session. Torque uses numerous methods to account for errors, internet lag times, and to make good client side predictions. It is an extremely complex system of algorithms and works quite well. All the source code for this is included with your purchase of Torque 3D, but any modifications should be done with extreme care.

Map Changing

Map changing happens when the conditions of a map/level are met and a game is over. This could happen in response to a game time limit being met, a score limit being met, or any other event defined by the developer. When this event takes place, the server notifies all the clients that the map is switching. It then loads up a new map, and tells the clients to reconnect. At this point, all the map loading stages occur on the clients as if they were connecting from scratch.

Server Connections

An important consideration in Torque multiplayer is that every running instance of a Torque map/mission/level needs its own server instance. The server instance can be a dedicated server instance, or it can be a player who is hosting a map while playing at the same time. A server instance cannot run multiple maps, or different sets of players playing the same map. However, it is possible to run multiple server instances on the same physical machine, if they are running on different ports. Stock Torque 3D does not ship with a way to automatically start new server instances; this is an advanced function which requires interaction with the operating system. An advanced programmer (with at least some networking expertise) should be able to modify Torque 3D’s source to accomplish this if desired.