My first GDC conference was an awesome experience! I’m sure my head exploded multiple times throughout the week attending talks, meeting awesome people, eating great food, and a bit of sight seeing around San Francisco. Unfortunately, I came down with a double whammy of the flu/cold and bronchitis. Being ill the last couple of days of GDC were pretty miserable, but I was able to keep my head up for the rest of the week and try to enjoy what little I could. The flight back felt like a death sentence though. It was a bit of a downer coming back from GDC so energized and ready to work only to be out of commission for the next week and a half recovering from bronchitis (the cold symptoms went away a couple days after getting back).
In any case, I’m finally able to work (and write!) again this week with only minor coughing fits. And there is so much to cover, but being my first iDevBlogADay in a long time I’d like to focus on a little problem and a possible and exciting solution facing a lot of indie devs these days.
Keep in mind, as I write this I’m thinking from the perspective of an iOS developer looking to branch out. One of the biggest successes in the past couple of years is the explosion of devices that have become accessible to indie developers to make games on. Yet, one of the biggest downfalls is tendency for the software/hardware vendors to do what they can to create ‘vendor lock-in’. Apple iPhone with Obj-C, Microsoft windows phone 7 with C#, Android with Java (and the fragmentation of hardware within this ecosystem). I’m not going to speculate whether this ‘lock-in’ is a priority/intentional, but it’s a factor nonetheless when developing these days.
Even now, as an indie dev I’m still primarily focused on iOS development because it’s what’s working for us. I’m sure if I started out on Android (and I almost did a few years ago when deciding between getting an iphone or a G1) we may have the same but opposite opinion looking from the Android world. Yet, as I work on iOS games it’s becoming increasingly harder to ignore Android as it becomes more prevalent in the market. Lately, I’ve been trying to keep tabs on different technologies to hopefully allow me to keep development of our games in-house as much as possible.
I got into this line of work because of the joy I experience creating, developing, and releasing games. I would hate to see a future where I’m simply orchestrating contractors to port our games to platforms x,y, and z. Going along with Joel Spolsky’s advice, I’ve always had an aversion to outsourcing our core competencies:
If it’s a core business function — do it yourself, no matter what.
Pick your core business competencies and goals, and do those in house.
I think there’s an unstated assumption when talking ‘multi-platform’ with iOS devs that what they really mean in general is iOS + Android. It’s still a shame that to go to Android pretty much means “Hey, I don’t care what language you wrote your game in, re-write it again…in Java…muahahahahah”. In fairness there is something called the NDK that seems it might be feasible, but I haven’t look too far into it. Despite me wanting to keep development in-house, I think Android may be a lost cause without 3rd party engine or library support that will allow me to abstract away the platform I’m writing for. Tons have been written on Unity 3D so that’s not what I’m interested in. In fact, Unity3D’s 2D support is still lacking (though they have plans to improve this soon). What I am interested in keeping an eye on is Monkey.
Why? It’s written by Mark Sibly, the man behind Blitz Basic and Blitzmax family of languages. Coming from Blitzbasic and Blitzmax, I’ve become quite jealous when working in plain on Obj-C or C/C++ because these languages weren’t designed with ‘game development’ in mind. The biggest plus that came out of Blitzmax was true cross-platform compatibility. I can write code, compile it, and run it on Windows, Mac (Intel/PowerPC), and Linux. And true, the same can be said for C/C++, but the brilliance is you don’t have to think about it ahead of time. I’m currently writing some game framework code for our next project and I’m constantly having to ask myself, “What platform is this code specific to and what do I need to abstract away?”.
I’ve written networked, multiplayer games in isolation on Windows with Blitzmax only to drop the source on a Mac, compile it and instantly have a native mac client play against a windows client. This is the dream setup for mobile devices, and it something Mr. Sibly seems to be striving for with Monkey. Monkey allows you to create games for iOS, Android, Flash, HTML5, and even XNA with hopefully the same ease. While I’m only playing around with it right now, I’d love to see this get wider , more serious adoption as it’d be harder to be held hostage by a single platform, but still have more ‘lower level’ access to writing a light game instead of using a massive engine and workflow like Unity. The HTML5 demo was pretty mind blowing as to what can be done in modern browsers now, and you can try out a bunch of the HTML5 monkey demo apps here.
I’ve actually even went the route of writing some of our first tools for our next game in Blitzmax. Adam is on a Windows machine and I work primarily on a Mac, so having tools for both OS’s without having to write anything for a particular OS was a nice plus.
I’ve pretty much resigned myself from re-writing games from scratch for Android. In order to target Android in-house I feel I would have to write the game in a higher-level language or toolset (be it Unity or Monkey) to make it worth it. I think going forward any indie has to think long and hard about their target platforms they wish to hit before writing a single line of code, because once you’ve started on one path you might not be able to turn back easily. The work I’m doing now is to allow us to move our future games to other C++ friendly platforms like Mac/Windows, which I think could be pretty exciting. In the meantime, I’ll be monkeying around with Monkey.