What is the best practice of submitting scores to the c4a server (from a game developer's point of view)?
Should the game developer try to aggregate and cache scores and only submit the best one after a session (like NubNub does) or submit every new highscore (like Super Hexagon does) or only submit scores manually on the user's input?
Every one of these methods has some advantages and disadvantages and it's probably preference, but defining some "best practice" way would be a good idea I think.
This information should also be added to the
wiki.
I always figured it would be up to the developer .. it may vary by game; as long as any one game is consistent, that'd work (since cross comparison of scores between games makes no sense.) But as you say, maybe a set of guidelines? That sounds hard... Anyway, my thought was always 'end of session'; for arcade games it was sending up a whole table, and most people didn't mind if they.. achieved 10 entries onto the board of 5 slots, and then at end of session that 5 slot board was sent up and integrated; the fact they'd lost 5 of their scores wasn't important, since they'd beaten them off anyway. However, if you wanted higher resolution, and every single score posted.. server doesn't care obviously. So in this case, it leads to...
Pseudo-related, its probably not great to spend a lot of time working on offline caching of scores (since every game doing it independantly coudl create bugs and such), but obviously I've not gotten off my rear to add it into the official 'sc client'; but thats where it should be
(without putting thought to it, I'd just figured that since we decided we wanted to do it, then in the c4a-mame appdata dir (which is really the c4a appdata dir as well, despite the name), putting in a queue dir. Something like 'QUEUEDIRname/gamename/timestamp-random.q' or something; then when sc gets an order, instead of doing it live, add it to queue dir, and then invoke a routine that iterates the q dir and feeds them up in order to the server. Not too big a change, but should automate things nicely.)
Perhaps sc-client needs a 'queue only' option on the command line, and a 'flush queue' option; this wya, for performance, you could send -queueonly and it'd stick it in the dir withotu hitting the serever (taking a few seconds due to pandora slower wifi say), and then at the end or controlled time (end of session shell script wrapper, say), invoke the 'flush queue' option and have it due its business; or let c4a-launcher do it. HMM!
Anyway, adding queueing to 'sc client' may be the way to go.. to safely handle offline play, and to allow performance enhancements for higher resolution score submission...
jeff