Know you know quite a bit, enough to make a game. Do you know how and where to start? Let’s look at how to start coding your action layer, what code to put in what methods and how to keep your update method clean and tidy.
When I started coding, and unfortunately most of my current projects are still coded that way, I simply opened up Xcode and started coding. iOS apps are a bit better because you can use the “hooks” methods they come with such as viewDidLoad and cellForRowAtIndexPath etc. Games are a bit more confusing because you are given an empty slate. At least in Cocos2d you pretty much just get an init method.
It’s important to keep your code clean and orderly. This is hard to do if you start coding without a design blueprint in mind and even then it can get messy. You get what is called spaghetti code, which is just a big jumble of code. So here is a very quick and simple tip.
I normally start out by making a paper and pen sketch of the layout. If you have read some previous posts or looked into my course at Learnable.com, you will have seen I start my apps with a hand drawn layout. I don’t use digital tools for that because you can’t beat the sketch-erase flexibility of a good old fashioned scratchpad.
Anyway, here is the tip…once I have your layout and know that names of my classes, I use comments to place ideas. IOW, I open up my mainActionLayer or actionLayer or whatever the layer name is, and I start entering lines of code like:
//Call Create my main player
//Call Make player move
//Call Enter first enemy
//IF time = x then Call Create Powerup
Notice for example I didn’t say, IF time…create power up, I said Call create…because this way I can outsource these things to individual methods. This may be very obvious but when you get to coding a game, or app, your idea is fresh in your head and you don’t want Strategic Planning to slow you down. This results in spaghetti code most of the time. What you want is to get your ideas down “on paper” first. Then worry about making those ideas happen. The reason is that you get caught up in figuring out HOW to Call Make player move. Most of the times you don’t know how to do something right off the bat or you get caught up in something silly like declaring ivars vs properties or you can’t recall the exact name of the method signature you had in mind to do something. By the time you get it right, you’ve lost track of what you were doing.
So this is what I do; I take all my idea comments and put them in the init method. Then I start creating the respective empty methods to carry out each step. For example:
-(void)createMainPlayer{
//Get image (from atlas or file) (from own subclass)
//Add to layer (or batch node)
//Position and call player initialization methods
}
This way I can see what needs to be done inside my layer and what I can do in another method or subclass. Ie, in this case I may end up calling my player from its own subclass instead of just saying CCSprite *myPlayer. This also helps me leave out specifics that belong in that subclass so that I don’t clutter up my init method or layer class with object specific code. IOW, I wrote I needed to position my object and call its player initialization methods. This means those methods to do initialization stuff for that object must reside outside of my layer, ergo, the object subclass methods.
I think this is a good tactic to creating games because believe it or not they will get more complex, even if you don’t intend them to. That will make your code unreadable in the future and with API changes or new ideas, your code will be very easy to modify.