Come sarebbe MVVM per i giochi?

Question

In particolare per i giochi 2D, e in particolare i giochi Silverlight/WPF.

Se ci pensate, potete dividere un oggetto di gioco nella sua vista (il grafico sullo schermo) e un modello/modello di vista (lo stato, ai e altri dati per l'oggetto). In silverlight, sembra comune rendere ciascun oggetto un controllo utente, mettendo il modello e la vista in un singolo oggetto. Suppongo che il vantaggio di questo sia la semplicità. Ma forse è meno pulito o presenta alcuni svantaggi in termini di "motore di gioco" sottostante.

Quali sono i tuoi pensieri in merito? Quali sono alcuni vantaggi e svantaggi dell'utilizzo del pattern MVVM per lo sviluppo del gioco? Che ne dici delle prestazioni? Tutti i pensieri sono ben accetti

Answer 1

In una parola: fantastico!

In effetti, Josh Smith ha appena pubblicato un libro su MVVM utilizzando un gioco come sua app esplicativa. Ti consiglio di leggere l'eccellente (e gratuita) critique di Ward Bell dei lavori di Josh.

Answer 2

È possibile che si verifichino problemi di prestazioni, poiché MVVM generalmente porta a molte funzionalità di associazione dei dati in WPF per eseguire una separazione netta. Tuttavia, è ancora un'idea eccellente e vale la pena perseguire; puoi sempre profilare l'applicazione in un secondo momento e ottimizzare determinati elementi, se necessario. Molto probabilmente sarà l'intelligenza artificiale che sta bloccando piuttosto che l'integrazione dell'interfaccia utente.

Per quanto riguarda la divisione del modello | Visualizza modello | Vedi, mi piace prendere il seguente approccio:

1. Il Modello è tutto ciò che non ha nulla o molto poco a che fare con l'interazione diretta con l'utente. Ciò include il motore delle regole di gioco, l'intelligenza artificiale, ecc. I modelli di vista interagiscono con il modello in modi ben definiti in cui l'utente ha il controllo o riceve feedback su ciò che accade nel modello di gioco.

2. Provo a creare Visualizza modelli per ciascun componente principale dell'interfaccia. Ad esempio, se stavi creando un gioco di ruolo, potresti avere InventoryViewModel, CharacterStatsViewModel, WorldMapViewModel, ecc. Di solito non li creo per i singoli controlli/widget (come indicatori di salute, glifi degli elementi o segni '+' per salire di livello) a meno che non abbiano un'interfaccia ragionevolmente complessa.

3. Le viste sono ovviamente come l'utente può finalmente interagire e osservare, il che è abbastanza semplice da capire. Una cosa bella è che puoi creare più viste per un determinato ViewModel, quindi potresti avere una vista ampia per l'inventario e anche una vista più piccola per un rapido accesso a elementi importanti, ad esempio, se il modo in cui interagisci con loro è essenzialmente la stesso.