HTML5 is never quite ready

I managed to clean up most of the prototype with new assets, and have something that was more publicly presentable. ImpactJS was the first time I’d worked in a framework, rather than an engine, but it became rapidly apparent that the Framework was designed for platform games, and I ended up not using and having to bypass much of what was there, mostly relying on the gameloop, and the object faking.

I started running into troubles, the game was locking up on OSX, and I couldn’t test there, and the two leaderboard systems I implemented shut down almost as I implemented the features. I decided that Google’s Game Play Services would be a better option, whilst they do have a reputation for killing off services, they’re usually not ones that they’ve spent much promoting, and they put a huge effort into promoting GPGS.

At about this time, I got a new job and that came with a Macbook air - my sound wasn’t working because it was in .ogg format and it’s not supported on OSX devices. Rookie mistake, it worked on Windows, without special drivers though, supplying MP3 files fixed the Apple bug.

I ended up with a playable game on the web, all fancy and HTML5. Poker Kingdoms HTML5. (This link may not continue to work, I’m only vaguely aware of where it’s hosted).

Great as an example, you can hit the page, play the game, it’ll keep your score, and I think there’s even achievements.

The game was perfect for mobile, so I experimented with a mobile port, and here I ran into serious roadblocks, Google requires a secure authentication token, and clicks on Canvas are not considered secure. At the time, none of the cross-platform HTML5 builders were suitable, either their canvas performance was too slow, or they were pure canvas implementations, which had no other HTML elements.

I resigned to having to build against something that was more proven than HTML5, and Unity was free, and supported the Python-Like Boo language, and I really dig python, so I began porting the game to Unity.