Handling scripted and "native" components in a component-based entity system

Question

I'm currently trying to implement a component-based entity system, where an entity is basically just an ID and some helper methods tying a bunch of components together to form a game object. Some goals of that include:

1. Components only contain state (e.g. position, health, ammo count) => logic goes into "systems", which process these components and their state (e.g. PhysicsSystem, RenderSystem, etc.)
2. I want to implement components and systems both in pure C# and through scripting (Lua). Basically I want to be able to define completely new components and systems directly in Lua without having to recompile my C# source.

Now I'm looking for ideas on how to handle this efficiently und consistently, so I don't need to use different syntax to access C# components or Lua components, for example.

My current approach would be to implement C# components using regular, public properties, probably decorated with some attributes telling the editor about default values and stuff. Then I'd have a C# class "ScriptComponent", which just wraps a Lua table internally with this table being created by a script and holding all the state of that particular component type. I don't really want to access that state much from the C# side, as I wouldn't know at compile time, what ScriptComponents with what properties would be available to me. Still, the editor will need to access that, but a simple interface like the following should suffice:

public ScriptComponent : IComponent
{
    public T GetProperty<T>(string propertyName) {..}
    public void SetProperty<T>(string propertyName, T value) {..}
}

This would simply access the Lua table and set and retrieve those properties from Lua and it could easily be included in the pure C# components as well (but use the regular C# properties then, through reflection or something). This would only be used in the editor, not by regular game code, so performance isn't as important here. It would make it necessary to generate or handwrite some component descriptions documenting what properties a certain component type actually offers, but that wouldn't be a huge issue and could be sufficiently automated.

However, how to access components from the Lua side? If I make a call to something like getComponentsFromEntity(ENTITY_ID) I'll probably just get a bunch of native C# components, including "ScriptComponent", as userdata. Accessing the values from the wrapped Lua table would result in me calling the GetProperty<T>(..) method instead of accessing the properties directly, like with the other C# components.

Maybe write a special getComponentsFromEntity() method only to be called from Lua, which returns all the native C# components as userdata, except for "ScriptComponent", where it'll return the wrapped table instead. But there'll be other component-related methods and I don't really want to duplicate all these methods both for being called from C# code or from Lua script.

The ultimate goal would be to handle all types of components the same, with no special case syntax differentiating between native components and Lua components - especially from the Lua side. E.g. I'd like to be able to write a Lua script like that:

entity = getEntity(1);
nativeComponent = getComponent(entity, "SomeNativeComponent")
scriptComponent = getComponent(entity, "SomeScriptComponent")

nativeComponent.NativeProperty = 5
scriptComponent.ScriptedProperty = 3

The script shouldn't care what kind of component it actually got and I'd like to use the same methods I'd use from the C# side to retrieve, add or remove components.

Maybe there are some sample implementations of integrating scripting with entity systems like that?

Answer 1

A corollary of FxIII's answer is that you should design everything (that would be moddable) in the scripting language first (or at least a very decent portion of it) to ensure that your integration logic actually provisions for modding. When you are certain that your scripting integration is versatile enough rewrite the required bits in C#.

I personally hate the dynamic feature in C# 4.0 (I am a static language junkie) - but this is without doubt a scenario where it should be used and is where it really shines. Your C# components would be simply be strong/expando behaviorial objects.

public class Villian : ExpandoComponent
{
    public void Sound() { Console.WriteLine("Cackle!"); }
}

//...

dynamic villian = new Villian();
villian.Position = new Vector2(10, 10); // Add a property.
villian.Sound(); // Use a method that was defined in a strong context.

Your Lua components would be completely dynamic (the very same article above should give you an idea of how to implement this). For example:

// LuaSharp is my weapon of choice.
public class LuaObject : DynamicObject
{
    private LuaTable _table;

    public LuaObject(LuaTable table)
    {
        _table = table;
    }

    public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
    {
        var methodName = binder.Name;
        var function = (LuaFunction)_table[methodName];
        if (function == null)
        {
            return base.TryInvokeMember(binder, args, out result);
        }
        else
        {
            var resultArray = function.Call(args);
            if (resultArray == null)
                result = null;
            else if (resultArray.Length == 1)
                result = resultArray[0];
            else
                result = resultArray;
            return true;
        }
    }

    // Other methods for properties etc.
}

Now because you are using dynamic you can use Lua objects as though they were real classes in C#.

dynamic cSharpVillian = new Villian();
dynamic luaVillian = new LuaObject(_script["teh", "villian"]);
cSharpVillian.Sound();
luaVillian.Sound(); // This will call into the Lua function.

Answer 2

I'd rather do the opposite: write all using a dynamic language and then track down the bottleneks (if any). Once you find one you may selectively reimplement the functionalities involved using a C# or (rather) C/C++.

I tell you this mainly because what are trying to do is to confinate the flexibilities of your system in the C# part; as the system becomes complex your C# "engine" will start to look like a dynamic interpreter, probably not the best one. The question is: are you willing to invest the most of your time into writing a generic C# engine or to extend your game?

If your target is the second one, as I belive, you will probably use your time best focusing on you game mechanics, letting a seasoned interpreter to run the dynamic code.