5 Best Practices Beginner Mobile Game Developers Must Know

Entire Post Here

Introduction

For those who don’t know what Cocos2D is, it is the most popular game engine on iOS and was around before Sprite Kit (the official Apple Framework), and Sprite Kit also takes a lot of ideas from Cocos2D. What is great about Cocos2D is that it is open source, and with company called Portable it is also possible to write the game on iOS and then port it to Android.

A couple of great games were also have been made by Cocos2D, a great example being Badland, which won Apple’s design prize for games. It is definitely a very popular and well-maintained game engine.

Another tool that we’re using a lot is SpriteBuilder. If you used Unity before, it is very similar to Unity but it’s for 2D games where it allows you to create great game content, to create levels, and to do all that visually without writing code for the game content part. This means when you’re building games with SpriteBuilder or Cocos2D, you’ll get a nice separation between your content (e.g. levels, menus, etc.) and your core game mechanics.

Not all of the points here are iOS-specific, but one thing you should have realized when you started game development is that it’s pretty platform-agnostic. A lot of content also apply to PC games and web games.

#1 Don’t make assumptions about the screen size

When starting out with game development, a lot of people will use constants for the screen work. In the past, the only resolution for any screen size we had was 480 x 320 on the iPhone 4. That means people could make assumptions about the size of the screen, and you could code in constants and use them to position things on the screen.

After the iPhone 5 came out with a different screen size, all of these inexperienced developers’ games needed an entire redesign for the new screen sizes.

So, now with the current state of the platform, even for iOS where we don’t have that many different devices, we have enough different devices that you definitely can’t make assumptions about how big the screen size is. We should always place things relative to the screen size and not make hard code assumptions about the screen size.

let screenWidth = 320 
myButton.x = screenWidth - 50

We have constants for the screen width, and you calculate the position for an object on the screen based on that…this is usually a very bad practice. Instead, you have to think about what width to write while you basically correspond to the screen size like this:

// cocos2D example 
myButton.x = self.contentSize.width - 50

In Cocos2D, for example, that would be the content size property on the scene. So each scene has a content size property, and if you, for example, have a full scene and that content size property will be the full screen size.

But it’s also possible to have your scene smaller than the full screen. Either way, if you press the button relative to that scene, then you should calculate the position based on the content size.

That’s just a very simple example where you shouldn’t use constants for width and height. Calculate the things based on scenes or whatever is relevant to your specific example.

This is really important to keep in mind. That would save you a lot of time from redesigning your game for every different devices type (e.g. iPad, iphone6, iphone5, etc). The good news is that SpriteBuilder and Cocos2D have some good support for such relative layouts. This makes things pretty easy once you start thinking about how to implement a flexible design.

Beyond that very basic rule, there is another thing to think about and that’s basically I would like to divide the things I show on the screen into two categories. One for UI components, such as buttons or the HUD (Heads-up-Display) that shows current points in the game, and the other one for actual gameplay.

Entire Post Here