joethun/joetemulator

1. Project purpose

- Joe T Emulator is a browser-based multi-system game emulator frontend. Its job is to let users add ROMs, organize them, fetch artwork, and launch games entirely in the browser.

2. Primary runtime boundary

- The core application runs client-side in the browser. The README explicitly says ROMs and save states stay local, so the app’s main architectural boundary is between the browser UI and external asset/services, not a backend API.

3. Emulation engine integration

- The emulator functionality is provided by EmulatorJS. This is the main execution engine for running games and supporting the wide range of systems listed in the README.

4. Library and game management layer

- The app includes a game library workflow: users add one or multiple ROM files, assign a system, optionally rename entries, and then launch them from the library. This implies a catalog/index of user-imported games maintained locally in the client.

5. Metadata and cover art flow

- Cover art is fetched automatically from thumbnails.libretro.com using hashing or, if needed, a title-based fallback. This is the main external data dependency and affects the library presentation layer rather than gameplay.

6. User input and import paths

- Games can be added through a sidebar “+” action or by drag-and-drop onto the page. That makes file ingestion a key UI subsystem, with multi-file import and per-game assignment steps.

7. Local customization

- Users can override artwork through a context menu and can rename games during import. This suggests per-item metadata editing stored locally alongside each ROM entry.

8. Storage model

- Because the app keeps ROMs and save states in the browser, persistence is likely client-side storage rather than server-side accounts or databases. This is an important architectural constraint: the user’s library is tied to the browser/device unless exported elsewhere.

9. Supported platform breadth

- The supported systems span consoles, handhelds, arcade, and computer platforms. Architecturally, that means the app is a multi-core frontend that routes each imported game to the correct EmulatorJS-supported system configuration.

10. Deployment surface

- The app is hosted at a Netlify URL, which strongly suggests a static web deployment model. The hosting layer likely serves the frontend assets only, with runtime behavior remaining in the browser.

11. No evidence of a traditional backend

- Nothing in the README indicates authentication, remote storage, server-side game indexing, or API-driven gameplay. For an architecture diagram, the safe assumption is: frontend app + external cover-art source + embedded emulation engine.

12. Diagram-friendly summary

- The key components to draw are: browser UI for library management, local browser storage for ROMs/saves/metadata, EmulatorJS as the emulation engine, and thumbnails.libretro.com as the external artwork service, with Netlify as the static hosting entry point.