Gamemaker 2 has been out for a few weeks, and we’ve all had a decent enough chance to play around. There’s a lot to the engine, and I’m very much an intermediate user whose has learned just enough to make the games I want to make, so I’m by no means across everything. Hopefully my experience with the upgrade can be illuminating for others.
To start off with, Yoyo has copped a bit of flak for putting the last version on sale while working on the new version, knowing they wouldn’t support Gamemaker: Studio once Gamemaker 2 was out. This seems way too harsh to me. Gamemaker: Studio still works just fine, and in the Humble Bundle sale I was able to spend just $15 for the amazing ability to easily create games and export them to almost any platform. How anyone can feel anything but utter gratitude for that is beyond me. End rant.
I ended up popping a few hundred on the new version and modules anyway (their plan worked on me I guess!), because it looked slick and part of the promise was that projects would import smoothly into the new engine. That last part didn’t go so well for me.
For those upgrading and importing old projects, Gamemaker will add compatability scripts to your project to convert all the old functions to the new ways of doing things. These scripts can actually be quite informative, and I spent some time browsing the compatibility scripts added to my game, just learning the new functions and their uses. I did get a bit of a scare, however, when I tried to actually run my game and it was far from functional.
From what I’ve seen on the net, lots of people have had a “plug & play” experience upgrading to Gamemaker 2. It just works, and they can modify their project with new functions at their own pace, or just not do it at all. I’m making a tower defence game with random level generation, and it seems to use a lot of stuff that the new version changes.
At the start of each game, it cycles through the screen, dropping tiles randomly. Not only is the tile system very different in Gamemaker 2, the layers on which tiles sit have also changed. It took me about two nights to get my game up and running again, and it required me to fully get my head around the new tile and layer systems.
Tiles, Layers, and Depth
Layers in the last version were the Wild Wild West. You just altered the “depth” variable of an instance, and new layers were created on the fly, to be deleted when they weren’t being used. Now, layers are named and tightly managed. There are “types” of layers, for instances, tilesets, and whatever else. A layer displaying tiles needs to have a tileset assigned to it.
If you have an object that increases or decreases its depth in code, Gamemaker 2 will create new layers as necessary, and delete them when they’re not being used. But other than that the program wants you to name all of your layers and reference them in code. The idea here is that less layers with less tilemaps will be loaded to run the same thing. It’s more efficient, but it also means more effort on your part to name, organise, and reference your layers.
If your game is actually big enough to make use of the 32,000 layers Gamemaker 2 makes available, you’ll still need to do a hefty amount of optimising to make it run well, but it’ll perform a lot better than it did in the last version. Using the new layer system is no problem at all for me now, but it’d still be nice to have the easy method. My game uses a total of five layers, so to me, the added efficiency is just added work.
The same goes for the tiles. Before, there was an easy “tile_add” function. Now, there are a bunch of commands to set up a layer, tileset, tilemap, and then start laying tiles, which is all a much more efficient way of doing things on the rendering side, but on the coding side, not so much.
The best example I’ve seen of this is in isometric games where moving towards the bottom of the screen brings you closer to the camera. Before, all your problems were solved with this one little piece of code:
depth = -y;
You can still kind of use that code, but it doesn’t really have the desired effect. To do it properly is a lot more complicated now. Again, it’s great that this system exists, which will result in much more efficient games in some cases, but for those making smaller games, it’d be nice to have the simple option.
One of the more efficient things you can do is get an object to check for collisions against a layer’s tilemap, which works out to be a lot faster than checking for other objects. Another nifty thing this allows you to do is arrange your tileset in a predefined way, and in the room editor you can just hold the mouse button down and paint tiles onto your room as if they were a brush. It’s really nice. Have a look:
I’m unable to use it unfortunately, because there’s currently no way to make that work in code, meaning games with random level generation or proc gen will have to wait until Yoyo adds that feature.
It’s a fair criticism that you could look at the feature list of Gamemaker 2 and think, “there’s really nothing there I can’t do already in code”. You’d be mostly right, and in fact, some things are harder. Tiles can also be animated now though. Great for backgrounds and large seascapes.
Perhaps one thing you couldn’t do before involves the new camera system, which you can use to point the camera at an angle to the play space. Here’s a nice video explaining it. I can’t envision using it in my games for the foreseeable future, but I’m sure some people will get creative with it.
GameMaker Language is largely the same, with some upgrades to the IDE to make prettier words, and macros to save you typing time. Variables will autocomplete as you type them now, and the colour-coding is more intelligent — though you can change the theme if you don’t like it.
If you forget to reset the draw alpha or colour at the end of the draw event, it’ll no longer break everything visually, which is nice. Sprites can also be created in code now without needing to be attached to an instance.
Bit shifting also makes an appearance, which you can see in the above example on tilemap-based collisions. It’s something I’ve always been intimidated by, but the latest few tutorials from experienced users getting into Gamemaker 2 have me keen to give it a go.
Drag n’ Drop
I’ll be honest, I never use it, and I mostly view drag n’ drop coding as a means of luring people into Gamemaker before eventually springing the fact on them that they’ll have to script to make the game they really want to make. I suppose you can mix and match the scripting and drag n’ drop elements to your liking, which is good for newer users. And occasionally I’ll be on the Gamemaker forums and see an advanced user post some Iliad-level code and think “wow, that’s a bit much for my level…” But in my experience, there’s nothing like driving manual.
The TLDR here is Drag n’ Drop has supposedly improved, and I believe it, but I won’t spend time on it.
They’re pretty. I actually think I get less done using the super-schmick layout of connected windows that you can see in every Gamemaker 2 trailer, but it’s a pleasure to work in. Once I’m over the novelty of it, I’ll probably just full-screen everything. I do have a second monitor though, and the new layouts make better use of that. There’s a lot of customisability here, and so far I’ve enjoyed having my console running on my 2nd monitor while I test my game, watching my debug messages pop up in a more visible manner.
You can also change around how your resource tree is structured, and I think there’s no way you won’t run out of space, but everything is searchable and movable.
The image editor now has layers, bringing it more in line with image editors that people use because they’re useful. I feel a lot more comfortable making actual, complex sprites in the app now. It’s still not Photoshop, but there are a lot of nice features you’d want like animation previews, blending modes, and editing while cycling through a sprite’s different frames. Often I’d be surprised by it doing exactly what I wanted, such as automatically making a brush out of the space I’d just copied to the clipboard — handy for making big tilesets and spritesheets. I’m no artist, but this section was a definite win for me.
There are lots of quality of life improvements on the room editor, such as making everything zoomable and pannable, being able to make layers invisible, and the ability to paint large amounts of tiles at once with “tile brushes”.
The biggest one for me here is room inheritance, where you can have a parent/child situation with rooms, just as you would with objects. This could be a massive boon for people working on games with lots and lots of rooms with similar rules, like RPGs. I have no use of it in my game which basically creates levels in code right at the start, but I can imagine a time in the future when this feature will seem straight from heaven.
A lot of people look at the new version and ask “So what does it let me do that I can’t do already?”, for which there really isn’t a strong answer. It does make a lot of things easier, and some things are even harder in the name of efficiency, but overall it’s absolutely a net win for usability and saving time.
It took me two nights to get my head around the tile and layer systems as someone who knows Gamemaker fairly well, but the myriad improvements to the IDE, debugging, layouts, and more are tiny time savers that are bound to add up. On top of that, it feels a lot better to work in.
I haven’t started exporting yet, so I’m hoping I don’t encounter any snags, but judging by the number of people who’ve said the transition was smooth sailing, I think it’ll be fine. Crucially, for anyone wanting to pick it up for the first time, the library of community-created guides and videos is still relevant.
It’s a thumbs up from me.