Dans quels cas quels langages de script sont meilleurs que les autres?
Toutes les réponses sont appréciées, veuillez fournir une description et décrire dans quels cas le langage est excellent.
(Rappelez-vous, une langue par réponse)
Dans quels cas quels langages de script sont meilleurs que les autres?
Toutes les réponses sont appréciées, veuillez fournir une description et décrire dans quels cas le langage est excellent.
(Rappelez-vous, une langue par réponse)
Réponses:
Lua est largement utilisé dans l'industrie du jeu . Des jeux indépendants ( Aquaria ) aux titres AAA (Civilisation).
La raison principale? Je dirais qu'il est facile à apprendre et à intégrer à vos jeux. Mais on pourrait en dire autant de Python, j'en suis sûr. L'écriture, en général, n'est pas difficile. Je pense que la vraie raison pour laquelle vous devriez aller avec Lua est parce que c'est prouvé, ce qui vous donne beaucoup plus de ressources pour apprendre. Si vous avez envie d'expérimenter quelque chose hors de la norme, je commencerais à jouer avec une autre langue.
L'écureuil a une histoire intéressante. Il a été construit après qu'un architecte de jeu ait eu des problèmes avec le ramassage des ordures imprévisible de Lua, et tout devient fou même s'il n'existe pas .
Squirrel est le langage de langage utilisé dans Left 4 Dead 2 . L'API est très semblable à lua (l'auteur de Squirrel aime le design de Lua ).
Squirrel est donc un langage génial car il est un peu Lua de la deuxième génération. Il a pris les bonnes idées et enlevé les excentricités ennuyeuses.
Même de Lua:
Nouveau sur Squirrel:
Le principal inconvénient de Squirrel est que ce n'est pas Lua. Lua est beaucoup plus largement utilisé. Mais si ce n’est pas un problème, Squirrel est une victoire facile. Cependant, la popularité de la langue est souvent une caractéristique utile en elle-même, de sorte que la décision n'est pas aussi nette.
V8 Javascript de google.
Avantages :
Assez facile à utiliser
De mieux en mieux
Puissant et flexible
Autres Comme beaucoup l'ont mentionné, javascript est un outil de programmation commun. L'ajouter à mes jeux a ouvert beaucoup plus de personnes qui se sentent capables que les autres langues. Il prend également en charge une grande quantité de transtypages et de conversions pour économiser le travail du programmeur, le rend également très facile à utiliser et fonctionne bien avec STL.
CON possible:
La documentation peut être déroutante Ce n'est vraiment pas le meilleur.
Exemples Souvent une toile d'étrangeté. Manquant de simplicité, il apparaît comme un niveau bien supérieur à ce qu’il est.
Modèles Parfois, ceux-ci sont détestés ou évités.
Taille de la base de code du SDK La taille du code généré peut être considérée comme un gonflement.
Cela dépend du jeu et de sa plate-forme cible.
Un jeu utilisant 100 personnages non-joueurs (jeux RTS) a des besoins différents d'un jeu comportant seulement 2 joueurs (Street Fighter). Un jeu fonctionnant sur un PC a des besoins différents d’un jeu fonctionnant sur une console.
Lua est populaire
GameMonkey est utilisé par plusieurs équipes. C'est plus rapide que Lua et meilleur en enfilage.
Le python a été utilisé dans plusieurs jeux.
JavaScript est une option possible car vous pouvez télécharger des moteurs JavaScript. Il y a plus de programmeurs JavaScript que tout autre type de programmeur.
Il existe également des langues spécialisées.
SCUMM a été utilisé dans plusieurs jeux d’aventure et est particulièrement adapté à ces jeux.
Par souci d'exhaustivité, une autre option est mono-script , qui vous permet d'utiliser l'implémentation Novell du framework .NET pour les scripts. C'est ce que Unity utilise. Voici une autre page sur l' intégration mono dans votre application.
Le cadre Mono est plus rapide que la plupart (peut-être tous?) Des langages de script, car il n'est pas interprété et qu'il existe une couche entre le compilateur et le jeu d'instructions, il vous permet de programmer dans une variété de langages, y compris le C # et les dialectes de Python, Lua et Javascript.
Cependant, je ne suis pas sûr que ce soit gratuit sur toutes les plateformes.
Personnellement, j'ai trouvé AngelScript (voir le lien ci-dessous) beaucoup plus facile à lier au C ++ qu'à Lua lorsque je choisissais un langage de script pour mon propre projet. (J'ai en fait écrit une petite bibliothèque d'empaquetage pour la rendre encore plus facile à utiliser, au prix d'une certaine flexibilité.)
http://www.angelcode.com/angelscript/
Cela étant dit, je soupçonne que Lua présente quelques avantages qui le rendent attrayant pour les développeurs de jeux commerciaux:
(a) Il est plus mature et répandu qu'AngelScript.
(b) Sa syntaxe est plus simple pour les non-programmeurs (AngelScript ressemble beaucoup à C ++)
(c) Il a une empreinte plus petite qu'AngelScript (du moins si je me souviens bien)
Si vous écrivez juste un projet de loisir, cependant, je dirais que AngelScript mérite au moins un coup d'oeil.
Vous devez choisir un langage de script disposant de liaisons stables et bien prises en charge avec le langage de développement principal de votre jeu. Si vous écrivez votre jeu en C ou C ++, il existe des liaisons assez solides pour Python et Lua. Si vous écrivez votre jeu pour la plate-forme .NET (en utilisant C # ou un autre langage), je vous recommande vivement d'utiliser IronPython ou IronRuby. Les deux sont des implémentations linguistiques complètes qui exploitent le langage DLR (Dynamic Language Runtime) de Microsoft, qui offre d'excellentes performances et une intégration très étroite avec .NET Framework. L'interopérabilité entre C # et IronPython / IronRuby est plutôt fluide ces temps-ci, en particulier avec l'introduction de la liaison dynamique de callsite en C # 4.0.
Eh bien, ruse spécifiquement.
Avec guile, vous pouvez avoir votre propre langage DSL (Domain Specific Language) juste pour votre jeu. Une fois que vous vous êtes habitué aux parenthèses et à la notation de préfixe, le schéma est un paradis avec lequel travailler.
Si vous voulez utiliser la ruse dans un jeu sérieux, j'attendrais quelques mois jusqu'à la sortie de la version 2.0, qui comprendra, IIRC, un interprète Ecmascript ainsi que le schéma actuel. Vous pouvez également vous attendre à de grandes améliorations en termes de vitesse.
Cela dépend de ce dont vous avez réellement besoin. Comme le souligne David, Lua est très populaire, bien qu'un développeur de jeux ait noté qu'il ne savait pas trop pourquoi. Je pense que sa légèreté est une raison commune, mais à ce stade, je m'attendrais à ce que beaucoup de gens utilisent Lua parce que c'est devenu la norme de facto. Cela semble préférable pour une modification très légère.
Pour une approche plus complète, je dirais que Python est le bon choix. Civ IV l'a utilisé pour un effet décent.
Le choix d'un langage de script plutôt que d'un autre dépend de vos besoins spécifiques.
Certaines des options que vous devez choisir peuvent être:
Vitesse de l'interpréteur - si la fonctionnalité de script est uniquement utilisée, c'est-à-dire par les développeurs pour consigner le comportement statique, la vitesse et une API complète et extensible peuvent constituer l'aspect le plus important. J'ai eu de bonnes expériences avec LUA là-bas.
Facile à apprendre, accessibilité - pour un concepteur de contenu / niveau, il peut être difficile d'apprendre des langages de script plus complexes (dépend de l'arrière-plan) pour générer un comportement dynamique. Dans ce cas, l'utilisation de langues faciles à apprendre (c'est-à-dire couramment utilisées) et bien documentées pourrait être plus appropriée ici. JavaScript ou Python pourrait être une bonne solution ici.
Intégration du flux de travail - si vous avez un pipeline de production spécifique avec des outils existants, il pourrait être une mauvaise idée d’utiliser un langage qui semble fonctionner le mieux pour un cas donné si les autres outils fonctionnent avec un tout autre. Ceci est particulièrement valable si vous avez plusieurs programmeurs travaillant sur les différents outils. Dans ce cas, il pourrait être plus efficace d'utiliser le langage "pas tout à fait approprié".
Si vous travaillez sur un titre pour Windows et écrivez du code managé s'exécutant sur le Common Language Runtime (CLR) - disons par exemple en C # -, je vous suggérerais de regarder l'intégration de (Iron) Python en tant que langage de script.
D'après mon expérience, Python est très facile à enseigner aux non-programmeurs / concepteurs. Il est encore plus facile à comprendre pour les développeurs car il se lit essentiellement comme un pseudo-code. Le typage dynamique n’est qu’un des aspects qui aident les personnes peu ou pas expérimentées dans le codage à maîtriser rapidement le langage.
En plus du langage facile à apprendre et puissant, les équipes CLR et linguistiques de Microsoft (Anders Hejlsberg, Eric Lippert, Mads Torgersen, Jim Hugunin et autres) ont fait un excellent travail en exposant les fonctionnalités de compilation et d'exécution à l'aide du nouveau logiciel Dynamic Langage DLR (Language Runtime) dans .NET 4, rendant l’interopérabilité entre le code statiquement typé et le code dynamiquement typé beaucoup plus simple. D'après ce que j'ai vu et essayé jusqu'à présent, le code standard est réduit au minimum. Cela gardera votre base de code propre et maintenable.
Vous pouvez l'utiliser pour limiter les frictions entre les parties scriptées de votre jeu et le moteur. Avoir les deux exécutés dans le même ordinateur virtuel permettra également au moteur d’optimisation d’optimiser davantage votre code pendant l’exécution.
La réponse dépend beaucoup de votre environnement. Je travaille actuellement avec Unity, donc j’utilise un langage mono (dans mon cas, C #, mais Javascript et Boo sont également des options). La réponse dépend entièrement de votre situation particulière.
Si vous avez une équipe existante qui utilisera le langage de script ou un concepteur principal (niveau) qui utilisera le script, choisissez le langage de votre choix. Ils passeront leur temps avec cela, alors ils devraient être pris en charge.
[grain de sel] Si vous n'avez personne ou planifiez à long terme, alors lancez le vôtre . oui, écrire un compilateur et / ou un interprète pour un langage de script peut prendre une semaine ou deux, mais à long terme, la flexibilité sera payante à de nombreuses reprises. Il suffit de ne pas trop s'égarer et de ne pas réinventer le brainfuck. [/grain de sel]