Gestione dei componenti con script e "nativi" in un sistema di entità basato su componenti

Attualmente sto cercando di implementare un sistema di entità basato su componenti, in cui un'entità è fondamentalmente solo un ID e alcuni metodi di supporto che uniscono un gruppo di componenti per formare un oggetto di gioco. Alcuni obiettivi includono:

1. I componenti contengono solo stato (ad es. Posizione, salute, numero di munizioni) => la logica va in "sistemi", che elaborano questi componenti e il loro stato (ad es. PhysicsSystem, RenderSystem, ecc.)
2. Voglio implementare componenti e sistemi sia in puro C # che tramite scripting (Lua). Fondamentalmente voglio essere in grado di definire componenti e sistemi completamente nuovi direttamente in Lua senza dover ricompilare il mio sorgente C #.

Ora sto cercando idee su come gestirlo in modo efficiente e coerente, quindi non ho bisogno di usare una sintassi diversa per accedere ai componenti C # o ai componenti Lua, ad esempio.

Il mio approccio attuale sarebbe quello di implementare componenti C # usando proprietà pubbliche regolari, probabilmente decorate con alcuni attributi che dicevano all'editore di valori e cose predefiniti. Quindi avrei una classe C # "ScriptComponent", che avvolge semplicemente una tabella Lua internamente con questa tabella creata da uno script e contenente tutto lo stato di quel particolare tipo di componente. Non voglio davvero accedere a quello stato dal lato C #, come non saprei al momento della compilazione, quali ScriptComponents con quali proprietà sarebbero disponibili per me. Tuttavia, l'editor dovrà accedervi, ma una semplice interfaccia come la seguente dovrebbe essere sufficiente:

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

Questo semplicemente accede alla tabella Lua e imposta e recupera quelle proprietà da Lua e potrebbe essere facilmente incluso anche nei componenti C # puri (ma usa le normali proprietà C #, attraverso la riflessione o qualcosa del genere). Questo sarebbe usato solo nell'editor, non dal normale codice di gioco, quindi le prestazioni non sono così importanti qui. Sarebbe necessario generare o scrivere a mano alcune descrizioni dei componenti documentando quali proprietà offre effettivamente un determinato tipo di componente, ma questo non sarebbe un grosso problema e potrebbe essere sufficientemente automatizzato.

Tuttavia, come accedere ai componenti dal lato Lua? Se faccio una chiamata a qualcosa del genere getComponentsFromEntity(ENTITY_ID)probabilmente riceverò solo un mucchio di componenti C # nativi, incluso "ScriptComponent", come userdata. L'accesso ai valori dalla tabella Lua racchiusa mi farebbe chiamare il GetProperty<T>(..)metodo invece di accedere direttamente alle proprietà, come con gli altri componenti C #.

Forse scrivere un getComponentsFromEntity()metodo speciale solo per essere chiamato da Lua, che restituisce tutti i componenti nativi di C # come userdata, ad eccezione di "ScriptComponent", dove restituirà invece la tabella spostata. Ma ci saranno altri metodi relativi ai componenti e non voglio davvero duplicare tutti questi metodi sia per essere chiamati dal codice C # sia dallo script Lua.

L'obiettivo finale sarebbe quello di gestire tutti i tipi di componenti allo stesso modo, senza che la sintassi del caso speciale distingua tra componenti nativi e componenti Lua, specialmente dal lato Lua. Ad esempio, vorrei poter scrivere una sceneggiatura di Lua in questo modo:

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

nativeComponent.NativeProperty = 5
scriptComponent.ScriptedProperty = 3

Lo script non dovrebbe interessarsi del tipo di componente effettivamente ottenuto e mi piacerebbe usare gli stessi metodi che userei dal lato C # per recuperare, aggiungere o rimuovere componenti.

Forse ci sono alcune implementazioni di esempio di integrazione di script con sistemi di entità del genere?

Un corollario di risposta di FXIII è che si dovrebbe progettare tutto ciò (che sarebbe moddable) nel linguaggio di scripting prima (o almeno una parte molto dignitoso di esso) per garantire che la logica di integrazione effettivamente fondi per modding. Quando si è certi che l'integrazione degli script sia abbastanza versatile, riscrivere i bit richiesti in C #.

Personalmente odio la dynamicfunzionalità in C # 4.0 (Sono un drogato di linguaggio statico) - ma questo è senza dubbio uno scenario in cui dovrebbe essere usato ed è dove brilla davvero. I componenti di C # sarebbero semplicemente oggetti di comportamento forti / esplicativi .

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.

I tuoi componenti Lua sarebbero completamente dinamici (lo stesso articolo sopra dovrebbe darti un'idea di come implementarlo). Per esempio:

// 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.
}

Ora, poiché stai usando dynamic, puoi usare gli oggetti Lua come se fossero vere classi in C #.

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

Preferirei fare il contrario: scrivere tutto usando un linguaggio dinamico e quindi rintracciare i bottleneks (se presenti). Una volta trovato, è possibile reimpostare selettivamente le funzionalità coinvolte utilizzando un C # o (piuttosto) C / C ++.

Te lo dico principalmente perché ciò che stanno cercando di fare è confinare la flessibilità del tuo sistema nella parte C #; man mano che il sistema diventa complesso, il tuo "motore" C # inizierà a sembrare un interprete dinamico, probabilmente non il migliore. La domanda è: sei disposto a investire la maggior parte del tuo tempo a scrivere un motore C # generico o ad estendere il tuo gioco?

Se il tuo obiettivo è il secondo, come credo, probabilmente utilizzerai meglio il tuo tempo concentrandoti sulle tue meccaniche di gioco, lasciando che un interprete esperto esegua il codice dinamico.