70 replies to this topic

[mcoot]

I would certainly like to have simple structs in GML. Personally I'd like full-on classes (with methods!) as well, but structs are certainly a step in the right direction.

As for syntax - my vote goes for C# style - for me, it matches my syntax 'style' (I generally tend to do my syntax in a C#-ish way for most things).

[@Alex@]

(You'll also notice I want CODE constants... I hate having to define them in via the menu)

I personally hate using the menu to define constants too, I normally end up using globalvar VAR ; to create makeshift "constants".

I've never used structures in any other language but after a little bit of research I believe it to be a good idea to implement.

[sabriath]

Problem with "creating structures" on the fly is that it becomes pretty hard to understand: similar to objects and instances, you have structures (and objects? not sure which term would apply here)..

So you would have 2 "structure_create(...)" functions.. (1 to declare a new structure, 1, which takes a structure as argument and actually creates the container).

I was going on the assumption that structures will be made _EXACTLY_ like objects and instances...except there are no events triggered on them. I have done nothing different than what is allowable by GM to perform on variables in instances for the structures...which means, yes, you can do this:

o = object_add();
object_event_add(o, ev_create, 0, "experience = 0; nextexp = 100; level = 1;");
object_event_add(o, ev_other, ev_user0, "if(experience >= nextexp) level += 1;");

i = instance_create(0, 0, o);
i.experience = 104;
with(i) event_user(0); //yay, the instance gained a level

I only took that same idea and pushed it into structures on-the-fly concept:

stat = structure_create();
  structure_add_var(stat, st_public, "experience", 0); //same as ev_create "experience = 0;"
  structure_add_var(stat, st_public, "nextexp", 100);  //same as ev_create "nextexp = 100;"
  structure_add_var(stat, st_public, "level", 1);      //same as ev_create "level = 1;"

player = structure_new(stat);  //'player' is now an instance of the structure
  player.experience = 104;     //exactly the same thing instantiated objects are allowed to do

So much for preventing typing, and actually increasing the difficulty:

huh?

btw: *WHAT* is the point of private variables if you don't have member methods? To store something which can't be retrieved in any way?

If there are no methods for structures, than private is useless....but if Mike/YYG doesn't add methods, than it can still come in handy to have the type argument be dynamic/static choice.

I personally hate using the menu to define constants too, I normally end up using globalvar VAR ; to create makeshift "constants".

You do realize that you can write your constants into notepad pretty easily and just import the constants? It's what I do. If you want to know the format, simply make a few constants and export them, then look at the file...pretty easy. Maybe you can go put that in the suggestion topic.

[gnysek]

I always forget to use constants, if they were in a #Main script it wouldn't just be useful to define constants, but also a number of other things.

It's good idea to have MainScript in Game Maker, where all variables can be set, and some scripts that should be run beofre whole game (like loading settings when game have some options, setting global.variables or preloading resources from disk...).

[Smarty]

You do realize that you can write your constants into notepad pretty easily and just import the constants? It's what I do. If you want to know the format, simply make a few constants and export them, then look at the file...pretty easy.

Except that you want to go back at times and make changes. For every change, you'd either need to edit the text file and delete constants to reimport that file, or enter the constants dialog anyway to modify them. It's not difficult, but there are still a few unnecessary steps involved in its maintenance.

[sabriath]

Except that you want to go back at times and make changes. For every change, you'd either need to edit the text file and delete constants to reimport that file, or enter the constants dialog anyway to modify them. It's not difficult, but there are still a few unnecessary steps involved in its maintenance.

I understand that point...that's why I said to "go to the suggestion topic and let them know" because this topic is based on structures, not the constant table.

For me, if it's only a few constants, I'll update them in GM and export them to the file that I am using as an intermediary. If it is a huge change, I'll open the file and edit it in notepad++ instead...then save, clear and import, done. I know the steps are long at this moment, but the answer to this problem is not by allowing const declarations in GML at parse/interpreted time, but rather redo the editor itself to allow a textpad editing. Again, that's something for the suggestion topic.

With this post and yours, we've gone offtopic, apologies to Mike and others. But at the same time, it is my opinion on the 'const' that Mike mentions briefly in a few of his code snippets in this topic (the same reasons I have about structs, apply to const in code).

[round]

If you like using objects so much then why do you use data structures so much in your games? Because it is way faster.

that is exactly the problem with instances. 10,000 instances of an object are slow because game maker is doing who knows what. but 10,000 values in a data structure list is fast because nothing is being looped. nothing is happening. it's just data sitting there. make the background thinking in instances optional.

so, why did you suggest to use instances then?

oh...in non-programers' view, instances are much much easier to use. Users of Game Maker are mainly non-programmers. They want an easy tool to make game. Don't change GML to anyone's favourite programming language but make Game Maker a game making tool as easy as possible.

[Rusky]

Another useful addition as part of structs would be object literals. Python, Lua, Ruby and JavaScript all have something like this:

var foo = { bar: 3, baz: "quux" }

This would be especially useful for putting data in maps, returning more than one value from a function (e.g. lengthdir) and defining structure values in general.

While it would of course be possible to do something like C/++/# to get literal values for statically declared structs, it would be much easier to leave them all as struct/map/dict type as you would only have to list the fields in one place- where you use them.

It also reduces complexity when dealing with structs with identical field names. When you receive such a struct value as an argument, you can't immediately tell its type, but it really doesn't matter as long as you can say "foo.x" and "foo.y". It doesn't matter that it's a "struct point" or "struct vector"- so why even make the distinction?

Forcing users to explicitly list fields before they use them, in a language like GML, is not really necessary and is in fact more complicated to use.

Edited by Rusky, 07 February 2011 - 03:15 PM.

[thatshelby]

Another thought... Could we have temporary structures, like using the 'var xxyyzz;' command in GML? It would be good for scripts where you define a TON of temporary variables.

Edited by Theophilus, 07 February 2011 - 04:03 PM.

[paul23]

Another thought... Could we have temporary structures, like using the 'var xxyyzz;' command in GML? It would be good for scripts where you define a TON of temporary variables.

What would happen with the data if I return a "temporary strucute"?

A structure in itself doesn't contain data (and should be "0" size). - It's an initialized structure which does - so there's no need to keep a "structure" script local (the initialization of this structure however should be).. The only reason for var declared structures would be to prevent name collisions/information hiding.