GameMaker and Why I Chose It

Posted by
November 29th, 2013 12:58 pm

Ah, it’s good to be doing a Dare again, even if this is just a mini-Dare.

Since my first LD, which was completed using Visual Batari Basic in order to create a game that runs natively on the Atari 2600, I’ve been experimenting with various engines and frameworks, including Construct 2, Loom, OpenFL/HaxePunk, LOVE, and, most recently, GameMaker.

I tried learning each of these engines by re-creating a Pony-clone of Tapper that a friend of mine made, since he gave me the already-made assets to ease development. Although progress has been slow because I’m sick of re-making the same game over and over, my experience with the engines was as follows:

Construct 2: Although I felt a bit patronized by the drag-and-drop coding interface, it did help to simplify the coding. In the end, I built in all the core functionality, but lost interest with Construct 2 when I attempted to export my game to mobile. Unlike Loom, OpenFL, and GameMaker, there is no direct push to mobile option, and instead I was just given a folder of assets that I’d need to manually compile using Cocoon Launcher… which never worked for me.

So I gave up on C2 pretty fast, though I can see the appeal of it for beginners who are looking to make games on Windows/Mac/Linux or HTML5. It compiled to those platforms very easily.

Loom: This engine was recommended by one of my game professors, as it’s a relatively new engine that is built for rapid app development, which is great because I was looking to make the game on mobile. The down-side is that the documentation for Loom is very sparse. For those familiar with ActionScript 3, LoomScript is heavily based on it, so I’m sure it would be a snap.

Unfortunately, I don’t know ActionScript 3, so I found it very frustrating to learn a language from scratch with little more than a handful of basic, outdated examples and an outdated API (because LoomScript is updating so quickly, much of the documentation is out of date). It was very good at live development on mobile, though. I just never got beyond building my game’s title screen.

OpenFL/HaxePunk: Initially, I was excited for this, as I saw it as an alternative to Loom. It’s a much more mature engine with better documentation and, while it doesn’t have live update like Loom does, it pushes to mobile just fine. Unfortunately, the language barrier of me not knowing ActionScript 3 again became an issue when I began to hit the limits of the tutorials and examples.

Unlike Construct 2 and Loom, HaxePunk can boast Papers, Please as a commercial product created using it. Once again, I didn’t get far beyond building a title screen before moving on to something else. As with Loom, I’d recommend it for those who are already familiar with making games in Flash, as I’m sure it’ll be fairly easy to pick up.

LOVE: This was my first time trying to program in Lua. Prior to this, my programming experience was only with C and a tiny bit of C++ (which I am currently taking a college course on). I immediately liked Lua’s dynamically-typed language and the flexibility of it. Tables are awesome! The only issue is that LOVE itself is very much a framework. I think it would be perfect for certain kinds of games, or for those who have experience with Lua. I, being a newbie to the language, had to rely heavily on plug-ins and additional frameworks to support animated sprites, object-oriented classes, and collision detection, which the engine does not come pre-packaged with (not completely true, as it does come with Box2D, but I didn’t require that level of a physics engine).

I got most of the framework of my Tapper clone built in Lua, but I was already nearing 650 lines of code by that point, just having laid the foundation for the game itself, but with no actual gameplay or levels implemented. On top of all that, LOVE does not have native support for HTML5 or mobile, and the plug-in support for both those platforms has been halted for at least a couple years.

In the end, I enjoyed LOVE, but I found making a game of this type from the ground-up to be frustrating. I think that I will return to LOVE if I ever have a game intended for desktop platforms that doesn’t rely much on object-oriented, but not until then.

GameMaker: It’s ironic that GameMaker was the first engine that I was ever introduced to, and yet the last I came back to. I never really did any programming to speak of (unless you count one mandatory C course and HTML/CSS) until I had an interest sparked by last year’s Game Jam. I wasn’t on as a programmer, but an artist (more because I knew nothing about programming, rather than because I was particularly adept at art). The game that I will be remaking, Heartbreak, was more one that I designed, rather than “made” per se, but it’s still the first (and only, unless you count Atari 2600 mini-games) original game that I’ve made, so it will be my focus of this Mini-Dare.

When I first designed Heartbreak for the 2013 Game Jam, I had a couple “programmers” who claimed to be decent in GameMaker. The first day of the Game Jam consisted of me designing the game’s mechanics in my head while I worked on simple (very simple) pixel art to build the game in GameMaker. I knew nothing of the engine at the time, but after an entire day of the programmers surfing the web and allegedly looking up tutorials, they claimed that the game simply could not be made in GameMaker. Since I had no experience with the engine, I was frustrated by this news. Luckily for me, another programmer stepped into the group at the eleventh hour to make the game in Unity.

With my sense of GameMaker having “failed” me, I begrudgingly avoided it as a useless prototyping tool that couldn’t make anything really “serious.” After trying all these other engines and frameworks, I find myself crawling back to GameMaker like the prodigal son. I’m aware that it still has problems, such as being very inefficient with its resources (according to the bitter folks over at the #GMC GameMaker IRC room), but I can’t sneeze at an engine that has been used to make awesome games like Spelunky, Hotline Miami, and, most recently, Hyper Light Drifter. If it’s good enough for games like that, it’s good enough for me.

In giving GameMaker a chance (I’ve been fiddling in it for about a week or two, whenever I can muster up the energy to go back to the Tapper clone that I’ve remade so many times, I hate its guts), I’m immediately drawn to how much it simplifies the organization of game code. I feel like I’m scripting more than “programming” per se… and I like it.

GML is very similar to C and it hides the annoying Java/ActionScript 3-inspired object oriented faffing that I had to deal with in Loom or OpenFL. Code is organized into easily-managed blocks within objects that are called from basic events, keeping it nicely organized into manageable scripts rather than giving me a 600-line file of code to just lay the groundwork for things. On top of all that, it has tons of tutorials, plug-ins, and shaders available online, AND it can push to mobile with the press of a button (if you have the Pro version, like I do).

I know that it’s not an end-all solution, but I think that it’s a great place to start, and even though I’ve only actually programmed in it for a whopping total of 10 or 12 hours at the most, I feel confident enough to try remaking Heartbreak in it, which is more than I can say for any of the other afore-mentioned engines and frameworks, aside from maybe Construct 2. The downside of C2, though, is the entire lack of the ability to write code. It forces the user to rely on its drag-and-drop system which, while powerful enough for basic game types, takes a lot longer than just writing raw code, lacks a lot of the flexibility of plain code, and it’s a pain to organize once the event sheet starts to get long.

I’m sure that someone with more programming experience will look down my choice of GameMaker, but I’ll say that I’ve only actually been programming for about six to nine months, and most of that was in a non-object-oriented language. The entirety of my non-Assembly/BASIC programming experience has come in the past two months, or so. I have to start somewhere.

Although this post was long-winded, I hope that some find it interesting or helpful in their own selection of an engine. Now to write a post about Heartbreak and why I am remaking it. Maybe after all this blogging, I’ll even have a little time left to make a game. Maybe.

Tags: , , , ,


14 Responses to “GameMaker and Why I Chose It”

  1. Photon says:

    Who’s going to look down on you for using Gamemaker? Ignore them. Use what works. If it gets the job done, then who’s complaining? I’m the kind of guy who likes some down-and-dirty coding, but ultimately its about whether you can get the desired end-result, no? It’s why I ended up using Stencyl for awhile.

    Besides, I seem to recall a GameMaker entry in a previous LudumDare placing in the top 10…

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]