Looking ahead

[Alex Wilson]

While the OS is being worked on, I've been looking at the next steps in the roadmap like the games package and the API and I've thought of some questions that need to be discussed to move on in those areas.

• What kind of data exactly needs to be given with games (like in a package.json/game.json file)?
• Anything about permissions or is that too complicated and out of scope?
• Basic metadata like name, publishers, credits, etc.
• What options do we have for databases/storing information like achievements/scores locally?
• I remember we discussed that we were looking for alternatives to MongoDB?
• Will game developers need to interact with our AngularJS stuff, or will they be able to just give us some HTML, CSS and JavaScript and have it work?
• I think that all that they should need to provide is a main HTML file and various files linked from that

[Scott Elcomb]

On Thu, Jul 4, 2013 at 12:04 AM, Alex Wilson <arex...@gmail.com> wrote:
> What kind of data exactly needs to be given with games (like in a
> package.json/game.json file)?
>
> Anything about permissions or is that too complicated and out of scope?
> Basic metadata like name, publishers, credits, etc.

I think we should start with just basic metadata; while I can see
value in permissions, I think it's probably out of scope for now.

AFAIK the node-webkit project is not yet ported to the Pi (though
there are a couple folks working on it). If and when it does become
available I think it'd be worth another look - node-webkit would be
well-suited to enabling a permissions system.

> What options do we have for databases/storing information like
> achievements/scores locally?
>
> I remember we discussed that we were looking for alternatives to MongoDB?

I would love to have mongo but I'm no longer convinced it's worth the
effort - at least not for the first version.

Over at psema4.com I'm working on an AngularJS site that communicates
with a very simple flat-file database of .json files. It's lightweight
(a small .cgi script which would be even smaller in node), RESTful
(which AngularJS comfortably consumes as $resource's) and best of all:
dead-simple.

There is a related question that I have though; are we providing a
platform as a foundation for others to build their own gaming consoles
and networks from? ie. should the base OS image include pine server
functionality? If so, should that be the default "network" for the
pine client or should we point it to "pinegames.org" (or whatever
domain we end up using).

FWIW, I don't think the image needs to include the server
functionality initially and that we should point the client to a
central server. If it's a feature (to create your own gaming network)
that others desire, we could (potentially) add it as a download from
the pine "store."

As regards the client, we may not need anything beyond localStorage
and/or sessionStorage - user profiles, achievements and the like can
all be retrieved via the servers' RESTful API.

> Will game developers need to interact with our AngularJS stuff, or will they
> be able to just give us some HTML, CSS and JavaScript and have it work?
>
> I think that all that they should need to provide is a main HTML file and
> various files linked from that

On the angular branch in the repo there are currently 2 "games" (stubs
really); these are what I'd image a game package to look like after
downloading & unpacking (albiet missing the manifest). For example,
here's the 2nd game stub:
<https://github.com/psema4/pine/tree/angular/angular/games/test2>

It keeps things simple.

User Workflow example: User logs into the pine "store" app/game which
makes a RESTful call to the server for known games. User views some
titles and decides to download one. Pine client downloads the
appropriate package and extracts it into the games folder (like the
test2 link above). Voila, game installed.

Dev Workflow example: Developer creates a folder, adds a manifest
file, game.js file* (game code) and assets folder. Any assets
referenced in game.js should be placed appropriately under the assets
folder. Developer iterates as necessary* and when ready to upload,
simply zip's the game's folder and uploads it to the pine "store"

* This bit intentionally left blank; I'm working on pine as we speak
and will expand on this shortly. The example is intended to be a
birds-eye view of the process.

--
Scott Elcomb
@psema4 on Twitter / Identi.ca / Github & more

Atomic OS: Self Contained Microsystems
http://code.google.com/p/atomos/

Member of the Pirate Party of Canada
http://www.pirateparty.ca/