Que recherchez-vous dans un langage de script? [fermé]


10

J'écris un petit langage embarqué pour un autre projet. Bien que le développement du jeu ne soit pas son intention initiale, il commence à ressembler à un bon ajustement, et je pense que je vais le développer dans cette veine à un moment donné.

Sans révéler aucun détail (pour éviter les biais), je suis curieux de savoir:

Quelles fonctionnalités aimez-vous dans un langage de script pour le développement de jeux?

Si vous avez utilisé Lua, Python ou un autre langage intégré tel que Tcl ou Guile comme langage de script principal dans un projet de jeu, quels aspects avez-vous trouvés les plus utiles?

  • Fonctionnalités du langage (lambdas, classes, parallélisme)

  • Fonctionnalités d'implémentation (optimisation des performances, JIT, accélération matérielle)

  • Fonctionnalités d'intégration (liaisons C, C ++ ou .NET)

  • Ou quelque chose de complètement différent?


2
Obfuscation: Parce que si elle peut être obscurcie, elle est probablement aussi assez flexible. Prenez Perl, par exemple, qui peut être obscurci dans la mesure où il ressemble à la sortie causée par le bruit de ligne d'un modem 300bps (quand quelqu'un d'autre décroche un téléphone à l'autre bout de la maison) à l'époque où ils étaient vite. ;-P
Randolf Richardson

1
@Randolf: Bon point. Le seul problème avec l'obscurcissement est qu'il a tendance à s'appuyer sur une langue stable, contrairement aux jeunes. Un obfuscateur qui fonctionne avec 0.10 peut ne pas fonctionner avec 0.11.
Jon Purdy

@Jon Purdy: C'est exact (+1 pour vous). Il y a aussi l'aspect du code obscurci qui est plus difficile à maintenir. La chose importante à noter, cependant, est que l'obscurcissement peut fournir une mesure intéressante de la flexibilité d'une langue.
Randolf Richardson

5
@Randolf: quand perl ne ressemble pas à ça?
Ken

1
@Joe Wreschnig Cela veut dire 'lequel dois-je choisir', c'est plus 'quelles fonctionnalités sont bonnes dans un langage de script'.
The Communist Duck

Réponses:


4

Je recherche deux choses: la vitesse et l'intégration. Habituellement, les deux vont de pair et avec familiarité. Malheureusement, pour C ++, il n'y a pratiquement pas de langages qui offrent vitesse et intégration. J'ai utilisé Lua et ça craignait, horriblement. J'ai passé tout le temps à écrire des liaisons et pas assez de temps pour écrire du code.

Caractéristiques linguistiques? L'intérêt d'incorporer un langage de script n'est pas pour qu'il puisse avoir des fonctionnalités de langage dynamique sifflantes que ma langue d'origine n'avait pas, c'est pour qu'il puisse être interprété au moment de l'exécution . Je ne m'inquiète vraiment pas au-delà de cela, tant qu'il est fondamentalement fonctionnel, alors c'est très bien et correspond à mon langage hôte (dans ce cas C ++). Cependant, étonnamment, les langages conçus pour être intégrés dans les applications hôtes échouent complètement à la partie concernant l' intégration .

Ai-je besoin de co-routines? Non, je n'ai pas besoin de co-routines. Ai-je besoin d'une saisie dynamique? Non, j'ai besoin de savoir quels types me reviennent de mon langage de script, et comme tout mon code existant est construit autour d'un typage très fort, j'aimerais vraiment que mon code de script puisse aussi respecter cela. Ai-je besoin d'une collecte des ordures? Non, mes types gèrent déjà leurs propres ressources et je veux vraiment une destruction déterministe. Est-ce que je veux goto? Non, je veux lever des exceptions.

Le problème que j'ai trouvé était que, fondamentalement, tous les langages de script existants étaient conçus pour étendre C, pas C ++, et ne prennent pas correctement en charge le modèle C ++ à bien des égards, et en plus de cela, ils ont une sémantique totalement différente. Comment diable vais-je traduire shared_ptr, qui est une destruction déterministe automatique, en un environnement de collecte des ordures? Vous pouvez écrire toutes les bibliothèques d'encapsulation que vous souhaitez, vous ne modifierez pas la sémantique du langage sous-jacent étant incompatible avec le langage que vous essayez d'étendre avec. Comment puis-je m'assurer que void*c'est le bon type? Comment puis-je gérer l'héritage? Comment lever et intercepter des exceptions? Cela ne fonctionne tout simplement pas.

Un bon langage de script pour C ++ serait typé statiquement, sémantiquement la valeur, détruit de façon déterministe, lève et intercepte les exceptions et respecte mes destructeurs / constructeurs / constructeurs de copie, car alors tous mes types fonctionneront simplement, agréablement et facilement, et le langage résultant sera rapide et supporte toute ma sémantique originale, facile à lier.


Vous devriez essayer quelque chose comme cette bibliothèque de wrappers que j'ai écrite moi-même récemment pour résoudre certains des mêmes problèmes que vous rencontriez. Vous pouvez très bien utiliser shared_ptrs et tout le reste, son type est sûr (autant que ce soit de toute façon), vous pouvez décider si vous voulez que la vie de quelque chose soit contrôlée par votre code ou par l'environnement Lua, il prend en charge l'héritage, et c'est extrêmement similaire à l'API Lua normale. Je ne suis pas sûr de recevoir la plainte concernant la création de liaisons, j'utilise simplement des extraits de code Vim pour effectuer mes liaisons 99% du temps.
Alex Ames

2

Pour les jeux sur le Web, trois facteurs importants pour moi sont:

  • Familiarité
  • La vitesse
  • L'intégration

J'aime particulièrement Perl, en partie parce que je connais déjà le langage, et parce qu'avec un module de serveur Web comme mod_perl2, il y a un énorme avantage en termes de performances et d'intégration - mod_perl2 conserve une version compilée des scripts en RAM (qui ne sont interprétés que sur premier chargement) qui lui donne un avantage de vitesse majeur sur les autres langages interprétés qui ne disposent pas d'options de compilation, et il s'intègre également au serveur Apache HTTPd avec une API riche en fonctionnalités qui donne accès à de nombreuses fonctionnalités très puissantes.

Ces facteurs peuvent être utiles pour le développement de jeux sur le Web (et lorsque l'accès à la base de données est nécessaire, la mise en cache des connexions à la base de données permet de réduire davantage les temps de réponse des utilisateurs). Bien sûr, ce n'est peut-être pas la solution la plus idéale pour tout car chaque langue a ses avantages (et ses inconvénients), mais elle a toujours bien fonctionné pour mes besoins.


2

Organisé par ordre d'importance (décroissante):

  • Lisible en un coup d'œil. En fait, c'est une exigence pour n'importe quel langage que je veux utiliser, mais pour les scripts, c'est sans doute plus important: les scripts, par définition, changent plus souvent que le code "de base". Donc pas de LISP ni de PERL.
  • Laconisme. Les scripts sont constamment écrits et réécrits, et taper beaucoup et beaucoup de code "passe-partout" est inefficace.
  • Débogage facile. De préférence avec des points d'arrêt, une étape, etc.
  • Intégration facile avec ma technologie "de base" choisie. Si j'utilise C ++ pour mon jeu, j'aurais besoin de bonnes liaisons C ++, comme dans LUA. Si le jeu est en C #, je choisirais un langage basé sur CLI: C #, IronPython, Boo.
  • Caractéristiques du langage: tableaux associatifs faciles, coroutines, peut-être lambdas. En fait, cela dépend principalement de la raison pour laquelle je vais utiliser les scripts. Les scripts AI sont différents, disons, des scripts d'initialisation.
  • Bonne documentation. C # a un MSDN entier dédié à lui, et Boo n'a que des sources. c'est pourquoi C # est bien meilleur.
  • Bon environnement de développement. VS ou Eclipse bat à chaque fois le Bloc-notes.

+1 Cela m'aide un peu, merci. J'attendrai de voir s'il y a d'autres discussions, mais je pense que vous en avez bien parlé.
Jon Purdy
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.