TorchED's C# Interface and Implementation

[JaipurVeggies]

Dear devs,

First off, thank you so much for making this game. It totally sated my craving for a polished, dun dungeon crawler in ways that I wasn't expecting. I liked the length, because that means it didn't totally consume me

As a fellow game (and tools!) developer, I was intrigued by the way you constructed your interface for TorchED. Specifically, the way you embedded the Torchlight engine into the GUI. It looks like the interface was constructed in C#, but obviously the editor itself utilizes all of the components present in the main game engine, as you can jump in and out of a level while you're editing it. I've had a few thoughts about how to accomplish this, and I was wondering if you'd be willing to share a high-level overview of the technologies you used?

Did you just (I say 'just' like it's a trivial task ) write a managed wrapper around the core Torchlight engine and expose the necessary functions to the C# app? Do you have any tips for someone considering a similar approach? The toolset I'm currently working on has a custom GUI that's built in Lua, which is handy for implementing complex functionality under the hood, but a right pain in the arse when it comes to designing the GUI.

[Marsh]

That sure is the way we did it. We ended up with very few exposed functions for the object creation, deletion and manipulation. Basically every object has an Object ID and every property has an ID and Type. We then use C#'s CodeDom to construct the classes on the fly so we can use them with the property grid. Check out the file under %appdata%torched/objects.dat.

When we create say a roompiece in c# via the codeDom it actually calls into the dll( createObject( ObjectID ) ) which returns that objects uniqueID; and at this point we have a room piece in the level. From there we can set properties on the roompiece object created in C#( via the property grid). Each property is just a function wrapper that calls into the dll( setProperty( ObjectUniqueID, PropertyUniqueID, void*, size )); allowing us to manipulate the objects in real time. The hardest part is probably the CodeDom as well as the Macro's you have to create in C++ to define the properties of each class. On the c++ side of things we created a definition class per object exposed in the editor( which honestly kind of blows ). The definition has a list of all the properties that are exposed per object( static get and set functions ), a virtual function for creating the object and a list of all the objects it has created.

Hope that kind of answers a few questions.

[JaipurVeggies]

That was indeed very helpful! I've heard about CodeDom before, but I really haven't spent much time looking into it. That alone gives me a lot to go off of, so thank you!

We're fortunate in the sense that most of our engine is built in Lua. Object creation, loading, saving, property modifying, etc. is all handled through a series of Lua methods, so we already have all of our properties mapped to strings. I think we could get away with exposing relatively few 'glue' functions to handle the object creation/management side of things.

For the actual act of rendering your engine in the GUI, did you just write a similar binding function that returns the D3D surface that the engine renders to? It seems like it you just rerouted that surface to an image in C# and forwarded all mouse/keyboard events to the engine through a few more exposed methods, that would take care of most of it. Can you think of any other major stumbling blocks related to interfacing the two? Any tricks to passing volatile pointers between processes?

This has been really insightful - it's encouraging to hear that the approach I was planning on taking wasn't completely off!