Movie
Master

I started as a customer.

I found Robert Cravens selling personalized movie recommendations on Facebook Marketplace, bought a package, and kept talking with him. I was his first customer. Before long, I was helping with the brand, the rules, the purchase flow, and the website.

The service was memorable but scattered across listings and messages. Customers needed one place to see the $5, $10, and $20 packages, understand how the recommendations worked, and contact Robert. He needed a site he could point to without becoming the person who maintained it.

Our conversations became the product backlog. A failed QR-code handoff made the need for a site clearer. Unusual customer requests turned into genre and refund rules. Mobile tests changed the navigation and purchase links. Robert’s reaction when his contact information looked less prominent led me to make that path much clearer.

What I was working with

• Hosting had to cost almost nothing.
• Robert is nontechnical, and requirements arrived through ordinary conversation.
• Customers needed a straightforward experience on phones and computers.
• The site had to sound and look like Movie Master, not a generic online service.
• New backend features could not make the basic storefront less reliable.

I kept the first version static.

The first version had no reason to use a framework or database. Plain HTML, CSS, and JavaScript gave me a fast site with free hosting and very little to maintain.

1. Browser Storefront + game
2. GitHub Pages Static delivery
3. Worker API Validation + routes
4. Cloudflare D1 Shared state

This let the architecture grow in one direction at a time. The storefront still does not depend on the Worker. If analytics is unavailable, the visitor count may miss an event, but the page and game keep working.

The hidden game became a project of its own.

I added a small popcorn-catching game as an Easter egg. It was fun to work on, so I kept going. The game now has two modes, saved records, controller support, analytics, and public leaderboards.

A continuous update and render loop handles movement, collisions, projectiles, power-ups, difficulty, pausing, and local statistics. Standard and Hardcore modes use the same core systems but apply different rules when the player misses popcorn or takes a hit.

Input took more work than I expected. Keyboard, pointer, and gamepad controls each behave differently. The controller code filters out stick drift with a dead zone. If the active controller disconnects, the game pauses instead of leaving the player stuck in a live run.

Leaderboards without a login screen

Requiring accounts would have been too much friction for a small browser game. The browser keeps an anonymous player ID and the name the player entered. The Worker validates names and scores before they appear on the daily or all-time boards. After a run, the game can also show the scores directly above and below the player.

The public boards introduced backend problems the original game did not have. Scores need server-side checks, names need moderation, old runs need migrations, and ties need consistent ranks. I added rate limits, replay protection, score receipts, profile-based renaming, and daily and all-time views while keeping the player flow short.

Measure before optimizing

As the game grew, guesses about performance became less useful. I built 25 deterministic benchmark scenarios, from an empty scene to extreme entity counts, and compared changes against the same workload. I kept the faster changes and rejected optimizations that moved work around without helping the cases players actually reached.

Most of the roadmap came from using the site.

I did not plan the finished system at the beginning. Each stage answered a current problem. The offer needed to be clearer. Robert wanted his contact information easier to find. The mobile layout needed work. I wanted real visitor numbers. Players wanted more reasons to return. Public scores then introduced validation and moderation work.

1. Static business site Put the packages, rules, testimonials, and contact options in one place.
2. Responsive rebuild Reworked navigation, testimonials, contact details, purchase links, and phone layouts after real use.
3. Browser game Added the game loop, three control methods, two modes, progression, and saved records.
4. Visitor and game analytics Added the Worker and D1 once visitor counts and game data needed shared storage.
5. Public leaderboards Added daily and all-time scores, player names, validation, migrations, and backend tests.

Where the project stands.

Movie Master is live and has handled paid orders. Robert has one clear link for the business, and players have a complete browser game with saved records and public competition. The storefront remains static, while the Worker handles visitor data, game analytics, player records, and public scores.

Once the site launched, the work changed. I had to translate conversational requests into product decisions, diagnose problems I did not anticipate, and decide when a new service was useful enough to justify the extra code.