It seems like a no-brainer to most computer-affiniados and gamers: eventually, all video games will be distributed online. The question is only, when?
To retailers this seems to be a whole different story. Most of them are in denial, as I can tell from occasionally reading retail game publishing magazines. They’ll be in for quite the surprise in about 10 years, when it will be obvious even to the blind-folded that boxed retail games will soon be a thing of the past. Alongside Blu-ray movies. It is inevitable, as video games and movies alike are moving towards their most natural distribution media format: instant digital home delivery.
Not only will this reduce inventory risks for publishers, it also cuts out the retail middle-man, allowing direct to consumer sales with full control over pricing and availability. With all the advantages of tracking each user’s usage and profile information for marketing purposes. At the same time conveniently disallowing or at least automating the consumer’s rights to re-sell or lend digital products or issue refunds. Neither Floppy Disks nor Optical Media have offered such compelling advantages to media producers.
But first, let’s consult the history of video game distribution before analyzing what it can tell us about the future. One thing I can say with conviction in advance: retail stores selling physical games and movies will be as commonplace in the 2030s as are Vinyl record stores today.
Whaaaaaat?
You heard right: if you want to forget about using retain, release and autorelease in your code, then the newly introduced automatic reference counting (ARC) mechanism (aka “automatic memory management”) is the way to go. And guess what?
Kobold2D Preview 6 fully supports ARC out of the box!
You may have heard that Cocos2D is incompatible with ARC at this time, and you’re right. However, the Cocos2D version in Kobold2D Preview 6 released just now has been improved to work with ARC. This post explains the most important changes to make Cocos2D compatible with ARC. All 15 Kobold2D example projects compile with and without ARC, just like the other libraries Kobold2D makes use of!
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.
I need help. I’ve run into strange problems with a very simple cocos2d v0.99.4 project created from the cocos2d project template. It’s two scenes with a layer each, much like the regular HelloWorldScene layer. Each scene is simply supposed to replace itself with the other scene, on touch. What happens is that the first scene started with runWithScene is never deallocated after the first scene change. So it stays in memory and keeps receiving the touches, which means a touch is always behaving as if switching from the first to the second scene.
What’s more, if I add the onEnter and onEnterTransitionDidFinish methods to the first scene, without adding any code to them, the first scene/layer doesn’t receive any touch events at all. The second scene doesn’t show this behavior and works fine with these methods implemented.
Maybe I’m just overlooking the very obvious, if you could take a look and let me know if there’s anything I’m doing wrong with this code please let me know! Thank you.
Download the code here: ScenesAndLayers02
Chapter 4 - First Simple Game
After Chapter 3 covered the fundamentals of the cocos2d game engine, this chapter will put to use what you’ve learned. The simple game is all about droping enemies that you have to avoid via accelerometer controls. Sort of like an inverse Doodle Jump. But it’s not just about the gameplay itself, I want the game to be reasonably complete with a main menu, scene transitions, game over and of course audio.
The chapter will be submitted on Friday, July 23rd.
Do you have any suggestions for the game?
What do you think should be in a first cocos2d game? Let me know!
Summary of working on Chapter 3 - Essentials
When I started the chapter I wasn’t really sure about its focus and progress was a little slow. Eventually it clicked and I found myself ending up having written more pages than needed and still having a great number of things left untold. The key was looking at the cocos2d API reference documentation and remembering what it was like when I was a beginner. Sure, every class, method and property is there but for a beginning cocos2d developer the API reference is just a huge list of names. In other words, if your experience was or is anything like mine was, it’s frustrating to work with the API reference.
I ended up writing about the cocos2d engine design and its scene graph first, the remaining 80% of the chapter explain in detail with lots of code samples how to use those darn CCNode classes. All the important ones are covered: CCNode, CCScene, CCLayer, CCSprite, CCLabel, CCMenu, CCMenuItem* as well as the Director, Transitions and Actions. Besides the code samples and how-to I’ve added numerous caveats, common mistakes, best practices and other nodes which are so very much needed to make any documentation complete.
For example, how Layers are best used for grouping other nodes together and of course how to enable touch and accelerometer input by adding the required functions which aren’t mentioned in the API reference since they are part of the iPhone SDK API. There’s also some weird recommendation floating around not to use too many Layers because they’re slow. I can’t find the source but what I did find was that this is only true if the Layers enable touch or accelerometer input, because that’s what costs a lot of performance. So what you don’t want to have is several layers accepting input, otherwise use as many Layers as you need - which shouldn’t be many anyway. And if you do need multiple Layers accepting input, why not just use one master Layer (possibly using a Targeted Touch handler) which forwards the input events appropriately to the other Layers?
Chapter 2 - Getting Started
This chapter starts with the usual prerequisites. Download and install iPhone SDK and cocos2d. Installing cocos2d Templates. Creating the first project from a cocos2d project template.
From what I already wrote I estimate that will be about one third of the chapter. I think what would be most interesting in this chapter is to talk about general code structure of cocos2d projects. The basic elements like Scenes, Layers and Nodes. How to transition from one screen to another, to see that we’re actually doing something cool with little effort. For that I think the scheduled selectors should also be introduced to time transitions, and one screen might be a Layer which is waiting for touch input to advance to the next screen.
It might also be a good place to discuss cocos2d memory management, like static autorelease initializers, and making sure dealloc gets called when you switch scenes - otherwise you’re obviously having a memory leak.
The goal is to get the reader into a position where he feels comfortable laying out a screen structure in cocos2d. He knows how to initialize objects and how to add and remove them from the scene. The foundation of working with cocos2d if you so will.
What do you think should be in Chapter 2?
Let me know if you think I’m missing anything important. If you don’t have any suggestions then just think about what you would expect from the chapter by reading this description, that might give you some thoughts.
Also I would welcome any tips and the common pitfalls first-time cocos2d developers might trap themselves into. Expert tips are also welcome, those little nasty things or habits which could bite you later on if you don’t consider them from the beginning.
I’m looking forward to your feedback! The earlier the better. Chapter 2 will be submitted next Friday, July 9th.
What’s planned for the Chapter after this one
Just to put Chapter 2 in context, for Chapter 3 I’m planning to talk about essential cocos2d classes and processes. Sprites, Labels, Menus, Actions, etc. It’ll show you how to work with them using small code snippets. The chapter will probably have a “reference” character with various code samples, so that experienced users feel comfortable skipping ahead while beginners still find it easy and encouraging to pick up the details.
