Game Editor plugin architecture

Question

I'm creating 3D Game Editor for my own use. As rendering i took Ogre3D and MFC as UI.

I faced with architecture problem.

I am using Document/View architecture and for each Doc. i create new SceneManager and for each View i create own viewport, camera, my own local Input manager which send input data to local camera. Also it's sending input data and pointer to SceneManager to global ToolManager which contains some base tools like Move, Select etc. and the pointer to active tool, if it's NULL he is sending input to SelectTool by default.

I'm only at start but i'm thinking of the future. I think that this strategy of passing some data to the global manager is not so good how it looks now. Can you give me some design advices or articles and share with me your experience.

Thank you for your time.

Edit:

I think that plugin architecture would give a lot flexibility and it`s like all editors do. But i never before faced with that. So i will try to tell u what i think about it. Host App contain

1. PLuginManager:
   • load/unload plugins
   • base interface to add frame/window and other UI
   • base interface to communicate with other plugins
2. EventListener
   • collect all events and EventListeners
   • send specific events to it listener

It's all what host app contains. But, how to implement it? I mean all communication. How to load and save files. Edit object with different plugins. I'm thinking to use QT, is it better than MFC or wxWigets.

Can you give me some advices please.

Answer 1

At the very basic level, you probably want your plugins to be able to provide new tools and new commands (alternative save methods, for example). You can implement this kind of extensibility, along with any other similar extensibility, in the same fashion.

You define for your system an interface that a plugin must conform to. This should at a minimum include hooks that the editor will call to load and unload the plugin. Pass, to the load function, references to all the extensibility interfaces you have supplied (or an interface that allows you to locate those interfaces).

For each extensibility interface, you want to have a related interface that corresponds to the new thing your plugin may be adding. For example, you might have an ITool interface that defines the properties of a tool the user can select from a palette and use to manipulate the scene. Or, you might have an ICommand interface that's used to populate your menu bar with options. The details of those interfaces are up to your particular needs and implementation.

The extensibility interface provides methods that allow the plugin to install new instances of ITool, ICommand or what have you. For example, you might pass your plugins an instance of the Toolbox class:

struct Toolbox {
    void AddTool (ITool * tool);
    void RemoveTool (ITool * tool);
    // ...
}

Because this type allows for tools to be added and removed from the available set, a plugin can define an entirely new tool that conforms to the ITool interfaces, such as a MeshSplitTool for example, and install that tool in the toolbox during the plugin's loading callback.

Similarly, you will want to remove the tool (and probably release its memory) in the plugin's unload callback.

This approach can be applied to any number of different things you'd want to extend. At the heart of it you:

• Define in the main editor the interface that new things must conform to.
• Allow plugins to install and remove instances of those new things so long as they fit the defined interface.
• Have the rest of the editor work in terms of that defined interface, so it doesn't care whether or not the particular objects it is working with came internally or from a plugin in some DLL.

Answer 2

My first question would be why have a ToolManager with methods like Move and Select. Different tools are going to provide different mechanics depending on the choice you've picked and trying to put all this logic into some manager class seems wrong and the typical approach to code bloat or god-like object class.

Instead, consider having your SelectTool register itself for input commands when the user selects it. Then as input occurs, this object determines what it does. When you select a different tool, perhaps the terrain splat tool, the SelectTool unregisters itself for input and the SplatTool registers itself instead.

Of course, there may be overlap between these two tools, which makes sense to be factored into a base class, perhaps called Tool for simplicity that all your specialized tools subclass from. In this case, perhaps the point of a ToolManager class could then be useful for registering different tools as plugins?

I think this fits with some of your edit comments.

As for which UI platform to consider, it really should boil down to what you're most comfortable using. All proposed UI solutions simply abstract the Win32 API from you and provide some feature rich classes that make UI programming easier and faster. In the end, they accomplish the same. The biggest difference here is that MFC is pure Microsoft. You can use MFC on *nix systems but of course the use of emulators such as Wine/CrossOver is necessary. Otherwise, using UI toolkits such as wxWidgets/QT offer more cross platform options.