Before going forward, we should mention about a certain pitfall that could plague a game that relies too much on the concept of nodes and even the general concept of inheritance-based structuring in OOD. When possible, it's best not to rely too much on inheritance for your game logic and work more with what's known as composite-based structuring. We'll go deeper into this in our next chapter when we talk about the helper game development framework first introduced in iOS 9, GamePlayKit, but here's a glance so that we know that working with inheritance and even nodes might not always be the best solution in our games.

At first glance, one might think that inheritance-based structuring is perfectly made for game development. Many of us familiar with OOD know that we can have generic parent classes or nodes of our game objects, such as an all-encompassing GameObject class, and then use inheritance and polymorphism to work with unique child classes from this base class. For small, simplistic games that will hold true, but games tend to have objects that could share some of the same functionality, but make no sense to have in a parent-child structure.

Take this typical structuring in a tower-based strategy game:

In a typical tower game, we'd have our base, tower, and enemy objects that can all inherit from a generic GameObject class we define. Towers can fire at enemies but so can enemies back at the towers and other player-based objects. Part of good programming and design is to have reusable code and methods. Normally, we'd do this with inheritance. The preceding graph shows two-way inheritance that can solve this. We would then want a ShootingEnemy class that inherits the movement and shooting functionality. We can't do this, as that would involve inheriting from two separate and rather unrelated classes of objects. In OOD, there's only one child-parent relationship. The next solution shown on the right would be to have the generic GameObject class have this functionality. The issue that arises is that our once simple GameObject parent class becomes all but simple and we inevitably want to add additional features and functionalities to objects in our game. In the past, this would involve refactoring tons of code to accommodate what essentially are simple design add-ons. Protocols used to be somewhat of a solution to this as they'd force us to make a class in a certain way, but even they could get confusing and don't involve the implementation of these features.

The solution would be to work with entities and components.

This preceding diagram gives an example of composite-based structuring. With this methodology, we can have components that share similar functionality, being used by multiple and usually unrelated game objects. This way, the generic GameObject class in this example doesn't have to have every possible function of its child class and we can keep Enemy classes as being members of Enemy. The shared functionality can be written once and then used throughout the game and even in the other games we wish to make. iOS 9's SpriteKit demo, DemoBots, and the SceneKit demo mentioned earlier, Fox, both use composite-based structuring for actions and animations.

It's important when thinking with nodes in both SpriteKit and SceneKit that they are used in the context of the View of the MVC model, or in both frameworks, the context of their scenes.

As for scenes in SceneKit, let's move on to making a very basic one.