77 replies to this topic

[Frag Fiesta]

Okay, a slightly more contentious one. I know some will hate this idea, and we are still debating it internally, but depending on feekback, it might open up some other concepts, so here we go....

Currently when you create a collection, you get back a handle to this object. I'm not a fan of this, I think it's confusing, and a messy. I would much rather return the collection as an object. In this way you could access functions/features directly as you would in an instance. For example, currently you do something like this...

mylist = ds_list_create();
ds_list_insert(mylist, 1, myvalue );
ds_list_destroy( mylist );

I don't like this. I think even beginners know the concept of an object because they have to deal with instances all the time anyway. So why not....

mylist = ds_list_create();
mylist.insert( 1, myvalue );
mylist.destroy();

This would allow us to do better syntax checking as we know what type the object is, it's not just a number that could actually be used by any number of collections. It should mean (at some point), we could do error checking in the editor and flag up issues where you try and use the list object as an illegal parameter, or try and use it as a grid object etc. Improved intellisense could also prompt you with functions as you type, making it far easier to know what the variable is used for.

However... some people might think this is a step too far for them or beginners.

What do you think? Obviously is people like this, it could open up a WHOLE new approach for GML, so have a good long think about it first....

Personally, I'm not a big fan of GML, but it is useful.
But you could add coding like: if guy is in position06=set guy in next room at position_x45 y66

something like that. You know, like in metroid, where you enter a room and you open the door, and you go back and appear at the door.

[mcoot]

But you could add coding like: if guy is in position06=set guy in next room at position_x45 y66

You can already do that...

[OpticalLiam]

The thing is, if you end up just implementing this for collections, you're essentially introducing a new piece of syntax that is a relatively special case, which only ends up causing frustration in the long run - special cases are generally a bad idea as they can be counter intuitive and confusing. I'm still not really sure why you'd decide to do this to collections in particular, as I don't see how it benefits them any more than it would any other resource type in GM. The main benefit of this concise syntax is essentially derived from being able to use it everywhere consistently.

I'm glad you guys are finally deciding to move forward with GML, but I disagree with changing the language bit by bit like this, as there just doesn't seem much sense to it. It should be all or nothing. And while you're at it, add collection literals.

Edited by OpticalLiam, 26 January 2011 - 01:55 AM.

[kburkhart84]

Why just collections? Every resource in Game Maker should be like this. GML has always been overly verbose - "sprite_set_alpha_from_sprite(ind,spr)" should just be "spr.setAlpha(alpha)". I imagine some may argue that verbosity makes the language somehow easier for new programmers, but I really disagree that it's any easier than this alternative. Though, admittedly implementing this would be a radical change - you'd basically have to implement OOP and hence you'd have to deprecate a lot of functions. In any case, GML is simply a terrible language as it is. In my opinion, either get it up to date or throw it out and replace it with something like Python - because otherwise it will never be generally accepted as a 'legitimate' programming language these days.

This is the way I believe. It is a radical change, but I like the OOP factor. I don't think this method is confusing for beginners(especially since collections are "beginnerish" anyway), but I see an issue where for collection objects, you use .method syntax, but not for OUR objects. The .method syntax makes sense, or the original "handle-to-function" method makes sense, but one good thing with gml is that in general, things work the same all over. I think though that a way to alleviate that would be atleast to have more user events, and be able to rename them, and be able to use .method syntax to execute them. Then, for the most part, we would have things be "the same" all across the language. I don't necesarily see the need for each object to have all the functions, like the above quote says, but a way to partially grant that request would be to possibly expose more variables as indices to things, such as the alpha channel(which should really just be put as part of the sprite directly soon enough).

And one more thing...about pointers...no...just no, not in GM.

[Andy]

If I don't know much about what you are talking about, and am just a person who uses collision codes like;

if collision_circle(x,y,100,obj1,true,true)
{
 //bla
}

will this effect me in some way?
Note: Just so you know, I will not vote on this, since I do not understand it.

Edited by Andy, 26 January 2011 - 02:35 AM.

[slayer 64]

if this was an object instance

mylist = ds_list_create();
mylist.insert( 1, myvalue );
mylist.destroy();

wouldn't it be used like this?

with ds_list_create()
{
    insert( 1, myvalue )
    destroy()
}

[round]

Hello, Mike.Dailly,

I am an amateur user of Game Maker 8.0 pro.
I think that the following syntax will confuse me. This new syntax will also increase the difficulty level to understand other people's GML code. It is easy for me to undertand the meaning of something like GameObjectName.x or GameObjectName.hspeed but the following syntax is really difficult for me.

mylist.insert( 1, myvalue );
mylist.destroy();

Moreover, please don't trust the poll in this thread.

Yes!! (49 votes [50.00%])
No!!! (23 votes [23.47%])

Although the percentage of "Yes" are double of the percentage of "No" at the moment, people who voted in this poll are actually Game Maker users with different levels, from beginners to expert users. However, this new syntax will affect the beginners the most! Game Maker is very popular and there are many reasons. One important reason is that Game Maker is very easy for beginners. Difficult syntax will decrease the popularity of Game Maker. Please consider that Game Maker is used to teach students programming in a lot of high schools around the world. Please don't introduce difficult syntax to Game Maker Language. Thank you.

I really hope that YoYoGames will not add this new syntax to the Game Maker in the future, please. Thank you very much.
.... ....

Edited by round, 26 January 2011 - 05:20 AM.

[kburkhart84]

if this was an object instance

mylist = ds_list_create();
mylist.insert( 1, myvalue );
mylist.destroy();

wouldn't it be used like this?

with ds_list_create()
{
    insert( 1, myvalue )
    destroy()
}

I don't think this kind of thing would come up. If I remember correctly, somewhere it was mentioned that if this is implemented, there would be a sort of type checking, atleast for collection objects.

Hello, Mike.Dailly,

I am an amateur user of Game Maker 8.0 pro.
I think that the following syntax will confuse me. This new syntax will also increase the difficulty level to understand other people's GML code. It is easy to undertand the meaning of something like GameObjectName.x but the following syntax is difficult for me.

mylist.insert( 1, myvalue );
mylist.destroy();

I really hope that YoYoGames will not add this new syntax to the Game Maker in the future. Thanks a lot.

I'm curious. Do you know how, and do you ever use the collection object functions as they are now?? I ask because if you don't, then it may be something like the other poll about external editors, where it doesn't affect someone who doesn't use it. It is possible that the simple use of collection objects as it is can confuse amateur/beginners, and I think either syntax(as is now and as is proposed) makes as much sense as the other.

[Frag Fiesta]

But you could add coding like: if guy is in position06=set guy in next room at position_x45 y66

You can already do that...

......oh

[mcoot]

I think that the following syntax will confuse me. This new syntax will also increase the difficulty level to understand other people's GML code. It is easy for me to undertand the meaning of something like GameObjectName.x or GameObjectName.hspeed but the following syntax is really difficult for me.

To you, what seems more difficult about calling methods with an object.method syntax than accessing variables with an object.variable syntax?

Although the percentage of "Yes" are double of the percentage of "No" at the moment, people who voted in this poll are actually Game Maker users with different levels, from beginners to expert users. However, this new syntax will affect the beginners the most! Game Maker is very popular and there are many reasons. One important reason is that Game Maker is very easy for beginners. Difficult syntax will decrease the popularity of Game Maker.

So in other words, you want to throw out this poll because you disagree with the results as they stand. This syntax won't affect total beginners at all - if you learn this way from the start (and having proper object oriented collections makes a lot more logical sense than having an index handle value) it shouldn't seem much more difficult than the current syntax.

Is

mylist = ds_list_create();
mylist.insert(1,value);

really more difficult than

mylist = ds_list_create();
ds_list_insert(mylist,1,value);

?

Edited by mcoot, 26 January 2011 - 04:17 AM.

[GameGeisha]

I think that the following syntax will confuse me. This new syntax will also increase the difficulty level to understand other people's GML code. It is easy for me to undertand the meaning of something like GameObjectName.x or GameObjectName.hspeed but the following syntax is really difficult for me.

However, this new syntax will affect the beginners the most!

Dot notation just like this one are used in many other languages when it comes to data structures (and objects in general). It's nothing new. In fact, most people with at least a casual understanding of any other language would be familiar with it, which includes all advanced users and new users with prior programming experience.

When I learned Java and Python less than a year ago, nobody in my classes complained about it. They picked it up just fine. And given that 80%+ of these people aren't even half-baked in programming, your point makes very little sense to me.


Back to the discussion. I'm in favour of this change, but the consistency needs to be there --- everything else in GM needs to be changed to suit this model. If the consistency cannot be maintained within GM, then this can be re-packaged into an alternate system targeting experienced users, that's cool too.

GameGeisha

[Sven]

I think that this is a good idea, however I am also worried about GML consistency and what effect it will have on learning the language.

I also thing it would mean that people would have issues with objects and objects that are in the game. Instances and objects are interchangeable terms in the world of GML but now, they won't be.

Edited by Sven, 26 January 2011 - 05:33 AM.

[gnysek]

If I don't know much about what you are talking about, and am just a person who uses collision codes like;

if collision_circle(x,y,100,obj1,true,true)
{
 //bla
}

will this effect me in some way?
Note: Just so you know, I will not vote on this, since I do not understand it.

No, if you are not using now functions like ds_list_something, ds_map_something, ds_queue_something and others that starts at ds_ (you can find them in documentation under Data Structures) - this will not affect you in any way.

---------

However, this new syntax will affect the beginners the most!

I don't know any beginners that uses data structures in their games... beginners are users, that drag&drop actions to events, and they don't uses so advanced things like data_structures since they ever have problems how to go to next room after you earn all diamonds in current room, how to set for every enemies they own health or how to check two buttons at once in GML... Particles, Data Structures, D3D, and vertex drawing - they not for beginners at all. And after they learn how to use instances, how they differ from objects, and how references work (you can even write a.b.c.d.e.f.image_speed = 1 if you make references for all of them) - syntax which Mike show us will be easy to understand. What's more - they should have then easier start for object oriented languages, like Java or C# where on collections you are working in similar way ( variable.method(value); ).

Edited by gnysek, 26 January 2011 - 08:51 AM.

[ragarnak]

For instances I never use >= 0, I usually use instance_exists(...) because that's what I mean.

Well, instance-IDs are not re-used, so if you try to refer to a destroyed instance GM knows its not there anymore. In other words: in GMs case you are lucky that that works.

In most "normal" languages that "instance-ID" is actually a handle to some memory, and you must change it to something sensible (normally a NULL) after you destroyed the object it pointed to, otherwise the next time you will (try to) access some non-allocated/owned memory and most likely cause a page-fault ...

But if that kind of "is NULL" (or equivalent) checking is not to your liking I can only hope that that suggested OO way of writing still uses the old ResourceID way of referring to the data-object, so a function like "ds_..._exists(...)" can be introduced.

[Derme]

Game Maker is, in essence, a game design tool. What I see here is not the actual change to data structure (which by the way, I use them a lot), but your insistence, Mike, to turn Game Maker from something more than this, into something that's in essence more 'programming' and less 'designing'. And although you being a C++ programmer makes you think that making Game Maker more object oriented than it already is is a good idea, I see a lot of defects in this. Disregarding that you want to force the newbies to swallow a completely new type of handle/pointer/whatever (ok... is it an object, or not?), you'll actually confuse them more. And it's not change for the sake of change, people actually enjoy using Game Maker because you don't have to give your soul to it and you can get some really nice stuff from it in return. That's the true asset of GM. And I feel that we should preserve that asset, no matter what. So what I percieve as something simple made less simple, still simple, but less, I see a downward spiral into something that I can still use but won't be as fun using it.

I feel amused that already a programming discussion has sprung up. There's a lot of great programmers in here (I can easily hold my own in programming, but that's another story), but let's consider that Game Maker is great game design tool, and like a lot of people have already said, there are a lot of programming languages that can provide the features you're looking for, let's focus on strengthening GM on what it's lacking (performance, lack of some features), instead of just rewriting it (cuz it's better and more powerful).


In other words, let's make Game Maker more like Game Maker (verbose and with strange programming tendencies). That's how I see it.

Game Maker is and will always be a great design tool, I know heaps of people who use GM to design fun and engaging games. Those people though have no aspirations to ever learn GML, because the D&D function does everything they need.

If you use Game Maker to design a game, you use D&D and maybe a bit of GML. But programmers who write in GML want a bit more control and power than D&D. Newbie programmers also want to be able to learn to code and they don't want to have to remember "strange programming tendencies" to learn the simplest programming language (In my mind) that there is.

This won't stop you from designing GM games, and it will be backwards compatible with your existing code. So why not make Game Maker Language easier to use and learn?

[Revel]

So why not make Game Maker Language easier to use and learn?

Because you have to be able to find a balance. Sure it might take longer for users to learn how the data structure "objects" work, but will actually make GML easier to use. The whole point would be finding features that are easy enough to learn, but provide many benefits to the language.

[gnysek]

So why not make Game Maker Language easier to use and learn?

Because you have to be able to find a balance. Sure it might take longer for users to learn how the data structure "objects" work, but will actually make GML easier to use. The whole point would be finding features that are easy enough to learn, but provide many benefits to the language.

I don't know how very_long_name_of_function_is_easier() to use than.this(); Why are you not writing change_instance_x_position(objBullet,12) but objBullet.x = 12 ? Because it's shorter & easier. Even event_perform(ev_other,ev_user0) will be more logical when there will be objBall.user_event0(); On left you have reference to something, so on right you deal with properties and call events/methods of thing that this variable reffers - and whole GM should keep that construction.
I know that some people thinks that when you write draw_sprite(sprite0,0,x,y), sprite0 is binary data with image - but it's isn't. You can write draw_sprite(0,0,x,y) and it's the same.

What is more fun, Mike said that old functions will still work, so in GM8.1 you can still write ds_list_add(); and you can still code in your old style... it's not a change, it's an addon.
Those functions was bad projected and beginning, now it's time to fix them.
And... you can still use GM 8.0 - isn't it ?

Edited by gnysek, 26 January 2011 - 09:35 AM.