Table of contents
FlashGames: A static shell around a Flash runtime
FlashGames preserves small Flash games in a browser-facing collection. The page selects a SWF and hosts the Ruffle player. The game binary and the surrounding HTML interface remain separate pieces.
- Languages
- 1Code breakdown
- Documented components
- 2Explore modules
- Source documents
- 1Read the instructions
Repository languagesHTML 100%1
Shares calculated from GitHub Linguist bytes.
| Language | % | Bytes |
|---|---|---|
| HTML | 12,166 |
1. Overview
1.1. Why it exists
Preservation archive of early 2010s ActionScript/Flash game creations with self-contained assets.
1.2. Best fit
Digital preservation and retro gaming nostalgia.
2. Use cases
A browser page that replays three Flash games from 2010 through the Ruffle emulator, with no plugin needed.
- Pick a game from the list
- Player
The #swfSelector drop-down in index.html lists Tag, Ricochet Kill and Ballon, each with a short description.
- Play a SWF in the browser
- PlayerRuffle emulator
loadSWF() creates a Ruffle player with RufflePlayer.newest() and loads tag.swf, ricochet kill.swf or jeux.swf into #swfContainer.
- Open a game by URL hash
- Player
updateHash() writes the game key into the URL hash, and the load and hashchange listeners reload that game, so a link like #tag opens it directly.
- Run the collection locally
- PlayerRuffle emulator
The README says to clone the repository and open index.html; Ruffle is loaded from unpkg, so a network connection is still needed.
2.1. Scenario: Replaying Ricochet Kill from a shared link
- Open https://antoinebou12.github.io/FlashGames/ (or index.html from a clone).
- The page loads the first game, Tag, because no hash is set.
- Choose Ricochet Kill in the Select a Game list; the URL becomes #ricochet_kill.
- Ruffle loads ricochet kill.swf into the black game area and the description bar updates.
- Play with the mouse, then copy the URL to send someone straight to the same game.
Files readREADME.mdindex.html
3. Try it
Address published in the repository README. The page opens in a sandboxed frame, only when you ask.
https://antoinebou12.github.io/FlashGames/4. Getting started
These commands come from the repository documentation. They were not run during this review.
5. Repository references
Excerpts from the repository’s guides, in their original language. Links open the inspected source revision.
Development and contributions
5.1. 🤝 Contributing
README.md
Contributions to this project are welcome! Here’s how you can help:
- Add More Games: If you have preserved Flash games that you’d like to add to this collection, please submit a pull request.
- Improve the Interface: Enhancements to the game selection UI are always appreciated.
- Documentation: Help improve this README or add game-specific instructions.
- Report Issues: If you encounter any problems with the games or the Ruffle integration, please open an issue.
6. Features and components 2
- Selection and runtime
- index.html includes the Ruffle script, a game selector and a player container. Selection updates the page state before loading the chosen SWF. Styles and icons come from CDN assets rather than a local frontend build.
- Preserved game files
- The repository stores the SWF files alongside the page. Ruffle supplies the browser-compatible execution layer; the page does not rewrite the games into JavaScript source.
7. Architecture
Expand a component to follow its connections, or explore the full diagram.
Game selector
Static page state
- From Game selector
- To Ruffle player
Ruffle player
- From Static page state
- From Selected SWF
Selected SWF
Mermaid Interactive diagram
System overview of the components and connections verified in the repository.
flowchart LR
n0["Game selector"]
n1["Static page state"]
n2["Ruffle player"]
n3["Selected SWF"]
n0 --> n1
n1 --> n2
n3 --> n2
Text version of the diagram
- Game selector → Static page state
- Static page state → Ruffle player
- Selected SWF → Ruffle player
Follow one path through the code
Trace the selector’s updateHash handler toward the player container. This is a useful distinction when debugging: a selector problem belongs to the page, while unsupported game behavior may belong to the runtime.
8. Technical dossier
Built from the source at commit 7ee14ee (1 files). Each item comes from a pattern match in the code, so open the linked file before relying on it.
8.1. Layers and modules
Folders are sorted into layers by name, from the user interface down to data access. Because the sorting uses names only, the diagram says nothing about calls between layers.
Mermaid Layered view
flowchart TB
subgraph L_presentation["Presentation"]
direction TB
presentation_0["(root)<br/>1 file"]
end
| Module | Layer | Files | Types | Extensions |
|---|---|---|---|---|
(root) | Presentation | 1 | 0 | .html |
8.2. C4 model
From system context to code declarations. Each level reflects the available source evidence.
UML 1 · System context
The widest C4 view: who uses the project and which outside systems and data stores it relies on. Rendered with uml-mcp.
PlantUML source
@startuml
!include <C4/C4_Context>
LAYOUT_LEFT_RIGHT()
System(SYS, "FlashGames", "FlashGames preserves small Flash games in a browser-facing collection")
@enduml
Level 2: the available sources do not support this view.
UML 3 · Components and layers
Modules grouped by source-layer classification. Boundaries show organization, not runtime isolation or call relationships. Rendered with uml-mcp.
PlantUML source
@startuml
!include <C4/C4_Component>
LAYOUT_TOP_DOWN()
System_Boundary(SYS, "FlashGames") {
Boundary(L0, "Presentation", "layer") {
Component(M0_0, "(root)", "HTML", "1 files")
}
}
@enduml
Level 4: the available sources do not support this view.
8.3. CI/CD pipeline
No CI/CD pipeline in the repository. The code is built and run by hand, as described above.
8.4. Deployment
Mermaid Deployment diagram
flowchart LR
repo[("GitHub repository")]
local["Local machine"]
repo -->|"clone and run"| local
The repository has no Dockerfile, Compose file or hosting configuration, so the code runs on the machine that clones it.
The available sources do not document the remaining sections.
9. Reference
1 / 1 eligible files read (6 in the tree); 0 oversized, 0 failed reads and 0 syntax diagnostics.
What the scan covers
Known dependency/build folders, credential files and binaries are excluded. The scan covers READMEs, recognized manifests and parser-supported source files.
Linguist statistics cover the whole repository and may include other languages.
11. Files to read 2
12. Glossary
Repository
The versioned source files, configuration, and history of a project.
README
The repository’s entry document, usually covering its purpose and initial setup.
Dependency
A library, tool, or service that another component needs to build or run.
Container
An isolated process environment created from an image. Persistent data needs storage outside the container’s disposable filesystem.
CLI
A text interface in which commands and arguments select operations. Exit codes let scripts detect success or failure.
Build
The steps that turn source files and dependencies into a runnable program or distributable artifact.
13. References
- antoinebou12. (2026, November 5). FlashGames. [Software repository] github.com.
- antoinebou12. (2026, November 5). FlashGames: README. [Repository documentation] github.com.
- antoinebou12. (2026, November 5). index.html. [Source file] github.com.
- antoinebou12. (2026, November 5). README.md. [Source file] github.com.
- Boucher, A. (2026, October 23). FlashGames: A static shell around a Flash runtime. [Project article] antoineboucher.info.
- Boucher, A. (2024, January 1). RetroArch Web Games. [Project article] antoineboucher.info.
Sources without a publication date show the date they were last checked, November 5, 2026. File links retain the inspected revision where available.