O SpriteKit segue o padrão MVC?

Atualmente, estou trabalhando em um projeto iOS chamado Old Frank, que tenho tentado seguir um padrão de design do MVC.

A essência disso é.

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

Agora, se eu entendo o MVC corretamente, você não pode usar muitos dos recursos que o SpriteKit tem a oferecer, se você deseja seguir o MVC. Por exemplo SKAction, qualquer detecção de colisão, etc.

Não depende do modelo em que os objetos do jogo estão localizados e como eles devem reagir ao tocar em outros objetos? Não cabe ao modelo determinar a localização ao longo do tempo?

Existem partes do SpriteKit que seriam consideradas aceitáveis para serem usadas como a "visualização" no MVC, além da renderização?

— Skyler Lauren
fonte

“Eu tenho tentado seguir um padrão de design MVC” - por quê?

— Paul D. Waite

@ PaulD.Waite Gosto da ideia de manter meu modelo separado. Em teoria, isso facilita a porta ou a recriação em outra plataforma. Também facilita muito o gerenciamento da persistência, que tem sido a maior razão até agora.

— Skyler Lauren

Peguei vocês. Para atingir a meta de persistência, o padrão de lembrança pode ser mais aplicável que o MVC. Seus sprites podem ser os criadores e eles teriam a responsabilidade de produzir uma representação salvável de seu estado e se restabelecer dessa representação posteriormente. Seu controlador de cena pode ser o que solicita a representação deles.

— Paul D. Waite

Isso também pode resultar no uso de seus jogos salvos em outra plataforma, embora eu suspeite que seja o mais longe possível em termos de capacidade de porta ao trabalhar com uma estrutura somente para Mac / iOS como o SpriteKit.

— Paul D. Waite

@ PaulD.Waite obrigado por seus comentários, examinarei o padrão de lembranças como outro padrão a ser considerado no futuro. As duas perguntas são sobre o mesmo projeto sim, mas não são relacionadas. Surpreso ao ver o outro foi migrado para stackoverflow e vai olhar para sua resposta alguma esta noite mais tarde =)

— Skyler Lauren

Respostas:

Sua pergunta é boa. Eu tive exatamente a mesma pergunta sobre o SpriteKit e fiquei muito confuso com a falta de informações na web sobre isso. O SpriteKit parece encorajá-lo a colocar todo o seu código Model-View-Controller na mesma classe (sua subclasse SKScene), o que é realmente confuso para mim. Como você construiria um jogo de qualquer complexidade usando essa técnica? Combinar o estado do jogo (score, numLives, etc), com o código do controlador como touchesBegan / Ended e a renderização de exibição na mesma classe fica muito difícil de gerenciar além do mais simples dos jogos.

Concordo que usar o padrão de lembrança para ajudar na persistência é uma boa ideia, mas também acho que mudar para um design MVC pode ser benéfico. Atualmente, estou movendo meu jogo para uma arquitetura MVC. Minha abordagem atual é fazer com que meu modelo (objetos de jogo) gerencie os physicsBodies, a subclasse SKScene atue como controlador e uma classe separada para atuar como visão para configurar e renderizar os aspectos visuais dos SKNodes na cena. Estou apenas no meio do processo, então não posso dizer com certeza se esse será um bom design, mas parece que será muito melhor do que ter uma subclasse de 10.000 linhas do SKScene.

— John Cleveland
fonte

Obrigado pela sua resposta / comentário. Parece que você acha que o uso dos recursos do SpriteKit também não segue o padrão de design do MVC. Sinta-se livre para me skyler@skymistdevelopment.com enviar e-mail se você tiver perguntas sobre como "eu" estou usando MVC ou quer ir mais em detalhes como "você" estão usando MVC com SpriteKit =)

— Skyler Lauren

Não há nada forçando você a colocar a maior parte do seu código na classe SKScene. Na verdade, acho que, ao usar o SpriteKit, a maior parte da lógica recai nos nós de maneira muito mais natural que a cena, já que os nós são o peso do SpriteKit. A cena é pouco mais que o "Controlador" para lidar com a atualização e a entrada da sua árvore de Nó. Embora o modelo "MVC" ainda não corresponda ao SpriteKit, os nós tendem a ser o "M" e o "V".

— Attackfarm

Em termos simples, um design comum nos jogos SpriteKit é cenas, camadas, nós e nós filhos.

Você pode transformar cada parte em uma classe discreta que encapsula todas as partes, propriedades e métodos.

Por exemplo, uma classe de plano de fundo que possui camadas de imagens, partículas e várias propriedades, como a velocidade de cada camada, deve se mover e métodos públicos para iniciar e parar de rolar o plano de fundo.

Nesse design, você monta essas classes discretas que fazem seu próprio trabalho na cena, que lida principalmente com atualizações em execução: física, eventos de toque etc.

— Jeremy
fonte