Difference between revisions of "Compo4AllSDK"
(→SC Exec Return Values) |
(→Getting the execution info) |
||
(2 intermediate revisions by the same user not shown) | |||
Line 49: | Line 49: | ||
- hi -> the actual score number (for single-score style of games); TBD for time-attack, and other kinds of games | - hi -> the actual score number (for single-score style of games); TBD for time-attack, and other kinds of games | ||
- time -> the epoch time the event occured | - time -> the epoch time the event occured | ||
+ | |||
+ | === Getting the execution info === | ||
+ | |||
+ | The execinfo request will get you some details so you can actually run the application needed for a given game. The url form is: | ||
+ | |||
+ | Example: skeezix.wallednetworks.com:13001/execinfo_1/microbes/pandora | ||
+ | |||
+ | Example return: | ||
+ | - command_line_add": "" | ||
+ | - "file_dependancies_hint": "", | ||
+ | - "last_known_filename_hint": "microbes1.0rel2-1.pnd" | ||
+ | - "pnd_unique_id": "microbes.wb.mainapp" | ||
+ | - "type": "standalone" | ||
+ | - "last_known_appdata_hint": "microbes" | ||
+ | |||
+ | File dependancies could be things like "roms/dkong.zip" for a MAME dependancy, say. | ||
+ | |||
+ | Command line add could be: "--c4a --game foo" or whatever the application needs to tell it we're running from a c4a frontend. | ||
+ | |||
+ | The actual invocation could be done a number of ways, such as by using pnd_run or pnd_run.sh directly; you can use libpnd (built into the firmware) for all the heavy lifting .. it has utility functions for most everything you need. | ||
+ | |||
+ | Some quick off-memory pseudocode follows-- though its so close it would nearly compile: | ||
+ | |||
+ | <code> | ||
+ | Now, libpnd gives you everything you need to run stuff, but you have to call a few functions.. its not all rolled into one. | ||
+ | |||
+ | Why? | ||
+ | |||
+ | Because it lets you be efficient; your steps are usually.. | ||
+ | i) Ask it to find pnd_run.sh <- you can skip it, and use the firmware path if you want | ||
+ | ii) Ask it for a path set from config <- you can skip it, hardcode it if you like: the fw conf is: | ||
+ | /media/*/pandora/apps:/media/*/pandora/desktop:/media/*/pandora/menu:/usr/pandora/apps | ||
+ | - you feed that to the discovery function | ||
+ | iii) Ask it to run a discovery (return all apps within a path set) | ||
+ | --> keep this value; it returns a 'box', a linked list, save it so that you don't have to re-discover for every run; discover once, and then you are run-instantly next run | ||
+ | iv) for loop over the result list, looking for unique-id match | ||
+ | v) ask libpnd to run the entry you found (just pass the box pointer into the run function) | ||
+ | |||
+ | Its pretty easy for me anyway :) All you need is steps 3-5. | ||
+ | |||
+ | If I roll you a utility 'run the damned pnd' function, it'll be doing all that stuff every time... pretty inefficient. | ||
+ | |||
+ | The code would be like this: | ||
+ | |||
+ | Given char *my_unique_id that you know from the server. | ||
+ | |||
+ | #include "pnd_pxml.h" | ||
+ | #include "pnd_utility.h" | ||
+ | #include "pnd_conf.h" | ||
+ | #include "pnd_container.h" | ||
+ | #include "pnd_discovery.h" | ||
+ | #include "pnd_apps.h" | ||
+ | |||
+ | // run a discovery | ||
+ | pnd_box_handle g_active_apps = NULL; | ||
+ | char *searchpath = "/media/*/pandora/apps:/media/*/pandora/desktop:/media/*/pandora/menu:/usr/pandora/apps" <- from conf file! | ||
+ | |||
+ | g_active_apps = pnd_disco_search ( searchpath, NULL ); <- keep this value for the life of the frotnend session | ||
+ | |||
+ | if ( ! g_active_apps ) { | ||
+ | printf ( life is hell ) | ||
+ | return ( sucks ) | ||
+ | } | ||
+ | |||
+ | pnd_disco_t *a = pnd_box_get_head ( g_active_apps ); | ||
+ | void *nexta = NULL; | ||
+ | |||
+ | while ( a ) { | ||
+ | nexta = pnd_box_get_next ( a ); | ||
+ | |||
+ | if ( strncmp ( a -> unique_id, my_unique_id, strlen ( my_unique_id ) ) == 0 ) { | ||
+ | // found disco-t entry, run it | ||
+ | |||
+ | ret = pnd_apps_exec_disco ( "/usr/scripts/pnd_run.sh", a, 0 /* options */, NULL ); | ||
+ | if ( ret ) ..... | ||
+ | |||
+ | } | ||
+ | |||
+ | a = nexta; | ||
+ | } | ||
+ | |||
+ | .. | ||
+ | |||
+ | Thats it :) | ||
+ | |||
+ | Now, the pnd_run.sh path might be wrong, I dont' sleep much :) | ||
+ | |||
+ | .... | ||
+ | |||
+ | Now, you want to pass args.. theres some params to pnd_apps_exec_disco() so you can pass it args, I think: | ||
+ | |||
+ | pnd_apps_exec_info_t extra; | ||
+ | extra.args = "--game foo" | ||
+ | then pass PND_EXEC_OPTION_INFO into the 'args' bit instead: | ||
+ | |||
+ | ret = pnd_apps_exec_disco ( "/usr/scripts/pnd_run.sh", a, PND_EXEC_OPTION_INFO /* options */, &extra ); | ||
+ | |||
+ | That should do it, but I'm going from memory. Still, thats pretty damned close pseudo-code... probably compiles ;) | ||
+ | </code> | ||
== Game Developer == | == Game Developer == |
Latest revision as of 00:27, 11 May 2013
Contents
Compo4All API Guide
Overview
All information from the server is transfered by the HTTP protocol, so you can use libraries such as libcurl to handle all that work. Information is passed using the JSON markup language
Launcher Developer
Getting the Games List
Sending a HTTP GET request to /curgamelist_1 will return you a list of games, and details of those games
The JSON response will be an array of dictionairies (one dictionairy per game.)
The dictionaries will include at least the following fields for each game:
- gamename -> the 'short name' of the game; for MAME, it is the driver name ('dkong') and not generally for display; it is a unique-id (unique within C4A) - longname -> the readable display name ('Donkey Kong') - status -> current status options include: - available -> show in frontends, available for scoring etc - active -> show in frontends (and highlight or in their own tab?), is actively in the ROT tournament or highlight right now (but is otherwise same as available) - wip -> do not show in frontend; available for scoring and functionality identical to 'active', but for developers to test their code prior to finalization - genre -> the 'type' of game (at a high level); current values are.. - platform - maze - runngun - shmup - strategy - ... we can add more - to be determined - field -> the 'kind' of game it is, the platform; current values are - arcade -> implies c4a-mame will be used - indie -> means standalone; it will contact c4a, but not be part of c4a-mame - TBD
Getting the Score Board
Requesting /json_1/(gamename) will return you scoreboard details
- You can also pull a simple HTML (ASCII) dump: skeezix.wallednetworks.com:13001/scoreboard_1/mspacman/ - Getting previous months can use backdating for both JSON and ASCII pulls; for example: skeezix.wallednetworks.com:13001/scoreboard_1/mspacman/201304/
The scoreboard is an array of dictionairies, one dict per score entry.
The dictionairies will include at least:
- shortname -> the player's shortname (initials) - longname -> the player's long name (display name) - hi -> the actual score number (for single-score style of games); TBD for time-attack, and other kinds of games - time -> the epoch time the event occured
Getting the execution info
The execinfo request will get you some details so you can actually run the application needed for a given game. The url form is:
Example: skeezix.wallednetworks.com:13001/execinfo_1/microbes/pandora
Example return:
- command_line_add": "" - "file_dependancies_hint": "", - "last_known_filename_hint": "microbes1.0rel2-1.pnd" - "pnd_unique_id": "microbes.wb.mainapp" - "type": "standalone" - "last_known_appdata_hint": "microbes"
File dependancies could be things like "roms/dkong.zip" for a MAME dependancy, say.
Command line add could be: "--c4a --game foo" or whatever the application needs to tell it we're running from a c4a frontend.
The actual invocation could be done a number of ways, such as by using pnd_run or pnd_run.sh directly; you can use libpnd (built into the firmware) for all the heavy lifting .. it has utility functions for most everything you need.
Some quick off-memory pseudocode follows-- though its so close it would nearly compile:
Now, libpnd gives you everything you need to run stuff, but you have to call a few functions.. its not all rolled into one.
Why?
Because it lets you be efficient; your steps are usually..
i) Ask it to find pnd_run.sh <- you can skip it, and use the firmware path if you want
ii) Ask it for a path set from config <- you can skip it, hardcode it if you like: the fw conf is:
/media/*/pandora/apps:/media/*/pandora/desktop:/media/*/pandora/menu:/usr/pandora/apps
- you feed that to the discovery function
iii) Ask it to run a discovery (return all apps within a path set)
--> keep this value; it returns a 'box', a linked list, save it so that you don't have to re-discover for every run; discover once, and then you are run-instantly next run
iv) for loop over the result list, looking for unique-id match
v) ask libpnd to run the entry you found (just pass the box pointer into the run function)
Its pretty easy for me anyway :) All you need is steps 3-5.
If I roll you a utility 'run the damned pnd' function, it'll be doing all that stuff every time... pretty inefficient.
The code would be like this:
Given char *my_unique_id that you know from the server.
- include "pnd_pxml.h"
- include "pnd_utility.h"
- include "pnd_conf.h"
- include "pnd_container.h"
- include "pnd_discovery.h"
- include "pnd_apps.h"
// run a discovery
pnd_box_handle g_active_apps = NULL;
char *searchpath = "/media/*/pandora/apps:/media/*/pandora/desktop:/media/*/pandora/menu:/usr/pandora/apps" <- from conf file!
g_active_apps = pnd_disco_search ( searchpath, NULL ); <- keep this value for the life of the frotnend session
if ( ! g_active_apps ) {
printf ( life is hell )
return ( sucks )
}
pnd_disco_t *a = pnd_box_get_head ( g_active_apps );
void *nexta = NULL;
while ( a ) {
nexta = pnd_box_get_next ( a );
if ( strncmp ( a -> unique_id, my_unique_id, strlen ( my_unique_id ) ) == 0 ) {
// found disco-t entry, run it
ret = pnd_apps_exec_disco ( "/usr/scripts/pnd_run.sh", a, 0 /* options */, NULL );
if ( ret ) .....
}
a = nexta;
}
..
Thats it :)
Now, the pnd_run.sh path might be wrong, I dont' sleep much :)
....
Now, you want to pass args.. theres some params to pnd_apps_exec_disco() so you can pass it args, I think:
pnd_apps_exec_info_t extra;
extra.args = "--game foo"
then pass PND_EXEC_OPTION_INFO into the 'args' bit instead:
ret = pnd_apps_exec_disco ( "/usr/scripts/pnd_run.sh", a, PND_EXEC_OPTION_INFO /* options */, &extra );
That should do it, but I'm going from memory. Still, thats pretty damned close pseudo-code... probably compiles ;)
Game Developer
Spaghetti Client
The Spaghetti Client can be downloaded from the thread, and you can easily submit scores by starting a process with the following command line (assuming sc is bundled in your working directory)
The paramater's vary by module;
An example for the 'scoreonly' simple module is:
./sc MODULE OPERATION GAMENAME PLATFORM SCORE
Platform: Currently 'pandora' should be specified
SC Modes
Mode | Description |
---|---|
so | Sends the Score only |
SC Operations
Operation | Description |
---|---|
push | Sending data to the server |
pull | Get data from the server (not implemented) |
SC Exec Return Values
Value | Description |
---|---|
0 | All seemed well |
-1 | General error (such as bad arguments to sc); maybe failure to get RAM; possibly a problem with plugins (scoreonly module submissions.) |
-2 | Could not write file that was pulled; coudl not find player profile |
-3 | For a file dependancy (such as MAEM ./hi file), file could not be found/opened |