There’s been a lot of news coming out of YoYoGames lately about the upcoming release of GameMaker Studio 1.3. They’re delivering a lot of new features that have me excited.
From the official roadmap:
Version 1.3
Debugger
Rewrite of the GameMaker debugger to include full source level debugging, break points and watch windows. Will also target cross platform support, allowing remote debugging of Mac, Android and iOS devices.
I really like that they’re delivering an improved debugger with breakpoints and watched variables. This is something that is frankly long overdue, the functionality that was provided in the current debugger would be considered barely adequate compared to what’s been offered in other IDEs for at least the last 10-15 years.
On the other hand, I credit the lack of a decent debugger in GameMaker for making me a better programmer by teaching me not to over-rely on a step-through debugger to understand my code.
Because I lacked a proper debugger, I learned to build myself a logging system. Because I lacked watch variables, I learned to draw the values of variables I wanted to read to the screen, next to the instance.
It turns out, when you have a game with a lot of objects, all of which are updated in a loop that runs at 30 iterations per second, stepping through your code to see what’s going on must be extremely slow and tedious. I am not sure how much use I’ll get out of a debugger — I’m sure there’s times where it’ll still come in handy for me, but for me, logging and drawing variable state to the screen so I can continue to run the game at realtime and see what’s going on faster will likely be more valuable to me.
One highly valuable programmer’s tool that I’d love to see added to GameMaker Studio in the future is unit testing. Programming benefits from unit testing by proving that existing functionality still works as intended when new code is added or existing code is modified. It can accelerate development by reducing the time it takes to find bugs, immediately identify when they are introduced, understand the scope of their effect, and so on. I don’t believe that unit testing can help prove whether a game design is fun, but it is very valuable to proving that code is correct. I’d rather spend my time in GameMaker playing with design experiments, not trying to figure out why something I coded doesn’t quite work like I thought it should, and if I could write unit tests for my GML code and use them, that would be a huge win.
Extensions
Windows and HTML5 already allow custom extensions, so this will add them to iOS and Android.
As I understand it from what I’ve read elsewhere, this means native code extensions. So far, I’ve done a little bit of work in creating extensions for my projects, and all of that has been done in GML, at first because that was the only thing I was comfortable writing them in, and then later because I wanted my extensions to be usable no matter what platform I was targeting. Being able to write extensions in other platforms that are native to the platform will mean substantial performance boosts, and the capability of leveraging existing code libraries, and potentially even entire engines or frameworks. This is great because it means a lot of existing functions are soon to become available to GM:S projects, and won’t require a lot of re-invention of the wheel. Instead, developers can just glue existing wheels written in other languages onto their GM:S projects.
The only downside to this is that I fear this will turn into an excuse not to implement language features in GML, when it comes to future development of the GML language and the GameMaker framework. “Why bother implementing [requested feature], it already exists in [other language], so just go install [some extension] or learn [other language] and implement the extension yourself!” may become a frequent response to feature requests and criticism of GM:S.
One of the really nice things about GameMaker was that it was a small, simple, self-contained language. As well, non-GML extensions have not historically had full access to the GameMaker runtime engine, meaning that in essence when you made a call to a native-code .dll extension, you were passing some data values out of GameMaker into the .dll, which would only know of those values, and it would do whatever it did, and return a value back to GameMaker, which you could then do something with. This scope boundary made native extensions a bit more difficult to work with, and a bit more clunky as well, and as such I tend not to use them.
As we’ve seen with the newly-added features such as source control, Box2D physics, and shaders, GM:S has for some time now been bolting on more and more stuff in order to quickly deliver features it has historically lacked, which are already familiar to experienced programmers and really don’t need to be re-invented. But this means that non-programmer game designers will have to stretch themselves increasingly further in order to gain mastery over these new features.
Much as web development in the mid-90’s was all about learning HTML, which was dead simple and easy to learn in no time, and then later along came CSS and Javascript, and SQL, and backend scripting languages like Perl, PHP, and ASP, which made things increasingly complex and difficult to learn, and then specialized Javascript libraries and frameworks like Rails, I see the same thing happening with GM:S — a tool that was once very simple to pick up and learn is growing more capable at the cost of increasing complexity, sacrificing ease of use.
True Type Fonts
The ability to add True Type Fonts to your game from an external file and support for non-roman alphabet languages.
This is a nice thing to see. It’s a little bit hard to feel truly excited about fonts, but TrueType support is another one of those things that is long overdue and will make GM:S feel no-longer antiquated in its typeface options.
Simple Flash Asset Importer
Allow importing of certain Flash assets directly, including things like vector images, and PSD files.
I never did get into Flash, so this isn’t especially important to me, but it will allow vector sprites and therefore resolution independence, which is pretty awesome.
Spine Animation Importer
Allow importing of animations created using Spine.
2D Animation runtime
Visualize in GameMaker any assets imported from Flash or Spine.
I haven’t used Spine, but it sounds a lot like the Spriter project, which I helped fund the kickstarter project for. So, hopefully this doesn’t mean that GameMaker won’t support Spriter in favor of Spine — one of the Spriter project’s stretch goals was support for GameMaker, and I still would like to see that delivered.
Push Notifications
Will permit you to use push notifications to inform the user of things on iOS and Android.
Mobage
Integration of the Mobage SDK will permit you to use their social gaming network in your games.
These last two are of special interest to developers targeting mobile platforms and social networks, which is pretty much everyone these days who wants to make money doing independent game development.
Early Access Builds
This is a very big deal for me. To date, GM:S has offered two update channels: Beta (for the latest builds), and Stable (for more well-tested builds) — but only one installation. So you had to decide whether you wanted to get the latest release and risk bugs, or the stable channel with its slower delivery of cool new features. Now, however, they’ve changed the way this works, so that the “Early Access Build” can be installed adjacent to a stable release, allowing the developer to play and experiment and learn the newest features before they’re ready for official integration, and not have to give up having a stable IDE for serious work. I’ve been burned at times by trying to use features that weren’t ready yet, and now I feel like I can safely do that without being punished by project-breaking bugs from the beta channel.