[El Matador] La création de jeux vidéos vue de l'intérieur - Episode 1

Trois programmeurs travaillent sur EL Matador depuis le début jusqu’à maintenant : Honza, Petr (un autre) et moi. Nous avons divisé le travail de programmation en secteurs relativement indépendants, ainsi nous ne faisons pas un pas sur les orteils de l’autre.

Honza travaille en majeure partie sur le code de notre très importante et puissante IA (tout ce que les ennemis peuvent voir, entendre et ce qu’ils peuvent faire de ces informations) et met en application une partie du jeu (interface utilisateur, gestion des stocks, mise en application de divers types d’entités). Il est également l’un des auteurs d’un système de script que nous utilisons.

Petr, lui, s’occupe de la physique, des collisions, de la planification des mouvements, des obstacles et des différents véhicules (voitures, hélicoptères, etc.).
Quant à moi, je mets en application le moteur, qui est le noyau de nos modules de jeux.

Bien, cela ne fait aucune différence, mais parfois les gens posent des questions comme celle-ci. La qualité d’un programme n’est pas déterminée par le nombre de lignes, plus de lignes = un peu plus d’espace pour des erreurs. Considérant la façon dont nous comptons les lignes de programme (Merci Noël Danjou), on peut dire que nous avons assez d’espace ;-) !

Global Summary (42.5 MB, actual: 36.4 MB)
Total number of lines: 1663728
Total number of lines of code: 950566
Total number of empty lines: 329478
Total number of comment lines: 199224
Total number of empty comment lines: 184460
5349 file(s) processed.

Quand vous entendez « l’IA des ennemis est bonne ou mauvaise », cela illustre souvent l’impression que l’on des effets des ennemis sur le joueur. A mon avis, nous ne pouvons parler d’aucune vraie intelligence (même tous les développeurs discuteront ceci avec ferveur).
En fait, ce qui est important dans des jeux d’action ce n’est pas « Quoi ? et Pourquoi ?» un personnage effectue une action (qui sont des décisions tactiques par elles-mêmes, et cela exige une intelligence), mais plutôt « Comment » il le fait (la méthode souhaitable est naturellement la plus impressionnante possible).

Nous employons des technologies et des algorithmes tout à fait standard pour l’IA d’El Matador. Nous utilisons un réseau que l’on appelle les waypoints pour mettre en application le terrain-reasoning (qui est en fait la capacité de l’IA de comprendre le monde dans lequel elle existe); ce sont des points dans l’espace, qui ont une information calculée à l’intérieur d’eux mêmes et aussi entre eux, pour fournir le déplacement des personnages dans l’espace et pour obtenir des informations tactiques sur l’environnement (visibilité entre waypoints, etc.). Il y a plusieurs milliers de waypoints sur un niveau (N) (voir fig. Waypoints), ainsi nous devons compresser l’information pour les waypoints NxN afin de pouvoir les garder.

Nous utilisons des Finite State Machines (FSM) pour mettre en application les personnages ennemis en tantque tels. Ces FSM sont directement soutenues par notre système de script, ainsi leur notation et notre travail avec elles, sont simples et efficaces. Chaque personnage peut se retrouver dans des situations diverses (se cacher, rechercher sa cible, combattre etc.), et chacune de ces situations exige le comportement approprié. Quelques parties de l’IA des personnages sont écrites directement dans C++, mais d’autres sont programmées dans un langage script. Certaines modifications dans l’IA, n’exigent aucun changement dans le programme principal. Il me reste un élément à mentionner : nous utilisons le Rule-Based Systems, qui nous permet de définir des ensembles de règles (encore en script), dont l’IA va se servir pour faire face à des décisions dans certaines situations.

//#include 􀂳rules_defines.h􀂴
OnSee
{
// See opponent ?
{
(in.ai_game_event_relationship == 1) && //E_CG_RELATIONSHIP_OPPONENT
(!(in.ai_game_event_obj_flags & 1)) && //dead flag is not set
(in.ai_game_event_status == 1) &&
//E_MEM_REC_STATUS_RECOGNIZED
(in.ai_game_event_last_tact_event != 20)
//E_TACTICAL_EVENT_ON_SEE_OPPONENT
:
out.ai_tactical_event_type = 20; //E_TACTICAL_EVENT_ON_SEE_OPPONENT
out.ai_tactical_event_obj = i n.ai_game_event_obj;
}
// See fighting friend ?
{
(in.ai_game_event_relationship == 2) && //E_CG_RELATIONSHIP_FRIEND
(in.ai_game_event_obj_flags & 2) && //fight flag is set
(in.ai_game_event_status == 1) &&
//E_MEM_REC_STATUS_RECOGNIZED
(in.ai_game_event_last_tact_event != 23)
//E_TACTICAL_EVENT_ON_SEE_FIGHTING_COLLEAGUE
:
out.ai_tactical_event_type = 23;
//E_TACTICAL_EVENT_ON_SEE_FIGHTING_COLLEAGUE
out.ai_tactical_event_obj = i n.ai_game_event_obj;
}
􀂫

De nos jours le système de script fait partie de tous les moteurs de jeu les plus évolués. Certains moteurs utilisent les systèmes disponibles (comme par exemple LUA, PYTHON etc.), et d’autres moteurs, comme le nôtre, utilisent leur propre système de script. D’un point de vue syntactique, notre langage de script est une « pousse » de C++, avec diverses limites et au contraire avec des extensions nécessaires pour la programmation des jeux (support de FSM, etc..).

En fait, dans leur précédent projet, les level designers étaient forcés de programmer avec toutes les contraintes habituelles liées à toute programmation. Le premier problème était de contrôler la syntaxe et d’adopter la manière de penser d’un « programmeur ». Une autre, beaucoup plus pénible, était la durée du cycle « écrire - tester – modifier ». Si un level designer voulait, par exemple, changer le comportement de n’importe quel personnage dans un niveau, il devait ouvrir le script approprié, et écrire une partie du programme correspondant au nouveau comportement.

Naturellement il faisait quelques erreurs de syntaxe dans le programme, mais ne les trouvait pas avant le re-lancement du jeu, qui prenait au moins 30 secondes.Imaginez bien que lorsqu’un niveau de 50 personnages, avec pour chacun un script de quelques centaines de lignes et avec des erreurs qui ne pouvaient être détectées qu’à un moment donné du jeu, c’était un système de travail extrêmement frustrant !

Pendant le développement d’El Matador nous avons décidé d’une nouvelle approche du scripting. La base actuelle de scripting est un système d’événements basés sur des entités. Chaque objet, qui participe au jeu de n’importe quelle manière active est relié à ce qu’on appelle l’entity class selon sa fonction. Une telle entité définit alors un ensemble de paramètres et d’événements de l’objet. Ce système est très semblable à celui de HalfLife2.

Le level designer peut alors éditer visuellement (voir image) et éliminer les problèmes d’erreurs de syntaxe et de références incorrectes dans le script, car en fait il n’écrit aucun script. Cette façon efficace de faire le scripting l’améliore considérablement. Il reste une partie du jeu que l’on peut écrire directement dans le langage script, mais seul les programmeurs s’en chargent. Ce système permet d’augmenter les fonctionnalités du jeu (pour ajouter de nouvelles entités, pour augmenter les fonctions des entités, etc...) Sans aucune intervention dans le programme. Notre objectif est de créer une architecture aussi « data drivée » que possible, mais son avantage et tous les détails de son exécution seront certainement matière à prochain journal de bord.

C’est tout pour le moment !
A la prochaine fois :-)
PETR