Book Image

Mastering Cocos2d Game Development

By : Alex Ogorek
Book Image

Mastering Cocos2d Game Development

By: Alex Ogorek

Overview of this book

Table of Contents (15 chapters)
Mastering Cocos2d Game Development
About the Author
About the Reviewers

Preparing the mindset

First, we'll discuss how to structure your project from start to finish, and why you should do that instead of just jumping right in. We're going to discuss some theory and ask you questions to help you determine what exactly your project will need before even a line of code is written.

Before you start planning, you need to ask questions about key features your game needs, as they will require additional support and development. For example, is there a physics engine involved? Are you going to implement Game Center or In-App Purchases or possibly connect to a database to store the user's information? How complex are the mechanics? Start thinking of the answers to these and similar questions, as knowing the answers will help you move faster and still remain efficient.

The physics engine

Although this is not something that most people will know off the top of their head when they first start planning their project, it's important to know. Luckily, with Cocos2d, there's a physics engine built into the code for you, which is nice because you don't have to go out of your way to implement one.

If you find your project does need a physics engine (or would be much more 'realistic' with it), you can refer to Chapter 5, Creating Cool Content, later on in this book to understand how to implement it, as well as example code to use.

If you're unsure of whether you should use a physics engine or not, here are a few examples of games that use Box2D, one of the built-in physics engines with Cocos2d. Take a look at the physics in Angry Birds by Rovio:

In the preceding screenshot, each bird and each pig is a circle-shaped physics object, the ground is a rectangle, and all the obstacles on the right-hand side (except the pigs) are rectangles. When the bird gets flung from the left side to the right side, gravity starts acting on the bird and begins pulling it down. Once collisions occur, it pushes the objects around and does some fancy "damage" calculations based on the velocity of the incoming and colliding object.

The following screenshot is of the physics in Crescent Ridge Mini Golf by KeitGames:

In the preceding screenshot, the ball is a circle-shaped physics object, and each wall has a set of vertices that act as the boundaries through which the ball cannot pass. There is no gravity in play here, or else the ball would be constantly falling to the bottom of the screen. If the ball bounces on a wall, the physics engine knows exactly what angle the ball will turn by, and by what velocity it will go backwards. Being able to determine the angle of reflection of the golf ball was the main reason a physics engine was used to create a simple mini golf game.

If you're still unsure, then answering "yes" to any of the following questions means you should consider using a physics engine. If your answer to any of the following questions is "yes," then refer to Chapter 3, Focusing on Physics, to learn how to implement a physics engine. If your answer to all of these questions is "no," then I suggest holding off for now because your game probably doesn't need an engine, and instead, it can be coded in a way that gives the impression of physics but doesn't actually use a physics engine:

  • Do you need noncircular or nonrectangular objects to collide?

  • Do objects need to bounce off of each other or push other objects?

  • Does your game make use of real-time gravity?

If you're interested in making use of any liquid physics or using soft bodies in your game, feel free to check out LiquidFun. However, this book will not cover how to implement or use that engine.

In-App Purchases

In-App Purchases (IAPs) are a feature that are a result of design decisions, possibly to make the game cheaper and/or include expansions or extra content in the game. There are a lot of ways you can utilize IAPs, but forcing them into your game instead of designing them as an integral part of the experience could cause your players to either not utilize the IAPs you took so much time to implement, or just stop playing the game altogether.

The thing about IAPs is that Apple requires your project's provisioning profile to have the IAPs permission added—that's the easy part. The hard part is getting them included in your code. Here are some examples of In-App Purchases in various games. The following screenshot is of the shop in Clash of Clans by Supercell:

In the preceding screenshot, you see the various IAPs available in Clash of Clans. You can see that they have a tiered structure such that as the player spends more money in one go, they get more gems per dollar spent. The following screenshot is of the bank in Bina Blocks by KeitGames:

What you just saw is a screenshot of the bank in Bina Blocks. You can see a similar tier of pricing as was in Clash of Clans.

Although IAP implementation is not covered in this book, it can still be a significant constituent of your game. If you wish to continue learning how to implement your own IAPs, you can read about them from any of these sources:

Making use of analytics

Analytics packages are a great tool that any developer can make use of. If you want to know what level your users are getting stuck at the most, you can track how many times each level was beaten to see where the drop-off happens. Or maybe, you want to track how people are using the new characters you just added. In Chapter 7, Reaching Our Destination, you'll learn how to implement Flurry Analytics, which uses a simple, event-driven system used to track when certain methods get called. Essentially, you can track anything from a button press and screen loading to the time a user spent on a problem. All of this data is sent to Flurry's server and compiled into easy-to-read charts and graphs.

Although your users won't notice any difference, it'll definitely make your game better in the long run, as you can see what is happening when your players interact with your game. Thus, you can submit better updates as time goes on.

Complex mechanics and special effects

The term "complex mechanics" can be a bit vague or general at times. However, it can be anything from a really smooth transition between your game's scenes to a unique control system for the way the player plays the game. If you feel that your game needs these complex mechanics to become successful, them make sure you do it right. If you're only planning to add extra bells and whistles because you feel that you have to, and not because it's part of making your game better, then thinking of this beforehand can help structure your project plan in a way that allows the addition of extra (or bonus) features at the end of development. This is better than attempting to add things halfway through and delaying necessary features if you can't figure out how to code them right away.

There are some games that are very special because of their unique gameplay mechanics, in combination with making use of the touch screen (which we will cover in detail in Chapter 4, Sounding Off). For example, if you look at Smash Hit, Blek, Tiny Wings, or Threes!, you'll see that they don't quite fit into any traditional genre.

Note that if you're relatively new to game design (especially when it comes to mobile design), it might not be entirely in your best interest to try something completely new or unique. Instead, try at least replicating mechanics that already exist, and possibly tweaking them slightly to better fit the game that you're trying to make. The following screenshot is of Smash Hit:

The next screenshot is of Blek:

The following screenshot is of Tiny Wings:

This screenshot is of Threes!:

These are games that thrive on their complex mechanics and special effects. They were extremely well-planned and properly designed. If you're only looking for special effects (for example, particle explosions or faces on the Threes! cards), then Chapter 7, Reaching Our Destination, is where you should look. That chapter goes into detail of how to polish your game and increase its likeability factor. But for now, just know that if you plan to do something unique, creative, or never done before as an integral part of your design, you should plan accordingly.

If you are adding mechanics just because you think it would be cool to have it and it isn't necessary for the game's progression, then plan it at the end. There's nothing worse than delaying your game's launch date because of a feature that isn't really that important in the first place.