Latest revision as of 17:39, 27 April 2012

KDEGames Ideas and Proposals

Multiple pointers and joypads connection feature (daemon?)
KGoldrunner - add game of tag feature (one controller for the runner, and one for the enemy) (Invented by Emil)

Unified onscreen interface (including menubar/submenus; shortcuts; toolbar buttons (place/name); statusbar)
Themable notifications (as part of "Unified onscreen interface")

universal background support (and maybe even theme)

Do we need toolbars? Can all be moved to the screen instead? (See "Unified onscreen interface")
Statusbar to display only unimportant information. All that relevant has to be on screen. (See "Unified onscreen interface")

Lots of changes suggested by Luciano Montanaro and Ian Wadham.
For details see http://websvn.kde.org/trunk/KDE/kdegames/kgoldrunner/TODO?view=markup

A new game for KDE Games, written by Ian Wadham about 2 years ago, but unable to be converted to KDE 4 due to pressure of other work ;-)
It is a 3-D game which uses OpenGL graphics.
Basically it is an on-screen animated Rubik's cube with configurable sizes ranging from 2x2x2 (for kiddies) to 6x6x6, including "bricks" such as 3x4x2 and "mats" such as 6x3x1.
Cubes can be saved to a file, reloaded or undone/redone for any number of moves.
There are several puzzles of varying difficulty, as well as demos of solving moves and classic "pretty patterns".
Hopefully it will reach Playground in KDE 3 form soon (as at 22 Jan 2008), then be ported to KDE 4. There are also some finishing touches to be put to the user interface (not the GUI, but more ways for the user to move the cube/brick).

Complaint - After the game is done and the highscore is shown, it takes quite an effort to start a new game (close window, go to menu, choose 'New'). Solve by adding a 'New game' button right onto highscore window?
Some people say they sometimes need to see the end results of the game to take a screenshot... Maybe build in this functionality right into 'Highscore'?

use KConfig like KHighscore does it).

Implement type of highscores where high score is gathered separately for each level (katomic, kolf, kshisen)

Somehow split the highscore group name which will be written to the config file with one which will be shown to the user. This will allow to freely translate visible name while not affecting config file
High scores should be put in a separate file in the game's "data" area,

$KDEHOME/share/apps/<appname>

Add option to seed highscores with some data to provide some challenge to new players (see kgoldrunner as an example)
Option to supply a nice heading and sub-heading (see kgoldrunner)
Nicer table and headings layout (see kgoldrunner)
Single-spacing of the lines in the table.
No lines of dashes for empty scores.
Neater alignment of headings and data, especially days of week and dates (neither attachment is good in this respect).
Option either to display one set of high scores and omit the tabs, or to supply separate group IDs and group names: the IDs to be used as keys (group games) for high score data and the names (translated) to be displayed to the end-user on the tabs.
There should be a cleaner separation of the GUI and the scores it represents so one can easily reuse the GUI for other score systems.

@@ Line 77: / Line 77: @@
 ===Implementation notes===
 * Somehow split the highscore group name which will be written to the config file with one which will be shown to the user. This will allow to freely translate visible name while not affecting config file
+* High scores should be put in a separate file in the game's "data" area,
+$KDEHOME/share/apps/<appname>
 * Add option to seed highscores with some data to provide some challenge to new players (see kgoldrunner as an example)
 * Option to supply a nice heading and sub-heading (see kgoldrunner)