DEV Community: Vladimir Ushakov

Show DEV: A safer intake flow for digital subscription requests

Vladimir Ushakov — Sat, 19 Sep 2026 04:27:31 +0000

When a user cannot pay for a digital subscription, the obvious product move is to ask for more details. That is also where a small support form can become risky: people may volunteer passwords, card data, or one-time codes before anyone has explained what is actually needed.

I built Оплата.Сервис around the opposite constraint: collect the minimum needed to triage a request, then continue the conversation without asking for account secrets.

The intake model

The first step asks for only two things:

the service (for example ChatGPT, Apple/iCloud, Steam, PlayStation, Google Play/One, or another service);
a Telegram contact so the team can respond after checking the specific case.

The form does not ask for a password, card number, CVV/CVC, SMS code, or sign-in confirmation code. It also avoids promising that every service can be handled. A request is reviewed first.

Product decisions behind the form

1. Data minimization is part of the interface

A warning hidden in a privacy policy is too late. The safe boundary should be visible at the moment the user is deciding what to submit.

2. “Other service” is structured, not a blank support message

Users can name a service that is not in the preset list, but the first step still stays narrow. This reduces the chance that a free-text box turns into a dump of sensitive account information.

3. No certainty before review

The UI says the team will check the possibility for the specific request. It does not promise a result, a price, or a deadline before the context is known.

4. The contact channel is explicit

The user knows where the follow-up will happen. That makes it easier to recognize an unexpected contact or a request for information the service says it never needs.

What I would like feedback on

The live flow is in Russian and intentionally short. I would especially value feedback from developers and product designers on:

whether the “never send secrets” boundary appears early enough;
whether the service selection is clearer than a generic support textarea;
what additional abuse-prevention cue could help without making the form feel alarming;
whether the review-first wording sets the right expectation.

You can try the current flow here: Оплата.Сервис.

Disclosure: I am connected with the project. This post was drafted with AI assistance and reviewed for accuracy and compliance with the DEV Community AI guidelines.

When One Boolean Changes Five Things: Keeping Mid-Match Rules in Sync

Vladimir Ushakov — Thu, 27 Aug 2026 06:19:46 +0000

Cat Laundry is a browser strategy duel played on a shared 4×4 board. A move begins by clicking one of your own cats. The clicked cat switches to the opponent, while your color travels along the diagonals and may complete a square, diamond, or cross.

The late-game mode, Spin Cycle, changes the match after either player reaches 70 points. Cat rotation becomes much faster, squares and diamonds stop scoring, only crosses remain valid, every cross is worth 10 points, and the winning target stays at 100.

The difficult implementation detail was not the threshold. It was preventing five different parts of the game from disagreeing about whether that threshold had been crossed.

Change the state after the scoring event

The computer match keeps the late-game state as one boolean:

let finalPhase = false;

function activateFinalPhase() {
  if (
    finalPhase ||
    matchTarget < 100 ||
    Math.max(humanScore, aiScore) < 70
  ) return false;

  finalPhase = true;
  return true;
}

The matchTarget < 100 guard matters because the first computer match can be a shorter introduction. Spin Cycle belongs to the regular 100-point match, not the 60-point trial.

More importantly, I call activateFinalPhase() only after the current move has found its patterns and awarded their points. The move that reaches 70 is evaluated under the rules that were active when the move began. Spin Cycle applies to the state that follows it.

That ordering gives the transition a clean causal chain:

the diagonal wave finishes;
completed figures are detected;
points are added;
the score crosses 70;
Spin Cycle is announced;
later moves use the new scoring rules.

The function also returns whether this specific scoring event started the phase. That is different from merely checking whether finalPhase is true. The UI needs a one-time transition message, while the board needs a persistent late-game appearance.

Let scoring consume the state directly

All figure detection still passes through completedPatterns(). Spin Cycle narrows that existing pipeline instead of adding a second scoring system:

for (const pattern of PATTERNS) {
  if (finalPhase && !pattern.name.startsWith('КРЕСТ')) continue;

  const scoredPattern = finalPhase
    ? { ...pattern, points: 10 }
    : pattern;

  // Find matching placements that include a cell touched by this move.
}

This is where the rule has to be authoritative. In late game, square and diamond candidates never enter the accepted set. Both cross variants survive, and their points are replaced with 10.

Everything after detection can remain unchanged: overlapping figures are resolved, points are summed, the scored cells are recycled, and the next turn begins. The UI labels also come from the accepted pattern objects, so a late-game cross is displayed as +10 because the scoring object itself contains 10. There is no separate display-only value to drift out of sync.

The computer opponent uses the same function while simulating candidate moves:

function simulateStrike(state, index, color) {
  // Apply the clicked-cat sacrifice and diagonal recoloring.
  return {
    state: next,
    touched,
    patterns: completedPatterns(color, touched, next)
  };
}

That means its move evaluation changes automatically when finalPhase changes. I do not maintain one scoring table for the real move and another for the AI.

Make the copy and animation read the same state

The renderer maps the boolean to a persistent CSS class and to the visible banner:

grid.classList.toggle('final-phase', finalPhase);
ui.finalPhase.classList.toggle('hidden', !finalPhase);

The class changes several visual channels together:

.machine-grid.final-phase {
  filter: saturate(1.45) contrast(1.08);
}

.machine-grid.final-phase .cat-wrap {
  animation-duration: 1.05s;
}

.machine-grid.final-phase .glass {
  animation: finalGlassPanic .34s steps(2, end) infinite;
}

The normal cat rotation is seven seconds, so 1.05 seconds is an unmistakable change. Saturation, flashing glass, and faster lamps reinforce the same state without changing the underlying board.

The banner states the scoring rule explicitly: Spin Mode activated; only crosses score; each cross is worth 10 points. The English strings live in the same translation map as the rest of the interface, including the 70-point announcement. This matters because an untranslated or stale rule sentence would be a functional bug: it could tell the player that squares still count while the scoring function has already rejected them.

Keep the network match server-authoritative

The multiplayer implementation has its own match object, but not its own interpretation of the rule. The server owns finalPhase, sets it after scoring, and stores when the transition began:

const phaseStarted =
  !match.finalPhase &&
  Math.max(match.scores[LEFT], match.scores[RIGHT]) >= 70;

if (phaseStarted) {
  match.finalPhase = true;
  match.finalPhaseStartedAt = Date.now();
}

Server-side completedPatterns() applies the same cross-only filter and 10-point override. The serialized match then sends both persistent and short-lived information:

{
  finalPhase: !!match.finalPhase,
  finalPhaseAnnouncing:
    !!match.finalPhaseStartedAt &&
    Date.now() - match.finalPhaseStartedAt < 3000
}

The client uses finalPhase for the banner, fast animation, and continuing visual state. It uses finalPhaseAnnouncing for the temporary 70-point message. Scoring never depends on whether a client rendered that message in time; the server has already decided which figures count.

This separation is useful beyond games. A state transition often has two presentation needs:

a durable indication of the current mode;
a short explanation of the event that changed the mode.

Trying to derive both from a timer or animation callback would make presentation timing responsible for game truth.

The invariant I actually care about

Spin Cycle is safe only if these statements are always true together:

if the banner says cross-only, the detector rejects squares and diamonds;
if the detector awards 10, the figure label also says +10;
if cats are spinning faster, the match is already in late game;
the AI evaluates the same late-game moves that the real scorer accepts;
in multiplayer, the server decides the phase and clients only present it;
changing the allowed figures never changes the 100-point victory condition.

The code is small because the transition has one source of truth and several explicit consumers. The work is in making every consumer read that truth at the correct moment.

You can play Cat Laundry in the browser.

When an interface changes rules while an interaction is still in progress, do you prefer a persistent mode indicator, a one-time explanation, or both?

One Flag, Three Consequences: Switching Scoring Rules Mid-Match

Vladimir Ushakov — Fri, 21 Aug 2026 06:49:32 +0000

Cat Laundry is a 4×4 strategy duel. A move starts by clicking one of your own cats. That cat changes to the opponent's color, while your color propagates along the four diagonals. When the wave stops, completed squares, diamonds, and crosses are scored.

That was already an unusual rule set. The late game added a second problem: how do you change scoring rules during a live match without making the result feel arbitrary?

The rule I shipped is called Spin Cycle:

when either player reaches 70 points, late game begins;
squares and diamonds stop scoring;
only crosses count, for 10 points each;
the winning target remains 100;
cat rotation becomes visibly faster.

The important part is not the threshold itself. It is making the state transition, scoring code, and visual feedback describe the same event.

Change state after scoring, not before

The match keeps one boolean:

let finalPhase = false;

function activateFinalPhase() {
  if (finalPhase || matchTarget < 100 || Math.max(humanScore, aiScore) < 70) {
    return false;
  }

  finalPhase = true;
  return true;
}

The timing matters. I call this only after the current move has finished finding patterns and adding their points.

That means the move which takes a player from 68 to 73 is evaluated under the original rules. Only the following state is late game. If I switched the flag while the wave was still resolving, the same move could begin under one scoring table and finish under another.

The return value is useful too. true does not merely mean that late game is active; it means that this exact scoring event started it. The UI can therefore announce the transition once instead of repeating a banner after every later move.

Put the rule filter next to pattern detection

Squares, diamonds, and crosses all pass through completedPatterns(). Spin Cycle does not add a parallel scoring system. It narrows the existing candidate list:

for (const pattern of PATTERNS) {
  if (finalPhase && !pattern.name.startsWith('КРЕСТ')) continue;

  const scoredPattern = finalPhase
    ? { ...pattern, points: 10 }
    : pattern;

  // Find placements that match the board and touch this move.
}

This gives the state flag two explicit effects in one place:

non-cross patterns are ignored;
every surviving cross is worth 10.

The rest of the scoring pipeline stays unchanged: overlapping figures are resolved, points are summed, used cells are recycled, and the next turn begins.

Keeping the filter here also makes AI simulation use the same rules. The AI evaluates candidate moves through the same pattern function instead of maintaining a second late-game scoring table that could drift away from the real match.

Visual feedback must read the same flag

The board renderer applies a final-phase class from that same boolean. CSS makes the washing-machine motion more aggressive, while the score event that flips the flag replaces the normal status copy with a direct explanation:

const phaseStarted = activateFinalPhase();

ui.status.textContent = phaseStarted
  ? '70 POINTS · SPIN MODE ACTIVATED'
  : normalStatus;

ui.log.textContent = phaseStarted
  ? 'ONLY CROSSES SCORE · EACH CROSS +10 POINTS'
  : normalLog;

This creates a causal sequence the player can follow:

a move completes;
points are awarded;
a score reaches 70;
the transition message appears;
the board accelerates;
future scoring accepts only crosses.

The animation is not decoration. It is a persistent reminder that the scoring function is now in a different mode.

Why keep the target at 100?

Changing the scoring system and the victory target at the same time would create two moving references. Keeping 100 preserves the player's existing progress while the set of useful shapes becomes narrower.

A 10-point cross is also large enough to make a late reversal possible. The leading player cannot simply wait for the score to finish itself: both players still need to build or interrupt a cross.

One state, three consumers

Spin Cycle became easier to reason about once I treated it as a state transition with three consumers:

game logic filters patterns and changes cross value;
presentation accelerates the cats and keeps a visible late-game style;
event copy explains exactly when and why the transition happened.

If any one of those consumers derived late game independently, the match could display Spin Cycle while scoring a square, or score a 10-point cross before the player saw the rule change.

You can play Cat Laundry in the browser.

When a game changes rules mid-match, what visual signal would make you trust that the new scoring mode has actually taken effect?

Changing the Rules at 70 Points: Designing a Legible Endgame

Vladimir Ushakov — Sun, 16 Aug 2026 06:53:52 +0000

Cat Laundry already had an unusual rule: clicking one of your cats gives that cell to the opponent, while your color travels diagonally from it. Squares, diamonds, and crosses score points. The interaction is simple to execute, but the result is not self-explanatory.

The newest change made that communication problem sharper. I added a late-game state called Spin Cycle.

When either player reaches 70 points:

Spin Cycle visibly activates;
the cats rotate much faster;
squares and diamonds stop scoring;
only crosses count;
every cross awards 10 points;
the winning score remains 100.

The purpose is mechanical, not cosmetic. A normal match can slow down near the end because both players understand more of the board and start protecting useful formations. Spin Cycle makes the last 30 points more decisive. It also leaves room for a sharp comeback: one cross is worth a third of the remaining distance to victory when the mode begins.

That creates a UX problem: how do you change the scoring rules during play without forcing the player through another tutorial?

A rule change must look like an event

The implementation has one explicit transition. After points are awarded, the game checks the higher score. If it is at least 70, the target is the normal 100-point target, and Spin Cycle has not started yet, the state flips once.

In simplified form:

if (!spinCycle && target === 100 && Math.max(playerScore, opponentScore) >= 70) {
  spinCycle = true;
}

The important part is not the conditional. It is what happens around it.

A silent boolean would be correct game logic and poor interface logic. If a square scores on one turn and does nothing on the next, the player is likely to read that as a bug. The new state therefore changes several signals together:

a high-contrast banner announces the mode;
the status text says that only crosses now count and that each is worth 10;
the board becomes more saturated;
the washing-machine glass and indicator lights pulse faster;
every cat's rotation accelerates dramatically.

The player should not have to infer a scoring-table change from a missing number. The board itself needs to say: the match just entered a different phase.

Why the scoring filter happens after the transition

The existing scoring pipeline detects completed shapes and returns their point values. Spin Cycle does not replace shape detection. It filters the detected results: outside Spin Cycle all supported shapes can score; inside it, only crosses survive the filter and each surviving cross is worth 10.

Keeping detection and late-game scoring separate matters for feedback. A square can still exist visually after 70 points. It simply is no longer a scoring object. If I removed square detection entirely, other parts of the visual explanation could drift away from what is actually on the board.

The transition is checked after the points from the current action are applied. That means the move that reaches 70 finishes under the old scoring state; then the interface announces Spin Cycle for what follows. The player sees a cause, a boundary, and the new consequence in that order.

The animation has to carry causality

This game already taught me that instant state updates can look like random flicker. One click may recolor the clicked cat, propagate diagonally, complete a shape, award points, and hand control to the other side. If all of those facts appear at once, the final board is visible but the move is not understandable.

Spin Cycle adds another possible consequence to the same chain. The readable order is:

the action resolves;
the current shape is scored;
the score crosses 70;
the mode announcement appears;
the board adopts its faster visual rhythm;
later scoring accepts crosses only.

The animations are not decoration between states. They are the grammar that connects those states.

No second tutorial, but no hidden rule either

I did not add a modal tutorial at 70. Interrupting a close match to explain the ending would fight the tension the mode is supposed to create.

Instead, the transition repeats the rule in the normal status area while changing the whole board's tempo. This is a contextual explanation: it appears exactly when it becomes relevant and does not ask for confirmation.

That is also why the faster spinning alone would not be enough. Motion tells the player that something changed, but it does not tell them what counts now. Text alone has the opposite problem: it is precise, but easy to miss during a match. The two signals need each other.

The real test is the first wrong expectation

The most useful observation will not be whether players notice the banner. It will be what they do immediately afterward.

Do they try to complete a square and become confused when it awards nothing? Do they understand that a cross is now worth 10? Does the accelerated motion feel like a clear endgame signal or just visual noise? And after they understand the rule, does the possibility of a comeback make them want another match?

You can play the current English build in the browser.

After the score reaches 70, is it clear from the visual signals that the rules have changed and only crosses score now?

I Built the Game Logic Quickly. Making Players Understand It Was Much Harder

Vladimir Ushakov — Mon, 10 Aug 2026 12:09:03 +0000

Cat Laundry is a small browser strategy game played on a 4×4 board. The rule that drives it fits in a few sentences. Explaining the consequences of that rule on screen took much longer than implementing it.

The board contains sixteen cats, each belonging to one of two colors. On your turn, you click a cat of your color. The clicked cat changes to the opponent's color, while your color spreads outward along all four diagonals. If the resulting cells form a square, diamond, or cross, that shape scores.

That sounded readable when I described it in text. My first visual implementation proved otherwise.

A move is not one state change

The simple implementation is to calculate the final board, assign it, and render once. From the program's perspective, that is attractive: input goes in, the rule function returns the next state, and the UI displays it.

From a player's perspective, several cats flash to new colors for no visible reason.

The important information is not only which cells changed. It is the causal chain:

I chose this cat.
That cat was sacrificed to the other color.
My color moved through the nearest diagonal cells.
It continued to the next diagonal distance.
The last recolored cell completed a shape.
The shape scored and was redistributed.

If I render only the final array, steps 2–5 collapse into one frame. The result is mathematically correct and visually indistinguishable from random blinking.

The current move code therefore groups diagonal targets by their distance from the clicked cell:

const distances = [...new Set(
  targets.map(target => Math.abs(row(target) - row(origin)))
)].sort((a, b) => a - b);

for (let ringIndex = 0; ringIndex < distances.length; ringIndex++) {
  const distance = distances[ringIndex];
  const ring = targets.filter(target =>
    Math.abs(row(target) - row(origin)) === distance
  );

  waveNext = new Set(ring);
  render();
  await wait(ringIndex === 0 ? 120 : 1500);

  waveNext = new Set();
  recolor(ring);
  render();
}

The structure is: announce the next ring, wait, apply it, render, then continue. waveNext, waveReached, waveOrigin, and the current actor are presentation state, not game rules. They exist because the player needs to see where the change came from and where it is going.

The shape highlight has to arrive late

I also had to separate "the board now contains a shape" from "show the scored shape."

Shape detection itself is straightforward. I slide templates over the 4×4 board: two forms of cross, a diamond, and a 2×2 square. A candidate counts only when every required cell has the scoring color and at least one of those cells was touched by the current move. Candidates are sorted by points, and overlapping lower-value shapes are rejected.

The timing was the difficult part.

If the highlight appears in the same render as the final recolor, it competes with the event that caused it. A player sees a colored outline and a changed cat, but cannot reliably tell which happened first. The UI is effectively presenting cause and conclusion at once.

After the final diagonal ring, the game now waits 650 ms before setting activePattern. Only then does it show the complete shape and add its points. It holds that state for another 1000 ms before redistributing the scored cells roughly between the two colors.

Those waits are not decorative polish. They turn one opaque transition into three statements:

the last cells changed;
this exact shape is now complete;
these cells are being recycled because the shape was consumed.

The rule engine does not need those phases. The person watching it does.

Interruption made animation part of the game state

The delay between diagonal rings created a tactical possibility: another player can move before the previous inertia reaches its outer cells.

When that happens, the game does not simply discard the earlier action. It increments a generation token so the old asynchronous loop can no longer continue, evaluates shapes using the cells that wave actually touched, fixes any score, and starts the new move.

In the single-player code, each animated strike captures a local token. After every wait it checks that token against the current waveToken. Starting an interrupt increments the token. The suspended strike wakes up, sees that it belongs to an older generation, and returns.

This was useful beyond cancellation. It gave the mechanic an honest visual contract: if the wave has not visibly reached a cell, that cell is not silently included in the result.

It also explains why the AI cannot answer immediately. The move selector can rank legal sources synchronously, but an instant computer response would erase the reading window that makes interruption understandable. AI actions are deliberately scheduled with a random delay between 1200 and 2200 ms. The delay is a gameplay constraint and a readability constraint, not an attempt to imitate expensive computation.

The AI itself evaluates simulated strikes. Easy mode chooses randomly. The other modes rank candidates using immediate shape points, converted cells, diagonal reach, and—on the stronger evaluation path—the opponent's best immediate reply. None of that matters if the player cannot see what move the AI interrupted, so the pause is as important as the score function.

A rules modal was not enough

My original explanation treated the move as a sentence: click your cat, sacrifice it, recolor the diagonals, make shapes. Test players still missed either the sacrifice or the propagation.

The tutorial became an eleven-step interactive sequence with its own small state machine. It does not merely show completed boards. It asks for a legal click, animates diagonal distances, pauses on the last recolored vertex, and only then highlights the square, diamond, or cross. Later steps stage an opponent's partial wave and ask the player to interrupt it. Separate examples explain overlapping shapes, independent shapes, safe opponent waves, and the eight-second turn limit.

That sounds more elaborate than the underlying game because it is. A novel interaction often needs examples ordered by dependency. I cannot usefully explain interruption until the player can identify a wave in progress. I cannot explain a scored cross until the player has seen the final vertex change before the highlight appears.

Multiplayer had to transmit the unfinished move

For online matches, sending only the final board would recreate the original blinking problem on the second client. The server is authoritative, but its serialized match includes the visual intermediate state:

return {
  board: match.board,
  scores: match.scores,
  waveOrigin: match.waveOrigin,
  activeEmitter: match.activeEmitter,
  waveReached: [...match.waveReached],
  waveNext: [...match.waveNext],
  waveFront: [...match.waveFront],
  activePattern: match.activePattern,
  transitioning: Boolean(match.transitionUntil),
  version: match.version,
  serverTime: Date.now()
};

The client polls the match endpoint every 240 ms and re-renders when the version changes. The server bumps that version when it announces the next diagonal ring, when it applies the ring, when it fixes a pattern, and when the transition finishes. A late or interrupted strike is protected by a server-side generation counter, just like the local token.

This means the intermediate animation is not reconstructed by guessing from two board snapshots. Both players receive the same origin, reached cells, next cells, active pattern, and transition lock. The causal explanation is part of synchronized state.

What I took from it

I used to think of animation state as a temporary layer placed over the real application state. Cat Laundry forced a more precise distinction.

Some animation is cosmetic. A hover bounce can disappear without changing what the interface communicates. Causal animation is different: it explains how one valid state became another. If users must make decisions during that transition—or if two clients must agree on it—the intermediate state deserves explicit names, cancellation rules, and synchronization.

The practical questions I now ask are:

What did the user cause?
Which visible change is the first consequence?
What must finish before I present the conclusion?
Can a new input interrupt the sequence?
If it can, which intermediate facts are already committed?
Would another client be able to render the same explanation?

You can play Cat Laundry in the browser. The tutorial is skippable, but it is also the quickest way to see the sequence described above.

When you try one move, is it clear which cat caused each recolor—and can you tell why a completed shape appeared before looking at the score?