Porting of KDE games from deprecated libraries

There has been a lot of discussion in the Kdegames mailing list regarding the porting of the games from deprecated libraries like KGameRenderer and KGameTheme to new rendering methods and Graphics stack. This is a very good opportunity for new contributors to start contributing to Kdegames. Although some of the ports might be a bit difficult but there are easy ones too once the code of a game specially the rendering portion of the code is understood. The port table is available here http://community.kde.org/KDE_Games/Porting. A basic understanding of Qt/C++ would be required, but the junior jobs should get one up to speed for tackling the ports.

For people who want to start contributing to Kdegames , it is advisable to go through the following steps in order

1. Subscribe to the Kde-games-devel mailing list (https://mail.kde.org/mailman/listinfo/kde-games-devel) . For those who do not know what it is, a mailing list is basically a kind of a forum where people post their queries or doubts or submit their patches. When they do that, all the people who are subscribed to this mailing list get notified by mail so that they can entertain their queries or the maintainers of the games can review the submitted patches.

2. Try to hang out in the official IRC channel (#kde-games on freenode) . You can have direct conversations with people from Kdegames here.

3. Post your willingness to contribute in the mailing list. It is more recommended than posting in the irc channel .One thing that has to be followed after posting in the mailing list is patience. People are busy and are from a lot of different time zones. They reply according to their convenience which has to be respected.

After following these steps , you should get a junior job which would surely help you get familiar with the source and in general to contribution if its your first time contributing.

Kdegames is a small group of developers and contributors and despite that they have done an awesome job. Although I haven’t been in Kdegames for very long but I really like this group and I would definitely want more people contributing to Kdegames which would help it become even better than it already is.


TicTacToe: A Qt quick approach to the classic game

Finally something interesting on (mostly) Boring Talk :P. In this blog post I am going to write about a new application that I developed. Its TicTacToe, the classic board game of Xs and Os , one that doesn’t involve a lot of strategy or time but is fun to play nonetheless. I developed it using Qt Quick which is basically QML integrated with Qt code.¬† The reason why I chose TicTacToe was simple. Although I know Qt Quick, I haven’t done any serious app development using it , so I was looking for something which would be simple to develop but would involve some complex interactions among the User Interface and the code

TicTacToe allows one to play TicTacToe with the computer where the decision of who moves first is made randomly. Its so because I feel like the player going first has a distinct advantage.. TicTacToe has an undo feature where the user can undo his/her last move and hence the corresponding CPU move is reverted as well. One thing I would admit is that it is a little difficult to beat the CPU at present ūüėČ

Some screenshots of the game:

Default Game Canvas

CPU winning

Human Winning!

Help Image

If someone wants to check it out , its available at http://sourceforge.net/projects/qtquickxo .

Now, I am moving on to how I developed TicTacToe and how it works , in brief (Non Geeks are forewarned)

As we all know designing UIs using QML is a piece of cake. Using QML fluid and intuitive UIs can be developed with very less effort. It didn’t take me long to design the basic interface of the game. But once it was done, I was faced with the task of writing the game logic i.e. how the game would react to the user interactions. I decided to write an AI class which would handle all the tasks of calculating which position to mark on the board. It models the board using a 3×3 matrix denoting vacant positions by -1, computer played positions by 0 and human played positions by 1. It has several methods at its disposal which helps it to calculate an optimum return move. Initially I thought of going through some generic algorithms for TicTacToe and implement them in my AI class methods but as it was only a 3×3 board , and as I was focusing on the human computer interactions, I decided to go with the brute force approach. The AI logic primarily goes through the following steps in order to calculate the optimum move.

1. It checks whether it can win in the current move.

2. If not , it checks whether the other player can win in his next move, if so it blocks the move

3. If none of the above are found then it checks whether the other player is trying to create a ‘fork’ i.e. whether the player is creating such a position on the board, where he can win by using two possible moves, thereby ensuring he will win the round.

4. If none of the above are true, the computer picks an empty place on the board and moves there.

The above conditions are checked using simple pattern matching between sets of three positions.

After writing the class, I tested it out by writing some sample code where I could test whether the AI logic is working using console input output.

When the class was finally ready , I set out to integrate the Qt code with QML (Qt Quick in essence). I integrated some JavaScript functions with the QML code to handle the various events that occurred on the canvas. There are events on setting  a particular position to X or O as per the play, code to decide when the board is full and hence the game is a draw, calling the AI class methods etc.  Integrating both the parts , finally TicTacToe was ready.

It took me aruond four days which included classes, interruptions from friends and delays due to the unstable internet connection at my hostel. Considering the above , I think, my first Qt Quick app got written in pretty good time :).

There are still some things missing in TicTacToe. The first and foremost thing is lack of proper documentation. I plan to add it very soon. I would also like to add a clock which would show how long the current round has been going on.

I have plans to add a LAN multiplayer feature too but thats for later on.

That’s all for today (rather tonight ) folks

Applying for GSoC, a tough road

This year I am going to apply for Google Summer of Code popularly known as GSoC. For those who do not know what it is, GSoC is an internship program from Google where Google pays you a hefty amount to hack FOSS softwares. Can’t get any better than this right ? But this program being so lucrative attracts a lot of competition and although there are a lot of organizations who are accepted for GSoC , the number of students is large too.

There are various stages of GSoC. First the organizations which want to participate in GSoC have to apply with their ideas. Google then publishes a list of accepted organizations and students can apply for GSoC for the accepted organizations only. After the GSoC student application period is over, all the mentors in a particular organization vote the proposals for their organization and send it to Google. On the basis of this vote Google selects the students who are going to be part of GSoC .

My interest in contribution has always been in KDE and I am applying for GSoC for a project idea in Kdegames. The idea is “Write a Kde game using QML/Qt Quick” . I am ¬†basically going to port two existing games present in Kdegames. One is KPat, which is basically a Patience like game including a lot of variants and the other is Kigo, the Go game. These games currently use the QGraphicsView/ KGameRenderer to render their graphics and in my project I am going to design a QML based interface for both of these games and integrate the existing game play logic with these new interfaces. Using QML , the interface can be designed fluid and intuitive so that the game play experience of the user is taken to a whole new level altogether. On talking with some of the people in Kdegames like Stefan Majewsky, I came to know that there are plans of porting Kdegames to the tablet platform Plasma Active, and the interfaces designed in QML would also help when these games would be ported. Although the interface would have to be written from scratch but the design would be available without any major changes.

After the interface designing is over, I am also planning to write a multi player module for Kigo. Go is a very popular game in many parts of the world and the IGF (International Go Federation) has over 70 member countries. There are Internet Go Servers (IGS) where people can connect using their clients and play against other players. They also have the option of watching other games in real time. The multiplayer module would enable a player to connect to any go server using his/her credentials and play. There are some such clients available like Cgoban and Jago but they are primarily designed for Gnugo. But the good thing is there are some standardized protocols for Go like Go Text Protocol (GTP) and Go Modem Protocol (GMP). These protocols are meant to standardize the Go games so that it can be played from any system against any system without any problems of compatibility. Jago is an open sourced Go client written in Java and I am going to study its code for porting it to Qt/C++ in Kigo.

I have already submitted my proposal and it is available at http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/arjbasu/1 . It would be viewable after the GSoC student application period is over i.e. fromApril 6th 2012.

Fingers crossed and waiting for the fateful day April 23rd.