Throughout December, I will post about the foundation of Cocos2D-PureSwift, to hopefully generate some interest, and get as many as possible to support the KickStarter Project. First post will be about how Cocos2D-PureSwift will handle screen resolution.
Scenes and nodes will work as in any other version of Cocos2D. As those who have used -ObjC knows, layers were removed in V3, but they are going to be reintroduced. The inner workings of scenes will be slightly different. They will now be treated as normal node descendants added to the director, meaning that ex. transitions, can be run as simple actions. But that is for another post.
The big new thing will be layers.
A very big challenge in designing cross platform mobile software, is handling all the different resolutions. There has been a lot of ways to deal with this, but none of them has been really easy and flexible. PureSwift changes that.
The magic word is layer. Technically, a layer is any rectangular portion of the screen, visible or non visible. It is exclusively ment to control resolution. It can clip geometry, and you can have as many as you like.
Lets us make an example with a football game (that will be soccer for the overseas readers)
You start by creating a pitch. This will be a layer with the size 100 * 75, because we want to handle all elements on the pitch in metres. Do not worry about artwork or scaling at this point. This will all go into asset handling. For now just imagine we have a pitch this size. This is 4:3 matching an iPad, so game designer decides, that game will default match an iPad. But what on the rest of the devices?
The pitch can be matched to ex. a 16:9 device in many ways. As you will have to be able to see the entire pitch, the options would most likely be A and B. Keep in mind, that as anything in PureSwift is data-driven, you could easily add your own placement schemes.
Today you would go for option B, because A would stretch the pitch, and ex. make the ball into an american football. And here comes the new thing. A layer does not stretch or compress graphics, only coordinates. The ball would still be round in A. It would move slightly faster in vertical direction, but that is basically it. At first this is a bit of a mind boggling concept, but once you think a bit about it, it makes perfect sense.
So how would that look?
This is an example of a layer design on different devices, without changing a single of code, just using simple absolute position. While it looks a little bit like normalised positioning, it isn’t. For normalised positioning to work, you would have to run in different resolutions, which is exactly what you do not want, when building cross platform software.
For the “purists”, there are two things you might want to add to this.
You might want to scale the buttons differently, depending on the physical device size. Buttons might get too big on an iPad. This is handled in asset handling, which is for a different post.
Next, you might want to keep the three top left buttons spaced equally on any device. This is handled in layout and positioning. Maybe I should make that my next post.
If you think this sounds interesting, please consider supporting the KickStarter Project