Dipende da come vuoi progettare il tuo sistema mod. Ne esplorerò due.
SDK
Molto probabilmente dovrai richiedere che i tuoi modder utilizzino la stessa lingua che usi tu e caricare le mod tramite la riflessione (o simili, a seconda della lingua che preferisci). Questo ovviamente ti limiterà alle lingue che possono eseguire il binding tardivo - e ce ne sono molte che possono farlo (anche il C può eseguire il binding tardivo con qualche LoadLibrary
inganno intelligente ). Potresti anche fare qualche meta-modding, in cui una mod potrebbe ospitare altre mod (ad esempio mod con script).
Il primo problema con questo approccio è nascondere lo stato interno. Prendendo ad esempio C # un modder potrebbe semplicemente usare la riflessione per accedere ai membri privati, C può anche farlo (anche se è necessario uno sforzo maggiore).
Il secondo problema è l'hosting. Alla gente non piace molto il codice straniero in esecuzione sul proprio sistema senza sandbox in atto. Come scenario peggiore potresti scrivere una mod che imposta un seedbox; se questo fosse installato su un ISP, potrebbe danneggiare seriamente la loro reputazione.
Scripting
I modder userebbero un linguaggio come Lua per creare mod. Avresti bisogno di una lingua che potrebbe invocare il codice nativo (per interfacciarsi con Lua); o dovresti scrivere il tuo linguaggio di scripting nella tua lingua preferita.
Il primo problema qui è che la maggior parte dei linguaggi di scripting viene interpretata, il che potrebbe non essere accettabile per i sistemi in tempo reale (anche se, vedi LuaJIT); come i giochi.
Ironia della sorte, il secondo problema esiste ancora qui; prendendo come esempio Lua, sono rimasto estremamente deluso dal fatto che abbia funzioni di "bombardamento" incluse nella libreria core / default - rendendolo completamente inutile come ambiente sandbox (senza un grande sforzo, fortuna e manutenzione), è difficile Descrivo quanto sono arrabbiato per questo, ma spero davvero che stessero bevendo dei cocktail forti quando includevano questi anti-funzionalità . Ovviamente potresti facilmente evitarlo se avessi implementato la tua lingua (vedi: UnrealScript).
Infine, il costo dell'interazione con un motore di scripting può essere proibitivo - prendendo di nuovo Lua come esempio, combinato con C #: C # ha un notevole sovraccarico quando si invocano funzioni native (tramite P / Invoke) e Lua è un'API piuttosto "chiacchierona". Ciò potrebbe causare problemi se il modo in cui si progetta lo "script SDK" richiede molte chat tra la lingua principale e il linguaggio di scripting (si noti che C non ha realmente questo problema). Ancora una volta potresti evitarlo scrivendo il tuo linguaggio di scripting (e nel caso in cui C # lo compili in MSIL) ed eseguendolo nel modo più rapido nel tuo ambiente [virtuale].
Poiché lo script è essenzialmente in esecuzione su un sistema completamente diverso dal codice primario, è possibile controllare completamente l'accesso allo stato interno (a meno che non facciano cose fantasiose con le funzioni di shell precedentemente menzionate).
Conclusione
Ho fatto un po 'fuori tema, tuttavia, quello che puoi sostanzialmente ottenere da quel muro di testo è che dovresti essere in grado di creare un gioco modificabile in qualsiasi lingua (mi permetto di dire che puoi ) - ma in alcune lingue può portare a più lavoro. Sono un po 'ansioso della sicurezza? Sì, dovresti esserlo anche quando si tratta di codice utente.