View Confusement

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

    • View Confusement

      Hello again,

      Sorry to waste your time with this amateur questions on architecture, but I seem to be a little confused with the View classes.

      A HumanView is essentially what will be present when the player is running in game right? Yet the Teapot Wars has a MainMenuView.

      Please correct me if i'm wrong, but essentially do we create view for every screen we will have, MainMenu, NewCharacter, Credits, Game each with it's own response to messages and processes etc etc. And then IScreenElements will define things like, MainMenuTable, Inventory, Titlebar.. etc

      and then we simply load the view we want in the game logic based on the state of the game? Which also brings me to my second confusement, why are we storing all the views in a list and then updating them if we only really need to show one at a time? (Well unless we including the AI View).

      If the above doesn't make sense as to what i'm trying to get at, then i'll attempt to redefine my question, essentially I just want to know how Views should be working in game, alongside the states and logic, I don't quite follow.


      Thanks in advance

      Edit: In the view classes wouldn't it be possible to load in an XML file to set the UI style and appearance ?

      The post was edited 1 time, last by thedevsykes ().

    • RE: View Confusement

      A view is a way to present game state and send it requests or commands. Separating views from game logic has a lot of advantages, especially since different views can act different ways, such as a Human View, which draws to a screen a player can see or sends sound through speakers a human can hear, it also interprets input from a controller or keyboard into commands the game logic can respond to.

      An AI view is completely different - in that it doesn't need to output anything to hardware devices or poll input from controllers, but it will interpret changes in the game state, and send it's own commands into the game logic in the hopes of achieving its goals.

      I wouldn't create a special view class for every screen - but separating the in-game screen from a front end (main menu, save games, options, credits, etc.) is a typical design that I'd recommend. The front end itself can have screens designed for the main menu, options, and other screens that can show and hide themselves as the player navigates them.

      The views are stored in a list because you might have more than one view attached to the same game logic - such as an AIView, or even another player's view in a multiplayer game.
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • RE: View Confusement

      Originally posted by mrmike
      I wouldn't create a special view class for every screen - but separating the in-game screen from a front end (main menu, save games, options, credits, etc.) is a typical design that I'd recommend. The front end itself can have screens designed for the main menu, options, and other screens that can show and hide themselves as the player navigates them.


      Why do we need more than one HumanView? TeapotWars has one for the menu and one for the game. Why can't we just push and pop screen elements inside single human view? Are there any benefits to have 2 different views?

      Oh, views, screens, logic separation is probably hardest thing to get in the whole book!
      Looking for a job!
      My LinkedIn Profile
    • RE: View Confusement

      If I was working on a two player, split-screen, co-op style game I'd implement it with two HumanViews. There would be some refactoring needed in the DXUT classes to make this work, since you have two cameras and scenes rendering to a portion of the screen. You'd also need to do some additional work to map controllers to specific HumanViews, but the architecture should handle it.
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • This was (and still is) a little bit confusing for me as well. I think the terminology is mostly to blame, the way I understand it after reading the corresponding chapters multiple times and Mike's / Devast3d's response is...

      "Views" are interfaces into the Game Logic / engine and represent different parties...

      1) Physical Human Player(s)

      2) AI Controlled Player(s)

      3) Networked Player(s)

      etc,

      ...so yes having more than a single view implementation and / or instance makes sense. Ex: You could have 2 physical players (split screen) and 2 networked players playing co-op against 4 AI controlled bots for a total of 8 view instances.

      As for "screen"s (IScreenElements in GCC4), the same thing applies as there will be multiple implementations and instances...

      1) In Game Screen

      2) Character Creation Screen

      3) Main Menu Screen

      ...not to mention you can stack them...

      4) HUD Screen Element

      5) Mini-map Screen Element

      etc,

      ...am I close in my understanding? If so then I agree with devast3d as I don't understand why the main menu got it's own view...

      Thanks!

      Nick
      -bullgoose
    • On the game I am currently working on, our state machine works like this, we have the game logic class, which basically manages 'state' classes, each one of those state classes each have there own set of views and actors, although the game state would be the only one likely to have actors. This is nice, because we can switch states, which stops processing the other immediately, so when we go back to the main menu state, the game state is still there waiting to resume. We could have done it with one state, one view, with multiple screen layers, however I have found that this system works really well, and allows us to separate all of the separate logic and control sets from eachother.

      Not sure if this is something widely done, but it is working great for us.
      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
    • You've said it right, perhaps with a caveat or two.

      First, the Main Menu, I believe, since it is a user interface object, should be implemented within a human view object. BUT - since the Main Menu is something that sends commands into something that can handle mundane things like choosing a level or setting volume for sound effects, there's a good case to be made that it needs a special kind of View and even Logic separate from what you'd have running the game.

      Also, Rez might have an opinion about AI - it is equally correct to consider AIs part of the game logic on their own and thus not requiring a view to interface into the logic. This design tends to improve performance, especially when the human players and AIs are not considered equals (perhaps like you might see in a racing game), but rather AIs are just complicated parts of the game world.
      Mr.Mike
      Author, Programmer, Brewer, Patriot