Do you always need arrays for menus?


I'm quite new to GM2, and have been looking at some menu tutorials that are out there. They all seem a little complicated for the kind of menu that I'm looking to make.

I'm working on a mobile game. I'd like to have a grid of square icons that appear after you tap on a parent menu icon. From there, tapping each menu icon will basically just bring you to a new room.

The best analog I can think of for this is the menu system in Neko Atsume.

It seems pretty complicated to create an array system for this, since most of the menu icons will just lead to a room_goto() function. So I'm wondering if it makes sense to do the following:
  • Create a persistent object with Draw GUI for the parent menu sprite (a little icon that says MENU). Tapping this will expand the menu and show the grid.
  • Create a new room for the expanded grid menu, which will simply appear over the previous room.
  • Create an object for the expanded grid menu, and use Draw/Draw GUI to draw the "buttons" (which will be sprites). Then in the Step event, program it so tapping each sprite will bring you to a different room
I do plan on having one or two menu items such that tapping on it runs a script instead of simply going to a new room.

Does it still make sense to organize this in an array, as is typical of menus? Or can I hack it together this way?


Well, you'll want to check out the programming section for future questions like this, this sub-forum is mostly for issues with the engine itself.

As for arrays, most people use arrays for menus simply because it's actually quicker once you're used to arrays. For a one off thing like a menu, an array isn't strictly necessary, it's just easier. Because you can index an array, you can do tricks where you can use math on the index to appropriately select the correct menu item and move the menu selection sprite to the correct place, and it's extendable easily. Yeah, it doesn't do a whole lot for a menu, but once you've used arrays they are an extremely easy structure to work with and shouldn't really cost any additional time. Personally, I would use them just so you get used to the idea of arrays and lists, as you will eventually basically need to use them at some point.

But if you just need to hack something quickly right now, not using an array won't kill you.


Forum Staff
Create a new room for the expanded grid menu, which will simply appear over the previous room.
That won't be as "simple" as you're making it sound here, as only one room can be active at a time. For this to work, at least one of the rooms involved would have to not be an actual room, but a collection of data structures which react and are drawn in a certain way... so you're back to using arrays or something comparable, anyway.

With that said, it is certainly more organized to keep menus in some form of data structure rather than spawning a plethora of buttons that are only loosely connected. That's not to say that the latter won't be functional, though - I imagine you'd have to jump through a lot more hoops to get it to work, though.


Friendly Tyrant
Forum Staff
My own advice on something like this is simply to use instances! If the grid is a set of buttons and pressing each button does something (like call a script or change room) then why not use the simplest of systems that is at hand and create multiple button objects and have them each do the task to be performed? This is made even simpler thanks to the parenting system, since you can create a parent button object that does all the things like fade in, fade out, check for mouse over, mouse pressed, etc... and then create child objects for each of the different buttons and only add in the code that is relevant for what the button does.



aka fel666
My advice would be to play with arrays a little until you are comfortable using them.
Create a couple test projects and try different things. Can you loop over any sized arrays? What can you store in San array etc...

The way GM users learn programming (including me) is a little backwards.
They learn to use instances and collision detection before arrays and loops.
In actuality, arrays and loops are far simpler concepts than instances. You just need to spend a little time to familiarise yourself with them.

They won't only help you with writing menus. Pretty much All your game systems can be made simpler, more efficient, or more flexible using arrays, loops and other basic programming constructs rather than building them up with instances.


šŸ§ *penguin noises*
GMC Elder
In many of my first games, I had an animated sprite with text and a cursor that moved between all options one by one, and had each selectable option correspond to current image_index. This is not very extensible, but it DOES let you do a really stylish menu since the different images don't need to be similar in any way (you could change the cursor for each option, make the text of the highlighted one much bigger, etc).


As I'm sure you've realised by now you don't have to use arrays for buttons.
I started of using an instance for each button but I usually use a for loop and the draw GUI layer now.
I found an array useful for making a staggered effect where the buttons cell out from the left one by one rather than all together.