Since the announcement of the Learn SpriteBuilder book I’ve submitted the first three chapters to Apress.
Actually it’s chapters 2 through 4 because I’ve learned that the details in the first chapters tend to change significantly. This includes version numbers but also highlighted features, tool and project names, and so on.
Chapter Summary
Following is a summary of each chapter thus far.
Chapter 2 “Laying the Groundwork” first introduces the SpriteBuilder user interface but also Cocos2D (-iphone/-swift) programming basics. I really went above and beyond existing SpriteBuilder user interface tutorials to explain even the smaller details that boggled my mind when I was learning SpriteBuilder. You’ll learn the difference between Scene, Node or Layer CCBs. The effect of position, content size and scale modes (points, UI points, %, insets). What all the nodes are and what they are used for. But also how to make the code connections and what the difference between CCBReader load and loadAsScene is. The importance of Sub File nodes and the Tileless Editor View.
At the end you’ll have a firm grasp on SpriteBuilder basics and a project framework with two scenes and transitions between both scenes. Continue reading »
I bought a Korg Kaossilator (more info on Wikipedia) and show what the device can do for you, music- and/or noise-wise.
I also explain the Q1 2012 iOS Device Sales statistics, the newly released Kobold2D v1.1 and v2.0 progress, and finally I got a surprise present: Mountain Lion. Not what you think, though.
• Korg Kaossilator
o Examples
• Kobold2D 1.1 released
o Kobold2D 2.0: orientation issues delaying release
• iDevBlogADay: iOS Device Sales Statistics Q1 2012
• 10 Golden Rules for Donate Buttons
o Mountain Lion gift
Chapter 15 - The Final Chapter
This is it. The last one. I don’t know what’s going to be in it. It’s supposed to give the reader a “where to go next” kind of outlook. I hope that one of the places will be here, but obviously there’s tons of places to go and tons of things for cocos2d developers to learn.
If you have a particular idea what should be included in the greater cocos2d developer outlook kind of sense, please let me know!
Summary of working on Chapter 14 - Game Center
Amazing! Simply amazing. I think I fell in love with Game Center in the process, I haven’t worked with a networking API that’s so smooth, straightforward and easy to comprehend. No thanks to Apple’s already excellent step-by-step documentation. Still, there were a couple pitfalls and things that one could forget, and I did, that I’ve obviously included in the chapter.
On the other side, with almost a week late for this chapter, I realized how time consuming network programming is. There’s a lot of testing going on, and especially if you’re testing on two devices the process is incredibly inefficient compared to a simple single-player game. You always have to deploy to two devices for every test, and every time the delay between request and response adds to the time spent on testing. Add to that common network errors such as a drop in connection or something blocking the line with a download, and you’re up for a fun ride.
But that alone didn’t account for the one week delay. In the past two weeks I’ve been helping to renovate someone’s apartment, I got a cold, I held a presentation at the Macoun Mac OS X conference (about cocos2d obviously) while still recovering from the cold. Then our pet cat Yoshi had to see the vet and almost died during anesthesia because of a pulmonary edema. On the brighter side I’ve also attended a wedding and wrote a GameKitHelper class for this chapter which contains more stuff than I could describe in the book, including storing achievements which failed transmission, as is recommended but not implemented by Apple’s Game Center Programming Guide.
That’s also why I haven’t been answering emails timely recently. Please be patient, I’ll get to yours soon!
What’s left?
Now that I’m almost finished writing the book, what’s left? Obviously I have to review technical and other edits done by Apress. Current chapter 13 is in technical review while chapter 6 is in editorial review, after which it’s ready for production. So I’ll still be busy reviewing and making changes and additions to chapters during October and probably even November.
Then there’s the issue of the example projects having used three different versions of cocos2d, starting with 0.99.3. That was actually an oversight on my part because at the time I had 0.99.4 available. Luckily those changes are really insignificant for the first few projects. The DoodleDrop game already uses 0.99.4 and so does most of the book’s code. But for the Game Center chapter, I had to migrate the Tilemap project from 0.99.5 beta 1 to beta 3 and that was a huge step. It was easier to simply create a new project from the latest cocos2d template, then re-adding all game source code and resources to the new project. Still, that’s doable.
The bigger issue I have here is the fact that I can’t change anything in the book anymore, so the code should reflect what’s in the book. If the book mentions CCLabel then the code should use CCLabel and not CCLabelTTF. What I think is probably going to be a good compromise is to update the important (final) versions of each chapter’s example projects to cocos2d v1.0 once that is released. Obviously the code supplied with the book will remain as it is described in the book, so the upgraded code would be for reference only and a separate download. Whether I wait for v1.0 depends on how progress towards v1.0 is coming along around the book’s release date some time in December 2010.
In hindsight, I really wished I had used my Xcode template project and used that throughout the book. Back then I decided against it because it was important for me to write the code like almost all cocos2d developers would do. Now I regret the decision because I could have changed the way cocos2d developers start new cocos2d projects for the better. The whole updating process for cocos2d is a major PITA and then some, so I think I need to bring this issue to the table more frequently, more actively. At least until the cocos2d template installation procedure is changed to not copy all of the source code into each new project and then leaving it up to the developer to deal with upgrades.
I assume we’re all eagerly awaiting for cocos2 v1.0 and to be given a download link to click on. The year 2010 started so promising, with v0.9 going through beta during end of 2009 and beginning of 2010. This v0.9 never came out of beta but was re-labelled as v0.99 and released as final version in February 2010 (if I remember correctly, it was either due to the amount of changes or the closeness to v1.0 that it was labelled v0.99). At this point I was thinking that by the end of spring, at the very least, we’d have a final v1.0 of cocos2d.
But 8 months later we’ve just seen v0.99.5 beta 3 release but no v1.0 in sight yet. I’m growing impatient. I’m wondering what the holdup is? The version labels seem to grow longer and longer, as if the labels were trying to prove the point that you can still have an infinity between 0.99 and 1.0 - if you only add enough digits and other stuff after the decimal sign this could go on forever.
So, please, for the love of god, just label it v1.0 already and lets get on with regular 0.1 steps from then on!
Just out of curiosity, I made a quick spreadsheet and hacked the average time between updates in, and it told me that according to this year’s release schedule v0.99.7 will be released on December 24th, 2010 and v1.0 sometime May next year. If version number updates continued at this rate, don’t hold your breath for v1.1 before the second half of 2012.
It’s just a silly estimation based on average days between new versions and their respective version numbers, so don’t take this seriously, or the wrong way. I’m merely growing annoyed and concerned how cocos2d progress has not been reflected in the version numbers in all of 2010, and how version numbers have grown out of proportion and anything I can relate to. Not that it’s any of my concern, but I do believe that doesn’t do cocos2d a good service to continue to label new versions like “0.99.5 beta 3”, and it certainly doesn’t help to portray it in the right light if you compare it to the progress other engines have made over the same period of time - if only in version numbers.
It’s almost as if going “v1.0” meant that cocos2d would be losing its virginity, and that being a life-changing event it shouldn’t happen without about a year of dating, right?
Right?
Well, for what it’s worth, I would suggest taking on the pretty-much-standard versioning style: major version dot minor version dot bugfix/hotfix (non-breaking) releases dot build number. Then go back to the regular release cycle with about two months for each 0.1 step, regardless of what the major number is.
I mean, a major version number change should still introduce something awesome, or useful, or practical, or helpful - in that case just skip the remaining 0.5 or so ahead and bump the major version right away. Personally, if HD support is in and points instead of pixels (what a concept) then that would be it for me. That would be a good v1.0. Get it done and all the bugs fixed, and label it v1.0 so we can all start looking forward to more reasonably labelled releases. Really, it just doesn’t matter that much if you change the first frickin’ number from 0 to 1.
Personally, I would have preferred if cocos2d were now closing in on v2.0. That would be about the version we might be at if the rate from 0.5 through 0.8 had continued at the past update rate. And a v2.0 would be absolutely justified for cocos2d, and I suppose a lot of people would feel much better working with a v2.0 than the current unstable 0.99.5 beta 3.
I hope we won’t see this happening again when cocos2d tries to get pregnant, and labels itself something like “v1.98.7 beta 6 final alpha” around that time to reflect the process, or progress, or lack thereof, or hormone levels, or morning sickness intensity, or whatever.
It’s a frickin’ version number, that’s all that it is!
And it needs some serious increasing to catch up with its level of maturity. Think about what that means to how cocos2d is first perceived by an outsider.
Heck, Unity is now at v3.0, SIO2 is racing towards v2.0, Shiva is close to v1.9 and even the slow-to-release-updates iTorque has gotten to v1.4 by now. Cocos2d is still afraid to go even v1.0 and it’s a shame, because it hurts its reputation, it doesn’t do itself justice, it’s likely to be perceived as being behind the pack and it doesn’t look good in terms of actual progress being made, regardless of the actual work that’s been done this year.
Chapter 6 - Spritesheets and Zwoptex
In this chapter the focus will be on Spritesheets (Texture Atlas), what they are and when, where and why to use them. Of course a chapter about Spritesheets wouldn’t be complete without introducing the Zwoptex tool. The graphics added in this chapter will then be used for the game created in the following chapter.
The chapter will be submitted on Friday, August 6th.
Anything about Spritesheets you always wanted to know?
Just let me know. I’ll be researching what kind of issues people were and are having regarding Spritesheets. I want to make sure that they are all covered in the book.
Please leave a comment or write me an email.
Summary of working on Chapter 5 - Game Building Blocks
I finally found a better title for the chapter. A big part is about working with Scenes and Layers. A LoadingScene class is implemented to avoid the memory overlap when transitioning between two scenes. Layers are used to modify the game objects seperately from the static UI. I explain how to use targeted touch handlers to handle touch input for each individual layer, either swallowing touches or not.
The issue of whether to subclass CCSprite or not is discussed and an example is given how to create game objects using composition and without subclassing from CCNode and how that changes touch input and scheduling.
At the end the remaining specialized CCNode classes such as CCProgressTimer, CCParallaxNode and the CCRibbon class with the CCMotionStreak are given a treatment.
As you can see from the pictures, I’m also making good progress at becoming a great pixel artist. Only I have a looooooong way ahead of me still. But I admit, the little I know about art and how much less I’ve practiced it, I’m pretty happy about the results and having fun with it. The cool aspect of it is that this should be instructive art. It doesn’t have to be good. So I just go ahead and do it and tend to be positively surprised by the results. I’ll probably touch this subject in the next chapter about Spritesheets: doing your own art. It’s better than nothing, it’s still creative work even if it may be ugly to others, and it’s a lot more satisfying to do everything yourself, even if it takes a bit longer and doesn’t look as good. At least it’s all yours, you’re having fun, and learn something along the way. And you can always find an artist sometime later who will just draw over your existing images or who replaces your fart sound effects with something more appropriate.
Btw, if you’re looking for a decent and free image editing program for the Mac, I’ve been using Seashore for about a year now and I’m pretty happy with it.
