After coming up with a complete game design document and after doing some tutorials so that I understood the basics of game design using Swift and Sprite Kit, I was ready to start prototyping the game’s code. Although I did not have any of the final artwork to being coding the game proper I could use test images to fill in the gaps.
Component based architecture also helps you do some quite fancy things. Instead of hard coding what components are in each game object, you could read a definition from an external file instead. This makes it really easy to create different behavior for your game objects without having to code, which is great for designers and quickly tweaking/iterating your game design.
Ray Wenderlich, (2015)
First I needed to create a plan of how the code will be set out. Like the game design document I decided to do this on paper so it could be shared easily between everyone working on the code whilst we were planning. We also needed to decide what kind of approach we were going to take in regards to the code.
As described in this article by Ray Wenderlich, there are several different approaches one can use in regards to game design. Personally I found one approach very interesting. Component-based game architecture is where instead of the objects in the game inheriting the same set of functions from each other, which can cause problems when the game becomes more complicated, components are inherited instead, meaning that in the long run the code is much simpler.
Here you can see the monster class has a lot of functionality in it already. If the programmer wanted to make the player be able to shoot for example, it would require copying that functionality over to the player class again.
However if component based architecture is used instead, components can be read in to both of the classes at the same time. Saving the programmer time and making the code a lot cleaner in the long run.
After looking at these approaches, we decided to stick with an object orientated game approach. Although a component based approach would be very useful, it is not really necessary for such a simple game. From our planning we would only need a few classes with quite limited functionality. Also the learning curve required to use a component based approach may offset the benefits from using this approach.
Here is the kind of structure we planned our game to have:
The code is based off of Sprite Kit’s internal architecture (I have written more about this here) where there are three main functions which we will use in our app. DidMoveToView which is called when the app displays that screen, Update which is called before each frame and TouchesBegan which is called every time the screen is touched. We also need four classes, a Player Class, a Background Class, an Object Class (which will be all the objects the player will jump over) and a Floor Class.
In DidMoveToView we need to call all of the objects that are going to be used in our scene.
In Update we need to move the player, scroll the background and check if the game has finished, either by Elias reaching the end (upon which the game will show a “win” screen) or by Elias hitting an object (upon which the app will show a lose screen.)
In TouchesBegan we need to check if Elias is touching the floor. If he is then Elias’s jumping function will be called. This means every time the screen is tapped Elias will be able to jump.
With this done hopefully we can being coding in a more clear and efficient way. It also means all the developers on the project know which features are meant to go where and code won’t be written twice or overwritten.
Ray Wenderlich, 2015. Introduction to Component Based Architecture in Games – Ray Wenderlich. [online] Available from: http://www.raywenderlich.com/24878/introduction-to-component-based-architecture-in-games [Accessed 30 Mar. 2015].