YoYoGames: Major GameMaker roadmap announcement

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:

IDE

• Code Folding

  This is a feature that has been asked for frequently in the forums. It won’t do anything to make GMS games any better, but will make long scripts easier to navigate, I guess. The thing is, why are you writing such long scripts? I’m glad they’re including this feature, but it’s really not as big a deal as I’m sure a lot of people who’ve been wishing for it think.

• Personal Asset Library – quick access for personal code snippets, assets, extensions etc

  I will make use of this a lot. I like writing code that I can re-use in other projects, and this will allow me to do so more easily.

• Quick 47 Tile Tilemap generation from a simple 5 tile

  Big labor savings. From playing around with 47-tile auto-tiling, it seems like a tedious, time-consuming process to come up with titlesets, particularly if they are animated. Reducing the amount of work needed from 47 to 5 is going to be a major labor savor.

• Minimap – Workspace and Room Editor

  Workspaces are giving many users a headache when it comes to navigating them. Adding a minimap should help, but my feeling is that this is not going to be the final form workspaces will settle on. Until YoYo figure out how to make workspaces more friendly and navigable, this will help.

• Import PSD file format to projects (NOTE: Will still convert to PNG) – should handle layers

  Now that the GMS2 Image Editor supports layers, this is a big deal, and this feature in particular will facilitate collaboration between the GMS2 dev and artists working in Photoshop.

• Attach points on sprites – allow multiple named points on sprites, can change on each frame

  This one is really exciting, as it opens up a lot of possibilities. Previously if you wanted an attachment point system, you would have to code it yourself. Having built-in features to support this will make it much more likely that developers will do more sophisticated objects, comprised of several sprites.

• Mobile Templates – indication of what room views will look like on popular platforms.

  This is a huge deal if you’re developing mobile games.

• Room Editor : Audio Emitter on Asset Layers

  This will help for designing levels in games that are highly dependent upon audio.

• Audio – basic audio generator in IDE

  If this allows programmatic, procedureally generated and modifiable audio at runtime, it’s something I’ve been wishing for since 8.x. Until now GMx has been limited to playing back pre-recorded audio files. Being able to define basic sounds at runtime, using functions, will free developers to do much more with sound. Previously this was only possible through the use of extensions, which were not necessarily portable to platforms other than Windows

• Audio – basic sample editor in IDE (cut / copy / paste / Trim / resample / Fade In / Fade Out)

  Well, now you won’t have to fire up Audacity as often, at least for doing simple/basic stuff with your sound files.

• Refactor support

  This will be another huge timesaver for those times when you decide you want to rename a variable or function, or pull out some inline code and turn it into a function call that you can reuse throughout your project.

• Save GIF

  Not sure what this is, but if it’s a way to quick-generate .gif images of your Work-In-Progress, then awesome.

• Particles Editor (and new Resource type)

  For a long time GM users have had to depend on independently developed 3rd party particle system designers, or else do everything through code. Having a built-in editor is a missing feature that has been long overdue, but thanks to the 3rd party community, not greatly missed. Still, it’ll be nice to have an official, supported feature. Let’s just hope that it’s as good as the mature 3rd party solutions.

• Room Editor : Particle Emitter on Asset Layer.

  This will go nicely with the new Particle Editor. Being able to place your emitters in the room and visually see them will be very helpful.

• Image Editor – Animated Brush support

  Animated brushes!!!

• Inherited projects

  This is another huge labor savor, enabling developers to re-use a project and avoid having to re-implement the same boilerplate stuff every time.

• Import SVG graphics

  This will make vector graphics easier to make.

• Tile Collision – built in support for tile collision

  Tile-based engines will be much easier to implement with this in place, resulting in efficiency gains and better performance. This will make possible bigger, more sophisticated 2D games and/or games on lower-powered platforms.

• Plugin documentation and SDK

  Being able to write your own plugins for GMS2 will open up a lot of possibilities, and enable YYG to focus on the core features of the IDE while allowing 3rd parties to develop features users have asked for, but YoYo doesn’t have the resources to work on, which seems like 80% of the things I wish for, sometimes ;-)

Runner

• Extended Gesture events – Pinch In and Out, Rotation

  A big deal for platforms that support touch screens.

• Runtime support for Game Languages

  This is tantalizing, but mysterious. What do they mean by Game Languages?

• 64bit runtime support for Windows, Mac and Linux

  Finally, we will no longer be constrained to 4GB of memory for our GMS projects!

• Wrapping Tilemaps – also allow smaller tilemaps than the room for simple parallax

• Allow auto tile sets to be used at runtime

  This will come in very handy when implementing dynamic terrain.

• GML: method data type to allow calling scripts through variables (i.e. foo=myscript; foo( 0, 1, 2); )

  Perhaps I’m mistaken in how I’m reading this, but I thought we already had the ability to do this. I’ve set up a GameMaker object with an instance variable, action, and done action = some_script which doesn’t call some_script() and return the result, setting action equal to the return value, but rather sets the value of action equal to the id of some_script, in other words turning action into an alias for the script some_script. Then, elsewhere I can use action() rather than being locked into calling some_script(), which means that I can dynamically re-assign action to be whatever script it happens to need to be at runtime, say some_other_script(). It’s a handy script, but nothing new… I did this in GMS1.x years ago.

• GML: exception support – try… catch… finally… and throw

  I haven’t needed exceptions, and I’m a bit skeptical about how much this will gain us. It’s better to write code that can’t throw an exception and doesn’t need to. Lots of newbie developers working in languages that do support exception handling end up just wrapping their thrown exceptions and ignoring them rather than deal with them properly. I suppose that this is a feature that many “real programmers” feel is important, but I just don’t know that it’s all that important for GMS.

• GML: data structures as a true datatype (not just an index)

  Sweet!

• GML: Chained arrays and accessors – allow foo[a][b][c] (and accessor equivalents)

  Sweet! This will make working with nested data structures much easier.

• GML: Inline functions – allow var a = function( a, b ) { ….. }

  So… closures? Hmm.

• GML: Accessor literals – allow data structure literals – var a = {| 1, 2, 3 };

  Sweet!

• GML: Garbage Collector

  Garbage collection can cause problems with performance, if the garbage collector wakes up and does it’s thing while the CPU is already under heavy load.

• GML: lightweight objects – new and delete + constructors / destructor methods.

  Basically, structs. Lots of users have been asking for this for quite a long time.

• GML: foreach statement to iterate over arrays and data structures

  Finally, some iterators.