OFFICIAL GML Updates in 2019 (Follow up AMA)

Status
Not open for further replies.

rmanthorp

YoYo Games Staff
Admin
YYG Staff
Hey,

Today we have released the following blog detailing the GML improvements coming in 2019

https://www.yoyogames.com/blog/514/gml-updates-in-2019
'As you may have seen in our GMS2 2019 roadmap we have ‘GML Updates’ listed for Q4. When we polled our community last year, the extension of GML received overwhelming support. In anticipation of these improvements, I would like to share with you an overview of the features we’re introducing and the thinking behind our approach. Updates to GameMaker Language and the other changes coming in version 2.3 will be available later this year.'

Following this, we aim to field questions about these GML improvements and the blog with this topic. If you have a question for Russell and the core tech team, please respond in this thread and preface your question with 'GML QUESTION:'. We will be collecting the questions and returning with a follow-up post containing the answers.

Thanks.
 

RujiK

Member
Hot dang! Definately the most impressive update I've seen since shader implementation at least.

TL-DR Summary:
  • Infinite dimensional arrays
  • Lightweight objects with no default variables.
  • Garbage collecters (Multi-threaded for performance)
  • Constructor-ish Abilities
  • Try-Catch error handling
  • Functions!
Function example:
Code:
var log = function(a) {
     show_debug_message( a )
}

log( “Hello World” );
Nice!
 

Cpaz

Member
I'd personally say that these additions are a litlte late to the party.
But still, better late than never!

I am curious as to why these listed for Q4. I figured these changes would take priority over the likes of IAP and TV os support.
Or they're working mostly everything in tandom, but these changes will likely take thw longest to implement. Which is likely and understandable I guess.
Something I'm also excited for is the potential optimization this allows. Instead of needing to create whole for, say, effects, we can instead use an single object that spwans lightweight objects. Or, at least, that's my hope.

GML QUESTION:
While on the topic of lightweight objects, I'm curious as to how big in scale they can get. Are there any hardcoded limitations on them? Will they have their own events? Or are they restricted ti the event they're made in?
 
Last edited:

JeffJ

Member
Definitely one of the most exciting updates in a long time! There's a lot of good stuff in here. One of my personal favorites is finally being able to do proper error handling manually in a more graceful way.

One thing to note - these are obviously some rather big changes (the biggest changes to GML I've witnessed in some 15 years), and so it's going to be very important that they are backed up and supported with lots of good documentation, examples and tutorials. We want everyone to get into good practice uses from the very beginning, so I really hope YYG will keep in mind how important this is to go along with these new language introductions.
 
This is absolutely the best update news I've seen come out in years. Seems to be drawing a lot from JavaScript? Any chance of adding native JS support eventually? Or, native Lua support?

Regardless, this will make life SO much easier. Thank you. Inline function declarations and chained accessors will remove like...20% of my lines of code alone.
 

K-Sys

Member
GML QUESTION:
Will the "new" operator be also available for "normal" objects, allowing us to write and inherit proper constructors for them?
If not will any other way be added to write and inherit constructors for "normal" objects?
 

gnysek

Member
AWESOME, YES FOR ALL !!!!

Can't wait to test it!

A huge change, even worth to change from 2.3 to 3.0 - because SCRIPTs are gonna to be removed.
 
Last edited:

Nommiin

Member
GML QUESTION:
Seeing that there is a lot of influence from JS with these new additions, will these changes also bring some helpful JS functions/features such as the spread operator and arrow functions? In addition to this, how would retrieving variables work in GML with these changes? Will it still function the same and throw an error, or will it behave like JS and return undefined if the variable does not exist.
 
Last edited:

rIKmAN

Member
Every single thing in the blog post made me smile a little wider and my eyebrows raise a little higher!
Great stuff guys, lots of stuff that is going to make GMS2 a lot nicer to use.

I'm gonna go hibernate until Q4, can someone prod me with a stick when the update drops please?
 

COWCAT

Member
Seems like good changes, I've been awaiting real "data structures" for a while (instead of having to use arrays and maps for everything) Not a fan of the try/catch practice (bad Java memories...) but as long as it's optional, no problem.

Just concerned over one thing :

The script resource is now executed at global scope, so the Foo and Bar functions above are, in addition to being accessible as just Foo and Bar (without a prefix), also declared in the global.Foo and global.Bar variables.


Won't this cause conflicts if we are already using "global.foo" and "global.bar" in our project? To avoid any issues, shouldn't it be something like "global.func_Foo" for example?
 

gnysek

Member
GML QUESTION:
Can "scripts" resource be renamed, so that wouldn't mislead people after changes ? Something like "definitions", or "code" or "functions" or even... "GML" would fit better now, as this is the breaking change in fact (a good one, but breaking), but as we can define macros and enums there - and soon "objects", that would have some sense.
 

gnysek

Member
Won't this cause conflicts if we are already using "global.foo" and "global.bar" in our project? To avoid any issues, shouldn't it be something like "global.func_Foo" for example?
The last GMS version is able to find unused variables, so I think it may be also able to find that you rewrite "function" with value and also report it (as warning). I see no reason to report it if you assign another function to same variable though.
 

Oracizan

Member
Some exciting updates here!

GML QUESTION:
How will functions interact with gml_pragma("forceinline")? I would really love to see a YYC / VM inline function preprocessor.
 

Oracizan

Member
GML QUESTION: Will there be a difference in the way methods and the built-in GML functions are handled? e.g. however ill-advised it actually is to do so, could I use the new keyword with a built-in function?
 

Urto

Member
GML QUESTION

1. Storing functions as a variable makes it seem like creating functions will actually consume runtime resources. If I declare and define several functions in an object's create event and then instantiate the object two, three, or even ten times... does each instance of that object process the function definition? The fact that you can declare functions outside of the create event, such as in step event, makes me worry that the answer is yes, but my hope would be that the compiler is smart enough to recognize that functions declared in a create event should just be bound to the object type and not to individual instances of the object.

2. If I declare and define multiple functions in a single script resource, will there be a way to bind all functions in that resource to an object instead of having to bind each one individually? It seems like it would be highly convenient for a dev to just make one script resource for an object type which houses all intended functions of that object (I daresay it would even be like OOP). I didn't see anything in any of the examples that would permit this behavior. Some simple function like:

bind_all_functions_in_script(scrPlayerCharacterFunctions);

This would especially be useful if the code completer could pop up with function suggestions only for bound functions, which would A.) remove the need to store a lot of these in variables and B.) reduce clutter in the code completer.
 
Last edited:

Ido-f

Member
@Urto
you might want to add "GML QUESTION:" to that to increase the chance it'd get answered.
I'm also interested in those questions.
about question #1, I'd note they did mention something about static variables in light weight objects, which might be a way around that issue, if you were to assign functions to those static variables.
Admittedly, that seems clumsy to use, in regard to lengthier code and function scope handling.
 

kupo15

Member
Whoooaaaa! YES!
No more scripts, named arguments... METHODS?!!!? Rock on!
Code:
global variables + light weight objects = namespaces.
I don't care how messy it gets
I have hundreds of scripts, what will that mean for me? haha Obviously this blog is great news but honestly a lot of it went over my head (except for the chained arrays) :)
 

Hyomoto

Member
It's too bad we have to wait, but I have no doubts this will require that much time. I always assumed we'd get bits and pieces over time, but this might as well been announcing GMS3!

I'm excited, this is like the cherry on a great roadmap for the year. I wish I had some great questions for you, but I just want to say this was exciting news, and I'm overjoyed to hear this is what you guys are working towards. Actually I thought of one:

GML QUESTION: how will this affect defining a function with variable arguments? I didn't see the syntax for that in the examples given.
 
Last edited:

thaaks

Member
2. If I declare and define multiple functions in a single script resource, will there be a way to bind all functions in that resource to an object instead of having to bind each one individually? It seems like it would be highly convenient for a dev to just make one script resource for an object type which houses all intended functions of that object (I daresay it would even be like OOP). I didn't see anything in any of the examples that would permit this behavior. Some simple function like:

bind_all_functions_in_script(scrPlayerCharacterFunctions);
An even better approach would be (IMHO) to give the old scripts some more meaning and automatically bind all functions inside a script to an object if both object and script have the same (or similar) name, like oPlayer and scrPlayer. Or if I would be able to "connect" an object with a script, similar to specifying the parent object in an object's dialog box I could also specify the functions script for this object...

But anyway, I'm very happy for all these announced features! That will make GML competitive again ;-)
 

TsukaYuriko

Q&A Spawn Camper
Forum Staff
Moderator
Looking at my most recent posts, one might think I'm the one in charge of these changes! (It wasn't me! I swear! I'll do anything!!!)

I essentially mentioned everything listed here as something that would be nice to have but for now needs a workaround in the past few days... stop reading my minds, that's creepy.

Can't really add much more to that to express my approval. :D
 
Are you guys planning on adding a native for-each loop? I've actually already implemented a rudimentary one, using macros and stuff, but it is an ugly beast of a thing, and doesn't run quite as fast as a native one would.
 

hippyman

Member
This is something I've been wanting from GML for a long time now so I'm super excited. No questions here, only praise. Nice job putting my foot in my mouth YYG!
 

Pfap

Member
GML QUESTION:
Will we be able to JSON encode lightweight objects and send them over the network?

GML QUESTION:

How will methods and factory functions work?
Will we be able to write functions that return based off of the objects state?
Example:
Code:
var obj = {
  prop: my_sprite,
  func: function() {
    return this.prop;
  },
};

show_debug_message(obj.func());
// expected output: index of the sprite resource

show_debug_message(sprite_get_name(obj.func()));
// expected output: my_sprite
Edit:
After reading the blog post again maybe the syntax would look more like this.
Code:
function assigned_sprite( added_sprite )
{
    my_sprite = added_sprite;
 
    current_sprite = function() {
       return my_sprite;
    }
}

var light_obj = new assigned_sprite( spr_player_skin1 );

show_debug_message(light_obj.current_sprite());
// expected output: index of the sprite resource

show_debug_message(sprite_get_name(light_obj.current_sprite()));
// expected output: spr_player_skin1
GML QUESTION:

Will this be valid object literal syntax:
Code:
var obj = {

name: "Pfap",
stats: [ 1,2,3,4,5 ],
features: {  height: 60, weight: 160, friends: [ 1,2,3,4,5 ]  }

}




GML QUESTION: can we nest object literals?
GML QUESTION: how about functions? can we nest those?
GML QUESTION: are functions declared in scripts bound to the global instance?
From the blog post:
The script resource is now executed at global scope, so the Foo and Bar functions above are, in addition to being accessible as just Foo and Bar (without a prefix), also declared in the global.Foo and global.Bar variables. Any code between (and outside) the function declarations will be executed at global scope – identical to gml_pragma( “global”, … ) fragments – and thus also executed before any room is created.
 
Last edited:

Lukan

Gay Wizard Freak
I thought this was a late april fool's day prank, holy ding dang dong you guys!
This is beautiful!
 

GMWolf

aka fel666
GML QUESTION: How about reflection on lightweight objects? will we be able to use the variable_* functions on them?
GML QUESTION: there is a way to rebind functions, but can we get what instances they are bound to?
GML QUESTION: Could we disable the garbage collector and get it to run only when its 'safe'/'ok' to run, like at the end of a level, during a cutscene, etc as to minimize its impact on performance when the main game is running? (glad to hear its only running once a frame as to not choke our tight loops)


Also:
Made a quick video on the subject.
 
Last edited:

J_Dev

Member
Can you explain a little bit more about this:

A side effect of this feature is that all arrays in GML will now be 1-dimensional, and the 2-dimensional syntax of:

foo[ index1, index2 ]

Will be the equivalent of doing:

foo[index1][index2]

This should be transparent for older projects and everything will just work as normal.
So if we have used a 2D array in the past, and then accessed it using array[ index0, index1 ] how is that now translated into a 1D array, and the syntax the equivalent of using a chained accessor?

Say our 2D array has the value "eggs" at the position example[ index0, index3 ]. If we changed the old syntax to the new chained accessor the syntax it would be:

Code:
example [ index0 ] [ index3 ]
So does this mean that the way 2D arrays are now stored/interpreted is that "example" now stores an array of indexes, for what would have previously been each row of the 2D array? For example:

Code:
example[ index0, index3 ]
The first value "index0" is now a reference to an array which makes up "row 0". While the second value "index3" is the position in the array that actually holds the value we are looking for? Another example:

Code:
example[ index3, index6 ]
The first value "index3" is now a reference to row 3 (which is now a 1D array in itself), and "index6" holds the position?

GML QUESTION:
Essentially, is every row in a 2D array now turned into a 1D array? And does the first value of the old syntax example[ index0, index3] reference which row/array is to be used, while the second value reference the position in the array?
 
Last edited:
Status
Not open for further replies.
Top