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.
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