Les termes scripts et scripts semblent être utilisés de manière interchangeable sur Game Development Stack Exchange, mais à part lire des questions sur un choix de langage de script, je ne comprends pas la relation entre les scripts et les scripts, et le langage de base. Que fait généralement un script, quand serait-il utilisé, et les scripts dans certains contextes (tels que définis par les programmeurs de jeux) sont-ils différents d'un langage de script?

Les scripts sont écrits pour un langage de script. Les gens peuvent utiliser les mots dans des phrases d'argot pour obtenir le brouillon auquel vous faites référence, mais demandez à n'importe qui les définitions de Script, Scripting et Scripting Language et vous obtiendrez quelque chose comme: Scripting est l'acte d'écrire des scripts en utilisant un langage de script.

Lorsque vous intégrez un langage de script dans un moteur de jeu ou un langage de base comme vous le faites référence, vous exposez non seulement les objets dans le moteur de jeu, mais vous autorisez également l'écriture de logique pour le moteur de jeu. Une autre chose à noter est que cela transforme votre jeu en une sorte de machine virtuelle, car les langages de script se compilent rarement en langage machine et sont plutôt mis sous forme de code octet et interprétés au moment de l'exécution par votre moteur de jeu.

Cela présente d'énormes avantages pour l'équipe de développement, dont vous trouverez ci-dessous quelques-uns:

• Les langages de script sont généralement gérés en mémoire, vous n'avez donc pas à vous soucier des allocations
• Il s'agit généralement d'un langage peu typé qui supprime la nécessité de s'assurer que vous utilisez le type de variable pour ce que vous faites, créez simplement une variable et suivez-la.
• Les langages eux-mêmes sont souvent très simplistes tout en offrant un certain contrôle aux personnes qui ne sont pas programmeurs
• La modification des scripts ne nécessite pas de recompilation du moteur principal.
• Scripting vs Coding réduit souvent le temps requis pour un réglage très itératif de la logique du jeu.
• Selon la conception et la langue, vous pouvez souvent recharger un script pendant le jeu pour un réglage / test encore plus facile.

Je suis sûr que la liste peut continuer indéfiniment, je suis sûr, en particulier lorsque vous entrez dans des types de jeux spécialisés et comment les scripts peuvent aider à définir des règles de formation de groupe pour déplacer des groupes d'unités dans un RTS ou comment vous pouvez créer une logique d'interface utilisateur dans un langage de script pour fournir une interface utilisateur extensible à vos utilisateurs finaux et autres.

L'utilisation de scripts présente de nombreux avantages par rapport au «langage de base». Certains d'entre eux comprennent:

• Déplacement (plus) du contenu des développeurs principaux vers les artistes, libérant les développeurs principaux pour générer des tâches à partir des tâches de jeu
• Les scripts ont tendance à être mis en bac à sable, ne peuvent rien y faire de vraiment dangereux
• La modification des scripts ne nécessite pas de recompilation et de réexécution du jeu

Un script est généralement un morceau de code qui s'exécute en dehors de votre moteur principal. Il est généralement contenu dans des fichiers texte où vous le souhaitez. Ensuite, il est généralement chargé par le moteur, analysé et exécuté au moment de l'exécution.

Ce qui se passe généralement, c'est que quel que soit le langage que vous utilisez (Lua, Angelscript par exemple), ce langage dispose généralement de certaines fonctionnalités qui permettent au programmeur de moteur d'exposer des fonctions de moteur ou même des classes entières à l'instance du "moteur de script" en cours d'exécution. .

Par exemple (exemple totalement stupide, mais juste pour faire passer le message), votre code de jeu peut avoir une fonction publique qui génère des zombies quelque part:

void SpawnZombie(int x, int y, int hp /* whatever else */)
{
   //...
}

Le langage de script que vous utilisez maintenant vous permet d'exposer cette fonction à l'analyseur de script en cours d'exécution. Cela signifie effectivement que vous pouvez ouvrir un fichier texte, écrire "SpawnZombie (200,300,1337)" et une fois que votre moteur exécute le code, un Zombie apparaîtra à cet emplacement.

Les autres réponses énumèrent déjà quelques bons exemples de la façon dont cela est généralement utilisé, mais elles omettent un point que je trouve très important:

Ces types de scripts facilitent le débogage ou le test du gameplay pendant l'exécution.

Supposons que vous vouliez trouver le moyen idéal pour placer un zombie sur la carte afin qu'il ait l'effet d'effarouchement maximal sur le joueur une fois qu'il l'a découvert. Sans prise en charge des scripts, vous devez quitter l'application, modifier certains nombres magiques dans le code, recompiler et tester.

Avec la prise en charge des scripts (à condition que vous disposiez déjà d'une méthode de saisie de texte pendant l'exécution, par exemple une console de débogage), il vous suffit de taper "SpawnZombie (333 444 555)" et de voir à quoi cela ressemble.

De la même manière, il pourrait vous être possible de faire apparaître des armes, des véhicules, de charger différentes cartes, de modifier les valeurs de certaines choses dans le jeu, etc. testé etc.

Cela vous fera économiser des tonnes de temps dans des jeux plus complexes.

1) Les scripts sont souvent beaucoup plus faciles à modifier que le code.

2) Les scripts sont souvent modifiables sur le terrain. Cela permet de modifier le jeu.

La plupart des langages de script sont beaucoup plus expressifs que le langage du moteur principal. Souvent, le moteur est écrit dans un langage de bas niveau (par exemple, C ++) pour des raisons de performances, mais le code de gameplay n'a pas besoin d'être aussi performant et les priorités changent donc pour pouvoir exprimer facilement les fonctionnalités.

Par exemple, typage dynamique vs statique. Un autre exemple: la collecte des ordures vs la gestion manuelle de la mémoire.

Les scripts vous permettent d'écrire la logique à un niveau supérieur. En d'autres termes, vous écrivez moins de code avec plus de fonctionnalités.

Ainsi, un exemple, ce qui suit montre la différence entre écrire quelque chose dans du code et l'écrire dans un langage de script.

Code de jeu

Update Loop
{
    if (CarExplodeAnimation.FinalFrame == true)
    {
        SceneGraph.Remove(Car);
        Message("You have destroyed the car.";
    }
    else
    {
        CarExplodeAnimation.AdvanceToNextFrame();
    }

}

Code de script

PlayAnimation(ShipExplode)  // blocks until animation completes
Message("You have destoryed the car.")

Voyez combien moins de codage le concepteur doit faire si vous utilisez un langage de script?

La raison en est que dans le code du jeu, vous devez diviser un événement en plusieurs images et écrire du code dans une perspective à plusieurs images. D'autre part, les scripts vous permettent de penser à plusieurs événements d'images comme une seule ligne de code, car tous les codes supplémentaires sont abstraits derrière une fonction de script.

Vous pouvez demander, mais cette fonction ne peut-elle pas simplement être écrite dans le code du jeu aussi? Eh bien, oui, mais cela signifie que les concepteurs devront ouvrir le code source du moteur de jeu et y écrire tous les codes, et vous ne voulez pas que vos concepteurs parcourent le code source du moteur de jeu (ils pourraient accidentellement changer un autre code et le tout crash).

Au lieu de cela, vous voulez que votre concepteur fasse quelque chose comme ceci à la place: cliquez avec le bouton droit sur une voiture dans l'éditeur de carte, cliquez sur Insérer un script, tapez les codes de script. Il n'y a pas de problème avec les codes sources du moteur de jeu critique.