OFFICIAL GML Updates in 2019 (Follow up AMA)

Status
Not open for further replies.

Azenris

Member
GML QUESTION

A question about the chained-accessors.
Does this include chained results from function. Like a function returning a ds_list

Eg.
Code:
var _rarity = item_get( _i )[| ITEM.RARITY ]
 

Miradur

Member
Thanks for the explanation @FrostyCat but I stick to it, if you want to program in a high level language, you should use C++ or similar.
GMS used to be a pure engine for beginners and now it's moving forward and is more and more aimed at experienced programmers.
Development is good, but GMS might lose its market niche, because many have probably decided for GMS, because you get there faster
than with Unity or Unreal. Unreal is indisputably the better engine, but Unity has earned its place because it has an easier entry.
At GMS there are also so many under construction where beginners are left alone, just think of shaders, deep sorting, tile collision and
much more.

You see it yourself, when you look at the beginners, you see 80% of the code copied together, from some videos or something like that.
That would make me think as a developer, because apparently the beginning is so difficult, that you can't get anything done yourself,
or else, there are just small hurdles, which take the fun out of you or let you miss your goal (see above, shader ...).

We live in the 21st century and I can say that there were Game construction kits in the 80s where you could really get a game fast.
Why do I have to deal with collisions and depth grading as a beginner? Why doesn't GMS do that for me and it would just need different
master-objects. A wall, an enemy, a water, a damage and a player object and everything I put under it are children of it.
Each of these parent objects would have default properties and the player object would even have its keyboard and gamepad controls
and whoever can program that better would overwrite the code so classes would make sense even for beginners because they would
make it easier to make a game.

In my opinion there is one thing that is always forgotten, we all have dreams, but only a few can make them come true. Especially Gamer
dream of their own game, but most of the time they can't program at all. It's clear to me that a company has to decide which way it wants
to go, but as soon as something appears that makes life a little easier, people are gone and make their games with an other game engine.


Miradur
 

Dog Slobber

Member
GML Question:

[two related questions]
  1. Will variable number arguments be supported within methods with argument_count, arugument[0 .. max_num]?

  2. When using user-defined argument names will an unreferenced argument_name generate a warning, or a run-preventing error as an unreferenced argument_n currently does?
 

Sammi3

Member
Thanks for the explanation @FrostyCat but I stick to it, if you want to program in a high level language, you should use C++ or similar.
GMS used to be a pure engine for beginners and now it's moving forward and is more and more aimed at experienced programmers.
I really don't see how this changes much for inexperienced programmers. The only hurdle is that now you're going to have to wrap any functionality you want to code into a function instead of just keeping it in a script file? Which helps you organize your code so I mean, idk. You won't have to use any of these features. They've just added features that a certain group want. Also, do you always want to be stuck in the "beginner" bracket? DnD is still possible.

YoYoGames are just adding functionality to allow more ambitious developers to remain in the ecosystem. Back in the day, people would just play around with GameMaker until they moved onto better engines. This left GameMaker's old game portal full of ugly games and it left GameMaker a terrible reputation. There was a time that it was a bit of a shame to say that you used GameMaker. Some of us stuck around because we loved the tool despite it's shortcomings and because YoYoGames started becoming ambitious. It's no mystery that with more features added to GameMaker, the more professional games we've seen being made with GameMaker.

This is not just about experienced programmers vs inexperienced programmers, this is about YoYoGames as a business. They need to retain their customers and one way to do that is to allow their developers to grow within their ecosystem rather than outgrow the tool itself. I would be remiss to remind you that a lot of seasoned GameMaker developers today are here out of a feeling of loyalty over the product more than anything else as they are perfectly capable of using different game engines. YoYoGames, I believe, do not want to lose these customers and they have to appeal to them to an extent. I mean, there are people who make bloody 3D games in GameMaker still and perhaps one day YoYoGames might have to attempt to keep them in the ecosystem (although I'm proud of the 3D GameMaker guys as they have done some astonishing things with such a limited tool).

So please, continue as you may. Preferably, become more ambitious on you learning how to create video games and indulge yourself in more advanced techniques. Improve and ask more of the tool you use so that you can grow with it. Don't limit yourself to forever be a beginner.
 
Last edited:

Dog Slobber

Member
Thanks for the explanation @FrostyCat but I stick to it, if you want to program in a high level language, you should use C++ or similar.
How does adding advanced features detract from beginners using Studio?
They don't. No beginner features have been removed. Nothing has changed for them.


GMS used to be a pure engine for beginners and now it's moving forward and is more and more aimed at experienced programmers.
GM hasn't been a "pure engine for beginners" since YoYo Games took over more than 10 years ago.

They didn't create exports for Mobile, Linux, xbox, PlayStation, Nintendo for beginners. Simply put, beginners are not spending money on Studio and export options like advanced people are.

Instead of telling advanced people to move on, perhaps you should tell beginners to open their wallets.
 
Last edited:

Tthecreator

Your Creator!
I came up with a pattern for inheritance, may it never become a thing.

Supposed you wanted to do:
Code:
class Enemy{

Enemy(_x, _y){
this.x=_x;
this.y=_y;
}

}

class Goblin extends Enemy{

Goblin(_x, _y){
super(_x,_y);
}

}
You could do in gml:

Code:
function Enemy(_x,_y){
x = _x;
y = _y;
}

function Goblin(_x,_y){
enemy = new Enemy(_x,_y);
}

It's not the nicest because you have to know how far down the inheritance tree you are to call the right function. In that sense it is limiting. Depending on how this gets implemented exactly and if self will still be just the value of -1, it might be possible to have Enemy have a reference to itself. Maybe you could use this variation on the pattern:

Code:
function Enemy(_x,_y){
x = _x;
y = _y;
enemy = 0;//init enemy to something

setEnemy = function( _enemy){
enemy=_enemy
}

}

function CreateEnemy(x,y){
enemy = new Enemy(x,y);
enemy.setEnemy(enemy);
}

function Goblin(x,y){
enemy = CreateEnemy(x,y);
}

This way you can always do object.enemy.x and object.enemy.y.
 
Last edited:

Nux

GameMaker Staff
GameMaker Dev.
@Tthecreator , that's essentially a composition relationship, i.e. where you embed an instance of one class inside another.

If light-weight objects end up having the ability to add new elements to them after they've been constructed, I can't see why it wouldn't be possible to to call the constructor of some other "class" at the top of another "class's" constructor.

Code:
function Actor(_x,_y) {
    x = _x;
    y = _y;
};

function Player(_x,_y) {
    Actor(_x,_y);
    health = 100;
};

var empty = new Actor(0,0); // empty actor
var player = new Player(0,0); // specialised actor
This might have some problems with scope. But, if there's a way to manually force scope like what the new operator does when preparing the new object, I don't see why this couldn't work.

EDIT: This was all but confirmed in one of the answers about inheritance found here. Search for "What would inheritance look like with "lightweight objects”?"
 
Last edited:

2Dcube

Member
I agree largely with Miradur and I can also see the merit in the counter-argument: They are just extra features for the people that want them.
I think the fear is that they will inevitably show up in tutorials or the forums.
For example when a beginner asks a question, people might answer with "just make a class for so and so" or "just use such and such advanced feature, it's really easy once you get it" (I'm guilty of this myself)...
 
I

immortalx

Guest
I agree largely with Miradur and I can also see the merit in the counter-argument: They are just extra features for the people that want them.
I think the fear is that they will inevitably show up in tutorials or the forums.
For example when a beginner asks a question, people might answer with "just make a class for so and so" or "just use such and such advanced feature, it's really easy once you get it" (I'm guilty of this myself)...
I understand your fear about tutorials getting more "unreachable", but there's a whole world of older tutorials and documented techniques, that are still straightforward. These aren't going anywhere and there aren't any breaking changes expected, so they should continue working. The good thing with GML is that it wasn't some C++ or Java clone from the get-go, and that attracted many of us, the less experienced users. But just imagine the potential when the experienced users get their hands dirty: No novice would swim on completely deep waters, because there's already tons of "easy" material, but if anyone wants to get a step further, won't have to flirt with other engines/languages.
I'm quite confident that these changes will keep the best of team-GML here, and if I'm definitely sure of something, is that no software survived without keeping its star-users happy.
 

gnysek

Member
Will variable number arguments be supported within methods with argument_count, arugument[0 .. max_num]?
I think that argument_count will be converted to array_length(argument) on project load in GMS 2.3, as:

- scripts which use argument0, argument1, argument2,... will be converted to function script_name(argument0, argument1, argument2) - as compiler already detects if you use wrong number of arguments, and calling them in code won't change
- scripts which user argument[0], argument[1], argument[2], should be converted to function script_name(argument), then in body they still gonna use argument[n], argument_count can be easily changed to array_lenght(argument), and calling them in code will change from script_name(a, b, c, ...) to script_name([a, b, c, ...]) . As arrays can be chained, this won't break anything if you pass array as any of arguments.

So, instead of argument_count, you can just pas an array in new functions, and check it's length, you can then have two or more variables with variable length thanks to it ;) In fact, you can also make the same now ;)

Easiest way will be to remove argument_count at all, but we'll see, maybe they gonna leave it for some edge cases (but as you can see above, all should be doable without this variable).
 

FrostyCat

Redemption Seeker
I agree largely with Miradur and I can also see the merit in the counter-argument: They are just extra features for the people that want them.
I think the fear is that they will inevitably show up in tutorials or the forums.
For example when a beginner asks a question, people might answer with "just make a class for so and so" or "just use such and such advanced feature, it's really easy once you get it" (I'm guilty of this myself)...
This is the kind of fear that I simply don't understand.

What's the problem with coverage on OOP showing up on tutorials or on forums? It's not difficult, it's just foreign. Everything you say about OOP being intimidating to rookies also applies to pre-OOP GML, relative to D&D. Why should anyone be guilty for answering in OOP-based GML in 2020 when a question is asked about a data-driven concern, when they aren't guilty for answering in pre-OOP GML in 2019 when a question is asked about an action-driven concern?

Rookies are already offered similar advice on the Q&A section, except they're improvised workarounds involving arrays and enums. If anything, I think these hacks are harder to understand and easier to screw up with than the self-documenting nature of their future OOP-based equivalents. Furthermore, I've seen more issues on the Q&A sections with people trying to take OOP concepts and shoehorning them into pre-OOP GML, than I've seen people chickening at the prospect of learning basic OOP. Those who do chicken aren't afraid of OOP, they're just afraid of anything that isn't a copy-and-paste solution and requires thinking. No responder should be discouraged for standing their ground and not pandering to that crap.

There is also no evidence that OOP will start applying en-masse post-2020 for routine action-driven tasks, which still constitute an overwhelming majority on GM tutorials and forums. The existing interface for things like collisions, I/O and drawing don't see any prospect of coming under heavy OOP influence, if they change at all, that is. What there is evidence of a visible shift in is data-driven modelling, i.e. anything that we currently offer workarounds involving these:
  • Enums coupled with arrays
  • Property tables in 2D array/grid form
  • Maps set up as gophers for serving up properties instead of for content-heavy lookup
  • Deactivated "heavyweight" objects being used as containers for data
There should not be a moral stigma to advise creating classes for a data-driven need, any more than to advise using the workarounds listed above.
 

gnysek

Member
Rookies are already offered similar advice on the Q&A section, except they're improvised workarounds involving arrays and enums.
In fact, since we have "objects" in GameMaker, we already have OOP, but with predefined methods only (called here: events), and we work on instances of objects in-game. There's even inheritance already. So - everything is there, but too heavy for lot of needs. Should be then easy to explain.

I also don't understand the fear, if we already have that logic in engine, and even a newbie can feel that there should be a more intuitive way for some solutions (like defining items/weapons/world list for game - now you need to make array in arrays, or arrays with different names - objects with named properties would be more intuitive).
 

Miradur

Member
Of course we will learn and we will certainly use the new functions sooner or later. The point, however, is that YoYo work is currently
being put into OOP-like architecture. That's not a magic trick and the new features are just there, there's a lot of work and time behind it.
Exactly this time is missing, however, with things which would support us beginners. But now that I know that the money comes from the
developers(thx to @Dog Slobber ) who buy every export module and not from people like me (who only have the standard version for
Windows), the current development fits.

I'd just like to have links to tutorials where YoYo tells us some basic things about how to do certain things (deep sorting, tile collision,
shaders, slopes, jumps, physics, etc.). And I don't mean ready-made programs, but real learning instructions. It's always said that the
Youtuber does this wrong and the other does that wrong, so it would be nice if the developers of GMS would show you how it really works.

Otherwise I leave this contribution to the developers who really support YoYo with money ;)


Miradur
 
Last edited:

11clock

Member
I am mainly excited that they are finally adding proper functions and structs. This will be making a huge difference.

I just hope that they don’t screw it up somehow. GameMaker is the main engine I grew up with and it is a shame that I have been feeling like I have outgrown it recently. Especially when there aren’t many good options for pixel art games that aren’t drag n drop rubbish.

I have heavily criticized the new IDE for the space-inefficient workspace system forcing us to do a lot of scrolling around, but I may be willing to look past it if they improve the programming. Programming is quite easily my favorite part of game dev aside from design, so this update is very important for me.

I have actually started to make a GameMaker equivalent using C# and MonoGame, but making an engine is quite a lot of work and there is an unlikely chance I will ever get it production ready (I knew this going in but I am quite desperate now).
 
Last edited:

2Dcube

Member
This is the kind of fear that I simply don't understand.
Thanks for the detailed explanation. You say it's not difficult but I think it is for beginners, and it's just more to learn.
True, a workaround can sometimes be more complicated. It depends a bit on what it is.

For example let's say data types are introduced.
As a game creator, I just want to store a number in a variable, which is fairly easy to understand. I don't want to think about whether it's an int or a float or a decimal, (which are all new things to learn and remember), I'd like the computer to do this for me. What it is internally is not as important for the game's design, which is what I want to focus on.
Now data types aren't introduced, but I hope it stays that way.
 
For example let's say data types are introduced.
As a game creator, I just want to store a number in a variable, which is fairly easy to understand. I don't want to think about whether it's an int or a float or a decimal, (which are all new things to learn and remember), I'd like the computer to do this for me. What it is internally is not as important for the game's design, which is what I want to focus on.
Now data types aren't introduced, but I hope it stays that way.
I think if data types are introduced they would have to be optional. Gamemaker variables are already intentionally loosely typed due to how they are set up and that is a very cool feature that no one wants to go away. At least, I use that all the time for saving systems or stats in a ds_grid etcetera. However, being able to optionally force a variable to be a certain type would help avoid a ton of different sorts of bugs.
 

11clock

Member
Thanks for the detailed explanation. You say it's not difficult but I think it is for beginners, and it's just more to learn.
True, a workaround can sometimes be more complicated. It depends a bit on what it is.

For example let's say data types are introduced.
As a game creator, I just want to store a number in a variable, which is fairly easy to understand. I don't want to think about whether it's an int or a float or a decimal, (which are all new things to learn and remember), I'd like the computer to do this for me. What it is internally is not as important for the game's design, which is what I want to focus on.
Now data types aren't introduced, but I hope it stays that way.
I don't think that we should sacrifice power just for the sake of newcomers. I would like GameMaker to be more than just a game engine for newbies. And it is becoming less and less like that as it goes on to add more powerful functionality.

I think that what is more important than beginner friendliness is convenience to do as much as you can writing as little, and also clean, code as possible. Add features to reduce lines of code and make it easier to organize, basically. What has been proposed in the blog post sounds like exactly that.

I am not sure why you are against the proposal of more advanced programming features. They are supposed to be making our lives easier, not harder. You are suggesting the latter.

What I would be against is GameMaker suddenly going the route of being a 3D engine, since that would definitely make 2D itself more convoluted to do. Just look at 2D in Unity. I shouldn't have to worry about a Z axis when making a 2D game.
 
Last edited:
YoYoGames are just adding functionality to allow more ambitious developers to remain in the ecosystem. Back in the day, people would just play around with GameMaker until they moved onto better engines. This left GameMaker's old game portal full of ugly games and it left GameMaker a terrible reputation. There was a time that it was a bit of a shame to say that you used GameMaker. Some of us stuck around because we loved the tool despite it's shortcomings and because YoYoGames started becoming ambitious. It's no mystery that with more features added to GameMaker, the more professional games we've seen being made with GameMaker.

This is not just about experienced programmers vs inexperienced programmers, this is about YoYoGames as a business. They need to retain their customers and one way to do that is to allow their developers to grow within their ecosystem rather than outgrow the tool itself.
but if anyone wants to get a step further, won't have to flirt with other engines/languages.
I think these are very valid points to bring up. The quality of games being made with GameMaker now is amazing, but that's partly because people making more ambitious games have less reason to ditch GM. In terms of business I think it'll be a huge deal for them to keep people long term instead of being stuck as some kind of stepping stone, which will benefit us all because they get to stay in business and we get more features etc.

I looked at switching to Godot or Unity because of all the hype around Classes and "real" programming language stuff plus what looks like better Spine support (since my games use lots of Spine stuff), but with the additions YoYo just announced and assuming Spine support will probably get better over time plus all the platforms GM can export to, I honestly can't imagine any reason to switch to another engine...I can do pretty much anything 2D that I want to do and get up & running super fast and do a ton of fine-tuning and optimization if I need to, and it sounds like these additions will let me do some of that much more organized and lightweight. Once these new features are in I can't see any reason to not just stick with GM long-term as a gameDev who loves making 2D games.

Rookies are already offered similar advice on the Q&A section, except they're improvised workarounds involving arrays and enums. If anything, I think these hacks are harder to understand and easier to screw up with than the self-documenting nature of their future OOP-based equivalents. Furthermore, I've seen more issues on the Q&A sections with people trying to take OOP concepts and shoehorning them into pre-OOP GML
This. People are already trying to do a lot of this stuff and coming up with crazy workarounds anyway, I know I'm using a few hacky methods to do stuff that I'm sure these new features would make way simpler...and I'm sure good tutorials the community will no doubt produce, with good examples will help ease the learning curve.

In fact, since we have "objects" in GameMaker, we already have OOP, but with predefined methods only (called here: events), and we work on instances of objects in-game. There's even inheritance already. So - everything is there, but too heavy for lot of needs. Should be then easy to explain.
Maybe for anyone planning to write tutorials on this stuff, this would be a good approach to take? Relating it to what's already in there to help beginners wrap their heads around "oh okay so this is just what I'm already doing, but with a couple lines of code I get way more flexibility". I think that would be a great way to walk through it in a tutorial.

I have heavily criticized the new IDE for the space-inefficient workspace system forcing us to do a lot of scrolling around
I'm sure people have offered you suggestions before so you might already know a bunch of this but once I got used to using CTRL-T and typing a few letters from whatever I want to open, instead of using the Resource Tree, and using F12 to collapse the outer panels (with "Open scripts full screen" in Text Editor Preferences turned "on" of course), and stuff like splitting the code window into 2 columns, right-clicking inside it to use "Add/Open Event" instead of going back to the Workspace to open an Event's code, my workflow sped up dramatically. I rarely have to scroll around and I get a lot of space to code in, although I wish I could collapse the top or pull separated code windows out without any top hud attached to them etc Maybe some of those will help if you don't already use them. :) I stubbornly avoided CTRL-T for the longest time but it even leaves the last few resources you've opened with it at the top which is super handy for jumping around...now I can't live without CTRL-T!
 
Last edited:

2Dcube

Member
I don't think that we should sacrifice power just for the sake of newcomers. I would like GameMaker to be more than just a game engine for newbies.
I agree with this. I'm just willing to sacrifice some power for ease of use. I want to focus on high(er) level design and let the computer do low level stuff. That does not mean it will be just for newbies in my opinion.

What I would be against is GameMaker suddenly going the route of being a 3D engine, since that would definitely make 2D itself more convoluted to do. Just look at 2D in Unity. I shouldn't have to worry about a Z axis when making a 2D game.
Yeah. I think some of the new advanced features can come across as convoluted as well. The concept of classes in traditional programming is not very intuitive for non-programmers, whereas the objects in Game Maker are easier to get (and as such a good compromise to have some sort of OOP power).
 

11clock

Member
You already do. Its called 'depth'.
Sure, but it is separated from the x and y values. In Unity it is coupled with position as "Z." In my custom engine I have it named DrawOrder and purely determines the order that the engine draws the objects to the screen, no 3D shenanigans. (I also added UpdateOrder which is basically just depth for the step event.)
 

11clock

Member
I agree with this. I'm just willing to sacrifice some power for ease of use. I want to focus on high(er) level design and let the computer do low level stuff. That does not mean it will be just for newbies in my opinion.


Yeah. I think some of the new advanced features can come across as convoluted as well. The concept of classes in traditional programming is not very intuitive for non-programmers, whereas the objects in Game Maker are easier to get (and as such a good compromise to have some sort of OOP power).
As said, these new features are supposed to be making things easier, not harder. I still don’t see how lightweight objects and functions will make things more difficult, when the whole point of them is the exact opposite.

GameMaker shouldn’t just keep with a weak programming language for the sake of “non programmers”, which makes no sense to me in the first place. If you are using GML, you are a programmer. You should be excited about this kind of stuff.
 
Last edited:

Tthecreator

Your Creator!
Can we ask follow-up questions now?

I asked:

If I make a new lightweight object 'a' using the new keyword, and then say 'b=a'. Do I then have a copy of the object or a reference to the object in b?

ANSWER - You have a reference.

What if I did specifically wanted to copy the constructor, can it be easily implemented or would I have to write my own function. We already have instance_copy(). Will this or some similar function work on lightweight objects?
 

2Dcube

Member
GameMaker shouldn’t just keep with a weak programming language for the sake of “non programmers”, which makes no sense to me in the first place. If you are using GML, you are a programmer. You should be excited about this kind of stuff.
It's "Game Maker", not "Game Programmer". I want to make games in a fast and easy way. What people are excited about is up to them.
 

11clock

Member
It's "Game Maker", not "Game Programmer". I want to make games in a fast and easy way. What people are excited about is up to them.
And these new features will be making things even faster and easier, especially for games that are more data oriented.
 

Coercive

Member
Nothing major is actually changing to the way you already do things. At least from what I gathered. Pretty much just adding some sprinkles on top of the ice cream you already enjoy. Keep making things the way you already do. All of the new features are more or less just ways to improve what you are already doing. If you don't understand what functions and lightweight objects are. Keep using scripts the way you currently do. Now I may be wrong and time will tell. I am happy with either direction...

All the questions I had were already answered so all I can say is they'll be selling more GMS2 licenses. This is something a lot of people were wanting ages ago.
 

gnysek

Member
The only noticeable change from start is change for scripts, as there will be no scripts anymore, there will be "files" (name will be decided by YYG) with "functions". The rest is an extension, which you don't need to use at all.
 
Last edited:

Miradur

Member
This reassures me as a beginner, of course, that YoYo's time is put into things I don't need or can't ignore.
It's not like GMS2 was started with less comfort (editors features) and restrictions (tile collision sometime later).
There one waits nevertheless gladly still another year, until one is supported also as a beginner (1 year with
consolations we have already behind us).


Miradur
 

11clock

Member
This reassures me as a beginner, of course, that YoYo's time is put into things I don't need or can't ignore.
It's not like GMS2 was started with less comfort (editors features) and restrictions (tile collision sometime later).
There one waits nevertheless gladly still another year, until one is supported also as a beginner (1 year with
consolations we have already behind us).


Miradur
How about instead of complaining about new features that are intended to make our lives easier, you take off your beginner’s hat and sit down for an hour to learn the features, and be happier in the long run? Instead of trying to stunt the growth of an engine for a majority of its users?

You talk like that you are going to be a beginner for years to come.

EDIT: I just don’t think that features should be denied because “ohmergerd now there is more to learn it’s too hard I need to move to Scratch.” Especially when said new features are supposed to be making things even easier and more convenient.
 
Last edited:

Dog Slobber

Member
This reassures me as a beginner, of course, that YoYo's time is put into things I don't need or can't ignore.
It's not like GMS2 was started with less comfort (editors features) and restrictions (tile collision sometime later).
There one waits nevertheless gladly still another year, until one is supported also as a beginner (1 year with
consolations we have already behind us).


Miradur
Exactly what beginner features would you like to see?

One thing I've noticed over the years is, a lot of beginners want to do very advanced things. But they somehow think YoYoGames should be able to wrap the advanced things in a Beginner-like function or DND action.

It doesn't work that way.
 

JasonTomLee

Member
I'd love to see a wide variety of in-depth examples of light-weight objects and constructors when it comes out! Stoked for this update :D
 

11clock

Member
Say you define a function in an object, but call it from a different object or a global function. Will that function’s scope still be the instance that it was defined in?
 

FrostyCat

Redemption Seeker
Say you define a function in an object, but call it from a different object or a global function. Will that function’s scope still be the instance that it was defined in?
If I'm reading the helpdesk's response right, yes, it will still be the instance it is defined in. You would need to use method() to get a copy of that function, so that the copy is bound to the new instance's scope instead.
 

11clock

Member
If I'm reading the helpdesk's response right, yes, it will still be the instance it is defined in. You would need to use method() to get a copy of that function, so that the copy is bound to the new instance's scope instead.
Cool. I can already see how I can use instance functions to make a much more robust alarm system!
 

Sammi3

Member
So objects which we have now all collectively agreed to call Actors, are based on light weight objects? Nice. GML is going in a great direction.

I hope we don't have to wait for this as long as that one guy waited for his colors.
Me too. Also can someone link me to that post if it still exists.
 

hippyman

Member
The more and more I read through the answers, the more it felt like this is just going to be a load of fluff.



EDIT: I don't know what the hell made me come to this conclusion or had me all upset on that day but I'm definitely excited about the new features.
 
Last edited:

8BitWarrior

Member
The more and more I read through the answers, the more it felt like this is just going to be a load of fluff.
I didn't get that impression. I am thankful for how practical the answers are. They aren't making crazy promises but have instead set a reasonable trajectory for the future. I am all behind this.
 

Hyomoto

Member
The more and more I read through the answers, the more it felt like this is just going to be a load of fluff.
I also disagree. I think what the answers show is that we were pretty rational to ask what we asked, but that they are trying hard to provide complimentary tools that add functions we've heard requests for, but without fundamentally changing GML as a language.

Sure, they aren't changing GML to Java or C++. But, this is clearly a foundation for some more under-the-hood changes mixed in with some convenience features. Or, to put it another way, their original blog post was pretty good at describing what we're getting.
 

GMWolf

aka fel666
The more and more I read through the answers, the more it felt like this is just going to be a load of fluff.
Yeah there are a couple things that make me think "damn, they still aren't implementing it in a robust way".
But hey, that's what Ive come to expect tbh. GML will always be GMSs weakness.

Nevertheless these updates are verymucve welcome!
 

gnysek

Member
Yeah there are a couple things that make me think "damn, they still aren't implementing it in a robust way".
But hey, that's what Ive come to expect tbh. GML will always be GMSs weakness.

Nevertheless these updates are verymucve welcome!
I always thought that GML is strength of GM/GMS, not weakness, as other competitive tools to GM (in previous decade) got lack of it (lack of any language in fact), they only got actions. If you're searching for complex languages, use C++ or C# but in another tool. GMS was never a competitor to the engine with "U" in name. With improvements, GML will be 2x more powerful that it is already and really enough for making 2D games. I put lot of hate in recent two years about GMS 2.x after initial optimizm, but seeing those changes - as for somebody who is using GameMaker for 16 years now - made me to see future in bright colours again.
 

Sammi3

Member
Yeah there are a couple things that make me think "damn, they still aren't implementing it in a robust way".
But hey, that's what Ive come to expect tbh. GML will always be GMSs weakness.

Nevertheless these updates are verymucve welcome!
I did say before, this was going to be done in a "GameMaker" way. I would have been absolutely surprised if they took a very conventional route. Nonetheless, I'm pleased. It's added functionality that will help a lot of projects by allowing better code management and resource management. Perhaps in a distant future they might keep shuffling towards more conventional approaches but for now, it's a step forward.
 

GMWolf

aka fel666
I always thought that GML is strength of GM/GMS, not weakness,
When I ask people what they like about GML I often hear "I like events" or "being able to draw using draw_* functions" etc etc.

These are not language features. These are library/engine features.

The GM engine is it's strength. It's library is ok, but ultimately crippled by the language design (like the way data structures are handled, for example).
 

FrostyCat

Redemption Seeker
The GM engine is it's strength. It's library is ok, but ultimately crippled by the language design (like the way data structures are handled, for example).
GML's library design is definitely not OK, particularly in how new features have almost always been introduced in an intentionally handicapped state.

Some examples:
  • The file sandbox that didn't allow valid external paths until 7 years down the road (i.e. sometime later this year)
  • HTTP functions that didn't support headers until 2 years down the road
  • JSON functions that didn't support nested encoding until repeated nudges from the user community (and even then it's still awkward when the top level is a list)
  • Vector and matrix functions that are awkward to use and still fail to cover many geometric use cases
If YoYo wants GML and GMS 2 to be taken seriously, they should do a 180 on its design policy. The standard library should be built complete with an assumption of skilled use, not infantilized by crippling features on purpose or forcing incomplete integrations just because "rookies could be scared of the full package".
 
D

Dazai

Guest
GML's library design is definitely not OK, particularly in how new features have almost always been introduced in an intentionally handicapped state.

Some examples:
  • The file sandbox that didn't allow valid external paths until 7 years down the road (i.e. sometime later this year)
  • HTTP functions that didn't support headers until 2 years down the road
  • JSON functions that didn't support nested encoding until repeated nudges from the user community (and even then it's still awkward when the top level is a list)
  • Vector and matrix functions that are awkward to use and still fail to cover many geometric use cases
If YoYo wants GML and GMS 2 to be taken seriously, they should do a 180 on its design policy. The standard library should be built complete with an assumption of skilled use, not infantilized by crippling features on purpose or forcing incomplete integrations just because "rookies could be scared of the full package".
I would be extremely happy if YoYo kept GML for people new to game development (or don't have a strong programming background) and added a language like C#, Python, etc for those of us who are far beyond that point. GMS2 is fantastic in many ways, but the biggest problem for those with a stronger programming background is how GML doesn't really work with conventional programming practices and design.
 
Status
Not open for further replies.
Top