The idea for this post really started with this poll:
I’ll present the results further down. Not wanting to spoil it before you made your choice.
This poll was just a quick test for a free web poll service. Well that and being curious how the major 3 Objective-C render engines compared against each other.
Since I added a “Other” choice and some users took it, I started to wonder what the “Other” choices might be.
I mean besides cocos2d-iphone, Sprite Kit, Sparrow and OpenGL ES, what choices could there really be? Have I perhaps not noticed the next big thing in Objective-C render engines?
Spoiler: I didn’t.
The Poll Results (as of Nov 28th 2013)
iOS 7 and thus Sprite Kit has been available for just over 2 months.
My expectation was that being so new and despite coming from Apple and developers usually slow to change their preferences, cocos2d-iphone would likely come out on top. At best it would have a head-to-head with Sprite Kit.
The actual result really surprised me: Continue reading »
Continue reading »
Don’t multiply velocity/position changes with delta time! End of story.
Okay, not quite. There’s a rationale that goes with it. And there are situations where applying delta time is important, if not required – but probably not in the way you’ve been taught by tutorials and fellow developers.
This is important stuff because applying delta time wrongly makes for a bad game experience.
What is this delta time thing anyway?
If you integrate velocity to a node’s position every frame, you have the option to multiply that velocity with the delta time passed in the update: method. Delta time is simply the time difference between the previous and the current frame.
Actually that is not entirely accurate – delta time is the time difference between the last and current execution of the update: method. This usually occurs every frame, but doesn’t have to be. On a scheduled selector that runs every second, the delta time is – tadaa – one second.
Okay, not even that is accurate. On a scheduled selector that runs every second, delta time is at least one second. It could be slightly more. This can depend on the resolution of the timer and how well one second divides with the time allocated to render a frame, or (as you’ll see later) whether time delta was calculated with the same means as the screen refresh rate.
What does multiplying with delta time do?
The effect of (not) multiplying a node’s velocity with delta time is as follows, assuming that 60 fps is the maximum achievable framerate as on iOS:
- Don’t multiply with time delta: the node slows down as the framerate drops below 60 fps.
- Multiply with time delta: the node moves the same distance regardless of the framerate.
Multiplying with delta time is often referred to as “framerate independent” (updates, movement, gameplay, etc). In contrast not multiplying with time delta is often called “framerate dependent” (updates, movement, gameplay, etc).
Unfortunately, framerate independent updates are said to be “important” and often taught by fellow game developers without actually teaching the implications, drawbacks and situations where you don’t want to apply delta time. Here’s one key point to take away early:
Applying delta time only makes a difference when the framerate drops below 60 fps.
If your game always runs at 60 fps there’s absolutely no point to multiply with time delta. If time delta is only used to combat the effect of short-lasting framerate drops, possibly introduced by system events, you’re doing it wrong.
In this case, and most others too, you’re almost always better off not applying delta time on iOS. And if you do, there’s a whole set of things to consider, including the architecture of both the game and the engine.
Continue reading »
Continue reading »
How to write code that is relevant for both Cocos2D and Sprite Kit, and as an extension to that the Kobold (2D/Touch/Kit) projects?
Because for the past months I shifted my attention to Sprite Kit, in order to create Kobold Kit and an accompanying Starterkit. While it’s obvious that Sprite Kit has everyone’s attention, I don’t want to turn my back on cocos2d-iphone and KoboldTouch. So from that came the need to create as much code as possible in a portable way.
The result is OpenGW, the world’s first game world simulation engine available to the public (in Nov/Dec). This is the holy grail I’ve been unknowingly searching for the past couple years!
What is OpenGW?
OpenGW stands for Open Game World.
It is a data-driven, engine-agnostic, cross-platform game world simulation engine.
I’ve set up a stub page where you’ll find more info on OpenGW.
With yesterday’s release of iOS 7 and hence Sprite Kit, many cocos2d developers will face this question sooner or later: switch to Sprite Kit or Kobold Kit or stick with cocos2d-iphone or perhaps move on to cocos2d-x?
I’ll give you some guidance and things to consider …
Sprite Kit / Kobold Kit
Sprite Kit made quite the splash. There are new tutorials coming out by the minute. Two books will be available within days after release. Several high profile tutorial & starterkit authors have jumped on the bandwagon. Tool developers are hard at work adding Sprite Kit support. Instructors are already offering new mobile game development courses based on Sprite Kit. Heck I even started a new game engine based on Sprite Kit: Kobold Kit.
With almost everyone jumping ship, it seems a safe bet to jump ship, too. You’re guaranteed to get excellent documentation from Apple, plus a stability of the framework until at least iOS 7.1 and even then Apple is known to carry on supporting deprecated methods for several versions. It’s easy to learn, and once learned you won’t be thrown off guard by new releases. And the developer community will soon surpass that of cocos2d-iphone. Continue reading »
Continue reading »
With the release of iOS 7 (ETA: Tuesday, Sept. 10th):
Kobold Kit will be available as open source under the MIT License!
We spent a lot of thoughts on how we like to run an open source project. And also why. I’ll start with an executive summary with more (perhaps too many) details in the text.
The Idea: make the project as open and inviting as possible. Let contributors gain control over and take on responsibility for the project based on their contributions. Provide them with ways to promote their work on their own accord.
The Goal: build the Sprite Kit game engine with the help of many developers.
Kobold Kit is supposed to become the “patron project” under whose roof the most valuable Sprite Kit extensions are combined. Website, forum, wiki, blog and store are extended playgrounds shaped by community members. If you’re part of the project, we want you to proudly present and benefit from it.
In essence: we want to get out of the way as much as possible and enable anyone to find their place in the project. Guidance, not dictating, is our guideline.
For Kobold Kit (the Sprite Kit game engine) we’re working on Super Stick Spy, a 2D platformer game. Like so many others, we started out using the (Box2D) physics engine that’s so neatly integrated in Sprite Kit to get everything up and running quickly.
But we knew full well that for the final product, we’ll have to scrap the physics engine altogether and follow best practices when it comes to platformer-programming.
Now with the demo version nearing completion (see video) I can tell you in full detail why you don’t want to use a physics engine for a 2D platformer!
Moving Platform Hell
A moving platform with physics needs to be a dynamic body. Don’t even try moving static bodies, at least in Box2D that will end up in jumpy movement of the body. Though kinematic bodies work better (if available).
The player or other game characters standing on a moving physics body will have the platform slide underneath their feet. The characters won’t magically move along with the platform! And there is no feature in the physics engine that lets you set this up. You have to program it to synchronize character movement with the platform they’re currently standing on, and end the synchronization as soon as a character lifts its feet up from the platform.
Which can be a problem for downward-moving platforms as the player loses contact with the platform every other frame, starts falling, and lands right back on the platform. To put it in Homer’s words: “Doh, doh, doh, doh, doh, doh, doh …”. So you need to make the character stick to the platform, yet allow him to fall off of the ledges and jump, and possibly also allow him to be forced off the ground by normal collision events (projectile impact, platform moving through a tiny crevice). Continue reading »
Continue reading »
This post will be unusually short because I’m going on vacation tomorrow (July 12th) and won’t be back before July 22nd.
I’ll use this post for a quick progress report on Kobold Kit.
Kobold Kit Progress
Kobold Kit is going more and more in a rapid-development direction, with fewer interruptions. Here’s the corresponding video to that:
It is also heavily gearing towards tilemap rendering and physics integration. We’re making a game with Kobold Kit which will become a Platformer Starterkit as well as a published game. It will also be featured in an upcoming book.
When I say we, I mean that a former colleague of mine (Marcus) has teamed up with me. He’s a game designer and Tiled user, so I get lots of good feedback on how to improve and move things in the right direction. You’ll see more of his work when we’re both back from our vacations in August.
The fact that I haven’t posted on the koboldkit.com blog for a week only means we were very busy making lots of smaller improvements to the platformer game we’re developing. I’ll be away for 1 week so I wanted to ensure that Marcus can get some work done while I’m away.
This is one other plus about this partnership: Kobold Kit will decouple as many tasks as possible from programming work and offload them to editing tools, configuration files and scripting. These improvements are beneficial to the programmers as well because they enable or speed up rapid prototyping.
And if you do happen to work with designers, your attention will not be required as often. If you haven’t done so in the past, you probably can’t appreciate what that means. But try anyway.
Since Kobold Kit is so heavily integrated with Tiled, we decided to sponsor Thorbjørn Lindeijer and Tiled beginning August 1st. I also sent him my old Mac mini so he can setup daily builds for OS X.
We have also secured several sponsors ourselves, and we’re very excited about one in particular, but we don’t want to spoil the fun with a premature announcement. All in due time.
PS: In case you haven’t built the latest Tiled source code: you’re seriously missing out on the reworked properties pane (no longer a modal dialog). Here’s a OS X build of the Tiled source code (June 29th) if you want to give it a try. Thanks to Andreas Löw who built it for me.
I have received very little support or feature requests in the past weeks. I take this as a sign of maturity. At this point development on KoboldTouch is on hold until some time after the release of Sprite Kit (iOS 7). I will tend to serious bugs of course, and already made a compatibility fix for iOS 7 and Xcode 5.
I can’t say whether KoboldTouch will continue to incorporate cocos2d v3 or not. This depends on too many hard to predict variables:
Will cocos2d-iphone v3 be competitive compared to Sprite Kit and still used by a considerable number of developers? Will users be interested enough in an MVC framework with extras? Will cocos2d v3 perhaps take the chance and improve in ways that make KoboldTouch much less attractive? And how much or for how long is development time best spent (exclusively) on Kobold Kit, how much danger is there in splitting efforts?
I take a “wait and see” approach. The hope I have is that cocos2d will trim down its own API and copy the Sprite Kit API and behavior to become a natural, seamless “upgrade path” for Sprite Kit developers (drop-in replacement).
It won’t work any other way, or would you willingly switch from, say, MapKit to an open source alternative (route-me)? Only if you absolutely have to, am I right? Though the only “must have” feature that cocos2d will always offer over Sprite Kit requires an advanced skill set to exploit it in the first place.
But all of that is speculative at this point. If you’re a KoboldTouch developer or want to become one, you’ll get the support as always and you’ll be able to publish your game two years from now. That’s guaranteed.
As KoboldTouch user you’re also going to be Kobold Kit customers, I won’t charge KoboldTouch users twice. And if you want early access to Kobold Kit, sign up to Kobold Touch and check the forum. Since I can only unlock you manually you’ll have to wait until I’m back though.
Signing up to KoboldTouch now makes perfect sense because you’ll pay forever less than Kobold Kit customers, and it helps our efforts in more ways than just financially.
See you in 10 days!
But ouch! This solution is not just hugely wasteful and unnecessarily slows down the physics collision code, it also introduces the well known problem of characters getting stuck even on flat surfaces.
This is in particular a problem for Box2D because its collision mechanic doesn’t work well with flat surfaces subdivided into smaller segments (rectangle shapes in this case).
A workable but still very awkward solution to work around this behavior is to create characters with bevelled edges at the character shape’s bottom at the risk of bopping characters as they walk about the map.
Lupines in the Moore Neighborhood
A good solution to generate physics collisions is to implement the Moore Neighborhood algorithm to generate chain shapes which are more suitable for tilemap collisions. The downside is that adding or removing individual blocking tiles at runtime requires updating the shapes – this is not implemented in this project.
Every flat surface, no matter how many tiles form the surface, will then consist of only one straight collision segment. Here’s a quick demo video of the project discussed in this post that shows the algorithm at work and the resulting “game”: