Legacy GM how would you design a menu

R

RoooodWorks

Guest
How would u design a menu like :

would u have different rooms for each part of the menu, or u would u have 1 room and use images and when a click on 1 option it deletes all objects in room and replaces them with whatever objects is needed for the menu option u selected.

if u go with making them all different rooms, how would u go back to the room when u pressed the menu button and make it remember what room you was in.

I want to go with whatever is best, I don't mind coding even though i am still learning. I am makign a castlevania type game (not a fan game.) and was wondering what best way to go about making this, there is no tutorial for making menu's just title screens.
 

Bingdom

Googledom
In my game i had 1 room for the start menu, deleting the buttons as i press and 1 room for the actual gameplay.

You can contain several scripts that can contain code of spawning objects, to help keep you very organised. e.g.

SCR_Item() will have:
Code:
instance_create(x,y,OBJ_Inventory_Grid);
instance_create(x,y,OBJ_Inventory_Modifier);
Parent all of these objects so you can easily delete them when you click on the back button.

SCR_Back() can have:
Code:
instance_destroy(OBJ_Buttons); //Make sure this is the first thing you do, you don't want to delete the new buttons you just created.
instance_create(x,y,OBJ_Button_DSS);
instance_create(x,y,OBJ_Button_Item);
instance_create(x,y,OBJ_Button_Card);
If you're going to switch rooms during gameplay, make your main objects (Stats, Inventory) persistent.

This is just from my experience and may not be the best option, i'm still learning too. ;)
 
Z

zircher

Guest
You could also do it as a GUI that overlays you existing room whenever you hit the appropriate key, handy if you want a translucent background.
 

Drell

Member
The best way to do anything that doesn't involve a dynamic instance (one that needs to be controlled in a lot of ways or respond to a lot of different occurrences) is to avoid using objects and sprites as much as possible. For menus, you don't really need more than 1 or 2 objects. You can draw sprites (or if you're up to it, tiles) and manipulate the way the look using GML which will ultimately speed up your game. The best way to do this is by creating menu functions that can call variables from an array, which is functionally what a menu is.


I actually just finished coding a set of functions that I will probably export as an extension once I've got it clean that creates menus as lists using text, as well as menus as grids using a single sprite with multiple sub images as well as arrays which can contain any number of sprites. You can set both list style and grid style menus to have varying numbers of rows and columns. When I'm done with it, you'll be able to import images from tile sets by specifying the tile sizes, and then change those images based on whether their the currently highlighted option.
 

Freddy Jones

Your Main Detective
I typically despise programming GUI at all. I make sure to use rooms in Game Maker to their fullest by separating GUI layers by rooms. There's really only ever complicated situations where room's wouldn't be a viable option, but I've never really found that to be true.

Basically, I'd just have a few instances like this:
- par_gui_button -> does stuff a button would do, and if activated calls its user_event 0 with a state describing the action
- Obviously, make a button instance inheriting from par_button that does what it should on click
- par_gui_*element -> anything else that has repeatable behaviors

Now because I'm not exactly sure what else the menu incorporates, I'd just keep it simple with whatever else is visible in the general room outlined with basic par_gui elements. Say, you had that box to the right change for each button. You could have it change completely programmatically or just place multiple objects on that you activate or deactivate when it's appropriate.

To address the issue of going back to the appropriate room, you could implement something like this:

Code:
///room_stack_init()
// called at beginning of game once.
global.room_stack = ds_stack_create();

///room_stack_save_room(room)
// use this just before going to a new room that way you can go back
ds_stack_push(global.room_stack, argument0);

///room_stack_previous()
// use this to get the previous room.
//  can keep being called until you're back at the room
if( !ds_stack_empty() ){ return ds_stack_pop(global.room_stack);}
else{ return room; }

... also need a stack clear, incase you don't want to go back to the previous rooms after an action
And because changing rooms will remove any saved progress in the room you're leaving, you'll want to make important rooms (almost never any room besides the one that has the gameplay) persistent to start with, or make it persistent programmatically before changing rooms.

Regarding what @zircher said, you can still do this with having a room based GUI, just copy the surface of the room to a global surface and display it behind your gui. If say, you wanted the room to not be paused, then using rooms would need to be more intricate in design.
 
Last edited:
Top