Motore di gioco: un modo decente, dal punto di vista dell'architettura, di implementare il supporto per gli script?

Sto sviluppando un semplice motore di gioco (in C #, se è importante), e non riesco a pensare a un modo abbastanza decente per implementare gli script in termini di architettura.

È una semplice strategia a turni con animazioni personalizzate e indipendenti dalla logica per le battaglie. Ha un livello di architettura globale per roba di sistema / basso livello e, soprattutto, due moduli principali - cose logiche e di visione di gioco - che comunicano usando un gestore di eventi.

E il fatto è che mi piacerebbe davvero che gli script influenzassero sia le cose relative alla logica del gioco (cambiando i parametri dell'unità, ecc.) Sia quelle relative alla vista del gioco, come animazioni / dialoghi speciali per battaglie che potrebbero dipendere da un certo trigger con script.

(Ad essere sincero, idealmente voglio che lo script controlli il flusso del gioco, lasciando solo la meccanica / la grafica di base alla logica / vista, ma sono nuovo in questo, quindi non sono sicuro di poterlo fare adesso)

Ho pensato a tre opzioni:

• Lascia che lo scripting viva nella logica, ma informalo sul lato grafico del gioco. Ma questo renderebbe la divisione logica / vista molto vaga, no ...

• Rendi lo scripting un modulo separato che scambierà gli eventi con gli altri usando lo stesso gestore eventi. Ma questo dovrebbe essere molto attento alla sincronizzazione degli eventi, immagino ... e aggiungere anche molti tipi di eventi al gestore. (Ancora, preferito personale)

• Trasforma gli script in un modulo soprattutto, in modo che possa influenzare / chiamare direttamente le funzioni della logica / vista. Ciò consente una funzionalità intrinsecamente più ampia al costo di una sorta di avvitamento dell'intero schema di scambio di eventi e la paura che lo script possa rompere le cose anche quando in realtà non dovrebbe.

Quindi, non posso né decidere uno di questi né pensare a un modo migliore per inserire il modulo di scripting ... Qualche suggerimento o link utile?

Grazie!

Ps grazie per aver migrato la domanda, non sapevo che ci fosse una sezione specializzata per gamedev

Credo che tu voglia la terza opzione, ma scoprirai che hai ragione nel pensare che avere eventi logici che si verificano in potenzialmente due posizioni sia una cosa negativa. Scoprirai che vuoi che il modulo logico del motore finisca per essere un segno di spunta di aggiornamento che pone due domande "Cosa devo fare ora?" e "Come posso farlo?" a cui è quindi possibile associare gli script per gestire la risposta a tali domande.

Abbinalo all'esposizione degli oggetti che contengono i dati e un'API per accedere ai componenti logici richiesti (intendo che potresti scriptare un rilevamento del percorso AI, ma poiché si tratta di un pezzo di codice generico che probabilmente verrà utilizzato e riutilizzato, perché no incorporarlo nel modulo e quindi aggiungerlo all'API esposta al linguaggio di scripting?). Questo dovrebbe darti l'accessibilità così come i luoghi chiaramente definiti in cui le cose stanno accadendo.

Ancora una volta, lo avverto con la stessa affermazione che faccio sempre. Un prodotto finito è sempre più prezioso di una buona teoria in programmazione :)

Spero che sia di aiuto!

Molti tendono a sottovalutare il potente dei linguaggi dinamici pensando che tale flessibilità abbia un costo per la velocità; Questo è vero ma spesso il costo è semplicemente trascurabile.

Personalmente tendo a sviluppare il più possibile usando linguaggi dinamici sfruttando l'espressività e quindi profilo il prototipo per capire dove e se è necessaria l'ottimizzazione.

Nel tuo caso ciò significa che dovresti provare a spostarti verso la terza opzione, sviluppando la parte "superiore" usando un linguaggio dinamico adatto che puoi usare anche come linguaggio di scripting.

Molti modelli possono essere utilizzati dopo aver posizionato il dinamismo alla giusta profondità. Gli script personalizzati possono essere integrati in un sistema basato su eventi come sistema di callback, quando il core richiama può fornire un ambiente adatto in modo che lo script possa modificare lo stato globale o solo lo stato di un sottoinsieme dell'intero sistema.

È possibile incapsulare l'interfaccia con cui lo script può interagire utilizzando il modello Façade. Nei metodi di facciata è possibile inserire la logica che definisce come , quando , se lo script può utilizzare una funzionalità e astrarre l'interazione dello script dall'implementazione principale.

L'interfaccia dello script dovrebbe fornire i metodi factory pertinenti in modo che lo script possa generare elementi senza istanziarli direttamente; queste istanze possono essere wrapper sugli oggetti reali, quindi è possibile implementare un ulteriore controllo della logica di accesso.

L'oggetto script deve avere accesso agli altri oggetti per i quali fornirà i dati. Fare attenzione a non passare quegli altri oggetti direttamente nell'oggetto script. In questo modo crea un'interfaccia fragile. Potresti voler avere qualcosa come una classe mediatore che gestisce quei riferimenti a oggetti e fornisce l'accesso ai dati all'oggetto di scripting.

Lua è una scelta popolare per un linguaggio di scripting generico. Puoi creare il tuo linguaggio di scripting usando Lex e Yacc (leggi l'articolo in Game Programming Gems 3) ma direi che la maggior parte delle tue esigenze potrebbero essere soddisfatte con Lua, non importa quanto grande o piccola.