GameMaker Studio 2 has been out for almost two years now. I have been using GameMaker since version 8.0, in 2010. I loved the direction YoYoGames took with the product when they introduced GameMaker: Studio, and had been an enthusiastic supporter of the tool, looking past its shortcomings.

When the 2.0 beta hit, I had some issues with it, but I wasn’t worried, because it was a beta. There were many long-standing shortcomings and limitations in old GM:S 1.x, and I was used to working around them as best I could. GMS2 represented a new beginning, a complete re-write of the IDE which was to have fixed many long-standing issues, and put YoYoGames into a position where they could deliver new features more rapidly due to a cleaner, more maintainable codebase.

GMS2 was supposed to be the cure for all that ailed me as a hobbyist wannabe indie game developer. Yet, I still generally prefer to work in GMS1.4, despite the many advances that have been introduced in GMS2.

Why?

Put simply, the improvements in GMS2 are eclipsed by some dire showstopping bugs, along with numerous minor gripes.

YoYoGames ended support for GMS1.4 earlier this year, and so its days as a useful tool are short. So, every so often, I try coming back to GMS2 to see if I can work with it. Each time, I’ve found another reason to stay away from it.

For a long time, I’ve been wanting to publish a list of these problems, in order to raise awareness in the hopes that YoYoGames would address the issues and make necessary improvements to their product. I still like GameMaker, and want to be a tool that I can rely on and continue to use. But it’s a lot of different issues, and to properly explain them requires screen captures and video capture that is time consuming to do, so writing this has been something that I’ve repeatedly put off. But, the more I put it off, the more new issues I discover. One would hope that it would be the opposite — that, over time, the issues would become fewer as they are resolved by the vendor.

YoYoGames takes MONTHS to respond to helpdesk inquiries, bug reports

I get that YoYoGames is a relatively small company, with a relatively large number of users. And I also get that a large proportion of those users may be students, non-programmers, or non-professionals who may tax the support department with questions that could have been better handled by reading the manual or going to the community forums. But that doesn’t make me feel any better about the fact that getting a response from the helpdesk when I submit a ticket can take, literally, months. Plural months.

When I have a problem that I can’s solve on my own, and need to submit a ticket with the YYG Helpdesk, the expectation should be that it will be responded to quickly. The exact definition of “quickly” might mean different things to different people, but it most definitely does not mean months, or even weeks.

A few years ago, I might get a response within a couple of days, which was still long enough to be painful. But since GMS2 has been released, it seems to take them several months to respond. I’m sorry, but there’s no way that can be acceptable for a professional user. And to my knowledge, there’s not a premium support option that’s reserved for corporate clients — maybe they do, but if so I have no knowledge of it. But even if that were the case, don’t solo developers deserve and require an acceptable level of support for the product? Of course they do.

Just today (8/8/18 as I’m writing this) I actually got a response to a Helpdesk ticket that I opened up more than a month ago, on 6/22/18, for the IDE crashes when Windows suspends issue that I describe elsewhere in this post. (That wasn’t the first time I’ve reported this issue, only the most recent. The first time would have been in November 2016, when GMS2 was still in its public beta phase.) The response (paraphrased): “Sorry it’s taken us so long to respond, but could you check to see if you’re still experiencing this issue? We’ve released an update since you reported this bug, and will need new log data using the latest version.”

I don’t know why YYG have fallen backwards in this area, but it’s definitely something that they need to improve on.

Other services that I use are able to reply to issues that I submit to them within 24, 48, or 72 hours; among them: itch.io, github, always reply to me quickly, professionally, and in a way that is helpful to resolving my problem. I don’t even pay anything to use itch.io, and they always have responded promptly, because itch understands that making customer support a top priority is paramount to successfully competing in this day and age.

GMS2 projects corrupt themselves when used with version control

To date, most of my experience with GMS2 hasn’t involved any projects that I’ve worked with in version control. I recently decided to start a new project, and wanted to try using GMS2 to make it. I’ve learned the value of version control, and in the last year especially I’ve taken to putting anything and everything that I work on into version control.

In my most recent attempt to work in GMS2, I used git. I created a new repository on github, and started working on my project. After a few hours, I had made several commits. At one point, my program started behaving strangely, so to try to troubleshoot the issue, I exited GMS2, relaunched, and tried to open the project again, only to find that it had become corrupted. No one else worked on this project, it was just me, making commit after commit on a single branch. And somehow GMS2 managed to make a mess of it.

I noticed the problem gradually — at some point, I had a bug in my code that I couldn’t figure out. An object I had placed in my test room wasn’t there. Or it wasn’t drawing. Or it was drawing where it shouldn’t be, somewhere outside of the viewport. I couldn’t figure out why — I only noticed that when I deleted the object and re-added it to my test room, it was offset a great distance from where I dropped it. Why, I couldn’t understand. After messing around with it for almost three hours, I decided to see if exiting GMS2 and restarting it would fix the problem. Instead, the project wouldn’t open.

Aha, corruption! Well, no problem, I’ve been using git after all, I’ll just roll back to the most recent commit, and start over. Losing a little work isn’t great, but sometimes it happens, and version control gives you assurance that you won’t have to throw out more than the most recent commit if something gets messed up. Well… not in this case. Apparently the project corruption was introduced very early into my git commit history, and rolling way back, I still couldn’t open the project. GMS2 gave an error message about a corrupt view. I dug around in the project files, and sure enough there’s a subdirectory called views within the project folder, with a bunch of xml files with weird file names made from long strings of random characters. I found the one that the error message said was corrupt, and tried deleting it, but even after getting rid of the offending view file, GMS2 still couldn’t open up the project. 

At this point, I gave up on the project, it was a total loss of about a day’s work for me. Very demoralizing. I returned to GMS1.4 to build the project there.

After posting about it on the Forums, I learned that this is a known issue that was submitted over 4 months ago, and is marked as a “High” priority bug. A potential solution recommended by the bug reporter involves engineering changes to the GMS2 project format, but doesn’t sound particularly difficult. But as the poster commented, “You cannot invite serious professional use of GMS 2 if it does not work with source control, period.”

I’ll be submitting a bug report on this issue, but again, the pace at which they respond to and resolve these problems means that it’s not going to be of any practical help.

[Update — Fixed]: GMS2 IDE crashes when I suspend Windows

This is another showstopper bug, but it apparently doesn’t affect everyone. Only certain combinations of hardware and operating system appear to be affected, and I’m one of the unlucky ones. I happen to be using Windows 7 Professional 64-bit Edition on a Lenovo ThinkPad P50. When I Sleep or Hibernate Windows, if GMS2 was running when I suspended the machine, it will have crashed upon resumption. At first, the program would report a bug, but now as of a few updates ago, it just crashes without any error message.

When I first reported this bug, GMS2 was still in its public beta phase. YYG responded that they were aware of the issue, but replicating it wasn’t easy for them. I learned that it affects certain hardware and OS combinations, and they couldn’t test for every combination. I can appreciate that, but I did send them application crash logs and would expect that they could use that information to determine what causes the crash, and handle it. YYG Support suggested that I try running any application, such as a game, that uses GPU acceleration, and see what happens when it suspends. I did so, and found that the game I tested survived a suspend-resume without crashing.

It’s really not acceptable that I should have to exit GMS2 whenever I decide that I need to close the lid on my laptop. Any time I forget to do this, and it’s very easy to forget, I risk losing work or a corrupted project. Professional tools need to be more reliable than this.

Update 10/10/2018: 

Almost TWO YEARS later, I finally have a solution to my long-standing problem of GMS2 crashes when I hibernate Windows! If you are having this problem, see here:

YYG Helpdesk issue 145712

TL;DR: Using the opengl driver resolved my issue.

“What I would suggest is trying the software (mesa) driver. It has far less to try and recover from as everything is CPU based. copy ther opengl32.dll from the “C:\Program Files\GameMaker Studio 2\mesa” folder into “C:\Program Files\GameMaker Studio 2″ folder. This may well give you more stable results.”

Only downside is that your IDE won’t have hardware accelerated graphics anymore, as it will use the CPU instead of the graphics card for rendering. This doesn’t seem to be a big deal so far. (edited)

Workspaces are a UX design fail

The GMS2 IDE consists of modular, dockable window components, and this much is good, and I like it. You can arrange and re-size the components as you see fit, which is how it should be.

The main working area within the IDE window is what GMS2 calls Workspaces. The idea of Workspaces was to allow the user to set up the IDE in a way that suits their workflow. I like the idea of Workspaces, but the way they work in practice is awful. Many users have complained on the forums, and it’s impossible to sum up everything that’s wrong with Workspaces succinctly.

Workspaces are just windows, when you get down to it. However, unlike windows in most other application, within the GMS2 Workspace pane, you have an infinite 2D space that can scroll four ways. Within this space are more windows, as many as you happen to open, which float in this space. These windows are your resource editors: object editors, sprite editors, image editors, room editors, whatever. Each one is opened, maximized, and spread out over the vast Workspace plane.

The result: a very space-inefficient design, with lots and lots of scrolling. Scrolling from one resource editor to another. Close an editor window, and it leaves a gap in the Workspace. If you close an Editor, and no other nearby editor is open within the viewpane area of the Workspace, you have no idea what direction you need to scroll in to find the next open editor. You can scroll in the wrong direction literally forever. There’s no purpose for this endless scrolling — it only serves to make Workspaces a pain to navigate, and I can see no excuse for it to work this way. Most windows, when you get to the end of its content, stop scrolling.

Some users have suggested adding a compass or mini-map to the workspace to aid in navigation when you’re scrolling about. But this is an absurd solution to a problem that shouldn’t exist. Rather than a infinite 2D scrolling region of virtual workspace with more windows floating about within it, a tabbed interface would be so much better. Rather than scrolling from editor to editor in a vast 2D space, simply click on the tab for that editor (or use Ctrl+Tab) to flip through the list of open tabs. Each tab could contain a single open resource Editor, maximized to fill the view pane, and thus give the user the most screen area to the task the user is focused on.

YYG have offered various workarounds, but most of them aren’t very good solutions to problems that should not be there in the first place. The Ctrl+T navigational shortcut can be learned, and it does make navigating about the project much speedier and less awkward than scrolling about a Workspace. But this doesn’t fix the awkward mouse navigation so much as replace it. Some users will prefer to use the mouse, for whatever reason, and they should get a better interface for mouse navigation.

I said I liked the idea of Workspaces, but not the implementation. So what’s the idea that I like? Well, I like the idea that the Project could store a view state of specific resources in the project that the user wants to open frequently. Say you have a large project, being worked on by a team, each team member specializing in some feature of the game. The artist may want a Workspace that opens up all the Sprite resources for all the different animations for each character in the game. One programmer might be working extensively on the Player objects, and needs a Workspace that opens the Object and Sprite editors for all the resources having to do with the Player. One programmer might want to configure a Workspace to organize assets needed for creating levels. Etc.

Rather than having to open up these resources manually, one at a time, every time the user opens the project, they could each define a re-useable, sharable Workspace, set up their Workspace(s) that they need (once), and close them when done working for the time being, and return to any Workspace as needed, and be back up and running with just the editors open that are needed for the task at hand. Each user could set up their own Workspace the way that works for them, and return to it whenever they need to do work on the feature that the Workspace was set up to facilitate. Workspaces could be shared across all users of a Project so that they can all benefit from this setup work. And users could ignore any of the previously set-up Workspaces and create a new one, or just open up resources and work on them one at a time, as normal.

Resource Editor Chain View

My complaints about GMS2 Workspaces are made worse by the desgin of the Object Editor. Depending on your monitor resolution, and how the other dockable window regions in the IDE are configured — the Workspace pane is often too small to show a full view of a resource editor. The Object Editor’s “chain view” expands horizontally as you go from the Object’s basic properties, to the Events, to the Code Editor.

There is a solution, and it is simple enough: In the Preferences>Text Editors. Open [scripts|shaders|object events] in a full screen editor.

Chain view could be easier for non-programmers to understand, since the code window is directly linked to the Object Editor. But the layout wastes a lot of space, and creates a scrolling region (the Code Editor) within a scrolling region (the Workspace), which makes for awkward usability, particularly if the Code Editor overflows the Workspace pane, or if you need to scroll the Workspace horizontally to see whichever end of the Object Editor chain you need to look at.

What I want and need is for the editor I’m using to be maximized, to fill out the pane occupied by the Workspace entirely, or to fill the screen entirely. I don’t want resource editors that float about in an infinite 2D scrolling workspace.

There’s a workaround for this as well, which is to pop out the Workspace into its own window, so it can be maximized to fill the entire screen. But this means you lose the other UI components, which are now in another window beneath the Workspace window. You can flip back and forth between the two, and of course this is what you do. But at this point you’ve essentially abandoned the original concept and design of the GMS2 IDE window and workspaces.

GMS2 IDE UI theme doesn’t follow OS standards

For some reason, YYG loves making the IDE as dark as possible. I guess it’s partly due to their branding. Many programmers prefer to look at code with a dark background and light colored text, because this makes the syntax higlighting easiest to read for most people. I do as well.

And some graphic designers prefer their graphics editors to have a completely desaturated interface, so that their perception of color in the image isn’t influenced by nearby colors in the UI. I do, as well. 

GM8 and GMS1 were dark grey, with mostly green accent color. But GMS2 took this even further — too far, in my opinion, making the IDE mostly white on black, with almost no color anywhere.

But I like the window chrome to be not quite so black as YYG have designed their interface, and I like for toolbar icons to be less monochromatic. I find that color helps me recognize the icon I’m looking for. YYG’s UI icons are hard to read, and this slows me down, and makes it harder to enjoy working with the IDE.

This is a relatively minor gripe, and now is largely mitigated by the option of using a custom skin which someone developed that makes GMS2 conform to the default Windows theme colors, giving it a look almost like Microsoft VisualStudio.

However, since custom skins aren’t yet officially supported, any time you update GMS2, the update removes the previous version, and deletes the skin. Then you have to re-install it. And since skinning isn’t officially supported, there’s every possibility that the custom skin you installed today may not work with some future update.

All YYG need to do to make me happy here, is to support alternative skins officially, and allow users to customize their IDE with a skin that won’t break with an update, or need to be reinstalled after an update.

Better would be to offer an official skin that follows the OS desktop theme, and include that among the choices available to the user out of the box.

Better still would be to make this their default, but I just want the choice, and for the choice to be free of inconveniences.

More Issues

The Code Editor

I am a pretty fast typist — 80wpm or better, sometimes as fast as 110 wpm if I’m sharp and fresh. I don’t like to take my hands off the keyboard when I’m doing heavy typing, it ruins my speed.

Many, many years ago, I learned how to use the keyboard to navigate text documents: in nearly every text editor I’ve used, the arrow keys can be combined with Ctrl and Shift to select text rapidly and accurately, and if you’re good at it, you can do it faster than someone with a mouse can do the same thing.

Add to that the Home and End keys, and Page Up and Page Down, and I can grab a block of text, cut/copy it, and paste it where I decide it needed to go, blindingly fast.

Except in the code editor for GMS2. Here, the usual arrow key behavior isn’t quite the same as it is in nearly every other application I’ve ever used. For some inexplicable reason, when I hit the end of a line in GMS2 with my selection, it doesn’t wrap down to the next line if I hit the Right Arrow. It just stops at the end of the line. Why doesn’t it wrap? Instead I have to hit the Down Arrow, but this isn’t the same — instead of the cursor advancing one word, wrapping to the start of the next line, the cursor drops down a line, appearing in the middle of the line wherever the cursor happened to be.

The effect of this is that I can’t quickly or easily select text in the code editor. I select to the end of the line, stall; my mental focus interrupts while my brain processes what happened and I recognize why the text selection is stalled: GMS2 text editor doesn’t work like every other text editor I’ve used. I switch from Right Arrow to Down Arrow, and continue selecting my block of text. Now too much text is selected, and I have to back it up with the Left Arrow for a few keystrokes.

This probably sounds minor, but if you’re a heavy keyboard user doing a lot of cursor navigation with the keyboard, it’s very annoying.

If you’re going to go through all the effort to build your own IDE for a commercial software product intended for professionals, you really need to make the text editor part of the IDE good, and a big part of that is following conventions.

AutoSave is poorly designed

In GMS1, and previous versions, and in most other applications where you make changes to files, Save was a deliberate action. If you didn’t do it, the program didn’t do it for you. If you wanted to close the file without saving, the program would ask if you wanted to discard your changes made during the current session, or save them. This is a long-established convention and is the way the vast majority of software has worked for decades.

Of course, things can happen. Applications and computers crash. Power goes out unexpectedly. About 20 years ago, better programs started to introduce auto-save, which periodically saves any changes made to the file since the last deliberate save was initiated by the user. In the event of an unexpected exit, the autosave file was saved, as a separate file, and on next application launch the user would be alerted to the existence of these files, and have the opportunity to review them to see if they recovered anything that they would have wanted to keep.

This was a great feature. It absolved the user of having to remember to hit save every few seconds as a matter of habit, and relegated the task to the computer. It also didn’t overwrite anything that the user didn’t explicitly want overwritten.

The way GMS2 works is very different. Whatever state your open code file or editor is in, it’s saved. When you close a file, you’re not prompted to save any unsaved changes. Every time you make so much as a keystroke, your file is saved, whether you wanted it saved or not.

If you’ve made some experimental edits that you didn’t want to save, the only thing you can do is Undo, as much as you need to, until the file has been reverted back to the state that you wanted it — if you have enough levels of Undo to go through, and if you can recognize that file state when you get there. Or to pull an old version of the file out of your version control repository.

It’s ridiculous to have to Undo some large number of edits to get back to a prior state, when in the old paradigm, all you had to do is close the editor and say “No” when it asks if you want to save the changes. And it’s not always the case that you’re going to have a check-in for the file in version control.

Further reading

• GMC Forums: Roundtable: Support Crisis for Professional Users
• GMC Forums: IDE UX complaints

YoYoGames announced GameMaker Studio 2.1.5 was released today.

This release focuses on bugfixes and stability, but also adds some very useful new functions:

New Collisions

New collision_*_list() functions that return a list storing the id’s of all instances in collision, not just a single id of the first instance detected. There have been implementations of this in GML scripts since forever, but finally having it in the engine is a great thing, since it will be much faster and available to everyone. The new functions even allow you to sort the list by position order, which is useful in many situations, such as when you need to know which collision would have occurred first in a collision_line situation.

Non-axis-aligned bounding boxes for sprites

This is a new collision type that you can configure in the Sprite properties, “rotated rectangle”. This enables tighter bounding boxes for more accurate collision detection for objects with sprites that rotate, and better performance than using precise collisions, but slower than the regular rectangular collision mask.

Mobile device virtual keyboards

Support for the virtual keyboard in iOS and Android. I’ve never built a mobile app version of any of my GameMaker projects, so I’m surprised to learn that this wasn’t always supported.