Goal of libgamelib

[karolherbst]

It is important to have a specific goal for a project.

For me libgamelib should be a library for creating awesome cross store Game Management Clients. Stores should be configured through very simple text files.

Stores should also be able to write a single GUI Frontend for their specific store with branding and single store mode.

I will collect results here:

[Cheeseness]

Perhaps some slightly more detailed key features might also help describe this:

• Store agnostic game downloader (supporting multiple protocols)
• Store agnostic game updater (supporting multiple protocols)
• Store agnostic game launcher (supporting user defined binaries)
• Easy to set up via text based configuration files
• Creating custom/branded GUI front ends should be as easy as possible

Other things that would be nice to have:

• Working example GUI (with branding customisable via a text based configuration file?)
• Wrapper allowing for Steam-like in-game overlay?
• Hooks for in-overlay and in-client XMPP integration?
• API for game->remote server communication?

[karolherbst]

what do you mean with "API for game->remote server communication?" Something like achievements?

[Cheeseness]

"API for game->remote server communication?" Something like achievements?

At the time, I was thinking more like content delivery (say, requesting somebody else's user generated content), but it was more a "here's something that would probably be of value for things that we haven't thought of yet" type thing.

If we were going to do achievement support, we'd possibly want to allow that to happen via an external authorative server (run by store providers?), so a gamer -> server communication feature would probably help with that. If we did do achievements, it would be neat to use/implement an open standard like Mozilla's badge stuff.

[karolherbst]

I would like to use as much as possible from the stores directly. I can imagine to add an API, that wraps around stores, but this would bind the game to libgamelib and I don't want to do this.

[Cheeseness]

If we did have some game-> remove server communication mechanisms, I think it'd be best to consider that as a separate lib that people could implement directly into their games or other places outside of our client.

[karolherbst]

yeah, I want only an overlay, which utilizes functionalities from the stores you have an active account, but it should not have game->overlay calls. We could use it for screen recording, screenshots, Chats, etc..

[karolherbst]

In fact nobody should ever call libgamelib besides the Client GUI. I would like to add an IPC based solution to broadcast events like dbus, so IM clients can listen to them.

[Cheeseness]

Hmm, I thought we were aiming for something game stores could communicate with for authentication, download verification and other game deployment related stuff.

Is there a reason why we'd want to steer clear of that sort of stuff? (we should all totally be brainstorming this stuff via IRC)

[karolherbst]

yeah, stores should be able to do this, but I would rather not bind the games to it. libgamelib should more use the stuff of stores and provide the game library functionality on top of it.

If libgamelib should provide a way for chatting with friends, a game store should just provide an API for that, but this API (even if we do it via HTML scrapping) should be provided by the store and libgamelib should not require any fixed APIs at all.

[Cheeseness]

I was thinking it'd be neat to (down the track) integrate libpurple to provide chat support and that way if game stores want to set up their own XMPP servers, they can, and we can have account creation hooks, but if not, chat functionality is still present and workable with all purple friendly protocols.

[karolherbst]

yeah, that is fine by me, but games itself should not rely or use libgamelib functionalities. We can use it in an overlay, because the game won't talk to a libgamelib overlay at all. Maybe a game relies on a specific overlay from a specific store, but here libgamelib would wrap around this overlay.

[Jookia]

Here are my notes that I haven't tidied up since I've been swamped with stuff. It mainly focuses on the serverside stuff that's important:

libgamelib:
  will we work with store owners to create a tiny simple API that they can
  implement?
  be able to 'emulate' the API on stores that don't have it
  API:
    authentication
    personal game list
    game info
      name
      download
        full game
        updates
  dummy API server for tests (also able to test production servers)
  todo:
    defined ways to auth, and install game/updates

[karolherbst]

I think this will give you most of the answers: discussion with fireflower and Kejiro on 20131113

[karolherbst]

also #7 is worth a look

[karolherbst]

8 is talking about the "Models" and the API isn't yet decided, but I made some architecture stuff here: #13

[Cheeseness]

discussion with fireflower and Kejiro on 20131113

I haven't yet had time to read this, but if anybody wants to distil what's covered there down into a set of questions, I can bring them to Jeff to chat about.

[Cheeseness]

A super high level overview I put together as part of the stuff I've been working on for pitching Gamekeeper to stores.

Any thoughts?

[karolherbst]

yeah, looks nice

[Cheeseness]

We were talking in IRC about updating the detailed framework architecture diagram. GitHub doesn't let me attach SVG images, but here's a 1600px wide render.