Q&A With Author of Official Cocos2D Documentation: Cocos2D vs. SpriteKit & More
How does Cocos2D vs Apple’s Sprite Kit compare? What about Cocos2Dx vs C++? What are the architectural differences in a iOS game app vs. a regular iPhone app? How do you build a 2D top-down view game? How do you form a great iOS game development team? Benjamin Encz, author of the Cocos2D and SpriteBuilder documentation, answers these questions when he sat down with us for a Codementor Office Hours.
Cocos2D vs. Sprite Kit
These two game engines are actually pretty similar because Sprite Kit took a lot of established concepts from the Cocos2D. I think the biggest difference for the moment is Cocos2D. Around for 5 years on iPhone, and it updates really frequently now. So a portable the company I mentioned earlier has a full-time team on there that are pushing out new releases in every 2 or 3 months. The speed at which Cocos2D is moving is a little bit faster.
On the other hand, one of the advantages of Sprite Kit is that it integrates a little better with Apple’s official tools. For example, you can use Sprite Kit in playgrounds, and there are some feedback tools in Sprite Kit that are unavailable for Cocos2D. For me the moment, the Cocos2D is more mature, it’s open source, and it’s more responsive to the community feedback. Sprite Kit is just the official “Apple way” of doing things. However, they are actually pretty similar. If you pick up one of the two, it’s pretty easy to switch and use the other framework as they’re very similar.
Cocos2Dx vs. C++
Cocos2Dx is very similar to Cocos2D at some point of time. It’s written in C++, which means from the ground-up it’s built for cross-platform development. So you can have same code base for your iOS game and also use it for Android. In my personal experiences, C++ in the beginning is a lot harder to pick up. The language is a little bit older and has a lot of memory management things going on that are not easy for beginners to use correctly.There is also not enough of type safety and there are a bunch of things in C++ that are pretty hard to pick up.
I feel that Cocos2D’s Swift API are a little bit better at this point. Beginning more or less a year ago, Cocos2D-Swift and Cocos2Dxhave diverged a little more. For my personal taste, I prefer the Cocos2D-Swift API when I compare the two. It seems that they have cleaned up a little more. As I mentioned before, you can also use Cocos2D-Swift to cross-compile Objective-C or Swift games to Android, so the whole platform development reasoning is not necessary relevant in picking Cocos2Dx. However, I also have more experience with Cocos2D-Swift so I’m more biased towards it.
Differences Between Game App vs Regular App
One of the biggest architectural differences between a game app and a regular app is that in a game app, you’d mostly have all the game logic in one place. You’d typically have gameplay class with core game mechanics with a few hundred lines of code, and the core business logic of the game is pretty simple.
In a regular iOS application, you will have a lot of different views in your app, and each one of them you will be able to modify the state of every application. For example, in a simple notes app, there are different screens you can use to modify notes, and there are different screens that you can add notes. There will also be some component that will allow you to synchronize things with internet, so your logic would be a little more spread out. If you change something in a part of the application, you’d have to think about how the change will reflect it in different part of the application. You have to think about the information flow for a lot more.
In games, it’s more about finding ways to reuse code to create different types of the gameplay, and you have your gameplay code mostly isolated and not talking to other parts of the game. This is probably the biggest differences in terms of architecture.
Tips on Building a Top-Down 2D Game
Cocos2D is a pure 2D engine, so you’d have 1~2 perspectives for the game. From the beginning, you’d have to stick that, so you don’t have to think about how to arrange these 2D elements on the screen to make it looks like you’re from a 3D role from a certain perspective. Common examples include old games such as Rollercoaster, Tycoon, or the Age of Empires. They are actually 2D games, but they have a 3D look since their 2D components have been arranged in some sort of perspective.
Cocos2D can also easily build a top-to-down game, but you wouldn’t use gravity because it wouldn’t work. However, you can use a physics engine to apply different types of forces. For example, when I developed a pong game, I had physics integrated with the game. So, the ball bounces from the wall and you will look at the playfield from the top.However, I deactivated the gravity because it doesn’t make sense when you looking at the table where gravity applies to any of these directions.
In conclusion, it’s all up to you. So, depending on the perspective of the game, you will have to come up with code and assets that make the game look real,and there is no limitation on the game engine and no assumptions from the game engine’s side.
How to Form an iOS game development team
I have many different experiences so far on working in a team to develop games. For example, in last year, I went to a game jam, where we had two developers in our team and two designers. From the business perspective, it is really important to have a good-looking game and it is really important to get a dedicated designer under the game so they can create great art.
If you have something like a level-based game, I’d recommend getting someone on the team who just takes care of building the levels and testing the levels. I will probably let one developer implement the core mechanics in the code and let one designer make the game polished. Then I will have one person actually creating the game content, which means the person will be creating a ton of levels, playtesting those levels, and getting the feel of each level right.
Similarly, if you have a quiz game, then you’d probably want to have one person working on the content (e.g. questions, etc.) In most cases, I think it is good enough to have one developer working on the core gameplay. Some nice advantages from working with two people are just classic things, such as having people who can do code review so that you can avoid introducing poorly structured code.
So, an ideal team will have somewhere between one or two developers,one content creator, and one designer
Other Posts in this Series:
- 5 Best Practices for Mobile Game Development
- Swift vs. Objective-C: What Should Beginners Learn?
- Handling Different Screen Sizes in Mobile App Development
About Benjamin Encz
