MemoryGameObjects: Difference between revisions
DanWilliams (talk | contribs) (initial dump) |
m (categorization) |
||
(One intermediate revision by one other user not shown) | |||
Line 23: | Line 23: | ||
In practice, it's usually cumbersome to have a very hard, distinct split between the view and the controller for many apps. In our case, we probably want to have a hybrid view/controller since all the game logic actually lives in the server, not with the clients. |
In practice, it's usually cumbersome to have a very hard, distinct split between the view and the controller for many apps. In our case, we probably want to have a hybrid view/controller since all the game logic actually lives in the server, not with the clients. |
||
= |
=Possible flow for Game Operations= |
||
Local user's turn: |
Local user's turn: |
||
Line 53: | Line 53: | ||
The game should have separate server and client objects to keep the object model clean and simplify the client code. The only difference between a participant and the game master should be that the game master has an additional server object which provides game coordination and files over the network. A client which is also the game master should still participate in the game over TCP/IP, only to localhost and not to the network. |
The game should have separate server and client objects to keep the object model clean and simplify the client code. The only difference between a participant and the game master should be that the game master has an additional server object which provides game coordination and files over the network. A client which is also the game master should still participate in the game over TCP/IP, only to localhost and not to the network. |
||
[[Category:Software development]] |
Latest revision as of 18:45, 6 January 2007
Use a loose interpretation of Model/View/Controller.
Object Model
Model:
- Stores tile array
- Stores pictures and sounds and what tiles they correspond to
- Stores tile states (flipped/not flipped)
- Stores player objects and associated information (scores, which tiles they won, etc)
- Stores game state (who's turn it is)
View:
- Displays model information (tile states, pictures, players) and displays it onscreen
- Responds to changes in the model information (tile state changes, new players, dropped players)
- Sends local user input to Controller
Controller:
- Receives local user input from View
- Updates the model based on local user input
- Sends local model state changes to game server
- Receives game state updates from the server, updates model from them
In practice, it's usually cumbersome to have a very hard, distinct split between the view and the controller for many apps. In our case, we probably want to have a hybrid view/controller since all the game logic actually lives in the server, not with the clients.
Possible flow for Game Operations
Local user's turn:
- Server sends the "it's your turn" message to client
- Clicks tile1, GTK+ button fires event to View
- View sends tile1 click event to Controller
- Controller tells Model to flip tile1
- Model sets tile1 to flipped and emits signal
- Controller sends tile1-flipped message over network to server
- View receives tile1-flipped signal and plays sound/shows picture
- repeat a - f for tile2
- If tile1 and tile2 match, server sends player a 'success' message
- Controller receives success message from server
- Controller tells Model to update points for local player
- Model emits points change signal for local player
- View receives points change and updates GUI
Remote user flips tile4:
- Controller receives tile4 flipped message from server
- Controller tells Model to flip tile4
- Model sets tile4 to flipped
- Model emits tile4-flipped signal
- View receives tile4-flipped signal and plays sound/shows picture
- repeat a - e for tile6
- Controller receives a success message from server
- Controller tells Model to update points for player
Server
The game should have separate server and client objects to keep the object model clean and simplify the client code. The only difference between a participant and the game master should be that the game master has an additional server object which provides game coordination and files over the network. A client which is also the game master should still participate in the game over TCP/IP, only to localhost and not to the network.