OddBrawlz was the final name of my entry for the TIGSource Sports Compo. Everything I’ve made so far has been for 3-day jams, and usually extremely stripped down. I wanted to do a month-long jam to make something with a little more thought. I’m also not a skilled enough programmer to impress anybody with three days of work. (Yet.)

This was also grand excuse for a crash-course in Construct 2. I’ve been finding Game Maker incredibly dissatisfying; it’s a wonderful program, but it resides in a weird limbo between being a hobbyist’s engine and a programmer’s engine. Most of the drag & drop interface is too simplistic to do anything very complex, but the scripting language requires at least an intermediate understanding of programming. Finding myself somewhere in the middle, Game Maker has always frustrated the bajeezus out of me. I illustrate this concept with the following chart:

I went forward thinking along these lines:

OddBrawlz

After spending a few days banging around Construct tutorials and trying to think of sports-themed projects, the idea for OddBrawlz’s fighting system popped into my head on the train. (Prior to this I was thinking a collection of equestrian versions of Olympic games – Equestrian Pole Vaulting, Equestrian Tennis, Equestrian Pommel Horse – which would have been a nightmare to program.) The idea was that I could treat the numpad as a 3×3 grid, and do a boxing game. I’ve been weirdly fascinated by using the numpad for core gameplay, probably since Oddworld. (The numpad itself didn’t, in the end, actually work.) It would be a weak-point based fighting game. The enemy would attack, show a weak point, and you’d have to punch in the right section of the screen. Non-stupid Quick Time Events. And I’d show off my rotoscoping skills.

For reasons we’ll get to, the finished game is a sort of half-boxing game, half-Tomagotchi.

Scheduling

Last month I was mostly working on my portfolio to re-apply to school. Then I’d spent a few weeks planning a Kickstarter campaign that I finally scrapped, so right before the competition was to start I did something I haven’t done in a very long time: I took a weekend off. Didn’t work, didn’t try to work. I’m not history’s most productive person, but I generally try to do something creative every day, and if I don’t I feel that much more pressure to work the next day. But I gave myself three straight days off.

Turns out I depend on inertia, and it took a lot of effort to get myself back up to speed. The first week was not terribly productive. And then, as things were getting going, Thanksgiving happened, and a friend invited me and m’lady to Wakefield to hang out in a beach house. Which was awesome. But the final 3 days each came with 10-12 solid hours of work, which is a lot for a jam game. I can say that, were it not for Thanksgiving, my scheduled pace would have probably gone alright. So the moral here is: you have no excuse to forget about holidays that are right there on the calendar.

PROStruct

All in all, I think I kinda love Construct 2. Construct is the successor to Multimedia Fusion, in that it you can make fairly complex projects without any code whatsoever. Everything is done by selecting actions off of lists, and I do mean everything. You have the option of scripting things yourself in Python – which is infinitely more user-friendly than Game Maker’s scripting language – but I didn’t have to touch it. The listing was baffling at first when I didn’t know where to look for things, but got the hang of it quickly – the organization is more intuitive than it first appears. Every time it took me a while to figure out where something was nested, I wondered if it had taken me more or less time to look up functions in the GML glossery; I’m guessing Construct saved me time on average.

It is true that there is a satisfaction to writing good code that I don’t get from Construct. It’s also true that I’ve never found that satisfaction very rewarding. The parts of my brain that love game design are different from the parts of my brain that like code, and every time I had to write movement code it felt like I was breaking into a minigame where the character only walks across the room once I do a math problem. It’s not that I’m not geeky enough to like math, it’s just that the math felt so disconnected from movement. I’m envious of programmers that speak a language fluently, but I’m still translating from English, you see. In Construct, pretty much every time I tried to accomplish something, it worked on the first try, intuitively. I felt like, whatever I was doing, it was directly related to making an enemy punch.

I SHOULD MENTION, HOWEVER: this worked well for me probably because I’ve spent two years, off and on, with Game Maker. The tag on Scirra’s website (“make games, effortlessly”) is a total lie – no matter how much Construct simplifies things, you’ll still have to understand programming logic. This is still if-statements and while loops, and you still have to keep a lot of stuff in your head at once. The best you can say for Construct is it makes this more accessible than Game Maker does. So far nothing short of completely visual languages like Twine spare you from keeping a lot of complex shit in your head.

And as long as we’re making comparisons, there are several other things Construct does better than Game Maker. The layout, for starters, it miles more sensible:

Level editor, Projects, Objects, Layers, and Properties, all on one page. Every single one of these is a separate tab in Game Maker, and all your code is stored in bunches of different scripts, objects, and room properties – trying to hunt down just where you left that one bit of code is Game Maker’s biggest headache. In Construct, all your “code” is in one place, and it’s the only other tab in the program:

I could go on – I also love that you access the image editor simply by double-clicking on a sprite, and that the animation and movement speed are measured in frames/pixels per second instead of per-click, which makes it easier to use whole numbers instead of fractions when you want a good ratio between them – but I’ll summarize: from the perspective of someone who knows how coding works but doesn’t love coding for its own sake, Construct is the most fun and easy to use engine I’ve ever put my hands on.

CONStruct

ALL THAT ASIDE: I don’t think I could ever use Construct for a game of any particular substance. There are very real drawbacks.

Let’s get this one out of the way: the free version is extremely limited. Blocks of code are called “Events,” and the free version only allows you 100 of them. At slightly over 12 hours before the deadline, I ran out of Events, and had to start stripping elements out of my design. I had to strip down some of the attacks to fit them into the game, like this one:

Time and event limits also forced me to remove blocking:

The free version of Game Maker allows you to make much larger games without opening your wallet, and there’s a fairly complete version for $25 (though they may start kneecapping the cheap versions now that there’s the $200+ Game Maker Studio). Construct seems designed to keep you from making anything of any real size without paying around $120, which is a lot more than I could contemplate for a jam game.

Then there’s the problem of the final product. Construct is HTML5-based. I’ve tested OddBrawlz on 2 computers and 2 browsers, and and it ran perfectly fine when I tested it in Firefox, but on neither computer does the finished game (hosted by my benevolent friend David) play in Firefox. It starts throwing “unresponsive script” at me shortly after loading, and takes at least 5 minutes to show the first, frozen frame. The game loads quickly and runs properly in Safari, but for some reason the sound doesn’t play, and since everything is done with the games pre-built events, I can’t exactly bug-check that (nor did I have time to). It seems to be playing OK for some other people, but I can’t really control that.

Also, compare any of the animations above with how they look in-game:

Ugh.

When the game was at slightly over 7 megs, it started taking 10 minutes to launch in a browser to test it. This was completely unworkable, and since I was down to the last day, I had to compress all the images to 1/4 the size and then blow them up to 1/2 size in-engine. This bumped up performance, but just look at it! The fact that a 7 megabyte game ends up being too large because it has to be transferred over a network is a real stumbling block. I also note the irony that, had the game been made in Flash (which is how I made the art, and which is supposedly getting replaced by HTML5), these frames would have been rendered as vectors instead of exported as PNGs, and been considerably more space-efficient.

Construct brands itself as being cross-platform – even running in Linux! – but that’s only in browser. You can only make downloadable apps using Awesomium, which warns you is still experimental, and then only for Windows. Within the limitation of running games in-browser, and the wildly variable reliability I’m finding on first go (certain still-popular versions of Internet Explorer don’t yet support HTML5), Construct is not an engine for making a 2-3 hour game, which is a shame, since it’s interface lends itself well to larger-scope projects.

Oh: and the documentation is horrible. If you have an entire section of the manual about how sub-events work that doesn’t say how to make a sub-event, you’re doing it wrong.

Wrap-Up

It’s clear that I can’t use Construct to make the game I want to make, which means I’m back to hunting out a Unity or ActionScript coder for that. Which is a bummer. But I’m still quite happy with Construct for what it is. If you look at the testimonials page on their website, most people praise it as their new favorite prototyping system, and that’s what it’s best for: prototyping. You can bet I’ll be using it extensively in the development of One-Eyed Monsters, especially for making proof-of-concept mockups. And I’ll most certainly be using it for small projects and game jams, as I’m sure with more study I can iron out some of the browser problems.

I can’t really imagine why anyone would pay $120 for the full version, though. I’d like more than 100 Events, but I have to wonder if a game even that large will run efficiently, or even to test efficiently – obviously it would depend on what that code does, but an animation-intensive game like mine chugged at just under 100. Since you can only build downloadable apps for mobile, and, at your own risk, Windows, you can’t make much money off a larger project. AppStore maybe, if you get a devkit, but Awesomium is probably not solid enough to put the game on Steam yet. And I don’t think it’s worth that kind of money just to get an extra 100 Events.

If you do want to build Windows-only apps, you can get the full version of Construct Classic for free, and it’s obviously quite capable – Konjak is using it for The Iconoclasts. It’s not supported anymore, and it doesn’t have much community, but it’s an option available to you.

But I would say that Construct, more than any other engine, fits snugly in that middle-ground between power and accessibility, and for that alone I highly recommend trying it out.

tl;dr

Construct 2 is brilliant for prototyping and small games that probably won’t make you much money unless you’re making the next Canabalt. Don’t part with your money for the full version unless you’re the type for whom $120 comes easily. Cheers.