Cocos2d-x Cross Platform Development for iOS, Android, and Windows Phone 8
I started creating iPhone games with Cocos2d-iPhone in 2009. Google Play and the iPad did not yet exist and the iPhone 3GS had just came out.
After some research* into game engines, Cocos2d for iPhone** seemed awesome. I bought Ricardo Quesada’s sample source code for an iPhone game. The game was a frog on a string; the objective was to see how far the frog could be launched. Buying that sample game was a great investment. It really knocked down the barrier to learning how to build a game for a mobile device very quickly.
Cocos2d-x in the Year 2015
Fast-forward five years later, over 7 million downloads of my games and countless books read. I have learned a lot and making games for mobile devices is more fun than ever. The developer tools have evolved significantly; Cocos2d-x has gone from a project plan in 2010 with a large map of multi-device support goals to a really awesome and capable product.
I now create all new games on Cocos2d-x (and have since October 2013). There is some extra setup work to be done if you want to publish to multiple platforms. I initially started with iOS and Android and then later added Windows Phone 8. For me, the benefits of publishing at a minimum to the Apple App Store and to the Google Play Store far outweigh the costs to support both platforms.
Should You Publish on Multiple Platforms?
I read in blogs from time to time that it is best to focus on one platform (usually iOS) and then only expand after success is achieved on that platform. That makes sense when the cost to add an additional platform is significant and you want to first test how the game does on a single platform.
But with a tool like Cocos2d-x and the right strategy to manage development tool chains, game assets, and testing, the cost can be very minimal and the added revenue from launching to multiple platforms may be worth the extra effort.
At a minimum, I now publish to the Apple App Store and the Google Play Store. Even for games that are flops, the flop makes about twice as much money by adding Google Play in addition to iOS for the initial launch. A game making $25/day on iOS might make $18/day on Google Play; sometimes it will even make more on Google Play. Revenue from the Amazon App Store and the Windows Phone 8 Store is usually quite small relative to the Apple App store an Google Play Store. But some games that have bombed on the Apple App Store and the Google Play Store have done quite well on the Windows Phone 8 store, so I wouldn’t completely dismiss the Windows Phone 8 store.
I have published numerous games (122 as of October 2014) on the Apple App Store, Google Play, Amazon App Store, and Windows Phone Store. Some games do better on different stores, likely by chance since I do almost no marketing other than linking to my website with a more games button. About 50% of my revenue comes from the Apple App Store, 45% from Google Play, 4.75% from the Windows Phone Store and 0.25% from the Amazon App Store. There are many factors impacting how well a game does, so this does not mean that you will see the same statistics that I am citing above.
Primary Costs of Supporting Multiple Platforms
Publishing to multiple platforms (rather than only iOS) has more than offset my costs of doing so. This might not be the case for others, but it has been my experience.
The one-time costs to get started publishing to multiple platforms include:
- Initial setup discussed below, which was about 6 weeks of work.
- Buying a Nexus 7, Galaxy S3, Galaxy S3 mini, Kindle Fire HDX, a $100 Asus android tablet, a $69 generic Android tablet, a high-end Windows 8 phone, a low-end Windows 8 phone, and some iPhones and iPads. The intention is to get a good sample of devices that will be published to. Obviously this is not a comprehensive list, but it has been sufficient for my needs.
The ongoing costs include:
- Testing on a sample of each of the supported platforms (easier than you might think).
- Additional graphical assets if desired, but rarely more is needed than to design with the intention that background assets can be scaled and cropped easily to support various aspect ratios and screen sizes. Pay a designer to make one high-resolution set of assets and then scale down and crop as needed.
- Will eventually need to buy new devices to test on.
Note: There are tradeoffs as in any product development that can be taken to reduce cost. If you want to design and engineer perfection, then it will cost you more. If you are flexible, then you can drastically reduce the cost of making your game. This doesn’t mean you need to create crap to keep development costs down; but be honest with yourself about the value added by trying to improve an aspect of the game. I spent almost a year working full time on my first game before I released it. It was probably ready for release by the third month. The next 8+ months were spent on activities that added questionable value. From a business perspective, that was a foolish thing to do.
Initial setup, but worth the effort
The first challenge of publishing to multiple platforms is getting familiar with Eclipse and Visual Studio Express for Windows Phone. Xcode, Eclipse and Visual Studio in some regards are similar. If you have mastered one then your learning curve for the others will be drastically reduced. However, there are unique settings to each IDE that you will need to become familiar with. The best way to learn is to start using them and ask your friend google search as many questions as you can. Lynday.com also has some good courses.
EDIT: I now use Visual Studio 2013 Community Edition with Update 4 as of the release of Cocos2d-x 3.6. See this post for details why. Android Studio also now supports NDK, so hopefully soon I can drop Eclipse and start using Android Studio.
For supporting Windows Phone I bought Parallels and a license for Windows 8.1 Pro. The Pro version of Windows is required if you want to use the hyperviser in Parallels so that you can use the windows phone simulator in Visual Studio.
The second major hurdle to get past is to create a layer of abstraction between the C++ code and platform specific code where necessary. You might not need these same features in your game, but likely will want to add some things that are platform specific. I wanted to create a series of games that would all have Leaderboards, Achievements, Flurry Analytics and Advertising. For each platform I needed to create separate implementations that would leverage the following libraries.
iOS Objective-C Specific Libraries
- Game Center
Android Java Libraries
- Google Play Game Services
Windows Phone 8 XAML/C# Managed Libraries
- No leadearboards or achievements on WP8 were implemented
The abstraction is then a set of C++ class declarations (some would call these interfaces). One header file (.h) each for ads, analytics, leaderboards and achievements. Each platform gets a separate definition/implementation (.cpp) of the class to implement ads, analytics, leaderboard and achievements on each platform separately.
This was a one-time effort and I have not needed to mess with any of that (other than minor upgrades) and I now have a reusable template for iOS, Android, and WP8.
Now when I make a new game, all I have to do is create a copy of my template, update some basic configuration, and then write the new game in C++. While I develop a game, I regularly test it on the different platforms by running the game on each of the different devices. This helps to catch issues early and by the time I move to final testing most issues have already been resolved.
As far as the web portals for the different app stores, where a game is uploaded to be published, I found them to be intuitive and easy to use.
Objective-C to C++
If you currently use Objective-C or Swift with Cocos2d-iPhone**, then transitioning from Objective-C to C++ might require some additional research to get up to speed with C++.
I particularly liked Lynda’s course C++ Essential Training by Bill Weinman and the Kindle book Effective C++ Digital Collection: 140 Ways to Improve Your Programming by Scott Meyer.
* After some research into Torque, Unity, Sio2 and numerous other game engines and considering I was only developing for iPhone, the best solution for my needs at the time was Cocos2d for iPhone.
** Today, Cocos2d-swift (formally Cocos2d-iPhone) is still a vibrant game engine with an active community. It even is in the process of adding cross platform support for Android using SpriteBuilder.
Leave a comment below to let me know what you think and what you would like to know more about.