Miniature/Development/Architecture

(New page: == GUI == * Board * Chat * Player Cards * Online Play == Logic == * Game - the logic for a particular game, right now that would be just chess, but other board games could be possible too...)
m (remove custom category)
 
(15 intermediate revisions not shown)
Line 1: Line 1:
 +
[[Category:Miniature]]
 +
{{out of date}}
 +
== GUI ==
== GUI ==
* Board
* Board
Line 13: Line 16:
* Board - Represents the data structure of the board (duh)
* Board - Represents the data structure of the board (duh)
** Can draw a position based on a valid FEN string, say "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1" encodes the start position.
** Can draw a position based on a valid FEN string, say "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1" encodes the start position.
-
** How it works: Each figure is a QGraphicsSvgItem. This is useful since it allows fingertouchability. The board draws its position, meaning it removes all its figures children (by deletion) and then re-reads the SVG files into new QGraphicsSvgItem. Needless to say, this is inefficient. A better way would be to let the board load all figures during its construction time, put them in a vector (using enums for the indices lookup, maybe) and instead of clearing the board by deletion, just unparent the figures from the board, then reparent them into the correct position. Or just move them around, and hide those that were removed by game moves. Both should be easy and bring a good speed-up (SVG loading is quite expensive I hear). It is bascially about killing unneeded new/delete sequences.
+
** How it works: Each piece is a QGraphicsSvgItem. This is useful since it allows fingertouchability. The board draws its position, meaning it hides all its piece children. It then asks the pieces pool manager for new pieces (the pool manager of course caches the QGraphicsSvgItems). The pieces are moved to the correct board position, and are made visible (again).
* Player - information about the other player, like online status, skill level
* Player - information about the other player, like online status, skill level
-
** Player "cards" would be part of this. Currently, they only exist as some HTML-formatted text in the scene view.
+
** Player "cards" would be part of this. The player info section on top of the board is fully editable with the Qt Designer, and we could need a good clock ...
== Communication ==
== Communication ==
Line 22: Line 25:
* Telepathy
* Telepathy
* Computer Chess Engine - an offline engine should be accessed the same way any online game is, the engine does not have to be in the same task
* Computer Chess Engine - an offline engine should be accessed the same way any online game is, the engine does not have to be in the same task
 +
 +
== Big Blocks Diagram ==
 +
[[Image:Miniature_modules.png]]
 +
 +
1. MPosition  is the centre block, represents a position on the board. Could be encoded as a FEN string  or as a 8x8 array with pieces enum'ed or as something else.
 +
 +
2. MBoardView displays position and handles user interaction related to moving pieces. This is the only purpose of it.
 +
 +
3. MLocalLogic analyses new position with respect to validity of a move at the very least, communicates the position to other party. May communicate with external engine either locally or remote.
 +
 +
4. MRemoteLogic - feeds the position directly to the MBoardView from other party. We may want to add feature like game feed later to this block too.
 +
 +
5. MInfo is an information dialog, "Illegal move", "Draw proposed", "You Win" etc.  Could include timer, although I am not sure.
 +
 +
6. MExtra and MExtraView - everything else not directly related to a chess - chat, ratings, pictures etc.
 +
 +
 +
 +
The game flow could  look like this:
 +
 +
- current position goes to the MBoardView
 +
 +
- player makes a move 
 +
 +
- MBoardView sends the new position to MLocalLogic
 +
 +
- MLocalLogic analyses validity of the move
 +
 +
- if the move is valid, the position to be sent to the other party ( eventually to its MRemoteLogic )
 +
 +
- If the move is not valid, the previous position is sent back to MBoardView, "Illegal move" dialog is displayed
 +
 +
 +
 +
* Arrows at the left side depict connection to an "outside", whatever "outside" can be. Details about connections, "outside" etc will be defined later. Examples - another player, chess server, adapter to a local chess engine. 
 +
 +
--[[User:boris_r|boris_r]] 00:57, 15 November 2009 (UTC)
 +
 +
== Current design in master branch ==
 +
The diagram shows classes and their associations. Furthermore, it shows signals and slots. The naming conventions should make clear which slot responds to which signal during runtime. The remaining public API has been left out, because it's all in a flux right now.
 +
[[Image:MiniatureArchClassDiagram.png|thumb]]

Latest revision as of 13:29, 14 June 2010

Image:Ambox_content.png
 This article is out-of-date, and needs to be updated.
Please see the talk page for discussion.

Contents

[edit] GUI

  • Board
  • Chat
  • Player Cards
  • Online Play

[edit] Logic

  • Game - the logic for a particular game, right now that would be just chess, but other board games could be possible too. (Chess based or other)
    • The current game controller can update the board, using FEN strings (we might want to wrap the QStrings in a simple Position container, if we add parsing API to it) and knows about the UI.
  • Pre-Game - How to find players, select a server or engine

[edit] Domain

  • Board - Represents the data structure of the board (duh)
    • Can draw a position based on a valid FEN string, say "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1" encodes the start position.
    • How it works: Each piece is a QGraphicsSvgItem. This is useful since it allows fingertouchability. The board draws its position, meaning it hides all its piece children. It then asks the pieces pool manager for new pieces (the pool manager of course caches the QGraphicsSvgItems). The pieces are moved to the correct board position, and are made visible (again).
  • Player - information about the other player, like online status, skill level
    • Player "cards" would be part of this. The player info section on top of the board is fully editable with the Qt Designer, and we could need a good clock ...

[edit] Communication

  • ICS
  • Bluetooth
  • Telepathy
  • Computer Chess Engine - an offline engine should be accessed the same way any online game is, the engine does not have to be in the same task

[edit] Big Blocks Diagram

Image:Miniature_modules.png

1. MPosition is the centre block, represents a position on the board. Could be encoded as a FEN string or as a 8x8 array with pieces enum'ed or as something else.

2. MBoardView displays position and handles user interaction related to moving pieces. This is the only purpose of it.

3. MLocalLogic analyses new position with respect to validity of a move at the very least, communicates the position to other party. May communicate with external engine either locally or remote.

4. MRemoteLogic - feeds the position directly to the MBoardView from other party. We may want to add feature like game feed later to this block too.

5. MInfo is an information dialog, "Illegal move", "Draw proposed", "You Win" etc. Could include timer, although I am not sure.

6. MExtra and MExtraView - everything else not directly related to a chess - chat, ratings, pictures etc.


The game flow could look like this:

- current position goes to the MBoardView

- player makes a move

- MBoardView sends the new position to MLocalLogic

- MLocalLogic analyses validity of the move

- if the move is valid, the position to be sent to the other party ( eventually to its MRemoteLogic )

- If the move is not valid, the previous position is sent back to MBoardView, "Illegal move" dialog is displayed


  • Arrows at the left side depict connection to an "outside", whatever "outside" can be. Details about connections, "outside" etc will be defined later. Examples - another player, chess server, adapter to a local chess engine.

--boris_r 00:57, 15 November 2009 (UTC)

[edit] Current design in master branch

The diagram shows classes and their associations. Furthermore, it shows signals and slots. The naming conventions should make clear which slot responds to which signal during runtime. The remaining public API has been left out, because it's all in a flux right now.

Retrieved from "http://bugs.maemo.org/Miniature/Development/Architecture"