Skip to content

Project Manager Guide

Jump to bottom
Peter Robinson edited this page Aug 19, 2026 · 2 revisions

Introduction

The Project Manager is where a game begins and where its pieces are kept track of. It makes new projects, and it shows you the modules a project is built from — your own game code, and the reusable ones you have pulled in.

It is the first thing you see. Torque2D opens on the project picker, and everything else — the Gui Editor, the Asset Manager editor, the console — is reached from a project once one is open.

This guide covers version 4.0 Early Access 4.

A word on the word "module". A module is a folder with a module.taml file in it that says what the folder contains. Your game is a module. The audio system is a module. An art pack you import is a module. That is the whole idea, and it is enough to get going — the Module Manager Guide documents the underlying system in detail, but it is written for people building tools and you do not need it yet.

Starting a project

When Torque2D opens you get the project picker: a card for every project it finds, plus a New Project card.

A folder becomes a project by having an AppCore module in it that carries a Project name, a description and an icon. That is what the picker is looking for and what it draws on each card.

The New Project form

Six things, of which two matter and four are easy.

Title — what your project is called. This is the name on its card, so write it for people to read. Spaces and punctuation are fine.

Directory — the folder to make it in, inside your Torque2D folder. It has to be empty or not exist yet, so nothing you already have gets written over.

Game Core — the template your game is copied from. Blank Game gives you a window, a background and some music, ready to be replaced with your own. Any module in the library marked as a game core shows up in this list, so a studio can add its own starting point.

Module Name — this is the one to think about. It becomes:

  • the folder your game lives in,
  • the module's ModuleId,
  • the namespace your create and destroy functions hang off,
  • and the front half of every asset id in your game — MyGame:hero.

So: letters, numbers and underscores only. It fills itself in from your title with Game on the end — "Coin Collector" gives you CoinCollectorGame — and follows the title until the moment you type your own, after which it is yours. PlanetXGame in the demo game is the same convention.

Author — who to credit. Left empty, Torque2D is credited. Changeable later.

Description — a sentence saying what the project is. It shows under the title on the project card.

What you get

A folder containing your game module and three others it needs: AppCore (start-up and window), Audio (sound and music), and a themes folder holding the look your GUIs use. Open it and you have a running game — an empty one, but it runs.

The project view

Once a project is open, the Project Manager shows it in two parts.

Game is your project's own modules: the one you made, plus AppCore, Audio and anything else living in the project folder. This is what your game is made of.

Library is the modules you can bring in — the ones that ship with Torque2D, plus anything you have added. Importing one copies it into your project, so a later change to the library leaves your game alone.

Each module is a card showing its name, description, version and author, with what it contains underneath.

Working with modules

Making one

New Module asks for a name and a template to copy from. The name follows the same rules as Module Name above, for the same reasons — it is going to be a namespace and an asset-id prefix.

Splitting a game into modules is worth doing once one part of it stops being about the game: a save system, a dialogue engine, a pack of art. Those can be imported into your next project. Things specific to this game are usually happier in the game module.

Editing one

Edit Module gives you:

  • Module Name — see the warning below before changing this.
  • Description and Author — free text, shown on the card.
  • Version and Build — your numbers to use as you like. Other modules can depend on a particular version, so raise Version when you change something that others would notice, and Build for everything else.
  • Type — what kind of module this is. A module typed Game Core appears in the New Project form's template list; Art Pack marks a bundle of art. Leave it alone unless you are making one of those.

Dependencies

A module can say it needs another. Add Dependency asks which module and which version, and from then on loading yours loads that one first.

The demo game depends on Audio and ScreenFade this way. If your game uses sound, it needs to say so here — otherwise the sound module may not be loaded when your game asks it for something.

Declared assets

This is how a module tells the engine where its assets are. Each entry is:

  • Asset Directory — the folder to look in, relative to the module.
  • Extension — which files count, such as image.taml or particle.taml.
  • Scan Sub Directories — whether to look in folders inside that one.

The trap worth knowing. Assets are found only if their filename ending matches the extension you declared. A folder declared with extension image.taml will not pick up a file named spaceship.asset.taml — nothing errors, the asset simply is not there, and the first you hear of it is a sprite with no picture. If an asset you can see on disk does not exist as far as the engine is concerned, check this first.

Once assets are declared, you edit them in the Asset Manager editor, not here. See the Asset Manager Guide for the asset system itself.

Renaming a module

A module's name is not just a label, and renaming is not just an edit.

The ModuleId appears in three places that all have to agree:

  1. module.taml, as the ModuleId.
  2. Your module's script, because the engine calls <ModuleId>::create() — the id and the namespace are the same word written twice.
  3. Every asset id, in script and in every .taml that refers to an asset — <ModuleId>:<assetName>.

Change only the first and the module still loads, still shows its new name everywhere in the editor, and quietly does nothing: create never runs, and its assets resolve to a module that no longer exists. Nothing looks wrong.

The Project Manager handles all three for you — a rename is a pass over the module's own source, not just its definition file. Renaming by hand, by editing module.taml in a text editor, is the way to break a project, and it breaks it silently.

Where to go next

Clone this wiki locally