I am most excited about lightweight objects and chained accessors, which will make it much easier to work with nested data structures.
Lightweight objects are more like what developers who are used to other languages think of as “objects”. In GameMaker, an “Object” had a number of built-in properties and behaviors, which enabled GameMaker Objects to be used in an intuitive way by users working with GameMaker’s engine. A “Lightweight object” is simply a named instance that can hold data, as defined by the user, without the overhead of GameMaker’s built-in properties and Event handlers. Before Lightweight Objects, developers had little choice but to create a traditional GameMaker Object, and make it invisible and use it to store whatever instance variables the game needed to store “somewhere”. This was suboptimal for performance, as these objects didn’t need to have x, y position, or a sprite, or collision mask, or most of the other features that are built-in by default for a traditional GameMaker object. With a lot of data-holder objects in the game, they could impose a enough unnecessary overhead that it could be detrimental to runtime performance.
If you’ve worked with GML’s data structures, and ever wanted to be able to store a List inside of a Map, well now you can a lot more easily, thanks to chained accessors. This enhancement to GML’s syntax makes it easier to reference a structure stored inside another structure. Previously, it was a pain to manage nested data structures, requiring convoluted syntax and multiple lines of code.
Other new features
GML will also receive Garbage Collection and an Exception handling system. I don’t know that I’ve ever actually needed either of these. I certainly haven’t missed them in my own GameMaker projects. But they are features of most object-oriented languages, and programmers who are used to having these features will appreciate being able to use them in GML now.
Overall, it’s very good to see the GML language adding these language features.
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.
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.
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:
“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.
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.
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 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.
So it’s little over a year since YoYoGames released the public beta for GameMaker Studio 2.
For a lot of the past year, I’ve been sticking with GMS1.4 in order to work on a project that isn’t yet ready to migrate to GMS2, but I’m also trying to use GMS2 when I can, to keep up to date with it and to get used to the changes. Overall, GMS2 is definitely better, and from a language standpoint GML is only slightly different, and what differences they’ve made to the language are all improvements.
On the IDE side, though, I constantly find myself wishing that YYG had made a less radical redesign of the user interface. I’ve had a number of issues with the new UI, from the way the new workspaces and chain-view windows work to the fact that saving works differently. But that’s not what I’m here to talk about today. (I’ll probably touch on those in future articles at some point.)
The default Dark theme for GMS2.
One of the things that I haven’t been able to get used to with GMS2’s new IDE is the new Dark theme. For years, GameMaker has opted for a default IDE theme that uses light text on a dark background, and with GMS2, YoYoGames took this concept to its logical extreme, opting for a black background and white-on-black icons and white label text everywhere.
The default theme for GMS1, GMgreen, was likewise dark.
I didn’t mind the dark grey background of the window panes of GMS1.x, and the resource tree’s pane used black text on a white background, and the code editor’s dark grey background with colorful, syntax-highlighted text, and the toolbas with their colored icons. While it’s not the standard Windows theme colors, it’s usable and reasonably attractive, and if you’re the sort of person who prefers to look at light text on a dark background, it’s quite good.
And to be fair, GMS1’s IDE definitely had its failings. Certain windows were “modal“, meaning that you could not switch focus to any other part of the UI when that window is open, when there was no good reason for them to be. And the user interface for the marketplace My Library had terrible performance-killing bugs with large manifests, which makes it all but useless.
But with GMS2, I feel the Dark theme has gone overboard with being too dark, particularly with the toolbar button icons. Being white-on-black only just makes them harder to read and harder to distinguish from one another, and this slows me down when I try to use GMS2, and this is frustrating, since the whole point of the tool is to make me more productive.
There has also always been a light theme that YoYoGames provides “out of the box” with GameMaker, in case you’re the sort of person who prefers to look at dark text on a white background.
The light theme for GMS2, appeals to users who prefer reading dark text on a light background, but I still prefer something with a bit more color and contrast, and sharper outlines so I can easily differentiate between different parts of the IDE UI.
There are certain colors in the syntax highlighting that contrast poorly against a white background. These should be fixed, but YoYo’s attitude about it seems to be “you can fix it, so fix it yourself.” So they provide preferences that allow you to set the colors yourself if you want to. So, great, you can have exactly the color scheme you want in the code editor, isn’t that wonderful?
The problem with this is, if you want to take screen captures of your IDE and share them with others, your non-standard code highlighting will be apparent to your audience, and may hinder in their ability to parse the text. It’s hardly surprising that we become dependent on the syntax highlighting we see all the time, to the point that once we get used to it, someone else’s color scheme will look “wrong” to us and become more of a hindrance than an assist.
If you want a full makeover for your IDE, you have to go beyond the syntax highlighting colors, and create your own IDE theme. Doing so will give you full control over the appearance of the entire IDE. The downside is that YYG doesn’t support anything but their own themes, so if their themeing templates ever change, breaking your custom theme, you’ll have to fix it. Also, it’s possible that installing updates can either a) overwrite the theme directory, so keep a backup of your theme files. Fun! So instead of spending all your time doing game development, you can take a slice of your time hacking the IDE to do things that arguably the vendor should have gotten right, or at least implemented better so that you wouldn’t have such a temptation. Hopefully this doesn’t happen regularly.
While I like tools that can be customized, I prefer to focus on developing games, not customizing the tools that make games. Too much customizing turns me from a game developer into a game development tool developer. While the skillsets overlap, I really want to maximize the time I put into being a game developer.
Naturally, this has head to some third parties releasing their themes, sharing them with the user community, thus saving you from having to do all the work yourself.
Based on the default Windows theme colors and Microsoft VisualStudio, this custom theme called VS blue, is excellent. Very readable, and easy on the eyes.
I really like this Visual Studio-inspired theme. The missing option that YYG did not provide in addition to their Light and Dark themes was a “native Windows” theme, and this is pretty much that. In fact, I would love it if YoYo would embrace this theme, give the developer who created it, iluvfuz, a reward, and make it an officially supported theme. This would erase 100% of the snarkiness in this article.
It’s very similar to the GM8 theme for GMS1.x, in that it uses mostly system colors for the window chrome. The GM8 theme was my favorite on GMS1.x, so of course the VS blue custom theme is my favorite for GMS2.
The GM8 theme for GMS1.x was my preferred way to theme my IDE, because it mostly followed the Windows standard theme colors.
I’ve been sitting on this suggestion for a while. I raised these concerns on the GameMaker forums some months ago, around the time GMS2 was in beta, or shortly after.
Don’t get me wrong, GameMaker Studio 2 has a much better interface for the Marketplace My Library as compared to GMS1.x, but there are a few things that I would love to see improved with it.
The “New Version” category shows literallyonly those items for which you already have some version downloaded, and for which a newer version is available for download. It does not show items for which you have purchased, but never downloaded before. This makes hunting for newly purchased assets in My Library a HUGE pain. I contend that when you have just purchased something and never have downloaded any version of it before, ANY version that exists at all is a “new version” and thus should show up in the New Version category. Please have everything that is “new” (whether a brand new purchase, or a update to an already-downloaded asset) show up here.
Every time I hit the Download button for an asset in the New Version category, My Library jumps to the All Assets view, then shows the asset being downloaded. Now, if I want to go back and find the next asset in New Version to download it, I have to go and click on the New Version category to go back to it, each time. Again, this is a huge pain — a lot of extra clicking back to the New Version category for each available updated asset that I need to download.
There’s no “Select all”. So when I have all these updates awaiting download, I have to download each of them, one at a time. It would be so much better to check a checkbox to select all available new assets, and then download them all with a single click.
YoYoGames recently announced a new edition of GameMaker Studio 2. Called the “Creator Edition”, it is $40/year subscription.
I’d pointed out earlier in the year that YoYoGames had taken all the necessary steps to make ready to abandon perpetual licensing, and this announcement proves my assessment was right on. See, reddit? I was right.
Permanent subscriptions are still offered starting at $99, although the software license is active only as long as the machine it’s installed on is able to log your YoYo Account in with YYG’s license server. Which is to say, if they want to they can disable your license, and if they go out of business, or if the license server goes down, you won’t be able to use the software.
The cost for these console development modules is $800 for 12 months. Each.
Additionally, customers who purchase a console module must be a registered developer program for the console in question.
Or, for “just” $1500/year, you can subscribe to GMS2.0 Ultimate Edition, which seems to be a response to popular demand to bring back the “Master Collection” package. Ultimate Edition is an “everything and the kitchen sink” bundle that includes any future modules that YYG may release for no additional cost. The price of Ultimate is much higher than the cost for Master Collection , however, and is subscription-based, rather than a perpetual license. GMS1.x Master Collection was originally introduced at a 1-time cost of $500, later $800.
YoYoGames confirmed that the existing modules (Desktop, Mobile, HTML5, UWP) remain a permanent license that you pay for once. However, it’s been YoYoGames’ practice in the past to charge again for the product when it hits the next major release number. Accordingly, YoYo could, if it wanted, release GMS3.0 next year, and charge everyone for an upgrade to that, and drop support/updates for 2.x, effectively forcing everyone to pay for another upgrade at that point. It’s a good bet that at some point they will switch to a subscription-based model at all tiers.
YoYo seem to be pricing themselves out of the market with this announcement. While it’s not unreasonable to charge a premium for the console build targets, the price points announced today do not compare favorably with the competition. Unity3D is also subscription-based, now, but you can get full access to all Unity3D build targets for free, with an income cap of $100K. Game Developers earning revenue over $100K/year from their games must upgrade to Plus or Pro tiers, at $35 or $125/mo — the $125/mo Unity Pro tier matches the cost of GMS2 Ultimate.
The Unity3D IDE is Visual Studio, an industry leader, and the language is C#. By contrast, the GameMaker Studio IDE and GML language are quite limited compared to the capabilities of Visual Studio and C#.
It’s likely that most developers who are in the Microsoft XBox or Sony PlayStation developer programs are already experienced professionals accustomed to professional-quality, industry standard development tools, so it’s hard to see why they would want to take a step down and use GameMaker when they could use Unity3D, or Unreal, or some other tool at less cost. GameMaker Studio 2 Ultimate is priced comparable to Unity Pro, but the capabilities and tools around Unity are much stronger and more flexible.
YoYoGames posted a major, detailed update to their roadmap for GameMaker Studio 2 this morning. Seemingly not an April Fool’s joke.
The announcement contains lots of exciting, long-awaited new features and improvements, but not much detail as yet about when most of these might be forthcoming. And the usual disclaimers that these are plans, not promises.
There’s even more at the link above, but here’s what I think about these in particular: (more…)
I have not yet updated any of my Marketplace assets for GMS2, but I believe that most of them should still work, although they may require the use of compatibility scripts generated by GMS2 on import in order to run in GMS2.
If you happen to have downloaded any of my assets, and find an issue with it, I am easy to reach for technical support.
The best way to reach me would be to send a message through the asset page on the GameMaker Marketplace. My email address is also in the documentation for the asset. And you can also reach me via the Contact page on this website.
YoYoGames have announced in an update to their GameMaker Studio 2 FAQ that the beta for GMS2 for Mac OS X will be coming out in the near future. No exact date has been given yet. But their announcement also mentions that the Mac edition will be available to users of GMS2 who have already purchased a license for the Windows edition, at no extra charge. In other words, purchasing a license will entitle you to run GMS2 on whichever platform you prefer, and you don’t need to decide that at purchase time, and you can change your mind at any time, or even switch between OS X and Windows boxes.
This seems to align with the GMS2 license model, which ties your GMS2 license to your YoYo Account, not your computer.
I think this is great for longtime users who wish to get off of Windows PCs, and are willing to switch to Mac. I only wish that YoYoGames had plans to port GMS2 to Linux, as had briefly been floated back in 2014.