Monster Math - Journey to the Android launch!

Its been a thrilling roller coster ride for all of us at Makkajai.  I remember the days when we were building our first game Monster Math Classic on iOS,

• We had no clue of how to develop a game?
• How to market it?
• How to get customers etc.  

All we knew was that, we had an idea and a lot of determination to execute it :D

In November 2014 we launched Monster Math Classic our first game on iOS.  Even though this was our very first game, we still managed to get lot of love from parents, teachers and students.  They had very kind words to say about our game.  Not just that, they also gave us some very awesome feedback, which could take user engagement to the next level.  We heard our customers and we incorporated their feedback which made them even more happier.

Somewhere in October 2015 we launched two new games Monster Math and Monster Math Multiplayer which got an even better acceptance than Monster Math Classic.  All these were still iOS only games.

One question which kept on coming from our customers was: When is it getting launched on Android!

It was not as if we didn't want to launch on Android.  We wanted to, but since our game was using Cocos2d (A game engine only for iOS), we couldn't do it just by a flip of a switch.

Somewhere in March 2016, we decided we need to launch our game on all major platforms, so that more and more kids can take advantage of our solution.  We started the effort on porting Monster Math solution to Cocos2dx.

When I first started to port, it felt like a never ending task.  We had around 50K+ line of Objective C code to be ported to C++.  Just the though of doing this humongous task -- that too all alone -- gave me nightmares :D.

There were many many problems to solve before we could could even compile an APK.  But as our dear friend Mark Watney (The Martian) says:

At some point, everything's gonna go south on you... everything's going to go south and you're going to say, this is it. This is how I end. Now you can either accept that, or you can get to work. That's all it is. You just begin. You do the math. You solve one problem... and you solve the next one... and then the next. And If you solve enough problems, you get to come home!

So thats exactly what we did, we started solving one problem at a time.  First problem was how can we quickly port Objective C code to C++ with minimal effort?

Instead of manually re-writing 50K+ line of Objective C code to C++, I wrote a quick and ugly Objective C to C++ translator.  It reads and parses any Objective C file and translates code into C++.  Simple right?  This translator does not generate compilable C++ code (because that would be difficult and time consuming).  It only get 90-95% of the job done!

This one step alone saved us few months of mundane work :D

• After the initial translation was done, I manually fixed the compilation errors.  
• Replaced Core Data/Realm with SQLite.
• Added memory management code, since there is no ARC to cover us.
• Replaced various SDK's with cross-platform equivalent.
• Where a cross-platform equivalent SDK was not available, we used platform specific code to integrate native SDK's.

After solving innumerable such small problems, on July 14 2016 (after around 4 months of starting the project) we launched Monster Math on Android!

I am very grateful to have gotten this opportunity, I learned (and unlearned :P) so many things in such a short duration.  I am super excited (and proud at the same time) to have achieved this feat.

Finally, I hope Monster Math on Android gets even more love from its users.  Keep Calm and Have Fun!

How to enable Immsersive Full Screen mode on Android with Cocos2dx

We are executing a project to port our flagship solution Monster Math 2 from Cocos2d to Cocos2dx.  This would enable us to release the solution on variety of different platforms including Android and Windows Mobile.

During the port, I came across one simple yet interesting problem -- Need to make the game UI truly full screen.

A lot of the Android devices have software navigation buttons at the bottom of their screens.

Android System Navigation Buttons

They seem to occupy part of the screen and block some part of the game UI.  Needless to say this does not give a great experience to the end users.  A better experience would be to hide these buttons.  But hey, if they are hidden then how do users navigate to the home screen or different apps?

Ideal experience would be to hide System navigation buttons at all times, but have some gesture to bring them back for a short duration when user needs them.

Android 4.4 (API Level 19) natively supports this functionality using the flag "SYSTEM_UI_FLAG_IMMERSIVE_STICKY".  This mode is called the immersive full screen mode.  When immersive full-screen mode is enabled, game continues to receive all touch events.  The user can reveal the system bars with an inward swipe along the region where the system bars normally appear.  System bars will automatically hide again after a few moments.  Perfect isn't it!

Usually setting this flag is enough to achieve the desired functionality, however in certain edges cases we need to do some additional work.  For example if you have a text field which accepts user input, once the on screen keyboard is dismissed the system navigation bars seem to stick around and do not hide until you kill the app and open it again.

In this post we are going to see how exactly to handle all situations so that the immersive full screen mode will always stick around for the app.

How Do They Do It!

What we need to do is basically setup SystemUiVisibilityChangeListener and FocusChangeListener and hide the system status bars in the callbacks.

Here is the sample code on how to do it.
That's it.  Once you run this Activity you should see that the game launches into immersive full-screen mode and remains in that mode!

How to fix Cocos2.1 shader crash on iOS 9 - Part 2

In my previous post, I explained how to fix the open GL Shader related crash on iOS 9.  This crash was specifically occurring for apps using Cocos 2.1, the crash fix did work correctly on iOS8 and above.  But the fix had introduced another crash on iOS7 devices.  The crash report looked like this:

I investigated the issue for sometime and then I had my "duh!" moment.  The code that fixes the crash on iOS 9 used the method "containsString" of NSString class to find whether string A contains string B (on line no 18).

The method "containsString" was only introduced in iOS 8 hence, it was not available on devices running iOS 7 and below.  When the code tries to use that method it obviously crashes the app!

We changed the code to not use "containsString" and used "rangeOfString" instead.  This method was supported on iOS 7 as well.  The updated code looks like this:

Heres the fully updated code that works on all devices running iOS 7 and above.
Such a silly mistake this was!

How to fix Cocos2.1 shader crash on iOS 9

We have been using Cocos2D 2.1 for our game Monster Math.  Recently we decided to release an update to the game by compiling it against iOS 9.  To our surprise the game started crashing right at the launch with the following error.

A little investigation showed that it was crashing while creating OpenGL shaders.  A little googling proved that others were facing the same issue (more details here and here).

Whats the Fix - How Do They Do It! 

To fix the crash, I had to modify code in file CCGLProgram.m of Cocos2D and change the method compileShader as follows.

Once I made the change, the crash disappeared and it stared launching the game without any problems.

After this change we released an update of our game to AppStore.  We did however see a few crash reports around this very same issue from devices that were running iOS 7.

Will have to investigate further and fix it for iOS 7 devices as well.  Will keep you guys posted on what we did to fix it for iOS 7 devices, till then, have fun!

Passing CGFloat to methods resets the value of arguments to 0

Recently, I was faced a very weird issue with methods that have CGFloat as argument.

The Problem

We were using cocos2d for our iOS project.  The code was very simple, I was trying to invoke a method of class that takes two CGFloat arguments.

No matter what values I pass to doSomething it always receives 0 or some other garbage value.  Just to be extra sure, I even logged the values of the parameters passed before actually invoking the method.  The values got printed correctly, but the doSomething method always printed 0.

The Explanation

Well, I was stumped here.  This was like the simplest possible code.  Set the value of a variable, pass it to another method and BOOM the value gets reset!

Obviously, this was nothing to do with how I have written the code, others out there must be facing the same issue.  A bit of googling calmed my nerves.

CGFloat is just a typedef wrapper around either a float or a double. Whether it actually is a float or a double depends on the header where CGFloat is defined that your code compiled against.  The CGFloat definition looks something like this

Notice how CGFloat either becomes a float or a double, depending on whether the architecture is 64 bit or not.

All goes well, until you mix code compiled with this flag on, with other code compiled with this flag off (Such as including a binary library with other code). Effectively mixing 64 bit compiled code with 32 bit compiled code.

This can potentially lead to a case where we are passing doubles to methods that are expecting a float.  Since this is all happening at the byte level, no error is thrown and the bytes are just truncated, taking off all of the bits that actually described your value and leaving bits with nothing in them i.e. 0.

In my case, it was happening because I was trying to build a binary for both the Simulator and iPad Air Device.

The Solution

A clean and build should have solved the issue, but I decided to change the method arguments to float instead of CGFloat.  Once I did this change, everything worked as expected!
Thats all folks!  Until we meet again, enjoy your time.