Professional developer’s look at GameMaker
It’s no secret that most of MoaCube’s projects are developed in GameMaker. I’ve been using it for 7 years now. Sometimes simply to play around with ideas, but mostly for commercial projects and some rapid prototyping back during my days at Codeminion.
I’ve developed a certain love-hate relationship with the software. We’ve had some good times together, but there were times when I considered filling divorce papers and turned my head after the younger and sexier Unity. So far, we decided to stay together. For the kids’ sake, you know.
GameMaker is a rather popular tool among amateur and freeware developers, but you rarely see it used to produce commercial-quality games, so there aren’t many publications on how it fares in professional game development.
With YoYo Games trying to attract more serious developers with the release of GM HTML5 and the upcoming GM Studio, I thought it could be interesting to do a little rundown of the good and the bad in the software from the perspective of someone trying to utilize it for commercial work.
Fast development: This was always the main advantage of GameMaker and other similar tools for me. You can develop damn fast in it. During the DBC game jams I was able to create working projects in only a couple of hours. Working as in: fully playable, with complete mechanics and already looking somewhat pretty. At Codeminion, I sometimes found it faster to show the programmer what I want using a GameMaker prototype, than to describe it and go through several feedback loops.
Being able to develop fast is crucial when you have to worry about budgets and deadlines. Of course, a skilled C++ programmer can work similarly fast in a good framework. But — well — you need to pay that programmer and spend months on developing the framework first. GM saves a lot of time and money here.
It’s very flexible and pretty capable: Think about any 2D game you like. You could probably do it in GameMaker. It’s a huge advantage over the more focused game creation tools like Ren’Py or RPG Maker. Even custom-built engines are usually done to meet needs of a particular game or genre.
Meanwhile, GM can be used to make arcade shooters, complex RTS, platformers, visual novels or any experimental game you have on your mind. Not having to learn new tools for each project saves a lot of time.
Performance is a-okay: I often hear that GM’s performance is its biggest issue. Well, hardly (as you will see later). It’s more than capable for most 2D projects. Of course, if you want to make something very technically-advanced, you probably would be better off writing your own engine. But let’s be honest — most commercial 2D games don’t need to be cutting-edge. You generally want them to work on older machines, as it’s a big chunk of the indie audience. Nice art is usually more important than pure tech-prowess here.
I consider ArcMagi and Cinders to be relatively pretty games, with plenty of effects, particles, cool transitions and such. They both easily maintain 60fps, even on netbooks or older hardware. I never really felt like I have to cut something cool out to prevent framerate drops.
I think part of the problem is that GM is very simple to use and it’s tempting to be lazy. It’s easy to just include all the art assets within the project, draw them all on the screen with tons of particles and then complain that it slows down and uses too much RAM.
Most of the slowdowns can be solved with simple optimisations and more responsible memory use. Which is something you have to consider in any commercial game, regardless of the engine. I assure you that when I was working on Phantasmat, using a much faster custom-built engine, I still couldn’t slap everything I wanted on the screen without any considerations for the lower-end hardware.
It’s cheap: Just that. It’s cheaper than pretty much any other commercially-viable engine. It doesn’t matter that much when you have budgets in the tens or hundreds of thousands, but for a small indie developer, paying over thousand bucks for Unity and a few plugins, just to try it out, may be a big deal.
It’s easy to learn: GM was designed as a teaching tool and it shows. It’s pretty easy to grasp, syntax rules are very leeway, documentation isn’t written in Klingon and there are many tutorials available. It’s something even an artist without former programming experience can pick up and use. It allows for more participation from your non-techy team members, which is a big advantage in small teams. And let’s not forget that time used to learn new tools is development time as well.
Predictable: Except for a few hurdles I’m going to list in the next section, GameMaker is pretty predictable. It’s been around since quite a while and it uses pretty low-end tech. If it works for you, it’s probably going to work for your clients as well. If it doesn’t, you can assume it’s your and not the engine’s fault with a good degree of certainty. Depending on the complexity of the project, this can shave off a few weeks or months of QA work.
Good multi-platform prospects: HTML5 exporter is already out. iOS, Android and a few others are coming later this year. Many games have been internally ported to iOS by YoYo Games already. Even given that it will likely have some troubles at start, it looks like the tool is going to get even more universal.
Lack of competition: There simply aren’t many alternatives. Coding your own engine can be superior but takes precious development time. Lots of it! Tools like Ren’py or RPG Maker focus only on a certain type of games. Construct, Stencyl and MMF2 all use visual coding that gets very hard to debug and read as the project grows. And using Unity to make a 2D game is like trimming a bonsai tree with a chainsaw.
GameMaker may not be perfect (oh, believe me, it’s so not), but it’s still likely the best rapid 2D game development tool around.
Bad first impression: To get GameMaker, you have to go to the YoYo Games’ website. It looks like poop. Then you download the software, boot it up, and hey — a big shocker — it looks like poop too! Gotta love that Windows95 feel!
It’s superfluous but it scares many developers and makes them waive GM as a kids’ tool. It’s not (at least not exlusively), but it certainly doesn’t make the best first impression.
Mac versions sucks like an atom-powered Dyson: No, really. It’s b-b-bad! First of all, it’s based on the GM7.0 while the Windows one is v8.1. This means that compatibility goes only one way. If you have a project in v8.0+ you can pretty much forget about porting it to the OS X. And it’s not even the biggest issue here.
Initially, it just didn’t work. As in: it was impossible to make a game in it. It crashed on every other function call, it was impossible to load a sprite with transparency, and drawing more than three lines of text was enough to slow the game down to a crawl. To be able to work on Cinders and release Magi on the Mac, we essentially had to do few days worth of QA work for YoYo Games. Got in contact with the developer, filled several bug reports, added better reproduction steps and examples to the bugs reported by other users, and so on.
It became usable eventually, but it still has more flaws than it’s worth to count. The interface falls apart, code editor has a mind of its own, and don’t ever count on error reporting to tell you what caused a crash if one happens. It’s just going to freeze or produce a bogus error message. If you know your way around GM with your eyes closed, you’ll manage. But if your first experience with the tool is on the Mac, I pity you.
It’s worth noting that the upcoming GM Studio will have an option to export to Mac and should be free of these issues. However, it’s going to be Windows only. If you ever tried to debug a game’s port without being able to work on the computer you’re making it for, then you know what that means.
True multi-platform development is said to come with GM9. ETA: chances are that if you look outside of your window when it comes out, you’ll see this.
Issues with fullscreen on Windows7: For some reason, GM gets lazy on Windows7 and doesn’t want to use interpolation for scaled image. It defaults to a basic nearest-pixel algorithm instead. It looks like this.
Why is it important? Because it happens when you run the game in fullscreen and it has to be scaled to fit the screen (you can’t possibly support every existing resolution natively). Most engines produce a slightly blurry, but overall workable image in this case. So does GM, unless the user runs Windows7 (hardly a niche).
Now, imagine you are making a casual game to sell on BigFish Games. Something GM is theoretically perfect for. You finish the game, it gets initially accepted and you receive their tech requirements doc. One of the first points is: “The game has to open and run properly in fullscreen”. Have fun.
Sprite loading issues in GM8.1: Oh, this one! Still sends shivers down my spine. Some of the Cinders pre-order owners probably remember it. Soon after the preview version launch, a large portion of users reported that the game crashes during scene loading. After some investigation, we figured that it happens on older computers, lower-end notebooks and netbooks with integrated video cards. So, about 20%-30% of our userbase. Scary.
We’ve spent two days and nights trying to reproduce and fix the issue. I pretty much haven’t slept for that whole time. After all, folks paid for a game that wasn’t working. Thank goodness it happened during the beta and not the official launch — that would screw us over completely. Eventually, Marius was able to find an old PC that had the error. After another day of testing and desperately trying to find the reason behind the crash, driven by a hunch, I decided to compile the game under GM8.0 instead of GM8.1 and see what happens. It worked!
Turns out that GM8.1 likes to crash on weaker PCs when loading larger textures. Something that probably won’t happen when you are just playing around, but is commonplace in bigger projects. It took a few weeks of bothering Russell Kay (one of GM’s programmers, a very cool and supportive fellow by the way) to get it fixed. Now it doesn’t crash, but instead produces weird graphical glitches and major slowdowns on the affected PCs. Cool, huh?
In the end, I have to use GM8.0 for all my PC releases (good thing that I kept the older version), even though I paid for GM8.1. The problem is that GM8.0 has some issues with font anti-aliasing that were fixed in 8.1 Argh!
Awkward dev schedule: You would think that the above two issues are pretty significant, and should be fixed as soon as possible. After all, loading assets and pixel interpolation can be considered core functionality.
Well, as of now, GM8.1 hasen’t been updated since several months and the programmers are focused on GM Studio and HTML5, both unfortunately based on the broken GM8.1 codebase. The fullscreen issue in particular was waived as something to fix in GM9.
It has to be said that both programmers working on GameMaker seem to be very competent and smart people. But one can’t stop wondering if they aren’t mismanaged. Focusing on new releases, while the core product is still kinda shaky, seems like a weird strategy to attract more serious developers.
Built-in editors are bad: GameMaker utilizes various built in editors for art assets and level design. They are all pretty unwieldy. It never bothered us much, as we just use normal graphics software for the art and our own solutions for level building, but it’s worth mentioning that you can’t expect to make much use of what’s already there. It’s possible to drag some objects around and make a simple game, but a larger commercial project — not so much.
Lack of portability: I said that publicly available exporters for Mac, iOS and Android are coming soon. It means they aren’t available now.
That is unless you want to go through a pretty unfavorable deal with YoYo Games (50% royalties, exclusivity, they are listed as the developer, some negotiations possible) to get your title ported. The fact that the multi-platform GM Studio is going to be based on the faulty GM8.1 also doesn’t bode well for the program’s reliability.
In general, if you consider smartphones to be an important part of your business model, I would say that using GM is too risky. At least for now.
Teamwork on GM is hard: GameMaker uses a single file for its projects. This means that co-operation with several team members and version control are a pain in the ass. GameMaker HTML5 and the upcoming GM Studio are going to store projects as a folder structure (much like Unity) so the issue is temporary.
Uncertain future: Being honest, GM is getting more and more outdated, while tools like Unity or Stencyl are getting progressively better. Latest GM releases also weren’t too reassuring, especially the Mac version. YoYo Games struggles to become profitable and focuses more and more on game publishing. It’s hard to predict what will happen to the software in a few years. It has great potential for sure, but I prefer to be cautiously pessimistic.
So, is GameMaker worth recommendation? For amateur or more lightweight indie — for sure. It’s fast and easy to use, and its issues don’t affect smaller games that much.
For commercial projects? Not yet, unfortunately, unless you really know what you are doing and can live with the problems. It’s fast, flexible, and powerful enough, but you risk that one of its quirks will bite you in the ass at the end of a project. And you can’t really count on it being fixed fast.
Using us as an example, we’re happy that we picked GM for Magi, ArcMagi and Cinders. All three games work as intended without making any sacrifices, look rather pretty, were fast to code and can be easily expanded or altered. We’re especially happy with what we’ve got in Cinders. A pretty flexible visual novel engine, similar to Ren’py, but able to produce much nicer graphics, with the possibility to expand it easily with more gameplay elements. And it took less than three months to code from scratch.
We definitely see ourselves using GM for some of our future projects, especially VNs and the more experimental stuff. However, we recently pitched one of our game ideas to a few friendly companies, to secure MoaCube’s stability undermined by the Cinders delay. A bigger game, requiring at least $100k to make. We strongly considered doing it in GameMaker. It seemed perfect for the job, but we eventually decided that it’s too risky and opted to license an engine from an established game developer.
Let me reiterate: when faced with the responsibility of having to spend actual money that isn’t ours, we concluded that using a completely new engine is less risky than working in software I’ve been using for the past 7 years. It made me think. You should consider it too.
GameMaker is a tool with much promise, and may well become a viable choice eventually, but it needs more time and better handling from YoYo Games. They could probably use some constructive feedback that’s not just straight hate, so if you are a professional indie developer, consider getting in touch with them and let them know what bothers you about the software and what improvements would be crucial for you to consider using it. The guys there really wish well and deserve the chance.
If you liked this article and would like to know what we’re up to, please consider following me on twitter. Thanks!
UPDATE: I’ve noticed that this post is still getting a lot of traffic from people looking up GameMaker Studio. Since the article was written before it was out, here’s a small update.
Studio fixes many of the issues I’m mentioning in the review. The annoying problems, like the troubles with the fullscreen mode are gone, teamwork is possible, and it’s properly multi-platform now. It still makes a bad first impression though, and while the built-in editors are better, they are still far behind Unity and other engines.
For me, the main problems of GMS are the lack of Mac version (you can port to Mac, but you can’t work on it) and overall bugginess. The tool is relatively early in the development and updates with bug fixes often introduce new problems. Some can be really scary. There were also cases of the built-in scripting language changing between versions, which can be deeply frustrating mid-project. It’s getting better, though. In another few months, it may stop being an issue.
In general, I hold to my former opinion. GameMaker is a good tool. Even better now that Studio is out. I can easily recommend it to indie studios working on small to mid-sized 2D projects. I would still think twice before deciding to use it for a larger game or when working with investor’s money.