GSoC 2013 started!

GSoC 2013 has started and it's time to start really planning work for 3 next months and get in touch with KDE community and documentation.

I am willing to port KReversi game to QML. Below I provide implementation details and tentative time line.


Implementation Details:

First part of the work will be porting of QGraphicsView related part to QML without any changes to actual game-play or interface. I will use mentioned here classes for interaction with theme files (sprite loading). There will be at least 6 main QML items:

0) Global definitions file: used to declare row, column counts, animation speeds and other global constants

1) Chip: it represents reversi chip, can be empty, black or white, incorporates corresponding sprite animation for state change.

2) Cell: it represents single cell of the board. Consists of chip, providing functions for changing and getting its state, have special hint and legal toggles to show hints and legal positions.

3) Board: it represents board, consisting of cell array, providing functions to operate with cells (hint, legal, chip state get/set), also can toggle labels showing on board.

4) Popup: item that is used for showing popup messages.

5) Table: it consists of background image, board, and popup.

Now game-flow is partly controlled by MainWindow and KReversiScene classes. MainWindow can change difficulty and KReversiScene check with KReversiGame move possibility and calls next_turn, after player moves. So it is essential to move all that logic to new KReversiView(QML) class.

The second part concludes in overall design change of the game. I think it will be good to abstract KReversiGame from player nature by providing some kind of abstract player-interface, which will be used for human-player and computer-player classes. This approach will make possible easy implementation of player-to-player, player-to-computer, computer-to-computer (or demomode) without obstructing code with if (demomode) {…} statements. Also it will make possible to choose color for your chips (whether you do first or second move in game), and maybe somebody else will introduce network game-mode by implementing network-player class, using player-interface.

If I have a freetime I will introduce some new animations to game by editing QML files.

Tentative Timeline:

May 28 – June 2: reading code, documentation, contacting with developers, setting up development environment

June 3 – 9: reading code, documentation, discussing details with mentor, understanding KgDeclarativeView, KgCore.KgItem and other QML related KDE components, select classes that will be completely deleted or rewrited to use QML

June 10 – 16: writing simple set of QML classes representing game-objects: Table, Board, Cell, Chip, Popup, debugging with qmlviewer, handling user-interaction (it is limited to click event)

June 17 – 23: getting rid of QGraphicsView/Canvas classes, writing of simple game view, which loading main QML file and can register user-interaction events

June 24 – 30: implementing game-flow structure, which is now partly incorporated to KReversiScene (handling of move possibility, turn change, etc.)

July 1 – 7: implementing special features like chip-color change (mono or colored), hints, last move showing

July 8 – 14: fixing bugs, testing of “one-to-one” QML port, checking window resizing, closing during game animations, game-play testing, checking animation smoothness, etc.

July 15 – 21: fixing bugs, testing, and documentation writing, checking state of preexisting bugs from bugtracker

July 22 – 28: polishing resulting code, at the end of this week QML port should be fully documented and functioning, start discussing of part two implementation

July 29 – August 4: implementing player interface, and using it to make human-player class, implementing computer-player class

August 5 – 11: moving all game-flow control from MainWindow and KReversiView classes to KReversiGame, connecting it with player interfaces through signals

August 12 – 18: creating new start game window, allowing to select difficulty before game start, and select game-mode.

August 19 – 25: fixing bugs, especially testing game-play in all game-modes (including demo-mode)

August 26 – September 1: If have time: implementing animation for chip placing, maybe hints and legal positions showing, if not: continue testing and debugging of new code design

September 2 – 8: fixing bugs, writing documentation, testing, polishing

September 9 – 15: fixing bugs, writing documentation, testing, polishing