A fast, easy to use, free, and community supported 2D game engine
Hey Folks,
I'm going to be giving an introductory talk on cocos2d in September and I'm trying to distill my presentation down to the most essential elements for someone new to cocos2d. Please think back to when you first started using cocos2d. What would have helped you become productive more quickly? What are some of the things that you wish you had known from day one?
Thanks in advance for the feedback.
Serban
Codemattic
Moderator
Good luck in your presentation. Im not sure if this is a good answer, but when cocos2d first came out handling audio was really difficult. There was some demo code from Apple, then Apple pulled it bc it had bugs, but everyone still used it bc it was the only thing out there. The official audio libraries from Apple leaked. You had to worry about incoming calls, is the user playing music already, what if the user hits the mute button? Yeesh. Im still not sure I know what Im doing, but thanks to Steve Oldmeadow and some others its not the complete nightmare it was.
Codemattic
Moderator
Another thing is people dont seem to know how to make a full game. I have trouble with this also. But developers seem to get some gameplay working, but then dont know how to add a main menu, help screen, how to pause, how to let the user set controls. Maybe they get their ball and paddle and bricks working in their breakout clone, but they have no idea how to do all the other stuff needed to make it more than just a proof-of-concept. People seem to have all sorts of problems with globals and how to get objects from one part of cocos to talk to another. I just imagine many developers getting a rough game concept working - and its fun, and theyre encouraged - and they have no idea how much more work is ahead for them or how to put the rest of the thing together.
anyway, hth, Codemattic
@mazebr, I will definitely put the presentation up.
@Codemattic, In regards to audio. I just recently started messing with audio, but I remember a lot of folks having issues with the SoundManager from Apple's CrashLanding sample. My sound needs thus far have been pretty basic (e.g., play some background music and play various short sound effects in response to user actions) and the AVAudioPlayer (which was unavailable prior to OS 2.2) combined with the SoundEffect class (found in a number of SDK 2.x samples like Metronome) have been perfect for me so far. I hadn't planned on it originally, but I think I will definitely put together some audio examples (maybe one with cocosdension and one with out).
In regards to making a full game, well, that's definitely a much longer talk ;-). What your getting at is how to actually architect a game that uses cocos2d. So let's get into it. How are folks architecting their cocos2d games? Looking back to some of your projects, are there specific architectural decisions that made it easier or harder to do some specific thing (e.g., get data from one component to another) in your game?
Thanks for the comments and suggestions everyone. Keep them coming. I want to put together slides and examples that are useful to the cocos2d community long after my talk.
Serban
Hi Serban,
This isn't really a Cocos2d gotcha, but my first "brick wall" was figuring out how to run the Cocos2d examples. I was completely unfamiliar with the concept of active targets and executables.
Another invaluable tip for me was setting up an Xcode Source Tree to simplify Cocos2d upgrades. Adding and removing individual source files by hand is not fun. :(
As for an introduction to Cocos2d, highlighting the ease to draw a sprite, play a sound, capture an input, and create a menu would definitely impress me.
Good luck,
Ben
P.S. The singleton pattern is a great game dev concept for referencing global data. It may be icing on the cake to show it's use in the Director, Scheduler, etc.
gravity
Member
I really second Codemattic's point. Talk about director, and how to transition from scenes, and how each scene has layer that include whatever they have. Have an example where there is a game layer and a control layer, the control layer on top responds to user input, and the game layer itself gets passed that control data through a delegate. Talk about the main concept of CocosNode too.
@donahue.dylan: Have you tried this tip from the end of the Wiki FAQ (it should probably be towards the top, or in its own 'getting started' section)
1. Open the cocos2d xcode project
2. Click: Xcode → View → Customize toolbar
3. Then, drag Active Target and Active Executable to your top project tool bar.
4. Select the test you want to view in both drop downs and hit Build and Go
I also add 'Active SDK' in step 3.
Hope that helps.
jotajota
Member
Are you actually opening the Cocos2d project? look for "cocos2d-iphone.xcodeproj" on Spotlight and double click it to open the project file on XCode. You should then see a list of about 20 different Targets on the dropdown for each example:
AccelViewportTest
AtlastTest
AtlasSpriteTest
...and so on
-Scenes vs Layers: when & how to ideally use each
-Layers: separating control/input layers, gameplay layers, and potentially UI layers... and getting them all to talk to each other
-Level loading concepts: hard coding levels is generally stupid, XML files are easy to work with, help keep art and code separate, and provide greater flexibility for making changes on either side
I think you should go through making a simple app, like in the monocle studios example. It just needs a basic menu, a background image, and maybe a sprite moving around with some touch events. That's the basics of any game right there. I might then go on to mention structuring things with scenes and layers, and using actions for movement, opacity, scaling, rotation, calling functions, etc. The ability to sequence and spawn actions really makes cocos2d a great library to work with.
One addition to my last post... you should also probably touch on if/when to use a scheduled main game loop. Some people move and render everything themselves in the game loop, though I tend to use it just for collision detection and use action chaining / events for everything else.
Some ah ha moments I had (and I don't have to think back far, I'm still very new)-
Memory management is definitely number 1. I agree that most people are learning objective-c at the same time, and a lot of programmers are accustomed to having garbage collection. One sentence to drive home - ALWAYS USE THE CONVENIENCE FUNCTIONS TO CREATE YOUR OBJECTS.
One small gotcha moment I had was that the coordinates for the iphone are bottom left to top right. On the atlas sprite sheets however, it is top left to bottom right.
Just recently learned labels can wrap to multi-line.
Lack of attaching listeners and firing events is disturbing to me (and maybe I just haven't figured this out). Most other languages let you add an object, then simply attach a listener to that object. For example, add a sprite on screen, then do something like mySprite.addEventListener( objToCall, methodToCall); etc. As far as I know, there isn't something like this in cocos or objective-c
Again, I am new, so I could be completely wrong about the above.
And, as a final note - I love cocos2d. I simply could not be where I am in my development process without it. period. =)
OJDee
Member
natedood, I get the impression you've come from an AS3 background. Like you I was looking for an event model and found that one does exist in ObjC:
Sending a notification looks like this:
[[NSNotificationCenter defaultCenter]
postNotificationName:@"myNotificationName"
object:broadcasterObject];
and registering for receiving looks like this:
[[NSNotificationCenter defaultCenter]
addObserver:listenerObject
selector:@selector(receivingMethodOnListener:)
name:@"myNotificationName"
object:nil];
This approach has worked fine for me so far and ties in well with my AS3 experience.
Oli
mikejstein
Member
@DetectiveCakes - "Layers: separating control/input layers, gameplay layers, and potentially UI layers... and getting them all to talk to each other"
Actually, how are you getting all your different layers to talk to each other?
@OJDee - thanks, that is very helpful indeed. I've been using a singleton ModelLocator class I developed to help pass event information around (sort of like cairngorm). Using the notification center will help string events between the app for sure.
What I would be really interested in finding out is if there are any way to do something like add an onClick type handler onto something like a sprite - rather than catch those events and having to go through all the sprites on the screen, find out if the hit was inside one of them, then passing the event along (which as far as I know - and that is very little - is the way to handle something like that right now). Does that make sense?
@natedood: have you looked at the new touch dispatcher in 0.8? It makes it very easy to touch enable nodes without having to loop through them yourself.
For me - memory management has been, and still is a big issue! Although thats probably more a job for the apple docs. Any simple tutorials I'm sure would still help people.
The singleton pattern helped me alot when learning how to communicate between layers/scenes (at first I started to pass references from one layer to another, but that got messy quickly!)
@Serban :
The things I wish I knew when I started with cocos :
The things in cocos you should talk about (and that have not been said in this thread yet) :
I'll post later something on game architecture and some best pratices/tips I can think of. But you know, I'm no expert, I've only started game development 9 months ago. Still learning...
@Serban again (and anyone else interested) :
If you want to talk about game architecture (and game design in general) during your introductory talk on cocos2d, it would be good to know what kind of audience will be attending and how much time you can spend on the subject. If you're dealing with people who are new to iPhone development or new to game development (or both), you need to keep things simple. But it sometimes imply dirty code.
I don't like dirty code, but maybe that's because I'm a real programmer (I mean it's my day - and night - job). A lot of people make video games for fun, as a hobby. They've probably never heard of GDD and design patterns. Some of them also don't read documentation and like to grab code samples from here and there and try to assemble them to make their games. They start coding/modifying the samples right away and try to make a game out of it. Sometimes they see a cool effect on a cocos2d video (generally a GridAction like the liquid or wave effect) and decide to make a game based on this effect. For them, "dirty code" is OK as long as it gets the job done.
If this kind of game developers constitute most of your audience, then you should probably talk about the "proper" steps to make a game before (instead of ?) game architecture. The first step does not necessarily requires a computer ! It definitely does not involve Xcode. You write down on a piece of paper your ideas for your game, you roughly draw some screens of what you'd want to obtain : splash screen, title screen with buttons, maybe options screen and about/credits screen, game screens, ranking screen, etc. You don't have to make a detailed GDD (game design document), but a sort of basic "storyboard". You determine where, when and what will be displayed (menus, buttons, HUD, bg, characters, animations, etc). You describe the game mechanics. If there's a health bar, you explain when/how you can lose/gain health. If there's a score, you write down how it's calculated, when you earn points, how many... Etc, etc.
(I forgot to mention something important you should do before step 1 : do some research about existing games similar to the one you plan to make. See what worked and what didn't work too well in these games. Think of what you can add/change/modify/do differently to make your game better)
Now that you have almost all of your game on paper, it's time to turn on the computer. If you're not already familiar with cocos, this is when you start looking into it. Read the wiki, run the examples and look at their code, maybe look at some tutorials. See how things work, discover the classes, be curious. As you do that, your brain should start associating some cocos elements to some of your game elements. You'll have to make decisions on how to implement things. Take advantage of other's experience, on the forums and on blog posts. Most importantly, if you're still unsure about how to go about something, write a very simple application which does just one of the things that seem difficult to you. See if that works. If not, try doing it differently until you have something working. You can get help from the forums, and you'll get better help if you've already tried something and if you post what you've done. Write an application for each difficulty you encounter (it's easy to do with the cocos Xcode template and/or the cocos Xcode project). I recommend not using the same application to proof your concepts because code will not be well organized (read : it will be a giant mess) and you'll be too lazy to start from scratch again to make code clean. Of course, it won't always be possible to keep it simple, especially if what you want to proof is the general performance when everything's in place.
In fact, each game is more or less unique and requires a more or less unique architecture. Whatever this architecture is, it's likely to be (very) different from a common desktop application one. Let's talk a bit about design patterns. Everybody knows the MVC pattern (Model-View-Controller). It's all over the place in the iPhone SDK. It's a very interesting pattern. It allows you to decouple the UI from the program core (data, routines, algorithms, etc). We can see easily how that would adapt to a game : view for rendering graphics, controller for player input and model for the rest (player, enemies, AI, score, etc). If you have functions to serialize/unserialize your model, then you can save/load your game relatively easily. There's a very interesting article about it on gamasutra. But most people always have a very hard time implementing the MVC pattern in their games. I remember a couple of threads on the old google discussion group where all the persons who asked how to make their games MVC compliant were answered something like : "you probably shouldn't go that way, it's more trouble than benefit". Why is it hard to use MVC in games ? This sentence (taken from this thread on the iPhone Dev SDK Forum) explains why :
Many books for object-oriented languages start with the example of "shapes who know how to draw themselves" , and it may be very OOP, but it's not very MCV
Nodes in cocos know how to draw themselves, they're both model and view. Therefore, applying the MVC pattern on a game made with cocos is definitely a lot of trouble. Next question is, how can we obtain the benefits of the MVC pattern without using it ? Well, I think the most important thing that is now hardly doable without MVC is the save/load stuff. I remember splister216 talking about how every cocos object should conform to the NSCoding protocol (if you don't know what NSCoding is, take a look at the iPhone SDK doc or search this forum or the old one because it's been discussed a lot). This way you could easily save whole cocos scenes (including running actions, timers, animations, etc) into a property list file and load these whole scenes from that same file as easily. But you'd have to modify almost every cocos source file. And in case you do, it would be very difficult to update to new cocos version.
What other options do you have ? It depends on your game. "Yeah, it always depends on your game" : although this is a boilerplate answer, it's true. A lot of iPhone games are/seem rather simple. The amount of data to save/restore may be small enough to take advantage of the NSUserDefaults class. Some games do not allow to save in the middle of a level. If you consider the games on Nintendo DS, on PSP (or even on XBox 360, on PS3, on Wii or on old-gen consoles), how many of them save the game state when you quit in the middle of the game and restore it the next time you launch them ? Anyway, if you plan to allow in-game save, you need to think it ahead. It sure will be a lot more work than just saving a few local scores and a user name.
If your game is complex, it will be very complex. If your game is simple, it will be... not very simple, but not that hard either. I don't have any miracle recipe. Next time, if anyone is interested, I'll talk about the Singleton design pattern (again !) but not from a code point of view. I'll explain why there is a controversy around it and discuss how we should use it and if it can do a bit more than just sharing data between all the scenes/layers/sprites of the game.
Hi Clain, nice post, thanks.
Would be interested to also hear your views on singletons, as there does seem to be a mixed reaction to their usefulness and whether they should be used at all by some users here. I've found them very useful, as long as you plan out what you want them to store in the first place, otherwise (in my first few attempts at using them), they quickly grew cluttered and hard to maintain (I tried to put everything inc. the kitchen sink at first).
Agree with your building small dedicated test applications. Since starting out using cocos2d (my first real attempt at developing any games more than as simple flash pong some years ago), I've built alot of little prototype apps to test certain features and learn the language and platform, whilst experimenting with various game ideas.
When I tried to initially build something more in depth, that combined a few different concepts, it soon grew into a mess. So I instead started from scratch again, put pen to paper with my designer, tried to get the rough key elements laid out on paper, and this process really helped us start to visualize how the game could be structured.
My main issue since then, and I presume this happens to a lot of newbie game developers, is your game idea can evolve, and as it evolves, you try and shoe horn in the extra features. Which if not thought out carefully (e.g. you want to experiment with new feature XYZ), you get it working, but its not extensible, or structured well, and can lead to spaghetti code. But when I started that app, I didn't think that idea would be feasible, or just hadn't thought about going down that route, so hadn't planned for it.
I know, I know, a good game design doc at the start is the ideal situation, but when your starting out, its hard to judge what you'll be able to physically pull off, so its hard to plan. At least thats what I found out.
After months of learning, and a couple of titles almost ready to ship, hopefully in the next 4 to 8 weeks, I feel more confident about starting future projects in a much more structured way. Just as I would do for my web dev work I do by day...
Hey Phil, thanks for your feedback. I agree, there are always new ideas coming along during development. A GDD can never be totally complete and accurate. However, when you discuss new ideas with other people working on the project (especially the graphics artists and level designers), it's important to explain them how these changes would affect the code and/or how much time it would take to integrate them. Sometimes you have to reject new ideas in order to meet the deadline. You can also keep them in mind for a future update. If you're close to releasing your game, you probably don't want to add new features, see this interesting article on the Valve Developer Community's wiki.
Back to today's topic : the Singleton design pattern. I briefly talked about it in this post. In fact, I don't have much to add ;) I don't do unit tests in my game programs so I don't really care about singletons possibly breaking them. Global state can be tricky and that's why you need to know what you're doing. By the way, an interesting discussion on the Singleton controversy can be found here : google-singleton-detector/wiki/WhySingletonsAreControversial (read the comments as well).
As Phil said about singletons : "I've found them very useful, as long as you plan out what you want them to store in the first place". Agreed. And if you followed the steps I described in my previous post on this thread, you should be able to determine what needs to be made global (in general, it's what needs to be accessed from different places in the code). I'm not going to paste the code to create a Singleton class since it's been done more than once on this forum (and the old google one) and you can always look at the following cocos classes which are all singletons : Director, TextureMgr, TouchDispatcher, ActionManager, SimpleAudioEngine, Scheduler. Instead, I'm going to talk about how I used the singleton pattern to both hold my global variables during the game and manage save and load stuff.
But before that, please read this thread : Component based entity systems. The topic has been quickly hijacked by ob1 and slipster216. It turned into a very interesting discussion around MVC and NSCoding. Worth reading !
.
.
.Alright ! Let me explain how I wrote the save/load functions in the following game : Dr Bubbles (this links to the cocos2d games announcement forum).
My singleton code is in the GameState class. In this singleton instance, I put all the global variables needed for the game. For example : level, shotsLeft, score, currentColor, bonusX2 and bubbles (of course, there are a lot more but let's keep it simple). If you read the Component based entity systems thread, these variables represent my model in the MVC pattern (though it's not really MVC, as ob1 pointed out in that thread). This model is all I need to resume a game. So I want the singleton instance to be serializable to easily save and load games. To achieve that, you have it conform to the NSCoding protocol. This what my GameState.h file looks like :
@interface GameState : NSObject <NSCoding> {
int level, shotsLeft, score, currentColor;
BOOL bonusX2;
NSMutableArray *bubbles;
}Of course, every variable is defined as a property (eg. @property BOOL bonusX2;). I then define a bunch of methods. The relevant one regarding the singleton pattern is :
+(GameState *)gameState;Since I want to be able to recreate the singleton from a saved file, I also have this method :
+(void)loadGameStateFromFile:(NSString *)file;In my GameState.m file, I have all the @synthesize statements for my variable. I have the regular + (GameState *)gameState { ... } and +(id)alloc { ... } functions for the singleton pattern. The singleton instance is defined as usual : static GameState *_gameState = nil;
And the loadGameStateFromFile :
+(void)loadGameStateFromFile:(NSString *)file {
@synchronized([GameState class]) {
[_gameState release];
_gameState = [[NSKeyedUnarchiver unarchiveObjectWithFile:file] retain];
}
}I then have the - (void) dealloc { ... } and - (id) init { ... } methods. In init, I initialize my variables with default values. In dealloc I release what needs to be released (in my case, I release the bubbles array). What's more interesting is the 2 methods of the NSCoding protocol :
- (void) encodeWithCoder:(NSCoder *)coder {
[coder encodeInt:level forKey:@"level"];
[coder encodeInt:shotsLeft forKey:@"shotsLeft"];
[coder encodeInt:score forKey:@"score"];
[coder encodeInt:currentColor forKey:@"curColor"];
[coder encodeBool:bonusX2 forKey:@"bonusX2"];
[coder encodeObject:bubbles forKey:@"bubblesArray"];
}
- (id) initWithCoder:(NSCoder *)coder {
self = [super init];
level = [coder decodeIntForKey:@"level"];
shotsLeft = [coder decodeIntForKey:@"shotsLeft"];
score = [coder decodeIntForKey:@"score"];
currentColor = [coder decodeIntForKey:@"curColor"];
bonusX2 = [coder decodeBoolForKey:@"bonusX2"];
bubbles = [[coder decodeObjectForKey:@"bubblesArray"] retain];
return self;
}Important :
My bubbles array contains objects of type Bubble. This Bubble class needs to conform to the NSCoding protocol, otherwise the above function won't be able to serialize the array. For example, in Bubble.h :
@interface Bubble : NSObject <NSCoding> {
int index, color;
BOOL captured;
}
@property int index, color;
@property BOOL captured;
@endAnd in Bubble.m :
@implementation Bubble
@synthesize index, color, captured;
- (void) encodeWithCoder:(NSCoder *)coder {
[coder encodeInt:index forKey:@"index"];
[coder encodeInt:color forKey:@"color"];
[coder encodeBool:captured forKey:@"captured"];
}
- (id) initWithCoder:(NSCoder *)coder {
self = [super init];
index = [coder decodeIntForKey:@"index"];
color = [coder decodeIntForKey:@"color"];
captured = [coder decodeBoolForKey:@"captured"];
return self;
}To save the GameState, when the application is about to terminate, you just do :
[NSKeyedArchiver archiveRootObject:[GameState gameState] toFile:file];And when the app is launched again, you check if the saved file exists, and if it does, you do :
[GameState loadGameStateFromFile:file];And that's it. It works very well for a game like Dr Bubbles because it's easy to dissociate the bubble sprite from the bubble data. If I had subclassed the Sprite class to make a BubbleSprite containing the index, color and captured variables as well as the TextureNode code to draw itself, I wouldn't have been able to save the game like that because the cocos classes don't conform to the NSCoding protocol.
@Clain: Thanks for that mini tutorial! I have one question:
If I had subclassed the Sprite class to make a BubbleSprite containing the index, color and captured variables as well as the TextureNode code to draw itself, I wouldn't have been able to save the game like that because the cocos classes don't conform to the NSCoding protocol.
If you had your Buble class like this:
@interface Bubble : NSObject <NSCoding> {
int index, color;
BOOL captured;
Sprite * sprite;
}
But your encodewithcoder remained the same, would it work?
I mean, do i have to encode/decode ALL of the properties of a class to make it conform to NSCoding?
In my game i have some class with a chipmunk body and shape, i would like to encode it, obviously i can't encode the shape/body, but i could encode the integers/floats, image path string, etc. to recreate it.
Thanks!
Conforming to the NSCoding protocol just means that you define the initWithCoder and encodeWithCoder methods in your class. You don't have to encode all your properties/variables. You can encode and decode whatever you want in order to recreate your object correctly in the initWithCoder method. What you want to do with your chipmunk stuff seems to be the way to go.
You must log in to post.
