Closed hizzlekizzle closed 1 year ago
Howdy! I'd like to suggest:
Follow-up: I've been editing the forums thread OP to fully take into account your items 1 and 2 here. Also I added information from the retroarch db spec, per bparker06's suggestion. I also looked through EmulationStation's basic GameList XML spec and added a few possible tags from that list.
Items 3-5 are more of a user interface thing, and seem like a later phase of the work. I'm glad to bring them over to the forum thread too.
Unless this Issue has further activity, see you in the forums: https://forums.libretro.com/t/proposal-for-playlist-file-format-v2/
This has all been completed in the JSON playlist format, so I'm going to close this.
@bparker06 has graciously offered to write a playlist-creation utility based on a new playlist format. This issue is to discuss what this format/spec should entail.
Extensibility - one of the biggest issues with the current playlist format is the reliance on line numbers, which means nothing can be added onto it. I think the new format needs to be markup like XML or JSON (something that we can already parse without adding another dependency) so if we decide to add more functionality at a later date, it won't break the format.
Per-entry icon/thumbnail paths - the current method of making the images' names match the game names is cumbersome. The playlist itself could use an icon, as well, so they don't need to follow our naming conventions to avoid the black box syndrome.
Sorting? - I know that's what the 'cursors' were intended for, but it would be really nice to be able to sort by various metadata, like publisher or date of release or genre. Is that something we want here?
Core selection - with the current format, once you load a game with a core, it's stuck with that core forever unless/until you delete the whole playlist and rescan. I'm not sure how best to avoid that while still allowing a game to use a specific core when desired.
Duplicate entries? / watch directories? - I'm personally okay with the current 'delete and re-scan' workflow, but I know this is something others have requested. Dunno how feasible it is, though.
What else do we need/want? Are there any other frontends that do something smart that we should emulate? @fr500 @RobLoach @kivutar
Feel free to comment or invite other interested parties into the discussion.