![qyCaD2JvXMez8GRXOAdFC.png](/api/media?pathname=blog%2Fthe-cities-we-deserve%2FxzbXz7anr4bmY_Dqir8p8.png)I have always been hyped about participating in hackathons. Remember the time I was too intimidated to even enter one? And then after my first hackathon, the blood rush to my brain showed me how ambitious you can get when you have a great team. That second hackathon, and every one since, drove me like a madman to strive for "greatness." Not to mock anybody, though. This year's CPH Hackathon, I had plenty of ideas and I wanted to do none of them. I think it was partly because I'd hit AI fatigue from coding, and partly because it was hard to imagine doing something different from what I do every single day. In the context of a hackathon, I really didn't want to touch AI RAG, AI integration, or workflow optimization. There are always those moments of inspiration, until you open the internet and see that hyped ideas rotate on a conveyor belt. I usually like following trends, but usually that's also because I'm genuinely curious about them and I know people respond well. This time, that wasn't the case. All I knew was: "I need to create something beautiful." That's what I told Iman and Ming, and honestly, I didn't know any better than that. Iman came with an idea around energy and cities, something that kind of pulled us back (we still consider ourselves young, for the record) to the days of SimCity and games like it. Some people wandered over to our area and said exactly the same thing, either out of genuine connection or as a lighthearted jab: "what you're doing is what happened 20-plus years ago." But the idea of building something like that from scratch, with real rules, real algorithms, high-performance tech, and actual collaboration, is what brought the whole project together. I've always been inspired by a game called Townscaper. It was my first personal brief: how do I learn from it, and how do I recreate something that feels like it? In our team we heavily work on AEC tools, construction, architecture, simulation, transport, and we all agreed on one thing: we need more fun tools. And I don't want to take the word fun lightly. Fun is what creates curiosity. Fun is what made me want to learn Grasshopper. Fun is what drives great discoveries. The best tools I've ever used didn't feel like tools at all. Yes, it's a game. Nej — it's a mirror. One where every solar panel you place ripples through the power grid, where every metro line reshapes how a thousand invisible agents flow through the city. It all came from a single question: what if anyone could design a city and actually see what happens when they do? Where stacking housing on a single block raises land value but quietly strains the water system beneath it. The kind of thing that doesn't exist in the AEC world, because the AEC world is too busy being serious. So here's what we actually built. The Grid The world starts with a Voronoi grid: seed points scattered across a plane, relaxed through Lloyd iterations until they feel organic, almost like a city that grew on its own. We also built a Townscaper-inspired hex mode, flat-top hexagons that tile into a coastal town layout. Both modes use Delaunay triangulation under the hood, which gives us the neighborhood relationships we need for everything that comes next: pathfinding, placement, simulation. The grid isn't decoration. It's the nervous system of the whole project. Wave Function Collapse This is where things got wild. Every time you place a housing block, the system doesn't just drop a cube on the grid. It runs a Wave Function Collapse solver, the same family of algorithms used in procedural game worlds, to figure out what shape that building should take. It looks at the neighbors, evaluates socket compatibility between tiles, checks morph rules (is this a foundation? a wall? a roof? a balcony?), and collapses possibilities one cell at a time using Shannon entropy. If it paints itself into a corner, it backtracks. Fourteen tile types: solid cubes, windowed walls, arches, peaked roofs, balconies, step-ups, all governed by constraint rules that make the result feel designed, not random. And because we track which faces are exposed to the outside, the energy model downstream knows exactly which walls face the sun and which ones don't. Simulation Under every city you build, four simulation layers are quietly running. Energy calculates supply and demand across every plant and building (solar, wind, gas, nuclear) and spits out grid stability, carbon intensity, renewable fraction. Transport builds a multi-modal graph (road, metro, train, cycling) and routes population flows through it, tracking congestion, commute time, modal split. The City layer rolls all of that into GDP, land value, tax revenue, health, crime, and tourism indices. And Water (still a stub, honestly) is waiting to model demand, supply, and wastewater. Each layer feeds into the next. Place a data centre and watch your energy demand spike. Draw a metro line and see commute times drop. It's cause and effect made visible. Real-Time Collaboration (Yjs) We wanted multiple people to build the same city at the same time. That meant we needed conflict-free shared state, the kind of problem that sounds simple until two people place a building on the same cell in the same millisecond. We used Yjs, a CRDT library, bridged to the game engine through Socket.IO. Every cell edit (housing type, height, building placement) gets written to a shared Yjs document that syncs across all connected clients in binary, no base64 overhead. Each user gets their own undo stack. The server persists the document to Redis so the city survives reconnects. Cursors broadcast at ~15fps so you can see where your teammates are working. It's collaborative SimCity, and it actually works. The Stack Three.js for rendering, React for the UI, Vite for the build, TypeScript across the board. Custom shaders for energy flow visualization, post-processing for ambient occlusion, instanced meshes for vegetation, a day-night cycle with mood presets (dawn, day, dusk, night) that shift lighting and window emissives. The dashboards (energy, city metrics, time controls, transport overlays) are all React components pulling live data from the simulation engine. The server runs Express with Socket.IO and Redis for session persistence, deployed on Railway. We didn't set out to build something this deep. But once the grid worked, the WFC worked, the simulation worked, and collaboration worked, and it stopped being a hackathon project and started being the kind of tool we actually wanted to use. The kind that makes you curious. The kind that's fun. You can find the source code on [GitHub](https://github.com/imanwarsame/thecitieswedeserve) and the live app at [tcwd-app-production.up.railway.app](https://tcwd-app-production.up.railway.app/). Many thanks from the whole team! [Ashkan Rezaee](https://www.linkedin.com/in/ashkanrezaee/) [Cristofor Mamaliga](https://www.linkedin.com/in/cristoformamaliga/) [Andy Andor](https://www.linkedin.com/in/andy-andor-8b059b65/) [Iman Warsame](https://www.linkedin.com/in/imanwarsame/)

Stay Updated