I remember watching The Social Network for the first time and coming away completely obsessed with the idea of building something people would use every day.
Facebook was already enormous, but it wasn’t only the scale that fascinated me. It was the idea that a website could become part of someone’s routine — the first thing they opened on their laptop, a place where people created profiles, shared interests, competed, talked and kept coming back.
I was a teenager, so naturally, my ambition was to build the next website used by millions.
I opened Notepad and started filling it with ideas. It was almost like writing a blog post to myself: plans for a platform people would visit whenever they opened their browser.
That mindset eventually became MarioRuns.
I was an avid gamer and particularly fond of the games I had grown up with. One day, I stumbled across someone speedrunning Super Mario 64 and was immediately hooked.
I started looking for rankings, guides and resources, but everything was scattered across forums, videos and a fairly messy Google Sheet. There was no polished, central place dedicated to the game.
Then it hit me: why not build one?
A website with leaderboards, runner profiles, guides, resources, streams and forums. Everything a new or experienced runner might need, all in one place.
MarioRuns was born.
It eventually received more than one million hits.
Then the speedrunning world changed. Speedrun.com arrived, the community moved towards one central platform, and MarioRuns was eventually taken offline.
For years, it remained part of my past.
More than a decade later, I watched The Social Network again.
This time, the film did more than entertain me. It reminded me of the teenager who stayed up late writing down ideas, convinced he could build something people would care about. It brought back the excitement of creating MarioRuns and watching it become a real community.
That rewatch lit the fire again.
I wanted to bring MarioRuns back.
The problem was that I had allowed the original hosting, code and resources to disappear. The most complete remains of the website existed inside the Internet Archive’s Wayback Machine.
What began as an attempt to recover an archived website became a full technical rebuild involving Ruby scripts, archived HTML, API integration, PHP caching, cron jobs, local JSON datasets, search indexing, responsive data tables and extensive performance optimisation.
This is the story of how MarioRuns was created, why it disappeared and how I rebuilt it into a faster, cleaner and more reliable website than the original ever was.
Looking for something in particular? Jump to one of the following sections:
When I first became interested in web development, I was fascinated by platforms rather than simple brochure websites.
I didn’t just want to create a homepage and contact form. I wanted to build something people participated in.
The original idea was effectively a social network: users would create accounts, build profiles, communicate and return because the content was generated by the community itself.
When I discovered the Super Mario 64 speedrunning scene, I found a much more focused version of that opportunity.
The community was growing, but information was scattered between spreadsheets, forums, videos, chat rooms and personal pages. There was no single, polished platform dedicated to the game’s leaderboards, runners and resources.
It felt like exactly the kind of community website I had always wanted to build.
MarioRuns launched in 2013 as a dedicated Super Mario 64 speedrunning website.
It was much more than a leaderboard.
The site included:
- rankings across the game’s main speedrun categories
- individual runner profiles
- a moderation system for reviewing and verifying submitted runs
- forums and community discussions
- guides and resources
- live Twitch streams embedded on the homepage
- a practice room containing training information
- user accounts and community features
At the time, there was no centralised leaderboard platform serving every speedrunning community. MarioRuns was built specifically around Super Mario 64 and the people playing it.
For a teenager building websites largely through experimentation, it became an unexpectedly serious project.
It eventually received more than one million visits.
That number mattered to me, but what mattered more was seeing the original social network idea appear in a smaller, more realistic form.
People were not simply reading pages. They were submitting runs, checking rankings, visiting profiles, posting in the forums and returning to see what had changed.
The website had become part of the community.
During MarioRuns’ lifetime, Speedrun.com arrived.
It provided a central platform where communities from thousands of games could maintain leaderboards in one place. It quickly became the new and exciting destination for speedrunning.
For a while, runners submitted times to both websites, although increasingly they chose Speedrun.com.
MarioRuns had also been built before APIs and structured integrations became central to the way I approached projects. The leaderboard data existed inside MarioRuns, but there was no clean public API that made it easy to synchronise with another platform.
I was also, admittedly, annoyed when MarioRuns data was scraped without anyone asking first, particularly because I had spent a huge amount of time manually watching and verifying hundreds of runs before building tools that allowed others to help.
But Speedrun.com solved a bigger problem, and it was clear where the community was heading.
Maintaining a separate manual leaderboard no longer made sense. Eventually, I took MarioRuns offline.
The domain later expired, and the website became part of the internet’s memory.
After rewatching The Social Network, I began wondering how much of MarioRuns still existed inside the Wayback Machine.
The Wayback Machine is a digital archive that captures and stores snapshots of websites over time. It allows people to revisit pages that have changed or disappeared, but it is not the same as having a complete website backup.
An archived site is made up of individual captures taken on different dates.
Some pages exist. Others do not.
A stylesheet may have been captured in one year while an image came from another. Internal links often point through archived URLs, and some assets are missing entirely.
Recovering a website this way is not as simple as clicking “download”.
Manually retrieving every page, image, stylesheet and script would have taken far too long, so I wrote a Ruby script to automate the process.
The script:
- queried archived MarioRuns URLs
- downloaded available pages and assets
- recreated the original folder structure
- removed Wayback Machine wrappers from URLs
- rewrote internal links to point to local files
- identified missing resources
- produced a usable local copy of the archived site
It felt less like restoring a backup and more like digital archaeology.
The script could recover what had been captured, but it could not recreate everything that once happened behind the scenes.
The original database, account system, moderation workflow and dynamic leaderboard logic were gone.
What remained was the shell of the website.
But that was enough to start.
Once the archived version was running locally, I had a decision to make.
I could attempt to recreate the original site exactly as it had been, including its account system, forums and submission process.
Or I could ask a more useful question:
What should MarioRuns be today?
Speedrun.com already handles accounts, submissions, moderation and the canonical leaderboard data. Rebuilding those systems would have duplicated working infrastructure and introduced unnecessary security and maintenance overhead.
However, one repeated complaint I found from runners was that browsing Speedrun.com leaderboards could feel slow.
That gave MarioRuns a new purpose.
Instead of recreating the original platform feature for feature, MarioRuns could become a focused alternative frontend: a compact, exceptionally fast way to browse Super Mario 64 leaderboards.
The goal changed from restoration to reinvention.
I retained the identity and history of MarioRuns, but rebuilt its technical foundation from scratch.
Building a static-first PHP architecture
The new MarioRuns uses PHP, JavaScript and CSS, but the visitor-facing experience behaves much more like a static website.
The key principle is simple:
Visitors should never have to wait for Speedrun.com.
A traditional implementation might request leaderboard data from the Speedrun.com API whenever someone loads a page.
That creates several problems:
- every page depends on an external service responding quickly
- API downtime can break the website
- rate limits become a concern
- large leaderboards take longer to process
- more visitors create more external requests
MarioRuns avoids this by separating data collection from page delivery.
An hourly cron job requests the latest leaderboard data from Speedrun.com and stores it locally. Visitors then read pre-generated JSON files directly from the server.
The flow is:
Speedrun.com API ↓
Hourly PHP cron job ↓
Local cached JSON files ↓
MarioRuns PHP pages ↓
Visitor
This means a visitor never triggers a live Speedrun.com API request.
Even if Speedrun.com is temporarily unavailable, MarioRuns continues serving the last successful dataset.
Processing the complete leaderboards
The five main Super Mario 64 categories contain thousands of runs:
- 120 Star
- 70 Star
- 16 Star
- 1 Star
- 0 Star
Each category also includes separate platform views:
- Nintendo 64
- Wii Virtual Console
- emulator
- all platforms
The cron process downloads each complete category leaderboard and then derives the platform-specific versions locally.
This avoids making unnecessary API requests for the same underlying data.
The system then:
- validates the returned JSON
- separates runs by platform and emulation status
- recalculates competition-style ranks
- preserves tied positions
- splits large leaderboards into pages of 100 results
- stores only the player records needed by each page
- writes files atomically to prevent incomplete cache files
- removes obsolete pages when a leaderboard becomes shorter
- records the time of the most recent successful refresh
Atomic writes are particularly important.
Each new cache file is written to a temporary location first and moved into place only after the complete JSON has been generated successfully.
That means visitors never receive a half-written leaderboard if the update process stops unexpectedly.
Recreating player presentation
MarioRuns uses Speedrun.com as its data source, but it does not simply display raw names and times.
The rebuild includes support for:
- account colour styles
- gradient usernames
- country flags
- console-region flags
- guest and anonymous runners
- verified and unverified status
- run comments
- video links
- platform labels
- relative submission dates
Run comments appear inside lightweight tooltips rather than expanding the table or forcing the visitor onto another page.
YouTube and Twitch links can also appear within those tooltips where appropriate.
These details make the leaderboard feel complete without making it heavy.
Instant player search
One of the most useful additions is the global runner search.
The cron process generates a compact local search index covering every main category and platform.
Typing a runner’s name searches that local file immediately. No remote API request is needed.
Results show the runner’s:
- category
- platform
- leaderboard position
- time
- run date
- country and platform region
- direct leaderboard destination
Selecting a result opens the correct category, platform and page, scrolls directly to the run and highlights it.
Without this feature, a visitor may need to choose a category, select a platform, estimate the correct page and search visually through dozens of rows.
With the local search index, the process takes seconds.
Weekly rank movement
MarioRuns also tracks weekly leaderboard movement.
Every Monday, the cron process creates a baseline snapshot. During subsequent hourly updates, each current rank is compared with that baseline.
The interface then displays compact markers such as:
▲5
▼2
NEW
The movement system works across both individual category leaderboards and the combined N64 World Rankings.
The implementation required more than simply comparing player names.
A runner can have separate personal bests on N64, Virtual Console and emulator. Some leaderboard variants may also contain similar records.
To keep every entry independent, MarioRuns creates a stable movement key using:
- the Speedrun.com player ID
- platform
- emulation status
- console region
- category variables
That prevents an emulator run from being incorrectly compared against the player’s N64 position.
N64 World Rankings
The new N64 World Rankings provide something Speedrun.com does not offer directly.
Each registered runner receives points based on their position across all five main N64 categories:
- 120 Star
- 70 Star
- 16 Star
- 1 Star
- 0 Star
First place earns 100 points, second place earns 99, continuing down to one point for 100th place.
The five category scores are combined to produce an overall ranking of the strongest all-round N64 runners.
Anonymous runs remain in their correct category positions, but they are excluded from the combined rankings because there is no persistent account ID that can safely associate an anonymous runner across multiple categories.
Each category result links back to the correct MarioRuns leaderboard page and highlights the exact run.
Fixing historical time precision
Older speedrun data is not always perfectly consistent.
Some runs include millisecond precision, while others were recorded only to the nearest second. In a small number of cases, a moderator comment confirms that a run was retimed to an exact .000 value, while the numeric API data contains only the whole second.
MarioRuns handles those cases carefully.
It does not blindly add .000 to every 16 Star, 1 Star or 0 Star run. That would invent precision for times that were never recorded that way.
Instead, .000 is displayed only when the run data or moderator comment explicitly supports it.
For example:
15:59.520
15:59.600
16:00
15:18.000
The goal is accuracy, not cosmetic consistency.
Designing mobile leaderboards properly
Large data tables are difficult to use on phones.
An early mobile version tried to fit the leaderboard into the available width by hiding columns. That made the layout smaller, but prevented visitors from accessing all the information.
The new approach keeps the complete table and allows horizontal scrolling.
The Rank and Player columns remain fixed while the rest of the data scrolls behind them, similar to a spreadsheet.
Visitors can swipe across:
- comments
- times
- dates
- platforms
- verification status
- run links
The mobile interface also replaces the desktop sidebar with compact platform and category controls.
This preserves the full leaderboard experience without forcing a desktop table into a narrow screen.
Performance shaped the entire build
Performance was not treated as something to improve at the end. It shaped the architecture from the beginning.
The current website uses:
- locally generated JSON
- hourly background updates
- Brotli and gzip compression
- long-lived browser caching
- versioned CSS, JavaScript and image files
- minimal first-party JavaScript
- partial leaderboard page updates
- pre-generated pagination
- no advertisements
- no heavy frontend framework
- no live API dependency during page views
When a visitor switches category, platform or page, JavaScript can request only the main leaderboard content instead of downloading and rebuilding the entire page.
Typical interactions transfer only a small amount of compressed data.
The result is deliberately uncomplicated: PHP renders the HTML, JavaScript enhances navigation and search, and the server completes the expensive processing before the visitor arrives.
It is fast because it was designed to be fast.
What the project taught me
Rebuilding MarioRuns reminded me that modern web development does not always mean adding more technology.
The original website attempted to own everything: accounts, submissions, profiles, moderation, forums, streams and leaderboard data.
The new version works because it understands what not to rebuild.
Speedrun.com remains the source of truth. MarioRuns focuses on presenting that data quickly and adding features that make it easier to explore.
The best technical decisions were often the simplest:
- cache remote data instead of requesting it live
- generate search indexes in advance
- use JSON files where a database is unnecessary
- make file writes atomic
- progressively enhance standard HTML
- preserve useful archived content without preserving obsolete architecture
From an old social network dream to a modern website
The idea started with a teenager writing in Notepad about building a website used by millions.
That ambition eventually became MarioRuns: a small social platform for a very specific community.
The original site disappeared when the internet and the speedrunning ecosystem moved forward.
Bringing it back was not about pretending nothing had changed.
It was about recovering the history, preserving the identity and rebuilding the technology around how the community works today.
MarioRuns is online again — not as a copy of its 2013 version, but as a faster, cleaner and more technically robust evolution of it.
After more than a decade, bringing it back felt like recovering a small part of myself too.
