One of the biggest things I got when moving to C++, was the concept of a contained object. The "this" pointer. Now GML is actually lucky as it already has this concept, and everyone uses it naturally. Inside the various events, you quite naturally use this concept so I don't think it too big a leap to start using the syntax to go with it.

For me new syntax for data structures (aka. collections) is closer than current one when I'm thinking about object and instances as part of object-oriented programming. Now they are like resource that you can create during gameplay.Why I'm still using GM - even using only GML in actions it's still 100x shorter to make something than in any other language... Game Maker is like jQuery - "write less - do more". And data structures should be shorter too, because they are very, very usable, and creating scripts thats aliases them to make function names shorter is only a waste of memory and computing power.

0

Previously game developer at YoYoGames, Currently PHP developer in DB-Team
Programming and working with: GML/C#/PHP/JS/MySql/CSS/HTML

Being a learning tool, one that helps you learn coding with the aim of advancement in your craft/career, I think this would world quite well, as it introduces you to "bigger" concepts that you'll need as you grow as a coder.

That alone seems quite a convincing argument as many people see GM as stepping stone... and as more studios seem to be using it as a prototyping tool tool, then it makes sense to have it more "in line" with the major programming languages.

So... look at this as a small step. Assume that all the "variable" stuff would just work. That if we introduced TYPES for this specific thing, it would give you enough feedback to make it a natural part of writing your code (and I do accept the chances of getting all this going first time would be...well... not good ). If this all worked as you would "hope" it would, and knowing what it would open the gates to (full object control for everything), do you think it's now definitely a bad idea, or one we should "try"? Particularly if it's just a small section of the language, a new addition that had no impact on GML as a whole.

Yes, lots of ifs but I think you have convinced me! As usual, anyhting that makes GM faster and is easier to use automatically is of interest... and if you phase the changes in through 8.1 before completely changing for 9 then itīs probably a good thing. Shame I canīt change my vote from "sitting on the fence" to "Yes!"...

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.

If you do change the DS functions, at least consider this. Please change the function names of the new data structure functions so that we who like the old system/need the compatibilty write some sort of compatibility layer/Extension so we can keep using what we like. At least consider that, and don't force us to use something we don't want to.

Been working with GM for about 6 years now I think... so at this point I only care about increased performance. So, I vote for the option that will do the job faster then the other

Also, I've been thinking...
The 2 modes you get to choose from in GM now is "Regular Mode" and "Advanced Mode" and that's it.
What if you could make like... a list of stuff you want to include/exclude.

For example, I would love to be able to define variable types and choose array sizes for increased preformance and more possibilities.
But yeah, I know, GM is supose to be easy to use and THANK GOD for that, I would never have gotten into game development without it!

Sorry for the none related post, just had to tell you guys about that.

Because I think a change like this should be applied globally. Like with sounds,

mysound = new Sound();
mysound.play();

I find it somehow confusing to have some object-oriented methods and the regular ones too.My concern is that keeping both in the the runner, would still take much, even more time to interpret/process, thus be even slower. I could be wrong about this.Also I believe the code would be hard for you to maintain/debug Mike Dailly, in order to please everyone old and new, novice and experienced user. And the less junk is in the GM runner, the better.

I am tempted to say yes (because I like object oriented structure), but I'd have to say if you choose a method, you should apply it globally so not to confuse people.

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

Game Maker already is object oriented, the problem is the syntax of GML makes this object orientation more difficult/tedious than it needs to be. The current method of addressing data structures is itself object oriented, but it's a rather cumbersome implementation of the OO paradigm. No matter what, you're working with something that's OO, that handle is a manifestation of an object. The problem is there's an inconsistency between objects and everything else. Objects already have the nice . operator syntax, but nothing else does. What I have yet to see is an explanation of why it's better that objects be treated as something so fundamentally different from everything else even though the current system of using handles every is itself just an implementation of OO.

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.

This is a horrible reason to keep things the way they are. Making GML easier/safer/faster can only help people create games with GM. How do better error messages make Game Maker less design-oriented? How does a less verbose scripting language make Game Maker less design-oriented? Just because an idea comes from a mainstream programming language does not mean it's not a good idea, even for Game Maker. A better scripting language facilitates design, directly as well as indirectly through other potential structural improvements to GM.

If you do change the DS functions, at least consider this. Please change the function names of the new data structure functions so that we who like the old system/need the compatibilty write some sort of compatibility layer/Extension so we can keep using what we like. At least consider that, and don't force us to use something we don't want to.

A much, much better solution would be to keep the old function names, but let them operate on the new data structures. So long as that notation is still there, there will be absolutely no need for a compatibility layer. Everyone gets the internal improvements for free, whether they use the new syntax or no. However, even with that solution it makes no sense to keep the old syntax around forever. There have been breaking changes in past versions of GM and supporting old features is never fun for anyone.

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...

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.

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 inparticular, 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.

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.

0

My KBInput system is now on the marketplace here. It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput. The support forum topic for it is here.

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. .... ....

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.

0

My KBInput system is now on the marketplace here. It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput. The support forum topic for it is here.

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.

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.

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.

0

Previously game developer at YoYoGames, Currently PHP developer in DB-Team
Programming and working with: GML/C#/PHP/JS/MySql/CSS/HTML

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.

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?

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.

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.

0

Previously game developer at YoYoGames, Currently PHP developer in DB-Team
Programming and working with: GML/C#/PHP/JS/MySql/CSS/HTML

Okay.... gonna wrap this one up for now. Lots of interesting points for us to consider. On the one hand, I would love ALL GML to be more object orientated, I think it's far less error prone, less verbose, and would allow some nifty additions. On the other, I totally understand the desire of non-coders to keep it the current syntax, either simply because they like it that way, or because they find coding hard, and don't really want to struggle with having to learn a different syntax. I do understand this, and agree to some extent. I'm also well aware that most folk in here are coders, and the results are biased towards that.

If we went forward with the "global" change (and I mark that with a big ol' IF)... then yes, it would affect everything, instances, sprites, sounds - everything. This means you'd end up with code like this...

So kinda like this... Things like "with(sndMyPingSound){ volume(0.75); }" would still work, meaning you don't have to store everything, you could carry on as before. Don't worry though, even if this did happen, it's a looooooooong way off. I'm not sure I'd head into namespace territory, but that choice is also a long way before we off even start thinking about it. GML is interesting because it's already a mish-mash of styles, so adding another (while keeping the ones that are there), isn't so far fetched. Our concern with this, is that all the examples users make for each other would start to use the alternate syntax, and this in its self would make GML harder for newcomers to learn. Imagine if we added lambda expressions, experianced coders would probably love them. But the upshot would be loads of code saying "you just do this, it's easy!", and newcomers wouldn't have a clue. GML is nice because it's a fairly level playingfield, we have to work to keep that.

So our main goal is to keep it easy to learn, but at the same time allow more experianced coders the power they want in order to stay "in" Game Maker longer, and possibly allow professional devs in at the top end as well. Make no mistake, it's a hard thing to do which is why we're taking small steps to see if we can get an idea of whats acceptable.

As I said before, fear of change isn't a reason not to do it. We all like what we know. That said, change for the sake of it, also isn't a reason to do it. We'll keep thinking about it, and see what we can come up with. If we think of something that might be a compromise, I'll come back and discuss this further.