Proper view setup for state objects

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Proper view setup for state objects

      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
      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
    • I think I would approach this problem by breaking it down into three discrete components: the frontend, the lobby, and the game.

      The frontend will contain the intro, main menu, options screen and anything where the player is simply interacting with user interface objects that model game settings or transitions to the lobby or launching saved games.

      The lobby will have a view for each player and an authoritative logic that knows who is in the lobby and how to match them into a game. In this kind of view, a single player typically has the authority to change game settings if they've created a game, or for other players they need to be able to issue commands to the logic to search for a game they'll want to play.

      When the game is actually launched, it will also have one view for each player and the remote logics/views needed to match up remote players with the authoritative game logic.
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • Thanks Mike, we came to that same conclusion as well after a while of planning, I think it's going to work out good this time :D
      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