I got three separate input handling systems for my game.

Unity Engine
1

Things are getting out of hand….

I got three separate input handling systems for my game.

One input system handles clicking on buttons to swap between screens. It reads a click on the Pause button on the main game “Play” screen to bring up the “Pause” screen. The Pause screen has volume level controls and buttons to bring up one of the following screens: Options 1, Options 2, Store, Play.

Then I have another separate input system for the Options 1 screen. The Options 1 screen has buttons to select either offline or online mode. If the “Offline” button is selected a list of selectable AIs popd up. If the “Online” button is selected a list of selectable game rooms pops up. There is also a “Back” button to go back to the Pause screen and and “options 2” button to go to the Options 2 screen (not implemented yet).

Clicking on an AI in the AI list starts a single player game. Clicking on a room in the Room list starts an online multiplayer game.

Then I have one more separate input system for the actual gameplay that accepts clicking on a piece to select it, clicking on buttons to rotate the selected piece, then clicking on the board to place the piece.

I do use layers to keep input separate. e.g Board layer, UI layer, HUD layer. etc. But as you can tell, things are getting quite complicated and out of hand.

This is my first game in Unity and I’d like to know what are standard or accepted procedures or best practices (such things probably don’t exist) for designing a comprehensive input system that handles menus, HUD, and gameplay input?

2

Merge them? Why have input all scattered like that?

3

Components. Separation of responsibilities.

4

In any large project, GUIs can quickly get complicated. While I don’t suggest sticking super strictly to design patterns, we use the MVP (Model, View, Presenter) design pattern to help make sense of our GUIs. There is also a variation MVC.

I have a master parent GUI MVP GameObject. Every GUI window gets its own child MVP GameObject to control it.

We also have a HUD MVP that controls the display (health, money, etc) while the game is running and also reads the input from the virtual pad on mobile devices.

It can be a pain to learn MVP or MVC but it helps keep the separation of responsibilities sane!

5

Thanks Garth. That is what I wanted to hear and that is what I was shooting for in my own clumsy way.I was hoping to keep things logical and simplified but ended up with exactly the opposite. I know the MVC concept but never really used it. I never heard of MVP and I’m going to look into it.