Centre - The System
The System Behind Espil.Online
Espil Online is a free knowledge-sharing community in a living world on real cities: a 3D player, Google Maps, and real businesses in one place. This page is its documentation and its implementation case study, arranged the way the world itself is arranged. It is told in the order it happened, in rooms that run in one line to the right: a house dreamed in 2015, the house and the novel, the tourism years, and at the end the case study of Espil Online itself.
What is implemented
The web build is live at espil.online. You arrive above a real city and dive the last stretch into it, then walk streets rebuilt from the city's own map data. Vancouver and Auckland stand today. Inside, the world begins as a mall: everything in every real store on the map can be traded, person to person, on trust, with no fee - promises, in an era of credit. The stall system (sellers and seekers, in real time, face to face) is the form that trade takes, and a guide walks new arrivals through the full journey to Auckland.
The app and PC program are the game build of the same world, on the same account. Character selection starts there, the game character is a server record created there, and Zealandia - the sunken land under New Zealand, entered only through the Auckland portal - is its first game expansion. The web stays light and social on purpose; the game weight lives in the app.
The backend, documented
Accounts are Google-only at this step, on a multi-provider identity structure so more providers can join without a rebuild. Sessions are issued by the backend, not the provider: an opaque token, hashed in the database, carried in an httpOnly cookie on espil.online, sliding for 30 days with a 90-day cap. Visitors who never sign in keep browsing as ghosts; the strict signup is deliberate, because trust is the foundation the trade runs on. Places data is served from the API with a cache-aside store, so the map stays fast without paying for calls. The whole backend runs serverless on Cloudflare - Workers for the API, D1 for accounts and data, Durable Objects for realtime presence, R2 for the heavy bytes: $0 recurring is a design constraint, not an accident.
Laws, tokens, one component family
The design system is a set of documented laws - palette, typography, interaction rules - written before implementation. Tokens are CSS custom properties in the production code itself, so a token change is the design decision and its implementation in the same act. Surfaces are composed from one reusable family (HUD, cards, buttons, loaders) before anything new is invented. The governance test already ran: one glass-loader implementation, built once against the laws, became the single standard on both production sites with no per-site redesign. The asset-size standard works the same way - sprite and 3D budgets, compression requirements, and per-place download targets, written before assets are produced.
The rooms run in one line to the right. Move with the arrow keys, the doors above, a right-click anywhere, or a sideways scroll. Rest the mouse at the left or right edge of the screen, and the way to the next chapter is written there. Escape returns here.
Step 1 - The Beginning
A dream of a house, 2015
It starts in 2015, with a dream of building a house - before there was a world, a product, or a plan. Everything in the rooms after this one grows out of that dream.
Bieclipse Design House
I founded Bieclipse Design House and spent the following years designing and building websites for clients. The design house was my trade and my school at once: identity, websites, and the discipline of shipping work other people rely on. The name I worked under - Espil - comes from those years, and it never left.
The house, modelled in 3D
The house itself I designed the way I design everything: in 3D, modelled in full before anything was made. A minimalist house, printed by machine rather than built by hand, set in nature without disturbing it, powering itself. The model came first; the physical object followed the file, not the other way around.
Printed with RealPrinty
The modelled house was then printed as a physical object using RealPrinty - the dream of 2015 as something you can hold in your hand. A design that survives printing has nowhere to hide: every proportion in the file has to be true.
The record
The full record of these years - the design house, the clients, the sites, and the house work - is in the PDF on my minihome page. This room is the short version: a house dream, a design house, a model, a print.
Step 2 - The House & The Novel
The Espil House Collection, and a story begins
The house became a collection, and the collection needed a world around it - so I started writing one, as a novel, on the blog. This room holds both: the houses, and the beginning of the Espil story.
The design brief
One house, designed for years before it had a world: 3D-printed, minimalist, set in nature without disturbing it. It powers itself - hydroelectric and solar - so it owes the land nothing. Inside, a VR chamber copies a place completely, so the house can be anywhere it has visited. I have not built this house in the real world; it is a design ambition, and inside Espil Online it is a place - the models of the collection trade there for Leo Coin, and one day the houses are the world's housing layer, where your website is your house.
The collection
Five houses, modelled in full - walkable builds exist for the collection, and the renders below are its concept art: the Universe house and its grounds, drawn at the hours the world keeps. The spiral you see in the roof is the same spiral as my mark; the house was the logo before the logo was.
The novel begins
A house alone is an object; it wanted a world, and the world wanted a story. So the Espil novel began, published in instalments on my blog under the name Espil Ceil - Espil from spelling Bieclipse backward, the o removed because o is earth. The novel is the canon of everything built later: Espil, the cauldron maker who shapes the space the world lives in; Lunaris, who keeps it; Leo, who makes its coin; and the house at the centre of it all. The game is built on top of the novel - not the other way around.
The story, published
Espil Ceil - the novel on the blog
The novel and the essays around it are published on my Naver blog, in Korean, as they are written. The world of Espil Online is this story, made walkable.
Step 3 - Tourism
Tourism, and the products it taught me to build
Tourism took me through the travel industry - and every job in it turned into a web product I designed and built. The ideas in this room are the ones that later converged into Espil Online.
The tourism years
I worked as a travel representative producing daily customer brochures, completed a Tourism Diploma at Capilano University, and then joined Discover Holidays as an intern and converted to full-time Operations Coordinator - producing the entire Alaska and Canada tariffs, alone, under the Founder's direction. Tourism taught me the conviction the rest of my work stands on: a culture is only truly shared by visiting in person.
Web-based tourism products
The work kept becoming products. An online tariff, built within weeks of arriving, that moved the printed books to the web - shown, approved, and then deliberately left unlaunched while I raised the accuracy of the existing tariffs first, because the older B2B partners were the business. A map of the partner hotels. The old company database, converted into an API the modern tools could read. And a style guide where none had existed, enforced with InDesign JavaScript across thousands of tariff pages so one person's standard held at production scale.
Where the ideas pointed
Every one of those products was the same idea in different clothes: real places, on a real map, with real information, shared properly. That is where this page has been heading. Espil Online is a community and a free knowledge, information and technology sharing solution: a 3D player walking the real map of a real city, where everything in every real store can be traded person to person, on trust, with no fee. The mall is its beginning; the sharing is its base. The next room is its birth certificate - how it was actually built.
The evidence
The Discover Holidays case study
The tariffs, the style guide, the API conversion and the stewardship call are documented in full on the case study page - the working record of the tourism years.
Step 4 - The Case Study
Espil Online, born with AI
The last room is the case study: the birth of Espil Online, and how AI is used to build it - not as a feature of the product, but as the workforce, the tools, and the way the work itself is organised.
The birth
Espil Online is live at espil.online. You arrive above a real city and dive the last stretch into it, then walk streets rebuilt from the city's own map data; Vancouver and Auckland stand today, trade begins as a mall on trust, and a guide walks new arrivals through the full journey. The app and PC program are the game build of the same world on the same account, and Zealandia - entered only through the Auckland portal - is its first game expansion, in production now. The backend runs serverless on Cloudflare with Google sign-in and backend-issued sessions: $0 recurring is a design constraint, not an accident.
Plushy AI - my own image-to-3D pipeline
Plushy AI is my local, private alternative to Meshy: services in Docker containers on my own machine that turn drawings into the world's matter - sprite packs for whole cities (115 curated sprites in the city pack, 82 of them Vancouver buildings), monsters as sprite sheets, and character work finished through the Meshy API for rigging and animation. One rule the pipeline never breaks: an existing character's appearance changes by retexture, never by regeneration.
The assets themselves - Plushy AI in, GLB out
No stills for this step: the models below are the actual production files. Ahi, the fire master, and Huka, the ice master, were produced by Plushy AI and finished through Meshy AI; Hermes is the giant who carries the Time Stone key. Each ships in the game as the GLB you can turn here - drag to orbit, scroll to zoom.
The map editor toolkit
So that I can author the world myself, a placement editor was built for the game: paint the ground as tiles - village road, grass road, water, paved road - place building and prop sprites on the satellite terrain, mark where the player, the villagers and the monsters spawn, and export village-map.json, which the game reads directly. The first village built this way is Waitematā. The editor turns world-building from code into composition: I place, the game loads.
AI, separated into departments
The production itself is organised like a studio. The work is separated into departments - a map department, an asset department, a skills department, a music department, quality, and a coordinating office - each staffed by AI agents working from written specs and written laws, each reporting its state to the coordinator, and nothing ships without my verdict. I write the laws, direct the departments, edit the code, and decide. That separation is how one person runs a production of this size without it dissolving into one long prompt: every department holds one craft, knows its standards, and answers for its own work.