A preview version of cocos2d-iphone v3 has been available for a couple days now. I thought I’ll take a closer look and summarize what’s been done, what’s working and what isn’t, what’s new and what’s old but revamped.
Installation
The installer script has been revamped. It has a different name (install.sh) and different parameters (-force instead of -f).
The first thing I noticed is that the installer is downloading Chipmunk2D. Made me wonder why, so I double-checked to confirm: Chipmunk isn’t included in the archive. This means no offline installation.
I’ll explain later why Chipmunk isn’t included.
Project & File Templates
In the preview there’s only one project template. It doesn’t demo any physics features, it’s your typical “Hello World” example with buttons.
There seems to be an issue with the template where any attempt to save it to a custom location caused Xcode to crash. In fact every time the “Save File” sheet came up and I didn’t click on “Create” right away, Xcode would crash. That’s just one of the reasons why it’s still a preview.
The CCNode File Template isn’t worth mentioning at this point, it creates an empty Objective-C class and is barely different from the regular Objective-C class template at this time.
Hello World v3
Continue reading »
This is my coming out: I’m not a test-driven developer. I have stopped trying to force it onto myself.
Yet I do test.
TDD never seemed to work very well for me personally. As a consequence the process never took hold in my habits of writing code, it did not prove itself as the uber-strategy to advancing to the next engineering level.
It took me a while to free myself of thinking that by not following TDD, that I am somehow an undergraduate software engineer. Or worse. As is sometimes implied by more religiously test-driven developers.
Eventually I realized that test-driven development is a thing that you’re born to love, or you aren’t. A process that works better or worse depending on personal habits, circumstances and environment - in that sense I now regard test-driven development along other relatively subjective and debated processes, like pair programming (XP).
Moreover, like pair programming, the minimum requirement is two programmers. If there are only two programmers in your team, it’s a freakin’ waste of time to do pair-programming round the clock. In the same light my experience with TDD is specifically in environments where I was/am the sole programmer, perhaps only occasionally sharing code development with one or two other developers at most.
This is where TDD’s proposed benefits lose a lot of their weight, while its drawbacks are more pronounced, and a more “agile” process works just as well for sole developers and tiny teams.
TDD is a personal preference
Unit testing is a tool used in test-driven development. If you don’t “test first” and then write the class’ code and then refactor, you aren’t doing test-driven development, you are testing. On the other hand, you can do just that without following the formal TDD process.
In test-driven development, the tests are written first. They are made to fail because the class they test hasn’t been written yet, it’s only a stub. Therefore all tests initially fail. Then you write code. Then you test and verify. Then you refactor. Then you test and verify again.
TDD is a fairly rigorous, rinse and repeat kind of process. It formalizes the process of writing code. It sometimes feels great, other times it feels terribly constrictive. Unfortunately TDD is not someting that you can do on and off, and still expect it to be very effective. Which means you have to be a rigorously test-driven developer. That might also explain why some developers are quite religious about TDD.
I wager that TDD is significantly harder to subscribe to for certain developer archetypes than others. It makes little sense to force it on developers. A lot of the process has to do with personal preference and a certain enlightened feeling that comes when applying and succeeding with it. Likewise, others may still be in shock after weeks and may forever struggle to adapt.
What is often forgotten when adapting TDD is to actually measure key metrics for the team and individual programmer, both before and after - for some teams/individuals the benefits may be tremendous, for others it may reveal fewer defects but also slower development. Then what remains is a tradeoff: do you prefer fewer defects or faster development? This is a valid question in any product development.
It should also be considered that it takes significantly greater effort for an experienced software engineer to change his or her personal process of developing code than it is for a student. Talk about teaching old dogs new tricks. The students are also more likely to find great rewards in test-driven development as TDD encourages them to learn and experience many software engineering principles.
Undeniably, test-driven development has benefits even for experienced developers. But since I’m talking about TDD specifically for sole developers and fairly small projects, then TDD is simply much less effective in my experience. A more informal process works just as well.
TDD benefits are generally overrated
There are benefits and drawbacks to TDD. Most remain inconclusive and subjective, only few have been measured in some very narrow-focused case studies (here and here). Continue reading »
I got a lot of questions in the past why I’m not contributing my work to the cocos2d-iphone project.
One of the obvious reasons being that what I did is simply too radical technically and I don’t want to compromise. Another reason being a fundamental difference in attitude towards developing and managing open and closed source projects.
These questions made me wonder - in particular because there was often a notion associated with these questions: because I do so much with cocos2d-iphone I should somehow be obliged to contribute back to it. Weird, right? I am contributing a lot already, just not code to the repository.
So if I don’t contribute (code), why don’t you? Or generally speaking, why aren’t we all contributing more (code) to open source projects?
I have been using open source software for as long as I can remember doing programming work. Yet I’ve probably contributed no more than a few dozen lines to all projects together. And realizing this it’s easy to see that this is the case for 99.9% of the developers out there.
So why aren’t we contributing more to open source projects? What is stopping us? I’ll give you some probable causes and ideas how to improve it for your own open source project. Continue reading »
I like to take a moment and explain what the development process of KoboldTouch will be, and how you will influence the direction of KoboldTouch. But first, let’s have a look what I have planned for the initial version:
UPDATE: KoboldTouch is now available!
First Goal: KoboldTouch equals Cocos2D
To be completed in November, the main goal is to allow users to use the MVC framework of KoboldTouch with all features of Cocos2D, minus a few exceptions (odd features like CCMotionStreak).
You should be able to write Cocos2D apps with Cocos2D features entirely within the KoboldTouch framework. You’ll experience the KoboldTouch API design goal “feels like Cocoa”.
The first version’s features will be:
- Controller/Model Framework wrapping Cocos2D views
- View Controllers for “view” nodes, minus exceptions (see below)
- Scene Transitions
- Scheduled updates (Step methods in KT)
- Touch & Accelerometer input controllers
- Mouse & Keyboard input controllers
- Simple Audio Controller
- Simple Model Classes
- Archiving & Unarchiving Model Classes
- Basic “Hello World++” Example Project
This first version will be KoboldTouch v6.0. Continue reading »
So, you’ve heard about Objective-C automatic reference counting (ARC). And you’ve read about it here and there and every where. But you’re not using it.
Guess what? You’re not alone. There are developers out there who refuse to use ARC, who delay using it, who believe they just can’t use it or expressly decided against using ARC for the time being. They all have their reasons.
Most of them are wrong.
Here’s a summary of reasons I’ve heard (repeatedly) in the past months from developers who aren’t using ARC, or have tried it but gave up using it. And I’ll tell you why these rationalizations are wrong, or at least over-inflated. Continue reading »
LearnCocosTV is sort of like a personal sprint review presentation but in video form.
I think that just writing about what I’ve done recently would be rather dull, whereas a bi-weekly Show & Tell video would not only be more interesting, it is also much more encouraging for me to create something cool to show in the first place!
Each episode will update you about what I’ve done for or with Cocos2D, Kobold2D and iOS/OSX development in general, what I’ve learned in the process and what the end results are. Here’s episode one, I hope you’ll enjoy it:
LearnCocosTV - Episode 1: How I maed your Kobold
• Kobold2D 1.0 Released
• Kobold2D source code published on github
• First Kobold2D games published on App Store
• Kobold2D Server moved
• iDevBlogADay: How to use CCRenderTexture…
And no, I’m most certainly not going to run out of TV Show titles to vilify. 😀
PS: in case you’re wondering, the video was created with ScreenFlow 3.0.
I did not create the following products. But I help sell them through ads and affiliate links because they’re high quality and highly recommended. I get a commission for each sale made through these links, which in turn helps me spend more time on this website and on Kobold2D.
Paralaxer Platformer Game KitParalaxer runs on iOS, Android, Windows, & Mac using the same C++ game code. Thanks to the ultra-awesome, open-source Cocos2D-X game engine, Paralaxer is a cross-platform platformer. |
The iPhone RPG Engine
Rapidly create your own RPG or action-adventure game with this complete starter kit. Includes an ebook, game source code and a royalty-free art package. |
|
Commander Cool Game Kit
This starter kit includes the complete source code of “Commander Cool” for iPhone / iPad / Mac build with Cocos2d & Box2d, extensive code documentation and video documentation (accessible online or offline) covering every beginning step to modifying the app for yourself. |
Angry Ninjas Starter Kit
Ride the wave of success that sling shot games are seeing in the App Store and create your own popular game. All thats required is a bit of time on your part to build some fantastic levels and add your own artistic twist. We’ve done the hard part. Now you get to do the fun part! |
|
Visit the Ray Wenderlich Store! |
||
|
Also check out Sprite Kit by Tutorials! |
 The Starter Kit Bundle: Full Cocos2D source code and tutorials for creating a side-scrolling space shooter game, a platformer game and a beat ’em up game for iPhone and iPad! |
|
|
Ray Wenderlich and his team provide awesome iOS Tutorials and excellent Starter Kit source code. |
||
TexturePackerCreate sprite sheets and optimize images for your Cocos2D, Kobold2D, Corona and other game engine projects. |
PhysicsEditorEdit collision shapes for Box2D and Chipmunk based physics games. Supports Cocos2D, Kobold2D, Corona, and other game engines. |
|
I have no doubt that automatic reference counting (ARC) is the next big leap forward for Objective-C since the introduction of Objective-C 2.0. ARC allows you to put the burden of memory management on the (Apple LLVM 3.0) compiler, and never think about retain, release and autorelease ever again.
Since many user’s first experiences with ARC will be trying to convert an existing app, they will learn the hard way that converting existing code to ARC is not a fire & forget operation. And since this is the Internet, there’s also a lot of assumptions, false statements and other myths revolving around ARC going around.
So here’s just about everything you need to know about ARC, and some ARC-mythbusting too.
- Development Requirements for ARC apps
- Minimum Deployment Targets for ARC apps
- Required Deployment Targets with zeroing weak references
- How to enable ARC in your project
- Compile errors after switching to LLVM 3.0
- Getting third party libraries to build with ARC
- Converting an existing app to ARC
- “Cannot Convert to Objective-C ARC”
- Fixing pointer types in C structs
- Fixing C/C++ pointer transfers with bridged casts
- Fixing NSAutoreleasePool with @autoreleasepool
- Methods you can’t call (or override) anymore
- You can still override -(void) dealloc {}
- Property naming restriction
- New Property keywords: strong and weak
- ARC forbids synthesizing a readonly property without ownership qualifier
- For experts: detecting at compile-time if ARC is enabled
- For experts: allow use of ARC keywords with ARC disabled
- Myth: ARC has not been proven reliable
- Myth: ARC takes away control over Memory Management
- ARC Reference Documentation
