Building a Browser Arcade: Three Game Loops, One Entry Point

I’m Ludy, and I built LudyPlay, a free browser-game portal with open-answer trivia, a 15-minute survival run, and a coastal motorcycle race.

The interesting engineering question is not just how to make a game. It is how to give very different games a shared entry point without pretending they behave the same way.

The browser is the common platform

At the platform level, this is a web project: players access games through a browser rather than installing a native package.

I’m keeping this write-up framework-neutral because a specific framework, backend, or hosting setup is not documented here. The architectural discussion is about responsibilities and trade-offs, not an invented stack breakdown.

The useful separation is between the portal layer and the gameplay layer. The portal helps someone choose an experience. Each game then needs its own rules, input handling, and lifecycle.

Different games need different state models

For open-answer trivia, the central flow is submission and evaluation. A typed answer introduces questions that multiple-choice interfaces avoid: whitespace, capitalization, punctuation, and accepted variations.

A useful evaluation pipeline to consider is normalization followed by an explicit acceptance check. Broad fuzzy matching needs care: being generous with spelling can accidentally turn a wrong answer into a correct one.

A timed survival game raises another class of questions. Elapsed time, update frequency, and rendering frequency are related, but they should not automatically be treated as identical.

For a racing experience, responsiveness becomes the obvious thing to inspect. Input should not depend on how often unrelated interface elements update.

These are design considerations, not claims about undocumented implementation details.

Keep state boundaries boring

The boundary I would recommend is simple: each game owns its session state, while shared navigation stays outside that state.

That reduces the temptation to build one enormous state object containing trivia answers, survival timers, and racing controls. Shared presentation does not require shared gameplay logic.

It also creates clearer testing questions. Can a session restart cleanly? What happens when a tab becomes inactive? Does navigation leave anything running?

What I want feedback on

Try LudyPlay and tell me where the experience feels awkward.

I’m especially interested in answer acceptance for trivia and how the survival session length feels. Specific examples are much more useful than a general "looks good."