Request for advice: customised document types

[djewsbury]

Hi!,

I've been experimenting with integrating the LevelEditor code with an existing engine. So far it's gone very well! I'm hoping to fork the code and build some customised object and manipulator types to suit our needs.

In particular, I'd like to support more top-level "Document" types. It's convenient for us to have many specialised document types, wherein each document contains a separate dom node hierarchy. One document might contain static object placements. Another document might contain nodes with AI data. Another might contain FX data, etc.

So, rather than having a single giant dom hierarchy containing all object types, we would have many smaller dom hierarchies with specialised object types.

I've done some experiments, and the best solution I've found is to implement the IGameDocument interface for each document.

So, eg:

public class PlacementsDocument : DomDocument, IGamePlacement {}
public class AIMarkupDocument : DomDocument, IGamePlacement {}

This allows us to place all documents in the GameDocumentRegistry. And I've found that is necessary to get the history context working (and some other things, including bounding box rendering in NativeDesignControl)

But this requires that we also implement IGameObjectFolder for each document type. And it also means that every object type within must implement IGameObject (for clients of the GameObjects property in IGameObjectFolder -- where otherwise just IListable, IVisible & ILockable were enough).

There are some other problems as well:

• some places assume that objects that implement IGameDocument also implement IGame (eg, NativeDesignControl.TargetGame and RenderingInterop.m_gameDocumentRegistry_DocumentAdded).
• when creating a new object, sometimes the code must choose which document to add it to. For example, NativeDesignControl.OnDragEnter makes this decision. But it might be helpful to be able to customise how this decision is made -- so objects can be assigned to documents based on type or locality
• some UI controls might work better if they were bound to a specific document. For example, the layer window seems like it should be bound to a specific document. The history window could be bound either way -- either globally, or bound to a single document -- I'm not sure what is best in that case.

I was wondering what your thoughts on this were? Is there an easy path to go about supporting many smaller documents like this?

Is there a roadmap for future work on this LevelEditor? Or any intentions to work on document support for future versions?

Thanks so much

[abeckus]

Hi David,

Some part of LevelEditor meant to be heavy modified or replaced when integrating it with Game Engine. So you might need to make some local changes to the Core and also replace/modify some parts.

LevelEditor supports multiple documents where each document can contains all the game object types. This way a designers to divide game into multiple section or can designate certain document for a certain game object types.

Your approach for adding multiple documents types seems reasonable.

IGameObjectFolder (could be removed in future releases). For now each document must implement it. If you have a document type for holding non game objects then you can return null for RootGameObjectFolder.

IGameObject: Any object that can be placed in level must implement IGameObject. A game document can contain other object types as direct children (outside RootGameObjectFolder).

IGame: Ideally it should have been merged with IGameDocument. All game document must implement IGame

Drag/dropping object into design view: I suggest creating new MEF component to handle drag/drop operation. The new component can injected into NativeDesignControl may be from NativeDesignView Or you can directly import it using Globals.MEFContainer.GetExportedValue

You can create new UI that can bound to a specific document type or context. For example Layer is bound to a master document.

There are few other operation only make sense for master document. For example all document have grids but only Mater document’s grid is rendered.

LevelEditor’s Dom hierarchy needs extensive refactoring. But there is no immediate plan for such a work.

Alan

[djewsbury]

I see; thanks for the reply.

Actually, I've managed to quite far with only making changes to RenderInterop and the LevelEditor project.

My engine has some existing tools; and I've been using a C++/CLI layer between C++ and C#. So I rewrote all of RenderInterop::GameEngine to reuse that path. It worked out pretty well. There have been some difficulties. But I can usually find ways to make it work.

I've been avoiding making deeper code changes, but that was mostly because leave the door open to merge-in future changes from you or other clients of LevelEditor.

But I'm guessing from your message that it might be best just to go in an make the changes I need. Still, I'm finding that some of the changes I'm making are fairly general, and might be helpful to other clients. It just leaves me struggling with the decision of how deep I should go in refactoring. Light changes to retain some compatibility; or deep changes to create something much more targeted. I might have to consider creating a fork for more general changes, and keep engine specific changes separate?

Anyway, the LevelEditor code has been very useful for me. It's a fantastic starting place for creating a targeted editor.