KDE Games/Tagaro: Difference between revisions

From KDE Community Wiki
(Created page with 'Tagaro is the top secret codename for my redesign of libkdegames. More details coming soon.')
 
m (moved Games/Tagaro to KDE Games/Tagaro over redirect: Requested by Frederik Schwarzer.)
 
(8 intermediate revisions by one other user not shown)
Line 1: Line 1:
Tagaro is the top secret codename for my redesign of libkdegames. More details coming soon.
Tagaro is the top secret codename for my redesign of libkdegames.
 
== Goals ==
 
* deprecate unmaintained frameworks like KExtHighscore
* create tools that allow KDE games to scale to new form factors
* use new and state-of-the-art Qt and KDE technology to its full extent
 
== FAQ ==
 
; Where is the code?
: Clone the repository from [http://git.bethselamin.de/?p=tagaro.git;a=summary my Git server]. I want to move it to git.kde.org when this becomes available, but it is not yet. If you want to participate, send me your push requests. I can also give you commit access, or put it on a more publicly available place, if you plan to work on it regularly.
; What does the name mean?
: Tagaro is an oceanic deity which is said to have created mankind in a game of bowling. A perfect fit for a library which allows you to create games.
; Is its feature set/API/ABI stable?
: No way. Work has just begun, and we're by far not done desigining and implementing everything.
; When will it be ready?
: Even earlier if you help out. :-) But seriously, I hope to get first parts into the 4.7 release.
 
== Modules ==
 
=== Core ===
 
;Status: configuration facilities are available
 
This library will (if necessary) define common data types used throughout the other Tagaro libraries.
 
libtagarocore also provides configuration facilities in order to allow users and packagers to control the behavior of all Tagaro-based games from one central point.
 
=== Graphics ===
 
;Status: mostly finished; support for bitmap images missing; we might want to roll our own SVG implementation with extended editing API
;Responsible developer: Stefan Majewsky
 
libtagarographics manages and renders theme components. Possible theme formats include:
* SVG-based component themes (like currently managed by [http://api.kde.org/4.x-api/kdegames-apidocs/libkdegames/html/classKGameTheme.html KGameTheme])
* single SVG or bitmap images (like currently managed e.g. by [http://api.kde.org/4.x-api/kdegames-apidocs/libkmahjongg/html/classKMahjonggBackground.html KMahjonggBackground])
The KGameRenderer framework has become a part of libtagarographics for this purpose.
 
Furthermore, libtagarographics provides some convenience classes for embedding these theme components into QGraphicsView and possibly QDeclarativeView. (We have not made a final decision whether Tagaro will have built-in QML support.)
 
=== Interface ===
 
;Status: first components (Board, MessageOverlay, Scene) available; on-going evaluation of QGraphicsWidget and QML
;Responsible developer: Stefan Majewsky
 
Today, the user experience of our KDE games resembles very much the interface
of desktop GUI applications: They have a menubar, a toolbar, a statusbar. There is no homogeneous API for on-screen game interface elements.
 
libtagarointerface will provide these on-screen game interface elements, and automatically substitute them for the traditional KXmlGuiWindow chrome on mobile devices, or in fullscreen mode (which will be available to all games automatically).
 
=== Input ===
 
;Status: to be done
 
This is where the dreaming starts. :-D
 
I envision an input framework that recognizes the context of input events, rather than just their receiver, like QtGui does. Palapeli has something remotely similar with its InteractorManager, but these classes have serious design flaws.
 
=== Gaming ===
 
;Status: to be done
 
There is the [http://api.kde.org/4.x-api/kdegames-apidocs/libkdegames/kgame/html/index.html KGame] namespace in libkdegames, which provides an abstraction for general game components (like players, data exchange in network games, chat channels). Like most parts of libkdegames, KGame is near ancient, and should probably be rewritten, based on the actual requirements of our games.
 
=== Audio ===
 
;Status: mostly ready, needs testing
;Responsible developer: Stefan Majewsky
 
Phonon cannot (and does not) guarantee low latencies and is therefore (in general) unsuitable for games. TagaroAudio therefore uses OpenAL+libsndfile, but that's an implementation detail which is very well hidden by the API (in contrast e.g. to GluonAudio, which is essentially a Qt-style C++ wrapper for the OpenAL libraries). The only OpenAL-specific feature exposed by the API is positional playback.
 
=== More? ===
 
We certainly need more modules for Tagaro, for example for...
* multiplayer networking (GGZ, Telepathy, Jabber, or whatever provides a solid base)
* social gaming (definitively an area to collaborate with the Gluon people on)

Latest revision as of 03:58, 27 March 2012

Tagaro is the top secret codename for my redesign of libkdegames.

Goals

  • deprecate unmaintained frameworks like KExtHighscore
  • create tools that allow KDE games to scale to new form factors
  • use new and state-of-the-art Qt and KDE technology to its full extent

FAQ

Where is the code?
Clone the repository from my Git server. I want to move it to git.kde.org when this becomes available, but it is not yet. If you want to participate, send me your push requests. I can also give you commit access, or put it on a more publicly available place, if you plan to work on it regularly.
What does the name mean?
Tagaro is an oceanic deity which is said to have created mankind in a game of bowling. A perfect fit for a library which allows you to create games.
Is its feature set/API/ABI stable?
No way. Work has just begun, and we're by far not done desigining and implementing everything.
When will it be ready?
Even earlier if you help out. :-) But seriously, I hope to get first parts into the 4.7 release.

Modules

Core

Status
configuration facilities are available

This library will (if necessary) define common data types used throughout the other Tagaro libraries.

libtagarocore also provides configuration facilities in order to allow users and packagers to control the behavior of all Tagaro-based games from one central point.

Graphics

Status
mostly finished; support for bitmap images missing; we might want to roll our own SVG implementation with extended editing API
Responsible developer
Stefan Majewsky

libtagarographics manages and renders theme components. Possible theme formats include:

  • SVG-based component themes (like currently managed by KGameTheme)
  • single SVG or bitmap images (like currently managed e.g. by KMahjonggBackground)

The KGameRenderer framework has become a part of libtagarographics for this purpose.

Furthermore, libtagarographics provides some convenience classes for embedding these theme components into QGraphicsView and possibly QDeclarativeView. (We have not made a final decision whether Tagaro will have built-in QML support.)

Interface

Status
first components (Board, MessageOverlay, Scene) available; on-going evaluation of QGraphicsWidget and QML
Responsible developer
Stefan Majewsky

Today, the user experience of our KDE games resembles very much the interface of desktop GUI applications: They have a menubar, a toolbar, a statusbar. There is no homogeneous API for on-screen game interface elements.

libtagarointerface will provide these on-screen game interface elements, and automatically substitute them for the traditional KXmlGuiWindow chrome on mobile devices, or in fullscreen mode (which will be available to all games automatically).

Input

Status
to be done

This is where the dreaming starts. :-D

I envision an input framework that recognizes the context of input events, rather than just their receiver, like QtGui does. Palapeli has something remotely similar with its InteractorManager, but these classes have serious design flaws.

Gaming

Status
to be done

There is the KGame namespace in libkdegames, which provides an abstraction for general game components (like players, data exchange in network games, chat channels). Like most parts of libkdegames, KGame is near ancient, and should probably be rewritten, based on the actual requirements of our games.

Audio

Status
mostly ready, needs testing
Responsible developer
Stefan Majewsky

Phonon cannot (and does not) guarantee low latencies and is therefore (in general) unsuitable for games. TagaroAudio therefore uses OpenAL+libsndfile, but that's an implementation detail which is very well hidden by the API (in contrast e.g. to GluonAudio, which is essentially a Qt-style C++ wrapper for the OpenAL libraries). The only OpenAL-specific feature exposed by the API is positional playback.

More?

We certainly need more modules for Tagaro, for example for...

  • multiplayer networking (GGZ, Telepathy, Jabber, or whatever provides a solid base)
  • social gaming (definitively an area to collaborate with the Gluon people on)