KDE Games/Ideas

KDEGames Ideas and Proposals

New Features

• 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)

Visuals changes

• 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")

User interaction

• Keyboard/Mouse/Game-pad (where possible)
• Highs-core viewer/manager (clear/share/view) ?*unified*?3
• stats for the game usage

Application level

All

• GGZ Network game support (where possible)
• Standardize menus (rest of the interface)
• Interchangeable themes for all games.
• Theme selection dialog has to be one and the same.
• ?Unified "theme selection dialog"?
• ?Game selector? Downloader?
• "New Stuff" getter + Theme selection dialog = better integration
• Rethink Theme structure + animations support
• Can we read settings from SVG file directly?
• Can we have frames described inside?
• How to define animation?

KGoldrunner

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

Kubrick

• 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).

Knetwalk

• 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'?

Onscreen Interface

Elements:

• Container/Panel
• Button
• Label
• (Icon?/Pixmap?/Vectormap?/Part of label???)
• self alignment (left/right/top/bottom) < application defined
• XML driven?
• Themable?
• One code to rule them all

Text:

• Use QT4, or not?
• preset font?
• Ship font?
• Vectorized fonts
• Don't use texts, just images/icons?

Notifications

Elements

• Container/Bubble
• Vabel
• Icon
• self alignment (left/right/top/bottom) < application defined
• Themable?
• Once code to rule them all

Reworked highscore system

General ideas

• Get rid of KExtHighscore. It's unused and unusable.
• Get rid of KHighscore and use KConfig directly (but see next suggestion)
• Split KScoreDialog in two parts - GUI part and config-writer part (it should

use KConfig like KHighscore does it).

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

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)
• 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.