J'ai découvert le cadre de la prochaine génération d'agents dans Project89
TechFlow SélectionTechFlow Sélection
J'ai découvert le cadre de la prochaine génération d'agents dans Project89
Project89 adopte une approche entièrement nouvelle pour concevoir un framework d'agent haute performance dédié au développement de jeux.
Dédié à des analyses Web3 approfondiesAuteur : 0xhhh
Pour commencer par la conclusion, @project_89 adopte une approche entièrement nouvelle pour concevoir un framework d'agent. Il s'agit d'un framework d'agent haute performance destiné au développement de jeux, plus modulaire et offrant de meilleures performances que les frameworks d'agents actuellement utilisés.
Cet article a pris beaucoup de temps à être rédigé, dans le but de rendre compréhensible par tous les améliorations architecturales apportées par ce framework par rapport aux frameworks traditionnels. Il a été révisé plusieurs fois avant d’atteindre sa version actuelle, mais certaines parties restent très techniques et je n’ai pas réussi à les simplifier davantage. Si vous avez des suggestions pour améliorer l'article, n'hésitez pas à laisser un commentaire.
Profil du développeur
Il s'agit d’un blog technique, examinons donc d’abord les compétences techniques du fondateur :
Avant de créer project89, le fondateur a travaillé sur ce projet : https://github.com/Oneirocom/Magick, un logiciel utilisant l’IA pour programmer, où Shaw est également classé quatrième développeur. Ce projet figure également dans le CV de Shaw.
En haut à gauche : fondateur de project89 ; en bas à droite : lalaune, alias shaw d’ai16z
Nous allons maintenant présenter le framework d'agent haute performance de project89 :
https://github.com/project-89/argOS
I. Pourquoi utiliser ECS pour concevoir un Framework d'Agent ?
Dans le domaine des jeux vidéo, les projets utilisant actuellement l’architecture ECS incluent : jeux blockchain comme MUD et Dojo, jeux traditionnels comme Overwatch et Star Citizen. De plus, les principaux moteurs de jeu évoluent vers l’ECS, notamment Unity.
Qu’est-ce que l’ECS ?
L’ECS (Entity-Component-System) est un modèle architectural couramment utilisé dans le développement de jeux et les systèmes de simulation. Il sépare complètement les données de la logique afin de gérer efficacement diverses entités et leurs comportements dans des scénarios évolutifs à grande échelle :
-
Entity (Entité) • N'est qu'un identifiant (nombre ou chaîne), sans données ni logique. • Peut recevoir différents composants selon les besoins pour lui conférer divers attributs ou capacités.
-
Component (Composant) • Stocke les données spécifiques ou l’état de l’entité.
-
System (Système) • Responsable de l'exécution de la logique associée à certains composants.
Prenons l’exemple concret d’une action d’agent pour comprendre ce système : Dans ArgOS, chaque agent est considéré comme une Entité pouvant s’enregistrer avec différents composants. Dans l’image ci-dessous, cet agent possède quatre composants : Agent Component : stocke principalement des informations de base telles que le nom de l’agent, le modèle utilisé, etc. Perception Component : stocke principalement les données perçues depuis l’environnement extérieur. Memory Component : stocke les données de mémoire de l’entité agent, comme les actions passées, etc. Action Component : stocke les données des actions à exécuter.
Le flux de travail du System :
-
Dans le jeu, si l’agent perçoit une arme devant lui, cela déclenche la fonction d’exécution du Perception System pour mettre à jour les données dans le composant Perception de l’entité agent ;
-
Ensuite, le Memory System est activé, appelant simultanément les composants Perception et Memory, puis persistant les données perçues dans la base de données ;
-
Le Action System appelle ensuite les composants Memory et Action, récupère les informations environnementales depuis la mémoire, puis exécute finalement l'action correspondante ;
-
Nous obtenons ainsi une entité agent mise à jour dont toutes les données de composants ont été actualisées. On voit ici que le rôle principal du System est de définir quelle logique appliquer aux composants concernés.
De toute évidence, dans project89, le monde est rempli de divers types d’agents. Certains agents ne possèdent pas seulement les capacités de base citées ci-dessus, mais aussi la capacité de planifier. Cela donne alors l’illustration suivante :
Flux d’exécution des systèmes
Toutefois, le flux réel d’exécution des systèmes ne suit pas l’approche traditionnelle imaginée où le Perception System terminerait son exécution avant d’appeler le Memory System. En réalité, il n’y a aucune relation d’appel entre les différents systèmes. Chaque System s’exécute périodiquement selon un cycle prédéfini, par exemple :
-
Le Perception System pourrait s’exécuter toutes les 2 secondes pour mettre à jour les perceptions reçues de l’environnement externe, et les inscrire dans le composant Perception ;
-
Le Memory System pourrait s’exécuter toutes les 1 seconde, extrayant les données du composant Perception pour les charger dans le composant Memory ;
-
Le Plan System pourrait s’exécuter toutes les 1000 secondes, évaluant selon les informations reçues s’il doit optimiser ses objectifs et élaborer un plan raisonnable, puis enregistrer cette mise à jour dans le composant Plan ;
-
Le Action System pourrait également s’exécuter toutes les 2 secondes, permettant ainsi une réaction rapide aux informations extérieures, tout en mettant à jour son composant Action en cas de modification du composant Plan, influençant ainsi l’action initiale.
Jusqu’ici, l’article présente une version fortement simplifiée de l’architecture d’ArgOS afin de faciliter la compréhension. Passons maintenant à l’architecture réelle d’ArgOS.
II. Architecture du système ArgOS
Pour permettre aux agents d’effectuer des réflexions plus profondes et d’accomplir des tâches complexes, ArgOS a conçu de nombreux composants et systèmes.
ArgOS classe les systèmes en « trois niveaux » (ConsciousnessLevel) :
1) Systèmes conscients (CONSCIOUS)
-
Incluent RoomSystem, PerceptionSystem, ExperienceSystem, ThinkingSystem, ActionSystem, CleanupSystem
-
Fréquence de mise à jour généralement élevée (ex. toutes les 10 secondes).
-
Traitement plus proche du « temps réel » ou du niveau « conscient », tel que la perception de l’environnement, la pensée en temps réel, l’exécution d’actions, etc.
2) Systèmes subconscients (SUBCONSCIOUS)
-
GoalPlanningSystem, PlanningSystem
-
Fréquence de mise à jour relativement faible (ex. toutes les 25 secondes).
-
Traitement de la logique de « réflexion », comme vérifier ou générer périodiquement des objectifs et plans.
3) Systèmes inconscients (UNCONSCIOUS)
-
Pas encore activés pour le moment
-
Fréquence de mise à jour encore plus lente (ex. toutes les 50 secondes ou plus),
Ainsi, dans ArgOS, les différents systèmes sont divisés selon leur ConsciousnessLevel, qui détermine leur fréquence d’exécution.
Pourquoi une telle conception ? Parce que les relations entre les différents systèmes dans ArgOS sont extrêmement complexes, comme illustré ci-dessous :
-
PerceptionSystem collecte les « stimuli » provenant de l’extérieur ou d’autres entités, puis les met à jour dans le composant Perception de l’agent. Il évalue si les stimuli ont changé de manière significative, puis effectue les mises à jour appropriées selon la stabilité, le mode de traitement (ACTIVE/REFLECTIVE/WAITING), etc. Fournit enfin les informations de « perception actuelle » aux systèmes ultérieurs tels que ExperienceSystem et ThinkingSystem.
-
ExperienceSystem convertit les stimuli collectés par PerceptionSystem en « expériences » plus abstraites. Il utilise un LLM ou une logique de règles (extractExperiences) pour identifier de nouvelles expériences et les stocker dans le composant Memory. Il supprime les doublons, filtre et valide les expériences, tout en déclenchant via eventBus un événement « experience » pour d'autres systèmes ou observateurs externes.
-
ThinkingSystem est le système de « réflexion » interne de l’agent. Il extrait l’état actuel depuis les composants Memory, Perception, etc., puis génère un « résultat de réflexion » (ThoughtResult) via generateThought(...) avec LLM ou logique de règles. Selon le résultat, il peut : • Mettre à jour les « pensées » dans Memory (historique des réflexions). • Déclencher une nouvelle Action (dans Action.pendingAction[eid]). • Modifier l'apparence extérieure de l’agent (expression, posture, etc.) et générer un stimulus associé pour que d'autres entités « voient » le changement.
-
ActionSystem : si l’Action.pendingAction d’un agent n’est pas vide, il exécute réellement l’action via runtime.getActionManager().executeAction(...). Après exécution, il écrit le résultat dans Action.lastActionResult et notifie la pièce ou d'autres entités. Il produit également un CognitiveStimulus (stimulus cognitif) afin que les systèmes ultérieurs « sachent » que l’action est terminée ou puisse être intégrée à la mémoire.
-
GoalPlanningSystem évalue périodiquement l’avancement des objectifs listés dans Goal.current[eid], ou vérifie si des changements importants surviennent dans la mémoire externe ou interne (detectSignificantChanges). Quand de nouveaux objectifs sont nécessaires ou doivent être ajustés, il génère via generateGoals(...) et écrit dans Goal.current[eid]. Il met également à jour les objectifs en cours (in_progress), change leur état si les conditions de réussite ou d’échec sont remplies, et envoie un signal de réussite/échec au plan correspondant.
-
PlanningSystem génère ou met à jour les Plans (plans d’exécution) pour les « objectifs existants » (Goal.current[eid]). S’il détecte qu’un objectif n’a pas de plan actif, il produit via generatePlan(...) une feuille de route d’exécution comprenant plusieurs étapes, puis l’écrit dans Plan.plans[eid]. Il met également à jour l’état du Plan associé quand l’objectif est atteint ou échoue, et produit un stimulus cognitif correspondant.
-
RoomSystem gère les mises à jour liées à la pièce (Room) : • Récupère la liste des occupants de la pièce, générant pour chaque agent un stimulus d’« apparence » pour que d'autres entités « voient » son aspect ou ses actions. • Crée un stimulus d’environnement de pièce (par exemple, une information pertinente sur « l’ambiance de la pièce ») et l’associe. Assure que lorsque l’agent est dans un environnement spatial donné, les autres entités percevant cet espace puissent détecter ses changements d’apparence.
-
CleanupSystem recherche régulièrement et supprime les entités marquées avec le composant Cleanup. Utilisé pour recycler les stimuli ou objets inutilisés, empêchant ainsi l’accumulation d’entités invalides dans l’ECS.
-
Exemple : boucle complète allant de « voir un objet » à « exécuter une action »
Le scénario suivant illustre comment les différents systèmes coopèrent successivement durant un tour (ou quelques images) pour accomplir un processus complet.
-
Préparation du scénario : un agent (EID=1) existe dans le monde (World), en état « Active », situé dans une pièce (EID=100). Un nouvel objet « MagicSword » apparaît dans cette pièce, générant un stimulus correspondant.
-
PerceptionSystem détecte l’apparition du « MagicSword », génère un stimulus (type=« item_appearance ») pour l’agent(1), et l’ajoute à Perception.currentStimuli[1]. En comparant le hash des stimuli précédents, il constate un « changement significatif », « réactive » l’état de traitement de l’agent (mode ACTIVE).
-
ExperienceSystem remarque que Perception.currentStimuli de l’agent(1) n’est pas vide, extrait alors des informations telles que « Sword appears » pour créer une ou plusieurs nouvelles Expériences (type : « observation »). Elles sont stockées dans Memory.experiences[1] et un événement « experience » est émis.
-
ThinkingSystem lit les informations d’état depuis Memory, Perception, etc., puis appelle generateThought : « J’ai vu le MagicSword, peut-être que je peux le ramasser pour voir ce qu’il fait... ». Ce résultat de réflexion contient une action à exécuter : { tool : "pickUpItem", parameters : { itemName : "MagicSword" } }. ThinkingSystem écrit cette Action dans Action.pendingAction[1]. S’il y a un changement d’apparence (ex. « expression curieuse »), il met à jour Appearance et génère un stimulus visuel.
-
ActionSystem constate que Action.pendingAction[1] = { tool : "pickUpItem", parameters : ... }. Il exécute la logique de l’action « ramasser » via runtime.getActionManager().executeAction("pickUpItem", 1, { itemName : "MagicSword" }, runtime). Résultat obtenu : { success : true, message : "Vous avez ramassé l'épée magique" }, mis à jour dans Action.lastActionResult[1], et un événement « action » est diffusé à la pièce (100). Un stimulus cognitif (type=« action_result ») est également produit, écrit dans Memory ou capturé au prochain tour par ThinkingSystem.
-
GoalPlanningSystem (si l’agent a des objectifs) évalue périodiquement les objectifs de l’agent. Si l’un des objectifs consiste à « obtenir une arme puissante » et qu’il détecte que le MagicSword est en possession de l’agent, il peut marquer cet objectif comme terminé. S’il détecte de nouveaux changements importants (par exemple, « un nouvel objet dans la pièce affecte-t-il l’objectif poursuivi par l’agent ? »), il génère de nouveaux objectifs ou abandonne les anciens selon detectSignificantChanges.
-
PlanningSystem (s’il y a un objectif lié) vérifie si un nouveau plan est nécessaire ou si un plan existant doit être mis à jour pour un objectif tel que « obtenir une arme puissante ». S’il est terminé, le statut du plan associé est passé à « completed » ; ou, si l’objectif doit être étendu (ex. « étudier l’épée magique »), de nouvelles étapes sont générées.
-
RoomSystem (chaque image ou tour) met à jour la liste des occupants et les entités visibles dans la pièce (100). Si l’apparence de l’agent(1) change (ex. Appearance.currentAction = « holding sword »), un nouveau stimulus visuel « appearance » est créé, informant les autres agents (Agent2, Agent3) dans la même pièce que « agent1 a pris l’épée ».
-
CleanupSystem supprime les entités ou stimuli marqués (Cleanup). Si après avoir ramassé l’objet, le stimulus « MagicSword » n’a plus besoin d’être conservé, CleanupSystem peut supprimer l’entité Stimulus correspondante.
Grâce à l’interconnexion de ces systèmes, l’agent IA réalise : • Percevoir les changements environnementaux (Perception) → Enregistrer ou transformer en expérience interne (Experience) → Réfléchir et décider (Thinking) → Agir (Action) → Ajuster dynamiquement objectifs et plans (GoalPlanning + Planning) → Synchroniser l’environnement (Room) → Recycler rapidement les entités inutiles (Cleanup).
III. Analyse de l’architecture globale d’ArgOS
1. Couches principales de l’architecture
2. Classification des composants (Component)
Dans l’ECS, chaque entité (Entity) peut posséder plusieurs composants (Component). Selon leur nature et cycle de vie dans le système, on peut classer grossièrement les composants comme suit :
-
Composants d’identité principaux (Identity-Level Components) • Agent / PlayerProfile / NPCProfile, etc. • Identifient de manière unique l’entité, contiennent les informations fondamentales du personnage ou unité, doivent généralement être persistés en base de données.
-
Composants de comportement et d’état (Behavior & State Components) • Action, Goal, Plan, ProcessingState, etc. • Représentent ce que l’entité fait actuellement ou ses objectifs, ainsi que sa réponse aux commandes externes ou pensées internes. • Incluent pendingAction, goalsInProgress, plans, et les tâches ou réflexions en file d’attente. • Souvent des états à moyen/ court terme, changeant dynamiquement selon les tours de jeu ou cycles métier. • La persistance en base dépend du cas. Pour permettre la reprise après interruption, ils peuvent être régulièrement sauvegardés.
-
Composants de perception et mémoire (Perception & Memory Components) • Perception, Memory, Stimulus, Experience, etc. • Enregistrent les informations externes perçues par l’entité (Stimuli), ainsi que les « expériences » extraites après perception. • Memory peut accumuler de grandes quantités de données, comme les historiques de conversation ou événements ; souvent nécessite la persistance. • Perception peut contenir des informations en temps réel ou temporaires, valables à court terme ; décision de persister ou non selon les besoins (ex. ne conserver que les événements perceptuels importants).
-
Composants d’environnement et d’espace (Room, OccupiesRoom, Spatial, Environment, Inventory, etc.) • Représentent les informations sur pièces, environnements, positions, conteneurs d’objets, etc. • Les champs comme Room.id, OccupiesRoom, Environment, etc., doivent souvent être persistés (ex. description de la page d’accueil de la pièce, structure de la carte). • Les composants en constante évolution (ex. entité se déplaçant entre différentes pièces) peuvent être écrits de manière événementielle ou périodique.
-
Composants d’apparence et d’interaction (Appearance, UIState, Relationship, etc.) • Enregistrent les parties « visibles » ou « interactives » de l’entité, comme Avatar, pose, expression faciale, réseau de relations sociales avec d'autres entités, etc. • Une partie peut être traitée uniquement en mémoire (représentation en temps réel), tandis qu’une autre (ex. relations sociales clés) peut nécessiter la persistance.
-
Composants auxiliaires ou opérationnels (Cleanup, DebugInfo, ProfilingData, etc.) • Servent à marquer les entités à récupérer (Cleanup), ou à enregistrer des informations de débogage (DebugInfo) pour surveillance et analyse. • Existent généralement uniquement en mémoire, rarement synchronisés avec la base sauf besoin de journalisation ou audit.
3. Architecture des Systèmes
Déjà présentée ci-dessus
4. Architecture des Managers
Au-delà des Composants et Systèmes, il nous manque un gestionnaire de ressources : comment accéder à la base de données, comment gérer les conflits d’état, etc.
À gauche, les Systèmes (PerceptionSystem, ExperienceSystem, ThinkingSystem, etc.) :
• Chaque système est planifié par SimulationRuntime dans la boucle ECS, interroge et traite les entités qui l’intéressent (selon des conditions de composants).
• Pendant l’exécution de la logique, ils doivent interagir avec les Managers, par exemple :
-
Appeler RoomManager (RM) pour interroger/mettre à jour les informations de pièce.
-
Utiliser StateManager (SM) pour obtenir ou sauvegarder l’état du monde/l’agent, comme Memory, Goal, Plan, etc.
-
S’appuyer sur EventBus (EB) pour diffuser ou écouter des événements.
-
Appeler PromptManager (PM) lorsqu’un traitement en langage naturel ou un prompt est nécessaire.
----------------
À droite, les Managers (EventBus, RoomManager, StateManager, EventManager, ActionManager, PromptManager, etc.) :
• Fournissent des fonctionnalités au niveau système, n’initient généralement pas activement la logique, mais sont appelés par les Systèmes ou Runtime.
• Exemples typiques :
-
ActionManager gère spécifiquement l’enregistrement et l’exécution des actions (Action).
-
EventManager / EventBus assure le mécanisme de publication/abonnement aux événements.
-
RoomManager gère les pièces, leur agencement et les occupants.
-
StateManager assure la synchronisation entre l’ECS et la base de données ou le stockage.
-
PromptManager fournit des modèles de prompts LLM, gestion de contexte, etc.
-
Au centre, SimulationRuntime (R) :
• Est le « planificateur » de tous les Systèmes, lançant ou arrêtant les boucles de systèmes selon leur niveau (Conscient/Subconscient, etc.) ;
• Crée également les Managers lors de l’initialisation et les transmet aux différents Systèmes.
-
CleanupSystem :
• À noter particulièrement : il interagit aussi avec ComponentSync (CS) pour supprimer simultanément les composants ou abonnements aux événements lors de la récupération d’entités.
Conclusion : chaque Système lit ou écrit des données ou appelle des services via le Manager correspondant quand nécessaire, tandis que Runtime orchestre à un niveau supérieur le cycle de vie et le comportement de tous les Systèmes et Managers.
5. Interaction entre vecteurs et base de données
Dans l’ECS, les Systèmes sont les lieux où s’exécute réellement la logique, tandis que la lecture/écriture de la base de données peut être réalisée via un « gestionnaire de persistance (PersistenceManager / DatabaseManager) » ou un « gestionnaire d’état (StateManager) ». Le flux général peut être le suivant :
-
Au démarrage ou chargement (Initial Load) • StateManager / PersistenceManager charge depuis la base de données les données des composants essentiels persistants (Agents, Rooms, Goals, etc.), crée les entités (Entities) correspondantes et initialise les champs des composants. • Par exemple, lire un lot d’enregistrements d’agents et les insérer dans le monde ECS, en initialisant pour chacun les composants Agent, Memory, Goal, etc.
-
Pendant l’exécution de l’ECS (Boucle de mise à jour des Systèmes) • Les systèmes effectuent leurs tâches chaque image (ou tour) : PerceptionSystem collecte les « perceptions » et les écrit dans le composant Perception (généralement temporaire, non persisté). ExperienceSystem écrit les nouvelles « expériences cognitives » dans Memory.experiences ; si l’expérience est importante, il peut appeler immédiatement StateManager pour la stocker, ou marquer « needsPersistence » pour une écriture groupée ultérieure. ThinkingSystem / ActionSystem / GoalPlanningSystem prennent des décisions selon les contenus des composants et mettent à jour les champs dans l’ECS. Si certains composants (ex. Goal.current) subissent un changement important nécessitant la persistance (ex. nouvel objectif à long terme), via un écouteur de composant ou un événement système, StateManager est notifié pour écrire ce champ en base.
-
Persistance périodique ou déclenchée par événement (Periodic or Event-Driven) • Appeler à des points critiques (ex. mise à jour du plan ou événement important de l’agent) une interface comme PersistenceManager.storeComponentData(eid, "Goal") pour sauvegarder en base. • Ou bien, dans CleanupSystem ou via un minuteur, faire en sorte que StateManager scanne les composants ou entités marqués « needsPersistence » et les écrive en base d’un coup. • En outre, les journaux ou données d’audit (ex. historique des actions, logs de réflexion) peuvent être archivés ici.
-
Arrêt ou sauvegarde manuelle (Manual or Shutdown Save) • Lors de l’arrêt du serveur ou du processus, appeler StateManager.saveAll() pour écrire en base toutes les données non sauvegardées, garantissant ainsi que l’état ECS puisse être restauré au prochain chargement. • Pour des scénarios hors ligne ou locaux, une sauvegarde manuelle peut aussi être déclenchée.
-
Exemple complet du flux
Voici un scénario simple illustrant comment les composants interagissent avec la base de données :
-
Au démarrage : StateManager.queryDB("SELECT * FROM agents") → obtient un lot d’enregistrements d’agents, crée successivement une Entity (EID=x) pour chaque enregistrement, puis initialise les champs des composants Agent, Memory, Goal, etc. Charge simultanément les informations de pièces depuis la table « rooms », crée les entités Room.
-
Pendant l’exécution : PerceptionSystem détecte dans une pièce l’événement « apparition de MagicSword », écrit dans Perception.currentStimuli[eid]. ExperienceSystem transforme les Stimuli en Experience, assigne à Memory.experiences[eid]. ThinkingSystem décide de l’action suivante grâce aux informations de Memory, Goal, etc., génère Action.pendingAction[eid]. Après exécution de l’action par ActionSystem, le résultat est écrit dans Memory ou Action.lastActionResult. Si c’est un événement narratif majeur, la dernière partie de Memory.experiences[eid] est marquée comme needingPersistence. StateManager, après un certain temps, détecte que Memory.experiences[eid] porte le marqueur « needsPersistence », et l’écrit alors en base (INSERT INTO memory_experiences ...).
-
Arrêt ou point de reprise : selon l’ECS ou la planification du système, lors de « l’arrêt du serveur », appeler StateManager.saveAll(), écrivant dans la base l’état le plus récent des champs de composants clés en mémoire (Agent, Memory, Goal, etc.). Au prochain redémarrage, on pourra charger depuis la base et restaurer l’état du monde ECS.
• Classer les composants permet non seulement de mieux gérer les données des entités dans le projet, mais aussi de distinguer clairement les données « nécessitant persistance » des données « existant uniquement en mémoire ». • L’interaction avec la base de données est généralement gérée par un Manager spécialisé (ex. StateManager). Les Systèmes effectuent leurs lectures/écritures via ce Manager, évitant ainsi d’écrire directement du SQL ou des instructions basses dans les Systèmes. • Cela permet de bénéficier à la fois de l’efficacité et de la flexibilité logique de l’ECS, ainsi que des avantages de persistance, de reprise après interruption et d’analyse statistique offerts par la base de données.
V. Innovations architecturales
-
Le point fort de cette architecture réside dans le fait que :
-
Chaque System fonctionne indépendamment, sans relation d’appel avec les autres Systems. Ainsi, même si nous souhaitons que l’agent dispose de la capacité « percevoir les changements environnementaux (Perception) → enregistrer ou transformer en expérience interne (Experience) → réfléchir et décider (Thinking) → agir (Action) → ajuster dynamiquement objectifs et plans (GoalPlanning + Planning) → synchroniser l’environnement (Room) → recycler rapidement les entités inutiles (Cleanup) », bien que les Systems soient fonctionnellement fortement interdépendants, l’architecture ECS permet de les structurer comme des Systems indépendants, capables de fonctionner séparément sans aucun couplage. C’est probablement aussi la raison principale pour laquelle Unity migre de plus en plus vers l’architecture ECS ces dernières années.
-
Par ailleurs, si je souhaite simplement qu’un agent possède des capacités de base, il me suffit, lors de la définition de l’Entity, de réduire le nombre de composants et de Systems enregistrés pour y parvenir facilement, sans modifier une seule ligne de code.
Comme illustré ci-dessous :
-
En outre, si vous souhaitez ajouter de nouvelles fonctionnalités pendant le développement, cela n’affectera aucun autre System et vous pouvez facilement intégrer vos propres fonctionnalités. De plus, les performances de cette architecture sont nettement supérieures à celles des architectures orientées objet traditionnelles, un fait largement reconnu dans l’industrie du jeu. L’architecture ECS étant particulièrement adaptée au parallélisme, elle offre potentiellement un avantage significatif dans des scénarios Defai complexes, notamment dans les applications d’agents pour le trading quantitatif (pas uniquement dans les jeux d’agents).
-
Classer les Systems en conscient, subconscient et inconscient pour différencier la fréquence d’exécution des différents types de Systems est une conception extrêmement ingénieuse, déjà très proche des capacités humaines concrètes.
De mon point de vue personnel, il s’agit d’un framework extrêmement modulaire, aux performances exceptionnelles, avec une qualité de code élevée et une documentation de conception solide. Malheureusement, le projet $project89 a manqué de promotion autour de ce framework, ce qui m’a poussé à passer beaucoup de temps (4 jours) à rédiger cet article. Je pense que les bonnes choses méritent d’être découvertes. Une version anglaise sera publiée demain, dans l’espoir que davantage d’équipes de jeux ou de Defai découvrent ce framework et envisagent cette nouvelle option architecturale potentielle !
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@hhh69251498
