Looking Back: March to July 2026
Looking forward is not always easy, but looking backwards can be surprisingly reassuring.
CityPunk in March 2026 compared with July 2026.
Comparing the game today with where it was in March makes the progress much easier to see. The tower has gone from a fairly simple spatial prototype to something that is starting to resemble the dense, interconnected city I originally imagined.
More importantly, the design itself has become much clearer.
After working through the GDD, prototyping systems, and reconsidering what makes the game interesting, I am now much more convinced about the direction: CityPunk is becoming a spatial deckbuilding citybuilder with roguelike structure, rather than a straightforward puzzle game.
The city itself should be the engine. Cards provide buildings, policies, and upgrades, while placement determines how they interact with the six neighbouring blocks.
That change in direction makes the design challenge considerably harder, but it also gives the game much more room for meaningful decisions, different strategies, and cities that actually develop their own character.
The Deckbuilding Focus
The next major goal is proving that the core deckbuilding and city-building loop is fun before adding more content.
A turn should revolve around selecting a card, placing a block, resolving its adjacency relationships, updating production and resident demands, paying ongoing requirements, and making upgrades that shape the city engine over time.
The main resources currently include Population, Energy, Supply, Capacity, Leisure, and Commerce. Rather than existing independently, these systems are intended to push and pull against each other.
A major design target is making different decks create genuinely different cities.
For the first prototype, I am focusing on two strategic extremes.
Corporate Compression
Corporate Compression is fast, dense, efficient, and unstable.
The idea is to grow aggressively, exploit adjacency bonuses, and complete objectives before the city's accumulated problems catch up with you.
Civic Arcology
Civic Arcology takes the opposite approach, investing in infrastructure, resident satisfaction, redundancy, and long-term stability before committing to large-scale growth.
Both strategies need to operate under the same fundamental rules. The interesting part should be how the player chooses to exploit those rules, rather than simply selecting a completely separate game mode.
If those approaches do not result in visibly different layouts, decisions, strengths, and failure states, then the core systems still need work.
Only after that foundation is working well does it make sense to introduce more archetypes, cards, and complexity.
Building a Proper Card Balancing Tool
That increased systemic depth creates another problem: balancing the cards.
The current Excel setup works, but it is rapidly becoming difficult to maintain.
Until now, most of the balancing work has lived in Excel. That was perfectly adequate during early prototyping, but the relationships between cards and resources are becoming too interconnected for a growing collection of formulas to remain practical.
Changing one value can influence several other calculations. Space, Energy, Supply, Leisure, Capacity, Population, and other effects all have relative costs and benefits, so manually keeping those relationships consistent quickly becomes error-prone.
I am therefore building a small dedicated card-authoring CMS and balancing engine.
The intended workflow looks like this:
Designer defines cards and their resource values in the CMS.
The system discovers how those resources depend on each other.
A solver calculates consistent relative valuations.
Every card revision is evaluated automatically for Benefit, Cost, Efficiency, and Strength.
Results are stored so cards and revisions can later be compared, filtered, and analyzed.
We can also experiment with different valuations per deck and set of cards. See, if you do not have the most efficient energy providier in your deck, then average cost of energy will go up and hence all energy consumers are less effective.
Ingame usage
The idea is that the algorithms also work ingame so that logic that provides cards to players knows what each player needs at any given situation. We are a very small team and hence need to automate as much as possible.
While I don't now if these calculation are even feasible, they give me a great headstart and base to work with!
What Comes Next
For now, the priority is deliberately narrow: prove the core game before expanding it.
That means:
Getting the deckbuilding loop right.
Making adjacency and resource trade-offs understandable.
Ensuring the two initial city strategies actually play differently.
Building tools that let me iterate on the card pool without losing control of the balance.
There are plenty of additional directions already planned, from new city archetypes to board members that alter how players evaluate their cities.
But those should remain design targets until the basic systems are strong enough to support them.
The game is becoming more ambitious than the prototype I had in March, but also much closer to the game I actually want to make.
And for the first time in a while, looking at the tower growing upward feels a lot like watching the design come together with it.