I started making my meep project to learn about cocos2d. I have to say, once you get the initial environment set up it's really a straightforward process. One thing I've not done much of is graphics programming. Other than my previously released iPhone app Geopher Lite, I've done little with graphics other than sample code here and there. And the compass rotation on Geopher Lite wasn't exactly rocket science.
Enter cocos2d. I've known what a sprite is for a while now, but collision detection and making things interact was like magic to me until recently. I ditched college (wisely or not, who knows at this point) to go to work full time as a software developer and support a family. Which means that I missed out on a bunch of math that many computer science guys take for granted. For example, it's more effort than I would expect to try to understand transforms on coordinates and bezier paths. (Which, by the way, are really cool, I'd recommend the apple documentation on the subject if you're curious)
Cocos2d is relatively straightforward. I'm no expert, but the process seems simple: you have a director that is set up initially which takes care of delegating events each frame of your program. I believe the default is 60fps. The director is directing what's called a scene, and the scene has a bunch of nodes which represent objects and graphics. It makes sprite based manipulation fairly simple.
So... what's the point of all this? Good question. Mostly it's documenting my experience with cocos2d. But it's also a recommendation to others who may be looking to write a fairly simple game for the iPhone.
It took me about 6 hours to do a bunch of learning about cocos2d, read some tutorials, copy an example tutorial and then re-do the example tutorial as much out of my head as I could. Including a lunch break. From that point on I was adding images and features measured in minutes rather than hours. I've spent probably about 20 hours total in less than a week on Meep and already my kids are loving it. This seems like a long time until I realize that I'm learning a new API and doing graphics and pseudo-animation for the first time. Probably 5 hours of that is messing around with sound and image generation, not actual coding. So far I've got a project that does the following:
- A main menu screen with a splashy background and a few menu options. (Well, okay, they all just put up snarky alerts except for the new game one, but still -- those took about 15 minutes to complete)
- A main game screen with a static background
- A group of meeps, currently 7, when starting out.
- meep attributes include random meep colors via the tint command, random placement onscreen, random movement from place to place onscreen, sounds when you touch a meep, and the ability to drag a given meep around the screen. Oh, and they have a sub-layer which give them eyes.
Not bad for a dat and a few evenings worth of work. My 5 year old wants to have them waddle. My 7 year old wants them to sing. They want angry and scared meeps. Meeps that have character. And it's likely I will start there. I have a number of possible apps I could do with the meeps, but for starters I'll be working on a kids version. It will help me continue to get up to speed, my kids will love it (they supplied the sounds for the meeps), and I think it will be worthwhile to have such a product on the app store.
I'll see what I can do to post some pictures of the meeps in the next few days.
Subscribe to:
Post Comments (Atom)
you should link your developer blogs together, by the by...
ReplyDeleteyou pretty much lost me right after "sprite", which is a term I was very familiar with way back in the days of the C=64 which had sprite functionality via the VIC-II chip.
ReplyDeleteMEEP!
ReplyDelete