Help Me To Solve Some KBounce's Design Issues

Hello everybody.

Me and last year's Season of KDE student Anuj Pahuja implemented a save and load feature as well as keyboard support for KBounce. However, before finally merging the changes into the master branch I'd like to hear your opinion regarding some design questions. Here they go:

1. The player is allowed to load a saved game only once. i.e. as soon as the game is loaded the save file is deleted. I made this to avoid cheating from the player's side. Without deleting the file, a player could replay the same saved game countless times, managing to always go to the highscores list.

I'm unsure about this. Is it desirable for a player to have this ability? What's your general experience on the subject?

2. By default, the keys used to move the cursor are W, A, S, D; L for rotation and Space to simulate a mouse click. What do you think about this setup? Are the arrow keys preferred over W, A, S and D? Independent on the default settings the shortcuts may be changed by the player.

3. The following screenshots show the new dialogs I've had to include. #1 looks terrible though I can't think on good alternatives to improve it for now. Your opinions are very welcome.

Save Game Dialog

Load Game Dialog

Trying to Load a Game When Tere's None Saved

4. Is Ctrl+O a good shortcut for "Load Last Saved Game"? What would be a better alternative?

The code is available at the keyboard-integration branch on kbounce's repository. Give it a try and feel free to share your thoughts on the comments bellow.

KDE Games on SoK

If you're willing to be part of this year's SoK then don't be so eager to pick a project, consider working with KDE Games having fun with one of the coolest parts of programming: game development.

I wrote the following proposals related to KBounce and KNavalBattle, which are the games I currently maintain and therefore feel more confident regarding mentoring related projects. However this is not a problem, if you have a project or at least a good idea for a project related to any game in KDE, then feel free to talk to me and submit your proposal.

This is just an "official" post for publicizing the proposals to the KDE community, you can also find them on SoK's wiki.

1: Reveal opponent's ships when losing a game in KNavalBattle.

Brief Explanation: After losing a game it would be interesting for the defeated player to see the opponent's ships. This way a player is allowed to study the adversary and plan ahead for future matches.

Currently there's a branch on KNavalbattle's repository with some code that implements this feature. However, it only works on single player mode and has no entry at the settings menu. Some polishing and a thorough review is needed

Expected Results:

• The feature shall be optional, with a correspondent entry at the settings menu. 
• It shall work in all game modes.

Knowledge Prerequisites: C++ and Qt focused on QGraphicsView.


2: Make the number of ships and size of grid configurable in KNavalBattle. 

Brief Explanation: Currently the player has not the option to decide how much of each ship will be placed on the sea before a match. This way many users complain that KNavalBattle has basically become a game of luck, not allowing a player to define a good strategy for guessing where the smaller ship is hidden. 

Implementing this feature can be accomplished by letting the players individually select the quantity for each kind of ship -- something ranging from zero up to a number still undefined -- through a new special menu that will appear during the pre match stage.

Expected Results: 

• A new dialog menu shall be designed. This menu must contain a chat widget case the game is being played through a network, as well as a system allowing a game to be played only if both players agree on the selected set of ships.
• The new feature shall work in all game modes.

Knowledge Prerequisites: C++ and Qt.


3: Fix as much KBounce's or KNavalBattle's bugs as possible.

Brief Explanation: Simple as the title says. The accepted student will pick a game and within two or three months, with my help naturally, will try to fix as much bugs as possible.

Expected Results: At least three bugs fixed within the scheduled planned.

Knowledge Prerequisites: C++, Qt and a basic notion on how to use Review Board and generate diffs.

[GSoC] KBounce Has Been Ported to QGraphicsView

I am considerably late regarding writing a blog post about my progress in this year's GSoC. I was terribly busy working on the project and solving some pending stuff from university. But now, for my relief, the summer came and therefore I have some free time to dedicate to this newly created blog. :-)

My proposal has as its title "Porting Games to a More Modern Graphics Framework" and was designed taking in consideration this topic provided in the KDE's ideas page. Basically, my project consists of changing the graphics stack and the rendering system of six games, porting them from the old KGameCanvas libraries to the most recent stable version of the Graphics View Framework (namely QGraphicsView) and KGameRenderer.

You can found a more detailed description of my proposal here.

It's been more than a month since KBounce was finished but, as explained above, just now I have the necessary time to write something.

KBounce is a game simple to play and understand but extremely hard to master. I was extremely surprised, after reading this interesting article, to know that there is a registered world record for the game and that such record is something unthinkable from the point of view of a casual player. See the picture:

Naturally, I've found some difficulties in this first contact with the frameworks I'm working with. It was hard to understand all the concepts related to the different coordinate systems a game can have, to deal with the translations from one coordinate system to another, and to understand the custom tile-based coordinate system most KDE games have.

Also, it was a bit hard to deal with old and not commented code. Don't get me wrong, I'm not saying that the whole game does not have a single comment. I'm just saying that games, generally, are complex programs and comments explaining some of the arcane equations they use are very welcome. :-)

Visually, there's nothing much different to present, since my modifications are only internal. But, as I am a fan of screenshots, here goes the new QGraphicsView KBounce:

P.S.: As you have probably noticed, I am not an English native speaker and you will find some grammatical errors spread over the text. In this case I'd love to apply your corrections pointed in the comments.

PPS: The next game, KNavalBattle, is almost finished. I'm just waiting my mentor's final evaluation. See you In a few days. :-)