Command Ordering Architecture of Dwarf Fortress

Qual è il modo più elegante per implementare un sistema di ordinamento dei comandi per l'IA? ad esempio nella fortezza nana quando si contrassegna un'area boschiva per il taglio del legno, i nani eseguiranno quindi la seguente sequenza:

1. Vai all'albero
2. Taglia l'albero
3. Consegna legna alla scorta
4. Vai a un altro albero
5. e così via..

Ho già un comando stack funzionante no. 1 che passa dallo stato inattivo al raggiungimento della piastrella di destinazione dell'albero.

Ciò di cui ho paura è come questo diventi disordinato quando creo più ordini come questo:

Costruire una casa

1. Vai a scorta
2. portare il legno nell'area di costruzione
3. torna alle scorte
4. Porta la pietra nell'area di costruzione
5. animare lo sprite dell'edificio

Piantare

1. Vai a scorta
2. porta semi alla trama della fattoria

Brewing

1. Vai a scorta
2. Porta la pianta ferma
3. animare lo spirito di birra

Quindi la mia domanda è: come posso implementare un sistema di ordinazione dei comandi come fortezza nana ed evitare allo stesso tempo il codice spaghetti? ci sono delle strutture di dati che devo studiare? Devo mettere la sequenza di comandi su un file XML separato?

All'inizio vedi che i tuoi comandi hanno la forma di un elenco , quindi il tuo primo istinto potrebbe essere quello di ricreare quella struttura, e ogni nano scorrerà attraverso quell'elenco in sequenza. Quello che suggerisco però è di spezzare l'elenco in passaggi , con ogni passaggio con i prerequisiti e quindi eseguire l'intero comando al contrario . Lasciami dimostrare con un esempio:

Taglio del legno

• Sto portando la legna e una scorta? Sì : rilascialo
• Sto portando legno? Sì : vai a una scorta
• Sono ad un albero? Sì : tritatelo
• No a tutti sopra : vai a un albero

I vantaggi di questo sono:

• Molto semplice da implementare
• Flessibile: puoi decomporre liberamente questo elenco, aggiungere elementi, rimuovere elementi, combinare elementi
• Nessuno stato: puoi eseguire questo elenco dall'alto per qualsiasi nano in qualsiasi stato e il nano farà semplicemente la cosa giusta ^TM

svantaggi:

• È facile rimanere bloccati nei circuiti, poiché non c'è stato e consapevolezza di essere bloccati

Logicamente, puoi rappresentare questi comandi come un diagramma di flusso, che viene eseguito dall'alto ogni volta, e ciò che fai dipende dal fatto che rispondi sì / no ad ogni passaggio. Decidi tu se implementarlo nel codice o in un file esterno come XML.

Se riesci a rendere le sequenze piuttosto generali, non c'è molto di un codice spaghetti.

In caso di consegne, ad esempio: WorkTask funziona con un piano di lavoro. Il piano di lavoro dice quale tipo di unità di risorse deve scegliere, da quale tipo di casa, usando quale animazione di camminata, usando quale animazione di lavoro, tempo di lavoro e tutti questi dettagli. Quindi alla fine WorkTask potrebbe apparire come:

1. Trova% resource1% sulla mappa
2. Vai in quella posizione usando% animation_1%
3. Lavora sul posto usando% animation_2% per% time%
4. Prendi% req_resource1% nel conteggio% req_count1%
5. Vai a% home% utilizzando% animazione%
6. Avvia% animation_6% all'interno per% time_2%
7. eccetera..

Usiamo con successo l'approccio descritto. Abbiamo ~ 15 compiti nel nostro gioco. Alcuni punti salienti:

• Compiti forniscono azioni unitarie (vai lì, entra, esci, vai qui, rimani, lavora, vai)
• L'azione termina con stato Fatto o Interrotto e la passa all'attività
• Tutto è codificato (non è necessario scrivere parser, metodi di interfaccia, compatibilità all'indietro)
• Ogni attività implementa la classe Task astratta con pochi metodi comuni (creare, eseguire, salvare, caricare)
• Generalmente un'attività per modulo, ma attività simili si trovano in un modulo
• Compiti molto simili rientrano in una classe e sono regolati da pochi IF (consegna a domicilio o consegna a unità)
• Ogni attività richiede un corretto blocco e sblocco delle risorse (ad esempio se l'unità muore in QUALSIASI passaggio, la risorsa che ha bloccato deve essere rilasciata)

Quindi questo è fondamentalmente un problema di ordinamento topografico.

Hai un grafico, ogni nodo è un'attività che deve essere eseguita e alcuni nodi dipendono da alcuni altri nodi (questo è rappresentato da un bordo nel grafico dal nodo dipendente al nodo da cui dipende). Si desidera eseguire tutte le attività, quindi è necessario produrre ALCUN ordine dei nodi che è topograficamente OK (i nodi dipendenti sono dopo i nodi da cui dipendono).

Ora, di solito ci sono molti di questi ordinamenti (perché alcuni nodi non hanno dipendenze e possono essere posizionati ovunque, e alcuni nodi hanno le stesse dipendenze e non sono dipendenti l'uno dall'altro, quindi possono essere in qualsiasi ordine tra loro e qualsiasi nodo può essere messo in qualsiasi posto dopo che sono state fatte le sue dipendenze e prima che siano fatti i nodi che dipendono da esso).

È anche possibile che non ci sia modo di ordinare un grafico per topografia - questo accade quando ci sono cicli nel grafico (non hai legno, per ottenere legno devi tagliare un albero, tagliare l'albero che ti serve ascia, per farti ascia bisogno di legno). In tal caso, l'algoritmo dovrebbe probabilmente indicare al giocatore che questi compiti non possono essere svolti.

È inoltre possibile aggiungere priorità ai nodi e il compito potrebbe essere quello di trovare tale ordinamento, tra tutti gli ordini che soddisfano le dipendenze, che abbia per primo i nodi con priorità maggiore.

Puoi anche aggiungere attività ricorrenti: il modo più semplice sarà probabilmente quello di aggiungere nuovamente l'attività con timeout al grafico ogni volta che viene eseguita.

Ora come risolverlo - http://it.wikipedia.org/wiki/Topological_sorting