Collada

The Collada subsystem loads COLLADA content files created by external tools into the framework.

This subsystem is unusual in that it needs to know about all of the other systems. For instance, it loads geometry from a COLLADA file by directly calling the graphics sytem to create and populate a mesh object. This goes against my philosophy of avoiding subsystem interdependencies.

To get rid of these dependencies, I split the Collada module into several different assemblies, one for each supported subsystem (this is my plan, I am currently lumping everything together to speed up the coding). The code to load graphics-related elements is stored in FlatFour.Graphics.Collada.dll, physics elements go in FlatFour.Physics.Collada.dll, and so on. The main subsystem, contained in FlatFour.Collada.dll, is responsible for finding and loading all of these driver modules at runtime and handing off elements when a file is loaded.

Breaking everything up this way buys me several things:

• I can add new subsystems without needing to modify existing code: just add another *.Collada.dll and it will automatically get picked up and used.
• I can remove any subsystem that I don't need: just remove the corresponding *.Collada.dll and everything will continue to work.
• I can remove support for Collada entirely by removing *.Collada.dll, perhaps to replace it with an optimized binary format for a production release. No code needs to be changed.

OpenGL

The Flat Four OpenGL component provides a common, simple interface to get OpenGL up and running on Windows, MacOS X, and Linux/X11. It is implemented as a fully-managed .NET assembly: one binary, many platforms with no recompiling.

If you are looking for a full-featured graphics system, you might want to check out the Graphics component (hardly full-featured at this point, but I'm getting there) which provides (someday) mesh- and shader-based rendering over both OpenGL and Direct3D.

The OpenGL component is intended for developers who want to write small, lightweight 3D applications that can run on multiple platforms.  It requires the Tao.GL module, which provides a binding to the full API, and a windowing framework such as the Flat Four Platform component (see example), System.Windows.Forms (see example), or any toolkit that can provide a window handle.

The OpenGL component does not include a mapping to the full OpenGL API (use Tao.GL for that) or any type of rendering objects (use the Graphics component instead). Like I said, small and lightweight.

Platform Abstraction

The Flat Four platform component provides basic platform services -- such as window and display management, event handling, and user input -- as a common, simple interface across Windows, MacOS X, and Linux/X11. It is implemented as a set of fully-managed .NET assemblies: one binary runs on many platforms, no recompilation necessary.

using FlatFour.Platform;
 
public class VerySimplePlatformApp
{
   static void Main()
   {
      IPlatformSystem platform = PlatformSystem.Start();
      IPlatformDisplay display = platform.OpenDisplay("My Display", 640, 480);
      platform.RunEventLoop();
      platform.Dispose();
   }
}

The Platform System is developed and delivered as part of the Flat Four Framework (coming soon :). You can use it independently, in conjunction with the framework, or pair it up with FlatFour.OpenGL and Tao.OpenGL for a lightweight, fully-managed 3D development platform.

Status and Plans

In its current state, the available platform services include:

• create desktop windows
• run the application event loop
• dispatch window resize events
• dispatch idle time events

Read on to learn how to get started with the Flat Four platform services.

using FlatFour.Platform;

public class MyApp 
{
   [STAThread]
   public static void Main() 
   {
      PlatformSystem.Start();

      // ...application code goes here...

      PlatformSystem.Instance.Dispose();
   }
}

// Create a display with a 640x480 pixel client area named "My Display"
IPlatformSystem ps = PlatformSystem.Instance;
IPlatformDisplay display = ps.OpenDisplay("My Display", 640, 480);

ps.RunEventLoop();

void OnResized(object sender, EventArgs e)
{
   IPlatformDisplay display = (IPlatformDisplay)sender;
   int newWidth = display.Width;
   int newHeight = display.Height;
}
   
display.Resized += OnResized;

PlatformSystem.Instance.RunEventLoop();

PlatformService.Instance.Idle += new IdleEventHandler(OnIdle);

void OnIdle() 
{
   // do update work...
}

Scene Management

This is area is a big question mark for me. I've tried implementing it in several different ways and none have felt entirely "right".

The scene manager is the component that collects all of the "stuff" that exists in the world. I like to think of the concept of a "world" which contains "actors". Each actor has "behaviors" associated with it that allow it to appear in the world, move around, and interact with other actors.

Ideally the scene system would be just another loosely coupled component, wired to the other subsystems via data. In practice, the subsystems always seem to end up needing to know about the scene system. While it might be a lack of discipline on my part, I find the scene management, serialization, and object model all tend to bleed together.

In the past I've used a composition system for actors, where each behavior is represented as a separate class. A "visual" behavior adds a visual representation (a 3D mesh) for the actor to the scene. A "shape" behavior adds a collision shell, allowing the actor to detect interactions with other actors. A "physics" behavior allows the actor to fall under gravity and bounce around in a realistic way.

In this system you don't know what behaviors an actor contains so you can't make direct method calls against it. Instead, you send a "message" which gets routed to one or more behaviors. Behaviors send messages whenever they detect an event, such as contact with another actor, or a health gauge ticking down.

Here are some design challenges for a good scene system. I realize that my terminology reflects a certain type of implementation; I do try to look past that and think out of the box.

• How is an actor assembled? Can it be built by a designer using a visual tool, or is coding necessary?

• How do the parts communicate with each other? Consider an actor with a visual, a shape, and associated physics. How is the physics notified of a collision? How does the visual know where to draw?

• If a message-like system is used, how are message sinks detected and messages dispatched?

• Can a behavior be "extended" by another behavior (see the WeaponCoolDown example below)?

• How would behavior state by propagated to a UI? Consider a player health gauge.

• How are actors queried? Such as "give me all actors within 10m of me" for a radar display.

• How does a behavior add or remove actors from the scene?

• How do behaviors find and monitor other actors? Consider an AI behavior that needs to follow another actor. How does it hold the reference? What if the other actor dies or leaves the scene?

• How are multibody systems represented? Consider a car, with wheels and suspension parts, connected but otherwise independent. How does the logic find and manipulate (move, spawn, etc.) such an actor?

• How are actors updated? Is update ordering important (and how is it maintained if it is)? Is it possible to extend the updating process to a multicore approach?

• How do you add a new subsystem? Is it necessary to add code to the scene system, or can it be adapted by data?

• How are scenes saved and reloaded? Can scene loading by streamed?

• How would a save game feature work?

• Does the behavior system enable (or at least not prevent) networking?

Some more thoughts on the subject.

Would a dynamic language, like Ruby or Python (or Scala), make things easier or more effective?

What about taking a more functional approach (Matt Hopkins), where an actor stores "properties" that are operated on by "actions" or "events"? The properties use well-known names to allowed them to be shared across code components.

The subsystems should all be maintaining their own internal state. The graphics components manages the collection of visuals, the physics components manages the collection of rigid bodies. If you want to know if something is visible, you query the graphics component, not the scene. This enables optimized data structures for each system and reduces the coupling with the scene system.

WeaponCoolDown

Scala mixins present an almost perfect model for a composition system. Unfortunately they are a compile-time feature, preventing (as far as I can tell) data-driven actors. The following is a bit of Scala code that demonstrates. Weapon is a mixin trait that contains a fire() action. WeaponCoolDown is another trait that modifies the behavior of this action. This simple example could be done in other ways, so try to think bigger. The basic idea here is: multiple inheritance done right.

trait Weapon {
   def fire = {  ... }
}

trait WeaponCoolDown with Weapon {
   var timeToFire = 0.0f;
   def update(dt: float) = {
      timeToFire -= dt;
      super.update(dt);
   }
}