10
\$\begingroup\$

I am currently working on an iOS project called Old Frank that I have been trying to follow a MVC design pattern.

The gist of it is.

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

Now if I understand MVC correctly you can't use a lot of the features that SpriteKit has to offer if you want to follow MVC. For instance any SKAction, collision detection, etc.

Isn't it up to the model where game objects are located and how they should react when touching other objects? Isn't it up to the model to determine location over time?

Are there any parts of SpriteKit that would be considered okayto use as the "view" in MVC other than rendering?

\$\endgroup\$
8
  • \$\begingroup\$ “I have been trying to follow a MVC design pattern” — why? \$\endgroup\$
    – Paul D. Waite
    Commented Mar 18, 2015 at 19:04
  • 2
    \$\begingroup\$ @PaulD.Waite I like the idea of keeping my model separate. This in theory makes it easier to port or recreate on another platform. It also makes it a ton easier to manage persistence which has been the biggest reason so far. \$\endgroup\$
    – Skyler Lauren
    Commented Mar 18, 2015 at 21:09
  • \$\begingroup\$ Gotcha. To achieve the persistence goal, the memento pattern might be more applicable than MVC. Your sprites might be the originator, and they’d have responsibility for producing a save-able representation of their state, and restoring themselves from that representation later. Your scene controller might be the thing that requests the representation from them. \$\endgroup\$
    – Paul D. Waite
    Commented Mar 18, 2015 at 22:41
  • \$\begingroup\$ That might also result in your save games being useable on another platform, although I suspect that’s about as far as you can go in terms of port-ability when working with a Mac/iOS-only framework like SpriteKit. \$\endgroup\$
    – Paul D. Waite
    Commented Mar 18, 2015 at 22:43
  • 1
    \$\begingroup\$ @PaulD.Waite thank you for your comments I will look into memento pattern as another pattern to consider in the future. The two questions are about the same project yes but are unrelated. Surprised to see the other one got migrated over to stackoverflow and will look into his answer some more later tonight =) \$\endgroup\$
    – Skyler Lauren
    Commented Mar 18, 2015 at 22:57

2 Answers 2

Reset to default
5
\$\begingroup\$

Your question is a good one. I've had exactly the same question regarding SpriteKit and have been very confused about the lack of information on the web about this. SpriteKit seems to encourage you to put all of your Model-View-Controller code into the same class (your SKScene subclass), which is really confusing to me. How would you ever build a game of any complexity using that technique? Combining game state (score, numLives, etc), with controller code like touchesBegan/Ended, and view rendering all in the same class gets really hard to manage beyond the simplest of games.

I agree that using the memento pattern to help with persistence is a good idea, but I also think moving to a MVC design could be beneficial. I am currently moving my game into an MVC architecture. My current approach is to have my model (game objects) manage the physicsBodies, the SKScene subclass act as the controller, and a separate class to act as the view to configure and render the visual aspects of SKNodes in the scene. I'm only part way through the process, so can't say for sure if this will be a good design, but it seems like it will be far better than have a 10,000 line subclass of SKScene.

\$\endgroup\$
2
  • \$\begingroup\$ Thank you for your answer/comment. Sounds like you feel that using the features of SpriteKit doesn't follow MVC design patter either. Feel free to email me [email protected] if you have question about how "I" am using MVC or want to go more into detail how "you" are using MVC with SpriteKit =) \$\endgroup\$
    – Skyler Lauren
    Commented Mar 23, 2015 at 12:30
  • \$\begingroup\$ There's nothing forcing you to put most of your code in the SKScene class. In fact, I find when using SpriteKit, most of the logic falls to the Nodes far more naturally than the Scene, since the Nodes are the brunt of SpriteKit. The Scene is little more than the "Controller" to handle updating and input for your Node tree. Though the "MVC" model still doesn't match SpriteKit, as the Nodes tend to be the "M" and the "V". \$\endgroup\$
    – Attackfarm
    Commented Apr 16, 2015 at 7:48
1
\$\begingroup\$

In simple terms a common design in SpriteKit games is scenes, layers, nodes and child nodes.

You might make each part into a discrete class that encapsulates all of the parts, properties and methods.

For example a Background class that has layered images, particles, various properties like the speed each layer should move and public methods to start and stop scrolling the background.

In this design you assemble these discrete classes that do their own work into the Scene which mostly handles running update:, physics, touch events etc.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .