Hey Guys,
So I am planning out the game logic / view system for our new engine, and I was hoping to brainstorm/get advice on one of the issues I ran into with Orbito, and how I could better design my system to work nicer.
The problem I came to with Orbito was in that instead of using a simple switch statement based state manager like GCC, I decided to split up my logic into state classes, which was much better to organize and extend, however one of the issues I had was that I assumed that I should also bring my views along for each state, so in the end while having states for;
- Intro
- Main Menu
- Credits
- Setup
- Loading
- Game
- Summary
Each one of these states had multiple views for each player, the intro state had a really simple one that translated any input to switch to the main menu state, however in the main menu, there were 4 views for representing possible players that could enter the game ie. Each player could move the menu selector, and enter the setup screen. There were also 4 views in the setup state, and game state.
One of the issues that came with this was having to essentially transfer info on each view used to the next state ie.
- In the main menu, if the second controllers 'A' button was pressed, the player 2 view would capture this and send an event to the main menu state to switch to the setup state with player 2 active
- In the setup state, each player who received input which matched the confirm or 'A' button would send an event to the setup state to activate that player (the active player data was on the logic side)
- When all players were ready and the start game button was pressed, the loading state would be notified to create each active player in the game state, thus creating 1-4 views as well as the actors for them
- The game state would already be set up from the loading state
Personally I found this back and forth transferring of confirmations from view -> logic -> view -> logic, really cumbersome, yet I am having trouble thinking of any other way to do it. Some questions I would like to hammer out are;
- Where should the views belong? In each state, globally, both?
- Should they be shared between states?
- If employing a component based view system (which we are considering), could we maybe remove things like a main menu controller component and add on a game controller component when switching?
Specifically Mike and Rez what are your experiences with this and is there a better way to do this?
Thanks
So I am planning out the game logic / view system for our new engine, and I was hoping to brainstorm/get advice on one of the issues I ran into with Orbito, and how I could better design my system to work nicer.
The problem I came to with Orbito was in that instead of using a simple switch statement based state manager like GCC, I decided to split up my logic into state classes, which was much better to organize and extend, however one of the issues I had was that I assumed that I should also bring my views along for each state, so in the end while having states for;
- Intro
- Main Menu
- Credits
- Setup
- Loading
- Game
- Summary
Each one of these states had multiple views for each player, the intro state had a really simple one that translated any input to switch to the main menu state, however in the main menu, there were 4 views for representing possible players that could enter the game ie. Each player could move the menu selector, and enter the setup screen. There were also 4 views in the setup state, and game state.
One of the issues that came with this was having to essentially transfer info on each view used to the next state ie.
- In the main menu, if the second controllers 'A' button was pressed, the player 2 view would capture this and send an event to the main menu state to switch to the setup state with player 2 active
- In the setup state, each player who received input which matched the confirm or 'A' button would send an event to the setup state to activate that player (the active player data was on the logic side)
- When all players were ready and the start game button was pressed, the loading state would be notified to create each active player in the game state, thus creating 1-4 views as well as the actors for them
- The game state would already be set up from the loading state
Personally I found this back and forth transferring of confirmations from view -> logic -> view -> logic, really cumbersome, yet I am having trouble thinking of any other way to do it. Some questions I would like to hammer out are;
- Where should the views belong? In each state, globally, both?
- Should they be shared between states?
- If employing a component based view system (which we are considering), could we maybe remove things like a main menu controller component and add on a game controller component when switching?
Specifically Mike and Rez what are your experiences with this and is there a better way to do this?
Thanks
PC - Custom Built
CPU: 3rd Gen. Intel i7 3770 3.4Ghz
GPU: ATI Radeon HD 7959 3GB
RAM: 16GB
Laptop - Alienware M17x
CPU: 3rd Gen. Intel i7 - Ivy Bridge
GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
RAM: 8GB Dual Channel DDR3 @ 1600mhz
CPU: 3rd Gen. Intel i7 3770 3.4Ghz
GPU: ATI Radeon HD 7959 3GB
RAM: 16GB
Laptop - Alienware M17x
CPU: 3rd Gen. Intel i7 - Ivy Bridge
GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
RAM: 8GB Dual Channel DDR3 @ 1600mhz