Le seul avantage que je peux actuellement penser est que vous pouvez effectuer des mises à jour de codage, via Lua, sans avoir à recompiler.
Ne négligez pas l'utilité de ceci si facilement. Vous ne comprendrez jamais à quel point vous serez productif tant que vous n'aurez pas supprimé l'étape de recompilation.
Le "flux" est un concept psychologique assez bien compris quand il s'agit de travailler. Le flux est ce sentiment que vous ressentez lorsque vous êtes concentré sur une activité, lorsque vous analysez et résolvez des problèmes presque sans réfléchir, etc. Vous êtes au maximum de votre productivité lorsque vous "coulez".
Les temps de compilation bousillent tout ça. Il est difficile de rester dans le flot si vous avez même une compilation de 10 secondes entre deux tests.
Lorsque vous développez le gameplay, vous avez généralement une "boucle serrée". Vous avez une idée, vous codez un test pour voir si cela fonctionne, puis vous l'essayez. Si cela ne fonctionne pas, modifiez-le et essayez à nouveau. Le temps de "code à tester" est très important pour le maintien du flux. Obtenir le plus petit possible est crucial.
Ce que Lua (ou tout autre langage de script intégré) vous permet de faire, c'est de tester les changements, pas seulement sans "compiler", mais de vivre dans le jeu . Selon la manière dont vous construisez votre jeu, vous pouvez exécuter une commande qui le relancera avec de nouveaux scripts sans avoir à arrêter et à recharger des données, etc. Non seulement vous n'êtes pas obligé de recompiler, vous n'avez pas besoin de le réexécuter.
La capacité de le faire, avec le support moteur approprié, peut augmenter considérablement la productivité.
Un autre avantage majeur du script est la possibilité de ne pas s'en soucier. Si vous avez passé beaucoup de temps à écrire en C ++, vous seriez surpris du temps que vous passez sur les minutae. Où la mémoire est supprimée. Où cela est libéré. Même si vous utilisez shared_ptr
partout, le simple fait de taper tous ces noms de type de variable vous ralentit.
Dans un langage de script à typage dynamique, vous n'avez pas à vous en soucier. Le cadrage est simple. Les fonctions sont des objets de première classe. vous n'avez pas à construire manuellement des foncteurs. C'est tellement facile de faire certaines choses.
Maintenant, il y a des points négatifs, si vous n'êtes pas un programmeur discipliné. Il est très facile d’utiliser des globals dans Lua (bien qu’il existe des moyens de l’empêcher). Ne pas s'en soucier signifie que vous pouvez être très bâclé lorsque vous codez.
Mais encore une fois, être très bâclé peut avoir des avantages .
Un autre avantage de Lua est qu’il fait un bon langage de description de données. Tout comme JSON est juste un fichier JavaScript qui construit et retourne un tableau / une table, vous pouvez créer des scripts Lua qui renvoient des tables.
Ceci est utile pour les fichiers de configuration. Le format de table de Lua est bien meilleur que celui de .ini. Le format est encore plutôt propre, compact et extensible.
Oh, et c'est toujours un script Lua, il peut donc exécuter une logique réelle. L'inconvénient de cela est ... eh bien, c'est un script Lua, donc il peut exécuter une logique réelle . Cela pourrait être désastreux dans le jeu, car l'utilisateur pourrait potentiellement commencer à tout gâcher.
Mais en réalité, cela se règle facilement. Lua est conçu pour l'intégration, ce qui signifie que l'isolement est en fait assez facile. En effet, un nouvel état de Lua ne fournit rien par défaut; vous devez réellement faire quelque chose pour exposer même la plus élémentaire des bibliothèques Lua standard. L'accès aux fichiers, l'accès aux états du jeu, etc., sont tous opt-in, pas opt-out. Et chaque état de Lua est séparé l’un de l’autre. L'état Lua que vous utilisez pour les scripts AI ne doit pas nécessairement être l'état Lua que vous utilisez pour les fichiers de configuration.
En fait, j'ai un code qui vous permet d'enregistrer de nombreuses bibliothèques Lua standard, mais qui passe et supprime tous les fichiers IO. En fin de compte, le pire qu’un fichier de configuration basé sur un script Lua puisse faire est de faire planter votre jeu immédiatement après l’exécution de celui-ci, en l’utilisant à court de mémoire. Et puisque vous ne partagez pas ces fichiers de configuration manuellement, ce ne serait pas très amusant pour un pirate informatique.
Je dirais que le plus gros inconvénient de tout langage de script est le débogage. La plupart des langages de script n'ont pas de débogueurs, et Lua n'est pas différent. Lua dispose de tous les outils nécessaires pour créer des outils de débogage. Mais il n’a pas réellement de débogueur intégré. Vous devez en mettre un ensemble. Et cela nécessitera un degré de travail raisonnable.
Ou vous pouvez rendre compte avec "printf debugging". Cela dépend vraiment de combien de code Lua vous écrivez.