Jump to content

KDE Games/Tagaro/Data ontology

From KDE Community Wiki
Revision as of 03:58, 27 March 2012 by Bcooksley (talk | contribs) (moved Games/Tagaro/Data ontology to KDE Games/Tagaro/Data ontology over redirect: Requested by Frederik Schwarzer.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Purpose of this page

  • define an ontology of types of data entities etc. which are used throughout different games, and can be managed centrally
  • make it interoperable with non-Tagaro apps, esp. Gluon (interoperability with any other Linux games is a secondary goal)
  • download/upload entities to a server, most probably via OCS

Data types

User-generated game-specific content

  • This includes any static, public content: levels, level packs, themes, etc.
  • current situation: some games have KNewStuff support and can download themes, mostly from kstuff.org
  • what we need:
    • basically what we have now
    • semantic links between content is desirable (e.g. theme packs which apply to multiple games, like the Egyptian theme pack introduced with 4.4)
    • user should be able to restrict access to uploaded content (see next section)

Savegames/recordings

  • A savegame records the state of a game/match at some point, so it can be continued from this point at a later time, possibly on a different system. The actual format depends highly on the application.
  • Recordings describe a match that has ended, possibly in a way that allows external programs to verify the integrity of the recording. Integrity means that the recording has not been modified in order to misrepresent the score or similar achieved by the player.
  • current situation: some games can store savegames as files (e.g. Kolf)
  • what we need:
    • client-side infrastructure for storing savegames and recordings, possibly with integrity checking
    • server should be able to store savegames and recordings in a private section as a backup, for transfer to a different system, or for integrity checking of highscores (see below)
    • user should also be able to publish recordings and download and view the recordings of others

Highscores

  • This is basically a key-value map of values, with the keys and value data types defined by the application.
    • example: KDiamond stores player name (string), score (int) and mode (untimed or timed game) for each score
  • current situation: locally stored in application config via KHighscore, no server-side system
  • what we need:
    • highscore server with at least global and personal highscore tracking, possibly also per self-defined groups (for competitions between friends)
    • infrastructure for integrity checks (possibly using a recording of the match that achieved the highscore)

Achievements

Gluon people, that's for you. We do not have anything like this at the moment, and I have not played games with achievements so often that I can talk a about this on a thorough basis.

  • Achievements are...
  • current situation: not used in kdegames
  • what we need:
    • ...
    • ...