Cela dépend de la façon dont vous souhaitez concevoir votre système de mod. J'en explorerai deux.
SDK
Très probablement, vous aurez besoin que vos moddeurs utilisent le même langage que vous, et chargent les mods via la réflexion (ou similaire, selon la langue de votre choix). Cela vous limitera évidemment aux langages qui peuvent faire une liaison tardive - et il y en a beaucoup qui peuvent le faire (même C peut faire une liaison tardive avec une astuce intelligente LoadLibrary
). Vous pourriez même faire du méta-modding, où un mod pourrait héberger d'autres mods (par exemple des mods scriptés).
Le premier problème avec cette approche est de cacher l'état interne. En prenant C # par exemple, un modder pourrait simplement utiliser la réflexion pour accéder aux membres privés, C peut également le faire (bien que plus d'efforts soient nécessaires).
Le deuxième problème est l'hébergement. Les gens n'aiment pas vraiment le code étranger exécuté sur leur système sans bac à sable en place. Dans le pire des cas, vous pourriez écrire un mod qui configure une boîte de départ; s'il était installé chez un FAI, cela pourrait nuire gravement à sa réputation.
Scripting
Les moddeurs utiliseraient un langage tel que Lua pour créer des mods. Vous auriez soit besoin d'un langage qui pourrait invoquer du code natif (pour interfacer avec Lua); ou vous devrez écrire votre propre langage de script dans la langue de votre choix.
Le premier problème ici est que la plupart des langages de script sont interprétés, ce qui peut ne pas être acceptable pour les systèmes en temps réel (bien que, voir LuaJIT); comme les jeux.
Ironiquement, le deuxième problème existe toujours ici; en prenant Lua comme exemple, j'ai été extrêmement déçu de voir que les fonctions de `` décorticage '' sont incluses dans la bibliothèque principale / par défaut - ce qui le rend entièrement inutile en tant qu'environnement bac à sable (sans beaucoup d'efforts, de chance et de maintenance), il est difficile de dépeindre à quel point je suis en colère à ce sujet, mais j'espère vraiment qu'ils buvaient des cocktails forts lorsqu'ils ont inclus ces anti-fonctionnalités . Vous pouvez évidemment facilement éviter cela si vous utilisez votre propre langage (voir: UnrealScript).
Enfin, le coût de l'interaction avec un moteur de script peut être prohibitif - en prenant à nouveau l'exemple de Lua, combiné avec C #: C # a un surdébit substantiel lors de l'appel de fonctions natives (via P / Invoke) et Lua est une API assez `` bavarde ''. Cela pourrait entraîner des problèmes si la façon dont vous concevez le `` SDK de script '' nécessite beaucoup de discussions entre votre langage principal et votre langage de script (notez que C n'a pas vraiment ce problème). Encore une fois, vous pouvez éviter cela en écrivant votre propre langage de script (et dans le cas de C # le compilant en MSIL) et en l'exécutant de la manière la plus rapide sous votre environnement [virtuel].
Étant donné que le script s'exécute essentiellement sur un système complètement différent de votre code principal, vous pouvez contrôler entièrement l'accès à l'état interne (à moins qu'ils ne fassent des choses fantaisistes avec les fonctions shell mentionnées précédemment).
Conclusion
J'ai un peu dépassé le sujet, cependant, ce que vous pouvez essentiellement tirer de ce mur de texte, c'est que vous devriez pouvoir faire un jeu moddable dans n'importe quelle langue (j'oserais dire que vous le pouvez ) - mais dans certaines langues peut conduire à plus de travail. Suis-je un peu anal à propos de la sécurité? Oui, vous devriez l'être aussi en ce qui concerne le code utilisateur.