Gameboy Development Forum

PinoBatch wrote:

Help users find what they want
The index file would need to have some sort of category scheme so that the user doesn't have to scroll through a thousand unrelated things. How might this be organized?

I'd say, divide it into categories and tags. Categories are broad and each ROM can only have one category. Tags are more specific, can be applied more liberally, and a ROM can have any number of tags. Please allow for categories to include non-games, for example demos and music compilations.

PinoBatch wrote:

Display enough information about each work
This isn't much of a problem for an emulator that runs on a PC or a modern console. But if someone decides to push it a little farther than emulators to make an Internet-connected cartridge for the console, another problem I foresee is that decoding PNG, the Internet standard format for indexed color images, might pose a problem for a CPU that weak. Screenshots might have to end up scaled down, color reduced, and in some specialized format.

Anything that is a screenshot of something running on the actual hardware could theoretically be reproduced on the same hardware. However, that might require non-trivial hardware tricks, like scanline or even mid-scanline perfect register manipulation. Also, around 6k of data per image (worst case for a GBC game including both tiles and map data) might be on the high end for what can be delivered while maintaining a smooth user experience.

Perhaps it would be a good idea to define a format for miniature images that would be shown in a subset of the screen for this particular purpose. This image would then fit into a predefined UI for the GB screen. This would require manual artistic work though, and is likely to be a bottleneck in the project. (Assuming it's a goal of the project to catalog existing homebrew.)

PinoBatch wrote:

Ensure someone doesn't upload something that could get the server operator in trouble
The browser could be set up such that the user can add a repository's base URL. Then the repository administrator decides whether to accept it or send it back for changes. There'd need to be some sort of means of submission for this.

I'm unsure what "repository" and "it" mean in these sentences. I can interpret the first sentence in two ways:
1) The user is free to add any repository they want, to their local copy of the browser software, essentially like how an RSS feed works online. But this interpretation clashes with the second sentence.
2) ROM creators can submit a repository containing their project. It is then vetted by the administrators. This sounds like the more likely interpretation. However, this also means that the browser relies on those maintaining the main repository to both keep it online and to trust them to curate content correctly.
For this reason, it may be a good idea to separately define the database format and guidelines for content curation, and the official repository. It may also be a good idea in this case to define different terminology for the type of channel used by a homebrew author to distribute their works, and the type of channel that is used for end user distribution of curated content.

Is this project intended to be a completionist project, similar to a GoodSet, or mainly to promote actively/recently developed homebrew projects?