Cities: Skylines meets Balatro in a frighteningly good new Steam roguelike

Bold take: Combolands is less about skylines and playing cards than it is about building a resilient, event-driven state machine that happens to look like a metropolis.

Polygon's recent write-up on Combolands frames the game as a hybrid between the tile-placement strategy of Cities: Skylines and the combo-chaining dopamine of Balatro. On the surface, that sounds like a marketing hook for genre fans. For senior engineers, it's a much more interesting signal: it means the studio is trying to merge two simulation models that don't naturally share the same data structures - update loops, or determinism guarantees. One system thinks in grids, zoning, traffic, and agents. The other thinks in hands, seeds, modifiers, and multiplicative scoring. Getting them to coexist is an architecture problem first and an art problem second.

At Denver Mobile App Developer, we spend most of our time on production software, cloud platforms, and mobile systems, but game-adjacent engineering shares the same constraints: predictable latency, deterministic state - observable telemetry, and safe modding surfaces. The announcement of a roguelike city builder like Combolands is a useful case study for how modern studios balance creative ambition with engineering discipline. Let's walk through the systems that probably make this title tick. Where the risks hide. And what engineering teams can take away from it.

Why Genre Hybrids Stress Engine Architecture

City builders and roguelike deckbuilders are both deep. But their deep parts point in different directions. A city builder optimizes for spatial planning, long-running simulations. And emergent behavior from thousands of independent agents. A deckbuilder optimizes for compact state, fast evaluation. And deterministic seeds that produce reproducible runs. Since when a game like Combolands tries to do both, the engine can't favor one model without starving the other. The simulation layer needs a stable tick rate and spatial indexing, while the combo layer needs a directed graph of effects that can be evaluated in a single frame.

In production environments, we found that the safest first move is to split the world into two authoritative subsystems: a board state that owns tiles, adjacency and resources, and a game state that owns the deck, hand, modifiers. And scoring. Each subsystem publishes events on a central bus; neither subsystem reaches into the other's private collections. Unity's Entity Component System (ECS) is a natural fit for the board side because it turns tile adjacency and agent queries into cache-friendly, data-oriented jobs. The combo side can live in plain C# structs or even a small embedded scripting runtime if designers need custom effects. The discipline that matters most is that the two systems agree on a single source of truth for each piece of data.

Procedural Layouts and Seed Determinism

Roguelikes live or die by determinism. If two players start with the same seed, they should see the same map, the same shop offers. And the same boss order. That sounds simple until city-builder randomness enters the picture: traffic patterns - citizen needs, disaster timing. And procedural district generation all want their own noise functions. The engineering challenge is keeping those noise functions isolated and replay-safe. Most studios solve this with a hierarchical random generator: one master seed produces child seeds per act, district, and encounter, so a bug in one system doesn't contaminate the global sequence.

Another detail that bites teams late in development is floating-point determinism. Scoring multipliers and resource counts often drift across platforms if they rely on float math. In Combolands, a run that scores 4, and 7 billion on Windows shouldn't score 47000001 billion on macOS or Steam Deck. The safer choice is fixed-point integers or deterministic decimal types for anything that affects leaderboards. We have also seen teams serialize the seed and the complete input log to RFC 8259 JSON for replay-based QA. Which lets testers reproduce a reported crash without sharing a multi-gigabyte save file. Read our guide to deterministic simulation testing for live games

Combo-Chaining as Graph Traversal

Balatro turned poker hands into a graph problem: each card is a node, each joker and planet card adds edges or modifiers. And the final score is the result of traversing that graph under a set of rules. Combolands likely does the same thing with buildings and districts. Place a coal plant next to a factory, add a policy card that boosts industrial output, then chain a wildcard building that copies adjacent bonuses. And you have a scoring path that grows exponentially with board size. From an engineering perspective, this is a weighted directed acyclic graph evaluation with possible cycles if the design team allows feedback loops.

The naive approach is to recompute the entire board after every placement. That works for a five-by-five grid. But it collapses once the city grows. The production-grade approach is incremental invalidation: each tile subscribes to its neighbors. And only changed regions recalculate. We have used this pattern in inventory systems and recommendation engines, and it applies directly here. Memoization, topological sorting, and dirty-region marking keep combo evaluation inside the 16. 6-millisecond frame budget. If the team exposes custom combo rules to modders, they also need a sandbox that prevents unbounded recursion or exponential path explosion. See how we design safe scripting surfaces for user-generated content

Modding APIs and Content Delivery

Games that blend two beloved genres usually attract modders who want to extend either half. The engineering question is how much of the game's internal model to expose without locking the studio into every future change. A stable modding surface typically starts with data: cards, buildings, districts, textures, and audio defined in JSON or ScriptableObjects. Schema validation against a published contract keeps mods from crashing on load. RFC 6901 JSON Pointer is useful here for referencing nested mod assets without brittle path strings.

Scripting is where things get fragile. If Combolands allows Lua or C# mods, the team needs clear boundaries around what code can touch. We usually recommend a capability model: mods can read board state, register new cards, and subscribe to events. But they can't rewrite core scoring, make network calls. Or access the filesystem outside the mod directory. Versioning is equally important. When the base game updates, older mods should fail gracefully with a semver check rather than corrupting a save. Steam Workshop handles distribution. But the validation layer still lives in the client.

Steamworks Integration and Build Pipelines

Any PC game launching On Steam In 2025 is really two products: the game itself and the integration with the Steamworks SDK. Authentication, user stats, achievements, leaderboards, cloud saves. And Remote Play Together all flow through Steamworks. For a roguelike city builder, cloud saves are especially critical because runs can last an hour or more and players expect to continue on Steam Deck or another machine. The save format must be forward-compatible. Or players will lose progress after a patch.

From a DevOps perspective, Steam builds are usually pushed through steamcmd inside CI/CD pipelines. A typical setup has three Steam branches-internal, beta. And release-each mapped to a Git branch. Automated smoke tests launch the build, start a seeded run, place a few tiles, verify that the score matches the expected deterministic output. And then upload only if assertions pass. We have seen teams skip that verification step and pay for it later when a single bad depot broke leaderboards for a weekend. The cost of a slow pipeline is always lower than the cost of a bad release.

Telemetry, Balancing, and LiveOps

Balancing a hybrid game is harder than balancing either parent genre because changes ripple through two systems at once. A card that buffs industry might be fine in the deckbuilder layer but dominant in the city layer if it stacks with a particular zoning layout. Studios usually instrument the game with telemetry to spot these interactions. OpenTelemetry, Prometheus, or a purpose-built analytics pipeline can capture per-run events: which cards were drafted, which districts were built, where runs ended. And how long combos took to evaluate.

Privacy matters. Steam players aren't children by default, but regional laws like GDPR and COPPA still apply to telemetry. Event schemas should be designed with Protocol Buffers or Avro for compact, versioned payloads. And user identifiers should be hashed or pseudonymized. In production environments, we found that sampling five percent of runs is usually enough to catch balance outliers, while full sampling should be reserved for crash reporting and performance traces. The real value of telemetry isn't the dashboards; it's the ability to validate design hypotheses with actual player behavior instead of gut feel.

Rendering Dense Cities Without Stuttering

A city builder's visual promise is density: roads, buildings, cars, citizens. And effects all visible at once. A deckbuilder's promise is responsiveness: cards flip, numbers pop, and the screen shakes when a combo lands. Satisfying both at 60 frames per second is a rendering challenge. The first tool is aggressive level-of-detail: distant buildings render as low-poly impostors, mid-distance tiles use simplified shaders. And only the camera-adjacent area shows high detail. GPU instancing batches identical meshes into a single draw call. Which is essential once tile counts climb into the thousands.

The second tool is separating static and dynamic geometry. City tiles rarely move, so they can be baked into static batches. Cards, particles, and UI animations live on dynamic canvases with their own update loops. We have used Unity Profiler and RenderDoc to diagnose stutter in similar projects. And the culprit is almost always either too many dynamic GameObjects or a UI canvas rebuild on every frame. Memory pooling for particle effects and object pooling for spawned cards prevent garbage-collection spikes. These are classic optimizations. But they have to be designed in early; retrofitting them after a city builder is feature-complete is painful.

Security, Anti-Cheat, and Save Integrity

Roguelikes with leaderboards attract players who want to compete, and any client-authoritative scoring system can be exploited. The simplest attack is editing a local save to claim a higher score. The next simplest is modifying game memory to force favorable seeds or card draws. For a single-player or asynchronous-multiplayer title, full kernel-level anti-cheat is usually overkill,, and but some protections are still necessaryLocal saves should be encrypted or at least signed with an HMAC so tampering is detectable. Leaderboard submissions should include a replay or input log that the server can re-simulate.

Server-side validation is the only robust long-term defense. The client sends the seed, the input sequence. And the final score; the server replays the run and compares results. This is computationally expensive. So most teams validate only the top percentile or suspicious outliers. We learned this lesson the hard way on a previous title: client-side score verification lasted exactly one week before the first forged score appeared. Cryptographic proof of run integrity isn't paranoia; it's the cost of maintaining trust in a competitive community.

What Engineering Teams Can Learn

The most transferable lesson from Combolands is the value of a data-driven core. Cards, buildings, policies. And disasters should all be rows in a designer-friendly format that exports to typed game data. When balance changes are a config edit instead of a code change, the team can run dozens of experiments per week. Property-based testing tools like FsCheck or Hypothesis can then generate thousands of random board States to verify that scoring never produces negative resources, overflows. Or infinite loops. This is exactly the kind of defensive testing that saves a launch.

Another lesson is to treat the combo engine as a library with its own unit tests, independent of the renderer and input layer. If the scoring function is pure-it takes a board state and returns a score-it becomes trivial to fuzz, replay, and improve. The board simulation can be tested separately for adjacency correctness and agent pathfinding. When both subsystems are clean, the integration layer becomes a thin orchestrator that wires events together. That separation is what lets a small team ship a game that feels like two genres without building two engines. Explore our architecture reviews for cross-genre product teams

• Split board simulation and scoring into separate, testable subsystems.
• Use deterministic seeds and fixed-point math for replayable runs.
• Validate mods against a published schema and capability model.
• Instrument the game early so balance decisions are data-informed.
• Assume client-side scores will be tampered with and plan server-side replay.

Frequently Asked Questions

What engine is most likely powering Combolands?

The studio hasn't publicly announced the engine. But Unity is the safest bet. Both Cities: Skylines and Balatro shipped on Unity-friendly stacks, and Unity's ECS, DOTS. And Steamworks support make it a natural choice for a hybrid city builder with heavy simulation and UI demands. A custom engine is possible but would require the team to rebuild tooling that Unity already provides.

How do roguelike city builders keep runs fair across platforms?

They use deterministic seeds and avoid platform-specific floating-point behavior. A master seed produces child seeds for districts, shops, and events, and all scoring math is done with fixed-point integers or deterministic decimal types. Input logs can be replayed across platforms to verify that the same sequence produces the same result.

Why is combo-chain scoring so hard to debug?

Because a single change can cascade through the whole board. A new card might interact with ten existing buildings in unexpected ways, creating exponential score paths. Engineers use graph traversal, incremental invalidation. And memoization to keep evaluation fast, then write unit tests and property-based tests to catch edge cases before they reach players.

How important is mod support for a small hybrid game,

Very importantMods extend the life of the game and build a community around it. The engineering cost is creating a stable API and schema so that user-generated content doesn't break with every patch. Distribution is easy through Steam Workshop; the hard part is sandboxing and validation.

Can single-player roguelikes really stop cheaters on leaderboards?

Not perfectly, but they can raise the cost. Local saves can be encrypted and signed. And leaderboard submissions can include replay data that the server re-simulates. Server-side validation of top scores is the strongest defense, even if it can't catch every subtle exploit.

Conclusion

Combolands may look like a clever pitch for fans of Cities: Skylines and Balatro, but underneath the marketing is a genuinely difficult engineering puzzle. Combining city simulation with roguelike combo chains forces teams to solve determinism - graph evaluation, modding safety. And anti-cheat all at once. The studios that succeed are the ones that treat the game as a pair of clean subsystems with a thin integration layer, rather than one tangled monolith.

If you're building a hybrid product-game or otherwise-the same principles apply. Separate concerns, instrument early, validate aggressively, and never trust the client. Want to talk through your architecture? Reach out to our team for an engineering review. And keep an eye on Combolands when it hits Steam; it will be a fun game to play and a fascinating one to dissect.

What do you think?

Would you rather architect a hybrid game as two tightly coupled subsystems or as independent services that communicate over a strict event bus, and where does latency make that choice painful?

How much server-side validation is worth the cost for a primarily single-player roguelike with asynchronous leaderboards?

If you were designing the modding API for Combolands,? Which layer would you expose first-data-driven cards and buildings,? Or a scripting runtime for custom combo logic,