2012 – Year in Review

Well it’s been my busiest year ever. Six Foot Three Foot has kept me busy full time for a whole calendar year. Some projects got shifted, some got shelved, some got released. Over the year, we saw Retro Art Studio grow across both iOS / Android to the point where at any moment in time there were at least 100 people playing the game around the world. For a small developer like myself, that’s a huge accomplishment.

What I’ve done:

Mojo Video Poker has done excellent on the Mac platform, we really wish people could find it on iOS, it truly is the best video poker app out there, and I’m not just saying that because I made it. It really was made by a video poker player for video poker enthusiasts.

Word Jumblerama Blitz, this came out of a personal challenge to make a game in 1 week, I did and it actually did quite well. For a free game, with very little graphical polish, the game keeps people playing in long sessions (sometimes an hour or more), which is fantastic. I’d like to see it get a wider audience, especially on android, and have some ideas to help that out for the next year.

Also Six Foot did a bit of contracting work within New Zealand. I’ve been helping out at Carnival Labs, and helped them on a tight deadline for an app for CNN. Then I took over a project for iOS (iPhone / iPad) for a feature film promotion. I did 5 of the 6 releases, including some graphic work, all the level design, and programming. In the end I made 5 unique programs under the umbrella program, sometimes with less than 2 weeks to develop one. I was also in control of localization, and asset management. Several lessons learned there, and a lot of fun working on new projects. We finished off the year starting a new contract at Trade Me a company in NZ which to put simply, is the eBay of New Zealand. I’ll continue that contract into the next year, and hope to provide them with some good work.

That’s the summary of what we did.

What I didn’t do.

Episode 9:
I had wanted to start work on Episode 9, a not so secret, secret project. However it’s a huge labor of love, taking one of my favorite creations, and bringing it back to life. As a result, along with working 16 hours a day 7 days a week… I didn’t feel I could fully commit to it. I hope to change that very soon.

Box Stuffer:
This was a puzzle game I had started, (I’ve started about 20 puzzle games), it is a good idea, I have all the functional bits, but I don’t have the resources to do the level design. That’s something that I’m not sure I’m the best to do, which has been a blocker on a few projects. I need to either commit to doing it, or find someone to help. This project is still around, even looked at it last week, but it’s on the back burner for now.

New Ideas

Some new things that came out this year which are in progress, I’ll even put a little marker to estimate how far they are.

  • Mojo Casino – (iOS / Mac) [25% Complete] : This was an ambitious project I started to create a collection of casino games that can be played on all devices. I know there are many casino apps out there, so my goal was to make something that was fun, accessible, and didn’t rob you blind of fake credits like most virtual casinos on these platforms do.
  • Mojo Solitaire – (iOS / Mac) [75% Complete]: This is a collection of single player games that help you pass the time. Initially to be released with Spider Solitaire, Klondike, and Mahjong Solitaire. The game was just about ready for release in June, but a new job took precedence, and I can only afford 1-2 hours a week right now. But I do plan to get the first release out ASAP.
  • Arcade Collection – (iOS) [10% Complete] : This is a collection of arcade style games, that are quick play. It is meant to be small fun games, like in a quarter arcade way back when. The goal is for all the games to be compatible with the iCade controller, for a mini arcade at home.
  • Photo Booth – (iOS) [20% Complete] : This is an app that allows you to take photos, and do some fun tweaking, modifying, etc. I know it sounds like other apps, but I hope this one will be slightly different, and more accessible. Plus we’ll never sell your photos…
  • Localive & MediaDirect – (iOS) [ 30% Complete ] – This is a framework I’ve found a need for after working with international clients on rapid development projects. First is Localive, a way to dynamically update text after an app is released (currently you need to release a new version.) I hope this will help people push out apps with functional changes, and then have the localization catch up while the app is in review, saving between 6-16 days per release, a huge saving for a developer over time. MediaDirect, is a tool for quickly and easily serving hosted content to devices. The need this came out of was releasing a universal app with retina graphics, meaning an iPhone had to install with iPad Retina, iPad, iPhone Retina, and iPhone graphics, it became a nightmare in terms of app size. So the goal now is to just ship with baseline graphics, then use the MediaDirect Framework to pull the appropriate assets for the device. Obviously managing of the assets is required, but the Framework should make handling the assets transparent.

As you can see, I’ve been busy and plan to be more so! My work is building and building, as are my relationships with people who make apps, and those who want them. I continue to offer help to just about anyone who needs some input, (I started this company in 1998, so I’ve been around a few blocks). Now I blogged all this, I’m excited to get working again! But right now it’s time to take my family to the park.

Taking our first step away from Mac App Store to Direct Sales

I’ll must admit I love the idea of the mac app store, and the ios store. They take all the work off my plate and take care of the payments, the distribution, and rights control. However what I am now completely jaded by is the inexcusable turn around times. Our last update which we apparently need to fix, took 28 days to be reviewed, only to be rejected due to an incompatibility with an OS that shipped after we submitted the app!

The first time we sent our apps to apple for the Mac we were looking at 7-10 days, not bad. But now it’s taking near a month or more to get any feedback, especially to find out that your small change was rejected. The hard thing is, Im trying to address user issues in a timely manner. I always respond to user requests ASAP when they contact me, but to then tell the user ‘I fixed it, now wait a month or more for Apple to approve it’ just sucks to be honest. It makes us (small developers) look incompetent. The other issue is that a month has passed, and I have been working on 6 other apps since then, I really am not in the mindset to go in and fix another issue in that app. So now it’ll take me a lot of time to find the room to fit it in my schedule, plus I then have to retest is, et al, then wait another month to hear back from Apple.

All in all, it’s not a good situation. I lose out on a month+ of potential sales, and my customers more importantly are getting less updates in a very infrequent manner. There are good things to the App Store, they make finding apps easy, and installing / upgrading is good. I don’t really mind the cut they take if the service was up to par. But I don’t see the justification of 30% of my revenue when I can’t get a timely amount of customer service (which I pay for in a yearly subscription to Apple plus the 30% cut of all my sales). This isn’t a new rant by developers, but it is for me. I’ve long had an affection for Apple’s system, mainly because I helped watch it grow and helped make it grow when I worked there for 5 years. But now, I’m a bit jaded and disappointed. My customers are the only thing keeping my small shop going, and if I can address their issues in a timely fashion, due to an overly lengthy review process by a 3rd party then I think it’s best I find an alternative.

So I now to my own dismay have to create a sales portal, re do all my software validation, and include a way of doing key gen to prevent piracy. This is way more work than I want to do, which is probably what Apple accounts for. But I’m in a corner as I have 2 new apps I want to release and 3 updates to existing apps. I can’t lose 6 months total over those apps waiting for Apple to get review (and getting paid for it from their royalty cut). So, I will do these things, I will create a way to sell my apps directly to consumers, I will implement authentication, I will create an online store, I will do all these things I was so happy to hand over to Apple years ago. It’s disappointing but it’s just a reality. I’ll be working on it as soon as possible, I already signed up with a very well reviewed / popular e-commerce company to handle the sales. They’re called FastSpring, they allow me to add apps to my site and sell directly.

I didn’t want to fragment out into another store such as bodega, and I know my apps would never get approved by Steam as they’re not AAA titles. Also I’m sick of fragmentation, I hate it on Android, and I want to avoid it as much as possible. So I’ll provide my apps direct for sale from our website.

What does this mean for existing mac store users? Well I will always keep my mac store apps up and alive. Apple only lets me submit 1 build at a time, so if we are 3 out of 4 weeks Waiting for Review and I have a new version to send them, I have 2 choices, either remove the existing one, and submit the new one and start the 4 week countdown all over, or wait 1 week if the app gets approved then upload the next version. It’s painful, but that’s what we’ll have to deal with.

The website versions will be able to be updated faster, and direct to the users. They will not be able to be upgraded via the Mac app store, but people who buy from the Mac app store will get updates, they will just take longer unfortunately due to the process above. For my customers, which will I recommend going forward? Ideally purchasing directly from us would be better, because I can address your issues directly. If you have the Mac App store version, I can’t give you the non-app store version if I make a fix, you’ll have to wait for the Mac store version to be updated. However if you (customer) feel more comfortable with Apple handling the transactions than our provider (fastspring) then by all means use them, just know that updates will be slower. On the plus side it looks like I keep a small amount more if you buy direct, something like 10% goes to the provider, and 90% to taxes and myself.

As I find the time I’ll be implementing this new model in our apps and putting them up for sale on the web as we get there. But it’ll take a whole lot of software writing to get there to implement all this. And I am currently writing 12 hours of code a day for a client, so I’m pretty flat out at the moment… but I’m sure it’ll take me much less time than Apple to approve our next submission…

Word Jumblerama for Android Released

Word Jumblerama Blitz has made it’s way to the android platform, and is now available via google play as well as on the Amazon App Store.

Word Jumblerama Blitz for Android is a free to play game (ad supported), and features Kiip integration where available. Kiip allows players to earn real rewards for getting high scores and achievements. In Word Jumblerama, if you can hit a high score you can unlock an award, easy peasy. It’s a great game for people who love the old board games like boggle, and doing news paper word jumbles.

Game Features:

  • Fast two minute games
  • Multiple colorful themes
  • Free to play
  • Kiip Rewards*

Get it on Google Play!

Or Don't

Get it on Amazon!

*Kiip is dependent on location. Rewards are handled through the Kiip service, not us.

Cocos2dx Migration -> Seventh update (44 hours) And now to rest

Whew! What a rush, I’m exhausted. Squeezing in an app release in the middle of a full time job, 6 maintenance releases of other apps, and jumping between 3 languages on 4 platforms, all I can say is ‘I need a relax’. But there is no rest for the weary, my current contract job is in high gear and I have to finish a whole cocos2d world for 2 different devices (so technically 2 worlds) in 4 days.

That said, we’re done I guess. We’ll find out if there’s glaring issues when it’s out there, but this is the first step to this app’s long future. So the last few things I did, is added a little gloss, some custom labels i’ve wanted in there for a while, added a help screen, and some other bug fixes here and there. There’s a bit more to go, but this was a good baseline release, a playable game, with Kiip rewards in there, and out the door in under the 48 hours I guestimated. That’s always a good sign.

Going forward, I need to start wrenching in the iOS code from the original objc version, this time to get game center back in there, and other custom iOS only things that need to be in obj. I also have a version that I’ve been working on for iOS which is multiplayer, I’m really excited for that, but it’s very very hard to test by oneself! two computers, two devices, two GDB’s, and single source code synched up, it’s very time consuming! But I’ll get to that later. I also want to release for Amazon market, but I haven’t really figured it out yet, I sent one app to them and it’s stuck in some queue, and it doesn’t make much sense. But i’ll post experiences on that vs google later (once I get it up and running!)

Anyway, I should probably cover a lot more detail in what I did, but I’m just happy to be done. I’ll come back in the +4 hours and do a proper post mortem, maybe see how the initial pick up is and see if there’s any comments to be made on Kiip. That may be down the line to see how it pans out, but still lots to cover. I have to get back to work, lots of more projects ahead.

Blogging this was pretty fun, maybe I’ll do some more, and start adding a few more technical bits and share some code again (once I get organized). Till next time…

Oh! By the way, how about some links? The app is free on all mobile and only a couple bucks on OSX. Game programming is a passion for me, not a financial gain, so if you do enjoy anything here pick up a game it’s a great way to say ‘thanks’ and keep me working on ’em.

Here’s the original cocos2d (currently) (universal)iOS version:
Word Jumblerama Blitz - Six Foot Three Foot

Mac version (Paid because no ad support, but very cheap!) :
Word Jumblerama Blitz - Six Foot Three Foot

Google Play Version (The one this blog followed! cocos2d-x, Kiip):
Or Don't

Cocos2dx Migration -> Sixth update (40 hours) JNI We meet again

Things were moving ahead quite nicely, converting my obj classes to C++ went smoothly, cocos2d-x is really well refined. I even found out that there was a problem in my declarations for using sprites with sprite frame names, so I fixed that code. I also wrenched in some ad frameworks, and most of all I’ve been working back and forth with the folks at Kiip. After my first (bad) impression, they were kind to follow through with all my information requests and clarifications. So in the end I said ‘if it’s not too hard to integrate, i’ll give it a go’. Well the issue we have here is that Kiip is native for iOS and android, but I want it to work on both. Plus, all my code is cocos2d-x (c++) with no calls to Java (well very few), so I’d need a JNI wrapper to handle Kiip. I’ll get to that in a second.

First things first, I think my first post I mentioned I love the new ‘create’ initializers, however I had an issue with create(), well that’s because I called the wrong init! There is actually a createWithSpriteFrameName(”). If you use just create(”) it’ll look for that file, not a frame name, hence the second initializer. It just brings it inline with what they’re doing, and it’s great. So to sum up.

To create sprite with a file call this:

CCSprite *mySprite = CCSprite::create("filename");

To create one with a spriteframename

CCSprite *mySprite = CCSprite::createWithSpriteFrameName("frameName");

Ok that’s cleared up let’s keep moving, as we have some more work to do! So Integrating the ad networks (I use mobclix and admob open allocation) was pretty easy, I actually migrated the code from my other app ‘Retro Art Studio’ for android, and dropped it in. I did have an issue doing the layout in the XML file, so I just did it programmatically and it worked fine. The only thing I’m not doing which I’d like (which I do on iOS) is control when the ads show and hide. Right now they just are a view and show over the game when the app opens, sorry I just don’t have time right now to fix that. Ideally I’ll plug in some JNI calls and have them hide / show during the right times.

JNI… first of all, I write code in many many languages, C, C++, OBJC, Python, (some ruby, basic, shell, action script, javascript), etc. One language that I’ve used in the past, and try to avoid at all costs is JAVA. I find it repulsive, I won’t go into the details, but the sum is ‘write once run everywhere’ the original motto never worked, so everyone who jumped on it got screwed. It’s the most difficult to develop and debug language around. By attempting to simplify (‘HEY NO POINTERS NEEDED!’) they’ve encouraged sloppy programming standards, and an over complicated way of delivering underperforming code. — Sorry for the rant, just got stuck in the Java mud and it pains me every time — Professionally I tell clients I don’t do Java, and they assume I don’t do android, on contrary I do android, via C++, if you want a Java / web based app, there’s plenty of people out there for that. I’ve worked at Apple, I’ve used Java (not at apple), I’ve used Windows for many years (prior to my job at apple), and in the end I choose the tools I like, which are Linux/Apple OS’s, C based languages, Xcode (for C++/OBJC/etc), Python for scripting, vim for editing on the command line. P.S. I have zero fear of managing memory, I actually enjoy it.

OK! Rant over, back to work. So Kiip, these guys have an interesting idea, but like I said I wasn’t sold on their initial pitch, but going back and forth it seemed like something I’d be willing to try on this android version of the app, and if it worked well I’d put it in the iOS version. The basics of Kiip is that you can reward players at certain levels with unlock able real-world items. Mainly coupons, vouchers, gift cards, etc. I don’t provide them, they are provided by the advertisers, e.g. If you unlock level 20 in your game, then you’re rewarded a coupon for a bag of Chippy brand Fish Sticks. Which apparently you can take and redeem at your local Chippy brand grocer. (Or something like that).

So to integrate I needed it to work on both iOS / android. First thing is their setup is pretty good, I’ll admit the walk through was easy to follow. And I called into the iOS api instantly and was up and running in about 20 minutes. Their website has great debugging as well, you can real time watch the log of you logging in and unlocking achievements. Impressive. Now for android… My contact at Kiip was great, when I mentioned I was doing cocos2d-x he sent me a wrapper class another dev had created for JNI. This was a huge help, until 6 hours later I realized it didn’t work. No fault of Kiip (they said it wasn’t their code, and was unsupported), and no fault of the original Dev. It was built against a different version of cocos2d-x and Kiip, so it just wasn’t up to date.

I had to put on my JNI hat again, and grrr… go to java. Well I hit so many roadblocks, first this code was made without JNIHelper, which simplifies a lot of code that was written, second I couldn’t get the method signature right for the kiip call to the ‘saveLeaderboardScore’ method. I could get access to the static singleton, but couldn’t call the method inside. I tried every combination I could think of, and it just wasn’t going. So after a while, I just implemented JNIHelper and that simplified the code by about 140 lines. However it still wasn’t doing what I needed, the signature was wrong. I called it the way the API said, no luck, I called it the way javap said, no luck, I made up ways to call it, no luck. So in the end I did a ‘hack’, but it worked and it was clean and easy.

I implemented a method in my root java class (the one called by the app that loads up my c++ code), and in there I added a simple static method that called the actual lib and submitted the score. Then in the JNI wrapper, I replaced all the code in there with a call to my simple static method and hey, it worked! Ideally I should call the method directly, but that wasn’t going well, and I feel that if I can do the same in < 10 lines of code that was done in > 100 then I’m probably ok. Obviously you don’t want to add a ton of new methods to your .java file, but this really is a single one as I’m only using leader boards right now, so I didn’t mind.

Here’s the code I ended up using in my .java file

	 static public void kiipSubmitToLeaderboard(String boardName, int score)
	 {
	     Kiip.getInstance().saveLeaderboard(boardName, score, null);
	 }

Then to call it from my wrapper class.

void GameResults::SubmitHighScore()
{
...
    KiipWrapper::sharedKiipWrapper()->reportScoreForLeaderboard("highscore", _score);
...
}

You can have multiple leader boards, so just create a const char * for whatever the name of your leader board is along with the score amount. There’s probably many other ways to do this, but for 6 lines of code, not bad.

After that, the kiip code was up and running and I just tweaked out the alignment a bit (which is done via their web interface, in real time which is cool.)

Depending on how my (and my users) experience with Kiip goes, I’d be more inclined to explore it more on my other apps, as well as provide a step-by-step approach to get it up and running in cocos2d-x. But first I have 8 more hours to go to hit my deadline!

Cocos2dx Migration -> Fifth update (32 hours) The meat of it

I’ve done thousands of lines of code in the last few days, and 32 hours. The main benefit I have is the speed at which I can type, moving between the languages is easy enough, the only slowdown is when you hit something platform specific (reading / writing files for example). Once you get over those hurdles things move quick. Now I’m in the much of the ‘boring bits’, this is where I’m basically just going through the code and translating it.

The benefit I have is the existing OBJ-C app has shipped on two platforms already (iOS/MAC) so I know the code all works, and when something doesn’t it’s usually something as simple as a variable not copied correctly. I wish I could say I have a real easy method of doing this that I can share with others, but the truth is, I have a single workspace and I jump from the original code to the new code and copy and paste, then re write the methods using the original code as a reference. It’s all pretty easy going, just time consuming.

I was on holiday for a few days, so I just got about 2 hours a day in, but still I’ve made a lot of progress, and have just 16 hours left to go (hopefully). Here’s the major bits I did.

Since android will be the first release, I started doing some Android specific things. First was to implement the ad networks for the app (as it’s free on mobile and ad supported). I had done this before, but anything with Android / Eclipse is always a new learning experience for me no matter how much I do it. I just never enjoy it and my brain flushes it out immediately after I do it. Regardless, after a few hours it’s all up and running. Now I’m going through and porting more of the core classes and views into the app. The good thing is about 20% of this code comes from shared classes I use on my other apps. When I do an iOS project I usually have about 25% of the code ready to go from frameworks / root classes I’ve created. Now I have these in cocos2d-x (versus obj-c cocos2d).

I’ve always prototyped in OBJC because it was easier to get started because I have so much pre-work done. But now with this project I’ve translated a bunch of shared things from OBJC->C++, so possibly (and hopefully) I’ll start doing my prototypes in C++ using cocos2d-x now, so I don’t have to revisit this exercise again! The cocos2d(x) framework is very easy to understand once you use it a while (i’ve used it exclusively for > 2 years, and have done about 130 prototypes, 8 commercial apps in it. The only thing officially missing from cocos2d-x is full MAC support, I know it’s in development, but with cocos2d I have it out of the box currently, which is why I start there. Also other platforms (aside from iOS/OSX) haven’t proven fruitful yet. But I do like the idea to grow, and is why I like the C++ work in cocos2d-x.

Anyway, so we have the core game up, we have the ad support, the main menu brings you to the game, you can play it, start a new match, all the animations works, etc. What’s missing, scoring, game over handling, other menu items, pop up notifications within the game.

Word Jumblerama Blitz for OSX Released

Word Jumblerama Blitz, our popular quick fix word finding game is now available for OSX. Featuring the same great gameplay as on the iOS version the OSX version includes unlock able achievements, multiple themes, and the fun quick action you’ve come to know.

The OSX version is ad free and only $1.99! If you haven’t played Word Jumblerama Blitz yet, check out the free iOS version (ad supported) and give it a try.

Word Jumblerama Blitz - Six Foot Three Foot

Cocos2dx Migration -> Fourth update (22 Hours) Kicking down the wall

Well just like a Thursday morning, I’m over the hump. Getting into the android slump is always discouraging, but once through the middle of it (you’re never always out), things start to look up. I had a rough few hours last block, and I waited until I was done until I posted to keep my mood light. So, where are we now? We have all the core gameplay working, the tile selection works, the word lookup and matching works, and it’s blazingly fast.

So as I mentioned before we had some issues with Android, the question always comes up ‘You don’t care for android, but why do you develop for it?’. It’s true, I don’t care for it, for a few reasons, mainly the JAVA bit (which I don’t need to touch much thanks to cocos2dx), the fact that I have to write for 2.3 devices which make up 60% of the market today (shocking as 4.0.3 is out). [Devices can’t update, and most manufacturers still ship 2.3 for low-end phones as it has much cheaper licensing costs, and less restrictions from google]. So that’s never fun. So the reason why I do develop for it… I simply like a challenge, and I like keeping my coding skills up to par. I can write OBJ-C in my sleep, it’s my day job, and I do rather well at it. That’s work for a client, I always tell clients to avoid Android when they can, as the work / cost is 10 times that of iOS and the return is about 1/10th. This is pretty well known now in the market, unless you’re doing a utility app (banking, finance, fart app), for games it’s not viable yet.

But I like c++, but I really love cross platform development. I always write my objc projects in a a custom environment which runs on Mac, iPhone, iPad all within the same code. It is a bit of setup work, but in the end I have one code base for 3 platforms. With cocos2d-x I can get 5 platforms potentially (more, but only 5 I’m currently interested in), all on the same code. That’s a really cool concept, and Android does have a market. I may not like the software, but the hardware is kind of cool, and I really like users, as well as my games. My games do well on iOS ratings wise, so that encourages me to port them to other platforms. They don’t move many units on Android, but the feedback is great, so that’s encouraging. So yes, in short I bury the hatchet with the platform to deliver to the customer.

Ok so some technical things! Wow reading a huge plist / processing it on Android was unbearable, something that took 1 second on a iPod takes 11 minutes on my android tablet (same chip as an iPad), I blame the os. So that led me to some cool programming which I carried over to all the platforms. Basically I already was generating this huge dictionary from the plist on Mac, so I then just added a call to save it as a binary file to disk. I then take that binary file and load that into memory, and parse it into an array. Basically doing the same thing, but pulling out the middle man of reading in a plist / parsing it into a primitive array. That said, I got the loading time down to 200 milliseconds on android. That warrants a smiley… 🙂

Next thing I hit was errors on Android which I didn’t see on iOS. These were memory issues. I created a custom class that will determine your resolution and pull up the right assets. If you’ve done android from iOS in cocos, you’ll know you really want your ‘-hd’, ‘-ipad’ files to work instantly. Well they don’t, so I created a simple class that does similar logic and appends the file suffix depending on your resolution. Anyway, the issue I hit was that the memory sometimes go bad after making the call. I was passing const char* pointers out of the methods, which ‘is’ correct, but when setting multiple labels, etc to the same variable it would get lost.

I didn’t set up the overly complex way of debugging c++ code in eclipse on android, so I had to do some logging to catch the issue. It was pretty apparent after a while it was memory gone missing, as it would work on a relaunch, and fail somewhere else. (It always worked on iOS). So I then looked at ways to keep that memory around, using strdup worked great, but it caused leaks, as I was returning the value with a strdup, so no way I could release it. But then instead of fighting c solutions, I put on my cocos2d-x hat, and then simply returned a const char* as before, but fed that into a CCString, that then worked until the end of the method and cleaned itself up properly, no leaking! I had that issue a couple places, as it’s a word game, very character centric!

Anyway, not much insight here, this is more of a log than a development lesson, if I had the time and there was interest I could cover some of these topics in more depth. For now I’m just fighting the clock to get the app done. But we’re getting close the core gameplay is working, now I just need to start adding some of the other displays, (timers, lists, etc), which should prove challenging as they’re custom drawn views, but challenges are fun. (Usually after the fact)

Cocos2dx Migration -> Third update (14 Hours) … Hitting the “Wall”

Things were moving along so well I thought i’d jump a head a couple steps, and get Android builds up and running. Something I knew would be painful, and as expected it was.

Before that I have most of the core logic in the game, it’s not all up 100% but we’re now registering interactions and some of the core gameplay. I guess I’ll explain a bit how I do this. I grab a method, for this example ‘TouchMoved’, this is where I detect if a tile is being selected or not. I then simply take the existing cocos2d (objc) code and translate it to c++. Everything maps about .95:1 a very few exceptions, and those are easy enough to sort out. And then when I hit a method call that’s not implemented, I then add that stub and write out the code for it.

Example (pseudo code), in my ‘TouchMoved’ I have a call within, ‘if touch is valid, then execute draw connection code’, well when I got to that part, the draw connection code wasn’t implemented, so I then stubbed out the m ethos ‘drawConnections’, and then translated the code again from the origin objc to c++. Pretty easy, instead of going top to bottom through the old code, this way I can work in snippets of code of the same logic. Sometimes I find improvements in my rewrite this way, because I can see the flow of actions calling the methods.

I had to write some custom wrappers, because I have an interaction handler which uses touches for iOS devices, and mouse / keyboard for mac. I then use that class to send messages, so my core code doesn’t know / care if it’s a touch or a mouse click, to it it’s the same, and it simplifies the code. I had to re-implement that class in C++, and in there I found a limitation that I couldn’t use CCPoint as an argument to a notification. I then created a wrapper class which is a child of CCObject *, (cocos2d-x root object), which I can now easily pass around between the classes to handle my points. It was simple, clever, and it worked, the way good code should!

Now the wall —

So I decided to build up for android, and to do this I had to create an android project with cocos2d-x, and then integrate it into my iOS code. I’ve done this before with ‘Retro Art Studio’ for Android, but that was ages ago, and I’m using a much later version of cocos2d-x now (2.0.x). The configuration is one of the most painful parts of this whole project, and doing anything on Android. Android is hands down the worst platform to develop for period. It’s not that I don’t like the hardware or anything, it’s just very very difficult to configure, debug, etc, especially when doing this type of coding, where everything is custom drawn. iOS has basically 4 devices, iPhone/iPod normal (320×480 screen), the iPhone/iPod retina (Double resolution 640×960), easy as it’s just double. Then the iPad (1024×768) (very close to the iPhone Retina so we can re-use a lot of layouts), and the iPad Retina (Huge but once again, double 2048×1536). I have a couple extras I through in for Mac, which mainly re-use iPad assets. But that’s it, really 4 devices, some nuances in hardware, but displays are pretty easy to accommodate. Android on the other hand has over 2,000 devices with over 325 different possible resolutions, things from watches, to TV sized components. The other thing is the quality of the hardware / type of hardware is almost always an unknown. You don’t know if it’s a touch screen like iPhone, or if it’s an older one which requires a pen.

It’s easy to just go after the new fancy samsung phones, but still to this day only 15% of android users use the new software (4.0.x at this time), 60% are on 2.3, a really old archaic by mobile software terms software version. Unfortunately 2.3 is still being sold, because it’s cheap and widely used. So as a developer I have to support it, but with it you lose a lot of advanced functionality of the later operating systems, most importantly the ability to detect the screen type. On Android 3.x you can simply say ‘only run on a device that can support X resolution in pixels’, below that, (2.3) they don’t read / honor that flag, so users may install an app not designed for their phone. You have a choice, #1 don’t support 70% of the market (other 10% use < 2.3 still), #2 try to support low-end devices while trying to make high end games. It's painful to be blunt. So, the setup was painful to get cocos2-x to use android, to compile then run using Eclipse, while sharing all the code / doing all development in Xcode. It's something that I have to relearn every time, and I really wish I could document it and make it easier on myself and others going forward, but it's literally 4 hours of just hacking, trying this, modifying that, tweaking here, until it works, then you just back up slowly as it's a thin thin ice you don't want to go near. One last note on differences between iOS / Android in our app: WE parse a 80,000 word dictionary at the launch of the app, it's stored in a NSArray Plist, which is readable by cocos2d-x regardless of platform. On iOS (same code) it takes < 1 second, on Android (4.0.3 tablet) it takes 11 minutes. Ponder that, the hardware is virtually the same, actually I can get it in a couple seconds on an OLD iPod touch, 3rd generation, but a new Android Tablet takes 11 minutes. I'm pretty sure users aren't happy with the idea of a 11 minute loading time, so I'll look at other ways to do that file parsing, just unfortunate as it's so quick and easy on ios. It's not a limitation of android nor the hardware, just the limitation of they implementation. But it's small things like this which will take more time than rewriting a core to the game. Anyway, that's where we are hoping our next update has a basic playable version, but we need to fix this file loading issue first.

Cocos2dx Migration -> 2nd update (8 hours)

Right now we have the basics of the menus all loaded, and the main game screen is now loaded and displaying some of the core assets. I did hit an issue on the cocos2dx code, not sure why but for now I reverted back to the original code. I’ll summarize below.

Cocos2d-x has a cool constructor for it’s core objects, instead of multiple different constructors depending on your argument, you can now just call the same one, and feed in your arguments. In plain english…

To create a sprite from a sprite frame name we used to do this:
CCSprite *sprite = CCSprite::spriteWithSpriteFrameName(“frameName.png”);
Create a sprite from a file:
CCSprite *sprite = CCSprite::spriteWithFile(“frameName.png”);
Now we can just do this
CCSprite *sprite = CCSprite::create(“frameName.png”);

The new create() has now replaced just about every constructor in 2.0.x. I found it really easy to use mainly because I’m used to all the constructors and cocos2d lingo, it could be a bit overwhelming if you don’t know cocos2d that much, because it’s nondescript. But I found it easy to use, until it didn’t work.

The issue I had was the one above, adding a sprite frame name from a sprite sheet added to the cache, it didn’t work. So, I had to revert to the original call, spriteWithSpriteFrameName(“frameName.png”);. I’ll keep watching the cocos2d-x source and see if a fix comes in, or better yet understand if I did something wrong. As I’m using the old style, it’s marked as deprecated, so I’ll be reminded to check for updates along the way.

Aside from that hiccup, things are going well, and we have 40 hours to go. Most of the core logic is ported, once the main view is up, we have some custom scrolling views we’ll need to port over which I presume will be time consuming.