The cool thing about KoboldTouch autoscaling is that it works transparently. Your nodes will be positioned relative to the design resolution, for example 480×320. The nodes will continue to use the same position on any device! So you just develop these nodes’ positions and their movement as if they were always on a 480×320 device. It’s that simple.
It also works for movement of any kind, be it CCMove* actions or manually updating the position property every frame. Moving nodes continue to move seemlessly even when you rotate the device.
The content size is not scaled for good reason: it wouldn’t look good. Instead depending on the target device cocos2d’s file suffixes kick in (-hd/-ipad/-ipadhd) as usual, provided that you’ve added these assets.
If you’re using move actions as in the demo, you’ll notice that nodes may pick up speed or slow down after rotation due to the fact that cocos2d’s actions use a duration from which they derive movement speed, as opposed to using an actual “points per frame” speed value which is more common in games (and why I recommend not to use move actions for game world objects).
Please take the KoboldTouch survey. I highly appreciate your feedback, thank you!
Most wanted feature?
Autoscaling Demo Gallery
Retina iPhone, Widescreen
Mac OS X, 16:9 Aspect Ratio
Like this feature?
Then check out KoboldTouch.
I know I promised a numbers article on KoboldTouch for today. I decided to postpone it to February because upon closer inspection the current stats aren’t too meaningful yet. Most are projections since it’s only been two months. This also leaves me time to run a survey about KoboldTouch.
One last thing
I already promised KoboldTouch members to write a small example game around new features and document it. The next one will make use of the new Tilemap renderer.
However I think I can do one better: developing an actual, publishable game! The game will be available to KoboldTouch members as a template from day one and over time evolve into a starterkit and a demonstration of KoboldTouch features and code. And most importantly: it’s all about eating my own dogfood.
I realized that building an engine requires a goal that’s more than just features on a checklist. Feedback from members has been invaluable, but there’s nothing more valuable than to actually use the tool (or engine) you’re working on. If the goal is to make a game, a lot more of those pesky details and usability issues in the engine will surface, allowing me to fix or improve KoboldTouch.
The game will pick up the railroad game idea, combine it with the railtrack linedrawing demo (see above) I wrote several months ago, add physics and a randomly generated tilemap world – the rest will be a surprise. Even to us. I teamed up with a former colleague who will do the game design while I’ll focus on programming.
Hint: we both watched Unstoppable recently. So that may have been an influence.
|Follow @gaminghorror||Follow @kobold2d|