Looking for advice/gossip/theories on how to structure a game’s menu in code.
The last game I worked on and the my current one uses a finite state machine to control where the player is currently located within the game (thinking of switching to a different system to improve flexibility).
If the player is in the main menu the current state in the machine is “GameModeMainMenu”, if its the garage it’s, “GameModeGarage”.
Finite state machines are great when you go into a game mode / level, you can just change the state like so:
GameModeMachine.State = new GameModeLevel(<level>,<difficulty>,<etc>);
The problem I have is when you try to have a modular menu system where a notification window can be reused, or the options screen can be accessed anywhere in game.
You can’t just switch the state to GameModeOptions as that breaks the idea of the finite state machine.
The reason I used state machines in the beginning was so I could setup events like Open(), Close() and run code that would either prepare the menu or destroy it properly.
Here’s what I currently have:
Menu’s can all be called from their static class MyMenu.Create() which creates a new instance of MyMenu and adds it to MyMenu.Instances
Menu’s can be created multiple times by passing a reference MyMenu.Create(“Menu1”);
Each menu has Hidden,Destroy,Depth properties so it’s easy to control them individually, even duplicates.
Any suggestions on how you would go about structuring a menu using these?
I personally use a system that is similar to this one http://www.blog.silentkraken.com/2010/06/22/unity3d-manager-systems/
Except that I keep the GameState and Screen state completely separated, each Screen is responsible for it’s self.
Example: I have a 3 step menu till you reach the play state, the whole time I am still in the Menu State even tough I am showing different Screens.
I decided to split the game modes and menu “modes” into two different systems like you mentioned.
I’ve called everything that happens before the game actually starts a menu mode, then each game mode type is it’s own mode.
All of my menu’s can be instanced and they are only allowed to talk to other menus that are created from within themselves (everything else is through database access or the constructor).
The menus have their own Load,Show,Hide events that get called appropriately so the button delegates can be set up etc…
I think this design is going to be much easier to manage and update in the future and it allows me to call any menu at any time and it’ll function as expected.
I usually just use booleans… I may be highly unusual in that I rather like using OnGUI for most GUI code unless it’s on a mobile device. So, if (boolean == true) { one menu. And so on.
Nested menus would be nested ifs, too. So if (mainMenu == true) { and if (loadGame == true) {, I’d be in the load menu.
I’ve been looking over different solutions to what you originally asked in the post. It seems like the conclusion you came to may be something I’d like to try to implement, but I was a bit vague on the details on how to implement such a system. You think you could make any suggestions on how to implement such a system.
I used to do things as suggested by this, but I now go for far more dynamic and data driven solutions that leverage Unity’s component oriented nature. They also don’t require any kind of programming to change the content or navigation between screens, dialogs, popups or overlays.
If you’re interested I can possibly show you next time you’re at an ARGGGH?
