Moteur de jeu: une manière décente, au niveau de l'architecture, d'implémenter le support des scripts?

Je développe un moteur de jeu simple (en C #, si cela importe), et je ne peux pas penser à un moyen assez décent pour implémenter les scripts en termes d'architecture.

C'est une stratégie simple au tour par tour avec des animations personnalisées indépendantes de la logique pour les batailles. Il a une couche d'architecture globale pour les trucs système / bas niveau et, surtout, deux modules principaux - la logique et la vue de jeu - qui communiquent à l'aide d'un gestionnaire d'événements.

Et le fait est que j'aimerais vraiment que les scripts influencent à la fois les choses liées à la logique du jeu (modification des paramètres d'unité, etc.) et les choses liées à la vue du jeu, telles que les animations / dialogues spéciaux pour les batailles qui pourraient dépendre d'un certains déclencheurs scriptés.

(Pour être honnête, idéalement, je veux que le script contrôle le déroulement du jeu, ne laissant que les mécanismes / graphiques de base à la logique / vue, mais je suis nouveau dans ce domaine, donc je ne suis pas sûr de pouvoir le faire maintenant)

J'ai pensé à trois options:

• Laissez simplement les scripts vivre dans la logique, mais faites-le savoir sur le côté graphique du jeu. Mais cela rendrait la division logique / vue très vague, n'est-ce pas ...

• Faites du script un module distinct qui échangera les événements avec les autres en utilisant le même gestionnaire d'événements. Mais cela nécessiterait d'être très prudent sur la synchronisation des événements, je suppose ... et également d'ajouter un grand nombre de types d'événements au gestionnaire. (Toujours, favori personnel)

• Faites du script un module avant tout, afin qu'il puisse directement influencer / appeler les fonctions de la logique / vue. Cela permet une fonctionnalité intrinsèquement plus large au prix d'une sorte de vissage de l'ensemble du système d'échange d'événements et de la peur que le script puisse casser des choses même quand il ne devrait vraiment pas.

Donc, je ne peux pas décider de l'un d'eux ni penser à une meilleure façon d'insérer le module de script ... Des suggestions ou des liens utiles?

Je vous remercie!

Ps merci d'avoir migré la question, je ne savais pas qu'il y avait une section spécialisée pour gamedev

Je crois que vous voulez la troisième option, mais vous constaterez que vous avez raison de penser que des événements logiques se produisant à deux endroits potentiels sont une mauvaise chose. Vous constaterez que vous voulez que le module logique du moteur finisse par être une coche de mise à jour qui pose deux questions «Que dois-je faire maintenant? et "Comment faire?" auquel vous pouvez ensuite lier des scripts pour gérer la réponse à ces questions.

Ajoutez à cela exposer les objets qui contiennent les données et une API pour accéder aux composants logiques requis (je veux dire que vous pouvez créer un script pour trouver le chemin AI, mais comme il s'agit d'un morceau de code générique qui sera probablement utilisé et réutilisé, pourquoi pas l'intégrer dans le module, puis l'ajouter à l'API exposée au langage de script?). Cela devrait vous donner l'accessibilité ainsi que les endroits clairement définis où les choses se passent.

Encore une fois, je mets cela en garde avec la même déclaration que je fais toujours. Un produit fini de travail est toujours plus précieux qu'une bonne théorie en programmation :)

J'espère que cela t'aides!

Beaucoup ont tendance à sous-estimer la puissance des langages dynamiques en pensant qu'une telle flexibilité se fait au détriment de la vitesse; C'est vrai mais souvent le coût est tout simplement négligeable.

Personnellement, j'ai tendance à développer autant que possible en utilisant des langages dynamiques exploitant l'expressivité et ensuite je profile le prototype pour comprendre où et si l' optimisation est nécessaire.

Dans votre cas, cela signifie que vous devez essayer de passer à la troisième option, en développant la partie "supérieure" en utilisant un langage dynamique approprié que vous pouvez également utiliser comme langage de script.

De nombreux motifs peuvent être utilisés après avoir placé le dynamisme à la bonne profondeur. Vos scripts personnalisés peuvent être intégrés dans un système basé sur des événements en tant que système de rappel, lorsque le noyau le rappelle, il peut fournir un environnement approprié afin que le script puisse modifier l'état global ou simplement l'état d'un sous-ensemble de l'ensemble du système.

Vous pouvez encapsuler l'interface que votre script peut interagir en utilisant le modèle de façade. Dans les méthodes de façade, vous pouvez mettre la logique qui définit comment , quand , si le script peut utiliser une fonctionnalité et l'abstraction de l'interaction du script de l'implémentation principale.

Votre interface de script doit fournir les méthodes de fabrique pertinentes afin que le script puisse générer des éléments sans les instancier directement; ces instances peuvent être des wrappers sur les objets réels afin de pouvoir implémenter une logique d'accès de contrôle supplémentaire.

L'objet de script doit avoir accès aux autres objets pour lesquels il fournira des données. Veillez à ne pas passer ces autres objets directement dans l'objet de script. Cela crée une interface fragile. Vous souhaiterez peut-être avoir quelque chose comme une classe de médiateur qui gère ces références d'objet et fournit un accès aux données à l'objet de script.

Lua est un choix populaire pour un langage de script à usage général. Vous pouvez créer votre propre langage de script en utilisant Lex et Yacc (consultez l'article dans Game Programming Gems 3), mais je dirais que la plupart de vos besoins pourraient être pris en charge avec Lua, peu importe leur taille.