Considerazioni su un gioco di simulazione

Question

Il tipo di gioco di simulazione che ho in mente è il tipo in cui hai cose da costruire in varie posizioni e lavoratori / trasportatori che collegano tali posizioni.

Qualcosa di più simile alla serie Settlers.

Supponiamo che al momento non voglia alcuna grafica, che penso di poter gestire.

Quindi i miei dubbi sono i seguenti:

1. Ogni entità dovrebbe essere una classe e ognuna dovrebbe avere una discussione?
2. Le entità dovrebbero essere raggruppate in liste all'interno delle classi e ognuna ha un thread?

Se si prende l'implementazione 1, sarà molto difficile eseguire su macchine con specifiche basse e non si adatta bene per grandi numeri.

Se si prende l'implementazione 2, sarà meglio in termini di risorse ma poi ...

Come devo raggruppare le entità?

1. Hai una classe per le case in generale e un Elenco di interfacce per gestirlo?
2. Hai una classe per gruppi specifici di case e un Elenco oggetti per gestirlo?

e i thread?

1. Dovrei avere il semplice ciclo principale del gioco?
2. Dovrei avere un thread per ogni gruppo di classi?
3. Come si adattano i lavoratori / i trasportatori all'immagine?

Answer 1

L'approccio normale non utilizza affatto il threading, ma implementa piuttosto entità come macchine a stati. Quindi il tuo mainloop è simile al seguente:

 while( 1 )
{
    foreach( entity in entlist )
    {
        entity->update();
    }

    render();
}

Answer 2

MMORPG Eve Online utilizza Python stackless e il modello di attore per emulare un sistema thread-per-entity senza il hit delle risorse.

Dai un'occhiata a questo link per ulteriori informazioni: http://harkal.sylphis3d.com / 2005/08/10 / multithread-gioco-script-con-stackless-python /

Answer 3

Sono abbastanza certo che vuoi avere un solo thread che esegue la logica di gioco. Avere più thread non accelererà nulla e renderà solo il codice confuso. Avere un ciclo di gioco principale va benissimo, anche se le cose diventano un po 'più complicate se il gioco ha multiplayer.

Sono un po 'confuso riguardo alla parte della tua domanda relativa alle lezioni. Se capisco correttamente la tua domanda, il mio suggerimento sarebbe di avere una classe per ogni tipo di casa (allevamento di suini, mulino a vento, ecc.) Derivante da una classe base astratta comune House . Quindi memorizzeresti tutte le case del mondo di gioco in un elenco di case.

Answer 4

Pensa all'utilizzo di Erlang. Con Erlang puoi generare molti più processi (= thread leggeri) rispetto a un normale thread di sistema. Inoltre è distribuito, il che significa che se il tuo sistema non è abbastanza buono, aggiungi un altro nodo.

Un'altra alternativa sarebbe il Python senza stack (o l'attuale alternativa al Python), poiché supporta anche una sorta di leggerissimo, che è molto interessante per i motori di gioco. Eve Online lo utilizza per i suoi server. Ma non è distribuito, ma può essere facilmente raggiunto manualmente.

Answer 5

Mentre la risposta di @Mike F è per lo più corretta, devi tenere presente che l'iterazione sulle entità in un ciclo foreach rende l'ordine di valutazione significativamente deterministico, con effetti collaterali indesiderati . D'altra parte, l'introduzione di thread apre il potenziale per heisenbugs e problemi di concorrenza, quindi il modo migliore che ho visto e usato si basa sulla combinazione di due cicli: il primo raccoglie azioni di agenti / lavoratori basate su precedenti stato, il secondo ciclo compone i risultati delle azioni e aggiorna lo stato della simulazione. Per evitare possibili distorsioni, ad ogni ciclo l'ordine di valutazione è randomizzato. Questo BTW si adatta a una valutazione massicciamente parallela, soggetta a una sincronizzazione alla fine di ogni ciclo.

Answer 6

Eviterei di creare una classe separata per ogni entità perché in tal caso si verificheranno situazioni in cui si sta ripetendo il codice per le capacità condivise o si avrà un albero di eredità funky.

Direi che quello che vuoi è una singola classe e oggetti con funzionalità composta su di esso. Ho visto un articolo su un blog che parlava proprio di questo concetto in un RTS ... aspetta, penso che sia stato un tour di progetta modelli che qualcuno stava scrivendo .

Usa il modello Visitor che genera un thread sul metodo DoEvents di ogni oggetto (per mancanza di una parola migliore) per dire a ogni oggetto di fare ciò che farà durante questo dato ciclo. Sincronizza i thread alla fine del tuo loop perché non vuoi che alcuni oggetti con una logica complessa facciano ancora la loro cosa da dieci loop indietro quando in realtà è stato distrutto cinque loop fa.