OFFICIAL GML Updates in 2019 (Follow up AMA)

Status
Not open for further replies.

Tthecreator

Your Creator!
GML QUESTION: Any changes or ideas for polymorphism and inheritance? I'd be great to at least be able to implement the functions from another light object.

If we don't get that then what we get is probably is just an error when a function is not implemented and you try to call it. GML is not a strongly typed language anyways so you would just be able to use any object anywhere. Still some of programmings industry standard 'best practices' are not possible in GM.

@FrostyCat woops
 
Last edited:

FrostyCat

Redemption Seeker
GML QUESTION: Any changes or ideas for polymorphism? I'd be great to at least be able to implement the functions from another light object.

If we don't get that what is probably is just an error when a function is not implemented and you try to call it. GML is not a strongly typed language anyways so you would just be able to use any object anywhere.
That actually looks much more like an example of inheritance than polymorphism. Polymorphism is when you implement one concept in many different ways, and copying functions verbatim off another "lightweight object" isn't an example of that.

With that said, the current evidence points towards duck-typing being the main driver for polymorphism in GML 2020. As long as two "lightweight objects" A and B both implement operation X (doesn't matter if they're done the same way or not), A.X() and B.X() will be equally valid.

Given what you just said, I do have new additional questions about how OOP in GML 2020 will regulate itself and relate to the 3 basic tenets of OOP (encapsulation, inheritance, polymorphism).

GML QUESTIONS:

Encapsulation

  • Will there be the equivalent of a protected and/or private scope for methods and fields?
  • What happens if you set a previously inexistent field for a lightweight object after it has been instantiated? Example:
    Code:
    function Vec2(_x, _y) {
      x = _x;
      y = _y;
    }
    var foo = new Vec2(0, 0);
    foo.z = 0; // What will the runner do about this?
  • What happens if you initialize a field to function type value (i.e. making it a method), then assign it another value (could be a function or a non-function)? Example:
    Code:
    function Vec2(_x, _y) {
      x = _x;
      y = _y;
      mag = function() {
        return sqrt(x*x+y*y);
      }
    }
    var foo = new Vec2(0, 0);
    foo.mag = 0; // What will the runner do about this?
Inheritance
  • If the new GML allows "lightweight object" types to inherit from each other, how will children call their parent's original implementation of a method after overriding it (i.e. the equivalent for the super keyword in Java)?
  • Can you implement "mix-ins" in global functions to be executed in "lightweight object" definitions? Example:
    Code:
    function ExampleMixin() {
      say = function(message) {
        show_debug_message(message);
      };
    }
    function Vec2(_x, _y) {
      ExampleMixin();
      x = _x;
      y = _y;
    }
    var v2 = new Vec2(0, 0);
    v2.say("Hello world!"); // Is this allowed?
  • If the new GML supports a private scope, how will it protect against a child accidentally overriding a private method/field of the same name in its parent? This may happen in an extension setup, where the end user would not be aware of what private method/field names to stay away from.
Polymorphism
  • Will duck-typing be the main manifestation of polymorphism in the new GML update, as I predicted?
  • Can you alias methods? Example:
    Code:
    function Vec2(_x, _y) {
      x = _x;
      y = _y;
      mag = function() {
        return sqrt(x*x+y*y);
      }
      norm = mag;
    }
    var v2 = new Vec2(3, 4);
    show_debug_message(v2.mag());
    show_debug_message(v2.norm()); // Is this allowed?
  • Will there be syntax that enforce the implementation of certain properties without providing an existing implementation (e.g. the interface keyword in the C++/Java lineage)?
 

Tthecreator

Your Creator!
I'd love to see inheritance, but GM would need to be more strongly typed. Super fast strong type variables would be great for both code structure and speed. (speed as in some checks and loops aren't needed anymore).
Still I can see that this isn't a focus right now as it's not a core value of GML and probably just too much to ask.

GML Question: Has strong typing been considered? Are there any future plans for it?
 
I can't wait to see what I can do with the new GML additions.

Other than a built in and better version of GMLive, these new GML additions, and more stability, I can't think of anything else that I would want. :D Anything else is pretty much a plus for me.
 

Sammi3

Member
I think we should be skeptical at the extent GM is going OOP through lightweight objects. I want to be hopeful but I see people talking about polymorphism and I can only see polymorphism being done in such a "GameMaker" way. That is, very hacky and a bit of a mess but hey, it works in principle. I hope I'm proven wrong.
 

GMWolf

aka fel666
It would be great to see something akin to Lua metatables.

Perhaps an instance could have the 'meta' field.
Any member access would first try the instance, and if not found , go to the meta table.
For example:
Code:
meta_vector = {
    add = function(o) {
        x += o.x;
        y += o.y;
    }
    getNum = function() {
        return 0;    
    }
}

function vector(_x, _y) {
    meta = meta_vector;
    x = _x;
    y = _y;
    getNum = {
        return 4;
    }
}


vec = new vector(6, 7);
vec.getNum(); //looks for getNum in vec; found uses vec.getNum
vec.add(vec); //looks for add(in vec. not found => looks for add in vec.meta. found. uses vec.meta.add
This would be really powerful to define classes, but also for performacne reasons.

If we have a lightweight object (LO) type with many, many methods. then every time we create one such objects we have to assign all these methods to it. this would use up memory and take up time. (and because we now have more members the garbage collector will have tons more work to do).

If instead we assign a meta instance, then its only one allocation, and one extra field. It does make member access slower, but only in the case when it has to go up to the meta class.
If LUA can do it and still be the fastest scripting language out there, I think YYC can do it (it being compiled and all).

GML QUESTION: Metatables / Metainstances. could they be worked into the mix?
 
Last edited:

Pfap

Member
It would be great to see something akin to Lua metatables.

Perhaps an instance could have the 'meta' field.
Any member access would first try the instance, and if not found , go to the meta table.
For example:
Code:
meta_vector = {
    add = function(o) {
        x += o.x;
        y += o.y;
    }
    getNum = function() {
        return 0;   
    }
}

function vector(_x, _y) {
    meta = meta_vector;
    x = _x;
    y = _y;
    getNum = {
        return 4;
    }
}


vec = new vector(6, 7);
vec.getNum(); //looks for getNum in vec; found uses vec.getNum
vec.add(vec); //looks for add(in vec. not found => looks for add in vec.meta. found. uses vec.meta.add
This would be really powerful to define classes, but also for performacne reasons.

If we have a lightweight object (LO) type with many, many methods. then every time we create one such objects we have to assign all these methods to it. this would use up memory and take up time. (and because we now have more members the garbage collector will have tons more work to do).

If instead we assign a meta instance, then its only one allocation, and one extra field. It does make member access slower, but only in the case when it has to go up to the meta class.
If LUA can do it and still be the fastest scripting language out there, I think YYC can do it (it being compiled and all).

GML QUESTION: Metatables / Metainstances. could they be worked into the mix?
I'm not too familiar with Lua, but this kind of sounds like the prototype chain in javascript.
 

11clock

Member
They are finally addressing the main reason why I ditched GameMaker several years ago.

But this also means that I am racing with them now. My C# alternative in the works is shaking.

Tell you what, if my custom MonoGame engine isn’t ready by the time these features come out, I will reconsider.
 
I was trying to think of questions to ask myself, but I figured FrostyCat and others would have it covered.

Here are a few that I am particularly interested in though, albeit asked by other people already:
GML QUESTIONS:
- How will inheritance work with lightweight objects?
- Will we be able to use polymorphism (or something with similar functionality) for better OOP code organization?
- Can we use dot notation to run methods, such as inst.method()? Or will we still need to use with(inst) { method(); }?

THINGS I WOULD LIKE TO SEE:
- As with others, I would also like some options for stronger variable typing.
 
I

immortalx

Guest
Just as others have said, optional typing would be a nice addition, fitting with the rest of upcoming changes to the language. If you ever considered such a thing, I believe this would be the right time to bring it on. Being optional won't alienate users who like the more loose nature of GML and will also please those who want stricter code. Basically, checking for type at compilation and preventing automatic conversion if the type was present at variable declaration, is all I would ask.

GML QUESTION:
Would you consider adding some sort of optional typing?
 
S

samyak

Guest
GML QUESTION
Is there any plan to shorten the existing functions' names? e.g. instance_create_layer() can be shortened to instance_create() , even if it continues to have 3 variables.
 

11clock

Member
GML QUESTION
Is there any plan to shorten the existing functions' names? e.g. instance_create_layer() can be shortened to instance_create() , even if it continues to have 3 variables.
How about function overloads so that we can abandon all of this draw_ext crap? Or optional parameters with default values?

The more power they grant to programmers, the better.
 

hdarren

Member
I am concerned about the changes to scripts. I use scripts for example if I want to use the same code in multiple objects so not just to make 'functions'. Will the changes stop me from being able to use them in that way?

Basically I hope I can use scripts as they are now and this function stuff is a separate extra thing.
 
Last edited:

11clock

Member
I am concerned about the changes to scripts. I use scripts for example if I want to use the same code in multiple objects so not just to make 'functions'. Will the changes stop me from being able to use them in that way?

Basically I hope I can use scripts as they are now and this function stuff is a separate extra thing.
I don't get what you are saying. Isn't the whole point of functions to allow code reuse? How does this change get rid of this?

The only thing I see is that scripts will now be global scope functions, which they should have been in the first place. You can do very hacky things with the current implementation.

The changes made to scripts sounds like they will now behave more inline with how they work in other programming languages.
 

Dog Slobber

Member
What do you mean by "like the introduction of var did before"?

As far as I'm concerned, var was never "introduced", it has been there for as long as GML has been around. You will find mentions of it even in the Manual for GM 1.0 (the first version after Animo), and its behaviour has been more or less constant this whole time. Mark Overmars knew what kinds of problems could arise if instance and global are the only two scopes available.
var did NOT exist in GM4 and earlier. I can't remember if it was introduced in 5 or 6, but it definetley was not in 4 or earlier.
 

hdarren

Member
The only thing I see is that scripts will now be global scope functions, which they should have been in the first place. You can do very hacky things with the current implementation. The changes made to scripts sounds like they will now behave more inline with how they work in other programming languages.
It's very troubling to see so much "this is how other languages do it so this is how GM should do it". I use GML because it is quick and simple to make games. I don't use other languages because they are obtuse and pointlessly complex. There is nothing wrong with how scripts are used right now. They are simple and easy. Current useful applications should not be removed simply because "well other languages do it". It was similar with the new camera system. A simple system is now replaced with something needlessly complex when the old method worked perfectly fine. If new features are added they should be new additions not replacing systems that work very well.
 

GMWolf

aka fel666
There is nothing wrong with how scripts are used right now.
Small scripts using entire files. Having to use many tabs. Eating up the global namespace. Long script names instead of namespacing. Just a few issues that the current system suffers from.
Current useful applications should not be removed simply because "well other languages do it".
Actually looking into other languages can be useful. GML is a small language built and maintained by a small team, Whilst JS, C++ etc have entire consortiums helping shape the language.
not to mehtion how much more mature, and widely used these languages are. It makes sense study these languages as they are an indication of what makes a language succesful.
A simple system is now replaced with something needlessly complex
Functions are not 'needlessly complex'. Compared to scripts they essentially got a syntax change + a few optional goodies.
If before you had a script name doSomething
Code:
var foo = argument0;
var bar = argument1;
var baz = argument2;
return foo + bar + baz;
you will instead have a script that you could name doSomething (or anything else):
Code:
function doSomething(foo, bar, baz) {
    return foo + bar + baz;
}
if you really like the argument* keywords,
Code:
function doSomething(argument0, argument1, argument2) {
    return argument0 + argument1 + argument2;
}

The syntax is different, yes. But in terms of complexity it is the same.
 
H

Homunculus

Guest
@hdarren the point here is that scripts have always been in fact global scoped functions, which is exactly what the post seems to suggest they will be turned into, so I really don't get what you are worried about.

I agree that changes shouldn't be made just because other languages do it, but it's stupid not to borrow ideas and ways of doing things that are good and can actually improve GML and empower the developers. You may not like or use other languages, but there's no way to argue that things like not having user defined argument names for scripts has ever been a good idea (as in argument0 etc. instead of a custom name). Or user events instead of instance methods. Other languages already provide robust solutions to these "problems".
 
P

psyke

Guest
It's very troubling to see so much "this is how other languages do it so this is how GM should do it". I use GML because it is quick and simple to make games. I don't use other languages because they are obtuse and pointlessly complex. There is nothing wrong with how scripts are used right now. They are simple and easy. Current useful applications should not be removed simply because "well other languages do it". It was similar with the new camera system. A simple system is now replaced with something needlessly complex when the old method worked perfectly fine. If new features are added they should be new additions not replacing systems that work very well.
You will still be able to use the scripts globally, but instead of typing the name of the script, you type the name of the function inside that script.

It's very useful because you could make a script like: Math
And add all the math functions/operations inside that script instead of making one script for every function.
 

GMWolf

aka fel666
Not to mention it will make writing libraries a whole lot better! be ready to have a lot more third party tools and libraries!

GML QUESTION: how will instances and functions interface with the C interface? Will we be able to create and pupolate lightweight objects in DLLs?
 
R

Rukiri

Guest
This was needed over a decade ago...
Great, we can now create 1 large script vs supporting scripts.
However, I think we finally need a class system so something like this.
Class Hero {
variable = -1;

function add(x) {
x += variable;
}
}

Also a collider system would be nice but I think there is one but only in the physics world :(
 

FrostyCat

Redemption Seeker
Not to mention it will make writing libraries a whole lot better! be ready to have a lot more third party tools and libraries!

GML QUESTION: how will instances and functions interface with the C interface? Will we be able to create and pupolate lightweight objects in DLLs?
Not yet. In order for third-party tools and libraries to truly bloom, formal documentation on the IDE plugin API and system-level hooks to the runners (e.g. type interoperability, audio stream, window handle/main activity, graphics context, etc.) must be released first, neither of which have an announced timeline.

And looking only at the C interface in Windows is a superficial take on extensions. On a broader scale, the extension interoperability of types across all exports should be considered, and some makes it easier than others. For example, in the HTML5 export, can GML arrays now interoperate with JS arrays, and/or GML lightweight objects with JS objects? What about other types like buffers and surfaces, that up until now have operated under an internal ID system and isn't interoperable with their JS counterparts? This is just one example of unresolved confusion in extension development, I'm sure people familiar with other exports can attest to similar concerns.

GML QUESTION: After the GML 2020 update, what are the type correspondences between GML-native types and native extension types for each export platform? And if there are GML-native types that don't interoperate directly, will there be runner hooks that allow native extensions to have limited read/write access to those types?
 
Woah this was totally unexpected! Awesome news! I can't even imagine a question @FrostyKat hasn't covered lol but that huge list of "what about this situation?" is a good reminder of how much work goes into adding features like this, massive thanks to the YoYo team for all the hard work!

I've been trying to learn about classes and entity component systems and polymorphism etc from non-GML tutorials but I'm too amateur a coder to grasp a lot of it once they start going into each specific language's complicated looking syntax in examples...I know there's something in there that can make doing games way cleaner and more organized but trying to understand it and then trying to figure out some kind of workaround to it in GML right now is overwhelming.

A tiny request for the people who are psyched about doing tutorials (and that's super appreciated, all the tutorials and examples are what make GM so easy to learn):

Most of the tutorials I've seen for stuff like classes and components and polymorphism etc are super abstract "foo & bar" examples that I'm sure make complete sense to advanced programmers, but to us amateur level guys where GML is our first real coding language it can be hard to see where super abstract examples like that fit into the puzzle of gameDev and it becomes like "this seems complicated to learn, and I can't really see how it would apply, so I think I'll just stick to the old inefficient way of doing things because I don't really get what this is for"

Same with examples that have no real relation to actual gameDev like "mammals have fur and teeth and eyes, but the bird class will have wings, but if the birds are African swallows then they have carrying abilities so we could have another sub class and..." But then I open up some open-source game or like the Doom source or something and they just have players and enemies so I'm thinking "is this stuff just overkill? Is it only for making a AAA MMORPG or simulation game or something with 50000 different features? Is this beneficial for making just an action game like Mario or a shootemup or is it just over-complicating things? Would Pong or Tetris or Pac-Man have any use for classes and polymorphism and components?"

Like I know it sounds dumb lol but why do I want to do this?:
Code:
function Vec2(_x, _y) {
  x = _x;
  y = _y;
}
var foo = new Vec2(0, 0);
I have x and y and hspeed and vspeed, why am I trying to some sort of Vec2 stuff? I have a goblin with a sword and a red goblin has a shield and they have hitPoints and die when they're out of hitPoints, what part of that should be in Vectors or classes using these cool new features instead of just doing stuff the usual (presumably inefficient) way? It sort of feels like a lot of the examples I've been seeing are tailored toward "you could make a cool spreadsheet database program with a million items in just 10 lines of code!" lol ok great but what exactly do I DO with that ability if I'm making Mega Man? How do I apply it to an actual game?

Like I totally WANT to learn and understand this so I can upgrade my coding skill and write better code etc, but it's really hard to see how this foo bar vec2 stuff all fits together in terms of actually making a game lol

Anyway, with this being such an advanced concept that's going to probably be confusing to a lot of GML users at first since the userbase is a ton of beginner programmers often totally new to programming at all, for anyone who's doing tutorials: could you tailor them toward something less abstract and more "this is how it would benefit you to learn this and speed up your game development and help organize your code better etc, newbie programmer!"

I just want so bad to be able to use and understand all these cool new features like the advanced guys do ahhh!! lol
 
Last edited:
B

Big_Macca_101

Guest
Had started to give up hope with GMS2 but after seeing all these changes I think I've done a full 180 on that, super excited to jump into this update when it's released and see what I can break!

GML QUESTION: With the addition of lightweight objects and functions, will we have an official way of doing namespaces at all? Because yes we could do globalvar but I think we all know why that isn't ideal
GML QUESTION: When the 'new' operator and lightweight objects are added as well as the foreach statement, will we be able to check for lightweight objects as if they were classes?
 
Last edited by a moderator:
A

atmobeat

Guest
A tiny request for the people who are psyched about doing tutorials (and that's super appreciated, all the tutorials and examples are what make GM so easy to learn):

Most of the tutorials I've seen for stuff like classes and components and polymorphism etc are super abstract "foo & bar" examples that I'm sure make complete sense to advanced programmers, but to us amateur level guys where GML is our first real coding language it can be hard to see where super abstract examples like that fit into the puzzle of gameDev and it becomes like "this seems complicated to learn, and I can't really see how it would apply, so I think I'll just stick to the old inefficient way of doing things because I don't really get what this is for"

Same with examples that have no real relation to actual gameDev like "mammals have fur and teeth and eyes, but the bird class will have wings, but if the birds are African swallows then they have carrying abilities so we could have another sub class and..." But then I open up some open-source game or like the Doom source or something and they just have players and enemies so I'm thinking "is this stuff just overkill? Is it only for making a AAA MMORPG or simulation game or something with 50000 different features? Is this beneficial for making just an action game like Mario or a shootemup or is it just over-complicating things? Would Pong or Tetris or Pac-Man have any use for classes and polymorphism and components?"

Like I know it sounds dumb lol but why do I want to do this?:
Code:
function Vec2(_x, _y) {
  x = _x;
  y = _y;
}
var foo = new Vec2(0, 0);
I have x and y and hspeed and vspeed, why am I trying to some sort of Vec2 stuff? I have a goblin with a sword and a red goblin has a shield and they have hitPoints and die when they're out of hitPoints, what part of that should be in Vectors or classes using these cool new features instead of just doing stuff the usual (presumably inefficient) way? It sort of feels like a lot of the examples I've been seeing are tailored toward "you could make a cool spreadsheet database program with a million items in just 10 lines of code!" lol ok great but what exactly do I DO with that ability if I'm making Mega Man? How do I apply it to an actual game?

Like I totally WANT to learn and understand this so I can upgrade my coding skill and write better code etc, but it's really hard to see how this foo bar vec2 stuff all fits together in terms of actually making a game lol

Anyway, with this being such an advanced concept that's going to probably be confusing to a lot of GML users at first since the userbase is a ton of beginner programmers often totally new to programming at all, for anyone who's doing tutorials: could you tailor them toward something less abstract and more "this is how it would benefit you to learn this and speed up your game development and help organize your code better etc, newbie programmer!"

I just want so bad to be able to use and understand all these cool new features like the advanced guys do ahhh!! lol
I have to agree here. I immediately see how useful chained accessors, methods (especially with named arguments), and exception support all are. And I can kind of see how flexible lightweight objects are, but I don't see how LOs will make certain things easier to do with all the 'foo' and 'bar' talk. So I want to support this plea to the community of tutorial makers to show us how to use these things to speed up game dev and just generally do things that we couldn't before these changes.
 

matharoo

manualman
GameMaker Dev.
Just making sure; the [x, y] syntax for arrays will still work after the update, right? And the array_length_2d() function calls will stop working and will need to be updated?
 
I

immortalx

Guest
...so I think I'll just stick to the old inefficient way of doing things because I don't really get what this is for
With the exception of using what we currently have as objects, as data containers, the "old" way is NOT inefficient. It's just difficult to produce code that is organized and maintainable when it comes to large projects.
If GML gains some OOP features, it will be a godsend for people who are used to this paradigm, but it doesn't force anyone to program this way. There are experienced C++ programmers to this day, who write code in a procedural C style way without ever having to type the "class" keyword.
So it's just a larger toolbox (the OOP features specifically) that won't necessarily change a thing for you or me, if all we want to do is program small games. And because efficiency was mentioned, it's OOP that is sometimes considered inefficient (when misused) and not the other way around. In the end, everyone should be happy with a richer language.
 
the "old" way is NOT inefficient. It's just difficult to produce code that is organized and maintainable when it comes to large projects.
Right, that's all I mean lol I know programming debates can get heated about what's the right way and wrong way to do things but I just mean as a newbie all this stuff that's about to be added seems like the next "level" of options available that absolutely have some kind of awesome purpose but it's a huge jump conceptually from just doing everything straight-forward and ending up with spaghetti code...it's like someone giving you a key but you don't know what lock it's for, you just know it'll unlock something that would be really useful even if it's just for certain situations.

Like most of us who are coding in GML as our first language probably aren't programming "procedural" because we WANT to...we're doing it because we just don't know any other way...but I'm sure like atmobeat and I, we really WANT to have that other option at our disposal lol It's like I KNOW there's something super valuable in these new features especially since everyone is so excited about them and has been asking for them for so long, but it seems like a completely different way of thinking and I can't see the applicable benefits yet beyond if I need to make different mammal types I can say which ones have wings or arms and I'm not sure why that's better than saying "has_wings = false; has_arms = true;" in an obj_human and obj_bat Create Event over the course of a project VS as some kind of programming demonstration exercise lol

I have to agree here. I immediately see how useful chained accessors, methods (especially with named arguments), and exception support all are. And I can kind of see how flexible lightweight objects are, but I don't see how LOs will make certain things easier to do with all the 'foo' and 'bar' talk. So I want to support this plea to the community of tutorial makers to show us how to use these things to speed up game dev and just generally do things that we couldn't before these changes.
Ya I'm only bringing it up in this thread because I saw a few people who sound psyched to write tutorials to help us newbies bring our coding skills up to speed and the scope of these new features seems like without good tutorials it could create a divide between beginner coders who can't pass that advanced coder wall, and the pro coders who are working magic with GameMaker...sort of like how the people using D&D would have an impossible time learning GML if there weren't so many incredible tutorials out there to learn from.

So just as one of the beginners who's been wanting to figure this stuff out for a while, I thought I'd drop in and explain what's probably a common perspective for us where the abstract stuff and non-gameDev related examples of "here's an example of a payroll that pays out every February and December for Steve and John but Sarah gets paid on the 3rd Wednesday of every month and you can do that with this function setup" is like "where the heck do I use this to get the most out of it when I'm making a Pac-Man game to practice and learn what to use this for? Do I have classes and functions for anything that can move at all and has hitpoints at all, menu buttons have an x/y should they use the same class as the enemies and my player? do I just use this for a few major things in a project or is there some benefit to having literally everything in the game use these things? Should I lump stuff together, is more classes better or is that just making things overly complicated for no reason, what's the benefit of this over the Inheritance stuff that's already in there??"

I'm confused but excited to improve!
 

Pfap

Member
Woah this was totally unexpected! Awesome news! I can't even imagine a question @FrostyKat hasn't covered lol but that huge list of "what about this situation?" is a good reminder of how much work goes into adding features like this, massive thanks to the YoYo team for all the hard work!

I've been trying to learn about classes and entity component systems and polymorphism etc from non-GML tutorials but I'm too amateur a coder to grasp a lot of it once they start going into each specific language's complicated looking syntax in examples...I know there's something in there that can make doing games way cleaner and more organized but trying to understand it and then trying to figure out some kind of workaround to it in GML right now is overwhelming.

A tiny request for the people who are psyched about doing tutorials (and that's super appreciated, all the tutorials and examples are what make GM so easy to learn):

Most of the tutorials I've seen for stuff like classes and components and polymorphism etc are super abstract "foo & bar" examples that I'm sure make complete sense to advanced programmers, but to us amateur level guys where GML is our first real coding language it can be hard to see where super abstract examples like that fit into the puzzle of gameDev and it becomes like "this seems complicated to learn, and I can't really see how it would apply, so I think I'll just stick to the old inefficient way of doing things because I don't really get what this is for"

Same with examples that have no real relation to actual gameDev like "mammals have fur and teeth and eyes, but the bird class will have wings, but if the birds are African swallows then they have carrying abilities so we could have another sub class and..." But then I open up some open-source game or like the Doom source or something and they just have players and enemies so I'm thinking "is this stuff just overkill? Is it only for making a AAA MMORPG or simulation game or something with 50000 different features? Is this beneficial for making just an action game like Mario or a shootemup or is it just over-complicating things? Would Pong or Tetris or Pac-Man have any use for classes and polymorphism and components?"

Like I know it sounds dumb lol but why do I want to do this?:
Code:
function Vec2(_x, _y) {
  x = _x;
  y = _y;
}
var foo = new Vec2(0, 0);
I have x and y and hspeed and vspeed, why am I trying to some sort of Vec2 stuff? I have a goblin with a sword and a red goblin has a shield and they have hitPoints and die when they're out of hitPoints, what part of that should be in Vectors or classes using these cool new features instead of just doing stuff the usual (presumably inefficient) way? It sort of feels like a lot of the examples I've been seeing are tailored toward "you could make a cool spreadsheet database program with a million items in just 10 lines of code!" lol ok great but what exactly do I DO with that ability if I'm making Mega Man? How do I apply it to an actual game?

Like I totally WANT to learn and understand this so I can upgrade my coding skill and write better code etc, but it's really hard to see how this foo bar vec2 stuff all fits together in terms of actually making a game lol

Anyway, with this being such an advanced concept that's going to probably be confusing to a lot of GML users at first since the userbase is a ton of beginner programmers often totally new to programming at all, for anyone who's doing tutorials: could you tailor them toward something less abstract and more "this is how it would benefit you to learn this and speed up your game development and help organize your code better etc, newbie programmer!"

I just want so bad to be able to use and understand all these cool new features like the advanced guys do ahhh!! lol

Yea, I agree with you for the most part. These new additions won't necessarily help with making a mega man game though they may make your life a lot easier when it comes to keeping code that's easily understandable at first glance.
Here is a recent example of how I "bent" gml to a design pattern I learned from javascript.

This script will get data from some input source. In my case it was a player customizing how there character looks.
Code:
//will be player selections which were added into a map from a selection screen
var data = argument0;

 
//where this object is created does not matter as it is just for storing data
var inst = instance_create_depth(x,y,-1000,data_state_player);
inst.name = ds_map_find_value(data,"name");
inst.color = ds_map_find_value(data,"color");
inst.wins = ds_map_find_value(data,"wins");
inst.losses = ds_map_find_value(data,"losses");
inst.levels = ds_map_find_value(data,"levels");

//when we destroy the map this list will be destroyed so read into the list created in the inst
var player_list = ds_map_find_value(data,"player");//this map also has a list with the items the player has
var items = ds_list_size(player_list);

inst.size = items;

var add = undefined;
var j = items-1;
repeat(items){
 
 add = ds_list_find_value(global.pseudo_index,real(ds_list_find_value(player_list,j)));
 ds_list_add(inst.player_list,add);
 j -= 1;
}
 
 
//the below will get destoryed when the full json decode is destroyed
//ds_map_destroy(data);


// I can access the properties of the data_state_player from the id stored in the variable inst
return inst;

The above is a function that creates an object which just stores the state of the object at that point in time. It's values can be accessed by using the return value and dot notation.
You could have a megaman game with thousands of these objects that were all constructed by the player and all you wrote was the little code above. This is especially useful with any networked code as you can just pass these properties to the server and use the same script to construct a player on the client.

The new light objects will really be a better way to handle what I am doing above as I don't really need an object I just needed a way to access the data. Although, now after typing this I am wondering to myself why I just didn't create a global map.....
Hmmm, there must have been some reason.



Edit:
This really is my main struggling point with GameMaker and game making in general. There is so many different ways to do things and as soon as I pick one way I find a way I like better or just wham something together. I wish there was a more concrete design paradigm to making games. I suppose it will come with experience.
 
Last edited:
Code:
//where this object is created does not matter as it is just for storing data
var inst = instance_create_depth(x,y,-1000,data_state_player);
inst.name = ds_map_find_value(data,"name");
inst.color = ds_map_find_value(data,"color");
inst.wins = ds_map_find_value(data,"wins");
inst.losses = ds_map_find_value(data,"losses");
inst.levels = ds_map_find_value(data,"levels");
This part is what I see in a lot of the class tutorials and all I can think is "but if I just made an obj_data with name, color, etc all set to defaults in it's Create Event then made an obj_player a child to it and just use event_inherited() and change the name, color etc that need to be customized to it, isn't that the same with way simpler code?":
Code:
//obj_data
//Create Event
name = "";
color = c_white;
wins = 0;
losses = 0;
levels = 0;

//obj_player (child of obj_data)
//Create Event
name = "Player";
color = c_yellow;
losses = 2;

//obj_enemy (child of obj_data)
//Create Event
name = "Enemy";
color = c_red;

And to access the data I'd just be using:

obj_player.name
obj_enemy.color
And that's where it gets confusing for me personally...like I know there's a benefit to doing it the more elaborate way but I just don't understand exactly what yet lol

The two things I've gotten it narrowed down to in my head is:

1) you can have a Dog and Cat both call a "talk();" script instead of having "dog_talk()" and "cat_talk()" so that one will say Bark while the other says Meow but it's like is that the same as just having a string_to_say = "Bark!" and calling talk(string_to_say), or just having a script you can fill text into like talk("Bark!")?

2) Parenting only lets you go down a chain and call everything at once in one big event_inherited(); command but this would let you work in more of a mix & match component style and you could call parts of a Parent(? or Class?) in various orders for more customization of what gets handled when, which I could definitely see benefits to if I'm understanding that right

I feel like an idiot asking this stuff, I'm sure these are such newbie questions lol but I'm honestly trying to understand the benefits of this new superpower we're about to get and where/how I can apply it and why and I'm super excited that there could be some tutorials on this written using actual GML instead of trying to decipher the syntax of other coding languages and having to learn what "void" and "New" and "* Extends virtual void (%int var vec2(x,y,z))" means just to get a grasp of what would apply to coding a game in GML lol

I wish there was a more concrete design paradigm to making games. I suppose it will come with experience.
Ya I'm not trying to be lazy here and sound like "just hold my hand and tell me how to make my game", I know stuff like this takes tons of practice and experience to really use properly...I just feel like once you've understood this stuff for a while it can be hard to remember how confusing it was to look at for the first time so I wanted to bring it up while everyone is so excited about these new features. :)
 
Last edited:

Pfap

Member
This part is what I see in a lot of the class tutorials and all I can think is "but if I just made an obj_data with name, color, etc all set to defaults in it's Create Event then made an obj_player a child to it and just use event_inherited() and change the name, color etc that need to be customized to it, isn't that the same with way simpler code?":
Code:
//obj_data
//Create Event
name = "";
color = c_white;
wins = 0;
losses = 0;
levels = 0;

//obj_player (child of obj_data)
//Create Event
name = "Player";
color = c_yellow;
losses = 2;

//obj_enemy (child of obj_data)
//Create Event
name = "Enemy";
color = c_red;

And to access the data I'd just be using:

obj_player.name
obj_enemy.color
And that's where it gets confusing for me personally...like I know there's a benefit to doing it the more elaborate way but I just don't understand exactly what yet lol

The two things I've gotten it narrowed down to in my head is:

1) you can have a Dog and Cat both call a "talk();" script instead of having "dog_talk()" and "cat_talk()" so that one will say Bark while the other says Meow but it's like is that the same as just having a string_to_say = "Bark!" and calling talk(string_to_say), or just having a script you can fill text into like talk("Bark!")?

2) Parenting only lets you go down a chain and call everything at once in one big event_inherited(); command but this would let you work in more of a mix & match component style and you could call parts of a Parent(? or Class?) in various orders for more customization of what gets handled when, which I could definitely see benefits to if I'm understanding that right

I feel like an idiot asking this stuff, I'm sure these are such newbie questions lol but I'm honestly trying to understand the benefits of this new superpower we're about to get and where/how I can apply it and why and I'm super excited that there could be some tutorials on this written using actual GML instead of trying to decipher the syntax of other coding languages and having to learn what "void" and "New" and "* Extends virtual void (%int var vec2(x,y,z))" means just to get a grasp of what would apply to coding a game in GML lol


Ya I'm not trying to be lazy here and sound like "just hold my hand and tell me how to make my game", I know stuff like this takes tons of practice and experience to really use properly...I just feel like once you've understood this stuff for a while it can be hard to remember how confusing it was to look at for the first time so I wanted to bring it up while everyone is so excited about these new features. :)

Whoops, the stuff in the edit section of my post was just me being reflective to myself not telling you to stop being lazy. Just musing to myself that I hope it gets better with experience...
Anyways, OOP has faced plenty of criticism and I'm not sure it's better than anything else... at this point I almost think there is no such thing as clean code it's all spaghetti.
 
Whoops, the stuff in the edit section of my post was just me being reflective to myself not telling you to stop being lazy. Just musing to myself that I hope it gets better with experience...
Anyways, OOP has faced plenty of criticism and I'm not sure it's better than anything else... at this point I almost think there is no such thing as clean code it's all spaghetti.
I didn't take it that way, I was just thinking out loud too. I know I hate when I see lazy "my game won't compile what does this "variable doesn't exist" error mean FIX IT FOR ME SO I CAN MAKE MY MMORPG!!" comments on tutorials so I'm trying to pre-empt sounding like that with all these questions...but I feel like this is a pretty big leap for the target audience of GameMaker's average skill level so I hope I'm asking stuff other "GML is my first language" gameDevs were thinking when they read about these new features. :)

I've made a lot of progress with coding more organized with less spaghetti mess this year so any new stuff I can learn that helps get even cleaner is huge to me. I can't wait to finish my current game and get started on the next just so I can start from scratch with all the stuff I've learned working on my current game...maybe I'll make it to at LEAST the halfway point before I start having no idea wtf my code does anymore and pull out the duct tape!
 
@BPOutlaws_Jeff I just wrote a post about using the Command Pattern for Undo/Redo feature in an editor :

https://forum.yoyogames.com/index.php?threads/undo-redo-in-game.61709/#post-371785

It uses objects to save the previous x and y and the instance id of the object that was moved.

This is an example where a lightweight object with a couple of functions attached would be ideal.

Rather than having to store the data in an object which comes with all the built in variables, plus having to use one of the precious few User Events of an object for performing the undo operation, I could make a Light Weight object that only has the info needed, plus a couple of custom named functions that I could call to perform the undo.

The polymorphism example with Cats and Dogs is a good example however of data encapsulation, where the Cat and Dog both have a Speak() function, and you can keep a bunch of cats and dogs in a data structure and you only need to call the Speak() function on the object without having to know the implementation details.

It lets the Cat manage its own data separately from the Dog, keeping the code clean and decoupled.

As you pointed out the "GML Way" has been in the past to have a Parent object with a string animal_sound = "Woof" that you then override in the childs create event.

Instead you could use a component based approach with lightweight objects.

An animal object could have a value/property called talk = undefined.

Then, when you create an animal object, if that type of animal need to talk, you assign a function to the talk variable.

When processing, the animal just checks if talk has been defined or not, and if it has, then it calls the talk() function. This means no deep chains of inheritance/parenting required, and each object only contains what it needs to run, without inheriting stuff that it won't be using.

To be fair, I'm actually a bit rusty on some of this stuff, so anyone feel free to correct me if I'm wrong.

But what's exciting about all these changes to GML is the possibility of much more efficient lightweight ( :) ) management of code and data structures. As well as the better ability to implement established programming patterns and paradigms that will make managing larger projects cleaner.

I've got hundreds of scripts in my current project, many of which are only meant for a certain type of object. I should be able to now group all those scripts into one file as their own functions, and have them only apply to one type of object.

If you haven't seen it before, Game Programming Patterns is a quite user friendly introduction to various Design Patterns with games in mind : http://www.gameprogrammingpatterns.com/
 

2Dcube

Member
I use GML because it is quick and simple to make games. I don't use other languages because they are obtuse and pointlessly complex.
Very good points.
I've made 2D games in both Game Maker and a certain engine starting with a U.
Basically when I want to make something with class based languages like C#, first I need to spend a lot of time setting up classes, before I can finally get something running.
I made a bunch of functions that basically replicated a lot of Game Maker behaviour, and only then could I prototype some ideas fairly quickly, but it was like writing a small 2D game engine.

Game Maker is great because you can type a few lines and have simple game mechanics you can test fairly quickly. I hope it stays that way: fast, agile, simple.
 

Zhanghua

Member
I think the most important thing is How to Keep the Data Save and Load more easy and reliable!!!!!!!!!!!!!!!!!!!
In current version the mix ds type such as A[? a] = B; where B is a list, the save and load is not comfortable!
 

Kenshiro

Member
This is a step in the right direction. Improve the language+IDE stability and GMS improves 200%.
One hope is that YoYo change the fact that you have to use a function to define a 'class'. I'd rather just use the term 'class' just to make things less confusing. Then change the name of objects to 'Actors' or something.
Having classes with private, public and static methods would be pretty cool. Hopefully they will extend the lightweight object syntax to be more "class-like".
 
A

Andy

Guest
This sounds exciting. :)
Looking forward to lightweight objects and infinite dimensional arrays.
I need to learn more about the other features before commenting on them.
 
Last edited by a moderator:

Nux

GameMaker Staff
GameMaker Dev.
I think using functions as constructors is pretty obvious. You're not defining a class, you're filling an empty "light-weight object".

Instead of doing
Code:
var position = {};
position.x = 0;
position.y = 0;

/* Compared to an array, this would be:
 * var arr = [];
 * arr[0] = 0;
 * arr[1] = 0;
 */
You could use the literal syntax
Code:
var position = {
    x : 0,
    y : 0,
};

/* Compared to an array, this would be:
 * var arr = [0,0];
 */
In both cases you are not defining a class, you are adding elements to an object like you would to an array.

You could even use a function to do this, by passing the object as an argument.
Code:
function build_vector(_vec, _x, _y) {
    _vec.x = _x;
    _vec.y = _y;
};
var position = {};
build_vector(position, 0,0);
Or, you can use the "new" operator, which automatically changes the object scope to _vec, so you don't need to do _vec.x and _vec.y
Code:
function Vector(_x, _y) {
    x = _x;
    y = _y;
};
var position = new Vector(0,0);
Which is far prettier and easier to manage.
 
Last edited:

FrostyCat

Redemption Seeker
@2Dcube @BPOutlaws_Jeff @hdarren @atmobeat @Miradur

I think posts like yours are addressing people like me who support the OOP shift in GML, so I'll respond to the three main themes among those posts as a counter-narrative. Hopefully then you'll see the other side of the argument, and how people like me are actually fighting in your favour.

The first is the apparent accusation that I'm throwing off novices on purpose with placeholder names in the examples I used on two previous posts.

I'll clarify right now that those were NOT intended as practical examples, but synthetic examples designed to attack or question YoYo's design decisions. Someone at my level wouldn't leave variables named foo and bar in a production-level project, and for a practical example I'd at least give some context and use more descriptive names. But some of the forms can manifest in live code just under different names, either as intended design (e.g. mix-in inheritance) or as the result of carelessness (e.g. forgetting the new operator), so they have to be raised in generic form.

The second is this sentiment about how introducing OOP in GML is intended to cater only to skilled hands and alienate novices.

Code in a game development setting typically falls in 2 categories:
  • Action-driven code: Code that deals with overt action and has a direct presentation to a player. Examples include code dealing with graphics, audio, movement, collision and I/O.
  • Data-driven code: Code that deals in background bookkeeping or abstract data and do not have a direct presentation to a player. Examples include code dealing with saving and loading, scorekeeping, stat management, relationships between agents, or abstract board states.
All games have components in both, though in different proportions and degree of interdependence. Yet mainstream GM education has a chronic bias against the latter, and students learning under it are inappropriately taught to do everything in action-driven space. The OOP additions to GML are mostly designed to address data-driven concerns, so YoYo would appear to be turning its back on novices, even though its intention is to make data-driven code easier for everyone.

Now look at all the things you claimed on this topic are "novice needs" for making a game. They are all superficial action-driven concerns that naturally come from the uninitiated. But have you ever stopped to consider data-driven concerns in a game's design, or even been taught to in the first place? You're like a handyman whose only tool is a hammer and for whom every job looks like a nail. You've been struggling with cutting 2-by-4s by beating it until it snaps, and when the hardware store announces that it's stocking better saws, you whine about how they should instead stock better hammers to serve you.

All of this community banter about how data structures, JSON and abstract modelling are "advanced" material is absurd to me. These are the most basic techniques in data-driven code, just as collision handling, drawing or keyboard/mouse input are in action-driven code. They're not difficult, just foreign to GM users who have only seen one side of the coin. If mainstream GM tutorials didn't teach you to handle action-driven code, common fare like place_meeting(x+hsp, y, obj_wall) or y += vsp; would be no less "difficult" to you, and you'd say that's also shibboleth intended to alienate novices. This is a 20-year-old problem with bias in GM's education system and ongoing development, and it's making you all confuse foreignness with actual difficulty.

The OOP update is for everyone regardless of skill level, and it's especially for people who have been underexposed to the other side of the action-data coin due to GML's past decision to divest from the data side. There will be incentives from now on to make GML less awkward in more contexts and usable for all.

The third is this constant insinuation that OOP is not applicable in general GM development, and won't add to what's already doable.

One of you questioned how the addition of OOP would help a beginner develop Tetris. Funny you'd mention that in particular, because Tetris is an example of a game that should be built upon an abstract data-driven foundation, and only handle I/O and presentation in action-driven space. In Chess, you don't state moves in terms of physical measurements like "pawn 1.5 inches forward", you state moves in terms of abstract square positions like "pawn to d4". The grid-centric nature of Tetris puts it in the same league as Chess. Many mainstream GM tutorials are encouraging the same absurdities as the "pawn 1.5 inches forward" anti-example, except the unit is pixels instead of inches.

Here's a rough example of what the centrepiece of the data-driven approach might look like:
Code:
function TetrisGameState() {
  board = [...];
  next_piece = ...;
  current_piece = ...;
  current_piece_offset = [..., ...];
  turn = function() { ... }; // Rotate current piece
  move = function(horiz_change) { ... }; // Move current piece left/right
  drop = function() { ... }; // Drop current piece
  tick = function() { ... }; // Make one in-game step
  // Other helpers here
}
A traditional controller object would hold a single game state, call tick() periodically and forward user input to turn(), move() and drop(). Visual board element objects would be "dumb" (i.e. hold no board-specific logic) and implement the observer pattern only to keep synchronized with its slice of the game state.

Why do it this way instead of going with the herd? I can list a whole host of features that building on a foundation of this would be straight-forward, where an equivalent mainstream action-centric implementation would struggle or needlessly duplicate code.
  • Fine tuning the animation of board elements (make it observe developer keystrokes or commands instead of a live state)
  • Changing sources of input (just use a different object to listen and then manipulate the state)
  • Pausing (just stop calling tick() and the other input methods in one place)
  • Replay (source of input is just a log of method calls)
  • Resolution independence (just change the square sizes and starting coordinates)
  • Automated testing of input behaviours (scripted input with expected comparison targets for board)
  • Automated testing of unwanted movement in corner cases and regressions (same as above)
How many of these do current GM games do improperly? How many of these commonly get the undeserved label of being "advanced" or "complex"? Given how basic data-driven operations have been neglected for so long, can you see why YoYo's showcase is basically a collection of 2D pixel/neon-geometric action games?

The addition of OOP is highly applicable to GML development, and learning and documenting these new OOP patterns will take GML to places where the general user community used to stick "do not enter" signs in front of.
 

Sammi3

Member
This is a step in the right direction. Improve the language+IDE stability and GMS improves 200%.

Having classes with private, public and static methods would be pretty cool. Hopefully they will extend the lightweight object syntax to be more "class-like".
You know what would be cooler? Remember when DnD used to be it's own thing and then they made DnD based on GML? I hope for a future where GameMaker Objects (Let's just call them Actors now please) are just a heavier version of what we now call lightweight objects and are there as a tool for people with little programming experience. So the GameMaker pipeline would be: DnD -> Actors with functions -> Creating your own types of objects from code and implementing them in your own way through the use of Actors. I do admit though, this is a pipe dream.
 
The first is the apparent accusation that I'm throwing off novices on purpose with placeholder names in the examples I used on two previous posts.
I gotta clarify there's NO accusation in what I'm saying lol I don't know about the other guys but I 100% know it's not some kind of intentional "I'm gonna keep this too confusing for them" thing, at ALL! I know there's some kind of history of beginner programmers VS advanced programmers battling over "don't ruin the language with advanced features!" with GameMaker but I don't care about any of that stuff lol

I'm totally just throwing out some ideas to help tutorial writers bridge help us all bridge the gap because I saw above above that you wrote "Most GM users have never been properly taught the other side of the coin. That's at fault here, rather than var actually being difficult." and @JeffJ wrote "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" and I think those are awesome attitudes because we all want everyone to make the coolest games they can make with GameMaker, so I wanted to give some perspective on how to help us newbies learn from tutorials easier as someone who's been trying to cross that final hurdle of really grasping this new stuff we're about to get looking at tutorials from other programming languages that tend to be super abstract or talking about making payroll payment processors lol

(I ran into that exact var situation you mentioned, I first saw var and was like "I dunno, this seems complicated, I can just make variables and they work, what do I care about memory management (as if that was the only benefit) I'm not making Metal Gear Solid 6 here!" and avoided using var for a while until I sat down and looked at every post video etc about the benefits of using var and I saw a couple key posts that made it click for me (like FriendlyCosmonaut's amazing tutorial that shows how you can avoid calling other.variable using a local variable and someone else wrote something on the forum about using loops inside loops with the same local variable etc) and then I found var wasn't actually hard at all, it was just a foreign concept to me and I just needed to understand what the point was and now I use them exactly how they're supposed to be used and I use them religiously! It's like when I learned I could just loop through an array instead of having a thousand IF...THEN statements lol)

And your post with all those questions goes almost completely over my head but I wasn't referring to those posts at all, I know the YoYo guys will know what you're talking about and you're just putting down no-nonsense get-to-the-point questions directly for the guys who will understand it right away.

It's purely just that the foo bar stuff on the first page reminded me of something I could bring up for the tutorial & documentation creators because I ran into so much of it in tutorials for other languages...that super detailed foo bar question list is exactly why we're lucky to have you advanced guys to ask those questions because you know exactly what to ask YoYo to help make sure these features come out rock solid. (I read through your questions trying to visualize and understand them just to learn lol) I'm in awe of that question list quite frankly...but that's also why I'm posting in this thread, 'cause this thread happens to have the eyes of everyone who understands this stuff and some people who might write tutorials. :)
The second is this sentiment about how introducing OOP in GML is intended to cater only to skilled hands and alienate novices.
Honestly I don't know what that stuff is about. This all looks optional to me so I don't see any problems with giving us more ways to approach things, especially if there's great documentation & tutorials that explain it. I think a lot of people come to GameMaker because the other languages are too intimidating to learn and other language's tutorials come with extra stuff like allocating memory and stuff that 99% of us are fortunate enough to not have to worry about thanks to GM's design so there's probably some fear about it becoming as hard to get into as other languages but I really don't see that being the case here. We're just getting more freedom!

and students learning under it are inappropriately taught to do everything in action-driven space
They're not difficult, just foreign to GM users who have only seen one side of the coin
This is a 20-year-old problem with bias in GM's education system and ongoing development, and it's making you all confuse foreignness with actual difficulty.
Right, that's all I'm talking about here...is how to help us "this is our first programming language" guys (which I assume are the majority of the users of GM) wrap our heads around this huge paradigm shift that these new features will bring in so that there's none of this "oh that stuff is ADVANCED, they're just catering to the advanced guys, that's not for me to bother learning" resistance to learning more coding approaches.

I'm basically just saying "for anyone who wants to tell a story, if you could use hand puppets instead of just words it would really help us to grasp these new concepts easier" lol That's all! And I know anyone writing a tutorial is wanting as many people to find it useful as possible so this is sort of to help everyone in general. :)

One of you questioned how the addition of OOP would help a beginner develop Tetris. Funny you'd mention that in particular, because Tetris is an example of a game that should be built upon an abstract data-driven foundation
That was me! And I tried my best to make it clear in my posts that none of this is any kind of sarcastic accusation like "pfff why would I use THAT, that's dumb I can saw this 2x4 with my hammer!" but I knew I was wading into rocky waters because there's the strangest (from the outside) heated clashing over this stuff in the GM community where we have such a mix of knoweldge levels.

But honestly what you just wrote as a rough example (thanks for writing it!) is exactly the stuff I'm legitimately trying to understand and hoping tutorials will be able to explain the way you just did, like I didn't know how to apply this way of approaching things to a game I'm familiar with like Tetris but just from the rough example you wrote I can already better understand "ohh so THAT'S what I would use functions for" and the list of reasons you wrote for doing it this way are like "I see, that makes complete sense, I get why it would be done this way!" because it's in an example of an actual game VS how to send out a payroll on every other month lol

where an equivalent mainstream action-centric implementation would struggle or needlessly duplicate code
Right, that's why I brought all this up...I can TELL I'm doing something "not optimally" or "with more struggle than is probably necessary" but trying to grasp how to use that saw instead of a hammer is a bit of a learning curve and I just want to help tutorial makers know how best to help us learn to use the saws. :)

The addition of OOP is highly applicable to GML development, and learning and documenting these new OOP patterns will take GML to places where the general user community used to stick "do not enter" signs in front of.
I agree completely! I'm excited to learn this new stuff! And again tons of thanks to everyone who takes the time to make tutorials and help make things easier for us beginner programmers to get our footing!
 
Last edited:

Sammi3

Member
I think using functions as constructors is pretty obvious. You're not defining a class, you're filling an empty "light-weight object".
There are some of us 'extremists' who basically just want C++ but in GameMaker. So getting even naming conventions similar is a priority :p
 
I just wrote a post about using the Command Pattern for Undo/Redo feature in an editor
Awesome! Thanks for the reply! So you would have similar code for the Undo stuff but using a LWO and you'd have like a "function undo_move()" instead of having a whole bunch of separate "obj_undo_move" "obj_undo_draw" "obj_undo_scale" objects, and then probably other undo_move, undo_draw, undo_scale functions all inside a big "undo" script collection or inside the LWO, if I understand this right...or maybe like an "lwo_undo" with some kind of "function undo()" and somehow inside THAT would be move() draw() scale() that just by being inside "undo" it would know "move()" means "undo the move action"?

That's the thing I THINK I understood too from other language tutorials, is that it's like you could have a Dog and a Bat calling "move()" but the Bat would run code that handles flying with direction/speed stuff, while the Dog runs code that handles walking on the ground using x/y stuff, but both would just use "move()" instead of having "move_flying()" and "move_ground()"...?

And just not having to deal with User Events would be cleaner for sure, I've avoided using those as much as possible because they feel so awkward. So it isn't even necessarily that you can do things you couldn't DO before, it can be more about organizing and reusing code better & cleaner in some cases, it sounds like.

When processing, the animal just checks if talk has been defined or not, and if it has, then it calls the talk() function. This means no deep chains of inheritance/parenting required, and each object only contains what it needs to run, without inheriting stuff that it won't be using.
This makes more sense...from what I was piecing together from other languages it looks like part of the function stuff is about "if it doesn't have this function defined in it then you literally can't call it" which probably helps keep things organized and less prone to sloppy errors, like if there's a function speak() in that "lwo_animal" lightweight object, but my obj_dog isn't inheriting(extended? New-ified?) that lwo_animal it would give a compile error if I tried to tell it to speak(); ...or I wonder if that wouldn't be applicable since GML scripts are global? I'm sure this will all be explained down the road, I'm just thinking out loud here! :)

I've got hundreds of scripts in my current project, many of which are only meant for a certain type of object. I should be able to now group all those scripts into one file as their own functions, and have them only apply to one type of object.
This is the kind of stuff I'm excited about, where I'm not sure exactly how I would reduce my millions of scripts down yet but I'm sure that with tutorials and examples it'll be clear that "oh wow I can reduce all this mess into this nice organized collection holy crap!" lol

Thanks for the link to Game Programming Patterns! I checked it out a while back and actually forgot about it...GPP uses great examples in their explanations which is totally what I'm trying to describe here about where it's like "here's how you would actually use this in a game, say you have a monster and he needs to..."

But there's a lot of non-GML stuff like "public/private(??) void Bjorn& Bjorn (*this) static const int" that I've slowly learned to decipher my way through to get to the meat of what's being explained, but that stuff was super confusing at first and scared me off the examples like it probably would to a lot of "GML is my first programming language" users which ends with us doing things the "hard" way instead of fully using these patterns...so I'm super psyched that we'll get to see tutorials and examples of these things but in actual GML where it's nice and clear and we can all be using these patterns in our projects instead of googling "wtf is void, why are some variables private, is there an equivalent to private/public in GML that I need to understand to use this?" just to try to grasp the examples.

God I don't know how to make myself not sound like the worst and laziest coder in the world when I type these posts lol I was getting cocky like "oh ya I understand var and ds_grids and shaders, I'm basically a pro now" and then I wrote all this and I'm like "jeeze I don't actually know anything yet!!" lol but that's the fun of the journey.
 
Last edited:
S

SrpskiCekic

Guest
Strides towards a more OO Game Maker and robust GML makes me really excited for its future.

GML QUESTION: Do you have plans & your thoughts on Multi threading support in GMS2? Also, the same question about run-time code compile?
 
Last edited by a moderator:

Tthecreator

Your Creator!
GML QUESTION: 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?
 

Hyomoto

Member
This was needed over a decade ago...
Great, we can now create 1 large script vs supporting scripts.
However, I think we finally need a class system so something like this.
Class Hero {
variable = -1;

function add(x) {
x += variable;
}
}
That's what the lightweight objects will allow. If your purpose is just to create tables of data and functions that can operate on them, just replace your class hero with "Hero = {" and voila. I think Yoyo chose lightweight object as a description, rather than something else, because that's the way the request has always been phrased. However, if you are looking for a way to inherit that, then objects will probably still be your go-to, but now you can bind functions. Which, would be similar to what you wrote above as well.
 

gnysek

Member
This was needed over a decade ago...
Great, we can now create 1 large script vs supporting scripts.
However, I think we finally need a class system so something like this.

I think you didn't readed the blog post until end. There are two examples of "classes" - in "lightweight objects" and " 'new' operator" sections.
 

Sammi3

Member
GML QUESTION: 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?
I believe a reference to the object. Considering that YoYoGames would probably not want to go down the route of copy constructors at least for now as that would really complicate things. But it's possible and not all that complicated for them to perform a shallow copy.

EDIT:
I would much rather create my own function that does the copying for me. I'm not certain if this has been asked but

GML QUESTION:
Will functions of similar names but different arguments be allowed? As in:

Code:
function Vector(x, y, z) {
    self.x = x;
    self.y = y;
    self.z = z;
}

function Vector(x, y) {
    self.x = x;
    self.y = y;
}
And if so, can you rename 'self' into 'this' ? :D

EDIT:
On second thought, leave it as 'self' to leave GML with it's own identity.
 
Last edited:
Status
Not open for further replies.
Top