Welcome back. If you haven’t read the first part of this blog post please check it out here. Otherwise, you can download the project source from the Downloads page.
Last time I showed you how to create a new tile map for the 2D Platform Game I posted, but we didn’t get into any of the details on how the project actually works. I said that I made a few changes from the original source code written by Paul over at http://www.wildbunny.co.uk, and now were going to dig right into them.
Class Hierarchy
The class hierarchy for the game is identical to the original source.
The Player inherits from the character and the character inherits from the Moveable Object.
The Moveable Object class contains all of the generic collision detection code required for an object to interact with the world.If you wanted to create a new “character” in the game, such as an enemy, you would subclass the character class just like the player class does.
These three classes are what make this game work, but they require that we pass in a Map object during initialization.
The Map Class
The Map class is simple enough, it accepts a .tmx tile map during initialization, and aside from being passed as an object to the characters of the game, should not be touched.
The job of the map class is displaying the layers of the .tmx tile map, and giving key information about tile locations and types to the moveable object hierarchy. As you further develop this project, you will be able to add more tile types to the map class.
Player Input
The main problem porting the code from the original action script to objective-c was player input. Since we are working with a mobile device with touch input, wer’e not able to read inputs as they were before. In order to solve this problem, I had to implement two new classes.
These classes are “GSButton” and “GSDPad”. Both classes are very similar and could probably be combined into one class given a little more time.
Each of these two classes derive from the CCLayer class and accept images during initialization. They read player input and return their state with a property called “isPressed” for the GSButton and “isPressedLeft” or “isPressedRight” for the GSDPad.
The touch area of each object is currently restricted to the image’s content size, but can easily be extended for better responsiveness.
Game Layer
The last class to talk about here is the “GameLayer”. This class is where all of the other classes are put into use.
As it stands, the GameLayer has one map object, one player object, one dpad object, and one button object.
Durring initialization, the GameLayer loads the games tile set into the shared sprite frame cache. It then creates the map layer with the .tmx tile map file and adds it as a child of the layer(note: if you want to change the name of the map file, this is the place to do so).
The GameLayer creates the player object and initializes it with the map object and adds the player object as a child of the map object.
The dpad and button objects are created and added as children of the layer as well, and an update is scheduled for the layer.
The update method for the GameLayer class is very simple. it has two jobs at the moment
1- Send info about the current state of the button objects to a singleton class called “VariableStore” that is accessible by all classes.
2 – Call the setViewPointCenter method.
The setViewPointCenter: method is a method for moving the camera to follow the player originally found here. For now it does the job, but it can be moved and adjusted to incorporate smooth camera movements.
Conclusion
Well, thats about all I have to say about the code of this project without getting into anything too technical. Remember, if you want to know the gritty details about how these classes work, namely the MoveableObject class, you can find a great tutorial here by Paul Firth.
Else, leave me a comment or suggestions.
Thanks for reading!