Implémentation d'un langage de script XML simple pour un jeu XNA

Question

Je travaille avec une équipe sur un moteur RPG en C# et XNA. Nous prévoyons de cibler Windows et Windows Phone 7, mais nous sommes confrontés à des problèmes liés aux interactions AI et au contrôle des actions des joueurs pendant les cinématiques. La plupart du temps, tout est extrait à l'aide du modèle de conception MVC, mais l'abstraction de toute la logique et du mouvement dans un contrôleur peut entraîner des problèmes sur toute la ligne. L'idée est donc d'avoir une interface (IScriptEngine) qui prend un IScriptObject et met à jour les données dans le modèle de carte en conséquence. Je pensais à mettre les scripts dans une sorte XML de la syntaxe:

<Script Name="MoveNPC_1"> 
    <Action Command="MoveToTile" Target="NPC_1" Value="10,2"/> 
</Script> 

et ont un IScriptEngine parser en conséquence. Je doute fortement que l'analyse d'une déclaration de switch géante soit une bonne idée, mais c'est ce sur quoi j'ai travaillé. Même mon expérience de programmation au secondaire me dit que c'est une mauvaise idée, mais je ne vois pas d'autre moyen de contourner cela.

Editer: Je voudrais d'une manière ou d'une autre intégrer tout ceci dans le fichier de carte. Dans le fichier XML de carte, nous avons des zones désignées pour, qui contient plusieurs balises. Ensuite, il y aurait une section, désignant où le PNJ est sur la carte, et quelles ressources et scripts il utiliserait. Ensuite, il y aurait une section, où toutes les batailles seraient définies (encore une fois, en définissant les ressources et quoi d'autre), puis éventuellement une section, où ces scripts seraient définis. Je souhaite juste qu'il y avait un moyen de compiler C# à la volée en utilisant WP7. Si je pouvais obtenir du soutien des deux côtés, ce ne serait pas un problème. Je me demande s'il y aurait une bibliothèque Mono qui pourrait être portée sur WP7 et qui partagerait les fonctionnalités de CodeDom et de toutes les classes du compilateur?

Answer 1

Vous pouvez utiliser un analyseur XML existant, il existe de nombreuses façons de le faire (SAX, StAX) et des parseurs disponibles pour de nombreuses langues.

Ensuite, vous pouvez utiliser XPath pour référencer des nœuds dans votre document.

Answer 2

Vous pouvez envisager d'incorporer un langage réel tel que Lua au lieu d'utiliser une syntaxe XML. Il y a une raison pour laquelle vous ne voyez pas beaucoup de langages de programmation construits sur la syntaxe XML réelle! C'est vraiment gênant pour les tâches de programmation.

Answer 3

XML Scripting !? Gasp! Maintenant que est quelque chose qui "pourrait causer des problèmes sur toute la ligne"! Pourquoi ne pas simplement utiliser C#? J'entends dire que c'est plutôt génial. J'ai déjà donné mon opinion on this matter.

Vous devez vous demander: Vos scripts doivent-ils vraiment être pilotés par les données? Y a-t-il une raison pour laquelle les données ne peuvent pas être exprimées en C#?

Ont-ils vraiment besoin d'être interprétés lors de l'exécution? Parce que, s'ils le font vraiment, cela can be done with C#.

Et voici un autre answer of mine to an almost identical question, sur le gamedev.stackexchange.com. J'ai même mis un petit exemple d'implémentation possible là-dedans.

Si vous souhaitez exécuter des actions qui nécessitent plus qu'une trame (par exemple, des routines), par exemple: «Passez par ici, parlez, attendez, avancez là-bas», vous pouvez aussi raisonnablement bien.

---

Edit: Si vous voulez mélanger vos niveaux XML et scripts C#, voici un exemple de ce que je veux dire:

<Level> 
    <Door position="4,4" name="spookyDoor" /> 
    <Region position="4,2" name="spookyOpener" /> 
</Level> 

Et en C#:

public void LevelStart() 
{ 
    this.Regions["spookyOpener"].OnPlayerEnter +=() => 
    { 
     (this.Items["spookyDoor"] as Door).Open(); 
    }; 
} 

Answer 4

Avez-vous nécessairement besoin d'interpréter les scripts lors de l'exécution? Vous dites que votre développement est axé sur le contenu, ce qui est une bonne chose à faire. Mais vous n'avez pas forcément besoin d'interpréter vos scripts pour tirer parti de l'augmentation de la vitesse et de l'efficacité de l'utilisation de XML ou d'un langage de script. Je suis l'exemple de Shawn Hargreaves pour créer des données XML et permettre au Content Pipeline de le compiler en .XNB. Si vous implémentez un système de script ou intégrez un projet ContentPipeline existant, vous pouvez compiler uniquement les scripts qui ont été ajoutés ou modifiés, très peu d'interruptions entre les exécutions par rapport à la recompilation de l'intégralité du jeu.

Et je n'irais certainement pas pour du XML, XNA peut avoir automatiquement un importateur pour cela, mais il sera moche en essayant de l'utiliser. XNUA était censé être une bibliothèque lua pour XNA qui est censé fonctionner assez bien pour ce genre de chose. Rendre les concepteurs compiler à .XNB n'est pas si différent de la merde que vous avez à faire dans des moteurs comme la Source de toute façon.

Aussi, j'ai trouvé l'utile suivant pour penser à des événements scriptés:
Riverman Media - Object Oriented Programming, the Scripted Event System
Brandon Furtwangler - First Impressions Matter

Answer 5

Vous pouvez également envisager une bibliothèque appelée XNA terminal de débogage à http://www.protohacks.net/xna_debug_terminal. Cela vous permet d'exécuter des instructions C# arbitraires lors de l'exécution. Il fonctionne essentiellement comme une méthode Eval() pour les langages de script. Peut-être que, au lieu de créer des actions scriptées au format xml, vous pouvez autoriser les utilisateurs à programmer des actions à la volée pendant que le jeu s'exécute avec cette bibliothèque? Ou vous pouvez l'utiliser pour écrire vos propres actions afin de voir ce qui se passe dans chaque cas. L'une des commandes spéciales du terminal vous permet de prendre une chaîne contenant du code C# et d'évaluer le code. Vous pouvez donc définir des actions prédéfinies et en faire choisir l'utilisateur. Ces idées peuvent ne pas fonctionner pour votre cas particulier, mais juste pensé que je vous donnerais (et n'importe qui d'autre lisant ceci) quelques options plus à penser.