Proposal for a New Action: Create Array

Proposal for a New Action: Create Array

Problem:
Currently, in GDevelop, the creation of arrays is done manually in the variables editor, which can be time-consuming and laborious, especially for large arrays.

Proposal:
Implementing a new action called “Create Array” that allows:

  • Define the name of the array.
  • Choose the data type of the elements (number, text, etc.).
  • Specify the number of elements in the array.
  • Fill in the values of the elements directly in the action, using brackets and separating the values by commas.

Example:
Create array:
Name: “myArray”
Data type: Number
Elements: 5
Values: [10, 20, 30, 40, 50]

Benefits:

  • Simplifies and speeds up the creation of arrays.
  • Makes the process more intuitive and beginner-friendly.
  • Allows creating arrays with various data types.

Usage Example:
The “Create array” action can be used to:

  • Store map data in a game.
  • Manage an inventory of items.
  • Implement algorithms that use arrays.

Conclusion:
Implementing the “Create array” action would significantly ease the work of developers in GDevelop, especially those who frequently work with arrays.

Are you aware of the Array Tools extension.
https://wiki.gdevelop.io/gdevelop5/extensions/array-tools/#array-tools

These are just the scene variable actions

The focus is not on array manipulation, but rather on exploring ways to create them. Have you ever considered how to create a large array with just a few simple actions? And furthermore, have you experienced the challenge of creating a two-dimensional or even three-dimensional array?

1 Like

I’m not saying I disagree. I was just mentioning the extension in case you were unaware of it.

GD only has extremely basic array events. When I’ve used multiple dimensional arrays, I have created my own actions so I can add multiple values in 1 action. I’ve also used nested repeats. Although, it’s much easier to do in Javascript and I know more about GD than JavaScript.

So, yes. I understand your issue and I agree.

1 Like

Generally the actions in the engine works off the design ethos “One action = One data change”, same for expressions only returning one value, same for conditions comparing against one value.

As far as I understand, this is why when arrays were added a few years ago, they were set up as such (one array action = one element), since they were being added to the base engine and they wanted to keep that design similar.

For what you’re asking, Keith’s response is correct. The “Split string into an array” is not just manipulation, it literally creates a new array with a string of data (such as your example “10, 20, 30, 40, 50”). If you want to not use strings, I’d recommend just modifying the extension to add a parameter for the type of array to create, and then you can add a condition branch into the actions that create the array.

But for strings, this already does exactly what you want with no changes. The array below is not pre-declared, there’s even a message mentioning that, but it’s created as desired after running the game.

Edit: Also note that overall GDevelop does not support multi-dimensional arrays in the way you would think. And it is unlikely that there would be actions added to allow them for the reasons I mentioned above.

You might be able to accomplish it via modifying the array tools extension (or making your own! Adding actions or conditions is one of the main focus of extensions)

Double edit: To be very clear (as it’s late and I somewhat rushed the above to get an answer before bed), I’m not saying you shouldn’t ask for this nor your idea is wrong or anything, I’m just giving context on how you can accomplish it today, and why things are as they are.

I am personally very skeptical of these, since these use cases are not something where you need to “create an array” with predefined data, you would load data in from another source (objects on the scene, user inputs, etc) instead of hardcoding it all in a single event.

Arrays in GDevelop do not have a fixed size or data type, those would be useless.

Counter point: It is rare to want to actually have a static array in GDevelop, and when you do, we already have better tools: JSON.

For cases where you do need a decent chunk of data to be externally edited (Map data, Enemy stats database, etc) you can use the “Load JSON Resource to Variable” to load a JSON file into your game.

If you really need to create a simple static array in events, which I honestly really have trouble seeing ever being an interesting thing to do, you can use the parse JSON string action with a static JSON string.

(I’m confused by this statement, I believe GDevelop should support nested arrays at the same level as any other programming language?)

Yes definitely, I meant more specifically around how conditions/actions interact with it.

The for each child events only parse a single level of an array. Sorry for the confusion

Indeed, in JavaScript, whenever you try to modify the value of an undefined variable, JavaScript automatically creates that variable, as GDevelop also alerts. If you try to use a condition with the wrong variable name, the game will still work because the value is equal to zero.

This is just an example; I know there’s no specific size or data. You can create a variable with 30 elements and define only the first 5 values, which is what I meant. However, the point isn’t about the values themselves, but rather about the ability to create variables as needed. The issue is solely about creation. I don’t think the point I’m trying to convey is clear. I’m not interested in extracting data from an external source, like a JSON, for example. The data will be generated on-the-fly and need to be modified in real-time. For instance, a block-lighting system where light propagates through the indices of a matrix (large enough and with a predefined limit), and with a radius, the farther an index is from the light point in the matrix, the weaker the light intensity (which would be from 0 to 255). I don’t know if you guys understood, but it’s about the ease of quickly creating and modifying the matrix for testing and algorithm improvement.

There is no new feature needed to accomplish this.

What you are asking for is exactly what the action both Keith and I posted about above.