@requerent: So what exactly is the kind of design approach you're suggesting? You have a big pile of data called "game state" with no member functions that various objects manipulate using their routines, and which has no routines associated to it itself? Also, you say stuff like "It's pretty standard nomenclature. Controller.Verb() queues a call to Actor.doVerb(). That's how Unreal does it anyway.". What's an "actor" in this setup? Is "Controller" a single monolithic object or are there many "Controller"s? Where's this queue? Who has access to it? Etc.
Ah- Naughty and I are going down a route of discussion that, honestly, doesn't remotely answer your question- but let me try and break some of it down.
Unreal Tournament 3, or the Unreal Development Kit, is a big 3d game engine that can do lots and lots of wonderful things. It uses a rather traditional OOP hierarchy, where all game objects (not data objects) extend from a base Actor class. Actors are any entity, static or dynamic (walls and monsters), that occupy or interact with the game space, or model. The 'state' of the game is a discrete configuration of the 'model,' which is the aggregation of data that describes the interactions/relationships of entities within the game (ie their current stats, positions, etc). When we talk about a 'game state' we're talking about a measurably distinct change to the model of the game. In a real-time game, like Unreal, the game state updates on every 'tick,' or game-loop. In effect, each 'tick,' or 'frame' is a state.
I wasn't being as specific as I should have been- Unreal uses a Controller-Pawn relationship, whereby both the Controller and Pawn inherit from Actor. The Controller is the decision maker and the Pawn interacts with the model. A Controller represent the player and handles input and the camera, but can also represent an AI that asks the Pawn what the model looks like from its point of view and then makes decisions for it. There is typically one controller per pawn- but for an RTS game, you may use Pawns to represent each unit and a single controller commanding them all. The 'queue' I'm describing isn't necessarily a universal action queue, but relative to how each Pawn.doAction() should be called. Controller.Action() is called on key press, whereas the controller then calls Pawn.doAction() where it is most logically appropriate. This can be as simple as setting a boolean 'performJumpOnNextTick,' so that the velocity of a jump is applied at the beginning of a tick, giving the Pawn an opportunity to manipulate it in some way before the physics engine updates the state, or so that the action can be replicated across a server.
Is this a useful architecture for a Roguelike? Yes. Pretty much every game can be thought of in terms of MVC, regardless of whether you use OOP or a Component system. A component system would hook a controller component into an entity, whereas OOP would represent the controller as an Object. I don't know any reference material off-hand, but the question is-- do you want to make Games or do you want to make Games and learn how to make games? If the former, do what you already know howt to do, otherwise, try something a little uncomfortable.
It also depends on what sort of features you want.
OOP vs DOP and Component Systems
Unreal, a heavily OOP game engine, uses components to unite all Actors in the game that share a property. The most mundane example are Collision Components. If an actor has a collision component, then it will be evaluated by the collision system. Unreal uses an event handler, where it calls something like 'CollisionComponent.Owner.onBump(actor bumpedActor,vector momentum, vector hitLocation)' whenever two collision components are interacting. There are other features built-in to the engine that will take care of displacement and overlapping issues, but that all depends on other values set in each Actor. In this way, Actors are performing all of the logic relative to their implementation, whereas the System isn't really doing anything except evaluating relational components and calling events on the Actors. Unfortunately, this tends to lead to a Monolithic Entity Superclass that has all of the possible events available to be overridden. Regardless, you are invariably using components even if you aren't using a component system- IE, the location of an entity is a logically discrete component of that entity that gets worked on at some point in the game-loop via the engine. Explicitly defining component-system relationships helps keep our logic succinct.
A 'pure' component system (DOP) looks at it from the other way around. Part of the value of using components have to do with meta-features like saving the game state, sending concise network messages, and some other things mentioned previously. This is where the 'database w/UI' idea comes in. Instead of having classes and objects relate to one another, we just have a Database and routines acting upon it in a Finite State Machine of Systems. This makes a lot of things easier- including Procedural Generation of bizarre items and monsters. Maybe a monster is equippable but can't be picked up, and there is a spell or ability that equips something from a distance. So very trivial to implement in DOP, but potentially very quirky in OOP.
The main problem I have with OOP is that you cannot predict all of the features you will want to implement. With DOP, it never matters.
If you're familiar with OOP already, then you should try a hybrid. It depends on what your goals are and what your experience is. I don't know of any good examples off-hand, but pseudo-code is available if you want.
Disregarding your experience/goals, Yea- I recommend a Database with no member methods/functions, with stateless routines acting on said database as an FSM of Systems.
