DEV Community: Tyler

I Built an Evidence-First Game Guide with Next.js and Cloudflare Pages

Tyler — Wed, 15 Jul 2026 09:07:34 +0000

When a new game is announced, the web fills up with answers very quickly—even when the developer has not provided them yet.

I wanted to build something different.

DearPassengers.net is an independent guide to Dear Passengers, an upcoming physics-based co-op airline game from FLEXUS. The site collects the details that have actually been confirmed while giving “not announced” and “not stated” their own place in the information architecture.

It is not the game’s official website, and it is not affiliated with FLEXUS, Valve, or Steam. It is a small experiment in building a useful content product around evidence instead of hype.

The content problem

A newly revealed game creates a predictable set of questions:

When will it launch?
How many players does it support?
Can I play alone or in local co-op?
Is it coming to consoles?
Does it support crossplay, controllers, or Steam Deck?
Is there a demo or playtest?

The official Steam listing answers some of these questions, while announcement footage provides clues about others. Community discussions reveal what people want to know—but they are not a product roadmap.

That led to a simple editorial model:

Confirmed: explicitly stated by Steam or FLEXUS.
Observed: visible in official footage, but not promised as a specification.
Not stated: the current source does not provide an answer.
Not announced: no official announcement has been found for the feature or platform.

For example, footage may show several crew members, but that does not automatically establish an official maximum player count. A missing console announcement also does not mean a console version has been cancelled.

“We don’t know yet” is still useful information when it is presented clearly.

Turning the model into a site

The project is built with:

Next.js 14 App Router
React 18 and TypeScript
custom, CSS-first responsive styling
static export for Cloudflare Pages
a small number of client-side islands for navigation, FAQs, and video selection

Most of the site can be rendered statically. There is no database, account system, or application backend because the product does not need one.

The core build and deployment flow is intentionally small:

pnpm typecheck
pnpm build
pnpm deploy:cf

The production build exports to out/, and Wrangler publishes that output to Cloudflare Pages.

Information architecture before components

Instead of putting every keyword and question on one giant landing page, I split the content by user intent:

a complete game overview;
a release-date guide;
a player-count and multiplayer guide;
About, Editorial Policy, Contact, and Privacy pages.

The focused pages can answer a narrow question immediately, while contextual links connect them back to the larger guide.

That structure also made the implementation easier to reason about. Each route has a clear primary question, a defined set of unknowns, and its own metadata rather than being another variation of the same generic page.

Trust is part of the UI

I did not want the sourcing rules to exist only in my notes, so the site includes:

visible verification dates;
a source ledger that distinguishes first-party material from community discussion;
an editorial policy;
a correction channel;
clear independence and attribution language;
structured data whose dates and claims match the visible page.

The same thinking applies to SEO. The project includes page-specific titles and descriptions, canonical URLs, Open Graph assets, sitemap and robots files, plus JSON-LD for articles, FAQs, breadcrumbs, videos, the website, and the game.

Schema is not used to invent certainty. If the visible page says a player limit is unknown, the structured data should not quietly imply otherwise.

Designing around the subject

I wanted the site to feel like an airline operations briefing rather than a generic collection of cards.

The visual system uses cockpit-like navy surfaces, warm paper backgrounds, safety-red accents, condensed display type, status boards, manifests, arrivals language, and “cabin feed” video panels. Four short gameplay clips are hosted locally, while the official trailer uses YouTube’s privacy-enhanced embed domain.

The aviation metaphor is mostly presentation, but it also reinforces the content model: every claim should feel like an item on a manifest that can be checked.

What I learned

The most important lesson was that uncertainty can be modeled instead of hidden.

On content-heavy projects, the data model is not always a database schema. Sometimes it is the set of labels and editorial rules that determine what a sentence is allowed to claim.

Static architecture also turned out to be a good constraint. The site stays operationally simple, and client JavaScript is reserved for interactions that materially improve scanning and navigation.

The project is still being refined. I am cleaning up dependencies and documentation, rerunning the full pre-launch checks, and reconciling a few implementation decisions before I consider the build finished.

You can explore the current site at dearpassengers.net.

I would especially appreciate feedback on one question: what is the clearest way you have found to communicate “unknown” without making a product page feel incomplete?

Building a Lightweight Social Deduction Game for the Web (Lessons Learned)

Tyler — Thu, 12 Feb 2026 06:37:09 +0000

Social deduction games are exploding in popularity again in 2026.

But instead of building another heavy multiplayer client, I decided to experiment with something different:

👉 A lightweight, browser-based imposter-style game that removes friction and focuses purely on deduction mechanics.

Here’s what I learned from building it.

Why Browser-Based Instead of App-Based?

Most modern players don’t want:

Large downloads

Account creation friction

Complex onboarding

They want:

Instant access

Fast rounds

Clear mechanics

That’s why I focused on a web-first architecture.

The goal was simple:

Make it playable instantly in a browser, without sacrificing strategic depth.

Core Design Principles

When building a social deduction game, the hardest problem isn’t graphics.

It’s psychology.

Here are the principles I used:

Minimal UI, Maximum Tension

Instead of cluttered menus and animations, I simplified everything:

Clear role assignment

Minimal voting interface

Direct interaction prompts

Reducing visual noise actually increases psychological pressure.

Fast Round Cycles

Attention spans are short.

So I structured gameplay around:

5–10 minute sessions

Quick resets

Immediate role switching

Short cycles increase replayability dramatically.

Deterministic Game Logic

From a technical standpoint, social deduction mechanics require:

Clear state management

Strict role validation

Predictable outcome resolution

Even small logic inconsistencies can break trust in the system.

The backend logic must always be authoritative.

Architecture Considerations

For lightweight browser gameplay, I focused on:

Frontend state management

Minimal API calls

Stateless round resets

Simple role distribution algorithms

Since the core mechanic is deception rather than real-time combat, performance requirements are actually manageable compared to FPS or physics-based games.

This makes it ideal for web deployment.

Real-World Implementation

As part of this experiment, I launched a browser-based version focused purely on deduction strategy and clean mechanics.

You can see the live implementation here:

https://www.impostergame.pro/

The goal wasn’t to compete with massive multiplayer titles, but to explore how far you can push social deduction mechanics in a streamlined web environment.

Lessons Learned

Here are the biggest takeaways:

Simplicity scales better than complexity

Adding more roles doesn’t always improve gameplay.
Sometimes fewer mechanics create stronger tension.

Social dynamics > Visual polish

Players care more about:

Being believed

Accusing others

Surviving suspicion

Than about particle effects.

Accessibility wins

Removing friction increases experimentation.

Web-based delivery lowers the barrier for new players significantly.

Final Thoughts

Social deduction games are not just trending because of nostalgia.

They work because they simulate something deeply human:

Trust under uncertainty.

And with modern web technologies, building lightweight versions is more viable than ever.

If you're a developer interested in game mechanics, psychology-driven systems, or browser-first architecture, this genre is worth exploring.