[Kde-games-devel] Re: Tagaro as an application?

[Dan Leinir Turthra Jensen]

On Sunday 16 Jan 2011 23:04:01 Stefan Majewsky wrote:
> Hi,
> 
> this is sort of a braindump, and a request for comments.

  Braindumps are best on mailing lists and other not-your-harddisk positions, 
good plan ;)

> I'm currently booted into a newly-installed Windows 7 and watching the
> Steam client download some games I own. [1] I don't know if you know
> Steam. Steam itself is a web/cloud-based game distribution and
> community-building platform, decomposed into a website (steampowered.com)
> and a client application for Win/Mac. The client provides access to a
> library of games, downloads updates, records highscores and achievements,
> manages contacts and friendships, and displays advertisements.

  This actually sounds a whole lot like what GamingFreedom.org is all about. 
Now, because you're wanting to not distribute the games themselves through 
this (or am i misunderstanding you?), and want to concentrate on DLC 
(distributing content for existing games), i am thinking that that site would 
likely be useful for you as well.

> This experience made me think whether a similar model might be beneficial
> for kdegames. I mean a central application for all the plumbing around the
> actual gameplay:
> * downloading content (levels or levelpacks) and keeping it up-to-date
> * downloading and selecting themes

  These are all in OCS already, though it might need a bit of extra stuff on 
the dependencies side - something which is already under consideration for OCS 
version 2.0 :)

> * managing highscores
> * managing saved games

  These sound like new OCS modules (see below ;) )

> * GGZ matchmaking

  Not OCS ;)

> Let's call this app "Tagaro Center" for now. So for example, imagine that
> you fire up Tagaro Center and it tells you: "Heya, do you want to continue
> playing this KGoldRunner game that you left yesterday at 23:17, or do you
> want to download the Puzzle of the Day [2] from the Palapeli server? By
> the way, the Egyptian theme for KPat has been updated. I'm fetching the
> update right now and will activate it on the KPat window over there when
> it's done."
> 
> From the technical side, centralizing these aspects has the advantage that
> we do not need to specify public API for this in libtagaro. (And even if
> this approach fails, the API can be added later, while the inverse
> operation is BIC.)
> 
> It can also simplify the application code considerably. For example, this
> change would mean that Palapeli would become an MDI application, with
> Tagaro Center managing the puzzles and Palapeli being reduced to the
> puzzle table.
> 
> I'm not aware whether this infrastructure would be good or bad for the GGZ
> side of things. (Josef?) I can however imagine that having a single client
> that connects to the GGZ server is the simpler design.
> 
> The obvious downside is that there is yet another application involved in
> the whole gaming process, which might confuse new users and increase the
> memory footprint, but what do you think? Is it worth to try out this
> concept?
>
> Greetings
> Stefan
> 
> P.S. If we do this, we should keep the Gluon devs in the loop to ensure
> that Tagaro Center can operate as a platform for Gluon apps (if this is
> possible; I don't know any specifics about the ontology of Gluon apps and
> components). Interoperability with any other game frameworks is a
> subordinated goal.

  GamingFreedom.org (our distribution site) uses the Open Collaboration 
Services for all contact between the player applications and the server (and 
gluon creator as well)... We will need a few extra things as well, in 
particular you might've seen a random note about a new module for 
achievements. Other than that, of course, high scores, savegames and the like 
will need some storage server side.
  While it would be fun to have this directly on the person, this is far too 
specific to games, which means that it really needs a module designed 
specifically for such things. So, it would be great if we could identify all 
those needs and work together on such an API :)
  As for being able to play Gluon based games, this ought to be not at all too 
difficult - as long as GluonEngine is installed, building a simple player to 
simply launch games is very straight forward (to the tune of around ten lines 
of code if memory serves).

> [1] I never paid for these games, I've just been at the right places at the
> right times when they gave away Portal and Half Life 2 for free.
> [2] Setting up a server that converts Images of the Day (e.g. from
> Wikipedia) to Puzzles of the Day is a long-standing idea of mine, which I
> did not realize yet.

-- 
..Dan // Leinir..
http://leinir.dk/

                          Co-
                            existence
                          or no
                            existence

                          - Piet Hein