DEV Community: ivan kulkin

I added AI to OKLCH Pixel Palette.

ivan kulkin — Sat, 22 Aug 2026 17:21:11 +0000

I added AI palette generation to OKLCH Pixel Palette.

The idea is pretty simple: instead of opening Lospec, Pinterest or another palette collection and scrolling until something feels close enough, you can describe the atmosphere you need in normal words.

For example:

зимний лес
бледно-розовый рассвет
фиолетовая пещера
deep sea horror
rusty factory at sunset

The site turns the description into a palette that can immediately be used for pixel art, illustrations, UI, landing pages or website design.

This is useful when you know the mood you want, but don't know the exact colors yet. An artist can start with a scene or atmosphere. A web designer can describe the visual direction of a page and get a base palette instead of manually trying dozens of combinations.

I didn't want this feature to be an API wrapper. The model runs directly in the browser. There are no OpenAI, Gemini or other AI API requests involved in generation. After the model files are loaded, palette generation works locally on your device and doesn't require an internet connection.

The existing OKLCH color engine is still responsible for building the final palette, keeping colors inside the sRGB gamut and generating usable combinations. AI only interprets the text and chooses the visual direction.

One of the reasons this update took longer than expected was a pretty funny failure in the first version: I typed black and got brown.

The model itself understood the text, but the small layer translating language embeddings into colors generalized badly. I ended up replacing that part with semantic color anchors and a separate constraint for explicit color names.

Now the same system can handle both obvious requests such as black or фиолетовый and more descriptive ones such as заброшенная больница ночью or неоновый киберпанк под дождём.

It supports Russian and English, runs locally, and the normal manual palette tools are still available if you don't want AI at all.

Try it here:

https://oklchpalette.ru

How I made uncertainty readable in a deterministic browser strategy

ivan kulkin — Fri, 21 Aug 2026 16:16:16 +0000

I wanted to build a strategy game where tension appears before the click. Random outcomes are easy to add, but they often feel arbitrary. MYCELIUM became an experiment in exposing enough information for a risky move to feel like a decision rather than a coin flip.

The board shows uncertainty instead of hiding it

The world is generated from a deterministic seed. A frontier cell is still unknown, but its forecast comes from the same seeded biome that will resolve when the player reveals it. The UI is not inventing flavor text after the fact.

Before an attack, the player sees the final probability and the local support around the target. Eight neighboring cells matter, so territory shape affects the odds directly.

That creates a useful distinction:

the result can remain uncertain;
the inputs are visible;
replaying the same seed remains reproducible.

Enemy plans are objects on the board

Hostile growth is announced before it resolves. An intent stores its source, target, direction, and chance. The player gets one turn to respond.

This matters because the counterplay is spatial. You can reinforce the target, spend a rare guaranteed Repaint, or capture the source and remove the threat entirely. The intent is not a timer floating above the UI; it belongs to a living tendril on the board.

One geometric rule creates chains

The main territory rule is simple: close a same-family square perimeter of at least 3×3 and its interior becomes captured and reinforced.

The interesting part is recursion. Filling one interior can complete a second square, so a single corner may trigger a chain of captures. The implementation needs to keep searching for newly completed shapes without processing the same square forever.

The result is a board where a locally weak move can be globally correct because it completes future geometry.

Keeping the game static

The stack is Next.js 16, React 19, TypeScript, and PixiJS. Solo play runs entirely in the browser:

deterministic world generation;
local saves and records;
daily seeds and challenge links;
no account, database, or API key.

Optional 1v1 uses direct P2P rooms. The static deployment remains enough for the game itself; TURN configuration is only a connectivity fallback for restrictive networks.

The public site also contains a server-rendered lore atlas. This gives the fictional world a crawlable surface instead of hiding every piece of writing inside a canvas.

What I am testing now

The hardest question is not technical: does showing forecasts, attack support, and enemy intents produce better decisions, or just more information to parse?

I would value focused feedback on the first match:

When did you first understand why a square matters?
Did an announced enemy intent change your plan?
Which number or preview felt unnecessary?

Play MYCELIUM: https://mycelum.vercel.app/

Source: https://github.com/vansGAMee/MYCELUM

Why OKLCH CSS variables need @supports for a real fallback

ivan kulkin — Fri, 21 Aug 2026 14:49:04 +0000

I added CSS export to an OKLCH palette generator this week. The obvious output looked like this:

:root {
  --brand: #5b21b6;
  --brand: oklch(43.22% 0.196 293.54);
}

It looks like ordinary progressive enhancement: older browsers ignore the second declaration and keep the HEX value. That assumption is unreliable for custom properties.

The failure happens when the variable is used

A custom property accepts almost any token sequence. A browser can preserve oklch(...) as the value of --brand even if it cannot use that function as a color. The second declaration therefore replaces the first one.

The browser only discovers the unsupported color when the variable reaches a typed property:

.button {
  background: var(--brand);
}

At that point the declaration can become invalid. The HEX line did not survive as a fallback because both declarations set the same untyped custom property.

Put the override behind a feature query

The exported file now separates the universal values from the modern override:

:root {
  --palette-1-shadow: #160067;
  --palette-2-base: #5b21b6;
  --palette-3-highlight: #ab7ce1;
  --palette-4-accent: #4dcd49;
}

@supports (color: oklch(50% 0 0)) {
  :root {
    --palette-1-shadow: oklch(25.12% 0.151 280.34);
    --palette-2-base: oklch(43.22% 0.196 293.54);
    --palette-3-highlight: oklch(67.4% 0.118 301.12);
    --palette-4-accent: oklch(74.82% 0.188 142.28);
  }
}

Browsers without OKLCH support keep the sRGB values. Browsers that pass the feature query receive the perceptual values. Consumers do not need to know which path was selected:

.button {
  color: var(--palette-3-highlight);
  background: var(--palette-2-base);
  border-color: var(--palette-4-accent);
}

The variable names include both order and role. The numeric prefix keeps them unique when a larger generated palette contains two colors with similar human-readable names.

Why export both formats?

OKLCH is useful when a palette needs controlled lightness steps. That matters in UI states and in small sprites where two colors with different RGB values can still look almost identical. HEX remains the practical compatibility layer and accurately represents the generator's sRGB-fitted output.

The generator handles the rest of the workflow in the browser: 2–9 colors, six harmony modes, sRGB gamut fitting, lightness inspection, sprite previews, and exports for Aseprite PAL, GIMP GPL, HEX, JSON, TXT, PNG, and now CSS. It requires no account.

Try the CSS export: https://oklchpalette.ru/create

Source: https://github.com/vansGAMee/OKLCH-PIXEL-PALETTE

The next candidates are Tailwind theme output, a Sass map, and a Godot resource. I would be interested to know which one would remove the most manual work from your workflow.

Building an OKLCH palette generator that survives gamut limits and exports to Aseprite

ivan kulkin — Fri, 21 Aug 2026 14:04:10 +0000

A row of attractive swatches is not yet a useful pixel-art palette.

A working palette needs a readable value structure, controlled hue relationships, predictable ramps, colors that actually fit inside sRGB, and an export format the artist can use without rebuilding everything by hand.

I built OKLCH Pixel Palette around that workflow. It is free, open source, requires no account, and runs entirely in the browser.

Source: github.com/vansGAMee/OKLCH-PIXEL-PALETTE

Why OKLCH instead of HSL

In HSL, two colors with the same numerical lightness can look very different in brightness. That is inconvenient in UI work and especially obvious in small sprites, where one bad value step can flatten the whole form.

OKLCH separates perceptual lightness (L), chroma (C) and hue (H). It does not make color decisions automatic, but it gives the generator a more useful coordinate system:

lightness steps can be planned as a visible value ladder;
chroma can be reduced without unintentionally steering the hue;
harmony rules can operate on hue while the value structure remains inspectable.

The tool generates between 2 and 9 colors from a base color and supports six harmony modes. The important part is not the number of modes. It is that every result remains editable and visible as a lightness progression rather than arriving as a sealed random answer.

Gamut mapping is product behavior, not cleanup

Browsers can describe OKLCH colors outside the sRGB gamut. Many pixel-art pipelines cannot store or display those colors consistently.

Simply clipping red, green and blue channels produces unpleasant shifts near the boundary. The generator instead reduces chroma until the color fits the target gamut while trying to preserve the intended lightness and hue. It then checks the converted result rather than assuming the math behaved.

Near-black and near-white seeds are good tests because they expose fragile conversions quickly. A palette tool should not turn #010101 into a colorful surprise or create several visually identical highlight steps. Those edge cases influenced the lightness limits, chroma search and duplicate handling.

Swatches are not enough

Palette quality depends on use. A ramp that looks elegant in a horizontal strip can fail as soon as it must describe a one-pixel edge.

The site therefore shows live pixel previews—a potion, gem, shield and character—next to the palette. They are intentionally small and familiar. Their job is to reveal value collisions, weak outlines and over-bright accents before export.

The same thinking shaped the editor:

a visible lightness ladder instead of hidden coefficients;
Delta E checks for colors that are technically different but perceptually too close;
an sRGB gamut guard;
direct editing after generation;
no account wall between experiment and export.

Export should end the task

Copying HEX values one at a time is not an export workflow. OKLCH Pixel Palette can produce:

JASC PAL for Aseprite;
GIMP GPL;
HEX and JSON;
a PNG palette strip.

That makes the generated palette a usable asset rather than a screenshot of an idea.

I previously experimented with accounts and cloud saving. I removed both. Generation, editing, import and export now stay in the browser. The product is simpler, there is no personal palette database to maintain, and opening the site is enough to start work.

A practical way to test it

Try the pixel-art palette generator with three deliberately difficult seeds:

a nearly black neutral;
a very bright saturated blue;
a warm low-chroma midtone.

Change the palette size, compare harmony modes, watch the sprite previews, then export the result as JASC PAL and open it in Aseprite.

If the ramp needs manual correction, I want to know where and why. A useful palette tool should make the correction obvious instead of hiding behind the word “smart.”

Try it: oklchpalette.ru

Repository: github.com/vansGAMee/OKLCH-PIXEL-PALETTE``

I built a browser chess client that can play Lichess games without becoming another chess server

ivan kulkin — Fri, 21 Aug 2026 14:03:16 +0000

I wanted a chess board that felt precise, opened without an account, and told me something useful after the game. I did not want to build another closed player pool and then pretend that an empty matchmaking queue was a feature.

That became VEYRN Chess: a free, open-source chess client with two ways to play online.

Send a private-room link and play directly browser to browser over WebRTC.
Connect a Lichess account and find a casual 10+0 opponent through the official Lichess Board API while staying on the VEYRN board.

The source is on GitHub.

The empty-network problem

A new multiplayer product starts with a cruel loop: no players means slow matchmaking, and slow matchmaking means no players.

Private rooms solve half of it. The host creates a link, the guest opens it, a short-lived serverless signaling route exchanges WebRTC offers and ICE candidates, and the game then moves to an encrypted DataChannel. The signaling data expires after a few minutes; it is not a game archive.

But a private link is useless when your friends are offline. For that case VEYRN can act as a Lichess client. OAuth uses PKCE in the browser, VEYRN opens the official Board API event stream, starts a casual rapid seek, and sends legal moves back to Lichess. Lichess remains the server and source of truth; VEYRN is only the interface.

This is deliberately not bot scraping and not an unofficial bridge. It uses the API Lichess provides for third-party boards and clients.

The board had to earn its place

Most chess interfaces are usable. The harder target is making the board disappear under your hand.

VEYRN uses pointer capture and transform-based dragging so a piece stays locked to the pointer instead of jumping toward whichever edge was grabbed. Click-to-move and drag-to-move share the same legal-move path. Premoves are shown as a separate visual state and are revalidated when the turn changes. Right-click arrows and square markers live on a non-blocking SVG layer, so planning marks never steal a move.

The visual problem was just as concrete. Coordinates, legal-move dots, last-move squares, check state, pieces and arrows all compete for contrast. I ended up treating the board as an instrument panel: restrained mineral squares, a high-contrast piece set, crisp coordinates, and state colors that remain distinct from both square colors.

On mobile, time controls are full-size targets rather than tiny inline links. The end-of-game report sits over the board and gives the useful actions immediately: next opponent, private room, PGN, or the behavioral report.

Statistics that stay on the device

VEYRN records completed games in local browser storage. The report goes beyond wins and losses:

think time by opening, middlegame and endgame;
clock pressure and time-spending distribution;
move timing and decision rhythm;
captures, checks, castling and move-pattern summaries;
network mode and country matchup context;
finished PGN.

There is no VEYRN profile and no cloud game history. Deleting browser data deletes the ledger. The site uses anonymous, cookie-free Vercel page-view analytics, but moves, PGNs and local reports are not sent with those events.

Country flags are detected approximately from the connection and can be overridden manually. In a private room each side receives the other player's selected country code, so two players do not collapse into one default flag.

What was unexpectedly difficult

Three parts took more time than the headline features:

Serverless signaling latency. A serverless instance cannot be treated like a permanent WebSocket process. Messages need short polling, deduplication, expiry and recovery without making room creation feel stalled.
Authoritative remote state. A Lichess stream may reconnect or deliver state after the local animation. The client must reconcile clocks, move history and results without accepting an optimistic illegal move.
Input geometry. A board that looks correct can still feel wrong. Pointer coordinates, board orientation, transforms and capture all have to agree at every viewport size.

Try to break it

Open VEYRN Chess, choose a time control, and either create a private room or use Play on Lichess. No VEYRN registration is required.

I am especially interested in blunt feedback about three things: how the first piece pickup feels, whether board states remain readable on your display, and whether the local report reveals anything you would actually use before the next game.

Repository: github.com/vansGAMee/veyrn_chess

I built an OKLCH palette generator for pixel art and UI

ivan kulkin — Fri, 07 Aug 2026 21:25:47 +0000

Hi! I built OKLCH Pixel Palette, a free and open-source browser tool for generating color palettes with OKLCH.

You can:

generate 2–9 color palettes
preview colors on pixel art
copy HEX values
export palettes as PNG, GPL and PAL
save your palettes to the cloud
publish palettes to the public gallery
browse and save palettes made by other users
share palettes with a link

The project is open source, so you can also check out the code and contribute.

I built it because I wanted a fast way to work with perceptually consistent colors without manually tweaking everything.

I’d love feedback, especially on the palette generation and UI.

oklchpalette.ru