-
Notifications
You must be signed in to change notification settings - Fork 0
Game Package
The idea is to have a game described by it's associated package. This should be a simple JSON file containing some or all available fields to fully describe a game. The initial download of a game package will be directly from the Marketplace. After initial download the local process on each Pine will be able to hit the Marketplace API to get the most recent package for a game and then determine if there are available updates that need downloaded.
disclaimer: I'm imagining this being stored using Mongo so id's I'm calling String's because they are hash's and anywhere that another schema will come into play I'm using the [Schema] notation that mongoosejs uses.
{
name: String
developer_id: String
package_id: String
published: Boolean
published_date: Date
approved: Boolean
approved_by: String
approved_date: Date
reason_not_approved: String
last_updated_date: Date
updates: [UpdateSchema]
reviews: [ReviewSchema] //probably much further down the road
meta: { //not sure that this really needs to be separated into meta
average_rating: Number //probably won't come until reviews
description: String
marketplace_url: String
version: Float
ratings:[RatingSchema]
}
media: {
images: {
thumbnail: String
cover: String
icon: String
wallpaper: String
gallery: Array
}
videos: {
trailer: String
other: Array
}
}
achievements: [AchievementSchema]
leaderboards: [LeaderboardSchema]
}
This may be a big enough topic to warrant another page, but I just want to outline it for now. The rating should contain a unique identifier (probably a letter or 2), a short description and some sort of identifiable image. I don't see any reason why a game can't have multiple ratings attached to it (for example gore & sex could be 2 ratings in our system, vs just getting an R or MA). This will allow us to do content filters easier for parental blocking if necessary.
Will have some predefined keys that may or may not be required like the "icon" and then have a spot to list any number of other media for display. I set up all media to be String's because I was thinking they could all just be URLs or local paths.
Giving these their own Schema so that an update can be described more than just "download new version of game". This will surely warrant a new page at some point, but the idea is to have the client be able to figure out if there is a new version(s) available and then be able to update itself to the newest version. The package will contain a unique version number, a published date, a list of any major changes (like a rating change) and then a developers list of updates.
The second part is the client being able to actually update itself. It would be optimal if we were doing some sort of versioning (can we use git?) to determine the differences and then only merge the needed changes to keep the amount of data and processing the raspberry pi has to do down to a minimum.
Published will be a switch the developer has control over to say if the game is ready to be released or not. Maybe we even want to add another level to this like alpha/beta/rc so that developers can open source beta testing if they choose?
Approved will determine if a game has actually been approved for release in the marketplace. This will require some sort of moderator to put the game through a predetermined review process and then mark it approved. Their name and the date will be attached for record keeping.
If the game is not approved, a reason will be attached and sent back for the developer to fix and then be re-submitted. This is basically the Apple review process and generally it works, though it would be nice to be more transparent and have the community do more of the work and decide the standards.
Only when a game is both published and approved will it show up in the marketplace.
I am imagining this is much further down the line than v1.0, but it does make sense to allow Pine users to review and rate games. It's a good way of helping users sort out quality games and keeping the community involved. However, it's a lot of systems and more moderation to set up so I'm not going to dive into it any further right now.
Again, something that is going to need to be fleshed out in it's own page but for now worth mentioning. Developers will be able to create achievements for their game that can be unlocked and awarded to players. This will work just like any existing achievement system. We will have written API's for tracking progress and unlocking achievements that developers can call from their games. This will be running as part of the Pine client.
A games achievement list will be downloaded as part of the initial game package so an internet connection will not be required to unlock achievements. However, an internet connection will be required to sync achievements from a users local Pine data to the server that we control that powers the marketplace and users online portal.
Much like achievements, this will require another page to be expanded on and will be provided as part of the Pine client API's. Developers can define Leaderboard structures as well as how to sort and determine rankings when scores are submitted. This can all be downloaded in the initial game package and with an internet connection available we should support global leaderboards that mimic local ones automatically.
A game should be able to have as many leaderboards as it wants, though for local storage we will probably need to put a limit on how many records these tables hold max to make reading and sorting run quickly.