Well, that’s that. Enjoy your holidays! 
I’ve also released OpenGW Preview 1 to KoboldTouch customers. Then visit the members area to download it. Visit the OpenGW website and wiki to learn more.
In case you feel like checking it out just sign up to any of the KoboldTouch subscription plans. The KoboldTouch subscription price will not change for you if you stay signed up. Once we release OpenGW (it will replace KoboldTouch) the price will go up for new customers.
The OpenGW framework itself is fully functional and well tested. It comes with a basic code-based example and a complex Platformer example game built with the help of Tiled and Lua.
What isn’t so good yet is the way projects are set up (expected to change before release) and to start a new project you’ll have to copy an existing project and start modifying that. OpenGW is not currently meant to be added to a custom project - unless you can fight your way through some project setup steps. These rough edges will be polished next year.
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 »
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.
