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.

I started developing the site in July 2026 and am its sole developer. Robert contributes many ideas. Part of my job is working through those requests with him: explaining when a feature would make the site harder to use, suggesting alternatives, and agreeing on what to build.

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.

Seeing what people actually use

The analytics dashboard brings site traffic and game activity into one place. I can compare visitor trends, games played, and the split between Standard and Hardcore instead of relying on a hit counter alone. It gives me a way to follow what happens after a feature goes live.

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

The benchmark suite (opens in a new tab) covers 26 deterministic scenarios, from an empty scene to extreme entity counts. It exercises collision checks, controller polling, rendering, and full updates, so changes can be compared against repeatable workloads.

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.

The Movie Master site has handled dozens of 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.