• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!
  • 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 Still no Class for GML/Threading?

C

Chinafreak

Guest
Hello guys,

why is there still no class for GML? It would be much easier to developing games if GML had class...
The other question is, how does look with multithreading? So we're abled to put a huge script into multithreading without lags?

- Chinafreak
 
Last edited by a moderator:

11clock

Member
What is class and why would it improve GML?
*sits in chair smoking fancy pipe*

Well, my dear good sir, a class is a blueprint that objects are instances of, much like how you have a blueprint of a house and the house itself. GMS already has something similar going on (objects and instances of the object), but it lacks functionality of many features of a class, such as local methods (like a dog having "Bark()" as a method), and not having to be a tangible thing with x and y values, functioning purely as a storage.
 

zargy

Member
GML is a scripting language, akin to javascript. It does not fit the definition of an actual programming language.
 

Gradius

Member
GML is a scripting language, akin to javascript. It does not fit the definition of an actual programming language.
GML is compiled in some form or another nowadays though. I suppose you could claim the VM is just scripting, but YYC is definitely actual bytecode, making it definitely just a programming language.
 
R

renex

Guest
I'd imagine a not specially difficult way to make the runner use two threads would be to separate the software rendering pipeline (sprite batching, tile animation, vertex buffer management and the such) into its own thread. This adds a potential one frame of lag to the game but allows a little bit of load to go on a second core.

I have only a very vague idea about how the runner is structured so I don't know how feasible this is to do, but it would be pretty cool.
 
Last edited:

Lewa

Member
  • Objects are effectively classes. (Instances are effectively class instances)
Theorethically yes.... practically... no...

  • Multithreading works extremely well (provided you are good at making DLL's)
Still, it would be nice to have such a solution built-in into GMS2 so that you can use it on multiple platforms (without having to write platform specific code for each platform, because that defeats the purpose of a multiplatform engine in the first place.)
But hey, maybe something is coming. (It's still a beta and not all features are available.)
 
Last edited:
E

EJ64

Guest
I too would also like to allow class definitions. Too many times I've wanted to group a number of variables together without having to use separate arrays or really sloppy naming conventions. Yes, you can technically do that by creating an object, but with each instance of an object contains a plethora of other junk that you probably don't need, like x and y coordinates, id, sprite_index, phy_active... it's a pretty hefty list and is terribly inefficient when you want to have a large number of these instances.
With classes, it would also be nice to be able to define scripts locally, through code. That way my resource tree won't be cluttered with scripts that are exclusive to one object.
 
A

atxgamedesigner

Guest
Interesting thread...

I too would love to see an overhaul to GML, however I don't think we'll ever see yoyo completely redesign the language to support the various features of more "standard" programming languages.

A) I think the market yoyo is targeting is more of the non-programmer type. If it wasn't, the drag and drop system wouldn't be a main feature of the engine.
There are significantly more people that don't know how to program, than there are people that can. And those that don't know how, will likely give up learning due to the complexity of the subject.
I think yoyo is making money on the idea that "anyone can make a game"... Ya know?

B) Implementing such major changes to GML would likely change so much about how GMS works under the hood, that the whole software would likely need to be redesigned.
Why bother with that amount of work if the change appeals to only a select group of people?

GameMaker is great, I absolutely love it.
Do I wish that you had more control over whats happening? Sure. But there are other languages and other engines that can handle that task.

For someone that has worked in other languages, look at it like this -
You can get all of the fancy language features if you build your game in Java or one of the C languages.... But you might never finish it...
Or you can use GMS (with a few workarounds) and be done with your game in a month or two.
 

GMWolf

aka fel666
You can get all of the fancy language features if you build your game in Java or one of the C languages.... But you might never finish it...
Or you can use GMS (with a few workarounds) and be done with your game in a month or two.
Yes, i wanted more OO, threads, etc before.
But now that ive actually worked on games in java, c#. I know its not that good an idea.
Sure, for my larger projects, where I need a clear program structure, GM is garbage.
But when working on a smaller, less structure dependant game (platformer, racing, etc), Then GM is gold. You can get straight to the point without having to think what classes to inplement, and whether to use synchronisation or not.
I short, GML is rather good at what it does.
 
A

atxgamedesigner

Guest
I think thats exactly the point..
GML (as with any other "programming language") should be used for a very specific task.
Sure it can do XYZ, but is there a better language to use instead..? Maybe..

I feel that people trip out too much on the little details.
Don't compare GML to C++ or Java, as it will never be the same. There is no comparison to be had.
GML is its own thing.... Just be glad they fixed arrays :p
 

hippyman

Member
While I personally would love to see GML become more OO, as Fel666 stated, GML really does it's job well. I've yet to find something I couldn't accomplish in GM with GML alone. Granted I'm not as advanced as quite a few of the people on here, but things like real-time audio generation, making any kind of file exporter (so long as you understand whatever format you're exporting) with binary files, and well.... those are pretty much the most advanced things I've done.... but you can do cool stuff with GML is what I'm trying to say!

If there is something that GML doesn't support, you can make an extension that does support it. Now a lot of people instantly think of DLL extensions as terrible because they remove the ability to be cross-platform but nobody seems to think about .dylib(Mac), .so (Unix) so that covers the PC market. As for mobile I really don't know and personally don't care. The mobile market is so saturated that I personally have zero interest, but for those of you that do have interest in mobile, dynamic libraries are in-fact possible on Android. But I really have no idea how they work or if GM is personally capable of working with them but I imagine a skilled programmer can make it work.
 

GMWolf

aka fel666
Well, GMS2 is getting plugins.
If those give us just a bit of preprocessor access, we can prettyuch add anything to GM. With just preprocessing, you can add full OO, new resources, etc.

So, when plugins come, who knows what GM will become! Personally, before OO, I would like to see a better namespace system. By that I mean, having a namespace system at all! Right now script clashing is just too common, without a real workaround!
 

hippyman

Member
Well, GMS2 is getting plugins.
If those give us just a bit of preprocessor access, we can prettyuch add anything to GM. With just preprocessing, you can add full OO, new resources, etc.

So, when plugins come, who knows what GM will become! Personally, before OO, I would like to see a better namespace system. By that I mean, having a namespace system at all! Right now script clashing is just too common, without a real workaround!
Is there actually a confirmed source where somebody from YYG said they were working on it or at least considering it? I've seen this around the forums but no concrete sources. I'm all for plugins though! Especially if we're able to make editor plugins so we can make our own editors.
 

GMWolf

aka fel666
Is there actually a confirmed source where somebody from YYG said they were working on it or at least considering it? I've seen this around the forums but no concrete sources. I'm all for plugins though! Especially if we're able to make editor plugins so we can make our own editors.
Sources... I think so. But I'm too lazy to look for them^^
Last I heard of them was on mike's stream. Said the documentation was a long way off though.
 
R

renex

Guest
Hardly a work around.
That's like saying there is a workaround to breathing: not needing to breath!
Mmmmm not really... this is a functional workaround that I have used for years. But this is beyond the scope of discussion here.
 
R

renex

Guest
Using a strict naming convention is no protection against naming conflicts with code that comes from an extension or a partner.
It does reduce the chance though.

But talking about a native engine feature - considering obfuscation is already done by the compiler for html5 targets, I imagine it would not be too hard to implement an obfuscation scheme that prefixes a unique extension identifier to all variables and functions used on an extension. We should probably make a Mantis entry for that. Perhaps it can also be written as an external tool.
 

GMWolf

aka fel666
It does reduce the chance though.

But talking about a native engine feature - considering obfuscation is already done by the compiler for html5 targets, I imagine it would not be too hard to implement an obfuscation scheme that prefixes a unique extension identifier to all variables and functions used on an extension. We should probably make a Mantis entry for that. Perhaps it can also be written as an external tool.
Would be nice
Would be nicer to have a folder-like structure for scripts.
Ie:
[Vector]
-scr_v2
-scr_v2_add
-etc

Then, calling scr_v2 must be done like so Vector.scr_v2. Or by calling '#include Vector' somewhere in the script/code block.

This shouldn't be too hard in GMS2. And its all feasible in the preprocessor!
 
C

Chinafreak

Guest
Or other solution would be:

Use instance as Class, but the instance is empty (no variable such like x, y, phy_speed_x etc.) and you can create methods by using event (Not a big fan, I would rather to use only one code file without event, but at least it something)

And then we can create our own "Class" such like:

Code:
//Create Empty Class. No Draw/Step/Create Event allowed/exists (?), class_dog is a "object"
dog = class_create(class_dog); // class_create = instance_create, but its creating a empty instance (no x, y, phy_speed_x, etc.)
and calling the script

Code:
// "Bark" -> Just a "custom" (?) event of instance dog with script.
class_call(dog, "Bark", argument0, argument1, argument2, ..., argument_n);
Of course, "dog.Bark(argument0, argument1, argument2, ..., argument_n)" would be better, but I don't think so that will work with currently GML system. (Or suprise us, YoYoGames-Dev!)

Calling variable would be, of course, easy such like:

Code:
dog.isHungry = false;
show_message(dog.isHungry);
I know, it still not a perfect "Class", but it would be something.
If you've better idea, improve it!


@hippyman Plugin System is confirmed (but idk if we are getting access from plugin system), Source: https://forum.yoyogames.com/index.php?threads/plugins-support.11859/
 
Last edited by a moderator:

hippyman

Member
Or other solution would be:
@hippyman Plugin System is confirmed (but idk if we are getting access from plugin system), Source: https://forum.yoyogames.com/index.php?threads/plugins-support.11859/

Meh, that was kind of a confirmation. It confirms that the entire IDE is based on a plugin system. But Mike himself said, there is no guarantee we'll get access to it. Which is a bit of bummer. Hopefully that's just squirrel talk... Custom editors would be HUGE for me, since that's basically all I do in GM anyways.
 

dphsw

Member
I think GML is already kind of object oriented. Ok, so all variables are public, and the basic Object, from which all others inherit, is pretty cluttered (with variables like 'x' and 'y'), and functions are global in scope. But I make use of an Enemy Object in my game, and then have all other enemy types inherit from that. Every time I make a type, the first command I call in its Create event is 'event_inherited', which sets all the variables to what the parent object would set them to, and then make any changes. You can do the same with the step or draw events if necessary. If you need polymorphism, you can set a variable to the address of a function in the parent, change what function that variable is set to when initialising the children, then use script_execute to call that variable. It's not as pretty as an OO language, but it does almost everything needed.
 
E

Eugen_M

Guest
I would love for it to have classes with functions and also something similar to Task.Run(()=>HeavyParticleEffectFunction());
That would have been so epic i wouldnt know what to say, its such a shame that gml2 doesnt have these 2 implemented yet :\
 

GMWolf

aka fel666
I would love for it to have classes with functions and also something similar to Task.Run(()=>HeavyParticleEffectFunction());
That would have been so epic i wouldnt know what to say, its such a shame that gml2 doesnt have these 2 implemented yet :\
So you want tasks, threads, and lambda expressions ?
Java got lambdas in 1.8. It already had objects from the start.
GML is far from having proper OO (with indirection, etc), its no way near having lambdas!

Besides, you can already use script id's. Similar to method pointers in C. Its actually rather flexible, and negates the need for lambdas.
 
E

Eugen_M

Guest
Well but i dont want to program in java, i want to program in gml and i wish gml was a little bit more like c# for visual studio (in code template not actual framework)
As for Tasks if at least the Task.Run method wouldve been implemented (i.e..) multithreading possibility, then that would be enough for me to make me very happy.
 

FrostyCat

Redemption Seeker
Another take would be to define both a display name and a constant for custom events, the same way Triggers did in GM8 but without the trigger condition. That way the chance of calling an event that isn't defined anywhere (e.g. due to a typo) is greatly reduced.
 

Hyomoto

Member
gosh. just remove this silly limit of 16 object "events" and let us change their names from event_user(1) into something normal like event_user("MyEpicMethodName");
In a really small way GM2 kind of handles that in that you can use the @description to name it and it will show up as such in the GUI, though obviously that isn't specifically what you were talking about. As a side note, I've been enjoying these trial limitations for the same reason people enjoy various jams: it's interesting to work in a simplified space and realize how wasteful full access can be. It's will be nice to be free of them but full access also lets you be really wasteful. In a way the sixteen user event limitation could be perceived that way, it keeps you frugal. I'm not saying it should be or can't be another way, just that maybe there are some unsung benefits to it.

Honestly though I'm sort of interested in what you are doing that needs it. Isn't it also possible to do something dumb like:
Code:
#macro myEpicMethodName ev_user0
It's not quite the same, but the end result is pretty similar?
 

GMWolf

aka fel666
In a really small way GM2 kind of handles that in that you can use the @description to name it and it will show up as such in the GUI, though obviously that isn't specifically what you were talking about. As a side note, I've been enjoying these trial limitations for the same reason people enjoy various jams: it's interesting to work in a simplified space and realize how wasteful full access can be. It's will be nice to be free of them but full access also lets you be really wasteful. In a way the sixteen user event limitation could be perceived that way, it keeps you frugal. I'm not saying it should be or can't be another way, just that maybe there are some unsung benefits to it.

Honestly though I'm sort of interested in what you are doing that needs it. Isn't it also possible to do something dumb like:
Code:
#macro myEpicMethodName ev_user0
It's not quite the same, but the end result is pretty similar?
It works. Yes. Intact, it's a decent alternative.
Though, I would say using enums would be better so that you don't clash with other objects.

Only problem is that you are limited to 16 user events, and have no return types. Though, yeah, you could use a custom calling method and a stack to circumvent this problem.
 

Hyomoto

Member
It works. Yes. Intact, it's a decent alternative.
Though, I would say using enums would be better so that you don't clash with other objects.

Only problem is that you are limited to 16 user events, and have no return types. Though, yeah, you could use a custom calling method and a stack to circumvent this problem.
When it comes to enums, and I admit I haven't given this a go in GM2 yet but in GMS, it would highlight the entire variable. So if I had an enum like:
Code:
enum mouse ( click = 0, double_click = 1 )
It would highlight ANY mouse as being an enum. So for some things I like them, but for other things I like macros better because it's hard to confuse:
Code:
#macro field_mode_inactive
With anything else and looks better than:
Code:
field_mode.inactive
Though ask me again tomorrow and I'll probably have changed my mind.
 
C

Chinafreak

Guest
It works. Yes. Intact, it's a decent alternative.
Though, I would say using enums would be better so that you don't clash with other objects.

Only problem is that you are limited to 16 user events, and have no return types. Though, yeah, you could use a custom calling method and a stack to circumvent this problem.
Oh, I forget about return... and we forget about argument/parameter, too. But why not just expand the "event_user" such like "event_user_class"

Code:
result = event_user_class(dog, "Bark", [argument1, argument2, ..., argumentX);
And of course, increase the limit of event_user.

@Mike @rwkay why didn't you say anything about class? :( Is something planned? Or at least adding other language such like JavaScript/C#/C/C++?
 
Last edited by a moderator:

MilesThatch

Member
It's the "Let's turn GML into a C++" argument again

Want classes. Switch to:
App Game Kit 2
Unreal Engine w/ Visual Studio

gml's a designer friendly language. Concentrate on areas that actually need attention.
 
Last edited:
Top