Implementazione di agenti basati sullo stato all'interno di un approccio di Entity-Component-System

1

Un agente guidato dallo stato è un agente che esegue un'azione in base al suo stato corrente. La logica può essere implementata mediante l'uso di un D-FSM che cambia stato in base alla "percezione" e agli "stimoli" dell'Agent ed esegue azioni all'ingresso, all'ingresso e all'uscita da uno stato.

Sto cercando di implementare questo tipo di design in un'architettura Entity-Component-System (ECS) .

Il mio primo pensiero è stato quello di implementare un componente "FSM" contenente un current_state e un rulebook, un sistema che aggiorna il componente FSM current_state in base al suo regolamento e un sistema che implementa le azioni di un'entità (e modifica i suoi componenti di conseguenza) a seconda dello stato del componente FSM.

Non sono sicuro che si tratti di un'implementazione ECS corretta e che possa rappresentare in modo pulito enter_state / exit_state - > eseguire un comportamento di azione.

Quindi, come dovrebbe essere implementato SDA in un'architettura ECS?

    
posta Animamorta 24.07.2014 - 19:15
fonte

1 risposta

2

Dipende da cosa è l'entità reale e qual è la cosa reale che stai modellando come una macchina a stati.

In un mondo ideale, la macchina statale vivrebbe interamente contenuta all'interno del componente. Il componente potrebbe esporre un'interfaccia, con cui l'utente finale potrebbe lavorare e non sapere / preoccuparsi che gli interni stiano effettivamente spostando una macchina di stato. Ciò è positivo quando la cosa che stai modellando è una "cosa" che esiste come parte dell'entità più grande e quando la macchina a stati è relativamente statica - input conosciuti, con uscite conosciute e transizioni di stato note.

Ma a volte, l'entità stessa agisce come una sorta di meccanismo di aggregazione per la macchina a stati. Ciò accade più frequentemente quando la macchina a stati è dinamica. Le entrate / uscite / transizioni di stato possono cambiare a seconda di quali componenti vivono nell'entità. In questo caso, potresti voler separare la macchina a stati in base a quali bit vuoi modificare e dove si trovano le dipendenze.

La cosa importante su cui concentrarsi qui è lo spirito del Principio di Responsabilità Unica: "una classe o un modulo dovrebbe avere una sola ragione per cambiare". Dove disegni le linee per renderlo vero dipende da come prevedi che il tuo sistema cambi nel tempo.

    
risposta data 24.07.2014 - 19:43
fonte