SpriteKit segue il modello MVC?

Attualmente sto lavorando a un progetto iOS chiamato Old Frank che sto cercando di seguire un modello di progettazione MVC.

L'essenza è.

GameObjects(model) <- Scene(controller) -> Sprites "SpriteKit" (View)

Ora, se capisco correttamente MVC, non puoi usare molte delle funzionalità che SpriteKit ha da offrire se vuoi seguire MVC. Ad esempio qualsiasi SKAction, rilevamento delle collisioni, ecc.

Non dipende dal modello in cui si trovano gli oggetti di gioco e come dovrebbero reagire quando si toccano altri oggetti? Non dipende dal modello determinare la posizione nel tempo?

Esistono parti di SpriteKit che potrebbero essere considerate valide per essere utilizzate come "view" in MVC oltre al rendering?

— Skyler Lauren
fonte

"Ho cercato di seguire un modello di progettazione MVC" - perché?

— Paul D. Waite,

@ PaulD.Waite Mi piace l'idea di tenere separato il mio modello. Questo in teoria rende più facile il port o la ricreazione su un'altra piattaforma. Inoltre, è molto più semplice gestire la persistenza, che finora è stata la ragione principale.

— Skyler Lauren,

Gotcha. Per raggiungere l'obiettivo di persistenza, il modello di ricordo potrebbe essere più applicabile di MVC. I tuoi sprite potrebbero essere il creatore e avrebbero la responsabilità di produrre una rappresentazione salvabile del loro stato e di ripristinarsi da quella rappresentazione in seguito. Il tuo controller di scena potrebbe essere la cosa che richiede la rappresentazione da loro.

— Paul D. Waite,

Ciò potrebbe anche comportare che i tuoi salvataggi siano utilizzabili su un'altra piattaforma, anche se sospetto che ciò avvenga in termini di capacità di porta quando si lavora con un framework solo per Mac / iOS come SpriteKit.

— Paul D. Waite,

@ PaulD.Waite grazie per i vostri commenti esaminerò il modello di ricordo come un altro modello da considerare in futuro. Le due domande riguardano lo stesso progetto sì, ma non sono correlate. Sorpreso di vedere l'altro essere migrato su StackOverflow e esaminerà la sua risposta più tardi stasera =)

— Skyler Lauren

Risposte:

La tua domanda è buona. Ho avuto esattamente la stessa domanda su SpriteKit e sono stato molto confuso riguardo alla mancanza di informazioni sul web su questo. SpriteKit sembra incoraggiarti a mettere tutto il codice Model-View-Controller nella stessa classe (la tua sottoclasse SKScene), il che mi confonde davvero. Come costruiresti mai un gioco di qualsiasi complessità usando quella tecnica? Combinare lo stato del gioco (punteggio, numLive, ecc.), Con il codice del controller come tocchi Inizio / Fine e visualizzare il rendering tutti nella stessa classe diventa davvero difficile da gestire oltre il più semplice dei giochi.

Concordo sul fatto che utilizzare il modello di ricordo per aiutare con la persistenza sia una buona idea, ma penso anche che il passaggio a un design MVC potrebbe essere utile. Attualmente sto spostando il mio gioco in un'architettura MVC. Il mio approccio attuale è quello di far gestire il mio modello (oggetti di gioco) a PhysicsBodies, la sottoclasse SKScene come controller e una classe separata che funge da vista per configurare e visualizzare gli aspetti visivi di SKNodes nella scena. Sono solo a metà del processo, quindi non posso dire con certezza se questo sarà un buon design, ma sembra che sarà molto meglio di avere una sottoclasse di 10.000 linee di SKScene.

— John Cleveland
fonte

Grazie per la tua risposta / commento. Sembra che tu senta che l'utilizzo delle funzionalità di SpriteKit non segua nemmeno lo stile di progettazione MVC. Sentiti libero di scrivermi a skyler@skymistdevelopment.com se hai domande su come "io" sto usando MVC o vuoi approfondire come "tu" stai usando MVC con SpriteKit =)

— Skyler Lauren

Non c'è niente che ti costringe a mettere la maggior parte del codice nella classe SKScene. In effetti, trovo che quando si utilizza SpriteKit, la maggior parte della logica ricade sui Nodi in modo molto più naturale della Scena, poiché i Nodi sono il peso maggiore di SpriteKit. La scena è poco più che il "controller" per gestire l'aggiornamento e l'input per l'albero dei nodi. Sebbene il modello "MVC" non corrisponda ancora a SpriteKit, poiché i nodi tendono ad essere la "M" e la "V".

— Attackfarm

In termini semplici, un design comune nei giochi SpriteKit sono scene, livelli, nodi e nodi figlio.

È possibile trasformare ciascuna parte in una classe discreta che incapsula tutte le parti, le proprietà e i metodi.

Ad esempio una classe di sfondo che ha strati di immagini, particelle, varie proprietà come la velocità di ogni livello e metodi pubblici per iniziare e interrompere lo scorrimento dello sfondo.

In questo progetto assembli queste classi discrete che svolgono il proprio lavoro nella scena che gestisce principalmente l'aggiornamento in esecuzione: fisica, eventi tattili ecc.

— Jeremy
fonte