• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Question - Code Question About Scoping

11clock

Member
For those who haven't used object-oriented programming languages, a scope defines the accessibility of a variable or method (scripts replace methods in GMS).

Private: Only available in the object that defines the variable or method.

Protected: Only available in the object that defines the variable or method, and its children as well.

Public: Available to any object that has a reference to the object that defines the variable or method. For example: player.HP

Global: Available to any object, not really anchored to the object that defines it.

One of my biggest problems with GMS is that variables can only either be global or public, and scripts can only be global. You can make notes for the variables to help organize them better (although more scopes would be way better), but the killer here is that scripts are global only. This results in very unorganized code that is spread out. If I want a Dog object to Bark(), I have to make the method available to all objects. The only way to really combat this is to organize scripts into folders.

The closest you could get to defining a script to a specific object in GMS is a user event. But you only have so many of these, they cannot be renamed to more sensible names, and they cannot take in arguments.

So I would really like it if GMS2 allows us to have more scopes for variables and, more importantly, scripts. It is absolutely crucial for organizing code in long-term projects, especially object-oriented code.

So will GMS2 have more scoping options for variables and scripts?
 

NazGhuL

NazTaiL
I understand ~ 30% of what oop is. What will you get if only dog can use bark()? I mean, in current gms can you only call that script in obj_dog and thats it? What benefit that only dog can bark?
 
What benefit that only dog can bark?
Simple organization, for one. When you have a million objects in your game, it starts getting ridiculously messy with GML1's way of doing things...
Also, readability. Less mistakes. It's a way to allow you to create pieces of code that work by themselves, and then allows you to stop worrying about them afterward. If I have Dog.Bite(), I know what it does. If I have EntireGodDamnedProject.Bite(), I can't be as sure. Does this Bite have poison, or not? Dog.Bite definitely doesn't, but EntireGodDamnedProject.Bite() might. Hard to remember when you have lots of stuff going on!
 

11clock

Member
I understand ~ 30% of what oop is. What will you get if only dog can use bark()? I mean, in current gms can you only call that script in obj_dog and thats it? What benefit that only dog can bark?
It's called code organization, and code logic. Bark being usable by any object and not being able to attach it to a specific object isn't organized and can make your project look messy, even if you organize scripts into folders representing the objects.

Think of each object like an actor that can do many things. For example, a dog can bark and bite. A cat can meow and scratch. The scripts for barking and biting should be able to be closely attached to the dog object, and meow and scratch should be closely tied to cat. Scopes for scripts would allow this kind of logical connection that you can't do with the current system in GMS.

If you used a real object-oriented programming language, you would understand how important defining scopes is for organizing a lot of code in a project. The idea is to allow the developer to give each variable the minimum scope it needs in order to operate.

The lack of scopes in scripts is one of the main two reasons why I switched from GMS to another game engine, since from my own experience the lack of scoping scripts makes large projects an absolute pain to work on in GMS. If GMS2 adds this basic functionality, it would by itself win me back.
 
D

Drewster

Guest
I'd really like an answer to this as well...this is one of the main things I was hoping to see changed in GMS2!
It's funny how we are all posting about what we'd like to see in GMS2. Now. Ages after how it works has already been decided. :)
 
t's called code organization, and code logic. Bark being usable by any object and not being able to attach it to a specific object isn't organized and can make your project look messy, even if you organize scripts into folders representing the objects.

Think of each object like an actor that can do many things. For example, a dog can bark and bite. A cat can meow and scratch. The scripts for barking and biting should be able to be closely attached to the dog object, and meow and scratch should be closely tied to cat. Scopes for scripts would allow this kind of logical connection that you can't do with the current system in GMS.

If you used a real object-oriented programming language, you would understand how important defining scopes is for organizing a lot of code in a project. The idea is to allow the developer to give each variable the minimum scope it needs in order to operate.
^Of course someone else working on big projects understands why this is so important! =)
So....does anyone have any confirmation whether or not GML has changed at all? The lack of enthusiastic replies is starting to make me worry that GML's core hasn't changed much...
 
It's funny how we are all posting about what we'd like to see in GMS2. Now. Ages after how it works has already been decided. :)
It's funny that I've been asking for this for like three (two?) years, actually. When I asked about scoped variables and such back on the old Suggestions forum, I was told "not in GMS1.0." :p
Now I'm asking "has it been changed in GMS2?" Nobody has confirmed or denied yet!
 
D

Drewster

Guest
It's funny that I've been asking for this for like three (two?) years, actually. When I asked about scoped variables and such back on the old Suggestions forum, I was told "not in GMS1.0." :p
Now I'm asking "has it been changed in GMS2?" Nobody has confirmed or denied yet!
Lol right! Give it time. I'm sure there will be plenty of both disappointments and pleasant surprises along the way. :)
 

icuurd12b42

TMC Founder
GMC Elder
>It is absolutely crucial for organizing code in long-term projects, especially object-oriented code.
It's not crucial. how do you think we did it before c++. structure your project as you yourself explained...

But yeah, I wish they would change the language too
 

Juju

Member
The only way to really combat this is to organize scripts into folders.
You mean robust naming is good practice? Get outta town, I never would have guessed!

Enforcing some kind of "scoped script" or method analogue would help new programmers organise larger projects better. There is some squiffiness with parsing that (though solveable) and inheritance might also get a bit messy.

The lack of enthusiastic replies is starting to make me worry that GML's core hasn't changed much...
Not yet. YYG are updating the IDE first (which affects literally everyone), then moving onto improvements to GML (which affects proportionally fewer developers). Be patient!
 

rwkay

YoYo Games Staff
YYG Staff
GML is a beginner language and we have no plans to add in any public, private or protected scoping as this complicates things (for beginners and infuriates more savvy ).

We have added a CleanUp event which helps extension writers to clean up objects in a cleaner way than 1.x (which has to be done with a combination of Destroy and RoomEnd events), we have also added various variable_* functions to allow accessing of dynamic variable easier, and improved the array handling allowing array literals and dynamic creation and manipulation of arrays (see the array_* functions we have introduced).

Russell
 
@rwkay: Thanks for the honest reply, although I'm very disappointed to hear it. It's good that gml is easy for beginners to wrap their heads around, but variable and script scope would have been huge boons to anyone making more complicated projects. I've been looking at other engines lately because of GM's historic lack of Nintendo support (any future plans? ), and I've been very pleasantly surprised by some of the things your competitors are doing. That said, I've known and loved GM for a very long time now, and the new room editor and IDE improvements look great. I know I'm not going to change your plans for GM here. Just my honest thoughts as a long-time GM developer. It sucks, because besides a few key things (things I was hoping and expecting GMS2 to address), I prefer GM to the other engines on the market. The other big two aren't really designed around 2d games like GM is.

Edit: also, yes, I had the same thoughts as icuurd, though I felt it was pointless to bring it up, looking at how many of my suggestions have actually been added over the years... ):
 

icuurd12b42

TMC Founder
GMC Elder
GML is a beginner language and we have no plans to add in any public, private or protected scoping as this complicates things (for beginners and infuriates more savvy ).

We have added a CleanUp event which helps extension writers to clean up objects in a cleaner way than 1.x (which has to be done with a combination of Destroy and RoomEnd events), we have also added various variable_* functions to allow accessing of dynamic variable easier, and improved the array handling allowing array literals and dynamic creation and manipulation of arrays (see the array_* functions we have introduced).

Russell
Adding complicated features does not equate complicating things. I can still program in C in C++

If you could add a Add Function to the object properties... hmm? that would be cool and not complicate things for anyone and yes I'm over simplifying
 

11clock

Member
GML is a beginner language and we have no plans to add in any public, private or protected scoping as this complicates things (for beginners and infuriates more savvy ).

We have added a CleanUp event which helps extension writers to clean up objects in a cleaner way than 1.x (which has to be done with a combination of Destroy and RoomEnd events), we have also added various variable_* functions to allow accessing of dynamic variable easier, and improved the array handling allowing array literals and dynamic creation and manipulation of arrays (see the array_* functions we have introduced).

Russell
Can we at least be able to have public scoped scripts, or more robust user defined events? Anything that lets us tie methods to objects like in an object-oriented language. It makes large-scale projects more viable in GMS.
 

rwkay

YoYo Games Staff
YYG Staff
We are still working on some further GML changes over the Beta period, not promising anything but there is more to come.

Russell
 

icuurd12b42

TMC Founder
GMC Elder
there's a tiny change I would like the language to have because every newbie is doing this...

id.instance_destoy()

could resolve in with(id) instance_destroy()...

so adding object functions would be a snap aftewards
 

icuurd12b42

TMC Founder
GMC Elder
It is not a feature if they added it, it will be major update to gml, I don't think it is cool to have normal gml and oo gml.

[Edit]

Oh yeah, I just saw your post, I like the with method but oo is just hard and difficult.
Like I said, I can program in C in C++ I'm not forced to use classes and all the new stuff... and I dont need to create classes in java or php or visual basic... something that becomes part of the language, as an option, does not mean it breaks the language.

Plus you are already halfway there with gml with id.x and so on
 
I am sure I saw Additional Target Platforms in Q3 2017 on the roadmap http://help.yoyogames.com/hc/en-us/articles/231719448-RoadMap .... my lips are sealed...

Russell
We are still working on some further GML changes over the Beta period, not promising anything but there is more to come.

Russell
You guys at Yoyo are great, Russell, but I've been getting these kinds of vague answers and announcements for the last two or three years now, always ending with "wait for 2.0! ;) "
Do you guys have plans on ever implementing a solid roadmap that plainly lists things, and marks whether they're done, on time, or late, the way Unity does? It seems like the best solution for things like this. I haven't done any programming on my project in months now, focusing totally on art, because I wasn't sure whether or not I was going to have to switch over from GM, and was waiting for 2.0. Now 2.0 is here, and while "we have other targets listed for nine months from now" is heartening and exciting, I can't just wait around another year for GMS2's full potential to be shown. It'd be really great if you guys would decide where the engine is going (which you probably have), and then lay it out there with us. Roadmaps aren't promises. Just something to show people where the engine is headed. GMS2 as it stands right now is missing a lot of very strong features that I'm finding enjoyable in other engines. It'd be great to know how many of those features will be missing forever, and how many will be in next year or whatever. Thanks for taking the time to answer, Russell. Excited for GMS2's launch, even if I do decide to move my main project over. Thanks for taking the time to address concerns here.
 

icuurd12b42

TMC Founder
GMC Elder
out of interest what do you think we are missing?

Russell
Classes - Objects that are not visually tied to the game visuals, no ties to the internal instance list.. Could be another resource type with a create and destroy event, fast creation and destroy, so we can implement our own container types easily

Adding functions to objects and the class type

A declarative for object variables, only valid in the create event to help with the auto complete
member varname = 10;

Stronger types and have data structures as separate types individually distinguished so there is no potential of using a structure id with the wrong function
list l = ds_list_create();
Or simply
list l;
member list l;
string s;
...

Structures, well you got the new array declaration, but structures would be nice.

And as mentioned before. Have id.somefunc(), resolve to with (id) somfunc ();

That is basically all that's needed to complete the language.
 
out of interest what do you think we are missing?

Russell
Thank you for asking! I haven't snagged a beta key for GMS2 yet, so this list is only based on what I've feverishly gathered from reading and checking the videos. The main things I can think of off the top of my head are:

-Scoped variables and scripts/Visual Studio style intellisense to pull up public fields for me. I'm making a large SNES styled action RPG, and I have a billion global scripts floating around my GMS1 project, along with a billion objects. Visual Studio's code editor (which Unity and Unreal(?) use) makes it a lot easier to build classes, then forget about them. With the lack of scoped variables and methods in GM, I'm constantly checking old code to see how it worked. It's a huge hassle for me with my larger project, and it's one of the biggest things I was hoping would be changed.

-Nintendo support! Maybe this will be addressed soon. Your answer hints that it will. Will I like the answer/implementation nine months from now, though? I won't know until then, which is a little too long for me! I hope you guys announce something more concrete soon.

-Unity/Unreal's no-compile game testing/playing. I haven't really used Unreal, but from what I've heard, it's kind of similar to Unity. In Unity, you can preview your game without compiling. Tying into scoping and intellisense, you can then change public variables of object instances on the fly while playing. It's not something I knew I was missing with GM, but it's incredibly powerful for tweaking game-feel and even bug testing. This one is also huge, and is something I would've loved to have seen in GMS2. My GMS1 project takes thirty seconds to turn on. How many hours do I waste a week tweaking little things over and over again until they feel right? After using Unity, this one is almost a must have for me as well.

There were a few other things I heard that disappointed me too, but they weren't really big. Lack of code folding was one of the niceties I heard was missing. There were a few others. None of them were really big deals, though, and of course the other engines have their own small (or large) things I could complain about. The three I listed above are what are pushing me away from GM right now, though.
Which is too bad, because GM is also pulling me to stay! The new IDE and room editor look fantastic, and the engine as a whole is probably much more geared for 2D game dev than Unity is. I know there will be times I'll feel like I'm wrestling Unity to force it to do something it wasn't designed for if I try to make 2D games for it. Although they've been pushing to make 2D development more natural in Unity (and have a roadmap outlining how they'll do it!), it still isn't the pure 2D/pixel art engine GM is.

Thanks again for addressing concerns, Russell. Really cool of you. GM's strong community is a very strong plus for it, I think!
 

rwkay

YoYo Games Staff
YYG Staff
1. I hope you will be pleasantly surprised at what we have in the GMS2 intellisense

2. I cannot say, you will be pleased though....

3. We have a lot of compilation / tooling to do before we can do this as our inherited codebase does not lend itself to this, we are making steps towards this, the next step is folding our debugger into the IDE which is still a way of yet.

Code folding is coming too but we do not see it as a priority (mainly because we don't use it ourselves) but we see its utility.

Russell
 

icuurd12b42

TMC Founder
GMC Elder
Code folding is a must, I can't believe you don't use that, you should see it as a priority, I use that 100% of the time in dev studio
 
1. I hope you will be pleasantly surprised at what we have in the GMS2 intellisense
I'll check it out as soon as I can, hahah! I heard its improved, but I'm not sure how much help it'll be without scoped methods or variables. It might at least help opening old objects to check variable names to a minimum, which would be good. Color me interested, at least! =)
2. I cannot say, you will be pleased though....
Very good to hear! =)
3. We have a lot of compilation / tooling to do before we can do this as our inherited codebase does not lend itself to this, we are making steps towards this, the next step is folding our debugger into the IDE which is still a way of yet.
I was under the impression that GMS2.0 was a complete rewrite, actually. Mike and others told me things were tough to do because of the old codebase back during the 1.0 days pretty often, and told me GMS2.0 would give you guys more freedom because of that. I'm surprised to hear you're using old code, but that does help explain why the changes to GML weren't as huge as I was hoping, maybe. I haven't been totally keeping up, but you guys did change over to C++ at least, correct? So hopefully the old code is at least easier to change and work with. Good luck to you guys. Looking forward to seeing GMS (mostly the GML portion, since you guys have done a fantastic job with the IDE/Room Editor itself, it seems) open up. Like I said, Unity and Unreal have a lot of compelling features, but the communities don't seem as active or tight-knit, and they're obviously not as geared towards 2D work as GM. Cheers, Russell! =)
 

GMWolf

aka fel666
To go back to the Bark() method for dogs. This is bad form for GM. (When building up an object interface)

Instead, make a script called Bark(dogObj).

Notice the script takes a dogObj. The script will do the necessary operations on the supplied dog object. This resolves a lot of problems.
Remember GM is not object orientated, and script really *should* take the objects they operate on. (again, if you are developing an interface, that is).

I describe a lot of it in my tutorial on OO in GM: https://goo.gl/IXmvWo (Ive been sharing this one a lot, lately).

Basically, interface to objects should not be defined within the object scope (object.function) but outside it, C style.

TL;DR Objects are more akin to structs, and script more like functions. Suply you structs (objects) to your functions (scripts) and you no longer have any problems.
Have a look a C programs for inspiration.
 

GMWolf

aka fel666
His issue is more of segregation of feature than implementation...
Yes, but my point was that OO would be a rather large shift from GM's current non-OO. Yes, you can bodge it in, (I already modded it in), but its far from ideal.

There is also a point to be made against OO for the purposes of GM (prototyping and all).
Many aspects of GM already embrases non-OO development, (ds_*, etc), and creating a divide by adding OO to objects may be a mistake. (Unless OO is added to data structures, etc)
 
Top