mike3

@SquaredD: "The inventory sub-state and the in-the-action sub-state can send commands to the ingame state to process." However, I thought that game states were supposed to be kept separate. But am I right in thinking this communication is OK in this sense since what we are doing here is building a _hierarchy_, and states on the lower level of the hierarchy (the sub-states) are not directly communicating with each other, but are instead communicating with the states on the higher levels of the hierarchy, and so the coupling of sub-states is loose and not tight?

Also, do the sub-states contain their own loop or just render/logic/input (or just render/logic only?) functions? If just those functions only, then it still doesn't seem to solve the problem of suppressing the input for the loop cycle performed while in the "game action" substate that immediately follows the ending of the "inventory" substate when processing drop commands (since the logic for that cycle is not using new input, but rather completing a command in progress).

Depending on the game style, whether realtime, turnbased, multiplayer I can see lots of possibilities for resolution. I think the second option Matais presented would be the cleanest.

 

while(running)
{
   //Process input.
   //process events
   // update logic
   // render
}

 So user presses d, the input is processed, a state change is requested, the rest of the logic is handled, and the scene is rendered. on the next iteration, the menustate allows the user to select the item for dropping, the scene is rendered again, and we return to the gamestate. on the next iteration, we now have an event to process(user dropped itemx) so we handle it. process the rest of the logic, and render our 3rd frame.

However, there's the problem: "a state change is requested, the rest of the logic is handled..." -- but we shouldn't do a turn's worth of logic until after we get the item to drop, since the drop happens as part of that turn. And also "on the next [3rd] iteration, we now have an event to process"... but on that iteration, before we get to "handle events", we go through "process input"... yet we shouldn't process more input until we have finished the drop.

OK, maybe my explanation wasn't quite good. I wrote my post kind of hurriedly. Hopefully this is better:

The loop would look like (pseudocode) (note this loop is for a simple "text mode" roguelike with no continuous animations, etc. -- that would require a different kind of loop that runs many times per second):

while continuing: // 1 cycle = 1 turn in "playing" state
      input = inputSystem.getInput();
      gameState.logic(input);
      gameState.render();

The state changes happen at the end. Consider what happens in the loop when one presses a "d", for "drop item", say. The input system gets the "d" key press. This then goes on to the logic _for that game turn_. However, _we cannot complete the command without first getting a choice of item to drop from the inventory menu_. So, we must:

1. defer the logic for the rest of the turn (move monsters, etc.) until the menu completes

2. switch to the menu state

3. when the menu gets its input, switch back to the game state.

4. finish processing the command and handle the logic for the turn.

Now, assuming the state transitions happen at the end of the loop, consider what happens in (3). The loop completes its final cycle in "menu" state, then switches back to "playing" state. But our work is not done -- we still need to do step (4). Yet when the loop executes its next cycle, now back in "playing" state again, it goes to requesting input again, when it should go to finishing up the logic for the turn. And the logic function will start all over again from its beginning, with a new input... what happened to finishing up the command we wanted to do (drop the item), and handling the remaining logic that would follow it in the turn?

However, aren't Qt and similar systems for rendering windows and widgets in the OS desktop environment, not for rendering them inside a game's render area, like on the console or inside a fullscreen graphics display using OpenGL, SDL, etc.? So it would seem that to use them would require extensive recoding of their render system, no? Seems that'd take an extraordinary amount of work.

Also, I've noticed that I'm still not sure as to how to do the rendering system in general. Should one just have one big "renderer" object that takes in maps, dialog widgets, text messages, "stats" info (i.e. player's HP, etc.) etc. and renders them to the screen?

What do you mean by "messages" here? Like telling the dialog to add an item to its list box, etc.? What uses the queue? What do you mean by "answers"?

I mean it more like a message-box not a system message. Like any string you want to represent to the user, like "Really drop item XYZ" which has possible answers "Yes/No" and a follow up message of either "you dropped item XYZ" or "you stow item XYZ in your bag again". You use the queue to make sure the user doesn't miss any of the information. Say you move on a square with a trap on it, which will generate information for the user: 1. there is a trap, 2. whether you fell into the trap, 3. if you fell in how much damage did you take. The Queue ensures that the UI can digest the messages in it's own pace and you don't miss any message.

Ah! A queue for the display messages. That makes sense But I'm asking about how to represent/implement dialog boxes with widgets on them that show various kinds of information, drawn on the game screen. Not as many kinds of widgets as an OS GUI would have (and nowhere near the same level of functionality), but some, like simple list boxes and text fields (as mentioned in the original post, this is to show stuff like the items in your pack, magic spells, and so forth.). How to represent that and also present it to the rendering system (the layout, widgets, etc.). What would you suggest?