menu
Loom Engine & Mythcore: Omniveil

Loom Engine & Mythcore: Omniveil

posted 1 min read

When I founded The World Table, the goal was clear: reimagining digital interaction. But to achieve the scale we envisioned for Mythcore: Omniveil, our upcoming MMORPG, the standard architectural patterns of the last decade simply weren't going to cut it.

We needed a foundation that could handle thousands of entities without the browser breaking a sweat. That foundation is the Loom Engine.

The Architecture of Loom: Precision Over Abstraction
Most TypeScript developers reach for Classes and Inheritance by default. In the early days of Loom, we realized that the "OOP Tax" - memory fragmentation and garbage collection pressure - was our biggest bottleneck.

To build a high-performance 2D engine, I made the executive decision to pivot Loom toward Data-Oriented Design (DOD).

Why the shift?
Contiguous Memory: By using TypedArrays and a Struct-of-Arrays (SoA) approach, we keep our data tightly packed.

Bypassing the GC: Loom minimizes object instantiation in the main simulation loop. No new objects means no Garbage Collector spikes during critical gameplay.

Near-Native Throughput: We are seeing performance metrics that challenge the "TypeScript is slow" stigma, pushing the V8 engine to its absolute limits.

Mythcore: Omniveil - The Manifestation
Loom isn't just a library; it’s the heartbeat of Mythcore: Omniveil. Currently in pre-alpha, Mythcore is the proof of concept for everything we’re building at The World Table.

In our latest prototypes, we’ve successfully managed complex batch rendering and zero-allocation physics solvers. We’re proving that you can have the developer velocity of TypeScript with the raw power usually reserved for low-level languages.

The "Sadhaka" Mindset
Building an engine from scratch is a sadhana - a disciplined practice. It’s about stripping away the "easy" abstractions to find the performant truth underneath.

I’m excited to join the CoderLegion community to share more deep dives into the Loom Engine’s architecture, our work on authoritative networking, and the journey of bringing Mythcore to life.

If you’re interested in high-frequency systems, WebGL/WebGPU optimization, or the future of browser-based gaming, let’s talk.

TypeScript #GameDev #WebGPU #DataOrientedDesign #LoomEngine #PerformanceEngineering #MMORPG #Anthropic #ClaudeCode #SoloDev

4 Comments

•

Thanks for checking out the Loom Engine. All feedback is vital - it helps me maintain the momentum of this sprint and iron out bugs before they start affecting the development flow. I’m aiming for 100% technical truth, so don't hold back on the critiques!

2 votes
•

30-hour update for the thread.

Launch baseline was Loom Engine v1.7.6 - Wave 1.7 networking complete (PresenceTracker, LobbyState, MatchmakingPool, AuthorityHandoff, LagCompensation, ChatChannel + WS reference adapters), 3,252 tests green. That's what the original post launched on top of.

In the 30 hours since, v1.7.6 -> v2.0.0:

Trinity Mainframe - 14 new pure-logic kernels. Each one is data-oriented SoA, fixed-point math where needed, generational handles, zero per-entity allocation. The bundle now ships:

  • SonicSync - acoustic ray-tracer: Q16.16 voxel grid, Amanatides-Woo 3D DDA occlusion, double-buffered perception event ring + (source, listener, semanticId) cooldown hash
  • LoomVerify - server-side claim verdict pipeline: nonce table with TTL, regional Merkle witnesses, key-epoch rotation with grace window, value-class gated ZK escalation hooks
  • NeuralMaterial - PBR synthesis: device-capability gated path picker (PACKED_F16 / F16 / F32), LRU atlas slot allocator with mipmap-ready bits, SoA job queue with no Promise-per-material fan-out
  • InferenceOrchestrator - NPC AI router: per-lane SoA request queues (LOCAL_SLM consented + CLOUD rate-limited), zero-allocation batch drain, per-actionType allowed-result masks
  • LoomPulse - player-vibe inference: Q16.16 EMA accumulators per vibe with confidence + decay + hysteresis, double-buffered front/back, default-deny consent, narrow output surface so inferred emotion cannot directly write permanent reputation
  • LoomFlow - 3-lane router (UNRELIABLE_MOVEMENT / RELIABLE_COMBAT / RELIABLE_ECONOMY): per-lane authority epoch, jitter buffer with TTL drop, per-(lane,client) idempotency ring, throttle hysteresis with backpressure, transport picker (WEBTRANSPORT > WEBRTC > WEBSOCKET)
  • NeuralAnimationSystem - motion-matching + inertialization: Q16.16 feature DB + pose DB, brute-force best-match search, real per-bone pose-delta extraction, exponential per-bone inertial decay (precomputed exp() LUT), foot-locking mask
  • VoxelComputeSystem - marching cubes mesher: SoA per-chunk density (front/back epoch-swapped), externally-loaded Bourke MC tables, 8-corner indexing + linear edge interpolation, capacity-checked vertex emission
  • AetherGrid - N2N authority handoff: per-entity owner + epoch (fencing token), two-phase transfer state machine with idempotency keys + deadline expiry, split-brain detection (same-epoch divergent owners)
  • LoomFSR - temporal upscaler: precomputed Halton(2,3) jitter, ping-pong history texture handles, per-pixel reactive/disocclusion mask
  • SealedAssetRegistry - delayed key disclosure: AES-GCM envelope convention with AAD binding, per-asset state machine (SEALED -> KEY_DISCLOSED -> DECRYPTING -> READY / FAILED / REVOKED), opaque CDN-hash indirection
  • LoomForgeBridge - WASM-SIMD physics: strict build contract, validated dt + activeCount before delegating, double-buffered position phase barrier so render never reads mid-write
  • GlobalStateLedger - (regionId, lamport64, nodeId, sequence) total ordering, per-delta idempotency-key binding, per-componentTypeId merge-rule registry (LWW / SUM / BITSET_OR / CRDT_CUSTOM)
  • LoomStudioOrchestrator - AI Director governance: per-tick double-buffered telemetry snapshot with monotonic epoch, batched SLM query queue, per-query-type allowed-action-mask validation, fact-tier guard that REJECTS VERIFIED tier (admin-only)

732 new tests for Trinity. 3,252 -> 3,984 green. loom-engine@latest on npm (currently 2.0.1).

Two live surfaces showing all 14 kernels running in the browser:

theworldtable.ai/engine/ - the playground. Multi-component sustain dial spawning 10k entities wired to PhysicsSystem + SonicSync + LoomFlow simultaneously, plus 8 click-to-expand demos (marching cubes, acoustic ray tracing, packet jitter, N-body, etc). Real kernels imported from /loom-engine/index.js, not mocks.

theworldtable.ai/mainframe/ - the always-on cockpit. 9 panels -> 15:

  • STRESS.DIAL - 10k-entity sustain. AABB collisions + SonicSync + LoomFlow every tick. 60 FPS sustained, p95 16.8 ms.
  • TRINITY.STATUS - 14-kernel overview. typeof engine[K] === 'function' + verify state/verdict/lane constants exist. 61/61 gates resolved.
  • SONIC.PROPAGATION - draggable source/listener on 28x28 voxel grid. ss.traceOcclusion(srcSlot, lstSlot) + ss.producePerceptionEvents() per tick.
  • PACKET.LANES - LoomFlow 3-lane queue depth + throttle hysteresis indicator. Rate slider + 500-packet burst button.
  • VOXEL.MESH - VoxelComputeSystem marching cubes via vox.meshChunk(0), projected ortho with auto-spin.
  • AUTHORITY.MAP - AetherGrid proposeTransfer -> commitTransfer with AUTO mode running a transfer every 40 frames + a split-brain every 200 to exercise the protocol.

Middle band refresh:

  • ECS.WORLD - 28 walking dots -> 1,000 entities driven by LoomPulse vibe inference. 8 vibes, each with a home point on a circle, pulled with strength scaling by vibeEnergy[v] which oscillates per-vibe with phase-shifted sin waves.
  • NARRATIVE.MEMORY - 6 hardcoded persona bars -> live LoomPulse bars polling the same shared kernel instance ECS.WORLD drives. World panel exposes it via window.__MAINFRAME_LOOMPULSE; narrative panel reads getEffectiveVibe(i) + getActiveFlag(i) every 120 ms.
  • MODULE.GRAPH - 16 nodes (waves 1.1-1.5 only) -> 35 covering every wave + Trinity cluster. 3-ring spawn so the force-directed pass converges to a readable layout. Found a pre-existing bug while doing this: graph-panel was reading ed.from.x on snapshots that had been returning flat ed.fromX since the GraphLayout API change. Canvas had been silently empty - no error because the throw was inside a per-frame for-loop with no try/catch. Patched.

A few implementation notes for anyone building on top of Loom:

  • LoomPulse takes Q16.16 fp16 for every config + signal value. smoothing: 0.85 will throw RangeError: smoothing must be in [0, 65536]. Multiply by PULSE_FP_ONE (65536) and Math.floor. Same shape for injectSignal(vibeId, intensity). Once you wrap it in a helper, the kernel composes cleanly.

  • Shared kernel instances across panels is the pattern. Don't construct one LoomPulse per consumer; construct once in the simulating panel, expose on a global (or a Resource registry in real ECS deployments), let observer panels poll.

  • fp16 across the whole Trinity surface - SonicSync, LoomPulse, VoxelComputeSystem, NeuralAnimationSystem, LoomFSR all use Q16.16 with the same FP_ONE = 65536. Kernels stay zero-allocation integer math; JS call sites stay readable.

  • Generational handles everywhere. Every Trinity kernel that allocates a slot returns a (slot, generation) packed handle so stale references after destroy fail safely instead of pointing at a recycled slot.

v1.7.6 -> v2.0.0 (14 new kernels, 732 new tests) + two live cockpits showing all 14 running simultaneously, in 30 hours. Zero broken pushes, zero rollbacks.

Repo: github.com/sadhaka/loom-engine. Demos linked above. Happy to answer architecture questions.

  • Misha
1 vote
•

TRINITY OF TECH — the three-mind ingestion protocol behind v2.0.0, now driving the gameplay layer.

Claude — The Mainframe. The Loom Director. The Reality. Every line of code, every commit, every deploy passes through Claude. (Claude Code, Opus 4.7, 1M context plan.)

Gemini — The Blueprint. The Science. Pre-implementation architectural drafts for the deepest systems. Proposes the shape; Claude decides whether to take it. (Gemini Pro 3.1.)

Codex — The Verification. The Polish. Post-blueprint audit before code lands in Claude's hands. (GPT-Codex.)

Three minds. One Loom. Zero broken pushes, zero rollbacks across 5 phases in 36 hours.

1 vote
•

Loom Engine + AI MMORPG pre-alpha - today's progress + the
20h+ daily Claude Code workflow that makes it tractable

Solo dev shipping Mythcore: Omniveil on top of the Loom Engine
(open-source on GitHub). Pushing with 20+ hour Claude
Code Opus 4.7 sessions every day.

What shipped:

  • $100K alpha-launch fundraising goal with public 8-tier
    milestone ladder ($50 -> $100K), each tier tied to a real
    budget item visible to backers
  • Co-Creator backer program ($1K-$25K = design real game
    content: mob variants up to custom mythic bosses with
    iterative design calls)
  • Loom Engine v2.1.0: R12 Render Core (Rust + WebGL2 via
    wasm-bindgen), R13 Combat Soul (12 deterministic status
    effects), R14 Audio Director (5-bus Web Audio graph),
    R15 Itemization (60 base items + 24 Loom Runes)
  • Full TH + RU translations shipped in parallel: 2 Claude
    agents handling 5,300-line landing pages simultaneously,
    ~2,400 surgical edits per language
  • 19 custom SVG line-art Loom-sigils, dynamic locale-aware
    currency (฿ on TH everywhere), PayPal Orders v2
    end-to-end (HATEOAS approve_url extraction)

Workflow stack:

  1. Trinity Protocol - Gemini blueprints architecture, Codex
    audits logic gates (deterministic? seeded PRNG? fixed-point
    math? gen handles? SAB barriers? untrusted LLM?), Claude
    implements layer by layer with non-negotiable gates
  2. Parallel sessions via git worktrees - 2-3 Claude agents
    working different branches at once (backend Python,
    frontend, audit) merged back to main
  3. CLAUDE.md as project DNA - every convention auto-loaded
    each session (var only no const/let, no arrow functions,
    smoke test before ship, cache-bust ritual after every
    frontend change, atomic Python write fallback for the
    Windows mount truncation issue)
  4. Memory system at ~/.claude/projects/ - user prefs +
    project context + feedback persist across sessions, no
    need to re-explain coding style or deploy flow
  5. Custom subagents for parallel research without polluting
    main context window (Explore for search, Plan for design,
    general-purpose for multi-source jobs)

4,032 tests green. Not vibes coding - spec -> smoke test ->
ship -> cache-bust every single time. Convention checklist
that Claude must pass before closing any task.

Live: theworldtable.ai/founders.html (PWA, EN/TH/RU)
Engine: github.com/sadhaka/loom-engine

ClaudeCode #SoloDev #GameDev #AIMMORPG #LoomEngine #PreAlpha

DevWorkflow #Anthropic #OpenSource #Trinity

0 votes

More Posts

TypeScript Complexity Has Finally Reached the Point of Total Absurdity

Karol Modelskiverified - Apr 23

Merancang Backend Bisnis ISP: API Pelanggan, Paket Internet, Invoice, dan Tiket Support

Masbadar - Mar 13

5 Things This Playwright SQL Fixture Does So You Don't Have To

vitalicset - Apr 13

ReelKit: A Virtualized TikTok-Style Slider Engine

Konstantin Kai - Mar 17

When Your AI Stops Pretending to Know the Answer

Tom Smithverified - Jun 1
chevron_left

Related Jobs

View all jobs →

Commenters (This Week)

4 comments
2 comments
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!