Rally Rush II is the second generation of the Rally Rush browser racing experiment. The first version proved that a lightweight Three.js rally game could live as a static web prototype. This version pushes the idea closer to a configurable racing sandbox: more stages, more setup choices, more vehicle handling detail, and a stronger sense that the game can grow into a real arcade-rally platform.

The important jump is not just visual polish. Rally Rush II turns the original road-driving prototype into a broader racing system with selectable environments, cars, weather, race types, difficulty, assists, traffic, timing, and camera tools.

What It Does

Rally Rush II lets you open a browser, choose a stage, select a car, tune the race setup, and start driving without installing anything. It is still a static site, but it behaves like a self-contained game launcher.

The current stage list is much more ambitious than the first Rally Rush:

• Scotland: wet Highland roads and green valley terrain.
• Desert: wide sun-baked roads through dunes and mesas.
• Alpine: tight mountain asphalt with snow banks.
• Tokyo: neon city expressway driving with urban scenery.
• Lakes: forest roads, shorelines, rocks, and open curves.
• Rainforest Mud: dense jungle, mud-road textures, spray, and reduced visibility.
• Mediterranean Coast: cliff roads, sea views, walls, pines, and coastal bends.
• Valle Verde: a fictional 14-turn Mediterranean circuit with pit lane, grandstands, paddock details, kerbs, and a proper track layout.

The menu is not just a title screen. It acts like a compact race setup interface: stage cards, car selection, race type, time of day, weather, difficulty, driving assist, and launch button all sit in one place.

What Makes Version Two Different

The first Rally Rush was valuable because it had a working browser rally loop. Rally Rush II is different because it starts to separate the game into systems.

The biggest differences are:

• Race modes: Traffic mode, Rally mode, and Grid mode change the objective and what appears on the road.
• Difficulty profiles: Rookie, Pro, and Expert tune traffic count and traffic speed behavior.
• Driving assists: Full, Sport, and Manual change road-following, heading recovery, steering response, and curve slip.
• Vehicle choice: Rally R is the balanced rally car; Apex GT is faster and more stable but less drift-focused.
• Weather and time of day: clear, rain, fog, day, sunset, and night combinations change the feel of the drive.
• Stage-specific world building: Tokyo, Rainforest, Lakes, Coastal, and Valle Verde each have their own scenery logic instead of being simple reskins.
• Camera tooling: chase, cockpit, track overview, and camera-tuning controls make it easier to inspect and refine the driving view.
• Persistent best times: local storage keeps times by stage, difficulty, assist, and race mode.

This is the difference between "a road with a car" and "a racing game that has a shape."

The Driving Loop

In the live build I tested Valle Verde with rain enabled. Even from a short run, the version-two goals are visible: a heavier HUD, stronger car presentation, weather effects, road furniture, stage signage, and track-side structures. The cover image for this entry comes from that live play pass.

The player-facing loop is straightforward:

Choose stage -> choose car -> choose race setup -> start race -> drive -> finish -> compare result

Under the hood, the game is doing more than that. It builds road and terrain data for the chosen environment, creates stage decoration, places traffic or grid opponents depending on the race mode, applies vehicle handling and assist profiles, updates camera behavior, and writes best times back to local storage.

What It Excels At

Rally Rush II excels at scope expansion without leaving the browser.

The strongest parts are:

• Menu density: many meaningful choices are exposed without burying the player in separate screens.
• Stage variety: the game now has distinct environment identities instead of one repeated terrain idea.
• Static deployment: the whole thing can be played from GitHub Pages.
• Configurable handling: assists and vehicle stats create a path toward both arcade and more demanding driving.
• Environment ambition: Valle Verde, Tokyo, Lakes, Rainforest, and Coastal all point toward a richer procedural scenery system.
• Iteration friendliness: because it is still plain HTML, CSS, JavaScript, Three.js, and assets, it remains easy to inspect and keep evolving with AI assistance.

For Small Web Lab, this is exactly the kind of project worth documenting: not a finished commercial game, but a working artifact where AI-assisted iteration produced a noticeable second-generation leap.

Areas For Improvement

Rally Rush II is more ambitious than the first game, and that also makes the next improvements clearer:

• Input onboarding: the menu is polished, but the driving controls could be made more visible before the race starts, especially for keyboard players.
• Loading communication: the asset loading screen exists, but large 3D assets and stage generation could benefit from clearer per-stage expectations.
• Race feedback: modes, timing, sectors, and position are present, but the player could use more direct goals and feedback during the first minute.
• Collision and recovery feel: a richer racing game needs clear off-road recovery, reset, crash, and penalty behavior.
• Performance budgets: the most detailed stages need careful limits for lights, instancing, textures, and draw calls so the game stays playable on modest devices.
• Mobile-first controls: touch controls exist, but the game would benefit from dedicated mobile layout testing around HUD weight and visibility.
• Sound design: stage-specific music is already present; engine, surface, collision, and weather audio would make the driving loop feel much more complete.

None of these are blockers to the experiment. They are the natural next layer now that Rally Rush II has moved beyond a simple prototype.

The Takeaway

Rally Rush II shows what happens when a browser prototype gets a second development pass instead of being left as a one-off. The original Rally Rush was a proof of concept. Version two is closer to a platform: multiple stages, cars, modes, assists, weather, cameras, and a growing library of environment systems.

It still has rough edges, but it is a strong AI-built game milestone because the improvement is structural. It is not just prettier. It has more game inside it.

Quiremark is the publishing engine behind this version of Small Web Lab. It is a blog platform, but the more accurate description is: a local control room that turns Markdown, settings, themes, and uploaded images into a fast static website.

Most blog platforms start with a server, a database, user accounts, plugins, and runtime rendering. Quiremark takes the opposite route. The writing and administration happen locally. The public site is compiled into plain files. The deployed result is HTML, CSS, JavaScript, images, feeds, sitemaps, and discovery documents that can be hosted almost anywhere.

The cover image shows the local dashboard tracking the selected website, post count, active template, widgets, and publishing actions.

What It Does

Quiremark combines four jobs that are often split across separate tools:

1. Content management

   Posts live as Markdown files in content/posts/. Each post has front matter for title, slug, description, date, category, tags, cover image, and draft status. That means the writing is portable and easy to version with Git.

2. Site configuration

   The site identity, author details, categories, feature flags, analytics ID, widgets, theme text, SEO metadata, and selected template live in content/settings.json. The admin dashboard edits that configuration instead of hiding it inside a database.

3. Static generation

   The compiler reads the posts and settings, renders Markdown through EJS templates, sanitizes the HTML, and writes a complete static site into out/. The generated output includes the home page, post pages, category archive pages, RSS, sitemap, robots file, client-side search index, and LLM-readable Markdown discovery files.

4. Deployment

   The local backend can deploy the compiled out/ folder to GitHub Pages using local Git credentials. Remote URLs, branch names, and commit messages are validated before Git commands run.

The basic shape is simple:

Markdown posts       settings.json       uploaded images
      |                   |                    |
      v                   v                    v
             Local React admin + Express API
                          |
                          v
                 Static compiler
                          |
                          v
        out/ HTML, CSS, JS, feeds, search, sitemap
                          |
                          v
             GitHub Pages or any static host

The Public Site It Produces

The public side is intentionally static. Once compiled, readers are not waiting on database queries, server-side rendering, or an admin runtime. They are just loading files.

That makes Quiremark especially useful for small product blogs, indie project journals, documentation-style notes, and portfolio sites where the public experience should be fast, low-maintenance, and resilient.

What Makes It Different

The main difference is that Quiremark does not ask you to choose between a friendly dashboard and a static site. A lot of systems give you one of these two experiences:

• A dynamic CMS with a rich admin panel, but a heavier hosting model.
• A static site generator with great output, but an editing workflow that mostly lives in code.

Quiremark sits between them. You get a local dashboard for editing, theming, widgets, SEO, and deployment, but the published site is still just static output.

That distinction matters. It keeps the public surface small while giving the author a comfortable control panel.

The Theme And Widget Layer

Quiremark ships with multiple visual templates: Nordic Minimal, Neo Glass, Cyber Monospace, Sunset Vaporwave, Brutalist Newspaper, LensDigest Magazine, and Eco Forest. The theme can be changed from the dashboard, and the same Markdown content can be republished through a different visual system.

Widgets are part of the same configuration layer. The system supports author bios, recent posts, topic chips, newsletter blocks, and custom HTML. Feature flags can turn public systems on or off: search, categories, RSS, newsletter, and About blocks.

Where It Excels

Quiremark is strongest when the site owner wants ownership and speed without giving up a dashboard.

It excels at:

• Static performance: compiled pages are cheap to host and quick to serve.
• Content portability: posts are Markdown, not database rows.
• Search and taxonomy: generated category archives and a client-side search index make small archives easy to browse.
• SEO and discovery: the compiler emits canonical metadata, Open Graph tags, Schema.org data, RSS, sitemap.xml, robots.txt, llms.txt, llms-full.txt, and Markdown alternates.
• Local-first publishing: the admin panel can stay local while the public site remains static.
• Small multi-site workflows: the upstream project supports separate website workspaces, each with its own content, output folder, and deployment settings.
• AI-assisted sites: because the source of truth is Markdown plus JSON, it is easy to have AI help draft posts, tune descriptions, reorganize categories, or audit generated output.

For Small Web Lab, that last point is the reason it fits so well. The site is now a record of things I build with AI, and Quiremark gives those projects a durable publishing workflow.

Why Not Just Use WordPress, Ghost, Medium, Or Jekyll?

WordPress is much larger and more extensible, but it usually brings a database, plugin maintenance, hosting hardening, and a broader attack surface. Ghost is polished and publication-oriented, but it is still a running application. Medium is easy, but it does not give full control over the site, templates, source files, or deployment. Jekyll and other static generators are excellent, but their authoring workflow is usually friendlier to developers than to a casual editor.

Quiremark is not trying to beat all of those tools at their own game. Its advantage is narrower:

Keep the public site static. Keep the source readable. Keep the admin local. Keep publishing simple.

That makes it a practical platform for builders who want to ship small sites without turning every blog into infrastructure.

Areas For Improvement

There are clear places where Quiremark could grow:

• Editor polish: the Markdown editor works, but a richer writing surface with block previews, better image placement, and reusable snippets would make long-form posts easier.
• Media management: uploaded images are supported, but a visual media library with alt text, captions, compression, and cleanup tools would help as a site grows.
• Theme authoring: switching themes is already useful. Creating custom themes would benefit from stronger docs, validation, and starter templates.
• Preview workflows: draft previews, diff views, and before/after theme comparison would reduce publishing mistakes.
• Authentication model: the local bearer-token login is enough for a private local tool. A team-hosted admin would need stronger multi-user authentication and permissions.
• Testing and CI: the compiler has a lot of useful behavior. Automated snapshot tests for generated HTML, feeds, search data, and discovery files would make future changes safer.
• Search scale: the generated JSON search index is perfect for small and medium sites. Very large archives may eventually need indexing, pagination, or a hosted search adapter.

These are improvement areas, not contradictions in the concept. The current system already has the important foundation: a readable content store, a configurable compiler, multiple themes, static output, and a dashboard that makes the workflow approachable.

The Takeaway

Quiremark is a strong fit for a personal lab, a product changelog, a small editorial site, or a portfolio of AI-made projects. It does not try to be a massive hosted CMS. It is more focused than that: a local publishing machine for turning structured Markdown into a deployable static website.

That focus is what makes it interesting. It gives a solo builder enough interface to move quickly, enough static output to host cheaply, and enough file-based structure to stay in control.

LensDigest is the editorial site in the lab: a photography and videography digest built around frequent publishing, clean search intent, and fast reading.

The interesting part is the operating system around the site. The product needs to turn a broad camera niche into consistently packaged pages that are useful to readers and legible to search engines.

What It Tests

• High-frequency publishing without making the site feel disposable.
• Clear page structure for camera, video, creator, and gear topics.
• A lightweight static delivery model that can keep up with daily updates.

Breakshot 3D is a standalone browser pool game with local play, CPU matches, and a support layer of rules and guides.

The product is not just the game loop. It also tests whether useful search pages around aiming, spin, rules, and play modes can help a browser game become discoverable.

What It Tests

• Browser-based 3D gameplay that loads quickly enough to be approachable.
• A rules and guide layer that supports players outside the main game canvas.
• The boundary between a game prototype and a standalone product domain.

Arcana Muse is the AI product in the portfolio: a tarot-guidance experience built around reflection, ritual, and follow-up context.

The useful design question is how to make an AI interaction feel specific without pretending to predict the future. The product leans into interpretation, practical framing, and repeat visits.

What It Tests

• A consumer AI interface with a strong theme and clear boundaries.
• Prompting that supports reflection rather than generic horoscope copy.
• A product surface where visual mood, memory, and advice all need to fit together.

Ping Pong 3D is a compact browser table-tennis prototype. It stays discoverable inside Small Web Lab while remaining a small standalone experiment.

The route is synced from its own repository, which makes it a useful reference pattern for future mini-sites that should live under smallweblab.com/lab/.

What It Tests

• A small 3D game surface that can be embedded as a static route.
• Independent prototype development with central-site publication.
• Keeping rougher experiments playable without giving each one a separate domain.

Asteroids 3D is an older browser shooter prototype. It is rougher than the newer lab entries, which is part of why it belongs here.

Small Web Lab has room for experiments that are still interesting even when they are not polished enough to graduate into standalone products.

What It Tests

• Preserving older AI-assisted build experiments as playable snapshots.
• A simple route pattern for prototypes that do not need a full product wrapper.
• The difference between a shipped public artifact and a finished product.

Rally Rush is a lightweight browser rally game with quick circuit selection, arcade controls, and a simple race loop.

It is synced from its own repository into the lab and is especially useful as a reference for road generation, track feel, and visual terrain inside a small static prototype.

What It Tests

• Arcade driving feel in a browser route.
• Three.js scenes that remain simple enough to ship as a static mini-site.
• Keeping a playable prototype connected to a larger portfolio without over-packaging it.

Meeting Notes expands the lab beyond games into practical browser tooling. It is a local-first workspace for capturing meeting details, action items, deadlines, tags, and quick follow-up search from one screen.

The prototype stays in its own repository, syncs into the lab from main, and gives the catalog a more practical product shape.

What It Tests

• Local-first utility design inside a small browser app.
• A productivity surface that stays useful without accounts or server storage.
• The same synced prototype route pattern used by the games.