Port ahoy!

I'm going to talk about some game development, but first...

I'm back in America!

And it's absolutely fantastic to be back. I've been back since mid-August, and I've been enjoying the company of my friends, family, and my dog. Not to mention all the great food I've been missing! Pizza costs $25 less here! What a country!

Occasionally I miss Niikappu, but it's more that I miss the people I met there. My badminton group was great, and I still have to find a place to play here at home! The students and teachers were great, and I miss them too. But not the town office. Not one bit.

So lately, I've been working on Star Reaction, and it's going well, considering it's our first game and our first time working together. How we'll eventually sell the game and distribute it is another story, and another post! The more pressing question on my mind is...

How do you port a game?

Well, that's a good question. Star Reaction is written in C# and uses XNA, which is what I've been using since my first trip to Japan in 2009. Long story short, I've been building Bolt, a fairly comprehensive 2D game engine, since then using C# and XNA. This is my second time building a game engine, but again that's a story for another post!

So after we formed unTied Games (yeah, we had a bit of a name change), we kept working in C# because... well, it was what I was using! We didn't really have a target platform at first, and it was only once we were a month or so into development that we decided we wanted to develop mobile versions as well, plus Mac and Linux clients. Okay, so we either have to
1. find a way to use C# and XNA on iPhone/Android/Mac/Linux devices,
2. use a different game development library and a different language for each platform.

Pitfall #1: Choose your target platform first!
If we had known what platform we were developing for beforehand, we wouldn't be in this predicament. After some research, I found that there are options for using XNA on iOS, Android, Mac, and Linux. Oh, except its dependencies cost a metric fuckton of money.
We discussed the options, and decided that the best thing to do would be to do a Kickstarter to raise the funds needed to buy licenses to the two expensive APIs. Except we still haven't gotten it online, because we're not quite a legal entity yet, there's still paperwork to be done. The process is taking so long that I began to look at other options for porting again. Too bad, because I did so much research that all the Youtube ads I get are now advertising Xamarin's Mono for Android.

Next, I looked at Lua, a cross-platform scripting language.

Pitfall #2: Interpreted languages
As an interpreted language, I knew it would be slow. I kept telling myself that. But nothing prepared me for staggering slowness of this magnitude!
About two weeks ago, I began looking at Lua as a way of porting code. The idea was that both Bolt and Star Reaction could be ported to Lua, which could then run on each target platform. Then on each platform, we'd have an adapter program that provides platform-specific draw routines, timing, etc. It's not perfect, but at least this way I'd have to rewrite less code per platform! As a test, I wrote a very, very, very basic port of Bolt that really just amounted to a game object manager and objects that had nothing but positions and velocity. No rotation, scale, transparency, collision... Nothing fancy! Alright, let's fire it up...
Alright, with 500 objects bouncing around the screen, it's getting 60 FPS. Let's turn it up a bit.
Uh. With 1000 objects, it's getting about 48 FPS. Let's optimize a bit...

Alright. Now it's getting about 59-60 FPS with 1000 objects. That's about how many objects Star Reaction has on the screen, given that each board piece is an object (the actual pieces of the board: 548 objects), and the bubbles in the tank are all objects (30 max per tank = 180 objects), plus the gun, background, stars, star fragments, and the rest of it.
But that's just 60 FPS. With no timing, no delays, no rests in the code. It's running as fast as it can on my beefy computer, and the best it can manage is 60 FPS. On my dad's less-beefy computer, it clocked in at 25 FPS.

This was going nowhere fast, especially given that...

The native engine could handle roughly 7000 objects.

The interpreted code barely handles 1000.

Needless to say, at this point I dropped Lua altogether. It would be cool for user-editable scripts, or for collaborating with a larger development team on smaller scripts. But this isn't that kind of game, this isn't a big team, and I just wasted a few days working on this!
But time is never truly wasted when you're learning, especially when you're learning from your mistakes.

So what now?
Well, since Flash is dying, that isn't an option. Lua is too slow. HTML5/Javascript can be pirated and cloned. C# isn't portable. Java is entering the realm of obscurity. What's the next best thing?

I'm currently porting Bolt to C++ (a far more portable language than C#), and the display routines will be handled by Allegro, a cross-platform game library with a great community, where development and bug fixes actually happen. I've used Allegro before to make some pretty cool things, and the new version is much better and includes hardware acceleration!

Allegro runs with no issue on Windows, Mac, and Linux. Android should be possible, with some work. The Android port of Allegro is still very much in development, or so I hear. For iOS, I don't think there's any other option but to port Bolt again to Objective-C, a language that doesn't look very pretty. Once that's done, it should be alright, since the iOS port of Allegro is more finished than the Android port.

I only wish I had started from this point!
One problem will be buying/borrowing a Mac that I can use to compile and test the Mac and iOS ports. Macs are pretty damn expensive though; even one from 2008 on eBay is bidding for $265 right now. And if I borrow someone's Mac, they won't be able to use it for a while- and everyone I know who has a Macbook is using it quite often.

More to come as we progress.

Avast, ports ahoy!