Résumé des états d'animation du système d'entité

J'ai récemment commencé à concevoir un moteur de jeu en utilisant le paradigme Entity System, c'est-à-dire avoir des entités comme agrégation de composants et des systèmes qui implémentent le jeu réel. Alors que j'ai eu des difficultés sous divers aspects, ce qui me préoccupe le plus, c'est l'abstraction / modularité des différents composants / systèmes. Plus précisément, disons que mon Playera plusieurs états d'animation, par exemple. Walking, Sleeping, JumpingEt un type d' Opponententité a plusieurs (pas nécessairement les mêmes) états ainsi, par exemple. Walking, Hidingetc.

Comment dois-je concevoir le moteur pour qu'il gère les différents états (d'animation) de chaque type d'entité? Doit-il y avoir différents systèmes d'animation pour chaque type d'entité? Dois-je utiliser des drapeaux qui signalent au système d'animation de restituer l'entité correcte? De plus, puis-je éviter d'utiliser des énumérations "codées en dur" pour les différentes poses? Je peux voir qu'un système de script pourrait probablement aider, mais je suis presque sûr qu'il existe une solution plus simple.

Non aux systèmes différents pour chaque type, cela coupe trop fin le partage des responsabilités.

Voici ce que je fais dans mon projet personnel actuel:

Il existe de nombreuses façons de gérer l'état, mais vous en avez probablement besoin d'une logique pour les humains, ou du moins d'un pont entre l'humain et le code. Vous devez considérer le système d'animation comme un gros mélangeur au lieu d'un état discret, par exemple, vous passez du ralenti à la marche lente en ajoutant 50% de marche au système, puis plus tard 100% de course.

Externe au système d'animation, vous pouvez utiliser des chaînes pour rendre le travail avec le système agréable et facile à utiliser comme scripts et code. En interne au système, vous créez un mappage entre cette chaîne et les données d'animation , cela peut être fait avec un magasin de valeurs-clés comme un hashmap (pour éviter complètement les énumérations en faisant des données d'animation le magasin) ou avec une chaîne à énumérer recherchez si vous aimez travailler de cette façon. C'est une question de goût à ce stade. Je préfère la valeur-clé car elle peut être totalement basée sur des données à partir de fichiers XML ou INI.

Pour gérer différents types, vous pouvez, au niveau de la couche système, autoriser la création d'ensembles de mappage d'animations de sorte que l'ensemble pour "minion" et "run" pour "minion" soit différent de celui pour "run" et "joueuse". type.

En résumé: le système d'animation est générique et vous n'avez qu'un seul système; le monde extérieur a besoin d'une interface conviviale; le monde intérieur doit mapper des états génériques aux types d'entités.

Et ma liste de choses que je veux faire mais qui ne correspondent pas encore à ma conception:

À FAIRE : mapper automatiquement la vitesse de déplacement au type d'animation. Ainsi, au lieu de faire en sorte que le programme principal connaisse «marcher» ou «courir», le système d'animation peut convertir «se déplacer à une vitesse x» en l'animation appropriée.

TODO : divisez les animations comme le suivi de la tête et du torse de manière transparente.

TODO : animations de réaction (comme se faire frapper au visage) gérées par le système et non par le programme principal.