OFFICIAL GML Updates in 2019 (Follow up AMA)

gnysek

Member
Some information or showcase in actual use could be nice. Hopefully they don't have problems with implementing updates, or internal problems from organizing the workload between employees
By chatting here and there, I have a info that "all changes they mentioned to add are in closed beta already for sure, and seems to work". So except they have problems with one of exporters (HTML5 may be pain here, as that one always was the least loved), I hope they have no problems with implementation, if that info is legit. But maybe they're adding some another changes too (we already know, that file format will change in 2.3, maybe that's the cause of delay?).

Without any official info, we can just make a fake-guessing, and I also don't want to spread any fake news, so I hope that they will finally tell us something if update didn't came before end of February, as that will mean start of third month of delay.
 

kupo15

Member
I would like to try out GML20 with few things, few weeks I have been writing and playing around with neural networks, and updates could make code cleaner and give possiblities do few things differently. Chained accessories would do the trick cleaning up the code.
What the heck is GML20? I thought it was some joke that when GML 20.0 comes out GML will be up to standard but with everyone mentioning it I don't think that is the case
 

drandula

Member
I meant GML in year 2020.

Edit. As GMS2.3 update is more than GML update.
Edit2. Therefore it is meaningful to talk about these separately, about whole update or just GML update
 
Last edited:

Cpaz

Member
I meant GML in year 2020.

Edit. As GMS2.3 update is more than GML update.
Edit2. Therefore it is meaningful to talk about these separately, about whole update or just GML update
Isn't it being referred to as GML 2.0? I thought I read that somewhere.
 

Alice

Toolmaker of Bucuresti
Forum Staff
Moderator
I'm just waiting for another announcement (these tend to be roughly biweekly, so maybe this Friday) and hoping it won't turn out that way.The early 2020 already took about 1/8 of a year, so having some kind of status update - if GMS 2.3 is not yet ready for open beta - would be really helpful... u_u'

On a side note, I feel like there are too many things packed into one big update (Sequences, new GML, apparently also resource tree changes and file structure changes?) that could instead be split into smaller independent updates, each taking less time to develop and test, thus keeping the momentum. But I also feel like having only one kind of upgrade would result in another series of these traditional disappointments because some people didn't get that thing they were waiting for and instead got another thing that doesn't benefit them specifically. So from that viewpoint bigger update at least has fewer people getting nothing useful, but still... ^^'
 

Cpaz

Member
On a side note, I feel like there are too many things packed into one big update (Sequences, new GML, apparently also resource tree changes and file structure changes?) that could instead be split into smaller independent updates, each taking less time to develop and test, thus keeping the momentum.
YYG b experiencing feture creps

But really, I dunno. They've been notorious for announcing update releases very last minute. The gml changes being announced a year in advanced was sort of out of left field, all things considered.

The delay was a few days before what was likely their winter break IIRC, and even then, was shoved to the bottom of an unrelated article on the winter sale.
 

FrostyCat

Member
I'm growing rather displeased at 2 trends on this topic that suggest incompetency and "greener-lawn-next-door" fallacies.

The first is the incessant, annoying pleas for live demos of GML 2020 features. There is already an article showing how the GML 2020 features work, and it's easy to predict use cases and approximate example code from it if you would just read it sensibly. If you can't see where the use cases lead without a compiler or physical demo, that says a lot about just how unqualified a programmer you are and why you should keep your mouth shut on this topic. There is a reason why when you learn programming in a formal setting, you get exercises with code that you predict the behaviour of without a computer around. The ability to predict where code leads makes a programmer, the same way the ability to predict the outcome of a blueprint makes a carpenter. A "carpenter" who can't form opinions and make educated predictions on a blueprint unless there is a scale model of it is not a carpenter.

The second is the constant requests for supporting JavaScript or some other "industry-standard" language. People who suggest this seem to have forgotten that GMS 2.3 is only a stepping-stone release, and are neglectful of just how big an operation making an engine polyglot is. There are language and build chain differences, none of which have easy answers. Godot has been at it trying to add C# for years, and they're still not done with it and their C# mobile support is nowhere near merchandisable. That's somewhat kosher for a free open-source engine, but absolutely NOT for a paid-for engine. Even after getting there, polyglot engines and platforms often start having issues with internal divisions and language differences, similar to the D&D-GML divide GMS 2 now has. The diversity of languages offered on the .NET platform on Windows, for example, is a support curse for Microsoft. Every API call doc is written at least 4 times, and the platform's support forum looks like the Tower of Babel's construction site right after divine intervention.

Please, start thinking a few more steps ahead before you talk. Read the blog announcements and predict the use cases yourself. Think ahead of the costs for implementing another language in addition to or in place of GML before suggesting it.
 

drandula

Member
You can only get so far with just thinking and planning. Without concretely testing out behaviour in your specific case, it is just guessing that it might work out, which could make other thing possible. But if not, then that other way what was thought beforehand.
Tutorial would be nice, yes, but more I want examples of how they can be used, in a ways which normally you wouldn't think of and were not previously possible.
And most, how they behave in edge cases.

Edit. As other code language support, I would like to have one. Currently I only know GML, but I am introducing myself to C# and JavaScript. I see GMS as familiar environment, and support for something else would be helpful in approaching these. Now this is from perspective of myself, for corporation they see it from cost and benefit.
 
Last edited:

FrostyCat

Member
You can only get so far with just thinking and planning. Without concretely testing out behaviour in your specific case, it is just guessing that it might work out, which could make other thing possible. But if not, then that other way what was thought beforehand.
Tutorial would be nice, yes, but more I want examples of how they can be used, in a ways which normally you wouldn't think of and were not previously possible.
And most, how they behave in edge cases.
You don't have to test or think very far to see the implications of GML 2020. If you have to use a compiler and do live examples to see where things lead, you are already doing predictions the wrong way and being intellectually lazy.

Have you read the book Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson and Vlissides? When it comes to programming, it's your choice whether to like it or not, but it's NOT your choice to not read it --- especially if you're dealing specifically with object-oriented programming.

For example, I can easily predict this is how the Observer pattern will work:
Code:
function Subject() {
  listeners = [];
  listeners_count = 0;
  attach = function(o) {
    listeners[listeners_count++] = o;
  };
  detach = function(o) {
    for (var i = 0; i < listeners_count; ++i) {
      if (listeners[i] == o) {
        listeners[i] = undefined;
        break;
      }
    }
    for (var j = i; j < listeners_count-1; ++j) {
      listeners[j] = listeners[j+1];
    }
    if (i < listeners_count) {
      listeners[--listeners_count] = undefined;
    }
  };
  notify = function() {
    for (var i = 0; i < listeners_count; ++i) {
      listeners[i].update();
    }
  };
  /* state manipulators */
}
Code:
function Observer() {
  update = function() {
    ...
  };
}
When I know that this works, I don't need to test concrete manifestations of this pattern in game-centric scenarios, for example guns moving/turning with the ship they're on. That's the power of design patterns: I prove and memorize one pattern, and then I know it'll work everywhere it is appropriately used.

This is the reason why I think people who keep asking for concrete examples on this topic are inadequate programmers. They work from the rookie assumption that every game element is unique and need their own tutorial, instead of the fact that they are compositions of basic non-specific patterns. And the GMC has been chronically negligent about the basic non-specific patterns.
 
Last edited:

Cpaz

Member
I'm growing rather displeased at 2 trends on this topic that suggest incompetency and "greener-lawn-next-door" fallacies.
Incompetence implies a level of unintentionality. No one is implying that as far as I'm aware (could be wrong, just my general impression). We know how this is being handled is deliberate. Just in ways that are frustrating for at least a few of us here.

But anyway, I can absolutely understand the whole "greener-lawn-next-door" fallacy, though. I'm all for comparing other tools, but it does each a point where it's ultimately the goal of the tool vs the goal of the user. If the tool doesn't suit you needs, maybe you either need to rethink your approach, or look for a new tool. Because you're clearly on different pages at that point.

So basically:
The second is the constant requests for supporting JavaScript or some other "industry-standard" language. People who suggest this seem to have forgotten that GMS 2.3 is only a stepping-stone release, and are neglectful of just how big an operation making an engine polyglot is. There are language and build chain differences, none of which have easy answers. Godot has been at it trying to add C# for years, and they're still not done with it and their C# mobile support is nowhere near merchandisable. That's somewhat kosher for a free open-source engine, but absolutely NOT for a paid-for engine. Even after getting there, polyglot engines and platforms often start having issues with internal divisions and language differences, similar to the D&D-GML divide GMS 2 now has. The diversity of languages offered on the .NET platform on Windows, for example, is a support curse for Microsoft. Every API call doc is written at least 4 times, and the platform's support forum looks like the Tower of Babel's construction site right after divine intervention.
I agree with this.
 

FrostyCat

Member
Incompetence implies a level of unintentionality. No one is implying that as far as I'm aware (could be wrong, just my general impression). We know how this is being handled is deliberate. Just in ways that are frustrating for at least a few of us here.
They are implying incompetence every time they ask for a concrete example that they could have come up with themselves with some mental effort. If they can't make educated predictions on theory in a given subject area, then they are incompetent in that subject area.

When the GML 2020 announcement came out, my first instinct was not "where are the tutorials/examples" like what the rookies on this topic are asking. The first thing was resolving syntax and corner cases compared to similar features in other languages I already know, particularly curly-brace OOP languages like Java or PHP (hence the big block of questions I asked on the AMA). The second thing was exploring the need (or lack thereof) for design patterns in the Gang of Four book, and for those with demonstrable need, prospective GML equivalents. None of these require live demos or videos, only common sense that every programmer with at least a year of formal practice should have been imbued with.
 

drandula

Member
Have you read the book Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson and Vlissides? When it comes to programming, it's your choice whether to like it or not, but it's NOT your choice to not read it --- especially if you're dealing specifically with object-oriented programming.
No, I have not read the book. As I said before, GML is my only knowledge in coding and it is a hobby. I am not professional coder in any manner. For some, professionals and experienced coders in other languages, new ways of doing the GML20 provides might seem trivial. I think they are empowering and I would like to know the limits. It is just I know things which I don't know, but there are things which I don't even know about not knowing. Of course even though I asked examples, and would they be released, they might be about things I thought or knew already. But before that, I will be unsure.

I have interpreted some JavaScript tutorials before for few things, one example about Verlet Integration. I tried to do it in GML inside only one object and do 3D physics simulations, which worked, but I had to do few workarounds. Now, when I heard upcoming GML20 updates, I saw what I could have done differently and it could provide more simplier approaches for other things I have written. Also I think it enables more swift interpretations of other languages, but this is just a guess of mine.
 

Yal

GMC Memer
GMC Elder
Coming up with applications for the new features isn't rocket science.
  • Chained accessors: make it easier to write complicated data structures (e.g. an array with some fields being maps or lists). I would use this all the time since my ideal data structure is a vanilla array and I've been forced to have multiple arrays in several big projects because of how cumbersome operations on arrays inside arrays are (with issues because of having to keep them in sync arising).
  • Lightweight objects: you can pass groups of data around in other ways than returning arrays or strings, making parsing and manipulating composite data more readable and less error prone. I'd use this all the time as well.
  • Declare functions / first class lambdas: this would do wonders at tidying up the resource tree which has gotten much busier after script tabs were removed. Helper functions can be grouped together with their parent, extension scripts all bunched together into one atomic unit, and temporary functions can be used to avoid littering the global namespace. This would make code reuse a LOT easier.
  • Named arguments: every other language C and upwards has this. It's been long overdue.
  • Exception support: now you can make your game look professional and deal with stuff like real() not having a check_if_can_be_interpreted_by_real() counterpart!
  • Sequences: i'm pretty content with my "put scripts in a queue" approach to cutscene, but it doesn't help with anything that has proper animation in it. Definitely would be fun to see what this is all about.
 
I'm growing rather displeased at 2 trends on this topic that suggest incompetency and "greener-lawn-next-door" fallacies.

The first is the incessant, annoying pleas for live demos of GML 2020 features. There is already an article showing how the GML 2020 features work, and it's easy to predict use cases and approximate example code from it if you would just read it sensibly. If you can't see where the use cases lead without a compiler or physical demo, that says a lot about just how unqualified a programmer you are and why you should keep your mouth shut on this topic. There is a reason why when you learn programming in a formal setting, you get exercises with code that you predict the behaviour of without a computer around. The ability to predict where code leads makes a programmer, the same way the ability to predict the outcome of a blueprint makes a carpenter. A "carpenter" who can't form opinions and make educated predictions on a blueprint unless there is a scale model of it is not a carpenter.

The second is the constant requests for supporting JavaScript or some other "industry-standard" language. People who suggest this seem to have forgotten that GMS 2.3 is only a stepping-stone release, and are neglectful of just how big an operation making an engine polyglot is. There are language and build chain differences, none of which have easy answers. Godot has been at it trying to add C# for years, and they're still not done with it and their C# mobile support is nowhere near merchandisable. That's somewhat kosher for a free open-source engine, but absolutely NOT for a paid-for engine. Even after getting there, polyglot engines and platforms often start having issues with internal divisions and language differences, similar to the D&D-GML divide GMS 2 now has. The diversity of languages offered on the .NET platform on Windows, for example, is a support curse for Microsoft. Every API call doc is written at least 4 times, and the platform's support forum looks like the Tower of Babel's construction site right after divine intervention.

Please, start thinking a few more steps ahead before you talk. Read the blog announcements and predict the use cases yourself. Think ahead of the costs for implementing another language in addition to or in place of GML before suggesting it.
As @FrostyCat said adding multi-language to GMS2 would be a pain for them and for us. Even from an user point of view. Imagine you have a question regarding your GML code and you would ask in the forums and people would be like..

  1. "don't know how to do that in GML only in JavaScript"
  2. "if I were you I would stop using GML and use C#"
  3. "you are using C# ?! c++ is way better and faster!"

People would begin to have a harder time finding answers to their questions.

Not trying to join neither of the 2 trends mentioned I have one thing to say. The thing that really leaves me frustrated is the fact that we are almost mid Q1 2020 and nothing else was said. And I'm afraid we get 2.3beta during Q1 and it only gets stable release during Q2, that would suck. If this was an open-source community based software well that would be acceptable.. but being a paid one. I think a blog post giving some update would be nice.

Regarding the tutorials explaining the full potential of the new features my opinion is that the new features are tools. And you have to look at them and be creative, no one will be able to list every single possible thing you can use them for. But if it really that important you can look at other languages for similar features and see what they can be used for ;)
 
Last edited:

Nocturne

Friendly Tyrant
Forum Staff
Admin
I think a blog post giving some update would be nice.
I'll mention this and see if we can't get some official word out on what's happening right now as I understand the frustration and anticipation for the new features.Keep in mind, that this is a BIG update, and it's laying the groundwork for future updates too, so we don't want to release it prematurely or piecemeal... we want to get this right as it's a pretty major advance in the product...

Regarding the tutorials explaining the full potential of the new features my opinion is that the new features are tools. And you have to look at them and be creative, no one will be able to list every single possible thing you can use them for. But if it really that important you can look at other languages for similar features and see what they can be used for ;)
Language features won't be getting tutorials... they will, however, be used in future tutorials. This is mainly because trying to do tutorials for language features like the ones planned is pretty much impossible, as you A) run the risk of making people think it can only be used for the subject the tutorial covers, and B) only covering a very limited set of the features and ending up requiring many, many tutorials to actually show them off properly. There will, however, be various tutorials and tech blogs for the IDE update (specifically, for sequences).
 

Sammi3

Member
I'm growing rather displeased at 2 trends on this topic that suggest incompetency and "greener-lawn-next-door" fallacies.

The first is the incessant, annoying pleas for live demos of GML 2020 features. There is already an article showing how the GML 2020 features work, and it's easy to predict use cases and approximate example code from it if you would just read it sensibly. If you can't see where the use cases lead without a compiler or physical demo, that says a lot about just how unqualified a programmer you are and why you should keep your mouth shut on this topic. There is a reason why when you learn programming in a formal setting, you get exercises with code that you predict the behaviour of without a computer around. The ability to predict where code leads makes a programmer, the same way the ability to predict the outcome of a blueprint makes a carpenter. A "carpenter" who can't form opinions and make educated predictions on a blueprint unless there is a scale model of it is not a carpenter.

The second is the constant requests for supporting JavaScript or some other "industry-standard" language. People who suggest this seem to have forgotten that GMS 2.3 is only a stepping-stone release, and are neglectful of just how big an operation making an engine polyglot is. There are language and build chain differences, none of which have easy answers. Godot has been at it trying to add C# for years, and they're still not done with it and their C# mobile support is nowhere near merchandisable. That's somewhat kosher for a free open-source engine, but absolutely NOT for a paid-for engine. Even after getting there, polyglot engines and platforms often start having issues with internal divisions and language differences, similar to the D&D-GML divide GMS 2 now has. The diversity of languages offered on the .NET platform on Windows, for example, is a support curse for Microsoft. Every API call doc is written at least 4 times, and the platform's support forum looks like the Tower of Babel's construction site right after divine intervention.

Please, start thinking a few more steps ahead before you talk. Read the blog announcements and predict the use cases yourself. Think ahead of the costs for implementing another language in addition to or in place of GML before suggesting it.
How old are you? You sound a bit novice. Someone who learned about the gang of four design patterns and is now trying to preach about being a good software developer. Look, if you think GameMaker is attracting software engineers then you're wrong. It's mostly designers who don't know OOP principles and what they entail and how it could benefit them let alone being able to imagine how to implement a gang of four pattern. Sheesh. YoYo Games actively target designers over traditional programmers. I don't think attacking them and calling them incompetent is fair as they see GML from an entirely different perspective than a software engineer would. Since when were people programming in GML getting elitist? Lol. This isn't C++ guys. No need to throw hissy fits.

Unfortunately, GameMaker does attract a few software engineers and some of them would love to be able to use another language. Again, not a big issue. I'm not one of them as if I need to use another language I would use another tool and I agree with you there but I think who knows, people should keep shouting about it if they want it and perhaps it will get popular enough in the future for YoYo Games to consider it the same way OOP has been talked about for ages. So keep doing your thing guys.

Anyway, I think Nocturne should close the topic. It's no longer insightful and once you see people throwing handbags and calling each other incompetent and unqualified programmers (for a language and engine made for designers ffs), it's only soon enough someone mentions Hitler... Whoops! My bad! ;)
 

drandula

Member
Wasn't one of GML20 possiblities to have functions inside variables and toss them around. Providing a way to change behaviour of instance on the fly without if-statements and having all code inside object, but any other object could handle or give changes. I think it as way of providing more modularity.

But yes Sammi, maybe it is better to close topic before flaming starts, if it seems going that way.
 

gnysek

Member
I don't think attacking them and calling them incompetent is fair as they see GML from an entirely different perspective than a software engineer would.
This. Pure truth.

If somebody thinks that GMS should allow more languages - just use another software, there's plenty of them, if you're better at another language, then just use it. You also can't use C++ or C# in a web browser where only JavaScript is allowed and I don't see complaints about that.

GML is created specifically for GMS, to make writing games easier, and it should be this way, as GameMaker is also for creating games in easy way. If you need something more complex - use something more complex (forum rules forbids saying exact tool names). If you think that changes in GML gonna make GML too complicated - don't use them. Use only those you already know, and forget about the rest - writing games will be exactly same (with exception of defining a scripts, but that's easy to learn, and adds one line more to write).

I know developers who sold games on steam which were made using Drag'n'drop actions only. So was it a problem to them, that GML allowed much more? No. Did they earned money and made a good game? Yes. Did they complain? No. Learn from them.

---

@Nocturne - thanks that finally somebody from YYG said any word :p Hope you all find a way to give us some official info :)
 

Coercive

Member
I would just be happy to see any news about anything... I guess this summer my project will get to see some progress.

Besides I have too much art to work on and such little time. Don't want to have any coding done just to rework a good portion of it.

I am hoping this update will get me more interested in coding again. I just find it annoying to work with in its current state.
 

Yal

GMC Memer
GMC Elder
Since when were people programming in GML getting elitist?
Since the Yoyo Sandbox days. Both me and several other people I knew from back in those days hesitated to move over to the GMC because everyone here were so elitist and serious. (I suppose I eventually caved in because "if you can't beat them, join them" :p)

Providing a way to change behaviour of instance on the fly without if-statements
There's been one for years.
Code:
///Step event
script_execute(state)
 

GMWolf

aka fel666
Since the Yoyo Sandbox days. Both me and several other people I knew from back in those days hesitated to move over to the GMC because everyone here were so elitist and serious. (I suppose I eventually caved in because "if you can't beat them, join them" :p)


There's been one for years.
Code:
///Step event
script_execute(state)
what about instance_change? everyone forgets about instance_change
 
I think the problem is that these new features have been hyped up too early, and then us being told multiple times that they would try and get info on it for us but that never ends up happening. (Which is why we are asking for any new info now, because we should have got 2.3 in Q4 of 2019. The least they can do is satisfy our hunger with new info on 2.3. I would love to hear about sequences, because we really haven't heard much about it. If they release a sequences blog post, I am quite sure that would last everyone up until 2.3 open beta release.)

I wish sequences and the GML changes in 2.3 were announced at the beginning of 2020. I prefer not knowing what is coming, and just having them drop off these good updates when they are ready. But yeah, in my opinion these features have been told and hyped to us way too early.
 
@FlameRooster I do understand the early hype you are talking about.. but worst then the hype is knowing it was ONE ENTIRE year ago. From what we can guess a lot might have changed, we don't know if all features will get to this release.
For example: "in the future lightweight object will allow for static properties and methods" (something like this was stated in the blog post). Will these features be included right now.. what future were they talking about "after 2.3.. future?" or "after the blog post, future??" And like this example some other things like this were stated in that blog post.
Another example, the "future implementation" in GMS2 roadmap stated that lightweight objects would count with "construct" and "destruct" methods (only). That would be nice since the garbage collector could call a default method ("__destroy") that could clean stuff inside the lightweight object (if one were to use data structures inside them)... and last week they silently changed that and removed the "destruct" part. So apparently there will be no destruct capabilities.

So the early hype is bad I understand but so much time without saying: what may probably change; what can we expect; and what not to expect is very frustrating.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
I wish sequences and the GML changes in 2.3 were announced at the beginning of 2020. I prefer not knowing what is coming, and just having them drop off these good updates when they are ready. But yeah, in my opinion these features have been told and hyped to us way too early.
The hype is pretty much all from you guys!!!! We've spoken about the updates to GML maybe twice and we've briefly mentioned sequences, but other than that, not much has really been said by YoYo Games...

You've only yourselves to blame for the hype!



So the early hype is bad I understand but so much time without saying: what may probably change; what can we expect; and what not to expect is very frustrating.
Yup, we get that and I've passed this along to the appropriate people. We'll see if we can't get an update on the situation out to you as soon as possible...
 

rIKmAN

Member
I'm surprised this thread has gone on as long as it has, I've seen others locked for "speculation" for much less.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
I'm surprised this thread has gone on as long as it has, I've seen others locked for "speculation" for much less.
I have been tempted to lock it several times already, but the I suspect people will just make other threads, so I might as well leave it open for now... and, tbh, the next update is a pretty big deal, imho, and you guys have a right to talk about it and be at least a little hyped. If (WHEN!) YoYo Games updates us n the situation I'll lock it and you can all pile onto the new thread. :p
 

rIKmAN

Member
I have been tempted to lock it several times already, but the I suspect people will just make other threads, so I might as well leave it open for now... and, tbh, the next update is a pretty big deal, imho, and you guys have a right to talk about it and be at least a little hyped. If (WHEN!) YoYo Games updates us n the situation I'll lock it and you can all pile onto the new thread. :p
Yeah I wasn't saying it should be locked, just that I'm surprised it's survived the Friendly Tyrant for this long given some of the posts! ;)

I'm pretty excited for the update, but personally I'd rather wait a bit longer and have it hit with a bang with all the new features working perfectly than have it rushed out due to time pressure and be unpolished and buggy.

Good things come to those who wait and you only get one chance to make a first impression, so if they feel like they need more time to make that happen then that's fine with me.
 
@FlameRooster I do understand the early hype you are talking about.. but worst then the hype is knowing it was ONE ENTIRE year ago. From what we can guess a lot might have changed, we don't know if all features will get to this release.
For example: "in the future lightweight object will allow for static properties and methods" (something like this was stated in the blog post). Will these features be included right now.. what future were they talking about "after 2.3.. future?" or "after the blog post, future??" And like this example some other things like this were stated in that blog post.
Another example, the "future implementation" in GMS2 roadmap stated that lightweight objects would count with "construct" and "destruct" methods (only). That would be nice since the garbage collector could call a default method ("__destroy") that could clean stuff inside the lightweight object (if one were to use data structures inside them)... and last week they silently changed that and removed the "destruct" part. So apparently there will be no destruct capabilities.

So the early hype is bad I understand but so much time without saying: what may probably change; what can we expect; and what not to expect is very frustrating.
Yeah, I personally don't like the early hype. I honestly never get excited for almost anything.. because it is usually a let down (most video games I buy and play), but I know for a fact 2.3 is going to be like Christmas.


The hype is pretty much all from you guys!!!! We've spoken about the updates to GML maybe twice and we've briefly mentioned sequences, but other than that, not much has really been said by YoYo Games...

You've only yourselves to blame for the hype!
That's true. Sorry about that. Seeing others anxious and hyped makes me feel the same, lol. I will cool it and wait. :D
 
Last edited:

gnysek

Member
The hype is pretty much all from you guys!!!! We've spoken about the updates to GML maybe twice
There was AMA, with a lot of answers and details, and that's what hyped us.

Also, remember that hype train doesn't end here, as roadmap says about 2 more sequence updates FOR THIS YEAR (they might move to next a little because of current delay), and I believe it's not the end, as there were sometimes a slight traces left here and there during last 2-3 years, about other features :squirrel: (in fact there's a official list of future considerations and it contains 5 times more features). Also, there's 2.4 planned for Q1 of 2021 and I believe that might be just a moment for PlayStation 5 and Xbox Series X exporters, but who know what they are hiding from us :D:squirrel:

Now it really seems that I've build my hype train :p
 
Last edited:

vdweller

Member
Has there been any hint about working on better YYC performance? I understand that for most users YYC is 100x faster than VM and that's all there is to it. But! Hear my case:

I have been testing the potential for a game using multi-grid, grid based pathfinding. Imagine floating islands, each a separate grid with dynamic, weighted terrain and obstacles, fairly large, up to 300x300 squares, and lots of agents. Agents can "hop" from an island to another if they are close enough. So essentially this requires a custom pathfinding algorithm. It also requires a lot of paper reading and a hierarchical approach to pathfinding. This is largely infeasible with GML, even using YYC.

To put things in perspective: Doing all the pathfinding stuff in GML with a lot of optimizations, and doing the exact same thing with a C++ dll: C++ code is ~20x times faster than YYC. What's even worse, I am not very knowledgeable in C++, so I expect my C++ code to be far from optimal, in contrast to GML, whose quirks I can safely say I know by now.

Now I understand that I cannot expect a similar performance with GML. You have type checks/conversions, everything has an underlying function call etc. But at this point every variable and line of code goes through so many layers that any meaningful speed gain is lost. I don't even know if things like cache coherence exist any more. It's a shame because Game Maker could be used to create a simulation game like Prison Architect, and I really don't believe that the current YYC implementation is as good as it gets. So here's hoping.
 
I don't want to change topic on this post but wanted to ask something.
Is there a topic similar to this regarding the Sequences feature?
thank you
 

gnysek

Member
There was once a screenshot in one of articles about Sequences (in this article: https://www.mcvuk.com/yoyo-games-plan-to-inspire-a-whole-new-generation-of-game-devs/ - but it seems that now it's removed). Another article about sequences is here: https://issuu.com/newbayeurope/docs/gamescom_daily_2018_day_3/10 and there is a small screenshot here.

Sequences (remember, this is not official info, just based on 2 or 3 articles and some mentions here and there, and I may not remember them correctly now) should allow predefined animations of sprites (objects?) in GMS, so you can set image color blend, rotation, scale, position, image speed, image index on timeline, and all will smoothly transform (using linear interpolation, or your own path-like tween) all of those values. Also, you can attach events to trigger at each frame of sequence - so it can be used to make cutscene for example. I would say, that Sequences are similar in some way to what Spine offers, but you can get it without separate license and in same IDE, with controls similar than in other IDE editors.

What I hope they add later (in sequences phase 2 or 3), based on official "future consideration list" is: text asset (for both rooms and sequences) and particles (as new type of resource, for sequences and asset layer).

What I would also love they would add to sequences/asset layer, is to change sprite shape similar to draw_sprite_pos, so you can morph sprites to any quad you like. That would make Sequences to compete with Spine, and can add some of 3d-look to some animations. However I didn't spot yet any info that this is coming - but it feels obvious that it will come at some point (maybe from start), as they seem to already support it for Spine (so they already have it in-engine), so maybe it was just not mentioned - there was not too much info about it, and it's hard to say that anything I already found is official or not. There can be also more things coming that are in Spine too, but it's up to their decision - we'll see, roadmap mentions updates of sequences to come for a year, so a lot may be added.

Sequences probably not offer anything new compared to what you can do using GML with a lot of effort (you can find some examples on marketplace for tweens too), but the difference is that you can do it without a line of code and with live preview using Sequences, so it would be much faster and don't require saving data outside of projects in custom format (no arrays, no ds structures, no buffers), and if you makes project in a small team, artists which aren't programmers can work on animations then.
A GML changes could be required on runner side to support sequences in fact, so that's probably why they are coming together.

So yes, 2.3 will contain a lot of good stuff inside :)
 
There was once a screenshot in one of articles about Sequences (in this article: https://www.mcvuk.com/yoyo-games-plan-to-inspire-a-whole-new-generation-of-game-devs/ - but it seems that now it's removed). Another article about sequences is here: https://issuu.com/newbayeurope/docs/gamescom_daily_2018_day_3/10 and there is a small screenshot here.

Sequences (remember, this is not official info, just based on 2 or 3 articles and some mentions here and there, and I may not remember them correctly now) should allow predefined animations of sprites (objects?) in GMS, so you can set image color blend, rotation, scale, position, image speed, image index on timeline, and all will smoothly transform (using linear interpolation, or your own path-like tween) all of those values. Also, you can attach events to trigger at each frame of sequence - so it can be used to make cutscene for example. I would say, that Sequences are similar in some way to what Spine offers, but you can get it without separate license and in same IDE, with controls similar than in other IDE editors.

What I hope they add later (in sequences phase 2 or 3), based on official "future consideration list" is: text asset (for both rooms and sequences) and particles (as new type of resource, for sequences and asset layer).

What I would also love they would add to sequences/asset layer, is to change sprite shape similar to draw_sprite_pos, so you can morph sprites to any quad you like. That would make Sequences to compete with Spine, and can add some of 3d-look to some animations. However I didn't spot yet any info that this is coming - but it feels obvious that it will come at some point (maybe from start), as they seem to already support it for Spine (so they already have it in-engine), so maybe it was just not mentioned - there was not too much info about it, and it's hard to say that anything I already found is official or not. There can be also more things coming that are in Spine too, but it's up to their decision - we'll see, roadmap mentions updates of sequences to come for a year, so a lot may be added.

Sequences probably not offer anything new compared to what you can do using GML with a lot of effort (you can find some examples on marketplace for tweens too), but the difference is that you can do it without a line of code and with live preview using Sequences, so it would be much faster and don't require saving data outside of projects in custom format (no arrays, no ds structures, no buffers), and if you makes project in a small team, artists which aren't programmers can work on animations then.
A GML changes could be required on runner side to support sequences in fact, so that's probably why they are coming together.

So yes, 2.3 will contain a lot of good stuff inside :)
I think you answered what I wanted to know for example imagine you want a instance to play an animation and when it ends destroy itself (instance_destroy)
you can use a sequence to play the animation and call a script at the end/on a specific step (you said we would probably be able to trigger events so I guess we can trigger scripts also).
this would be great not only for cutscenes stuff but for implementing animation finite state machines (if we could get/set instance variables from within the Sequences), then each action from a player "run","jump","die".. would just be a sequence.. and the player object just need to switch between them. Much like a (sprite + logic) packed in a single element

Come on 2.3, we are waiting!! ;)
 
Last edited:

gnysek

Member
I think that at lest getting the sequence frame number should be possible by using GML, and that's more than enough then to fire events and watch animation :p But yes, instead of making a sprite with all animation frames drawn in image editor, a sequence may be a better solution for walk/run/die animations, as then you can create it from several smaller sprites, instead drawing all possible images. Also, smooth animations require 20-30 frames per second of game, which can take for artist several days to draw, while sequence will save a lot of it. And may still looks smoother. And you can add a lot of other effects, and change them to different sprite without redrawing whole animation. It may require some coding to actually display it properly (at least more than sprite_index = ), but the result will be worth it.
 

Coded Games

Member
There was once a screenshot in one of articles about Sequences (in this article: https://www.mcvuk.com/yoyo-games-plan-to-inspire-a-whole-new-generation-of-game-devs/ - but it seems that now it's removed). Another article about sequences is here: https://issuu.com/newbayeurope/docs/gamescom_daily_2018_day_3/10 and there is a small screenshot here.

Sequences (remember, this is not official info, just based on 2 or 3 articles and some mentions here and there, and I may not remember them correctly now) should allow predefined animations of sprites (objects?) in GMS, so you can set image color blend, rotation, scale, position, image speed, image index on timeline, and all will smoothly transform (using linear interpolation, or your own path-like tween) all of those values. Also, you can attach events to trigger at each frame of sequence - so it can be used to make cutscene for example. I would say, that Sequences are similar in some way to what Spine offers, but you can get it without separate license and in same IDE, with controls similar than in other IDE editors.

What I hope they add later (in sequences phase 2 or 3), based on official "future consideration list" is: text asset (for both rooms and sequences) and particles (as new type of resource, for sequences and asset layer).

What I would also love they would add to sequences/asset layer, is to change sprite shape similar to draw_sprite_pos, so you can morph sprites to any quad you like. That would make Sequences to compete with Spine, and can add some of 3d-look to some animations. However I didn't spot yet any info that this is coming - but it feels obvious that it will come at some point (maybe from start), as they seem to already support it for Spine (so they already have it in-engine), so maybe it was just not mentioned - there was not too much info about it, and it's hard to say that anything I already found is official or not. There can be also more things coming that are in Spine too, but it's up to their decision - we'll see, roadmap mentions updates of sequences to come for a year, so a lot may be added.

Sequences probably not offer anything new compared to what you can do using GML with a lot of effort (you can find some examples on marketplace for tweens too), but the difference is that you can do it without a line of code and with live preview using Sequences, so it would be much faster and don't require saving data outside of projects in custom format (no arrays, no ds structures, no buffers), and if you makes project in a small team, artists which aren't programmers can work on animations then.
A GML changes could be required on runner side to support sequences in fact, so that's probably why they are coming together.

So yes, 2.3 will contain a lot of good stuff inside :)
Continuing the speculation, I still think it is interesting that the screenshot in the article has 2 new resource types. One of which is likely "Sequences" (between Objects and Timelines) and another that has a much longer name that is not used in that project since it is grayed out (between paths and scripts).

Overall, YoYoGames has a lot of stuff coming and all we really can do is wait. It will be here eventually and all I really hope is that they don't make massive changes to the scripts system so my game doesn't break. I hope functions and scripts live happily together.
 

S_Kleer

Member
I remember when I saw this screenshot in high resolution ... It is a pity that I did not save it anywhere ...
Unfortunately, I do not remember the name of the new resource.
 

gnysek

Member
I remember when I saw this screenshot in high resolution ... It is a pity that I did not save it anywhere ...
Unfortunately, I do not remember the name of the new resource.
The image was here but it's taken down: http://www.mcvuk.com/.image/c_limit,cs_srgb,fl_progressive,q_auto:good/MTU5MzQzMzA2Mjc3Mzk4MTEy/gms2_sequences_press.jpg

From what I remember new resource among sequences was named "Animation Curves". Not sure what those are, but I believe it might be a resource similar to path, where you can define interpolation (so put a value on y-axis, where x-axis is always between 0 and 1). So you can define lines/curves and then use them to animate (tweening), for speed/percentage of changes between frames, so they aren't linear between A and B values. They seems to be separate resource so can be used outside of sequences too, so you can read values of those interpolations using gml too.
Might be a nice addon, however for non-sequence usage this can be easily done now using paths, or even just scripts (for some most-known easings, like bounce, quad, sin, etc., there are just mathematical functions - you will find those on marketplace in all tweenings examples, or can even reuse code from known JS libaries - it's not hard to rewrite it to GML).

Another example of how complex 2.3 update will be.

don't make massive changes to the scripts system so my game doesn't break
Let's say, you have "script0", which code is:
Code:
return argument0 + 5
It will become:
Code:
function script0(argument0) { return argument0 + 5; }
// can be simplified manually to: function script0(a) { return a + 5; }
More complex:
Code:
var a = argument[0], b = (argument_count > 1) ? argument[1] : 0;
return a + b;
will become:
Code:
function script0(){
var a = (argument_count > 0) ? argument[0] : undefined, b = (argument_count > 1) ? argument[1] : 0;
return a + b;
}
Nothing to break here on project opening, while in my opinion change is massive :)
 
Last edited:
The image was here but it's taken down: http://www.mcvuk.com/.image/c_limit,cs_srgb,fl_progressive,q_auto:good/MTU5MzQzMzA2Mjc3Mzk4MTEy/gms2_sequences_press.jpg

From what I remember new resource among sequences was named "Animation Curves". Not sure what those are, but I believe it might be a resource similar to path, where you can define interpolation (so put a value on y-axis, where x-axis is always between 0 and 1). So you can define lines/curves and then use them to animate (tweening), for speed/percentage of changes between frames, so they aren't linear between A and B values. They seems to be separate resource so can be used outside of sequences too, so you can read values of those interpolations using gml too.
Might be a nice addon, however for non-sequence usage this can be easily done now using paths, or even just scripts (for some most-known easings, like bounce, quad, sin, etc., there are just mathematical functions - you will find those on marketplace in all tweenings examples, or can even reuse code from known JS libaries - it's not hard to rewrite it to GML).

Another example of how complex 2.3 update will be.



Let's say, you have "script0", which code is:
Code:
return argument0 + 5
It will become:
Code:
function script0(argument0) { return argument0 + 5; }
// can be simplified manually to: function script0(a) { return a + 5; }
More complex:
Code:
var a = argument[0], b = (argument_count > 1) ? argument[1] : 0;
return a + b;
will become:
Code:
function script0(){
var a = (argument_count > 0) ? argument[0] : undefined, b = (argument_count > 1) ? argument[1] : 0;
return a + b;
}
Nothing to break here on project opening, while in my opinion change is massive :)
I wrote a small tool (out of curiosity) in C# for doing the conversion from 2.2 scripts into 2.3 functions.
It was more complex than what I initially though and I had to guess some of the details (as we don't have all the information).
I actually ended up coding a full GML parser (I might keep it for future tools)
My main problem (while making the tool) and curiosity (on how 2.3 while do it) relies on how documentation will be handled..
for example functions internal to light-weighted objects will they have autocomplete?

GML doesn't have types so I really doubt it.. in my parser I actually ended up implementing type inference.
What I would pay for a peek into the development office ahahahah ;)
 
Last edited:
Top