[Kde-games-devel] Proposal for GSoC

[Arjun Basu]

I changed my project idea, now I am going to port two existing games
KPat and Kigo from QGraphicsView to QML. I have modified my proposal
according to that. If anyone can please 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.

As the developers of Kdegames are trying to analyze how to evolve the
libraries so that it can be ready for QML and almost all the popular
games are already packaged in Kdegames, I would like to port two games
Kigo and Kpat to display the game area on a QML canvas. Also
multiplayer support would be added to Kigo. As kigo is a board game
and Kpat is a card based game, so on the whole the porting of these
two games would provide a nice guide for porting of almost all the
other games present in Kdegames.


PROJECT GOALS:

This project mainly aims at porting the two games Kigo and Kpat from
Qgraphicsview and Kgamerenderer to QML based view. The UI thus created
would be much more feature rich and intuitive than what is achieved
using QGraphicsview and Kgamerender. Importance would be given to
making the game “touch friendly” so that when these games are ported
to mobile or tablet platforms like harmattan and plasma active, the
same interface can be reused to develop the user interface for those
platforms.
Before porting  some of the visual elements will be made as shared
libraries so that other games can use those libraries while writing
their own game interfaces. These libraries would encompass all the
visual elements possible.

As the above will not take the entire GSoC project time, I plan to add
multiplayer support in Kigo. As it is a two player game, there would
be a game room like support where many games might be taking place
simultaneously.


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.
Thus a new game would be able to define an object of this template
class and the default template would be rendered thus enabling the
developer to concentrate on the graphics of the game only.

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. This would be used while porting Kpat .

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.


On the basis of these classes the User Interfaces of the games would
be designed in QML using the existing design in QGraphicsView and
KgameRenderer. The classes would be developed keeping their
extensibility in mind. Once these classes are prepared
the ui of the games would be studied and the design would be
implemented and the design would be implemented using the classes
defined above . The logic of the games Kpat and Kigo would be studied
and integrated with the interface with minor modifications.

After the basic porting is complete , the multiplayer support would be
added to Kigo. As Kigo is a two player game, game room structure would
be provided where multiple games can be hosted simultaneously and
hence a tournament like competition can be hosted if wanted. The code
for basic multiplayer integration can be used from preexisting games
like Kbattleship with some modifications as required. It would also
incorporate a chat support in game rooms( public chat) and within
players in a game (private chat).

TIMELINE:

Until May1: Read through the codebase of Kdegames , fix bugs and get a
general idea of how things work. Get familiar with the source of Kpat
and Kigo and some other games to get a feel of how things work in a
typical game like the integration of game interface with the gameplay
logic. Read through the network integration code of existing
multiplayer games like Kbattleship.


May 2 to May 8 : Prepare a basic plan for the implementation and
working of the aforementioned classes. Learn the additional QML
features required to prototype these classes.


May 9 to May 16: Start coding the classes. The classes would be
developed according to their priority in the game e.g. First the
template class would be developed, then the SVG support etc.

May 17 to May 23: Test the functionality of each class by writing
sample code. Also debug the classes wherever required. By the end of
this period the classes would be fully working and ready.

May 24 to June 6: Thoroughly read the code base of Kpat. Understand
the complete working of Kpat including the functioning of the user
interface, the working of the game logic and the game solving logic
patsolve.

June 7 to June 13: Start designing the User Interface for Kpat using
the classes defined earlier. Complete the design of Kpat within this
period.

June 14 to June 20: Start coding the user interface of Kpat. The user
interface of Kpat would be complete and working by this period.

June 21 to June 27: Integrate the game play logic with the user
interface. Extensive testing and debugging would be carried out during
this period.

June 28 to July 3: Throughly read through the code base of Kigo.
Understand all the working principles of the code as well as the
integration of logic with interface.

July 4 to July 10: Design and code the User Interface of Kigo.
Complete the user interface of Kigo within this period.

July 11 to July 17: Integrate the logic with the user interface.
Testing and debugging would also be carried during this period.

July 18 to July 24: Add the network play support in Kigo. The
implementation of game room, public and in game chat would also be
carried out.

July 25 to July 31: Extensive testing and debugging of the network code.


August 1 to August 14: Two weeks backup for any unforeseen delays and
modifications in the project.



August 15 to August 20: Improve documentation of written code and also
improve code quality.

August 20: Pencils down date.

After GSOC : The code would be sent out and reviewed by the community.
The games would be continously monitored for any bugs or feature
requests. Efforts would be made for porting of other games and for the
overall improvement of Kdegames.



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 in general and Kpat and
Kigo in particular . 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.

On 3/26/12, Arjun Basu <arjunkbasu at gmail.com> wrote:
> After I an's review , I decided to port two existing games Kigo and KPat to
> QML from QGraphicsView. Is this acceptable?
>
> On Mon, Mar 26, 2012 at 3:24 PM, Frederik Schwarzer
> <schwarzer at kde.org>wrote:
>
>> Am Montag, 26. März 2012, 04:24:57 schrieb Ian Wadham:
>> > On 26/03/2012, at 4:39 AM, Wolfgang Rohdewald wrote:
>> > > Am Sonntag, 25. März 2012, 03:58:32 schrieb Arjun Basu:
>> > >> My Project mainly aims at developing the board game “Monopoly”
>> > >> using QML
>> > >>
>> > >>   /Qt Quick
>> > >
>> > > can you re-use parts of atlantik?
>> >
>> > You should tread very carefully here, Arjun.
>> >
>> > Firstly, the original author of Atlantik spent years working on it
>> > and never really finished. It was eventually dropped from KDE
>> > Games because nobody was able/willing/had-time to convert it to
>> > KDE 4 from KDE 3 and the original author, Rob Kaper, had long
>> > since departed from KDE Games.
>>
>> This raises a general question. A few years ago the KDEGames team
>> decided not to accept new games as GSoC projects anymore because they
>> tend to end up deserted quickly after the project ended.
>>
>> So, is this year's project about a new game or about the conversion of
>> an existing game to QML? Would we accept either? I mean, regardless of
>> who would be mentoring it?
>>
>> Regards
>> _______________________________________________
>> kde-games-devel mailing list
>> kde-games-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-games-devel
>>
>
>
>
> --
> Arjun Basu
> 3rd Year
> Electronics & Communication Engineering
> National Institute of Technology
> Durgapur , India
>


-- 
Arjun Basu
3rd Year
Electronics & Communication Engineering
National Institute of Technology
Durgapur , India