KDE Games/Tagaro/Data ontology

From KDE Community Wiki
Revision as of 20:10, 17 January 2011 by Majewsky (talk | contribs) (I'm still working on this)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Purpose

  • 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 flag uploaded content as private (see next section)

Savegames

  • A savegame records the state of a game at some point in time, so it can be continued from this point at a later time, possibly on a different computer.
  • current situation: some games can store savegames as files (e.g. Kolf)
  • what we need:

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, infrastructure for integrity checks