Langages spécifiques au domaine pour l'écriture de scripts [fermé]

12

Comme la plupart d'entre vous le savent, les interprètes intégrés pour des langages comme Lua et Python sont largement utilisés pour l'écriture de scripts de logique de jeu, mais je n'ai pas vu beaucoup d'informations sur les personnes utilisant des langages spécifiques au domaine pour leurs scripts, par exemple la construction d'un petit dialecte de script logique 'en plus de la langue utilisée pour le reste du jeu, en utilisant des macros ou une programmation fluide ou autre.

Mes questions sont donc les suivantes:

  • Quels exemples de ces DSL avez-vous vus dans les jeux du monde réel?
  • Quels problèmes ont été rencontrés?
  • Recommanderiez-vous cette voie aux autres développeurs de jeux et dans quelles circonstances?
  • Pensez-vous que cela devient plus courant à mesure que le développement du jeu évolue vers des langages plus adaptés aux métaprogrammes, par exemple Boo?
Cody Brocious
la source
Pour répondre à la question d'utilisation réelle du DSL, Battlefield 1942 les a utilisés. Bien que beaucoup de mods soient apparus; du point de vue des programmeurs (mon) c'était horrible et j'ai perdu tout intérêt très rapidement.
Jonathan Dickinson

Réponses:

6

Mon conseil serait "non".

J'ai utilisé un langage de balisage spécifique au domaine pour les données de jeu. Ce fut une douleur. J'ai passé des jours à le concevoir, puis chaque semaine ou deux, je devais l'ajuster pour ajouter plus de fonctionnalités. À un moment donné, j'ai réalisé que je devais générer automatiquement certaines de mes données de jeu, et j'ai fini par écrire un petit programme pour analyser les fichiers d'entrée dans le langage de balisage, les masser et produire différents fichiers également dans le langage de balisage.

Honnêtement, je n'ai aucune idée de ce que je pensais. Le tout aurait été plus simple, plus efficace, moins sujet aux bogues et beaucoup moins long si j'avais utilisé Lua.

Si vous travaillez sur un système si restreint que vous ne pouvez pas démarrer un environnement Lua, alors vous devriez peut-être utiliser une DSL, mais soyez prêt à l'agonie. Sinon, je crois fermement que vous devez simplement utiliser Lua. Lua a été initialement conçu comme un simple langage de balisage de données et est toujours extrêmement propice à l'utilisation en tant que tel, et quand (pas si) vous réalisez que vous avez besoin de quelque chose de plus compliqué, vous l'avez déjà. Tout mon développement de jeu actuel se fait dans Lua et je n'ai jamais été aussi efficace ou moins sujet aux bogues.

Je ne peux pas recommander contre les DSL assez fortement.

ZorbaTHut
la source
Euh, pourquoi pas? Vous venez d'utiliser Lisp, cela aurait été une expérience beaucoup plus agréable je pense. :) Starcraft II a le langage de script Galaxy qui est en effet un langage spécifique au domaine destiné aux gars / filles non-tech.
jacmoe
3
Lisp ne serait pas plus une DSL que Lua ou Python. Ce serait une langue entièrement formée que quelqu'un d'autre a passé beaucoup de temps à concevoir, temps que vous pouvez éviter de dépenser vous-même.
coderanger
2

Je n'ai pas vu beaucoup d'informations sur les gens qui utilisent des langages spécifiques à un domaine pour leurs scripts, par exemple la construction d'un petit `` dialecte '' de script logique en plus du langage utilisé pour le reste du jeu, en utilisant des macros ou une programmation fluide ou autre.

Les langages de script ont tendance à être une proposition coûteuse dans les jeux. Même Lua, qui est assez rapide, est toujours beaucoup plus lent que le code natif. Les équipes de jeu ne sont généralement disposées à prendre ce coup que parce qu'elles leur procurent en retour deux avantages très importants:

  1. La possibilité de modifier les scripts sans avoir à recompiler et recharger le jeu.
  2. La possibilité pour les non-programmeurs d'écrire des scripts.

Les DSL ne vous donnent malheureusement pas cela.

munificent
la source
Je dirais que 2) est un hareng rouge. Pour tout script suffisamment intéressant, un non-progammeur aura besoin de plus d'aide à la main ou au débogage qu'il n'en vaut la peine. Il existe de bons programmeurs-concepteurs qui n'ont pas besoin d'aide, mais vous ne pouvez pas gifler Lua For Dummies sur le bureau d'un concepteur de niveau régulier et vous attendre à ce qu'ils s'amusent.
tenpn
Je suis d'accord. Je ne pense pas que # 2 fonctionne bien dans la pratique, mais j'ai vu cela comme une raison apparente pour intégrer un langage de script.
munificence
Il y a beaucoup de gens avec de bonnes idées de jeux qui peuvent écrire des scripts Lua mais je ne ferais jamais confiance près de malloc / sprintf / n'importe quel endroit où ils devaient choisir une structure de données / etc. C'est vraiment ce que signifie # 2 - "La capacité pour les mauvais programmeurs de causer un minimum de dégâts et de continuer à travailler."
Ils peuvent ne pas provoquer de fuites de mémoire avec un script, mais un mauvais programmeur peut toujours écrire du code bogué, incontrôlable et lent. Les mauvais programmeurs ne devraient pas être autorisés à proximité de votre jeu. Embauchez des designers avec une expérience de script éprouvée et tout ira bien.
tenpn
2

Je trouve curieux que votre question se limite aux DSL internes , car je préfère préconiser l'utilisation d'une DSL externe afin d'avoir la possibilité de charger des scripts à l'exécution et surtout de permettre aux non-développeurs d'écrire la logique du jeu dans la DSL .

Par exemple, mon projet actuel utilise une DSL externe simple (pour l'instant) pour spécifier une partie de la logique de jeu qui permet aux concepteurs de jeux de faire des tests d'équilibre principalement sans intervention de développeur.

Bien sûr, vous devrez écrire un analyseur; à cette fin, je pense que l'outil le plus recommandé est ANTLR qui cible pas mal de langues . Sur mon projet, nous avons opté pour la route du combinateur d'analyseurs avec jParsec (notre backend est Java, il existe des variantes dans d'autres langages), ce qui est assez agréable pour sa relation étroite avec BNF mais peut-être moins bien documenté.

Thomas Dufour
la source
2

Mon conseil serait: fais !

Mais seulement si vous en avez l'usage.

Pas besoin de créer un DSL si vous voulez simplement l'utiliser vous-même - en interne.

Galaxy est le langage de script utilisé par l'éditeur Startcraft II. C'est un excellent exemple d'une langue spécifique à un domaine.

Il cible les concepteurs de jeux plutôt que les programmeurs:

Timer - Start Raise Lava Timer as a One Shot timer that will expire in 20.0 Game Time seconds
Variable - Set Raise Lava Timer = (Last started timer)
Timer - Create a timer window for (Last started timer), with the title "Lava will raise in: ", using Remaining time (initially Visible)
Variable - Set Lava Timer Window = (Last created timer window)
Timer - Show (Last created timer window) for (All players)
Variable - Set Lava Death? = false

Exemple de didacticiel

Lisp est le langage parfait à utiliser pour créer des langages spécifiques à un domaine, mais il y a bien sûr d'autres options. Comme Boo.

De cette façon, vos concepteurs / moddeurs n'ont pas à apprendre la programmation, même si c'est juste Lua, c'est toujours de la programmation.

Edit: Permettez-moi d'ajouter qu'un DSL peut être implémenté dans un langage de script - ce n'est pas synonyme de ne pas utiliser de langage de script. Surtout si vous utilisez Lisp ou similaire, car il se prête extrêmement bien à la création de langages spécifiques à un domaine.

jacmoe
la source
1

Les dsls internes ne sont que du sucre syntaxique sur une bonne API. L'API est ce qui est le plus important. Une fois que vous avez une bonne API, faire un dsl est trivial et pas si important.

Jonathan Fischoff
la source
0

Sans doute UnrealScript est un DSL. Cela semble faire le travail, bien que je pense qu'il est possible de rendre les langages de script de jeu encore plus «spécifiques au domaine» que cela. Je recommanderais de faire une DSL s'il y a quelque chose de spécifique au domaine qui bénéficiera des changements de langue - j'ai quelques idées dans ce domaine mais rien de complètement formé actuellement.

Pensez-vous que cela devient plus courant à mesure que le développement du jeu évolue vers des langages plus adaptés aux métaprogrammes, par exemple Boo?

Je ne pense pas qu'un moteur assez nouveau prenant en charge un langage prouve cependant que le développement de jeux évolue dans une direction donnée. C'est encore tôt.

Kylotan
la source
0

Si vous avez vraiment besoin d'un langage de programmation à usage général, alors rouler le vôtre est presque certainement une erreur. Si votre langage semble avoir besoin de variables, d'évaluation d'expression, de boucles, de conditions, de classes, de fonctions, etc., il vaut mieux s'en tenir à un langage connu comme Lua, Lisp, Python, JavaScript, etc. [Unreal a abandonné le leur.]

Mais si ce dont vous avez besoin est principalement de définir des données; est peut-être déclaratif plutôt qu'impératif; définit peut-être des états et des règles (comme GDL); et n'a pas besoin de la plupart de ce qu'un langage GP fait bien, alors considérez une DSL.

Mais attention: la création de langages et de compilateurs peut être très difficile et une expérience préalable est d'une grande aide. Je recommanderais un analyseur PEG (lui-même un DSL) basé sur une grammaire EBNF (un autre DSL), et si c'est une trop grosse demande, mieux vaut ne pas essayer.

david.pfx
la source