DEV Community: Eugene Kozlovsky

Building NICHLYST: The Architecture of Afterlife — Designing Post-Final UI Decay in CSS

Eugene Kozlovsky — Wed, 23 Sep 2026 22:35:52 +0000

Most video games treat the user interface as immortal chrome. The HUD sits above the world, pristine and unaffected by whatever apocalypse unfolds beneath it. The interface is the one thing that never dies.

NICHLYST rejects that premise entirely.

In NICHLYST, you spend forty days cataloguing the final archive of a dead language in a damp basement. The interface is not a sterile heads-up display. It is paper. It is ink on aging fiber. Over forty days of neglect, humidity, and moral erosion, it rots.

The Immortal UI Fallacy

Every game maintains a quiet contract with the player: the interface is sacred ground. Even in survival horror, menus remain immaculate.

NICHLYST breaks that contract. You are an archivist in a basement. The walls sweat. The paper records you handle are already decaying. Why should the interface be exempt from the same entropy that consumes everything else?

By Day 16, when the Postscript phase begins and the player confronts the weight of their choices, the UI degrades. Not through dramatic effects, but through the slow processes that govern real material decay. Ink fades. Borders fray. Text drifts off its baseline.

The Eight Stages of Decomposition

The decay system is organized into eight discrete levels, indexed 0 through 7. Each level corresponds to a range of game days and a specific phase of material deterioration.

Level 0 (Days 1-15, Pristine): Full ink contrast using #EDE6D8 on the near-black base. Solid 1px borders at rgba(125, 114, 99, 0.3). WCAG AAA contrast ratio of 8.4:1. The interface as the archivist first encounters it.

Level 1 (Days 16-18, Subtle): A slight desaturation filter (saturate(0.95)) cools the palette. Secondary elements drop to 90% opacity. The change is barely perceptible, which is precisely the point.

Level 2 (Days 19-21, Noticeable): Desaturation deepens to saturate(0.88). A text-shadow appears on the visitor name, simulating ink bleed. Resource icons dim to 90%. Day counter and mood text fall to 85%.

Level 3 (Days 22-24, Significant): Saturation drops to saturate(0.8). A solid border appears on the screen container. Mood text receives a hairline blur (filter: blur(0.3px)). Choice buttons maintain opacity: 0.95 and filter: none -- interactive elements must never be degraded beyond usability.

Level 4 (Days 25-28, Deep): The Hidden Postscript begins, and with it paper grain. An SVG feTurbulence filter is injected as a ::before pseudo-element, rendering fractal noise at baseFrequency: 0.9 with four octaves, desaturated to grayscale via feColorMatrix, composited at 3% opacity.

Level 5 (Days 29-32, Profound): Saturation falls to saturate(0.6). The content column narrows to max-width: 440px. Letter-spacing increases by 0.3px globally. Mood text shifts from opacity reduction to color substitution: var(--c-3) instead of var(--c-5).

Level 6 (Days 33-36, Ash): Saturation drops to saturate(0.45). Background shifts from var(--c-1) to var(--c-2). Visitor names shift to var(--c-4). Choice buttons gain a glitch overlay on hover: "ZHYVY" (LIVE) flickers via a stepped keyframe animation.

Level 7 (Days 37-40, Dissolution): Terminal afterlife rot. Saturation reaches saturate(0.3). Horizontal scan-lines overlay the viewport via repeating-linear-gradient at 2% opacity. Screen borders pulse in an 8-second cycle. Choice buttons overlay "DYKHAI" (BREATHE) on hover. On Day 40, the interface reaches terminal archival collapse.

Engineering Decay Inside an Immutable 5-Color Palette

The hardest constraint was not the decay system itself. It was the color palette.

NICHLYST enforces a strict 5-color palette at build time. The script scripts/check_colors.sh scans every CSS, JS, and HTML file, extracts all hex color values, and compares them against a whitelist:

#1A1C1C  #2D3131  #7D7263  #BCB2A1  #EDE6D8

Any unauthorized color -- blood-red warning hues, rusty oranges, sepia browns -- triggers an immediate commit rejection. The palette is the game's visual identity. We cannot break it to make rot look more dramatic.

So how do you simulate decomposition when you cannot add new colors? The answer is CSS math.

Opacity Reduction: Early levels reduce opacity on secondary elements. Level 1 drops day counters to 90%. Level 3 drops mood text to 80%. This is safe because the underlying tokens already yield 12.5:1 contrast (WCAG AAA), so even at 80% opacity the effective contrast remains well above 4.5:1.

Color-Shifting via Token Substitution: At Level 5, instead of reducing opacity further, the system swaps token references. Mood text shifts from var(--c-5) to var(--c-3). No new colors are introduced. The system reuses existing palette members to simulate ink dilution.

Dynamic Contrast Enforcement: The UIDecayManager includes a WCAG contrast guard that activates at Level 5 and above. It calculates effective luminance of desaturated text against the background:

const textRgb = _hexToRgb('#EDE6D8');   // --c-5
const bgRgb = _hexToRgb('#1A1C1C');     // --c-1
const grayPoint = Math.round(
  0.299 * textRgb[0] + 0.587 * textRgb[1] + 0.114 * textRgb[2]
);
const desatText = textRgb.map((c) =>
  Math.round(c * satFilter + grayPoint * (1 - satFilter))
);
const ratio = _contrastRatio(desatText, bgRgb);

If the ratio drops below 4.5:1, a brightness boost is injected as --nl-decay-text-safe, applied via !important override on all text elements. The decay becomes aggressive. The text remains readable.

SVG feTurbulence for Paper Grain: At Level 4, fractal noise is injected as an inline SVG data URI in a ::before pseudo-element using feTurbulence with baseFrequency="0.9" and numOctaves="4". At Level 7, scan lines appear via ::after using repeating-linear-gradient.

Letter-Spacing Drift: Level 5 introduces letter-spacing: 0.3px globally, simulating ink spreading on damp paper. The characters drift apart, as if the fibers holding them in place are relaxing.

The complete CSS cascade for representative decay transitions:

.decay-3 { filter: saturate(0.8); }
.decay-3 .ds-screen {
  border: 1px solid rgba(125, 114, 99, 0.4);
}
.decay-3 .ds-mood-text {
  filter: blur(0.3px); opacity: 0.8;
}

.decay-5 { filter: saturate(0.6); letter-spacing: 0.3px; }
.decay-5 .ds-mood-text { color: var(--c-3); filter: none; }
.decay-5 .ds-day-counter { color: var(--c-3); }

.decay-7 { filter: saturate(0.3); background-color: var(--c-1); }
.decay-7 .ds-screen {
  border-color: rgba(125, 114, 99, 0.15);
  animation: borderFlicker 8s ease-in-out infinite;
}
.decay-7 .ds-body {
  text-shadow: 0 0 1px rgba(237, 230, 216, 0.15);
}

Every property references existing palette tokens. The decay is real, but the palette is untouched.

Mitigating Mobile WebView GPU Choke

The original implementation chained CSS filters: filter: blur(1px) drop-shadow(0 0 4px rgba(0,0,0,0.3)). On desktop, trivial. On a budget Android WebView, catastrophic.

The Redmi Note 9 Pro thermal-throttles within 90 seconds when chaining multiple CSS filter primitives. The GPU cannot rasterize blur() and drop-shadow() simultaneously at 60fps on a Snapdragon 720G. The frame rate collapses to 15fps.

The architectural trade-off: replace dynamic CSS filters with static SVG noise tiles and pre-calculated opacity steps.

The paper grain at Level 4 is an inline SVG data URI rendered once as a ::before pseudo-element with pointer-events: none. The browser composites it as a single texture layer. Scan lines at Level 7 use repeating-linear-gradient, a static paint operation the GPU caches immediately.

On mobile, the @media (max-width: 480px) block reduces noise overlay opacity from 3% to 2% and trims letter-spacing from 0.3px to 0.2px, preventing the compositor from accumulating state across frames.

Result: 60fps locked on the Redmi Note 9 Pro, no thermal throttling on an AMD A4 laptop. The decay feels heavy. The rendering is lightweight.

The Somatic Impact of Visual Erosion

The decay system is not decorative. It is narrative machinery.

When the "CONTINUE" button on Day 35 overlays "BREATHE" in a flickering glitch, that is not visual polish. That is the interface speaking in a voice that is no longer the archivist's own. The paper is speaking. The archive is speaking. And what it says is: keep going, even though everything is dissolving.

Watching resource bars fade toward illegibility creates psychological tension faster than exposition. The player does not need to be told their situation is deteriorating. They can see it in the menu. The ink is running. The borders are fraying. The interface they trusted is becoming unreliable.

The UI is not separate from the story. It is a character in the story. And like every character in NICHLYST, it is subject to the same entropy, the same forty days, the same inevitable collapse.

Countdown to Production

With the September 30 Devpost deadline approaching, the decay system represents the final major technical milestone for the visual layer. The 14-day Closed Testing window on Google Play is underway, and the CSS architecture described here runs in production builds.

Every decay level has been tested against the 5-color palette constraint. Every opacity value verified against WCAG AA 4.5:1 contrast minimums. Every animation respects prefers-reduced-motion. The system is not a prototype. It is a production-ready framework built on CSS custom properties, SVG filters, and mathematical constraints.

Building NICHLYST: Eight Waves, One Canon — How 40 Days of Script Survived a Strict State Machine

Eugene Kozlovsky — Mon, 21 Sep 2026 19:55:09 +0000

It is Monday, September 21, 2026. Day 11 of the 14-day Google Play closed testing anabiosis. The clock runs on Google's terms, not mine. Outside the window in Kyiv, the air siren has just ended its third cycle of the morning. Inside, on an aging AMD A4 laptop with 4 GB of RAM, the terminal holds its breath. The bundle compiled. The state machine holds. There is nothing to add today, and that restraint is the only reason the system still works.

This devlog is about the architecture that kept NICHLYST from consuming itself.

The Branching Trap

Narrative games with branching paths face a problem that most builders underestimate until it is too late. You write a day. You give the player two choices. Each choice sets a flag. The next day reads that flag and branches again. After ten days, you have 1,024 possible states. After twenty days, the number exceeds one million. After forty days with 130 flags, six moral axes, and 33 distinct endings, you are no longer writing a story. You are constructing a state-space explosion that will crush any naive implementation.

The naive implementation is always the same: a plain JavaScript object mutated from everywhere. A gameState property on a global window object. Flags set with gameState.flags.whatever = true. Resources modified with gameState.endurance += 10. Every UI component reads and writes to the same object. The first time something goes wrong, you spend four hours chasing a race condition between the save system and the choice renderer. The second time, you lose a player's progression. The third time, you delete the project.

NICHLYST has 40 days, 33 endings, 130 boolean flags, and six moral axes (truth, mercy, preservation, complicity, memory, survival). The game data alone weighs 230 kilobytes of JSON. The exponential explosion of possible states is not theoretical. It is the daily engineering reality.

The solution was not cleverer writing. It was a strict, ruthless state machine.

The Eight Waves of Canon

Before describing the machine, it helps to understand what the machine protects. The 40 days are not a flat sequence. They are partitioned into eight thematic waves, each with its own mechanical identity and narrative contract.

Wave 1: The Cold Awakening (Days 1-3). The bunker. The first visitor. The player learns to listen, to record, to choose between silence and speech. Mechanical introduction: resource gauges, flag system, the weight of early decisions.

Wave 2: The First Ruptures (Days 4-7). The network stirs. Taras brings diesel. Khoma brings bread. Solomiia brings chalk. Each visitor tests the player's instinct: protect the archive or protect the person. Trust begins to fracture.

Wave 3: The Tightening Net (Days 8-12). Surveillance escalates. The Directorate tightens its grip. Choices become binary: comply or resist, at increasing cost. The player's endurance drains faster. Hope flickers.

Wave 4: The Great Raid (Days 13-15). The climax of the primary arc. The raid, the evacuation, the silence. The player faces the transmission choice: broadcast the archive into the open air, or seal it in an iron crypt. The 33 endings branch from this threshold.

Wave 5: The Silence of Ash (Days 16-20). The postscript begins. The world above has stopped. The player sorts through burnt paper, frozen salt, severed telephone wires. The choices shrink to single sentences. Frost on iron. Chalk dust. An empty chair.

Wave 6: The Postscript Residue (Days 21-23). Phantom flora. Paper mice. Documents that curl and mutate in the damp. The archive begins to develop a life of its own, independent of the archivist's intent.

Wave 7: The Hallucinatory Drift (Days 25-33). The hidden postscript. Reality bends. Memory echoes surface. The player navigates a space between remembering and forgetting, where the moral ledger exerts its final pressure.

Wave 8: The Afterlife Reckoning (Days 34-40). The archive afterlife. What survives. What decomposes. What the world remembers, and what it does not. The final endings: transmission success, transmission failure, burial preserved, burial lost, mercy destruction, haunted destruction, echo, ashes.

Each wave has a distinct emotional register and mechanical behavior. The state machine does not care about themes. It cares about invariants. The eight waves exist so that the machine always knows which rules apply.

The Iron Container: Engineering the State Machine

The state manager lives in www/js/state_manager.js. It is 777 lines of JavaScript that enforce a single principle: no external code may mutate game state directly.

Here is the core of it.

class StateManager {
  #gameData;
  #resources = {};
  #flags = {};
  #archive = {};
  #currentDayId = 1;
  #gamePhase = 'main';
  #moralLedger = { truth: 0, mercy: 0, preservation: 0,
                   complicity: 0, memory: 0, survival: 0 };

  get resources() { return Object.freeze({ ...this.#resources }); }
  get flags() { return Object.freeze({ ...this.#flags }); }
  get moralLedger() { return Object.freeze({ ...this.#moralLedger }); }

  modifyResource(key, delta) {
    const config = this.#gameData.global_resources[key];
    if (!config) return;
    const current = this.#resources[key] ?? config.start;
    this.#resources[key] = Math.max(config.min,
      Math.min(config.max, current + Number(delta)));
    this.autoSave();
  }

  getStateSnapshot() {
    return {
      resources: this.resources,
      flags: this.flags,
      archive: this.archive,
      currentDayId: this.#currentDayId,
      moralLedger: this.moralLedger
    };
  }
}

Every getter returns a frozen copy. Every mutation goes through modifyResource or applyDeltas, both of which clamp values between config.min and config.max (0 and 100 for most resources). The #private fields mean that if some UI component tries state.resources.endurance = 999, it simply fails. The property does not exist on the frozen copy. The internal #resources object is unreachable from outside the class.

This is not fancy engineering. It is defensive engineering. The distinction matters when you are building on a laptop that freezes if you open too many Chrome tabs.

The applyChoice method is the central pipeline. A choice arrives. Base deltas are applied and clamped. Conditional effects fire if the relevant flag is set. Flags are written. The moral ledger updates. Fatigue accumulates. Attention restores. Testimony corruption tracks. Weather effects apply. Surveillance stress penalizes endurance above 70. Codex fragments unlock. Memory echoes surface. Delayed notifications schedule. Screen readers announce the change log. At the end of the pipeline, getStateSnapshot() hands the UI a frozen, immutable snapshot. The UI never touches the internal state. It receives a photograph, not a live feed.

Antifragility in Practice

The rule of graceful degradation was simple: if a system is missing, skip it. If a flag is undefined, treat it as false. If a resource key does not exist in the schema, ignore the delta silently. If the save file is corrupted, clamp resources to valid bounds and set #tampered = true rather than crashing.

modifyResource(key, delta) {
  const config = this.#gameData.global_resources[key];
  if (!config) return;           // Unknown key: silent skip
  const current = this.#resources[key] ?? config.start;
  this.#resources[key] = Math.max(config.min,
    Math.min(config.max, current + Number(delta)));
  this.autoSave();
}

The restoreFromData method validates every field on load. Missing fields get defaults. Out-of-range values get clamped. The validateResources helper returns a corrected object alongside a valid boolean. If the save was tampered with (detected via HMAC-SHA256 signature in SaveManager), the system logs a warning to Sentry, sets the tamper flag, and continues. The player never sees the corruption. The game continues to function. This is antifragility: the system does not merely survive disorder, it absorbs disorder and carries on.

The Final Countdown

September 24 approaches. The 14-day closed testing window ends. Nine days remain until the final Devpost submission. The state machine holds. The 40 days compile into a single 230-kilobyte JSON bundle. The 33 endings remain intact. The 130 flags initialize cleanly on every fresh session.

There is a peculiar discipline in building something that must not change. The urge to add one more feature, one more flag, one more ending is constant. The correct response is always the same: no. The architecture is the architecture. The eight waves are the eight waves. The iron container holds what it was built to hold.

Outside, the sirens will sound again. The AMD A4 will spin its fan. The terminal will display its output. The state machine will clamp its values between 0 and 100, freeze its snapshots, and hand them to a UI that never touches the source. This is how a solo builder in wartime Kyiv keeps forty days of branching narrative from collapsing into chaos.

One wave at a time. One invariant at a time. One frozen snapshot at a time.

Building NICHLYST: The 14-Day Clock, the "Web App" Illusion, and Hardening the Archive

Eugene Kozlovsky — Sun, 13 Sep 2026 14:04:23 +0000

On September 10th, at 10:19 AM, the system finally turned green.

12 Testers Google Play

Twelve confirmed, opt-in testers. The threshold is met.

The 14-day Google Play closed testing clock is officially locked.

For the next two weeks, NICHLYST sits in a state of anabiosis. My role has shifted from "Builder" to "Watcher." But as any builder who has ever shipped knows, the moment you stop building is the moment you start seeing the cracks.

This week was the week of the "Web App" realization—a harsh feedback loop that transformed the project from a browser experiment into a tactile, native experience. When debating the native app vs web app architecture early on, I chose the web for speed. But the reality of shipping a Capacitor mobile app forced me to deeply reconsider the native app web app comparison. Under the hood, it relies on a native app WebView, but the user’s hand is the ultimate critic.

The "Web App" Illusion

A few days ago, I sat with the build on my Redmi Note 9 Pro. I was looking for glitches, for paywall bugs, for layout breaks. Instead, I saw a reflection of my own haste. Good mobile app UX design demands more than just functional code; it demands physical empathy.

The game felt like a website wrapped in a thin layer of Android glue. The scrolling lacked inertia, the buttons felt like generic text inputs, and the total absence of tactile feedback made the bunker feel... hollow. In a game about the "slow weight of testimony," the interface felt weightless.

When you build with Capacitor, the browser is your engine, but the user’s hand is the ultimate critic. If the scrolling doesn't have momentum, or if the system doesn't acknowledge a tap with a haptic tick, the user subconsciously knows they are looking at a document, not a world.

I spent 48 hours purging "web-isms":

Kinetic Scrolling & Notch Awareness: I replaced browser-default scrolling with CSS momentum and reclaimed the pixels stolen by the Android camera cutout. The UI is no longer "pushed" by the hardware; it flows around it.

/* Preventing overscroll bounce on body for native feel */
body {
  overscroll-behavior: none;
  -webkit-user-select: none;
  touch-action: manipulation;
}

/* Kinetic scrolling on individual scroll containers */
.scroll-container {
  -webkit-overflow-scrolling: touch;
}

/* Safe area inset padding for notch awareness (injected via NativeBridge) */
:root {
  --nl-safe-area-top: env(safe-area-inset-top, 0px);
  --nl-safe-area-bottom: env(safe-area-inset-bottom, 0px);
}

Capacitor Haptics

Tactile Haptics: When the Interface Feels Real

Tactile Feedback: If you are looking for a quick Capacitor plugin tutorial, the setup is straightforward. I integrated the @capacitor/haptics plugin. Every choice button now triggers a light pulse; every raid event or consequence trigger results in a distinct, medium haptic impact.

It is a small set of changes, but the difference between "viewing a site" and "holding an archive" is exactly the sum of these details.

Mobile Game Security

Security as a Feature: Hardening the Archive

In the first devlog, I wrote about an antifragile architecture. But when evaluating mobile game security, antifragility means nothing if the system is insecure. If your monetization is a bypassable localStorage flag, you haven't built a business; you've built a suggestion.

I audited the security of the payment flow this week. The results were sobering.

I had hardcoded the RevenueCat public keys and relied on weak integrity checks for save files. During the Shipaton, your work is not just being reviewed by judges; it is being probed by the entire community.

I implemented two critical hardening layers:

djb2 Checksum Integrity: Every save file now contains a djb2 checksum. If a user tries to modify their memory_integrity or guilt stats in the JSON, the checksum mismatch triggers a safe recovery protocol (backup restore) rather than a game-breaking crash.
Runtime Security: I stripped out the placeholder keys and implemented a strict build-time injection via sed in the Codemagic CI pipeline. The debug harness now checks for a native platform and a __DEV_MODE__ flag before initializing. If you are running a production build, the debug triggers are inert—they exist in the source but are gated by runtime checks that never pass on a signed APK.

Shipaton is about shipping, but it is also about shipping securely. If the paywall can be bypassed by opening the Chrome DevTools, it isn't "shipped," it's "leaked."

The 14-Day Clock and the Silence

The silence of the Google Play closed testing period is psychological warfare.

I have 15 testers now, well above the minimum Google Play testing requirements. I am waiting for the algorithm to tick over. In the meantime, I have stopped trying to "play" the game. I have stopped trying to find new features. The roadmap for Days 16 through 40 is written. The narrative is heavy. The engine is stable.

I am not optimizing for "more" anymore. I am optimizing for "deep."

For the next two weeks, the only work that matters is the polish of the remaining chapters. I am refining the weight of the testimonies—making sure that when a courier enters your bunker, you feel the cold air behind him.

My hands are steadier now. The medication adjustment is helping, and the rhythm of the building process has become a cage I am happy to live in. We don't have control over the city outside the window, but we have control over the bunker inside the phone.

The Archive demands a key. We are just waiting for the door to open.

Follow this devlog for the final sprint of the #BuildInPublic journey toward the RevenueCat Shipaton 2026.

Building NICHLYST: Explosions, Medication, and Rewriting 15 Days as a Novel You Can Fail

Eugene Kozlovsky — Sun, 06 Sep 2026 07:58:32 +0000

On Saturday evening, August 29th, I was lying on my sofa after eating way too much watermelon. I was taking a short break from writing the narrative core of my game, NICHLYST, pushing the limits of narrative game design for the RevenueCat Shipaton 2026.

Then the shockwave hit.

It sounded like heavy crushed stone slamming against sheet iron. The protective netting we installed to keep our cat from falling out of the window was blown a meter across the balcony to the door. I threw on my sneakers, grabbed my walking cane, tossed a piece of chewing gum in my mouth, and quickly messaged my family that the blast was so loud I nearly crapped my pants. Then I ran downstairs to see if our building was hit and if anyone needed help.

It turned out to be falling debris from a downed "Shahed" attack drone about 300 meters away. If the drone itself had hit the building, the consequences would have been much worse, and the windows in my apartment would have undoubtedly shattered.

When the initial adrenaline faded, my hands started shaking uncontrollably. You do not design survival mechanics when physical survival is being decided 300 meters from your desk. You just shake. I took a tranquilizer—the kind I keep strictly for situations when I feel a panic attack imminent or during severe stress—went back up to my apartment, sat down at my old AMD A4 PC, and opened VS Code.

On Wednesday, September 2nd, I had my regular online appointment with my psychiatrist. The verdict was recorded clinically: "State without significant changes. Changing Sertraline to Fluoxetine."

But the code has to ship. The 14-day Google Play closed testing rule does not care about my neurochemistry or the craters in my neighborhood.

Here is how the architecture and narrative of NICHLYST evolved this week through the fog of war, community feedback, and medication changes.

Filling the Void: Writing a Novel You Can Fail

In my last devlog, I shared the architectural shift of throwing away the 1-sentence script and refactoring the UI to support 4-phase literary chapters (Awakening → Approach → Encounter → Dilemma).

But building the container is easy. Filling it with prose that justifies a $4.99 premium unlock—the entire indie game monetization strategy for NICHLYST—is brutal.

This entire weekend was dedicated to writing the Prologue and Acts I through IV (Days 1–15). Because this is a game without 3D models or combat mechanics, the pacing has to rely entirely on syntax.

On Day 12 (The Raid), I wrote the text using fragmented, staccato sentences to simulate a panic-induced adrenaline spike: "Impact. The concrete shudders. Dust. Tactical flashlights slice the darkness like strobes."
On Day 13 (The Aftermath), the syntax completely changes. The sentences become long, heavy, and meditative, reflecting absolute, deafening silence after the violence has passed.

The RevenueCat Paywall Threshold

The monetization flow was also deeply integrated into this narrative pacing. The $4.99 paywall now appears precisely at the end of Day 3, not as a jarring commercial banner, but as an in-lore narrative threshold: "The Archive demands a key. Without a key, the blast door remains shut."

It’s not an interruption; it’s a pause before the descent.

Diegetic Accessibility: Subtitles That Whisper

A brilliant piece of feedback came from a community discussion on accessibility (a11y). Someone asked: How do deaf players, or people playing on mobile with the sound muted, experience an atmospheric audio-horror game?

My initial thought was to add generic tags like [wind blows] or [silence]. But that breaks the magic realism of the world.

Instead, I built a diegetic subtitle engine in AudioManager.js using the aria-live polite pattern for screen readers. The subtitles do not describe the sound; they describe the psychological weight of the room.

Instead of [silence], the subtitle reads: "[The room holds its breath and quietly laughs]"
Instead of [distant noise], it reads: "[A fragile violin is choked by the distant roar of turbines]"

<!-- AudioManager.js: Diegetic subtitle container -->
<div
  id="diegetic-subtitles"
  role="status"
  aria-live="polite"
  aria-atomic="true"
  class="whisper-layer">
</div>

If the Archivist's mental state is compromised (e.g., the codeine_faith state where clarity is artificially high but endurance is dead), the JavaScript dynamically stretches the typography of the subtitles, injecting slow ellipses and spaced letters ("...k-n-o-c-k... a-t... t-h-e... d-o-o-r...").

Accessibility became a core narrative mechanic.

Somatic UI: When the Interface Feels Pain

To further separate the game from mere "stat management," I implemented somatic micro-gestures directly into DayScreen.js and the CSS.

If your endurance drops below 10, the choice buttons do not appear. You are physically too weak to make a decision. Instead, a single, violently trembling button renders: [Bandage hands to stop them trembling...]. You have to click it, watch the 1-second CSS animation stabilize, and only then do the real narrative choices reveal themselves.

If your guilt exceeds 80, the morning rendering of the day screen is accompanied by a 1-second overlay of muddy rust-sepia (.ds-pain-sun). The interface itself degrades with your psyche.

Antifragility: Breaking the JSON Monolith

On the engineering side, I realized I had built a massive single point of failure.

NICHLYST runs entirely on a master file: game_data.json. It holds 40 days, 31 endings, all the codex fragments, and 116 persistent flags. It was over 4,000 lines long. One missing comma on Day 39, and JSON.parse would fail on boot, crashing the game on Day 1.

That is fragile.

So, I wrote a Node.js workflow to decouple the data. I split the narrative into modular files: prologue.json, act_1.json, postscript.json.

// A fragment of the bundler script that ensures dual redundancy
const manifest = JSON.parse(fs.readFileSync('www/data/manifest.json', 'utf8'));
// The script compiles the isolated acts back into the master file at build time.

Now, the engine's loader attempts to fetch the modular manifest first. If a network request drops or a module is corrupted, it gracefully falls back to the bundled monolith—a core principle of graceful degradation JavaScript in production environments.

// manifest-loader.js: Promise.allSettled pattern for module resilience
const moduleUrls = [
  'www/data/prologue.json',
  'www/data/act_1.json',
  'www/data/act_2.json',
  'www/data/postscript.json'
];

const results = await Promise.allSettled(
  moduleUrls.map(url =>
    fetch(url).then(r => r.json()).catch(err => ({ error: err.message }))
  )
);

const loadedModules = results
  .filter(r => r.status === 'fulfilled')
  .map(r => r.value);

// Fallback to bundled monolith if critical modules failed
if (loadedModules.length < moduleUrls.length) {
  console.warn('Falling back to bundled game_data.json');
  return fetch('www/data/game_data.json').then(r => r.json());
}

The game survives.

Google Play Closed Testing: The 14-day Clock is Locked

I finally completed the formal verification of my Google Play Developer account.

The verdict: The 14-day closed testing rule is mandatory. There is no bypass.

To meet the Shipaton deadline on September 28th, I must launch the closed test track no later than Tuesday, September 8th. The timer does not start when you upload the APK. It starts when the testers physically click Opt-In.

Google Play 12 Testers Requirement

The good news? The Shipaton organizers recently confirmed that the threshold to pass isn't 20 testers—it's 12+ active opt-ins. I already have 15 volunteers from the community. My task for the next 72 hours is to finish writing the Postscript chapters, integrate Sentry for error tracking, and hit the "Start Test" button.

My hands still shake sometimes. The explosions haven't stopped. The medication is adjusting. But the engine is stable, the narrative is heavy, and the architecture is antifragile.

I'll see you in the Archive.

Follow this devlog for the final sprint of the #BuildInPublic journey toward the RevenueCat Shipaton 2026.

Building NICHLYST: How to Code a Survival Engine When You Are Failing to Survive

Eugene Kozlovsky — Sat, 29 Aug 2026 15:58:32 +0000

Building NICHLYST: How to Code a Survival Engine When You Are Failing to Survive

I track everything. It is an occupational habit of a systems architect. You cannot fix what you do not measure — not a failing build, not a leaking color, and not developer burnout. And if you are reading this while grinding through the RevenueCat Shipaton 2026 yourself, you already know that the hardest metric to log honestly is your own state.

So, let me share some metrics.

Clinical Baseline: A PHQ-9 Depression Score of 21

On May 11, 2026, my clinical assessment scores were:

PHQ-9 (Depression): 21. Severe. Immediate professional intervention required.
GAD-7 (Anxiety): 11. Moderate.

On August 22, 2026, in the middle of the RevenueCat Shipaton, I took the assessment again.

PHQ-9: 21. No improvement.
GAD-7: 16. High anxiety. Daily functioning severely impaired.

If you have never read a GAD-7 anxiety assessment, 16 sits deep in the high-anxiety band — the zone where "daily functioning severely impaired" stops being a clinical phrase and becomes your actual schedule.

While I was typing the very first lines of this post, a massive explosion went off, loud enough to make my ears pop. About an hour later, the local news feeds brought the context: an attack drone had been shot down over a park roughly two and a half kilometers from my house. According to the updates, the falling debris killed a two-year-old child and injured two adults.

I am developing a narrative game about survival, the fragility of life, and human behavior under immense pressure. But here, in Kyiv, these are not abstract game mechanics or dramatic tropes to be monetized. They are the immediate, absurd, and brutal reality outside my window.

I am exhausted. The clinical scores haven't moved in months. I sleep in the middle of the day because my nervous system simply shuts down. I am looking at this hackathon as a final, desperate push to build something sustainable.

But here is the thing about the antifragile development plan I wrote about in my first devlog: it does not require me to be okay.

The code does not care about my PHQ-9 score. The system is designed to absorb the collapse of its creator and keep moving forward.

Here is exactly how NICHLYST advanced technically and narratively over the last grueling week, while its developer was barely holding on.

The Git Gatekeeper: A Git Pre-commit Hook Enforcing a 5-color Dictatorship

NICHLYST has a strict, uncompromising visual identity. It is built exclusively on a limited color palette of five: #232626 (Pitch Dark), #3E403F (Slate), #736758 (Sepia), #A69B8D (Ash), and #BFB3A4 (Bone).

I spent hours auditing the entire codebase via terminal (grep -rnE "#([0-9a-fA-F]{3,8})\b") to eradicate every stray #FFFFFF or #000000 from CSS, inline SVGs, and Android capacitor.config.ts. I even wrote a Python script to batch-process all graphic assets through a mathematical gradient map, ensuring absolute compliance.

But human beings make mistakes. Exhausted human beings make a lot of mistakes.

So, I took the human out of the loop. I wrote a pre-commit Git hook (check_colors.sh) that acts as an Anti-Color-Leak Gatekeeper, physically verifying every staged file against our strict 5-color whitelist before allowing a commit:

#!/bin/bash
# ==============================================================================
# NICHLYST — Anti-Color-Leak Gatekeeper (Pre-commit Hook)
# Strictly allowed 5-color palette (case-insensitive, 6 or 8-digit hex):
# #232626, #3E403F, #736758, #A69B8D, #BFB3A4
# ==============================================================================

ALLOWED_PATTERN="^#((232626|3e403f|736758|a69b8d|bfb3a4)([0-9a-fA-F]{2})?)$"

# Determine files to check: staged in Git, or all www/ files on manual execution
FILES_TO_CHECK=$(git diff --cached --name-only --diff-filter=ACM 2>/dev/null)

if [ -z "$FILES_TO_CHECK" ]; then
  FILES_TO_CHECK=$(find www -type f \( -name "*.css" -o -name "*.js" -o -name "*.html" \))
fi

EXIT_CODE=0
FOUND_ERRORS=0

for file in $FILES_TO_CHECK; do
  # Skip binary assets, fonts, audio files, and the check script itself
  if [[ "$file" =~ \.(png|webp|jpg|jpeg|svg|ico|ttf|woff|woff2|mp3|ogg|wav)$ ]] || [[ "$file" == "scripts/check_colors.sh" ]] || [[ ! -f "$file" ]]; then
    continue
  fi

  # Find all 3, 6, and 8-character HEX colors
  HEX_MATCHES=$(grep -onE "#[0-9a-fA-F]{3,8}\b" "$file" 2>/dev/null)

  if [ -n "$HEX_MATCHES" ]; then
    while IFS= read -r match; do
      LINE=$(echo "$match" | cut -d: -f1)
      HEX=$(echo "$match" | cut -d: -f2)
      HEX_LOWER=$(echo "$HEX" | tr '[:upper:]' '[:lower:]')

      # Validate against the allowed palette whitelist
      if ! echo "$HEX_LOWER" | grep -qE "$ALLOWED_PATTERN"; then
        echo "🚨 [STOP-LOSS] Unauthorized color '$HEX' in $file:$LINE"
        EXIT_CODE=1
        ((FOUND_ERRORS++))
      fi
    done <<< "$HEX_MATCHES"
  fi
done

if [ $EXIT_CODE -ne 0 ]; then
  echo ""
  echo "❌ COMMIT REJECTED! Found $FOUND_ERRORS unauthorized color values."
  echo "   NICHLYST strictly allows only 5 colors: #232626, #3E403F, #736758, #A69B8D, #BFB3A4."
  exit 1
fi

echo "✅ [COLOR-GUARD] All colors comply with the official NICHLYST palette."
exit 0

If I am tired and accidentally style a button with #FFF, the system physically rejects the commit. The system enforces the aesthetic when my brain cannot.

The Narrative Rewrite: Narrative Game Design — Why I Threw Away the Script a Month Before Release

A few days ago, I booted up the local server, clicked through the first three days, and felt nothing.

The engine worked perfectly. The resources depleted. The RevenueCat SDK integration was flawless (the paywall triggers exactly after Day 3). But the text was dry.

“Khoma arrives. He has evidence. Do you take it?”

If you are going to charge $4.99 for a narrative game — my entire indie game monetization strategy is that one honest purchase, no dark patterns — the text must react to the player's conscience. It cannot be a telegram. The player must feel like they are reading an elite, heavy book where they are the protagonist.

So, I rewrote the JSON schema and refactored the UI (DayScreen.js).

Instead of a single string, the engine now accepts a chapter_narrative array, breaking every day into four distinct phases:

Awakening: The somatic feeling of the basement. Cold concrete, heavy lungs.
Approach: The footsteps outside the blast door. The anxiety before the knock.
Encounter: The dialogue and the evidence.
Dilemma: The moral trap where there are no good options.

I updated the CSS to handle this like true typography. I added an isolated scrolling container, a cascading fade-in animation, and a drop-cap (::first-letter) to the opening paragraph so the text feels tactile and deliberate:

/* ─── Narrative Scroll Area (multi-paragraph chapter_narrative) ── */
.nl-narrative-scroll-area {
  flex: 1 1 auto;
  overflow-y: auto;
  max-height: calc(100vh - 290px);
  padding-right: 8px;
  margin-bottom: 1.25rem;
  scrollbar-width: thin;
  scrollbar-color: var(--c-3) var(--c-1);
  -webkit-overflow-scrolling: touch;
}

.nl-narrative-scroll-area::-webkit-scrollbar {
  width: 4px;
}
.nl-narrative-scroll-area::-webkit-scrollbar-track {
  background: var(--c-1);
}
.nl-narrative-scroll-area::-webkit-scrollbar-thumb {
  background: var(--c-3);
  border-radius: 2px;
}

/* ─── Narrative Paragraph (book typography) ──────────────────── */
.nl-narrative-paragraph {
  font-family: var(--font-serif, "Georgia", serif);
  font-size: 1.05rem;
  line-height: 1.7;
  color: var(--c-5);
  margin-bottom: 1.25rem;
  text-align: justify;
  opacity: 0;
  animation: nlParagraphFadeIn 0.35s ease forwards;
}

.nl-narrative-paragraph:nth-child(1) { animation-delay: 0.05s; }
.nl-narrative-paragraph:nth-child(2) { animation-delay: 0.15s; }
.nl-narrative-paragraph:nth-child(3) { animation-delay: 0.25s; }
.nl-narrative-paragraph:nth-child(4) { animation-delay: 0.35s; }
.nl-narrative-paragraph:nth-child(n+5) { animation-delay: 0.45s; }

/* Drop cap on the opening paragraph */
.nl-narrative-paragraph:first-of-type::first-letter {
  font-size: 2.6rem;
  line-height: 0.85;
  float: left;
  margin-right: 0.45rem;
  margin-top: 0.15rem;
  font-family: var(--font-serif, "Georgia", serif);
  color: var(--c-5);
  font-weight: bold;
}

@keyframes nlParagraphFadeIn {
  from { opacity: 0; transform: translateY(4px); }
  to { opacity: 1; transform: translateY(0); }
}

The engine now supports deep, multi-paragraph storytelling while gracefully falling back to old single-string descriptions for days I haven't rewritten yet.

Expanding the Dictionary of Despair

To ensure the new writing hits the exact psychological notes required, I expanded the game's internal game_data.json dictionaries. I added new tone keywords for the AI-assisted generation prompts:

Wave 4: chemical apathy, cognitive dissonance, claustrophobic giant.
Wave 6: telegraphic despair, spatial erasure, terminal apathy.
Wave 8: somatic overflow, phantom flora, sensory dissonance.

I also added a new piece of deep lore to the Codex: Directive 44. In the world of NICHLYST, the totalitarian Directorate has officially banned "vocal warmth" and empathy in speech as signs of psychological instability, punishable by ration forfeiture. This justifies the dry, brutal tone of the game's UI.

Securing the Perimeter (Via Negativa)

Marketing is not just about posting; it is about squatting. I spent one evening locking down the digital perimeter.

I registered the GitHub Organization, secured the domain koztechie.pp.ua (and deployed a blazing-fast Eleventy static hub onto Netlify), claimed @nichlyst on X, Instagram, TikTok, Bluesky, Threads, and Itch.io.

I also had "Create a subreddit" on my to-do list. But I looked at Reddit's current corporate ecosystem, the CAPTCHAs, the shadowbans, and the decay of the open web.

Aaron Swartz didn't fight for a closed corporate silo. I crossed the task off. NICHLYST is anti-Reddit. We rely on the open web, RSS, Dev.to, HackerNoon, and direct code. This is Taleb’s Via Negativa in action: removing the fragile elements to make the whole system stronger.

The 20-Tester Wall Remains

The game is structurally complete. The monetization is wired. The narrative is being rewritten into something profoundly heavy.

But Google Play’s bureaucratic wall still stands. I need 20 active testers to keep the app installed for 14 days, or I cannot launch on time for the Shipaton.

I currently have 15. I need 5 more.

If you are an Android user and want to help a developer who is pouring the last drops of his nervous system into this engine, please fill out this form. No heavy QA needed. Just accept the invite, install, and hold it on your phone.

👉 https://forms.gle/4hJkWsmuyKp3Tgtr8

I am starting my day with a selective serotonin reuptake inhibitor (SSRI) and eight other pills or capsules differing in shape, color, size, and purpose, just to keep my body and nervous system functioning. But the engine breathes. The infrastructure holds.

The antifragile plan works. I'll see you at the finish line.

Follow this devlog for the #BuildInPublic journey toward the RevenueCat Shipaton 2026.

Building NICHLYST: Two Mugs, a Black Screen, and the Weekend the Engine Woke Up

Eugene Kozlovsky — Sun, 16 Aug 2026 13:46:07 +0000

A friend came by last Thursday and handed me a mug she had brought from Bulgaria. On the mug was a Kama Sutra position so acrobatic that gravity itself seemed ready to file a complaint. "So that there would be love," she said. It felt strangely appropriate: the thing on my desk that week was a half-asleep HTML5 game engine, and it was going to need exactly that kind of stubborn love to wake up.

I already own a hackathon mug. It says: "I participated in the world's largest hackathon and all I got was this mug." And what is written there is the honest truth.

That mug is my main one now. Every day I brew Assam in it, plus a soluble chicory-and-barley drink, and I sit with it through work and through my own projects. The project I received it for last summer no longer exists. I chose not to develop it, for reasons that deserve their own separate silence. But the mug stayed — as a reminder of what I was able to build once, and as a quiet, stubborn motivation to do it again.

The new mug won for pure practicality. Six hundred milliliters. When you spend your days holding other people's infrastructure together and your evenings turning a vision into prompts, you are always drinking something, and 600 ml is the right amount of continuity.

Projects die. Mugs survive. Objects outlive the work that made them. I keep thinking about that while I build a game about keeping records after everything else has burned.

By the morning of August 16th, the plan had quietly eaten steps 49 through 86. Let me explain.

The Audio Phase: ElevenLabs Sound Effects

The second devlog ended on a promise: the audio phase, then the engine. The audio came together first. I wrote the key voiceover lines and generated the voice — and then, without planning to, made a discovery: ElevenLabs also generates sound effects astonishingly well. The ambient layers and the small diegetic motifs of the game were born there too. I did not expect a voice tool to hand me wind, hum, and a door that creaks without moving. I normalized everything on my Xiaomi, committed, and backed the folder up before I allowed myself to feel satisfaction.

Vibe Coding Tools 2026: OpenCode vs Antigravity CLI

The engine needed a different kind of help. Until recently I vibe coded with Antigravity CLI, and it was extremely convenient — exactly as long as my paid Google subscription lasted. The moment the subscription ended, the limits became laughable. Less than thirty minutes of vibe coding, and the tank was empty. So I switched to OpenCode. Even unpaid, its limits are enough to actually work, and OpenCode vibe coding quickly became my default rhythm: open the terminal, describe the intent, review the diff, commit. On Saturday I opened it, and something clicked.

If you are compiling your own shortlist of the best vibe coding tools 2026, here is my field data from one weekend: Antigravity CLI is brilliant while the quota lasts, and OpenCode is the tool that keeps a solo dev walking when the quota dies. The winner of any comparison is not the smartest model — it is the one whose limits let you finish an evening session.

The Engine Wakes Up

What followed is hard to describe as a sequence, because it stopped being one. The plan's steps blurred into a single long evening and then another. A state manager that reads the frozen JSON and loads its initial truths from it. A persistence layer — autosave after every meaningful event, because a mobile game that loses your guilt when the OS kills the process is not a game, it's a scam. A renderer for the day screen. A pipeline that resolves choices and their delayed consequences. A parser that reads condition strings and picks an ending from the data. Transitions between narrative layers. A UI that slowly decays after the finale, the way the design document always promised it should.

Then the wiring: backgrounds, portraits, audio — everything the art pipeline had produced, connected to the machine. Every subsystem arrived with a checklist and at least one test scenario, because on a weak PC with a weak margin for error, "it seems to work" is not a status. Commits landed before 23:00. The 23:00 rule from the first devlog is still alive; some rules survive precisely because they are boring.

Thirty-eight game development milestones closed in one weekend. Three of them had to be closed twice. That ratio is the honest metric of solo development.

The Black Screen

Because here is what happened the first time I wired the art: the game launched and showed me a header, two buttons, and a black void where the narrative was supposed to be.

Diagnosis first, guess-fix never. The render pipeline was interrupting itself the moment an asset manifest request failed. And the manifest was a lie I had written: it expected file names I had invented, while the disk held file names the generator had invented. Two fictions that had never met.

The fix became a contract. The narrative renders even if every optional subsystem dies. Every fetch gets a catch. And the manifest is no longer written by hand — it is regenerated from the disk, because the disk is the only source of truth; anything the script can't recognize goes to a quarantine list, never into the game by guesswork. When I reloaded and heard the knock — cautious, irregular, exactly as designed — I sat still for a while. The JSON was no longer a document. It was a place.

Monday Is Coming

On Monday, rehabilitation begins. Three to four hours a day, including the road. I don't yet know the exact slot, which means the schedule has to absorb an unknown shape — again. My sessions with the psychologist are also coming to an end; one is left, and I caught myself grieving in advance for a structure that taught me to stand without structures.

This is what the war years do to a plan. Not always with sirens. Sometimes just with the slow accumulation of appointments, procedures, endings, and beginnings, while the city stays hot and the air stays loud enough to be a baseline. You don't get heroic days. You get days. The antifragile plan from the first devlog was written for exactly this: the schedule bends, it does not break. Rehabilitation goes into the calendar. The 23:00 rule stays. The mug travels to every desk I sit at.

The Tester Wall: Google Play 20 Testers, Almost Down

Since the second devlog, the tester form has grown to 14 emails. I need 6 more. That's it. That is the whole distance between me and the Google Play production track.

If you are reading this, have an Android device, and two minutes to spare:

👉 https://forms.gle/4hJkWsmuyKp3Tgtr8

Accept the invite later, install the app, keep it for 14 days. No deep QA. Just your presence to satisfy the algorithm.

What Comes Next

The engine breathes. Next is money and time: the RevenueCat SDK and the paywall, the push-notification architecture — the diegetic knocks that arrive hours after a choice — the demo video under two minutes, and a Codemagic build my testers can hold.

NICHLYST is coming. And now it remembers.

Follow this devlog for the #BuildInPublic journey.

Building NICHLYST: The Weight of 40 Days, 29 Endings, and a Style Anchor

Eugene Kozlovsky — Thu, 13 Aug 2026 21:01:28 +0000

Three days ago, I published the first devlog for the RevenueCat Shipaton 2026. Diving deep into the heavy, emotional trenches of narrative game design, I had a 128-step plan, a blank APK, and 3 Google Play testers. Today, I have 40 days of structured narrative content, 29 endings, a full art pipeline, and a very familiar tightness in my chest.

Let me explain.

The Content Freeze

Between August 10th and August 13th, I completed a massive chunk of the antifragile plan. The most critical milestone was the content freeze.

What does "frozen" mean? It means NICHLYST now has a definitive shape. Unless a miracle happens and I find myself far ahead of schedule with time to consider expanding the lore, the scope is now locked. The JSON file that drives the entire game has been committed, tagged, and backed up to Google Drive.

Here is what that structure looks like:

40 days of narrative content.
29 endings (main and hidden).
Multiple resource counters (some visible to the player to manage survival, others running silently under the hood, tracking psychological and moral degradation).
Over 100 global flags tracking every choice the player makes.

Instead of relying on a rigid game design document template, I wrote the initial script as a markdown document, then structured it directly into JSON. The English translations were finalized alongside the Ukrainian originals, as the hackathon requires all submission materials in English.

The Moral Audit

Before freezing the content, I ran a moral complexity audit on the entire game. My design formula is simple: every choice must pit the value of testimony against the cost of survival. No binary good/evil. No easy outs.

The audit checked every single day for six criteria: no binary good/evil, testimony vs. survival tension, consequence weight, emotional cost, no easy outs, and narrative coherence.

The audit found 39 out of 40 days passing all six checks. One day failed.

It was a breathing space between two heavy acts. The problem? Both choices had zero mechanical consequences. No resource deltas. No flags set. The player could experience the day as cost-free.

That is a violation of the core design philosophy. In NICHLYST, nothing is free. So I fixed it: accepting help now costs a psychological resource (the moral weight of compromise), and refusing help costs a social resource (the cost of pride). The fix was committed, and the content was frozen.

The audit also identified some of the game's strongest moral scenes — moments where the player must decide whose memory gets preserved, whose identity gets erased, and whether to warm the paper archive or the living people in the freezing basement. These are not fun choices. They are not supposed to be.

The Art Pipeline: Style Anchor and Privacy

With content frozen, I moved to art generation. The design document specifies a "muted gouache and ink-wash illustration" style — desaturated, painterly, Eastern-European post-industrial. This is the style anchor.

I am using a single AI model for this: MAI-Image-2.5-Pro.

I rejected other tools because their creations are public by default. I am not publishing art before the game ships. Privacy is a stop-loss.

I generated a series of test images to validate the style anchor. Then I generated:

Character sheets and portraits for the Archivist and all visitors.
Base background locations for the underground node and the besieged city.
Postscript locations reflecting the slow decay after the finale.
Flat papercut UI icons for the visible resources.
The 1024×1024 app icon.

Every single image was manually audited against a negative checklist: no real flags, no military insignia, no celebrity likenesses, no readable text, no brand logos. One image initially had a pattern too close to real military gear. I regenerated it with explicit instructions for nondescript, worn winter gear without any insignia, and passed the audit.

The 23:00 Rule Met Reality

In my first devlog, I wrote about the 23:00 hard stop. I said an antifragile plan must absorb bad days.

I had bad days.

War breaks a person. Even a civilian one. It shatters the psyche. But paradoxically, it also builds a strange kind of callus. You start perceiving things not as acutely as you might have years ago. Explosions become background noise. But the internal pressure remains.

On August 10th, I felt the pre-panic state creeping in. A tightness in the chest, shallow breathing. I knew exactly what it was — I've been treating GAD for over a year. It didn't escalate into a full attack, but the physical toll was there. Sitting at my desk, trying to write JSON while my nervous system was bracing for an impact that wasn't coming.

On August 11th, Russian ballistic missiles hit Kyiv again. The explosions were loud. But I didn't panic. I just kept working. There is a strange detachment that develops — you hear the booms, you acknowledge the danger, and you return to the code. The anxiety that day wasn't about the missiles; it was the quiet, creeping dread of an exhausted mind.

None of these days were perfectly productive hackathon days. The plan bent.

But the plan did not break.

On the morning of August 13th, I sat down, opened VS Code, and committed the final content freeze. The JSON was valid. The art was generated. The moral audit was complete. The structure was intact.

The antifragile plan absorbed days of anxiety and war, and the project still shipped its milestones on schedule.

The Tester Update: Surviving the Google Play 20 Testers Requirement

In my first post, I asked for help with this exact bureaucracy.

I now have 6 emails.

It is progress, but the math is still unforgiving. I need 20 testers to bypass the 14-day closed testing wall before I can publish to production.

So, I am putting this directly into this devlog again. If you are reading this, have an Android device, and 2 minutes to spare, please help a fellow builder bypass this bureaucratic wall.
👉 https://forms.gle/4hJkWsmuyKp3Tgtr8

You will just need to accept an invite from Google Play later, download the app, and keep it installed for 14 days. No deep QA required. Just your presence to satisfy the algorithm.

What Comes Next

The content is frozen. The art is generated (resizing and compression are deferred to pre-APK build — another stop-loss decision to avoid perfectionism).

Next up: Phase 4 (Audio) and Phase 5 (Engineering — the game engine in HTML5/JS, reading from the JSON). The hardest part is still ahead. Writing a JavaScript state manager that tracks all these counters, flags, and ending conditions — all running inside a Capacitor Android wrapper on a phone.

But the foundation is no longer fragile. It is concrete that was poured during a heatwave, under missile alerts, through the fog of GAD.

NICHLYST is coming. And the content is frozen.

Follow this devlog for the #BuildInPublic journey.

Building NICHLYST: An Antifragile Approach to Surviving a Hackathon (and Reality)

Eugene Kozlovsky — Sun, 09 Aug 2026 21:30:57 +0000

I’m 36. From Kyiv.

Right now, my city is suffocating under a heatwave. At night, the air raid sirens wail, and the psychological weight of a war with no end in sight presses down on every decision. I am typing this on an AMD A4-4020 with 8GB of RAM — a machine so weak it chokes on modern web browsers. If you are reading this while also grinding through the RevenueCat Shipaton 2026, you already know the unique pressure of shipping under extreme constraints.

I am not a traditional developer. I am a practitioner of vibe coding with AI. To me, this isn't just a buzzword; it's a philosophy of orchestrating AI. It’s the ability to translate a feeling, an idea, or a complex vision into a precise prompt for a machine. It’s about bringing a concept to life, rather than getting bogged down in the syntax of writing code from scratch. By day, I work as a webmaster and system architect, navigating a full-time job and a complex medical regimen.

Yet, I am entering the hackathon. Alone. Against teams with M2 Macs and budgets.

Why? Because I don't just want to build an app. I want to prove that constraints don't kill projects. Fragility does.

This is the story of NICHLYST — a slow narrative survival-archive sim for Android — and the 128-step antifragile plan I wrote to ensure it actually ships by September 28th.

The Concept: Survival as a Gameplay Loop

In NICHLYST, you are an archivist in a besieged city. You don't fight. You record. Every day, someone knocks on your door with a story. You must choose: record the full truth and risk your safety, or edit it to survive. The consequences don't arrive immediately — they arrive days later, via a real-time push notification, forcing you to live with the anxiety of your choices.

It’s a game about documentation, truth, and the civilian experience of conflict.

Phase 0: The Pre-Mortem

Most hackathon projects die because developers start coding on day one. I started by writing a 128-step plan, but before writing a single line of code, I forced myself to do a pre-mortem.

I listed the 10 most likely ways NICHLYST would fail. Here they are, raw and unfiltered:

My weak local PC freezing during an Android build.
Solo development bottlenecks.
Missed evenings due to fatigue or schedule conflicts.
Google Play App Review delays.
AI art style mismatch or inconsistency.
RevenueCat sandbox failure or SDK integration issues.
Missing the hard deadline entirely due to scope creep.
Psychological burnout.
Catastrophic loss of content or code.
Conflict with an existing 32-day evening schedule I must maintain.

Then, I applied Nassim Taleb's Antifragility framework. I didn't just want to mitigate these risks; I wanted the project to benefit from the stress.

The Barbell Strategy: I allocated 90% of my time to the core, guaranteed MVP. The other 10% is strictly time-boxed for bonus categories. If you are constantly researching how to avoid scope creep, the secret is that the "middle ground" — medium-risk, medium-reward tasks — must be entirely eliminated.

Stop-Loss Dates: I hardcoded triggers into my plan. If the AI art pipeline isn't done by August 26th, I don't argue with myself. I automatically cut the art scope to a stark, 1-bit CSS visual filter and move on. Emotion has no place in the schedule.

Developer Burnout Prevention

To survive a solo hackathon, I rely on a strict checklist to protect my mental bandwidth:

Hard stop at 23:00.
Sleep treated as a strategic investment.
Zero guilt on low-energy days.

The 23:00 Rule and the Reality of Mental Health

My plan includes a strict rule: work ceases at 23:00. A tired solo dev creates more bugs than they fix. Sleep is a strategic investment.

But that’s the theory. The reality is messier.

Sometimes external factors — late shifts at my day job, or the air defense activity in Kyiv — make the 23:00 deadline impossible. And then there are the internal factors. I live with GAD and depression. There are days when there are no missiles, no extra work, but my brain simply refuses to cooperate. The energy tank is empty. On those days, the only achievable victory is making it to the shower and getting into bed.

An antifragile plan can’t be a rigid, brittle clockwork. It must absorb these bad days. If I miss an evening due to a depressive episode, the Stop-Loss dates protect the project. The schedule bends, but it doesn't break. It accommodates the reality of being human.

Phase 1: Infrastructure and the Art of Being Broke

I operate on a strict, near-zero budget. My monthly income is about $700 USD, and rent consumes half of it. The only financial investment I made was paying the $25 Google Play Console registration fee — a serious amount of money for me right now.

The Shipaton sponsors heavily promoted Replit for cloud builds. Replit even offers a 40% discount for hackathon participants. But even with the discount, a Replit Pro subscription is financially impossible for me.

So, I engineered a workaround. I set up a local development environment on my Xubuntu 26.04 LTS machine using VS Code. For the heavy lifting — compiling the Capacitor Android APK — I connected my GitHub repo to Codemagic's free tier.

The setup wasn't painless. Capacitor v7 requires Java 21, but Codemagic defaulted to an older version. My first cloud build failed with error: invalid source release: 21. A quick edit to the codemagic.yaml file fixed the environment variables, and the build went green.

When I sideloaded that blank, debug APK onto my Xiaomi Redmi Note 9 Pro and saw it launch... it wasn't just a blank screen. It was proof that a pipeline running from a $0 local machine to a $0 cloud builder to a physical device actually worked. The cycle was closed before I wrote a single line of game logic.

The Google Play 20-Tester Bureaucracy

Then came the infrastructure hurdle. Google Play now mandates a 14-day closed testing track with 20 active testers before a new personal account can publish to production.

This is a bureaucratic nightmare for a solo dev with a ticking clock. If I wait until the game is done to start this timer, I will miss the deadline. So, I built a Google Form and posted it in the Shipaton Discord, my social channels, and sent it to colleagues.

The result? Humbling.
I got 3 emails from colleagues — my most loyal audience. From the Discord community? Zero. After 24 hours, the form remains agonizingly empty.

I try not to succumb to panic. I try to filter out the noise, both from the outside world and my own anxiety. But the math is unforgiving: I need 20 testers, and I have 3.

So, I am putting this directly into this devlog. If you are a fellow builder figuring out how to get 20 testers for Google Play, I see your struggle. But right now, I need your help to bypass this bureaucratic wall. If you have an Android device and 2 minutes to spare, please take action:
👉 https://forms.gle/4hJkWsmuyKp3Tgtr8

You will just need to accept an invite from Google Play later, download the app, and keep it installed for 14 days. No deep QA required. Just your presence to satisfy the algorithm.

The Unseen Labor

Right now, NICHLYST is just a 128-step plan, a handful of .md files tracking risks and deadlines, a GitHub repository, and a codemagic.yaml configuration. No art, no story code, no RevenueCat paywalls yet.

But the foundation is poured. It is not fragile.

The day before yesterday, after a 10-hour shift at my day job and helping my wife with her transcription work, I had zero energy left. I didn't code. I didn't force it. I followed the rule: I updated my PLAN_STATE.md log with one sentence, did a git commit, and went to sleep.

In a hackathon, survival isn't about sprinting. It's about building a system that allows you to keep walking, even when the ground is shaking.

NICHLYST is coming. And it will ship on time.

Follow this devlog for the #BuildInPublic journey.

One person, one project, one month: Building Svitlogics from Kyiv

Eugene Kozlovsky — Sat, 12 Jul 2025 00:13:56 +0000

This is a submission for the World's Largest Hackathon Writing Challenge: Building with Bolt.

I'm 34. From Kyiv. A city that has learned to live by the sound of sirens.
Because of my health, office life is impossible for me. So my home became my studio.
I’m not a professional programmer. I know some Python, that's it. My real strength is something else. A process known as "vibe coding"—the ability to translate a feeling, an idea, a vision into a clear prompt for a machine.

When I saw the announcement for the World’s Largest Hackathon presented by Bolt, my first thought was crushing.
Who am I to compete?
A 34-year-old guy from Ukraine. Not a developer. Alone. Against 70,000 participants. Against entire teams. It felt absurd.

I almost gave up on the idea.
But a day before registration closed, I asked myself: what did I really have to lose? Time? I waste it doomscrolling anyway. A prize? The odds were tiny.
But the potential gain was incredible. Experience. And most importantly, a chance to build something that matters.

That idea was already living in my head. Svitlogics.
The name combines the Ukrainian word "світло" (transliterated as svitlo, meaning "light") and "logics" for reason.
This isn’t just a tool. It's my personal mission. Because I believe we must bring light into the information chaos. And while this is a global issue, here in Ukraine, the ability to see clearly has become an acute survival skill.

On May 28th, I registered. On the 31st, I began.
My first prompt was simple. Very simple. "Create the full structure for a web application. The design should have a brutalist vibe. The app's purpose is to analyze text." Then I hit "Enhance prompt" and let the AI work.

The result was… magic.
It wasn't what I envisioned, but it wasn't entirely wrong. Bolt.new had created a functional text analyzer, but one that focused on word counts and character metrics, not the nuanced analysis of manipulation I had in mind. But I didn't feel disappointment. I felt euphoria.
That feeling when you see a first, wobbly, but incredibly important step.
The foundation was laid. It was imperfect. It was raw. But it existed.
The first light of Svitlogics had been switched on.

Onwards.

Let me start with the questions…

… The ones people ask.

"Why does it look so... raw?"
"Where are the shadows? The rounded corners?"
"Isn't it a bit... primitive?"

My answer is simple. And it’s always the same.
This is not a mistake. It is a choice. It is a philosophy.

I call it "Pure Minimalist-Brutalist."
Because I believe form must serve substance. Not hide it.
Svitlogics exists to cut through the noise. Its design must do the same. No exceptions.

Modern UI uses soft shadows to create depth. It uses gentle gradients to feel "friendly."
This is persuasion.
It’s the same toolkit manipulators use, just with visuals instead of words.
I refused to fall into that trap. For a tool that dissects lies, a "friendly" interface would be the biggest lie of all.

So. No shadows. No gradients. No visual tricks.
Because they are noise. Because they distract. Because they are not honest.

The font is IBM Plex Mono. For one reason: absolute clarity. It sets a serious, analytical tone. It signals that this is a tool for thinking.
The palette is even stricter. Black and white. For pure contrast.
And one single color. Blue.
It’s not for branding. It’s for function. It has only one job: to say, “You can act on this” or “This is a key result.”
One color. One purpose.

This design is not about being "beautiful."
It is about being honest.
And for a tool designed to fight for clarity, honesty is the only thing that matters.

Unapologetically.

If the design is its soul…

…the system prompt is its brain.
It’s what turns a general AI into a specialized tool. And building it was the hardest part of this journey.

My first approach was naive.
I thought I could write one "universal" prompt for both English and Ukrainian.
I fed it an English text. The result was… promising.
Then I fed it a Ukrainian text.
A total mess.
The AI missed the cultural context. The scores were erratic. The justifications felt soull-ess.

This wasn't a turning point; it was a confirmation of what I already knew, especially after Russia's full-scale invasion: language is a weapon. The way manipulative narratives are constructed in English-speaking media can be vastly different from the techniques used in texts aimed at a Ukrainian audience. A universal tool would be a blunt instrument where a scalpel was needed.
So I threw out the universal idea. And started over.
Two separate prompts. One for each language. Double the work. But it was the only way.

The process became a relentless loop.
Prompt. Test. Analyze. Refine. Repeat.

First, the data. I realized my initial test texts were too simple.
So I spent hours building a richer dataset. Corporate press releases. Political speeches. Opinion pieces. Even 20th-century propaganda.
Then I did something more. I used another AI to create synthetic data. To generate perfect examples of disinformation, with every manipulation I wanted to teach Svitlogics to see. It was like a targeted training course for my AI.

Then, the real grind began.
I’d run a test. Svitlogics would miss a manipulation.
Why?
My prompt was too vague. "Look for logical fallacies" isn't enough.
So I’d refine it.
“Search for a 'Straw Man' argument. A 'Straw Man' is when you misrepresent someone's position to make it easier to attack. For example…”
Then I’d run the test again. A small victory. It found the Straw Man. But it missed the Appeal to Emotion.
Back to the prompt.
Another iteration. Another test.
For hours. Days. Living in this cycle.

Every success was a jolt of pure ecstasy. Every failure, a command to think clearer. To instruct better.
This is the unseen labor behind Svitlogics.
It's not just an API call. It's a carefully calibrated instrument.
And the prompts are its secret sauce. The result of dozens of hours of obsession.

The cascade eureka

At first, Svitlogics was fragile. It relied on a single AI model.
A choice born from pragmatism. I had a zero-dollar budget. It was free and generous.
For a while, it worked.

Then, during an intense testing session, it broke.
429 Too Many Requests.
I had hit the limit. My workflow, my focus — shattered.
It was more than an annoyance. It was a fundamental flaw. A single point of failure.
A tool for clarity cannot be this unreliable.

The dilemma was classic. A smarter model with stricter limits? Or a dumber one that was always available?
Neither was good enough. It needed to be smart and resilient.

The answer came to me while staring at the Google AI documentation.
I didn't have to choose one model. I could use them all.
The idea was a cascade. A sequential fallback system.
It would try the best model first. If that failed, it wouldn't show an error. It would seamlessly try the next one. And the next.
From a fragile pillar to a resilient, multi-layered structure.

I built a priority list of seven models.
The smartest and fastest at the top. The high-volume "workhorses" in the middle. The most limited one at the very end, defining the baseline for the whole app.
This became the central nervous system.

I chose to build this logic entirely on the client-side. In the browser.
Simpler for a solo dev. Faster to deploy.
I rewrote my API service into a recursive function.

Here’s how it works.
The system starts with the highest-priority model. It makes the API call.
Success? Great. The job is done. The user gets their analysis.
But if the API returns an error 429—meaning the model's quota is hit—there's no panic.
The function simply calls itself again, this time targeting the next model down the cascade.
This loop continues until it either gets a successful response or has tried all available models.
To the user, it just works.

Under the hood, it’s an elegant dance between seven different AI brains.
Orchestrated by a few lines of JavaScript code running in the browser.
Ensuring the light of Svitlogics never goes out. Even when some of its bulbs flicker.

My workflow: A symphony of two AIs

I am not a programmer. Not a traditional one.
This is the most important context.
Svitlogics exists because of a new way to create. A process known as "vibe coding."
It’s not about writing code from scratch. It's about having a clear vision and orchestrating AI to bring it to life.
The project was built by a trio. Me, as the director. And two AI partners.

Gemini was my strategic consultant. Bolt.new was my tireless engineer.
A constant, fluid dance between them.

I used Gemini as my architect and ultimate debugger. Before any big feature, I'd have a conversation with it. "I need to build a model cascade. What are the pitfalls?" It gave me blueprints. When Bolt's code broke, I didn't just ask Gemini to "fix it." I gave it the full context. The component. The prompt. The exact error. And it would find the root cause in seconds.

Bolt.new was my implementation team. It built the project structure in minutes. My daily flow was simple: discuss logic with Gemini, refine details in Bolt's Discussion Mode, then execute with Build Mode. My job was to be the lead engineer. To review. To refine.
This synergy is best illustrated by the story of when Svitlogics got "sick."

It happened on June 8th. Until then, my confidence was soaring. The plan was simple: add a language switcher to the UI. I asked my strategist, Gemini. It recommended a solid, battle-tested library.
But then, out of simple curiosity, I asked my engineer, Bolt, for its opinion. It suggested a different, lighter library. And I made a critical error. I deviated from my tested workflow and chose Bolt's suggestion.

I gave it the prompt. "Install the library."
And the machine I had come to trust turned against me.
The application collapsed. A complete, catastrophic failure.

My confidence evaporated. Frustration set in.
I spent hours in a frantic loop. Feed error messages to Gemini. Translate its advice into prompts for Bolt. Each attempt was a gamble, burning my precious token allotment. The afternoon bled into evening. I was getting nowhere.

Then, the air raid sirens began to wail in Kyiv.
The dissonance was surreal. Wrestling with a broken app—a problem entirely of my own making—while the very real threat of missiles loomed outside. It was a stark reminder of priorities.

In that moment, I had to make a decision. Not as a developer chasing perfection, but as a project manager with a hard deadline.
I could keep fighting this losing battle. Keep burning time and tokens on a feature that wasn't core to the mission.
Or I could retreat.

I chose to retreat.
The next day, my first command to Bolt was not to fix. It was to remove.
"Delete the library. Remove every file. Every line of code. Revert everything."
It felt like a small defeat. But it was the most mature decision I could make. I realized my desire for "one more feature" had endangered the entire project.

A buggy app with a language switcher is infinitely worse than a stable, single-language app that does its job perfectly.
This taught me the most valuable lesson of this hackathon.
Ruthless prioritization.
A great project is defined not just by what you add, but by what you wisely choose to remove.
Sometimes, the most powerful move is not to write more code.
It's to decisively delete it.

Building under fire: Finding focus amidst chaos

This isn't just about code. It's about the human context.
To build a hackathon project solo, with a full-time job, is a stretch.
To do it from Kyiv, during a war, is to find focus in the heart of a storm.

There were many nights like that. Nights that started not with code, but with the wail of air raid sirens. Nights that ended not with a successful commit, but with the grimly familiar routine: running to the hallway, waiting for the thud of our air defense systems at work, and hoping for the silence that follows.
The next morning, you wake up a wreck. Utterly sleep-deprived.
For me, sleep isn't a luxury; it's a pillar of stability. Its absence is a trigger for my depressive disorder. On those days, the energy tank is empty. Zero code gets written. Zero progress is made on Svitlogics.

This is the part of the story often left out of triumphant tech narratives. The grind. The exhaustion. The many days where you produce nothing at all.
And it was on one of those days, running on fumes, that I realized my perfectionism had become a trap.
I was obsessed with making the system prompt "perfect." But the list of other essential tasks was a mountain.
I was getting bogged down. Watering a single tree, while a whole ecosystem needed attention.

So I made a strategic decision.
I split my time into two tracks.
Track 1: The Engineer. Deep, focused work on the AI brain. Reserved for the days when I had strength.
Track 2: The Product Manager. Everything else. UI fixes, writing content, project planning. Less cognitively demanding tasks for the days of exhaustion.
It was a way to keep moving forward. Always.

This was a turning point. It felt empowering.
It taught me that discipline isn't about forcing yourself to work when you have no energy left.
It’s about being smart with the energy you have.
On some days, progress is a complex new feature. On others, it’s fixing a single bug.
Both are valid. Both are steps forward.

This journey has been a lesson in resilience.
The drive to create something meaningful is a powerful anchor in a sea of chaos.
And the quiet act of writing a line of code, of building a tool for clarity while the world outside explodes, feels like a small act of defiance.
An act of hope.
And that is the most powerful motivator of all.

34 days. What started as a last-minute decision has become one of the most rewarding experiences of my life.
Svitlogics is now a real, working application. But for me, it is so much more.

I came into this not as a programmer, but as a "vibe coder."
I had a vision, a deep "why." But I believed my lack of traditional skills was a barrier.
I was wrong.
This journey proved to me that tools like Bolt.new are powerful equalizers. They shatter the walls between an idea and its execution. The future of building is here. And it’s incredibly empowering.

Svitlogics itself is a project with a clear philosophy.
It's not a judge that gives you answers. It's a scalpel to help you ask better questions.
Its mission is to empower your own critical thinking. This belief is in every part of it—from its honest, brutalist design to its core analysis. Because the most effective way to fight disinformation is not by creating a new source of truth, but by fostering more critical minds.

Building this from Kyiv gave it a meaning I never expected.
The sounds of war are not a footnote to this story. They are the ink it was written with.
It transformed a technical exercise into a personal act of resistance.

I don't know if I will win. But I know I have already won the most important prize.
The experience of building something I believe in, from zero.
The lesson of managing a project, facing failure, and finding focus in chaos.
The proof that my personal challenges do not define me.

Whether it wins an award or not, Svitlogics exists. It works. It was built with purpose.
For a solo developer from Kyiv, that is everything.