[Kde-games-devel] Proposal for GSoC

Sat Mar 24 22:28:32 UTC 2012

This is the first draft of the proposal for the project "Write a game using
QML/Qt Quick" . It would be great if someone could review it.
Write a KDE game using QML ("Qt Quick")

 INTRODUCTION:

 Kdegames as we know has packaged some great games which are both fun as
well as challenging to play. Initially most games are written using
KgameCanvas due to the lack of good support of QGraphicsView and its lack
of support of SVG graphics. Due to significant improvement in QgraphicsView
, Kdegames is moving on to QgraphicsView and KgameRenderer, the unified
rendering solution for SVG files. Some of the games like KillBots have
already been ported and the rest are in the process .

 Now the next big thing in the world of UI design is QML/Qt Quick which
allows the developers to design fluid and intuitive interfaces with very
less effort. Kdegames is focusing on these new technologies in order to
make the game playing experience to be as good as possible. On using QML as
the display canvas, the existing games can be made more intuitive and fun
to play. Games written in QML have the inherent advantage of being 'touch
friendly' which allows the game to run smoothly in mobile and tablet
platforms like Harmattan and Plasma Active respectively where touch is the
only input option available. Writing a new game in QML/Qt Quick will allow
the developers of Kdegames to have an idea regarding how to evolve the
libraries so that in future games can be written/ ported to QML very
easily.

 PROJECT GOALS:

   -

   My Project mainly aims at developing the board game “Monopoly” using QML
   /Qt Quick. It is a 2-8 player game which has very simple rules yet involves
   some cunning strategical elements which makes it a lot of fun to play. The
   game would not only include single player but also multiplayer features
   playable over the internet or the local network., including in-game chat
   support for the players.
   -

   I wish to develop the entire game using QML. I plan to write new QML
   based classes encompassing all the visual elements of the game which would
   enable the future development or porting of games to QML very simple. These
   classes can be later integrated into libkdegames.
   -

   As the above will not take the entire GSoC project time, I plan to port
   an existing game in Kdegames “Kiriki” to QML using the classes I define,
   which would give a good idea regarding the porting procedures and also help
   others in the same regard.

 IMPLEMENTATION DETAILS:

 I plan to start off my project by writing custom extensible classes in QML
which would take care of all the display elements. Some classes which I
have thought of

   1.

   *A Default Template Class: *This would define an resizable empty QML
   canvas with a toolbar containing some default buttons like new game etc.
   And a menu bar with options of game, help, configuring options and other
   things. Other options can be added to the toolbar and menu bar fairly
   easily. This class would allow a developer to rapidly create a default game
   look with some elements and get started on the drawing of the game canvas
   and the logic. It would have an empty QML canvas on which the entire
   graphics of the game would be rendered.

   2.

   *SVG loading Support: *As several of the current games use SVG graphics
   , most notably the card games , use the predefined card icons from
   libkdegames. The QML Image Element can be used to render SVG Graphics
   fairly easily.
   3.

   *Class for custom score dialogs*: This class would create dialogs which
   would allow a game to define its custom high score or general score dialog
   with some standardized fields like Name, Date, Score, Ranking etc. A
   provision of defining custom fields would also be present which would allow
   the games to define their game specific fields and fill them with data.
   Users would also get the option of resetting the high scores as well as to
   forget the current high score.
   4.

   *A custom card loading class*: This class would standardize the loading
   of card icons in various card games. It would define a basic framework
   where the number of cards and the cards if specified would be loaded on the
   game canvas with a simple constructor call. Animations for card
   distribution, round wins and plays would also be available.
   5.

   *A Chat Widget Class*: This would be a default chat widget class that
   would take care of the chat options in the multi player version of the
   games where it is available. It would comprise of the basic chat layout
   with the integration with network code integrated in each particular game.
   6.

   *Theme Loading Class: *A basic class would be available through which
   themes would be available to all games without any extra code. There would
   be couple of themes available including an empty template which would allow
   the creation of new themes fairly easily.

 I have included the classes which I felt are required for the basic
graphics rendering of a game. In course of the project, if further classes
are required they would be added too. These classes would lay the
groundwork for the game I plan on writing. The classes would be generalized
such that they can be used by any and every type of game to take care of
its graphic requirements.

 The graphics of Monopoly aren't very complicated , it would feature a
regular board with the player moving along the boundary of the board. Some
effects are to be added like moving the pieces and placing of properties on
the board. The logic of the game can be easily developed as there are some
basic algorithms available upon which I can work, improve and finally
incorporate in the game. The multiplayer version of the game would be
playable by 2-8 players. The code for the network integration can be easily
seen in current multiplayer games like Kbattleship and I can port the code
as per my requirement. The multiplayer would also comprise of a chat widget
for in game chat.

 One another thing that has to be kept in mind that it should be touch
friendly. The entire design should be such that this game and future games
written in QML can be easily ported to mobile platforms like Harmattan and
tablet platforms like Plasma Active. Although it would need writing the UI
code from scratch but at least the interface design would be available for
easy porting.

 TIMELINE:

   -

   *Till May 1*: Read through the codebase of libkdegames and some of the
   board games in order to get a feel of how things work in a typical game
   like the integration of game logic with the user interface, the AI logic.
   Get familiar with the network code from multiplayer games like Kbattleship.

    -

   *May 2 to May 8*: Prepare a basic idea for the implementation and
   working of the aforementioned classes. Learn the additional QML features
   required to prototype those classses

   -

   *May 9 to May 16*: Start coding the classes. The classes would be
   developed in order of their importance and relevance to this game “Kpoly”
   e.g. First the template class would be written then SVG support, chat
   widget etc.

   -

   *May 17 to May 23*: Test the functioning of each class by writing sample
   code. Debugging of the classes would also be done. By the end of this
   period the classes would be fully working and ready.

   -

   *May 24 to May 27*: Design the Basic User Interface of “Kpoly”. All the
   visual aspects of the game would be covered during this period like the
   position of the board, the icons , the effects to be included etc. The
   interface for both Single Player and Multiplayer would be developed. The
   “Touch Friendly”aspect would be kept in mind while designing the interface.

   -

   *May 28 to June 3*: Start coding the interface and complete the entire
   interface within this time frame.

   -

   *June 4 to June 15:* Develop the Logic for the game play for single
   player. The multiplayer network integration algorithms would also be
   covered during this period.

   -

   *June 16 to June 22*: Write the code for the gameplay logic for Single
   Player. The network code for multiplayer would be added too.

   -

   *June 23 to June 30*: Integrate the game play logic, multiplayer support
   with the user interface. Extensive testing and debugging would also be
   carried out.

   -

   *July 1 to July 6*: Read through the code of Kiriki and understand the
   game play logic and the implementation of its interface.

   -

   *July 7 to July 9*: Prepare the design of the user interface of Kiriki
   using the created QML classes.

   -

   *July 10 to July 16*: Code the User Interface of Kiriki

   -

   *July 17 to July 28*: Integrate the gameplay logic of Kiriki with the
   user interface created along with some slight modifications. Carry out
   testing and debugging of the code.

   -

   *July 29 to August 11*: Two weeks backup for any unforeseen delays and
   modifications in the project.

   -

   *August 12 to August 20*: Improve documentation of written code, improve
   code quality

   -

   *August 20*:Pencils Down Date

 ABOUT ME:

 I am Arjun Basu, an undergraduate student of Electronics and Communication
Engineering. I am from Kolkata, India. I am a Linux and FOSS enthusiast. I
am part of GNU/Linux Users' Group of our college and also part of Nitdgplug
and have been in contact with some very popular personalities in Open
Source in India like Debayan Bannerjee, Kushal Das, Rahul Sundaram,
Shreyank Gupta, Sankarshan Mukherjee who have helped me a lot and also
enhanced my interest in FOSS contribution. I spend most of my free time
coding. I have been using KDE since 2009. I have contributed some patches
to Kiriki and Kdegames.

 I have gone through the codebase of KDEgames and Kiriki . I have fiddled
with the code to get a feel of how things work. I have good knowledge of
Qt/C++ and QML. I have used QML/Qt Quick before and hence very familiar
with the concepts.

 I am very dedicated to what I do. I will put all my time and energy to
give more than 40 hours a week into this job and complete my project in
time. I have kept some backup time to avoid any unwanted situations. I
would continue to work on Kdegames even after GSOC is over , give effort to
remove any kind of glitches or bugs in the code and in general work for the
betterment of Kdegames.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-games-devel/attachments/20120325/08516ecd/attachment-0001.html>