DEV Community: iCe Gaming

It's not about AI token costs. It's about prototyping.

iCe Gaming — Sun, 29 Mar 2026 10:00:11 +0000

It's not about the spending of AI tokens, it's about the potential of prototyping.

I like to build things in my free time.

Not necessarily products. Not necessarily monetization ideas. Just things I want to exist, things that benefit myself, or maybe others.

And I use AI a lot for it.

Because it's no longer about writing the best possible code upfront.
It's about having a prototype ready, fast, in some kind of MVP state. Then iterating.

Building with AI + your own vision

I recently redid my website for my weekend projects:

iCeGaming.org

I have to say, when you combine your own visual idea with AI, it gets really close to what you actually had in mind.

This is not a promotional post.
It's more about showcasing how empowered we are now to just… build.

Small note though:

Yes, humans are still accountable for the code.

I don't expect AI to write production-ready systems. Not without iteration, validation, and actually understanding what’s going on.

What I’ve been building

I’ve always had multiple projects going on. Games, tools, apps… always something upcoming.

🎮 Games

Main idea:

playable in the browser
no login
no tracking
just open and play

I care more about the experience than anything else.

I started with Warlocks, inspired by the Warcraft 3 days.
Pure chaos: pushing, dodging fireballs, shrinking safe zone.

Once I hit stable 60 FPS, I kept pushing:

bigger maps
more players
more interaction

Then came something inspired by Pudge Wars-style gameplay:

Mortar Mayhem
16 players, 8v8, blind mortar shots across the map, fog-of-war feeling, upgrades based on performance.

Then:

Pirate Ships deathmatch, 9 players, real-time aiming and prediction
Tank Blitz, same idea, but with powerups, turret alignment, charged shots affecting accuracy

At some point it became a pattern:

Boats. Tanks. Submarines. Planes. Bicycles.
Characters with bows. Pistols on horses. Whatever.

The constraint is always the same:

60 FPS in the browser.

🛠️ Tools

These usually come from real needs.

llm-schema-guard:
Strict schema validation + enforcing correct shapes + observability
commerce-orchestrator-api:
Moving towards agentic commerce, a layer in front of backend systems so agents don’t integrate directly with everything

Apex-Edge:
One problem I’ve seen everywhere:
What happens when the internet goes down? Or AWS/GCP?
Retail just… stops.
Idea:
local hub per store or region
process transactions locally
sync later
don’t push all complexity into POS devices

📱 Apps

Sometimes it’s just solving annoyances.

the-fuse
I was streaming and didn’t always have people to play with → so I built something to match creators for collaborations

what-i-paid
I got tired of not tracking prices across stores
→ take a picture of a receipt
→ AI extracts everything
→ track, manage, share
Free, simple, low friction.

And a lot more…

There are a lot of other ideas in progress.

Some go more into AI:

local assistants
multi-device control
something like a lightweight “brain” coordinating things

Some go bigger into games.

What I learned

Adapt to AI and iterate fast.

That’s it.

Prototyping is cheap now.

You don’t need to sit on ideas for weeks anymore. You can build something in hours or days, see if it works, and move on or improve it.

Just don’t forget:

If you ship it, you own it.

AI doesn’t change that.
(Quick note: I only linked the hub page because this isn’t a promo post. I just wanted to share the mindset and the joy of building fast with AI. The more we all build and iterate, the better it gets for everyone.)

Building an Offline-First Retail Hub in Rust: How ApexEdge Keeps Stores Selling When the Internet Dies

iCe Gaming — Mon, 16 Mar 2026 13:20:22 +0000

If you’ve ever built retail software, you know the happy-path demo is the easy part.

The hard part is everything around it:

internet goes down,
HQ APIs lag or fail,
terminals still need to sell,
receipts still need to print,
and nothing can be lost.

I built ApexEdge, a RUST-powered store hub orchestrator that sits between POS/mPOS clients and HQ systems:

POS/MPOS <-> ApexEdge <-> HQ

Repo: https://github.com/AncientiCe/apex-edge
This post is about the actual engineering problems I had to solve, and the architecture patterns that made the system reliable in production-like conditions.

The Core Constraint: Stores Must Keep Selling

Retail can’t block on cloud availability. That drove my first principle:

The store hub is the source of operational truth during a transaction.

In practice, that means:

local persistence for catalog/prices/promos/customers/config,
local cart + checkout orchestration,
local document generation (receipt, merchant copy, kitchen chit, etc.),
async sync with HQ, not inline dependency.

If HQ is unavailable, checkout should still complete locally.

Synchronization is eventually consistent, but sales flow is immediate.

Why a Hub Instead of POS Calling HQ Directly?

Direct POS -> HQ can work for tiny setups, but at scale it creates fragile coupling:

every terminal becomes an integration client,
token/session handling is duplicated per app/device,
every command depends on WAN quality,
retries/idempotency become inconsistent across clients.

The hub model centralizes this:

one northbound contract for POS commands,
one southbound contract for HQ submission/sync,
one place to enforce idempotency, retries, conflict handling, and observability.

Contract-Driven Commands Instead of “Random Endpoints”

Instead of exposing many ad-hoc mutable endpoints, I route checkout behavior through a command envelope:

POST /pos/command

Examples:

create_cart
add_line_item
set_customer
set_tendering
add_payment
finalize_order

This gave me major wins:

Compatibility discipline: versioned command envelope.
Idempotency at the boundary: safe retries from POS.
Unified observability: command metrics by operation/outcome.
Deterministic testing: journey tests mirror real checkout flows.

Problem #1: “Exactly Once” Is a Lie (So I Designed for At-Least-Once)

Networks duplicate requests. Clients retry. Humans double-click.

So I assume at-least-once delivery and make handlers idempotent:

command envelope includes idempotency_key,
server stores command results keyed by scope,
repeated command with same key returns same logical response.

This prevents duplicate line items, duplicate payments, and duplicate order submission side effects.

Problem #2: Reliable HQ Submission Without Blocking Checkout

Inline finalize -> call HQ is brittle. If HQ times out, do you fail the sale?

I don’t.

I use a durable outbox:

finalize order locally,
atomically write HQ submission payload into outbox table,
background dispatcher posts to HQ with retry/backoff,
mark accepted/retry/dead-letter based on result.

This separates customer-facing latency from external dependency reliability.

Operationally, this is huge:

cashiers are not blocked by HQ instability,
submissions are durable across process restarts,
dead-letter rows are inspectable and replayable.

Problem #3: Keeping Catalog/Pricing Fresh Without Breaking Ongoing Sales

HQ sync is asynchronous NDJSON ingest with checkpoints per entity:

catalog
categories
price book
tax rules
promotions
customers
coupons
inventory
print templates

Design goals:

ingest in batches,
move checkpoints only on successful entity application,
tolerate unknown entities for forward compatibility,
surface sync state via API for UI visibility.

This avoids all-or-nothing fragility and makes partial progress explicit.

Problem #4: Inventory Truth vs. Checkout Experience

Stock rules are trickier than “if qty > 0”.

I enforce availability at add-to-cart time:

inactive items are blocked,
out-of-stock items are blocked,
quantity checks can return insufficient stock errors.

But I also handle incomplete sync states pragmatically:

if inventory is not yet synced for an item, I allow add-to-cart (configurable policy at architecture level).

That tradeoff favors operational continuity while still applying strict checks where data exists.

Problem #5: Document Generation Should Be Local and Deterministic

Receipts are not optional, and they can’t depend on round-tripping to HQ.

I generate documents in the hub:

render from synced templates + order/cart view models,
persist document artifacts,
expose retrieval endpoints for POS clients.

POS remains responsible for printer/device UX, but generation is centralized and reproducible.

Bonus: template updates can be distributed through sync instead of app redeploys.

Problem #6: Security for Shared, Real-World Devices

mPOS fleets need practical trust bootstrap:

generate pairing codes,
pair device once,
exchange external identity token + device proof,
receive local hub access/refresh tokens,
protect operational routes behind hub auth.

This model gives controlled device onboarding without hardcoding secrets into POS binaries.

Problem #7: You Can’t Operate What You Can’t See

I instrumented behavior ownership across routes and background flows:

command counts + latencies + outcomes,
outbox dispatch attempts/duration/DLQ,
sync ingest batches + durations + outcomes,
DB operation outcomes,
HTTP-level request metrics.

In an outage, these metrics answer:

is checkout still flowing?
are HQ submissions backlogged?
is sync stuck on a specific entity?
are failures concentrated at DB, network, or domain validation?

Without this, “it feels slow” becomes your only signal.

Testing Strategy That Actually Catches Regressions

I leaned hard on behavior-level tests:

in-process smoke tests for health/ready/basic command flows,
full journey tests from cart creation to finalized order + document generation + outbox payload assertions,
crate-level tests for domain, storage, sync, outbox, printing, and contracts.

This matters because distributed correctness is mostly integration correctness.

Architecture Pattern Summary

What worked for me:

Local-first transaction boundary
Command envelope + idempotency
Durable outbox for external submission
Checkpointed async ingest for HQ sync
Local document generation
Device trust + token exchange
First-class metrics on all critical paths

If you’re building store, warehouse, or edge-heavy systems, this combination gives resilience without requiring “perfect network” fantasies.

Tradeoffs (No Silver Bullets)

What you pay for this architecture:

more moving parts than direct API calls,
stronger schema/contract discipline required,
eventual consistency complexity,
operational tooling for DLQ replay and sync introspection.

Still worth it for domains where downtime equals lost revenue.

Practical Advice If You’re Starting Today

Start with idempotency keys on day one.
Model outbox as a product feature, not a reliability patch.
Keep sync entity-specific with independent checkpoints.
Treat metrics as acceptance criteria.
Run end-to-end journey tests before adding more endpoints.
Document behavior ownership explicitly (who owns which route/flow/metric).

Closing

The biggest shift for me was this:

I stopped optimizing for request/response elegance and started optimizing for business continuity under failure.

That changes everything from API shape to data model to test strategy.

If you’re designing offline-capable systems and want to compare patterns, I’m happy to share a deeper follow-up on:

idempotency schema design,
outbox retry and DLQ policy,
sync conflict handling,
or observability dashboards that worked in practice.

Building an AI Commerce Orchestrator in Rust

iCe Gaming — Fri, 13 Mar 2026 13:41:44 +0000

Protocols and patterns are emerging that let AI agents interact with commerce systems - product search, checkout flows, inventory, order management. For that to work reliably we need middleware that orchestrates complex interactions between AI systems and traditional commerce APIs.

I built commerce-orchestrator for that role: an open-source Rust project that sits between AI agents (or any client) and commerce backends as a deterministic orchestration layer.

The Problem

Modern commerce stacks are complex. Simple user actions often require coordination across catalog, inventory, pricing, payment, and order systems. When an AI agent tries to perform the same flow - discover products, check availability, compare pricing, initiate checkout, confirm order - we hit a mismatch: AI systems are stateless and probabilistic; commerce systems need deterministic, transactional flows. Without an orchestration layer you get inconsistent state, duplicated requests, partial transactions, unreliable retries, and security risks. An orchestrator in the middle is what makes agent-driven commerce safe.

What This Project Does Today

The Commerce Orchestrator is middleware: clients call its REST (and A2A) API; the service runs deterministic cart and checkout flows and delegates to your catalog, pricing, tax, geo, payment, and receipt backends via configurable HTTP adapters.

Implemented today:

Cart and checkout - Create cart, add/update/remove items, apply adjustments, start checkout, execute checkout with idempotency and in-flight deduplication.
Payment lifecycle - Capture, void, and refund over the facade and HTTP API; tenant-scoped and auth-protected.
Reliability - Outbox, inbox, and dead-letter primitives; operational endpoints to process outbox, list/replay dead-letter, and run reconciliation.
Auth and multi-tenancy - Bearer token auth, tenant and scope checks; idempotency and state scoped by tenant.
Observability - Request IDs, tracing, a metrics endpoint; health probes for liveness and readiness.
Discovery - GET /.well-known/ucp returns a capability manifest (UCP-style) with version and rest_endpoint; advertised capabilities map to implemented routes.
A2A - POST /api/v1/a2a/checkout and POST /api/v1/a2a/cart accept envelope payloads; requests are normalized to the same domain types and policy as REST.

Why Rust

Rust was chosen for performance (high request volume with minimal runtime overhead), reliability (ownership model to avoid memory leaks and concurrency bugs in transactional workflows), and a strong async ecosystem for high-throughput APIs.

Architecture

The codebase is a Cargo workspace of crates. Request flow looks like this:

orchestrator-http - Axum server, routes, auth, request ID, tracing.
orchestrator-api - Stable facade: cart commands, checkout execute, payment lifecycle, incoming events, outbox/dead-letter/reconciliation.
orchestrator-runtime - Durable execution runner, idempotency, retries, timeout handling, persistence traits.
provider-contracts - Trait interfaces for catalog, pricing, tax, geo, payment, receipt.
integration-adapters - HTTP clients that implement those traits (configurable base URLs).
orchestrator-core - Domain model, state machine, validation, policy.
orchestrator-observability - Tracing, metrics helpers, audit event schemas.

Persistence is file-backed (event store, idempotency, outbox, inbox, dead-letter); restart-recovery tests validate that the same idempotency key returns the same outcome after process restart.

API Surface (What’s Actually There)

All under /api/v1 unless noted. Auth: in production, Bearer token required.

Area	Endpoints
Cart & checkout	`POST /api/v1/cart/commands`, `POST /api/v1/checkout/execute`
A2A	`POST /api/v1/a2a/checkout`, `POST /api/v1/a2a/cart`
Payments	`POST /api/v1/payments/capture`, `POST /api/v1/payments/void`, `POST /api/v1/payments/refund`
Events	`POST /api/v1/events/incoming` (idempotent accept-once)
Operations	`POST /api/v1/ops/outbox/process`, `GET /api/v1/ops/dead-letter`, `POST /api/v1/ops/dead-letter/replay`, `POST /api/v1/ops/reconciliation`
Discovery	`GET /.well-known/ucp` (no auth)
Health	`GET /health/live`, `GET /health/ready`, `GET /metrics`

Checkout requests include tenant_id, merchant_id, cart_id, cart_version, idempotency_key, and optional payment-intent fields (e.g. payment_handler_id, ap2_consent_proof). With AP2_STRICT=1, checkout validates a structured consent proof (issuer, signature, expiry, payment handler binding) before execution.

Reliability in Practice

Idempotency - Checkout and payment lifecycle use idempotency keys; duplicate keys get in-flight deduplication or cached result; state is persisted so restart doesn’t break idempotent semantics.
Outbox - Effects can be enqueued and processed via process_outbox_once(max_attempts); configurable retries with backoff in the adapter client; after max attempts, messages move to dead-letter.
Dead-letter - List and replay via HTTP; replay re-enqueues for another attempt.
Incoming events - accept_incoming_event_once(message_id) deduplicates webhook-style events.
Reconciliation - run_reconciliation(transaction_ids) compares orchestrator payment state with provider state (when the provider implements get_payment_state) and reports mismatches.

Outbox processing is triggered by you (e.g. timer or worker calling the ops endpoint); there is no built-in scheduler in the repo.

Implemented vs Deferred (No Spin)

Implemented	Deferred / optional
Discovery `/.well-known/ucp`, capability manifest, rest_endpoint	MCP tool mapping (optional; tests “when added”)
A2A envelope normalization for checkout and cart	AP2 replay protection for mandates (deferred)
Cart commands, checkout execute, payment capture/void/refund	-
Idempotency + in-flight dedupe; file-backed persistence	-
Outbox, inbox, dead-letter, list/replay, reconciliation	-
Bearer auth, tenant isolation, production config (PUBLIC_BASE_URL, etc.)	-
AP2 payment intent fields; AP2 strict consent proof validation	-
Request IDs, tracing, metrics, health probes	-

Known limitations (from the repo): File-backed persistence is directory-based JSON and is not suitable for high concurrency without external locking or shared-write storage. Default Kubernetes manifests assume a single replica for this reason. AP2 replay protection (mandate/nonce deduplication) is explicitly deferred.

Current Status and Next Steps

The project is in active development. The core is there: Rust API, orchestration layer, pluggable adapters, async workflows, and the reliability and observability pieces above. Possible next steps: more agent-oriented API shapes, a declarative workflow DSL, stronger observability (e.g. structured audit events), and additional pluggable adapters. MCP mapping and full AP2 replay protection are on the backlog as optional/deferred.

Open Source

The project is available at:

https://github.com/AncientiCe/commerce-orchestrator

If you’re exploring AI-driven commerce, agent automation, or orchestration middleware in Rust, I’d welcome feedback - especially on adapter design, workflow ergonomics, or observability. This repo is one concrete take on AI-safe commerce infrastructure you can run and extend today.

Summary: This post describes only what the repository implements today. Implemented vs deferred and known limitations are taken from the codebase, the conformance matrix, and the changelog.

One Saturday, One AI-Powered Pirate Ship Battle Game, Built in ~7 Hours

iCe Gaming — Fri, 13 Mar 2026 12:43:13 +0000

How did you spend your Saturday?

Following up on those weekend vibe-coding sessions where AI turns prototyping into actual fun (indie game MVPs at warp speed)...

I randomly thought about a super simple ship battle game, tiny pirate ships, one cannon each. Nothing AAA, just basic fun. (There was some old game like this that got buried on IGDB, but whatever.)

Challenge: how fast can I actually get this playable?

Started at 1:21 PM with a Lovable prompt.

By 8:45 pm I was texting my wife: "Done + "

Total ~7 hours, including a 2-hour shopping trip + dinner break.

Journey went like this:

Frontend & basics (~2 hours)

Used Lovable because credits were there, not married to it over Claude or anything, just whatever gets the job done fast. (People ask why not X tool; honestly doesn't matter as long as you ship.)

In ~2 hours: proper ship maneuvers, shooting, game menu, health bars, the works. All browser-based. Synced to GitHub.

Backend & multiplayer magic (the painful but rewarding part)

Pulled locally, opened in Cursor.

Asked it to plan an authoritative server: matchmaking queues, bot fills, WS everything. One requirement: RUST.

It went... ambitious. Generated Rust backend (very necessary for my tiny $6 DO droplet, low resources, fast, safe).

Struggles were real:

Stutter movements, flickering env
WS connectivity flakes
Message contracts all over the place
FIFO queue ordering headaches

Had to jump in a few times, mostly because I know where these things usually blow up (frontend fighting backend state updates = constant re-renders). Tweaked to make backend single source of truth, frontend just renders/interpolates. Way smoother now.

Deployment (reusing my template)

Techy spoiler, skip if you don't care

$6 DigitalOcean droplet + free Cloudflare Pages, classic combo.

Frontend: test+lint → build → Cloudflare deploy

Backend (Rust):

cargo test + clippy + audit + fmt
build release
rsync to droplet
update systemd unit
nginx config tweaks
pull fresh certs for API
healthcheck

One command, live.

End result

9-player browser lobby, 60 fps, ships sailing, cannons booming, health dropping, syncs across without major drama.

All in one Saturday.

This isn't really about showing off the game (but if you're curious for research or just want to play around, here's the live link: https://sea-mayhem.icegaming.org/ ).

Disclaimer: prototype, expect bugs, desktop only!

It's about how these weekend experiments keep getting faster and more rewarding with AI tools. Prototyping used to drag; now it's pure fun and you actually finish things.

What about you guys? Built anything silly-fun with AI on a weekend lately? How quick are your MVPs getting these days? Drop stories below, always love hearing them. 🏴‍☠️

🧙‍♂️ Warlocks: Weekend Journeys

iCe Gaming — Mon, 19 May 2025 17:01:08 +0000

🧙‍♂️ Warlocks: Weekend Journeys

What started as a weekend browser experiment turned into a fully functional multiplayer game — and a deep dive into performance, sync, and game architecture.

🎯 Phase 1 – Prototype

Movement and fireballs were handled entirely client-side.Sync was "best effort" — enough to demo, but chaotic under pressure.

🔥 Phase 2 – Load Testing Reality Check

The Node.js backend capped out at ~300 players.Sync issues, message storms, and heavy desync.Started rewriting the backend in Rust.

🧱 Phase 3 – Rust Rewrite + Server Authority

Moved the entire game loop to Rust.Fireball collisions, HP, knockback — all centralized.Clients only send inputs; the server owns the world state.Stress-tested up to 3,000 concurrent players with 0 visible lag.

⚔️ Phase 4 – Cleanup & Core Mechanics

Fixed movement prediction & "infinite knockback" bugs

Added fireball cooldowns + visual indicators

Health bars, player names, 8-player custom lobbies

Implemented win conditions and match lifecycle

🕹️ Phase 5 – Real Game

You can now play a full match, win, return to the menu, and rejoin.Everything is synced. Everything just works.All in the browser.

🏗️ Next Step – Standalone Game

Currently building a native Bevy (Rust) version.What I enjoy most is learning through building!

👉 Play the browser version here: https://warlockjs.pages.dev(You might not find an opponent since this is a share, but feel free to open a second tab to try it out.)