Models, Controllers, Properties
From C4 Engine Wiki
When coming to the C4 Engine from other game engines, you may be confused by the re-use of some terminology you might have seen used in other ways. You may also be befuddled by the way the pieces are put together, as it is very different from some other engines out there.
Contents |
Code and Data
It's important to understand that C4 makes associations between code and data explicit in almost all instances. This means that the code will not be likely end up working on data it wasn't expecting to work on. The drawback is that certain changes (such as adding a new NPC type) will require at least small code changes to happen in the game, and can't be made entirely by using the tools. In one sense, this probably protects Terathon from someone taking the distributable binary tools, and making a whole new game as a "total conversion."
Scene Graph, Node, Property and Connector
C4 is almost entirely structured around a rich scene graph, with support for portals and cells (called Zones). The player will move around as a node in this scene graph. Geometries the player can interact with are attached to nodes as well. The sample game, when colliding with geometries, will look for the node that goes with the geometry, and custom properties thereon, to figure out what to do about the collision. See Defining a Custom Property for how to attach arbitrary data to a scene graph Node, and how to expose it to the editor.
Scene Nodes can also have Connectors, which are a way to reference one Node from another. These can be created at runtime in the World Editor, or defined at code time by the Node subclass (or a combination of both). For more information, see Using Connectors. Code that expects a specific connector (such as a Controller on a Node) finds the Connector using the fourcc.
Controller
Players, NPCs, and other objects in the world will move around by changing the transform of the Nodes. However, in some rendering APIs, the scene graph is only for rendering, and the rest of the application will drive the scene graph, and treat the scene graph Nodes as data structures that the application delegates to. Not so in C4. In C4, the Scene Graph largely owns the action, and code that wants to modify the behavior of Nodes to make them live, will likely be attached as a Controller to a Node. Because each Node can only have one Controller, you will have to express behavior composition (this thing both sways and rotates) either as multiple parameters on a single, rich controller class, as multiple nested nodes, or using application-level code constructs that aren't visible to the scene graph. See Defining a Custom Controller for how to make nodes move. Note that you can still run the rest of the application separate from C4, you just have to arrange for hand-off of the appropriate data between the application and C4.
Model
Last, there is the concept of a Model. To place an animated .mdl file in a scene, you have to register a Model, and give a mdl that Model type. Model types also have default controllers (i.e., the PumpkinHead model might have a PumpkinNPC behavior controller), although this can be overridden in the editor. Thus, if there is a specific mdl file you want to use and animate in your game, you should register a Model for this mdl. This will let you place it in the editor. This is different from how you may think of Models, where you'll have a generic "NPC" model, which has a separate "model" field that lets you pick the model. That same functionality is expressed in C4 by putting the generic NPC behavior in a Controller, and then registering one Model per kind of model you might want to use. See Creating a Model for more information on how to do this in the world editor.
So, the Model node serves as the root node for a model. It can have any number of sub-nodes which can be geometries or any other kind of node (even other entities), and they may have sub-nodes as well. This creates a tree of nodes that make up your model.
Additionally, the Model node has a couple pieces of functionality that are useful for things that move around a world, like characters. First, models can have an animator tree attached to them to play/blend animation files. Second, a model will automatically re-parent itself to the zone that it's in so you don't have to worry about that when, for example, a character walks from one zone into another.
Note that any node can have a controller. Models usually have a controller, and a plain Geometry can have a controller, too.
