I’ve always wanted to make games. When I realised (roughly) what you need to do to make games, I was completely convinced that I’d make my own engine for each game, and that everything would be perfect. Soon after, I was introduced to GameMaker and immediately shunned away from it. Many people love GameMaker (and rightly so) but to me it felt like the learning curve wasn’t much better than learning to code, with the drawback of not being able to fiddle with all the bits and pieces. At this point I was still in school, learning Java, and only thinking about making games, instead of actually making them.

When I got to university, I noticed that my C textbook had a chapter around halfway through that we weren’t going to cover in our course, entitled “Game Programming with the Allegro C Library”. I quickly skipped ahead and started going through this chapter, and it felt like I had discovered the holy grail (of game development). Allegro allowed me easy access to simple 2D graphics and proper keyboard and mouse input. After going through their example game of Pong, I immediately decided to make a clone of Jump ‘n Bump, an old favourite of mine. Very soon after this I started using SDL, another game development library, and coded up a horde of prototypes. In function, SDL and Allegro are pretty similar though. I can’t even remember why I switched to SDL from Allegro, but found some tutorials on using OpenGL with SDL and quickly jumped in.

At this point I started using Linux, and the problem of cross-platform development started revealing itself to me. To my delight, most of my initial SDL prototypes worked on both Linux and Windows. The projects I had made using OpenGL were more tricky though, and I had trouble installing the correct libraries and linking them all properly. Somehow, I managed to install and link all the libraries correctly, and some of the prototypes using SDL and OpenGL, I still want to polish into full games today. However, at some point I got a new PC and could never get things linked up correctly since, and I did not have enough time to devote to figuring out why at the time.

Later on during my studies at the MIH Media Lab, the three of us here at Clockwork Acorn (along with other lab colleagues) decided to participate in a hack day our lab was invited to attend. Naturally, we wanted to make a game, and one of the first questions that cropped up was what language and libraries we were going to use. This was where I first encountered Haxe, and we ended up using it along with the NME library. We were all inexperienced with both Haxe, NME, and hack days though, so we ended up with a dismal game, but an admirable respect for both Haxe and NME.

When we next encountered Haxe was when OpenFL had essentially replaced NME, and Clockwork Acorn (as an idea) was already in our sights. The three of us decided to participate in our first game jam together, Ludum Dare 26. We picked up Haxe again in no time, and OpenFL was similar to enough to NME to feel familiar. I was quite impressed with ourselves, that we managed to make quite a decent game (codename Loki) in the three days allotted for our first game jam, and we may yet complete and release the game under the new title Polygone.

Since then, we registered Clockwork Acorn and started our most recent project, Monsters and Medicine, and did not hesitate to use Haxe and OpenFL. Although we kept in mind that we want to release this game on mobile, we’re happy that we can play the game on our phones by simply changing the build command. I highly doubt that we’ll turn away from Haxe and OpenFL any time soon. As with any game library, it is inevitable to run into problems, but in the rare cases that we did we could easily trace the errors down into the code and either fix it or avoid it thanks to both being open source.

Finally, I have to at least mention Unreal Engine and Unity, despite my experience with them being lacking, or even non-existent. Unity is the one that I have tried, and I just ended up not liking it personally. I didn’t manage to dig into the systems enough to feel like I can do exactly what I want to do. That said, I’m constantly impressed with what people make with Unity, and they have to be applauded for how they empower people without a hectic technical background. Unity 4 also compiles to many platforms including windows, mac, linux, android and iOS. Unfortunately I can’t say much about Unreal Engine, since I haven’t used it yet myself. I am tempted to try it out at some point though, after seeing tons of pretty screenshots.

In conclusion, SDL and Allegro both seemed fine in terms of cross-platform development, and might even be better now since I didn’t keep up to date with their changes. It wasn’t until I saw Haxe though, that I considered the possibility of including mobile platforms in the term “cross-platform”, and I’m surprised at how well Haxe works for mobile. I no longer have delusions of whatever library or tool being the “holy grail” of game development, but I do feel that Haxe and OpenFL is about as close to it as we need it to be, although I still want to experiment with Unreal Engine 4.

3 Responses to “How we came to use OpenFL”

  1. Guilherme Medeiros

    Nice post!
    Thanks for sharing your experience with all of us.

    I love programming and I love trying new things, specially things that may give me that special headache, that keeps you thinking about a problem/bug for days until you`ve solved it.
    Right now Im in that spot of “I want to make games”.
    Its a new challenge!
    And for that, I chose Haxe. A new language full of potencial, and targets!

    That said, I`d like to ask you guys to tell me more about your experience.
    Did you use HaxeFlixel? is it that good?
    What about source control? Was it easy working with GIT (Mercurial, SVN, etc)?
    And, finally, what about the quality of the final code produced by Haxe. Is it good enough to understand and debug?

    Thank you for your time, and good luck!

    Reply
    • Hilgard Bell

      Hi Guilherme,

      Always nice to see another person keen to make games.

      We haven’t used HaxeFlixel yet, although we have heard of it. I’ve heard good things about it, and if this is your first foray into game development, it might be a good idea to start with it instead of without. I can’t tell you much more about it unfortunately, we still want to look at it some more ourselves.

      I assume you mean to ask if Haxe specifically conflicts with source control. In that case, we use Mercurial ourselves, and it was pretty simple to work with. Building a project with lime puts all the generated material in an “Export” folder, so as long as you exclude that folder from your repository, there should be no problems between Haxe and any source control.

      We haven’t actually looked at the final code produced by Haxe much, as we haven’t needed to go that deep to debug anything yet. The extent to which we’ve had to debug so far was only so far as to look at the OpenFL source code, and since it’s not generated code it was pretty simple to go through.

      Good luck!

      Reply
      • Guilherme Medeiros

        Thank you for the quick reply and for sharing all this information.
        Its really good to learn with the others and their experience.
        I really appreciate it, thank you!

        Reply

Leave a Comment