13 replies to this topic

[ugriffin]

An array class like Cocoa's 'NSArray' or C++'s 'Array' class would be incredibly useful in Game Maker. +

Right now, we only have basic C-style arrays in GM, which have the following disadvantages:

• No way to get the size of the array aside from using scripts (slow).
• No way to insert data from the array.
• No way to delete data from the array.


I am aware ds_list could be considered a good array replacement, as it has all of the features I requested, but ds_lists take time to use and type.

For example, let's compare:

GML:

if(ds_list_size(listname))
{
}

Objective-C:

if(array.count)
{
}

I know back in the day I was heavily against OO'ing GM, arguing against the 'ease of use' factor (something which I believe is still a valid argument), but for tools like GM:Studio intended for professional use, the lack of advanced data types is heavily counterproductive.

My suggestion would be to install simple class methods to GM's data types... and make the syntax for calling them similar to C#. For example:

string.realvalue();
array.count();
real.round();

This would also enable us to ditch the ds_functions, replacing them with far superior 'classes'. For example:

ds_list= array
ds_map= dictionary
ds_grid= 2darray

The 'array' class could also be set to organise itself via priority, list, or queue methods, via an array.mode(mode); method.


I believe GM's greatest weakness right now is its tendency to embrace C-like data types, greatly lengthening the amount of typing for trivial stuff like an array size.

[Erik Leppen]

• No way to get the size of the array aside from using scripts.

You mean, no way to get the size of the array, period. At least, I know of none (but I have been proven wrong before, so please post said scripts (variable_exists does not count))...


If we're on the topic of improving arrays, then I know a few additions as well.

a = [1, 2, 5]

Then a[0] == 1, a[1] == 2 and a[2] == 5.

Using this one could pass arrays as arguments and return values:

//myscript:
return [1, 2, 5]

a = myscript(arguments)

We then have a[2] == 5.

One could take this even further by using

//myscript:
return [1, 2, 5]

[a, b, c] = myscript(arguments)

We then have c == 5.

[dannyjenn]

Going along with that, how about being able to stick an array into a script as an argument and return it? Something like

a[0]=5;
a[1]=2;
a[2]=2;
a[3]=8;

b = script0(a);

// script0(argument0)
// argument0 - array of reals

var a,temp;
for(a=0;a<=array_size(argument0);a+=1){ //assuming a size function is added as well
    temp[a] = argument0[a]+5;
}
return temp;

And in the end we'd end up with an array called b which has b[0]=10 / b[1]=7 / b[2]=7 / b[3]=13

[Eyas]

I like most of these suggestions but I would just say that I am not comfortable with the use of C++/C#/Java-like properties of arrays such as ".size" or ".length" in GM, instead go for a more PHP / Python method, using count/length/size(array) instead.

The main reason, I think, is that the paradigm is a bit different for Objects in GM. Namely, we use "." to access properties of instantiated objects, except objects in GM, as opposed to other OO languages actually specifically refer to "Object" resources, rather than any variable / structure / or class. So, GM should make arrays still feel (as much as possible) as variables, and in GM, variables are (for the most part) distinct from objects. I think its an easier (conceptual) jump for GM users to make when imagining a function that takes in a specific variable type (i.e. count(Array array)) than a variable who is treated differently than other variables.

[ugriffin]

I like most of these suggestions but I would just say that I am not comfortable with the use of C++/C#/Java-like properties of arrays such as ".size" or ".length" in GM, instead go for a more PHP / Python method, using count/length/size(array) instead.

That goes against my 'time to type' argument. Especially once autocomplete in GM gets better and more intelligent, using a object.function or object.property paradigm lets the autocomplete mechanism 'guess' what you're trying to achieve.

Let me go with an example.

You start with the letter 'c', because you're looking for the 'count();' function. Chances are you'll have to type 'cou' before you even get the correct suggestion from autocomplete.

Now, the alternative, you type a resource name, let it autocomplete, then type the '.'. With a proper autocomplete system, the 'count' function should pop up at the top of the autocomplete list, because:

1) The autocomplete knows that the resource we're calling a method/property is an array.
2) Using this knowledge, autocomplete can filter out irrelevant methods and functions that have nothing to do with the data type we're trying to use.

This is the way tools like Xcode and Visual Studio behave, and that's one of the hidden reasons why OO style programming is so time-saving. Because it's easier for the autocomplete feature to guess the correct method needed by the programmer based on the object we're calling the method for.

GM needs some sort of method mechanism added anyways, so it's about time we introduce the object.method(); functionality. As for arrays, an array.count or array.size property would suffice, which is already standard GML syntax (object.variable).

[Eyas]

Yeah I understand your argument, I just think the GM paradigm takes precedence over quick typing (especially when we talk about saving a few key-strokes ("cou" versus ".c")), and I also think that using the "." modifier with an array (or any variable / class that is not a resource) breaks the GM paradigm as it stands today.

While we might be OK with making GM a bit more advanced, I don't think we can make the learning curve much steeper.

[Oracizan]

I agree with Eyas. I think that arrays are important enough to be "built-in" with more usuability as opposed to using ds_list, and I love Python-like languages, but I think it is important to preserve the GM paradigm. Keystrokes aren't really that important to me, and even if they were intuitiveness and consistency would be more important still.

[Dark Matter]

Having simple OO features would definitely make me want to start using GM a lot more than I do now. There was a topic about it before, by Mike Dailly, if I remember correctly, so if it's been given some thought - it's possible. Perhaps an idea for GM:Next?

[Jobo]

Generally I just want more of C# (syntax included) in GameMaker - seeing as GM is now programmed in C#, perhaps this is not as hard to incorporate as it once was??
It would be splendid in general if we, instead of "Execute Code", could choose within a range of programming languages. Kind of like Unity 3D which has Boo, C# and JavaScript, so when you go to the "Execute Code" group of the D&D menu, you find "Execute C#", "Execute GML", "Execute JavaScript" - instead of just having DLL support and whatnot. It's a very hard addition for the team at YoYo Games but it would increase the value of GameMaker with another $200 at least.

Of course, certain things would only apply for certain platforms.
So a few more groups should be added;

[Universal]
-> GameMaker Language
[PC]
-> C#
-> Java
-> C++
-> Python
-> Lua
[Android]
-> Java
-> C/C++ (if the Android NDK is supported)
[iOS]
-> Objective-C
[Browser]
-> HTML5
-> JavaScript
-> ActionScript

And so on... Very complicated, but could be rather beneficial for advanced/experienced developers...

I'm just daydreaming, but it would be quite a lot of fun to see this in GameMaker.
But then again, if it was included, no one would be able to recognize GameMaker. Although the option to use GML would remain and therefore the program will be just as easy to use as it's always been, but the more advanced users have those "better" choices.

[Dark Matter]

But then again, if it was included, no one would be able to recognize GameMaker. Although the option to use GML would remain and therefore the program will be just as easy to use as it's always been, but the more advanced users have those "better" choices.

By removing GML, you're pretty much eliminating GM's ease-of-use. There are plenty of other IDEs for other languages that would be just as easy as a "C in GM" system, for example.

[Jobo]

I never said to remove GML though.

[filulilus]

• No way to get the size of the array aside from using scripts (slow).
use a variable to keep track of how large the array is

• No way to insert data from the array.

for(i = array_size - 1; i >= array_position; i -= 1)
{
array[i + 1] = array[i]
}
array[array_position] = insert_value
array_size += 1

• No way to delete data from the array.

for(i = array_position; i < array_size - 1; i += 1)
{
array[i] = array[i + 1]
}
array_size -= 1

I know these are slow altenatives to data structures but they work well if you don't use them a lot in each step.

There is how ever no way to free the memory used for a value, you have to delete the whole instance for that to happend.

Edited by filulilus, 13 July 2012 - 11:03 AM.

[Jobo]

• No way to get the size of the array aside from using scripts (slow).
use a variable to keep track of how large the array is
Reply: That doesn't solve the fact that there's no way to get the size of the array, and it adds more memory usage to your game.

• No way to insert data from the array.

for(i = array_size - 1; i >= array_position; i -= 1)
{
array[i + 1] = array[i]
}
array[array_position] = insert_value
array_size += 1

Reply: As opposed to ArrayList.add(int location, Object object); this is just plain stupid.

• No way to delete data from the array.

for(i = array_position; i < array_size - 1; i += 1)
{
array[i] = array[i + 1]
}
array_size -= 1

Reply: You're not deleting the array item, you're just refraining from using it.

I know these are slow altenatives to data structures but they work well if you don't use them a lot in each step.

There is how ever no way to free the memory used for a value, you have to delete the whole instance for that to happend.

Replies are bold.

[filulilus]

That doesn't solve the fact that there's no way to get the size of the array, and it adds more memory usage to your game.[/b]

I know, but that's the way we have to do it right now if we don't like to use dss.

As opposed to ArrayList.add(int location, Object object); this is just plain stupid.[/b]

I know it's time consuming but it works and does what you asked for.

You're not deleting the array item, you're just refraining from using it.[/b]

Not really, I over write the "deleted" slot BUT (notice BUT) I also leave a open slot (memory) at the end of the array, which I talked about in the last post.


Don't get me wrong, I would also like to see improvements with arrays (aspecially 3d arrays (which I can confirm that we won't see untill GM:Next) and be able to pass them as arguments) but there are alternatives that work (data structures and "work arounds" like codes I posted) and I rather see that YYG work on some imo more importent stuff such as shaders.

Edited by filulilus, 13 July 2012 - 01:06 PM.