DEV Community: nan

I built a browser game that asks your microphone to imitate a robot

nan — Fri, 04 Sep 2026 03:23:52 +0000

I wanted a microphone project with a very small brief: hear a sound, copy it, and see how close you got.

That became Mimic Party Online, a browser game where each round gives you a short sound cue and one recording attempt. The cue might be a meme clip, an animal call, a machine noise, or something that is hard to describe without making the sound yourself.

It looks like a toy, and it is. It also turned into a useful little audio problem. A score based only on volume would be boring, so the game needs to compare the shape of two sounds while staying fast enough to run in a browser.

The round is intentionally simple

The player does five things:

Choose a sound pack.
Listen to the reference.
Record one take.
Listen to the take.
Read the score.

The replay is important. People tend to remember the sound they meant to make. The recording tells them what actually came out. A convincing robot alarm can turn into a tired bicycle horn pretty quickly.

Quick mode runs for four rounds. Survival mode gives the player three Mic lives and keeps the run going until those lives are gone. The game also has different routes, so a player can protect a streak or accept a shorter recording window for more points.

The browser does the audio work

The recording stays in the browser. The game uses the microphone stream, converts the take to mono PCM at 16 kHz, and extracts the values needed for scoring. The audio does not travel to a scoring server.

For each take, the extractor looks at signals such as:

pitch contour
timing and active duration
attack and energy
rhythm and onset positions
spectral shape

The game does not use every signal for every sound. A pitched cue cares more about contour, while a machine noise depends more on its shape and attack. A rhythmic sound needs the hits to arrive at roughly the right moments.

This is also why the score is more useful when it has labels. A result of 68 is not very instructive by itself. "Timing: 74" gives you something to work on in the next attempt.

Comparing two imperfect recordings

The scorer turns the extracted values into feature distances. Duration and energy can use a straightforward difference after normalizing the arrays. Pitch contour is less cooperative because two people rarely make the same sound at exactly the same speed.

For that comparison, the game uses dynamic time warping with a 14 percent Sakoe-Chiba band. That lets a slightly slower or faster imitation line up with the reference, but stops the match from wandering anywhere it wants.

Each sound profile then applies its own weights. The final score is scaled to 0 through 100, and the interface shows the dimensions that mattered for that particular cue.

There is a quality check before scoring. Very short, quiet, clipped, or noisy takes are not treated as bad imitations. They are treated as bad input, and the game explains what to change. Move closer if the microphone barely hears you. Move back if the signal clips.

Why I kept it local

Microphone access is already a moment where a player has to trust the page. I did not want a silly voice recording to become an unexplained upload.

Local processing has another benefit: the result appears right after the recording ends. There is no upload progress bar and no request waiting on a remote model. The session state is saved in the browser as well, so a player can leave and return to an unfinished run on the same device.

The tradeoff is that browser audio is not perfectly predictable. Microphone hardware varies, background noise varies, and some browsers expose different audio capabilities. The game has to handle those cases instead of assuming every take is clean.

The part that took longer than expected

The comparison code was only half the job. The harder part was making the score feel fair.

A low score should tell the player why the attempt missed. A replay should make the result understandable. The interface should leave room for a bad take to be funny instead of making it feel like a failed test.

That is the reason the game shows the voice shape, the individual dimensions, and the recording before the final verdict. If the number is disappointing, there is still a clear next move: change the rhythm, hold the sound longer, or make a completely different noise and see what happens.

If you have a microphone handy, pick a pack and try one round. You may produce the robot you intended. You may produce the bicycle horn. Both recordings count.

I Built a Browser Game with Next.js 16, Cloudflare Workers, and a D1 Database

nan — Tue, 25 Aug 2026 16:19:08 +0000

I Built a Browser Game with Next.js 16, Cloudflare Workers, and a D1 Database

I've been messing around with Next.js 16 since the beta dropped, and I wanted to build something that wasn't another todo app or SaaS landing page. Something fun, self-contained, and weird enough that I'd actually want to test it myself.

The result is 195-0, a browser-based world conquest draft game. You pick five people for a cabinet, assign each one a role, and run a simulation to see how many of the world's 195 nations your team can conquer. You just open the page and play. No signup, no install.

The Stack

Next.js 16 (App Router, static export)
Cloudflare Workers for API routes
Cloudflare D1 for the leaderboard database
Tailwind CSS v4 with oklch design tokens
Deterministic PRNG for the Daily Challenge

The site is a static export served from Cloudflare's edge. The Worker handles /api/* routes only, which keeps the Worker small and the static assets fast.

Two Game Modes, One Component

Classic Draft lets you respin the country and category before viewing candidates. Daily Challenge gives everyone the same five rounds, same thirty candidates, and no respins. It resets at 00:00 UTC.

Both modes share the same draft flow component. The only difference is whether the RNG seed is random (Classic) or deterministic (Daily). I used a mulberry32 PRNG seeded with an FNV-1a hash of the current UTC date string:

function dailySeedFromDate(date: string): number {
  let h = 0x811c9dc5;
  for (let i = 0; i < date.length; i++) {
    h ^= date.charCodeAt(i);
    h = Math.imul(h, 0x01000193);
  }
  return h >>> 0;
}

function mulberry32(seed: number): () => number {
  return function () {
    seed |= 0;
    seed = (seed + 0x6d2b79f5) | 0;
    let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}

Every player on the same day gets the exact same rounds. The Daily Challenge has its own leaderboard, so you're competing directly against other people who faced the same puzzle.

The Scoring System

This was the most fun part to design. Every cabinet starts at 125 points. The game calculates a role fit percentage from 0 to 100 based on internal weight tables that map each of 16 profession categories to each of 5 cabinet roles. On top of that:

Graded combo bonuses: +11 for a top-tier category match, +8 for a second-tier match
Global alliance bonus: +4 for two countries, +8 for three or more
No-authority penalty: if you have zero Politicians, Dictators, or Military Commanders, your entire score gets multiplied by 0.65
Joke pick penalties: placing Poets or Porn Stars in the General seat costs 14 points
Battlefield variance: a random 0-20 swing so the same cabinet can score differently across runs

The game clamps the final score to 0-195. That's where the name comes from. Reaching 195 needs near-perfect role fits, combo bonuses, a multi-country alliance, and a high variance roll.

I wrote up the full weight tables and scoring formula on the cabinet roles reference page if you want to see the exact numbers.

Leaderboard with D1

The leaderboard was the part that pushed me to learn Cloudflare D1. Three ranking views: Daily Challenge, Classic Today, and All Time. The schema is straightforward:

CREATE TABLE leaderboard_entries (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  commander_name TEXT NOT NULL,
  score INTEGER NOT NULL,
  mode TEXT NOT NULL,
  day_key TEXT,
  created_at INTEGER NOT NULL
);

CREATE INDEX idx_score ON leaderboard_entries(mode, day_key, score DESC);
CREATE INDEX idx_commander ON leaderboard_entries(commander_name, mode, day_key, score DESC);

The Worker keeps only the best score per commander per period. Competition ranking means tied scores share the same rank number, with the earlier submission shown first.

For local development, I built a localStorage mock that auto-falls back when the API is unavailable. I could develop and test the full game flow without deploying the Worker.

SEO and Content Strategy

Each route has its own metadata. I separated the how-to-play guide and the cabinet roles reference into dedicated pages rather than cramming everything onto the homepage. The how-to-play page covers respin rules, invalid combinations, and the scoring formula. The cabinet roles page goes deeper into weight tables and draft order strategy.

robots.txt disallows /api/ to keep user data off search engines, and the Worker sends X-Robots-Tag: noindex, noarchive on API responses.

What I Learned

The biggest surprise was how well static export plus edge Worker works for a game like this. The game itself runs entirely client-side. The Worker is only needed for leaderboard reads and writes. That split keeps latency low and the Worker's daily request count manageable.

The deterministic PRNG was harder than I expected. Getting the same seed to produce the same rounds across different browsers and time zones required careful date handling. I settled on a UTC date string (YYYY-MM-DD) as the seed input, which aligns the Daily reset with 00:00 UTC.

Try It

If you want to see how it works in practice, play the game here. The Daily Challenge is probably the best place to start since everyone gets the same puzzle. There's also a leaderboard if you want to see how your score compares.

Feedback welcome, especially on the scoring balance. I'm still tuning the weight tables.

How to build Brat Generator By Rext.js

nan — Sun, 27 Jul 2025 08:36:24 +0000

Brat Generator Web Application: A Comprehensive Technical Architecture Analysis

Project Overview

The Brat Generator is a modern web application built to create content in Charli XCX's iconic "brat" aesthetic. This Next.js-based application allows users to generate brat-style text, album covers, and memes with the distinctive bright green background and bold typography that became a cultural phenomenon.

Technology Stack

Core Framework

Next.js 15.4.2 - React-based full-stack framework with App Router
React 19.1.0 - Latest React version with concurrent features
TypeScript 5.x - Type-safe JavaScript development

UI and Styling

Tailwind CSS 4.x - Utility-first CSS framework with custom theme configuration
Radix UI - Headless, accessible UI components
- @radix-ui/react-accordion - Collapsible content sections
- @radix-ui/react-slot - Composition utilities
Lucide React - Modern icon library
shadcn/ui - Pre-built component library built on Radix UI

Development Tools

ESLint 9.x - Code linting with Next.js and TypeScript rules
PostCSS - CSS processing with Tailwind integration
pnpm - Fast, disk space efficient package manager

Project Architecture

Directory Structure

The application follows Next.js 13+ App Router conventions with a well-organized file structure:

├── app/                          # App Router directory
│   ├── about/                    # About page route
│   ├── album-cover-generator/    # Album cover generator tool
│   ├── blog/                     # Blog section
│   ├── generators/               # Generator tools overview
│   ├── globals.css              # Global styles and theme
│   ├── layout.tsx               # Root layout component
│   ├── page.tsx                 # Homepage
│   ├── robots.ts                # SEO robots configuration
│   └── sitemap.ts               # Dynamic sitemap generation
├── components/                   # Reusable UI components
│   ├── ui/                      # shadcn/ui components
│   ├── Navigation.tsx           # Main navigation component
│   └── seo-head.tsx            # SEO metadata component
├── lib/                         # Utility functions
│   └── utils.ts                # Common utilities and helpers
└── public/                      # Static assets

Key Architectural Decisions

1. App Router Implementation

The project utilizes Next.js 13+ App Router, providing:

File-based routing with automatic code splitting
Server Components by default for optimal performance
Nested layouts for consistent UI structure
Built-in SEO optimization with metadata API

2. Component Architecture

The application follows a modular component structure:

Atomic Design Principles - Components are organized from basic UI elements to complex pages
Server/Client Component Separation - Strategic use of "use client" directive
Composition over Inheritance - Leveraging Radix UI's slot-based composition

3. Styling Strategy

Tailwind CSS 4.x with custom theme configuration
CSS Custom Properties for dynamic theming
Responsive Design with mobile-first approach
Design System implementation through shadcn/ui components

Technical Implementation Details

SEO and Performance Optimization

Sitemap Generation

// app/sitemap.ts
export default function sitemap(): MetadataRoute.Sitemap {
  return [
    {
      url: 'https://yourdomain.com',
      lastModified: new Date(),
      changeFrequency: 'daily',
      priority: 1,
    },
    // Dynamic route generation for all pages
  ]
}

Robots.txt Configuration

// app/robots.ts
export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: '*',
      allow: '/',
    },
    sitemap: 'https://youdomain.com/sitemap.xml',
  }
}

Next.js Configuration Optimizations

The next.config.ts includes several performance and SEO enhancements:

Image Optimization with WebP and AVIF formats
Compression enabled for reduced bundle sizes
Security Headers implementation
SEO-friendly redirects for legacy URLs

Canvas-Based Image Generation

The core functionality revolves around HTML5 Canvas API for dynamic image generation:

Text Rendering Engine

Dynamic font sizing based on canvas dimensions
Text wrapping algorithm for multi-line content
Color customization with real-time preview
High-resolution output for quality downloads

Image Processing Pipeline

Canvas Creation - Dynamic sizing based on content
Background Rendering - Solid color or gradient application
Text Positioning - Center-aligned with proper spacing
Font Application - Custom font loading and rendering
Export Generation - PNG/JPEG output with quality optimization

State Management

The application uses React's built-in state management:

useState for component-level state
useEffect for side effects and lifecycle management
Custom hooks for reusable stateful logic
Context API consideration for global state (if needed)

Responsive Design Implementation

Mobile-First Approach

/* Tailwind responsive classes usage */
.text-lg sm:text-xl md:text-2xl lg:text-6xl
.px-4 sm:px-6 lg:px-8
.grid-cols-1 lg:grid-cols-2

Adaptive Navigation

Mobile hamburger menu with smooth animations
Desktop horizontal navigation with hover effects
Touch-friendly interactions for mobile devices

Performance Optimizations

Code Splitting

Route-level splitting automatic with App Router
Dynamic imports for heavy components
Lazy loading for non-critical resources

Image Optimization

Next.js Image component for automatic optimization
WebP/AVIF format support for modern browsers
Responsive images with multiple breakpoints

Bundle Analysis

The build output shows optimized bundle sizes:

Main page: 15.4 kB (128 kB First Load JS)
Shared chunks: 100 kB across all pages
Static generation: All pages pre-rendered

Development Workflow

Build Process

# Development with Turbopack
npm run dev --turbopack

# Production build
npm run build

# Production server
npm run start

# Code quality
npm run lint

Code Quality Assurance

ESLint configuration with Next.js and TypeScript rules
Type checking with strict TypeScript configuration
Accessibility compliance through Radix UI components
Performance monitoring with Next.js built-in analytics

Deployment Considerations

Static Generation

All pages pre-rendered at build time
SEO-optimized with proper metadata
Fast loading with minimal JavaScript hydration

Production Optimizations

Minification and tree shaking automatic
Compression enabled in Next.js config
CDN-ready static assets in public directory

Security Implementation

Content Security

XSS Protection headers configured
Content-Type sniffing prevention
Frame options for clickjacking protection
Referrer policy implementation

Input Validation

Client-side validation for user inputs
Sanitization of text content before canvas rendering
File type validation for uploads (if implemented)

Scalability Considerations

Performance Scaling

Static generation reduces server load
CDN compatibility for global distribution
Efficient bundling with automatic code splitting

Feature Extensibility

Modular component architecture for easy feature addition
Plugin-ready canvas system for new generators
API-ready structure for backend integration

Conclusion

The Brat Generator represents a well-architected modern web application that successfully combines performance, user experience, and maintainability. The use of Next.js 15 with App Router, combined with Tailwind CSS and TypeScript, creates a robust foundation for a creative tool that has cultural relevance and technical excellence.

The application demonstrates best practices in:

Modern React development with server components
Performance optimization through static generation
SEO implementation with proper metadata and sitemaps
Responsive design with mobile-first approach
Code quality through TypeScript and ESLint
User experience with smooth interactions and fast loading

This technical implementation serves as an excellent example of how to build a modern, performant web application that delivers both functionality and user satisfaction while maintaining high code quality standards.