77 replies to this topic

[Erik Leppen]

I voted No because I think this will complicate GML without really adding much. Currently, GML is quite simple to learn because it has realatively few features. It's quite easy to understand how GML works. A list had an index, and the index is stored in a variable. To access the list, you need to have the index. To get the index, you must read the variable. The variable works just like any other variable. It's all very intuitive.

How's this done with the new system? I am not an expert on this, but I have the feeling that adding new syntactic features that don't really add much functionality-wise, might confuse GM users.

So, how would such a system work exactly? When using

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

is mylist a local variable holding the list index? Which means that mylist is stored in some instance. So we can do

(other.mylist).insert(1, value)?

Also, can I store the list index in a(nother) variable? E.g. can I now say

var li;
li = choose(mylist1, mylist2)
li.insert(1, value)

What would show_debug_message(mylist) do? Can I store the list index in a variable? Also can several instances each have their own mylist (e.g. if I want every enemy instance contain a list of visited nodes)? Can I pass the variable to another instance, e.g. when an enemy wants to know if the enemy it collides with has visited node X)? Can I make a list whose index is global? And how would this be indicated? I'm guessing

(global.mylist).insert(1, myvalue)

How can I make my own script for lists? With the current setup I can make a ds_list_swap and have the list index as argument0 and I can then just do

//ds_list_swap(ind, pos1, pos2)
var temp;
temp = ds_list_find_value(argument0, argument1)
ds_list_replace(argument0, argument1, ds_list_find_value(argument0, argument2))
ds_list_replace(argument0, argument2, temp)

With the proposed list syntax, how would such a swap script be defined in GML, in such a way that we can use mylist.swap(pos1, pos2)? Could you give an example of that?

Finally, can we have something like

mylist.type

to find out whether it's a list or a stack, instance, resource, particle type, etc.? E.g. by using

if mylist.type = ds_list
{
  //code to execute if mylist is a list
}

where ds_list is a built-in constant?

Edit: also, what about an existence check? You cannot do

mylist.exists()

because if mylist doesn't exist, I would expect an unknown variable error. If this error won't appear, this would be an inconsistency in the system, because right now it's a rule in GML that everything to the left of a dot, has to be defined.

As you can see, this whole concept raises a lot of questions I'm really not sure about. And that while the current system seems to work fine for me (or at least not worse than the proposed system).

Edited by Erik Leppen, 25 January 2011 - 07:33 PM.

[ragarnak]

Actually, it is. This would be much faster, as internally, GM doesn't have to dig for the handle.

Only if you force those structures only to be global ones, breaking lots of current functionality.

You see, if you would want to keep being able to store the data-structures handle somewhere (into an instance or script-local variable, into another data-structure or supply to or return from a script) you would have access to that very handle, and thus to be able to access it directly (if supplied to a DLL).

Although I would welcome such a direct-access possibility I don't think that is what YoYoGames wants (otherwise they would have done so long ago ...)

You cannot do

mylist.exists()

because if mylist doesn't exist, I would expect an unknown variable error.

Probably just as in other languages, or pretty-much the same as we currently do with instances : check if the contents of that "mylist" variable is valid. Probably something like

if mylist>=0 {
  mylist.something()
}

Edited by ragarnak, 25 January 2011 - 07:51 PM.

[Erik Leppen]

Probably something like

if mylist>=0 {
  mylist.something()
}

Problem: this ">= 0" business is exactly the arithmetic I thought is frowned upon. At least I don't like it. As a programmer I shouldn't have to know that these indices are nonnegative integers. For instances I never use >= 0, I usually use instance_exists(...) because that's what I mean.

[silentworks]

Is there any chance, that we can add our own methods to collections (objects)?

[IceMetalPunk]

To be honest, I don't really care about the syntax. What I do care about, however, is GM being able to differentiate between a data structure and a real value. That would make it much easier when returning collections from scripts, since the returned value couldn't be used in any way except that which the script intended--as a collection.

I'm assuming this would also mean comparisons between real values and collections would fail (as they should)? That's another plus. When writing lots of code, it sometimes happens that people will do things like this:

var1=2;
/*
.
.
.
Lots and lots of code, time, and testing later...
.
.
.
*/

var2=ds_list_create();
/*
.
.
.
Even more code, time, and testing later...
.
.
.
*/

if (var1==var2) { show_message("Values are the same!"); }

When these things are overlooked, you wind up with code that doesn't work as expected, but also doesn't throw any errors. It makes it very hard to debug when it's in the middle of lots of code.

Of course, if collections are recognized as a separate data type, the comparison would correctly fail and generate a nice error pointing to the line where the invalid comparison occurred.

So, all in all, I'm in favor of this more for functional reasons than syntactic ones.

-IMP

*EDIT*

Probably something like

if mylist>=0 {
  mylist.something()
}

Problem: this ">= 0" business is exactly the arithmetic I thought is frowned upon. At least I don't like it. As a programmer I shouldn't have to know that these indices are nonnegative integers. For instances I never use >= 0, I usually use instance_exists(...) because that's what I mean.

Why couldn't there be a collection_exists() function? Like so:

if (collection_exists(mylist)) {
  mylist.something();
}

Or perhaps an is_collection function, similar to is_real and is_string?:

if (is_collection(mylist)) {
  mylist.something();
}

Either would work; just because the syntax would allow for "instance methods" on collections doesn't mean all collection-oriented methods have to be localized.

Edited by IceMetalPunk, 25 January 2011 - 08:42 PM.

[Rusky]

I voted No because I think this will complicate GML without really adding much. Currently, GML is quite simple to learn because it has realatively few features. It's quite easy to understand how GML works. A list had an index, and the index is stored in a variable. To access the list, you need to have the index. To get the index, you must read the variable. The variable works just like any other variable. It's all very intuitive.

This is a possibility, but not a fundamental part of such a change. With stronger types, you would simply change the concept of an index being a transparent integer to an index being merely a reference to something, and nothing else.

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

is mylist a local variable holding the list index? Which means that mylist is stored in some instance. So we can do

(other.mylist).insert(1, value)?

Also, can I store the list index in a(nother) variable? E.g. can I now say

var li;
li = choose(mylist1, mylist2)
li.insert(1, value)

...
Can I store the list index in a variable? Also can several instances each have their own mylist (e.g. if I want every enemy instance contain a list of visited nodes)? Can I pass the variable to another instance, e.g. when an enemy wants to know if the enemy it collides with has visited node X)? Can I make a list whose index is global? And how would this be indicated? I'm guessing

(global.mylist).insert(1, myvalue)

mylist, mylist1, mylist2, li and global.mylist are variables holding references. To say it another way, they are names for the actual lists GM is managing for you. Everything would work (storing-indeces-in-variables-wise) exactly the way it did before. You could do other.mylist.insert(1, value), choose(mylist1, mylist2).insert(1, value), global.mylist.insert(1, value), anyexpressionthatresultsinalist.insert(1, value). The only thing you lose is using something that wasn't originally a list as an index, like random(3).insert(1, value).

What would show_debug_message(mylist) do?

This is a little bit more difficult, as it's not something you get for free by implementing collections as part of the type system. With GM's current system, it merely shows you the list's index, something that you don't directly care about. It would be possible to do any number of things, such as showing its address or some other unique attribute (many scripting languages do this) or allowing you to print its contents (this would probably be more useful as a separate operation to allow you the same functionality as the current system).

How can I make my own script for lists? With the current setup I can make a ds_list_swap and have the list index as argument0 and I can then just do

//ds_list_swap(ind, pos1, pos2)
var temp;
temp = ds_list_find_value(argument0, argument1)
ds_list_replace(argument0, argument1, ds_list_find_value(argument0, argument2))
ds_list_replace(argument0, argument2, temp)

With the proposed list syntax, how would such a swap script be defined in GML, in such a way that we can use mylist.swap(pos1, pos2)? Could you give an example of that?

That is another more difficult issue that can be solved in many different ways. Some scripting languages like JavaScript and Ruby allow different forms of this, although it can cause problems with libraries, etc. especially when you override existing operations rather than add new ones. Other languages don't allow this, and with this approach you would just have to stick with the old ds_list_swap syntax.

Finally, can we have something like

mylist.type

to find out whether it's a list or a stack, instance, resource, particle type, etc.? E.g. by using

if mylist.type = ds_list
{
  //code to execute if mylist is a list
}

where ds_list is a built-in constant?

This is one of the major advantages of stronger typing. You can tell what type something is and it's possible to add an interface like this (however using it as in your example is generally a bad idea, especially if you have GM's dynamic typing or some other way of writing generic/polymorphic code).

Edit: also, what about an existence check? You cannot do

mylist.exists()

because if mylist doesn't exist, I would expect an unknown variable error. If this error won't appear, this would be an inconsistency in the system, because right now it's a rule in GML that everything to the left of a dot, has to be defined.

In a system like the one proposed, existence is not a question you ask the index, because if you have an index you already know the list exists. It's impossible for someone to give you a number that might not have a ds_list backing it, they can only give you a number that's just a number. However, a lot of languages allow you to check for the existence of a variable or whether it holds a value. It might be possible to pass a null value (also enabled by an improved type system), in which case you would check if mylist == null, rather than doing ds_list_exists(mylist). This is a stronger guarantee, because you know that if it's a list it actually is list rather than a map or a sprite or a texture.

As you can see, this whole concept raises a lot of questions I'm really not sure about. And that while the current system seems to work fine for me (or at least not worse than the proposed system).

Most of your concerns are not really a problem, as those aspects of the system would not change. The others are all generally improvements over the existing system, so there's nothing to worry about.

[Manuel777]

I voted 'Yes', because i like the idea of being able to point a structure in a so direct way... it's also easyer for me to handle and understand.

[gnysek]

//ds_list_swap(ind, pos1, pos2)
var temp;
temp = ds_list_find_value(argument0, argument1)
ds_list_replace(argument0, argument1, ds_list_find_value(argument0, argument2))
ds_list_replace(argument0, argument2, temp)

With the proposed list syntax, how would such a swap script be defined in GML, in such a way that we can use mylist.swap(pos1, pos2)? Could you give an example of that?

you talking about:

//ds_list_swap(ind, pos1, pos2)
var _oldval;
_oldval = argument0.find(argument1);
argument0.replace(argument1, argument0.find(argument2));
argument0.replace(argument2, _oldval);

Since it should work like instances of objects, I didn't see any problem in it - that's the way that they works now, by references.

What is more fun with this syntax list will works like arrays, and maps like associative array, so we can even think about that syntax:

ds_map_find_value(_data,123) == _data.find(123) == _data[123]
ds_map_find_value(_data,'key') == _data.find('key') == _data['key']

Nice, isn't it? It remind's me PHP now.

Going further:

//example of existing structure
_var1 = ds_list_create();
_var1.add(1,'val');

// new data type
_var2 = ds_array_create(); // now it's like... _var2 = new Array()
_var2.push('value');
for (i=0; i< _var2.size(); i++) //postincrementation will be available in 8.1
{
    show_message(string( _var2.indexof(i) ));
}

In GM6/7/8 you cannot check array size and you must always use another variable to keep that info, and update it by your own. Think about it before saying 'no' to new syntax

Edited by gnysek, 25 January 2011 - 09:37 PM.

[Docopoper]

If you are going to add this would you add the vector array types? ie vector2, vector3 and vector4

Edited by Docopoper, 25 January 2011 - 09:43 PM.

[Docopoper]

My point! ... I bet you were typing you'r reply when I posted... :-(

I think it is a good Idea, I loved that about C# when I started moving to it (still moving to it).

[gnysek]

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.

Exactly, we have this for now:


How it looks in object-oriented pseudocode:

class GMObject {
	x = 0;
	y = 0;
	visible = true;
	speed = 0;
	image_speed = 0;
	...
	// and many otherbuild-in properties

	function create() {} // constructor
	function destroy() {} // destructor
	function step() {}
	function draw() {}
	... // more events here
	function userDefined15() {}
}


class object0 extends GMObject {

	function construct() {
		this.myVar = 1; // not existsing variables are set by magic method
		this.myOtherVar = 2;
	}
}


// and now instance_create(x,y,obj) from GML is like:
class GML {
lastInstanceId = 1000000;
// ...
	function instance_create(x,y,obj) {
		i = new obj();
		i.x = x;
		i.y = y;
		i.create();
		return this.lastInstanceId++;
	}
// ...
}

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.

[Nocturne]

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

[ugriffin]

No, please no.


I hope you read my argument and take it more than just 'meh'.


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.

Edited by ugriffin, 25 January 2011 - 10:26 PM.

[TheMagicNumber]

if you added pointers then I would consider using GM again

You wont be using GM again. Nice to know.

@ugriffin: It's not difficult to learn. It's just different. Would you rather have handles or objects?

[filulilus]

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.

Edited by filulilus, 25 January 2011 - 10:58 PM.

[Revel]

if you added pointers then I would consider using GM again

You wont be using GM again. Nice to know.

Shhh. Glad you caught my drift.

[Sindarin]

Does this topic concern ds lists only?

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.

Edited by Sindarin, 25 January 2011 - 11:46 PM.

[Yourself]

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.

[Rusky]

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.