How I Learned to Stop Worrying and Love Video Game Coding: Episode 1 – Flurry Analytics and Ads

How I Learned to Stop Worrying and Love Video Game Coding: Episode 1 – Flurry Analytics and Ads

Welcome back to our technical post corner.

The menu of today is Flurry analytics and ads in cocos2D-x.

First, let’s talk about why we chose Flurry to manage analytics and ads. Well, that’s a little embarrassing to admit but… because it was the easiest things to do! Flurry is already included in the list of cocos2D-x plugins. Among the possible analytics ads plugin that cocos2D-x provides Flurry felt like the easiest to use. Moreover, it has to be said that the plugins section of cocos-2D-x is not being supported much lately, probably because the focus is shifting towards using AnySDK to manage the integration. But already downloading AnySDK proved to be hard, and 99% of the documentation about it is only in Chinese! So we were faced with three options:
1) writing C++ interfaces to the Java and Objective-C for an Analytics/Ads software or 2) use the existing plugin interface stuff, although a little dated or
3) downloading the much adored “ChineseSkill” language learning app to figure out AnySDK 🙂

As you can guess, we decided to go for the second solution, and Flurry was the only one working with this outdated plugin support. cocos2D-x ships with Flurry 3.2.1, (the current version being 5.3.0). So we knew we were starting with an outdated version of the plugin. Not ideal, but at least we had something to start with.

Flurry analytics worked out of the box as far as we could see. The only problem (not related to the version of Flurry, but to the way Flurry works) was that each “event” we sent to Flurry to be processed by analytics, such as opening the app, winning a level etc., was displayed on the online dashboard of our Flurry account with a long time delay, varying from one day to one week. That was pretty annoying as we were running some tests to understand what’s going on and how things are working and the feedback to the tests could come with days of delay. Here in Eigen some of us don’t even remember what they (she 🙂 ) had for lunch the day before so you can imagine how this ultra delay of Flurry event display almost broke the causality barrier for some of us. Moreover, we found out that one cannot delete events from the Flurry dashboard. This means that if you created an event called “FlurryTest” , it will stay there forever. It will have very low event count after a while, but it will stay there (so be careful not to use an embarrassing event name…). The only way to remove events is to wipe everything, that means creating a new app on Flurry, with a new FlurryID, etc…

However, as always, laziness comes with cost. Some features of Flurry were not supported in our old cocos2d-x compatible Version 3.2.1 and ta-taaam: Ads were not working. The solution to the non-working ads was actually pretty simple (simple once you find it, of course). The solution I report here works for android (I didn’t test it yet on iOS but I speculate that it should be very similar).

Basically, the Java Class AdsFlurry (contained in $COCOS2DX_ROOT/plugin/plugins/flurry53/proj.android/src/org/cocos2dx/) does not call the FlurryAds.displayAd method while it should. This means the Ad is actually received but never displayed! The solution is to modify the method “spaceDidReceiveAd” from

We then decided to try updating it all to Flurry 5.3.0. Also this didn’t prove that complicated. What we did was to substitute the Flurry.jar in $COCOS2DX_ROOT/plugin/plugins/flurry53/proj.android/sdk with the newer versions (FlurryAnalytics-5.3.0.jar and FlurryAds-5.3.0.jar), and run the publish.sh tool (this guide proved very useful ).

That’s it for now. As soon as we try the iOS version, we will update this post with the solution. Stay tuned for more tech-posts!