Add compatibility list

[JayFoxRox]

We should have a compatibility list.
This issue is more about the user-facing side of things (for displaying the compatibility list);
we'll also need a backend eventually (including a frontend for data entry), but this will be more complicated to design, so it will be a separate discussion.

For now, we have some resources, like http://xboxdevwiki.net/XQEMU#Compatiblity_list (see linked Google Sheets), which can act as a backend.

There's also some (mostly outdated and broken) tools at https://github.com/JayFoxRox/xbox-game-databases which can be used to retrieve game information.
Ideally, we'll extend Wikipedia so it's compatible with our database, so we can also map between our entries, and Wikipedia articles MobyGame seems to be a good page with a lot of useful information, and we can find Wikipedia articles through MobyGame game-pages. Same for redump and other websites.

[JayFoxRox]

I've prototyped a compatibility list here: JayFoxRox#1

I currently have no interest continuing to work on it. I don't like web-technology and I'm busy working on the emulator and other ecosystem parts.

With a bit of work, we could at least visualize John GodGames list.

[mborgerson]

I'm personally against using the xboxdevwiki as a compatibility tracker for XQEMU. While information about the various emulators available merits a wiki article(s), I don't think we should depend on it for project tracking.

I think the ideal solution is for someone to build us some sort of a simple web app that can manage a database, cross-reference unimplemented features with games which require the features (associate games with open issues on GitHub), and allow users to easily help provide test feedback/screenshots/etc.

The Xenia project seems to use a GitHub repository for tracking game status. I'm not sure yet if this is the ideal solution for us, I'll need to think on it a little more. -- Off the top of my head we could abuse GitHub labels... create a label for each game and apply it to issues, but I think this could get noisy in the GitHub web interface. A special purpose-built web app could do this cleaner. Maybe a web app using the GitHub API is the best of both worlds.

[JayFoxRox]

I'm personally against using the xboxdevwiki as a compatibility tracker for XQEMU.

As mentioned in the first post: This is not what this issue is about. This discussion should be about how we present already stored data. Data can be stored whereever: github, wiki, google sheet, sql database. However, we'll also need a frontend which hides this complexity from end-users and displays data properly (on our website or in a launcher).

Converting data between backend formats is easy. Changing frontends is not so easy and needs careful design. It also has implications on what information the backend has to store.

I also agree: A wiki is a bad backend, however, that + the sheet are temporary solutions with 900+ test results, with a history of almost constant testing for ~3 years or so. So we have enough data to focus on a frontend, and we can deal with backend (storage / data-entry) later. The existing test results even include technical details, so we have many options in the frontend design.

I think the ideal solution is for someone to build us some sort of a simple web app that can manage a database, cross-reference unimplemented features with games which require the features (associate games with open issues on GitHub), and allow users to easily help provide test feedback/screenshots/etc.

The existing backends already do that (by keeping track of assert lines). This issue is about how we can display such information to users.

I don't think getting too technical with users is a good idea. Users typically only care about:

• Does it work?
• What happens if I try to run it?

My proposal answers both question.

Developers would use a different frontend to access the same data, similar to how xqemu-compatibility-inspector.py already does it (link in first post).

The Xenia project seems to use a GitHub repository for tracking game status. I'm not sure yet if this is the ideal solution for us, I'll need to think on it a little more.

Off-topic, because this issue is supposed to be about the frontend; but this is a backend / data-entry suggestion.
(My opinion regarding GitHub as backend: Contributing to the list requires a GitHub account, which end-users shouldn't even own in the first place. So GitHub is a bad backend choice. Labels in particular are risky as GitHub might radically change in the future)

I also already looked at other projects, such as Dolphin, Citra, PCS2X and Xenia before creating this issue. I have also been very active in the user-support of Citra for many months. I believe I've managed to implement most of what users expect from a compatibility list in my proposal above.

Talking about the Xenia compatibility list frontend, I have the following notes:

• First item in list is a cryptic title-id which confuses users.
• It's very vague with terms like "intro", "gameplay", "playable".
• It's confusing with terms like "crash-OBSOLETE" vs "nothing" (what's the difference, and what does "OBSOLETE" mean?).
• Sends end-users to GitHub, which is something I passionately hate as I made only bad experiences with it (users asking dumb questions / commenting weird things on PRs / posting memes and treating it like a forum for off-topic discussions).
• Takes very long (too long) to load because it's implemented in Javascript, fetching data from GitHub.
• Uses Microsoft artwork by hotlinking.

The existing proposal in my post is already much better in many ways, in my opinion (although it lacks a detailed log as provided on their issue tracker).
My proposal more clearly answers the users question I've mentioned above, and most users probably won't even need a detailed log.

What I do like about the Xenia list is the "updated" date information, and it's something that should be integrated. My list only shows "version-date", which is a bit vague.

---

Something I wanted to add for this issue in general:

Once we have a compatibility list, we should change "Please visit the issues page" on the "Welcome" page to only refer users to the compatibility list.

End-users should never have to know about development details, and even less should they attempt to report bugs or ask for help on GitHub.

[ajburley]

Your PR has been open more than one year and hasn't been accepted...I know you said you don't have time to work on it more, but it looks good to me as a starting point (MVP); what changes are needed before the PR can be accepted? I know you listed some changes needed in the PR itself, but these seem like minor changes and most if not all are not needed for an MVP?

[ajburley]

PS: Have we confirmed that the xqemu.com host supports Python? And does it support other types of code like PHP, Java etc?