• 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?

GMWolf

aka fel666
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. leave it at that.
This ^^
I dont know if you noticed, but most of my arguments are made to show how GML is fine as it is. Some tend not to get that....
 
T

Tirous

Guest
This ^^
I dont know if you noticed, but most of my arguments are made to show how GML is fine as it is. Some tend not to get that....
Ya, It's fine I guess...

Could still use a way make variables private/protected. Restricting who'm can use a objects variables would be vary nice.
 

GMWolf

aka fel666
Ya, It's fine I guess...

Could still use a way make variables private/protected. Restricting who'm can use a objects variables would be vary nice.
If you think of GMObjects as structs, rather than Classes, then you can organize your code much better.
GML has a lot more in common with nonOO languages than OO languages. And so, when developing with it, you have to use nonOO constructs rather than OO constructs.

At least, that's my way of thinking...
 

MilesThatch

Member
@Fel666 yeah I gotcha man. It was more in relation to the programmers who praise the classes and bask us in their knowledge of "true" programming languages. I get it, you "real language" programmers have suggestions that would make gml make more sense to you, go send a job application to yoyo or invest into some YoYo stocks, then you maybe you'll get a say in the matter.
 
Sounds like unnecessary clutter.
Sounds like you don't know much about programming.
@MilesThatch: so you're saying nobody should make suggestions here in the beta forum of a new product unless they work for or own part of Yoyo. Right.
@Fel666: I think most people understand that GM isn't oo and that we shouldnt think of it as such when programming. Some of us would like to see that change a bit, though. Like you said yourself, GM is garbage for large projects. With a few changes, it could be much better for large projects, without hurting ease of use. Allowing us private and public variables or allowing us to name events isn't going to make GM significantly harder for new comers, but it'd make things a lot easier for people like me who want to use GM for things larger than platformers.
 
Last edited:

zbox

Member
GMC Elder
The way I use GM, you can get fairly object-orientated like if you use data structures properly. It's not the same but you can get pretty close.
 

GMWolf

aka fel666
The way I use GM, you can get fairly object-orientated like if you use data structures properly. It's not the same but you can get pretty close.
You can get indirection and some form of polymorphysm, in simmilar ways to how you acheive them in C. Not really OO, but as you say acheives the same result.
Once you realize this, you can achieve quite a lot. You have to do some work that an OO build process would automate, but on the flip side, it allows you to do funky stuff with script 'pointers' etc.
 

zbox

Member
GMC Elder
You can get indirection and some form of polymorphysm, in simmilar ways to how you acheive them in C. Not really OO, but as you say acheives the same result.
Once you realize this, you can achieve quite a lot. You have to do some work that an OO build process would automate, but on the flip side, it allows you to do funky stuff with script 'pointers' etc.
For sure, not an optimal solution at all. But for my own sanity I have a small framework that I can build OOP-resemblant data structure operated apps and I find it a little better than just using straight up GML and objects.
 

GMWolf

aka fel666
For sure, not an optimal solution at all. But for my own sanity I have a small framework that I can build OOP-resemblant data structure operated apps and I find it a little better than just using straight up GML and objects.
Yeah, Im not saying its not a good thing, I do a lot of that myself. I describe my way of doing some things in this video. However, this still inst OOP programming. A lot of C programs i read use simmilar ideas with structs, etc. I believe people have to realise that by organizing your projects in such ways, you can come up with a lot of the functionality we need.

To set things straight though: Yes, I do like OOP. I mostly think OOP. But should GML become OOP? Its hard to tell.
OO could bring more problems to the table before other things are sorted out.
Im thinking namespaces, types, etc. All of which should probably be straightened out before OO is added. (it would be a total mess otherwise).

One technique i find myself using more and more, is using enums and arrays to create my own structs. I then either pass arround the actuall arrays, Or store them in a list and use handles in the same way ds_* works. Im duplicating code so often to get the handles work now, im thinking a small framework for that would be nice...
The advantage of handles is you can choose to store data ina variety of ways, and add indirection super easily. At the cost of a little overhead.
 
Last edited:

zbox

Member
GMC Elder
It is, and one day I might release mine for others to pick apart and evaluate :)

And to the point of should gamemaker have a core OOP system, the answer is unequivocally yes if it wants to progress. The only reason it doesn't is because it was a toy made by Mark Overmars at some stage and the language's syntactic sugar has basically not changed since some the very first versions of GM from the scripting language that it is. Just look at the evolution of javascript, that thing has classes now!
 
C

Chinafreak

Guest
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. leave it at that.
I'm already using Unity3D with C#t, its a nice language and I love it. But I don't want to leave Game Maker because it's nice to develop 2D games. Still it bother me that GML is still not using classes and its horrible to develop bigger projects.
I was hoping that GM:S2 would have much better GML such like class, struct etc. so I can continue my bigger project (which it's already hard to develop games on old Game Maker) on GM:S2 ;)
But however, maybe we'll hear more about this in future. I HOPE so.
 
R

renex

Guest
I tried making data structure objects. I tried making a global event stack system with callbacks. I tried making array classes. I tried many, many different things. In the end I just gave up because I was essentially trying to write Java and the script overhead was absolutely mangling performance. Now I just work with regular objects and scoped scripts, and the performance/organization and code/boilerplate ratios are decent. The only change from my old GM8 paradigms is that now I have one global manager object instance to handle everything instead of relying on hundreds of globals and confusing segmented controllers.

Code:
#define loadgame
with (global.manager) {...}

#define damage
with (argument0) {...}
 

GMWolf

aka fel666
I tried making data structure objects. I tried making a global event stack system with callbacks. I tried making array classes. I tried many, many different things. In the end I just gave up because I was essentially trying to write Java and the script overhead was absolutely mangling performance. Now I just work with regular objects and scoped scripts, and the performance/organization and code/boilerplate ratios are decent. The only change from my old GM8 paradigms is that now I have one global manager object instance to handle everything instead of relying on hundreds of globals and confusing segmented controllers.

Code:
#define loadgame
with (global.manager) {...}

#define damage
with (argument0) {...}
The point is not to rewrite java ^^
And if you get massive code overhead, you are doing something wrong.

For example, you can have scr_update call different scripts based on the supplied object_index.
Code:
///scr_update(instance)
var instance = argument0;
switch(instance.object_index)
{
 case obj_player: return scr_update_player(instance);
 case obj_dog: return scr_update_dog(instance);
 ...
 ...
 default: show_error("cannot call scr_update on " + object_get_name(instance. Object_index), true);
}
You could even store the script index as a variable in the object and call that.
Still not java. But provides indirection.
The update example isn't that great, but makes more sense with damage, hit, fire, etc...

The point is not to recreate OO. But to provide the same levels of abstractions, without OO.

You may say "oh, but you are just emulating OO!". Well, this kind of code is used a huge amount by C developers, especially in the games sector. Intact, the extra level of control it offers, and the lower abstract omplexity is even viewed by some devs as an advantage over OO, and a reason not to use OO.
I myself disagree, and like OO. But it seems this is the direction GML is going. Probably to reduce the mental load when developing, lowering the barrier to entry.
 
Last edited:
R

renex

Guest
And if you get massive code overhead, you are doing something wrong.
Nah, I'm just doing too much!

I was trying to have "polygon" class-abstraction and """""methods""""" on my 3d editor. That just bogged it down to massive lag spikes when rebuilding geometry (you're dragging vertices or something). Not even the yyc can save me now.

Then I tried abstracting grid access in a puzzle game and on a blockgame lighting engine, and it caused recursive updates to lag a LOT.

Then I tried abstracting water blocks as arrays on a grid for a blockgame fluid simulator, and it just killed it.

Nowadays I just go the old-fashioned way and write behaviors where it's easier to do it, without bothering too much about keeping object-specific code inside said object. This optimizes execution and doesn't get nearly as messy if it is documented properly.

My point here being - if the engine had a builtin solution for these issues then I would not need to waste so much time trying to organize my things, ultimately giving up and then coding in global scope. I agree with the points made, but wanted to add my personal experience with the subject.

I should also note that I would love to be able to execute timeline moments on demand - this allows you to define a potentially very large number of instance methods on a timeline. It also allows finer control over how and when the timeline executes, making them a @#$%load more useful than they are right now.
 

MilesThatch

Member
Sounds like you don't know much about programming.
@MilesThatch: so you're saying nobody should make suggestions here in the beta forum of a new product unless they work for or own part of Yoyo. Right.

@RichHopelessComposer: Suggestions here would always be subject for debate as you can see. Hell, I posted my own feedback post with my own suggestions, go nuts.

I'm already using Unity3D with C#t, its a nice language and I love it. But I don't want to leave Game Maker because it's nice to develop 2D games. Still it bother me that GML is still not using classes and its horrible to develop bigger projects.
I was hoping that GM:S2 would have much better GML such like class, struct etc. so I can continue my bigger project (which it's already hard to develop games on old Game Maker) on GM:S2 ;)
But however, maybe we'll hear more about this in future. I HOPE so.

Game Maker is a designer friendly programming engine. It provides certain goodies that cut down on programming all the utility and trivial features that a full time programmer wouldn't spend much time on but would be a nuisance to non-programmers (perhaps these features have to come at an expense) So if we turn GML to C++ How much of game maker is there left, how far off will Game Maker be from just being Visual Studio with an extra gui running on the side. Also how much extra will Studio 2 cost if they implement another language on the side of GML (like some people here seem to strongly suggest) And what happens to the whole community of game developers who are composers, artists, animators who do not have the insight on the programming in the major languages, who benefit from the simplified system (the very reason why it's there in the first place)? Are they the minority then? do we just tell them to get a C++ book and study?

I'm sure that every programmer here who preaches how bad glm is will have the mental capacity and experience use THIS: http://www.glfw.org/ for instance, to quickly code their own level editor in Visual Basic. How much of game maker is there left after we take away the level editor? We code all the audio in game, all the sprite drawing, all the blending modes and collisions. All that can be easily achieved with running open source game dev packages in Visual Basic.
 

GMWolf

aka fel666
FYI, enums are global scope, so unfortunately you won't avoid clashes.
Yeah, but you can have an enum each object:
Code:
enum dog_fields {
   size,
   name,
   stuff,
   otherStuff,
   moreStuff
}

enum cat_fields {
  name,
  length.
  stuff,
  otherStuff
}
That way, the 'name' and 'stuff' fields dont clash.
If you choose to go with macros, you end up with this:
Code:
#macro size 0
#macro  length 0
#macro stuff 1
#macro name 2
#macro otherStuff 3
#macro morestuff 4
Everytime you add a field, you have to keep track of all your other values to avoid clashes. You also need to make sure another macro with the same name doesnt exists.
Enums solve many of those problems.
 

11clock

Member
Regarding GML, since it looks like OO isn't the direction it will be going (although I still want at least named user events with return values), I decided to try following these simple rules to make my object code easier to read:

-The only code allowed in objects are conditionals (if statements, switch statements, etc.) and script calls.
-You can only use Create, Step, and Draw events.
-Scripts that modify an object or return an object's values must be able to accept the object it will be operating on as argument0 for indirect modification or value retrievals.

By doing this, in my platformer character my create event is just a player init script and a physics init script, and my step event checks for control input and calls appropriate scripts in response (like scr_jump(self)), and at the end of the step event just calls scr_physics_update(self). What used to be hundreds of lines of code in my object are now, like, 10 lines.
 

xot

GMLscripter
GMC Elder
@Fel666 Those examples don't really say anything. You can easily duplicate your enums accidentally or prefix your macros to avoid that. Globals is globals.

I could more convincingly argue that isolating your globals inside objects makes collisions much more likely.
 

Hyomoto

Member
I know some people are arguing but I love seeing the code examples. Personally I may just not understand fully what object-oriented means, but I always felt you -can- code GM in very object oriented ways and I think @Fel666 demonstrates a very interesting version of that. I mean, instances themselves cannot 'speak to' or touch one another inherently, you have to code in such a way that becomes a possibility. So if you want private or restricted variables you simply have to code in such a way that instances either don't have access to each other, or when they do -you- are responsible for not making them interfere with each other's vital functions. It reminds me of something I read a while back, and I wish I could remember the quote correctly but it was along the lines of companies hire mediocre programmers and utilize object-oriented structures to minimize the negative impact any of them can have.

Whether or not that's true, what IS true is there is no substitute for good coding habits. If you make two objects dependent on each other, it's not GMS' fault, it's yours for building a program like that. And GML like any language has it's own best practices and pratfalls. Coding in safeguards isn't really a solution, improving your understanding of the language and program structure is. The only real rule I use for coding in GML anymore is that nothing supporting another object should rely on it. My UI elements might rely on my GUI handler, but it runs whether or not they exist. If you build that way, you can both safely add and remove elements without worrying about creating bugs or breaking parts of the program. To me, that's the essence of object-oriented programming and it's completely feasible within the scope of what GameMaker provides.
 

GMWolf

aka fel666
I know some people are arguing but I love seeing the code examples. Personally I may just not understand fully what object-oriented means, but I always felt you -can- code GM in very object oriented ways and I think @Fel666 demonstrates a very interesting version of that. I mean, instances themselves cannot 'speak to' or touch one another inherently, you have to code in such a way that becomes a possibility. So if you want private or restricted variables you simply have to code in such a way that instances either don't have access to each other, or when they do -you- are responsible for not making them interfere with each other's vital functions. It reminds me of something I read a while back, and I wish I could remember the quote correctly but it was along the lines of companies hire mediocre programmers and utilize object-oriented structures to minimize the negative impact any of them can have.

Whether or not that's true, what IS true is there is no substitute for good coding habits. If you make two objects dependent on each other, it's not GMS' fault, it's yours for building a program like that. And GML like any language has it's own best practices and pratfalls. Coding in safeguards isn't really a solution, improving your understanding of the language and program structure is. The only real rule I use for coding in GML anymore is that nothing supporting another object should rely on it. My UI elements might rely on my GUI handler, but it runs whether or not they exist. If you build that way, you can both safely add and remove elements without worrying about creating bugs or breaking parts of the program. To me, that's the essence of object-oriented programming and it's completely feasible within the scope of what GameMaker provides.
You, I like you...
 
K

Kahvana

Guest
OK GML will not get multi threading for a while as the VM needs to be rewritten to handle it, currently it is not threadsafe and cannot be just shoe-horned in.

Russell
I think snake from the old gmc forum would disagree ^^. his GMThreadsV2 DLL works like a charm in GM8.
Sad that game maker won't support it trough, it would have been awesome if game maker did.
 

GMWolf

aka fel666
I think snake from the old gmc forum would disagree ^^. his GMThreadsV2 DLL works like a charm in GM8.
Sad that game maker won't support it trough, it would have been awesome if game maker did.
The GM8 VM was quite easy to add features to. It was just a Delphi runner with the .gm8 strapped onto it.
(Please correct me if wrong)
 

rwkay

GameMaker Staff
GameMaker Dev.
I also suspect that the extension had lots of race condition issues as the rest of the engine was not thread safe so any memory allocation would have had race conditions as well as data structure allocation - this is the main issue with the current VM on GMS and we would have to spend time ensuring that all these portions are thread safe.

Many games would just get away with it, which is what I expect is happening with the GM8 extension above - but it would not work with the current VM at all

Russell
 

FrostyCat

Redemption Seeker
I also suspect that the extension had lots of race condition issues as the rest of the engine was not thread safe so any memory allocation would have had race conditions as well as data structure allocation - this is the main issue with the current VM on GMS and we would have to spend time ensuring that all these portions are thread safe.

Many games would just get away with it, which is what I expect is happening with the GM8 extension above - but it would not work with the current VM at all

Russell
Would it be possible to reserve a thread-safe subset of GML for use with threading? This would be helpful for AI computations that run long enough to cause ANRs, for instance. Maybe classes can be implemented here as well, as an isolated and thread-safe stand-in for objects.

In every language I've seen that support threading, there were always things in the standard library that aren't thread-safe. As long as these issues are documented, I don't see a cause for concern.
 

rwkay

GameMaker Staff
GameMaker Dev.
We plan on making the VM thread safe in the future which will allow us to add a task library (which is our preferred method for multi tasking), but until then we will not be supporting anything like that.

Russell
 
Top