So I've been pondering way too much about how to separating logic from presentation. The reason I want to find a good way of doing this is not so I can reuse logic code, but rather for easier managing my code. So the parts I got are roughly the MVC pattern, I'll give an example of an entity, such as a player: Model - Contains the state of the entity and interfaces for altering the state - jump(), fire() etc. It also incorporates a tick() for proceeding with the current state each logic update. Controller - Decides what happens. The player Model could for example have a PlayerController that translates keyboard input to corresponding actions. Whether these actions are possible are decided by the model, not the controller. This way I can map different type of controllers to the same type of model without reimplementing the behavior rules of the entity. Presentation - Reads the Model and presents it through graphics and sound. Some things that are not part of the game logic - backgrounds and decorations etc - might even only exist as presentations. So that seemed like a good design I thought, until I realized that these presentations can only react to current states - not events. For example, what if I want to make a sound when somebody removes a line from my Tetris board? The presentation could see that a line has been removed, but what caused it? It could probably deduce some things by comparing previous and next state, but that would lead to duplicate work in model and presentation. Any suggestions? I feel I might just be best off just mixing the models and presentations together again. :)

that's not really a design. more like a pattern. actually more like the model-view pattern to be specific. your presentation reads the model based on a timer event more than likely and should be event based. the model can always post an event that triggers a sound by the presentation.

Quote:Original post by Kanzetsu
So that seemed like a good design I thought, until I realized that these presentations can only react to current states - not events. For example, what if I want to make a sound when somebody removes a line from my Tetris board? The presentation could see that a line has been removed, but what caused it? It could probably deduce some things by comparing previous and next state, but that would lead to duplicate work in model and presentation.

Presentations can react to events just fine -- I'm not sure what the problem is here, exactly. If this were my game, the action sequence would be roughly as follows:

1.) Somewhere in initialization, the presentation object subscribes to the model object's LineRemoved event.
2.) At some future point, a line is removed -- perhaps the player reached 10,000 points and that's a bonus effect; or perhaps they completed the row.
3.) The model fires the LineRemoved event. If additional information is required, this should be passed in as parameters as per the advertised interface. For instance, .NET's event model uses two parameters -- the object that generated the event, and specialized event arguments depending on the type of event. For instance, a MouseDown event supplies MouseEventArgs, which contain which mouse button was pressed and the current position of the mouse relative to the parent control.
4.) The presentation is notified that the event was fired. It makes the appropriate logic decisions about what to do -- play a sound, erase the line, and so on. (However, pure state changes like increasing the player's score should be handled by the model.)

Quote:Original post by Kanzetsu
...So that seemed like a good design I thought, until I realized that these presentations can only react to current states - not events. For example, what if I want to make a sound when somebody removes a line from my Tetris board? The presentation could see that a line has been removed, but what caused it? It could probably deduce some things by comparing previous and next state, but that would lead to duplicate work in model and presentation...

Why can't the removal of a line be part of the state? In the simplest case you would have a boolean called aLineWasRemovedThisFrame as part of the state. The presentation would play a sound when the value is true.

Quote:Original post by anist
that's not really a design. more like a pattern. actually more like the model-view pattern to be specific. your presentation reads the model based on a timer event more than likely and should be event based. the model can always post an event that triggers a sound by the presentation.

Yeah, I guess I'm trying to figure out a suitable variation on the MVC pattern here.

Original post by kSquared

Quote:Presentations can react to events just fine -- I'm not sure what the problem is here, exactly. If this were my game, the action sequence would be roughly as follows:

1.) Somewhere in initialization, the presentation object subscribes to the model object's LineRemoved event.
2.) At some future point, a line is removed -- perhaps the player reached 10,000 points and that's a bonus effect; or perhaps they completed the row.
3.) The model fires the LineRemoved event. If additional information is required, this should be passed in as parameters as per the advertised interface. For instance, .NET's event model uses two parameters -- the object that generated the event, and specialized event arguments depending on the type of event. For instance, a MouseDown event supplies MouseEventArgs, which contain which mouse button was pressed and the current position of the mouse relative to the parent control.
4.) The presentation is notified that the event was fired. It makes the appropriate logic decisions about what to do -- play a sound, erase the line, and so on. (However, pure state changes like increasing the player's score should be handled by the model.)

Hmm, yes, maybe it doesn't have to be harder than that. The problem I foresaw with this what the presentation would having to try to figure out what caused the event, but maybe it's not really harder than just supplying the cause or involved entities as an argument in the event handling methods.