MemoryGameObjects

From OLPC
Revision as of 18:45, 6 January 2007 by Xavi (talk | contribs) (categorization)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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:

  1. Server sends the "it's your turn" message to client
  2. Clicks tile1, GTK+ button fires event to View
  3. View sends tile1 click event to Controller
  4. Controller tells Model to flip tile1
  5. Model sets tile1 to flipped and emits signal
  6. Controller sends tile1-flipped message over network to server
  7. View receives tile1-flipped signal and plays sound/shows picture
  8. repeat a - f for tile2
  9. If tile1 and tile2 match, server sends player a 'success' message
  10. Controller receives success message from server
  11. Controller tells Model to update points for local player
  12. Model emits points change signal for local player
  13. View receives points change and updates GUI

Remote user flips tile4:

  1. Controller receives tile4 flipped message from server
  2. Controller tells Model to flip tile4
  3. Model sets tile4 to flipped
  4. Model emits tile4-flipped signal
  5. View receives tile4-flipped signal and plays sound/shows picture
  6. repeat a - e for tile6
  7. Controller receives a success message from server
  8. 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.