ROM community addon idea for homebrew playing/development

Eggy

Well-known member
Licensed customer
I’m toying with the idea of taking a standalone project I’ve been working on outside XenForo and turning it into a fully integrated XenForo add-on.

The concept would be a browser-based retro gaming platform supporting systems such as Game Boy, Game Boy Color, GBA, NES, SNES, Mega Drive/Genesis, N64 and potentially others depending on emulator support.

Users would load their own legally owned homebrew ROMs locally. ROM files would never be uploaded to or stored on the server. Instead, the add-on could identify games using ROM hashes and build XenForo community features around them, including:

  • Rankings and global leaderboards
  • Achievements
  • Cloud save states
  • Save states linked to a ROM hash
  • Hash verification when restoring a save, ensuring it is being loaded against the correct ROM
  • User game libraries without actually storing the ROM itself
  • Potential recorded input leaderboards / community statistics and challenges

The important part is that it would be designed for people using homebrew, public-domain ROMs, their own lawful backups, or content they otherwise have the rights to use.

So rather than XenForo hosting games, it would essentially provide the community, account, ranking and cloud-save layer around a multi-platform emulator.

It’s still something I’m experimenting with, but I think the XenForo integration could make it quite interesting.

What do you guys think of the concept?

1786341055948.webp


1786341034591.webp


1786341082505.webp


1786341131254.webp


1786341147663.webp


1786341191081.webp



1786346185837.webp


1786346221824.webp


1786402725231.webp


1786402757158.webp


1786402783657.webp
 
Last edited:
I think I must have been in the pub when role playing games came along and became popular; because I don't get them, and have never played one. Have I missed out. Are they better than the pub?
 
Using legally owned ROMs makes this project feel useful and responsible. @slope2

Yep, that's exactly the approach I wanted to take with it.

I deliberately designed it so the ROMs themselves are never stored by the system. It only keeps a small partial hash so it can recognise the same ROM later for things like cloud save/load. Basically, the save is tied to that ROM. If the ROM doesn't match the partial hash, the save won't load against it, and neither will the game session.

My standalone version was already mobile friendly too, which I think is one of the better parts of the idea. You could be playing on your desktop or laptop, save your progress, go out, then open it on your phone and carry on from where you left off.

I also originally built autosaving into it every few seconds, and that's still part of the architecture. I found that really useful because if the browser, emulator or device freezes, you shouldn't lose much progress. It doesn't keep stacking autosaves either because that would get messy pretty quickly. Each new autosave simply replaces the previous one.

My original standalone version also allowed you to import your own save files from native/local emulator software. So if you'd already been playing a game elsewhere, you could bring that save across and pick up from where you left off. I'd expect that to remain part of the XenForo version as well.

I've actually managed to integrate the core idea and features into XenForo already, so technically the concept is working as shown in my uploaded images. The bigger question for me now is whether I can actually sell it as a XenForo resource.

From my understanding it doesn't violate the DMCA because I'm not supplying, hosting or distributing ROMs, but I still don't know exactly where XenForo would stand on something like this under their own resource rules and terms. I've reached out to them anyway because the last thing I want to do is finish the whole thing off, get it ready for release, and then be told it isn't suitable to list as a resource.

But above all, I've been wanting to move all of my projects over to XenForo for my own personal use, rather than having everything split across standalone systems.

For me, that's where XenForo really becomes useful. Everything can sit under the same structure and permissions, inherit the same hierarchy, and most importantly use one account across every project instead of making people register and log in all over again.

From a user point of view, I just prefer having everything tied together. One account for all of it, no jumping between different systems, and everything I've built sitting in the same place.
 
Last edited:
My first thought with everything locally stored immediately went to how easy it would be to manipulate the games.

Hight scores, achievements, completions, etc would likely be open to manipulation locally, resulting in your platform seeing that User1 has completed 5,000 games, has every achievement and the top score on all of them.

Not sure if its possible to combat that through the platform, but its what popped into my head.
 
This was the original standalone version I built, and I expect the rewards and trading side of the XenForo version to end up pretty close to this. The main difference will be fitting it properly into XenForo’s own styling and hierarchy rather than keeping the standalone layout.

1786368397170.webp


1786368404144.webp



1786368412383.webp


1786368420841.webp


1786368429204.webp


1786368436149.webp
 
My first thought with everything locally stored immediately went to how easy it would be to manipulate the games.

Hight scores, achievements, completions, etc would likely be open to manipulation locally, resulting in your platform seeing that User1 has completed 5,000 games, has every achievement and the top score on all of them.

Not sure if its possible to combat that through the platform, but its what popped into my head.

Sorry I had to take a minute to think of a reply. That's a fair point, and it's something I did think about when I originally built the standalone version.

Achievements were probably one of the more rushed parts of it compared to everything else, so I'd definitely want to go back over them properly for the XenForo integration.

There were already a few abuse protections in the backend though. It didn't just blindly accept everything from the browser. Sessions could be marked as suspicious, there was a separate flagging system for dodgy-looking sessions, achievements were tied to actual recorded events, and the same achievement couldn't just keep being awarded over and over.

I also had things like qualifying play time in mind rather than simply counting somebody opening a game or refreshing the player repeatedly. Guests weren't able to earn achievements either.

That said, I wouldn't pretend the original system was impossible to manipulate. With something running in a browser you're always going to have to assume somebody will eventually try.

For the XenForo version I'd want to tighten that side of it up quite a bit. Cooldowns, sensible limits, server-side validation and looking for obviously impossible patterns would all be part of it. If somebody suddenly managed to unlock 40 achievements in two minutes, complete thousands of games or submit ridiculous statistics, that should be treated as suspicious rather than immediately being accepted as legitimate.

So yeah, the foundations for abuse prevention were already there, but achievements are definitely one area I'd want to revisit and harden properly as part of the XenForo integration rather than just porting the old system over as-is.
 
My first thought with everything locally stored immediately went to how easy it would be to manipulate the games.

Hight scores, achievements, completions, etc would likely be open to manipulation locally, resulting in your platform seeing that User1 has completed 5,000 games, has every achievement and the top score on all of them.

Not sure if its possible to combat that through the platform, but its what popped into my head.

High scores and leaderboards are probably the main thing I'd need to tighten up because anything coming from the browser can potentially be messed with, so I'd want the system checking the actual session before accepting it. Achievements are different because they're not built into the ROMs at all, ROMConsole only knows which game you've loaded from the hash, so it can't just claim you've completed a game unless there's something it can genuinely verify.
 
Changes that would be expected. The player will not be embedded in this XenForo integration it will have a player.php

1786409477741.webp


1786409511035.webp
 
Here's a live test with a homebrew ROM

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.
 
It looks incredible Eggy.

Presumably for leaderboard and achievement purposes, the administrator would have to add "support" for a ROM via some kind of hash whitelist?
 
It looks incredible Eggy.

Presumably for leaderboard and achievement purposes, the administrator would have to add "support" for a ROM via some kind of hash whitelist?

There aren’t game uploads or game-specific achievements being built by the admin.

The ROM stays with the user. The system tracks what they’re doing while it’s running, things like inputs, button presses, play time and session activity. That tracking is what the leaderboard and achievement system works from.

When you open a ROM, ROM Console hashes it and ties that hash to the autosave in MySQL, so when you come back later it verifies the ROM against that saved hash before loading the save.
 
It probably would be possible to build achievements around specific in-game ROM behaviour, but I deliberately don’t go that far because it could create DMCA/copyright issues, which is why the hashing is kept strictly to identifying the ROM for read/autosave verification.
 
1786423746936.webp


1786423768840.webp


1786423784985.webp


This is for people who own homebrew and want people to just click and play, and are legally allowed to store games on their server/host

1786423804977.webp


1786423835415.webp


1786423929585.webp


1786423954672.webp


More settings are being made, but this is an example of the admin side.
 
I’ve designed it so it isn’t tied to the style I use; it inherits the hierarchy of whatever style the site owner has set in XenForo, which I think is more important than forcing a separate style on the console. Tested here with XenForo default light.

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.
 
Back
Top Bottom