|
The beginnings of a KControl module for Decibel configuration make an appearance. Developments in the Subversion plugin for KDevelop. More optimisations in the KJS JavaScript interpreter. Further progress in the KBattleship rewrite. New country maps in KGeography. KRfb, a desktop sharing utility, starts to be ported to KDE 4. A new GStreamer backend for Phonon, and QSR, a search-and-replace utility, are imported into KDE SVN.
|
Gaël de Chalendar introduces KsirK, a strategy game proposed for inclusion in the kdegames module for KDE 4:
|
KsirK is a computerised version of a well-known strategy board game: Risk! It is a game for KDE released under the GPL. KsirK is a multi-player, network-enabled game with artificial intelligence.
The game has two modes: conquer the World or reach a goal like conquering two given continents. This is done through attacking your neighbors with your armies. At the beginning of the game, countries are distributed to all the players. Each country contains one army (represented by an infantryman). Each player has some armies to distribute to his countries. Note that five armies are represented by a cavalryman and 10 by a cannon. On each turn, each player can attack his neighbours, eventually conquering one or more countries. At the end of each turn, some bonus armies are distributed to the players relative to the number of countries they own.
KsirK is fully skinnable, allowing the use of other maps, other countries, other goals, etc. depending only on your imagination and artistic skills.
My motivation for this work is simply to offer KDE gamers a pleasant and challenging game in which the user can have good moments with players all over the world. That's all :-)
I have developed my KDE development skills through steady practice - I also wrote KGraphViewer, an application which has been in extragear/graphics for some months. I'm not a great technician, but I now have a good experience in digging into Qt and KDE API docs: what makes it so great to develop for KDE is these great docs.
I started this game around 1995 in order to learn C++ and Windows 95 programming. It was initialy named "Risk". I used a book about WinG, one of the first Microsoft attempts to give gaming abilities to Windows. But a lot of the examples of this book were in assembly language (which I never learned). I used these routines, but without being able to fully understand them. This first version never reached an acceptable status. Some time later I heard about Java and decided to learn it. So, I decided to convert Risk to JRisk. I obtained, if I remember well, a version that was running adequately, but really slowly. This was due to the use of an early version of Java but also to a really ugly programming!
In the meantime, for my work, I learned Smalltalk (VisualWorks), the object-oriented language (try it, you really cannot experience higher OO programming pleasure - I'm addicted!) and so discovered all the power of good OOP. I started also to use Linux and KDE. I wanted to learn KDE programming and so decided to convert back my lovely project to C++. KRisk was born! Through my experience of Smalltalk and the APIs of QT and KDE, my work has steadily improved.
At the time of April 2002, some architectural problems due to this complex history remained, but the application worked well and I could release a public version. I choosed to rename it in order to avoid copyright issues: welcome to KsirK!
In early 2003, KsirK got a minimal AI (for Artificial Idiot as its decisions were chosen completely at random) and the themability of the world. This last point was a direct consequence of the improvements of the overall architecture of the game.
I finally decided to propose the inclusion of KsirK in the kdegames module because I believe it would be good to have such a game in the package and because I felt the application ready for it. I made my proposal during one of the #kdegames IRC meetings and it was well-received. Also, during the poll about the future of kdegames, KsirK was one of the more demanded games.
The KGame library was a great help to develop the network part of KsirK and it's a pity that this library is rarely used.
Here is one of the first snapshots of the KDE 4 version of KsirK:
|
|
Gaël points out that the trunk version of libkdegames (so, for KDE 4) is now Qt3 and KDE3-support free. So, games which use this library can now be compiled without the support libraries.
|
For yet another indication of the current vitality of the kdegames module: Luka Marinko, someone who is completely new to KDE development, proposes to port KSnake to KDE 4 as his introductory task:
|
For some time now, I wanted to (had an itch) to help develop KDE. But since most of my programming to date has been on server side (C, Java, PHP, Python), never found enough time to learn GUI programming or C++. Now I have some more time, and decided to finally do it.
So after reading a few blogs and KDE wiki's I decided that best place to start is probably the games. I also noticed that KSnake isn't getting much attention. Since I quite like this kind of game (all the way back to Nibbles on DOS) I decided to do something about it.
What I am planning on doing:- Firstly, I intend to port the graphics to SVG.
- Another problem is size of game area. By default, the window size is about 1/4 of the size of a 17 inch monitor (1280x1024). Even with SVG graphics, if you maximize the window the game will look odd, since everything will be too big. So we need bigger levels, but if we just increase current level size, you get more room to move in, and the game gets easier as a result. So we also need new levels :)
- Current levels (and also the title screen and "level loading" graphic) are stored as 1-bit per pixel bitmaps, stored in header files which get linked in at compile time. I intend to change this to something that gets read at runtime.
I had some discussion about this on the #kdegames IRC channel, and one suggestion by Mark A. Taff, is to store levels as SVG (with help of clones and an ID naming scheme), the other one is to store levels similar to how KAtomic stores them. I welcome other suggestions.
- About gameplay, I find enemy snakes and balls annoying, so I would change the default game style to be without them. I was thinking of providing a few pre-configured game styles (this is just a few off the top of my head, suggestions welcome):
- Pick up a specified number of apples (depends on the level) before you can move to the next level (less time you take and higher the level the better the score)
- Pick up as many apples as possible, each time you do you grow or the speed increases - you never advance to the next level (so, how long you can last :). This mode would probably need some dedicated levels.
- Survive against enemy snakes, survive a specified amount of time against killer snakes (maybe balls also), you _don't_ grow (so you can't box yourself in someplace :)).
In general I think this is the sort of the game that shouldn't become too complicated: it should be quick to load, and quick to play.
- Sound: I listen to my ogg's and mp3's :)), so I have no plans in that regard. (that said, the Phonon API is nice, if there is demand for music/sound in games).
KSnake currently has no maintainer. Since I am so new/fresh I don't think I am capable of being one just yet. So what do we/I do? Is there someone willing to take over at least for the time being, or perhaps just move it to playground, until it's up to speed?
While I am sure I can learn to do everything myself, I will take any help I can get, whether this is in the form of pointers, suggestions, graphics, comments, code or tips & tricks.
|
|
Allen Winter provides a quick update on the state of KDE-PIM as we get ever-closer toward KDE 4:
|
In KDE-PIM news, this week saw some big fixes with the KMail IMAP support, thanks to a tremendous debugging effort by Stephan Kulow, Will Stephenson and our merry band of testers. The bug fixes have already been ported to trunk for the KDE 4.0 release and will be available in KDE 3.5.7, of course. KMail also received an infusion of new features from the good folks at KDAB, including:- folder drag'n'drop, allowing to copy or move (nearly) any folder
- search result drag'n'drop
- local subscription for disconnected IMAP accounts, allowing to mix online and disconnected IMAP on the same account.
- inline viewing of MS-TNEF attachments
The first two are already merged into the 3.5 branch, the remaining ones will be merged in the coming week from the KDE-PIM enterprise branch and thus will be available in KDE 3.5.7.
As with KDE 3.5.6, KPilot continues to receive much love from the KPilot team. All the recent changes are contained within our features development branch, but we expect them to be released with KDE 3.5.7.
On the API front, kdepimlibs received Christian Weilbach's blogging library called "kblog". From Christian:"KBlog is a small library for access to Blogger 1, MetaWeblog and Blogger 2 compatible blogs. It makes heavy use of the KXmlRpc client library of kdepimlibs and supports asynchronous sending and fetching of posts and (if supported on the server) multimedia files. Almost every modern blog software supports one of the APIs mentioned above."
We hope this new library will give our blogging team a solid basis for providing some cool blogging capabilities in KDE 4.
In addition, the old "emailfunctions" library was renamed to "kpimutils" and this is where we intend to keep our general purpose PIM utilities.
|
|
Though somewhat similar in content to the previous 51 weekly issues, this issue is fairly special, as it is number 52 of the "new" KDE Commit-Digest series, marking a year of digest goodness. To another year of exciting issues!
|
|
![[*]](/images/standard/features)
![[*]](/images/standard/other)
![[*]](/images/standard/bugfixes)
![[*]](/images/standard/optimise)