Bear with me a little bit, either if you are a microservice-enthusiasts or a hater. Each pattern and tech has its places.

At enterprise scale — multiple tribes, year-long programmes, regulatory constraints, teams across time zones — the bottleneck is never the database query, the API response time or the UX animation length. It's the organisational impulse, the weight of the moving whole. It's the three teams waiting on a single integrator team's API. It's the cross-cutting change that requires a six-week coordination window among 7 squads. (Be real, they are just departments with fancier names at this point.) Or the service that nobody owns fully but everyone depends on, long forgotten who made it, long left the building anyway.

Microservices at this scale work great when they're designed to scale the organisation.

Because it is faster to create small functional things in isolation than use and modify slightly something else that a thousand paying customer relies on daily.

For example, you might have three notification services. One for transactional emails. One for regulatory communications. One for marketing. They overlap. They're not DRY. They might be in three different languages, with different coding standards. And that's fine. Actually even desireable.

Each one is small enough for a single person even to own completely, modify quickly, and ship without coordination. Or anyone to pick up quickly, as to read a couple dozen lines in minutes and you can confidently modify with a good enough test harness around it.

And if you need a fourth — for a new channel, a new regulatory requirement — you write it and deploy it in a sprint. You don't refactor a shared service that three other teams depend on. That a nightly obscure job calls every so often and somehow holds up half the revenue in last quarter. You never mess with something that works.

But you build next to it. This is micro-efficiency over macro-efficiency. Building each service locally, is inefficient. The organisation globally becomes fast just for this reason!

My enterprise-scale Tech North Star package is built around just the right approach for this: choreographed microservices — event stream based, not orchestration — so no single service becomes the bottleneck that the whole programme waits on. No single fault point to bring down the entire revenue stream overnight.

It's not the architecture that looks cleanest in a diagram. It's the one that survives contact with two hundred engineers and a five-year operational horizon.

My medium-scale Tech North Star is built around this pattern — and its returning context: a core banking system, a complex end-user application in automotive, systems that need to integrate a dozen or so legacy calls and still let a team of twenty-ish people ship independently and fast.

That is harder to achieve than it sounds. The urge to scale up too early, especially for ambitious leaders to show off how they manage headcount, instead of how they succeed with less.

Just as microservices sound like the answer here. At this scale, with this team size, lacking the platform engineering enabling the real work, its just creates a distributed monolith — all the coordination overhead, none of the macro-efficiency.

A well-designed modular monolith gives you:

• Clear module boundaries that enforce team ownership without network calls bogging down the system and causing users to suffer a bad application experience.
• Integration seams that contain the chaos of legacy systems behind clean interfaces, so your team don't have to scrape their mind out at every feature implementation wrestling outdated legacy.
• A deployment model that a mid-sized team can reason about and operate without a dedicated platform squad, even on a Black Friday rush when every minute of uptime worth 100x revenue.
• ADRs that document why each integration decision was made — critical when the legacy system vendor changes or the integration contract shifts so blast radius is limited.

The package includes C4 diagrams at every level, decision records for the key integration choices, and a team structure recommendation that maps module ownership to squad boundaries.

You don't need to go distributed to go fast. You need to go reasonably modular.

I have seen widly different mistakes at different scales of the client, product or organization.

A small-scale system — a few engineers, a few weeks — doesn't need microservices. If you hand that team an enterprise architecture package and ask them to adapt it, they'll spend more time stripping out what doesn't apply than building the thing in the first place. The overhead becomes the project, and you can kiss goodbye to your investment.

An enterprise-scale system — multiple squads, year-long horizon, regulated environment — can't be solved at the module level. A single-service design is fine as far as it goes. Monoliths can be easily successful too. But it doesn't show you the system boundaries, the data flows, the regulatory touchpoints. It answers the wrong scaling problem, your scale is at the organization, not at the product or even the users.

The complexity tier you are at determines where you want to go and how you get there. My Tech North Star packages take these into account.

Pick too simple: you'll outgrow it before you ship meaningfully. Pick too complex: you'll spend your budget on scaffolding.

Each OTF Tech North Star package is calibrated to a specific scope. Not one-size-fits-all. The right skeleton for the right engagement.

Imagine a supertanker, fully loaded, engines running at full capacity, sailing the ocean, loaded to the brim.

Now imagine changing course every few days, or even hours.

It doesn't matter how powerful the engines are. Every course correction costs speed, time, and fuel. The ship never reaches its full velocity because it's always in the middle of turning.

That's what happens to engineering teams without a shared architectural direction. Their momentum is shattered, then you ask why they are not delivering. Then throwing more money or resources onto the problem that never had a solution in those areas.

Each new senior hire arrives with their own opinions. Each quarter brings a new strategic priority. Each undocumented decision becomes a revisited argument. The team is capable. The engines are running. But you're always turning, turning and turning.

A Tech North Star doesn't lock your direction forever, but gives a good sense and a narrower arc to turn in. It records why you chose this one — so when circumstances change, you change the decision based on updated facts, not because someone new in the room has a different instinct.

Teams with a Tech North Star move faster because they stop losing momentum to realignment and finally they build the directional momentum that translates to their velocity.

Tech North Stars require real leadership, making the calls for trade-offs. But the compounding return makes it worthwhile to invest.

Start from one that already holds course: technorthstars.hu.

I hear this a lot. And it's true: any LLM can produce a C4 diagram in seconds. But always, there is a catch.

Here's what it can't do:

It doesn't know that your team tried microservices eighteen months ago and burned six months on service mesh complexity before reverting to a modular monolith.

It doesn't know that your regulator flagged a specific data residency concern that ruled out three otherwise obvious vendor choices.

It doesn't know that your lead architect is leaving in Q2 and you need decisions externalised before institutional knowledge walks out the door.

And it doesn't tell you to which context to add, which is irrelevant.

An LLM generates plausible structure with other people's decision inherited and not even spelled out.

An ADR records your decision, with your constraints, for your future team.

The value of a Tech North Star isn't the diagram or the nice slides. It's the reasoning behind it — human-authored, context-specific, and designed to guide the next decision.

Use the LLM to move faster inside the structure. Don't use it to avoid creating a structure.

The structure, written by a human who has had to live with the decisions: technorthstars.hu.

Every package I've ever built in a real engagement is 40% universal things and 60% specific to that company, that team, that regulatory context.

The temptation was to include every dimension. Show all the work, the pieces to fit to any project you can have. Pack in every variant.

But that would have been useless.

What you actually need is the skeleton that's always right — and the space to fill in what makes your situation unique.

So every one of my Tech North Star packages is deliberately incomplete in the right places. The structure is there. The trade-offs are documented. The blanks are clearly labelled blanks.

That's not a bug, that's the feature you need.

Architecture that can't be adapted to reality isn't architecture. It's a day-dream dressed in diagrams and tech jargon.

Well, best practices have context where they work best. My approach is always a self-describing code. Comments are only for the why, the decisions the code doesn't capture and the occasional exceptional implementations.

And I rarely had not enough time to document due to my focus on what matters. However most of their teams, peer engineers said "We don't have time to document." I get it. But after 20+ projects, the same pattern returns.

Those who say they don't have time to document are actually the ones re-litigating decisions on review boards that were made weeks ago, spending another three hours of everyones time. Then another engineer is about to onboard and the dance starts again.

Why we use that stack? Why not a different one? While the users still can't log-in to their account in an embarassing ratio.

The right documentation doesn't waste time or prolong a project. It recovers the time tax you already pay anyway, just hides in your calendar under meetings.

Then I get a different answer sometimes: "We already have the architecture diagrams."

Great. But they you look and those didn't explain the why. They are not even accurate anymore, the code diverged long ago. A new engineer reads the doc, looks at the code and then codes the wrong solution confused by the two worlds, trapped by trade-offs undocumented, repeating mistakes that shouldn't have been repeated.

If you fix these problems, congratulations, you finally got a viable Tech North Star. A documentation that doesn't just tell what is now, but gives a plan how to go ahead and where are you going. That worth all their efforts.

However, given a boxed version, you would say: "But we build our own North Star."

And yes, you absolutely have to. But do you know what goes in to one and how to structure for effect? A Tech North Star no-one buys into or confused by can even damage ongoing or future projects.

Take my package as a starting point. Keep the structure, adapt the content to your context. Throw away what doesn't fit your organization. Wisdom is human.

But the package gets you to "good enough to build on" in days, not months.

And it was about what happened in the room.

"You can connect engineering and business world, you have huge experience and great people skills. Best experience that you entered our project and calmly got it back on track. At the time I could not imagine myself doing that."

— Roland Sz., senior data engineer

That's the thing I keep trying to bottle, the spark to capture so you too can wield it.

Not the C4 diagrams. Not the ADRs. Not the cost model. Those are important but the key lies in between them.

The moment when someone who thought they couldn't do it realises they can — because they finally have the structure to think clearly and communicate at the right level.

My Tech North Star packages are my best attempt at making that transferable to any engineer, heck even to any digital expert, they are understandable for non-techies too.

The frameworks are included. The structure is built. The blanks are clearly labelled to fill in.

You bring the context and you lead the room with better judgement. Not much to wait for the first drop.

A missed security control at design time costs tens of thousands of EUR in remediation. A misaligned system boundary costs six months of rework. An undocumented decision shows only at a key engineer's departure, with institutional knowledge you can't recover.

These were always foreseeable, only if you had a baseline to compare against. A burger at McD's is same all over the world and you can rely on its quality because of a baseline all worker has to follow, a checklist each has at their stations.

As a CTO, you have so many topics, don't you think you need one of those tailored to your job? But all so unique. Content-wise you are right. Structure-wise however...

My Tech North Star packages give you, the executives a validated reference architecture — not a theoretical framework you put to the drawer a day after download. These are real patterns built from real delivery programmes I delivered — so you can benchmark your current state and spot gaps before any of them become a crises.

Customize to your organization and situation in days. Not months and after ludicrous consulting fees. Only an afternoon to orient, a week at most to adapt to your situation.

Then confidently walk into any architecture review with C4 diagrams, ADRs, and cost-of-ownership analysis your board and auditors already understand.

And not even in the same team, that is a whole another pain. Now I talk about the repeated rythm of engagements with new clients, every quarter of half year you switch to another one, doing the same dance.

You know what you need to build. You know the right structure, you did it ten times. But every new engagement, every new team, every new CTO — you start from a blank Confluence page or a blank Miro board with dozens of opinions around you.

That's months of work before you can do the interesting part. You know, the unsexy alignment, the let's figure out how we build before we even know what we build.

OTF Tech North Stars exist to give you the skeleton so you can focus on the real meat right out the door.

Pre-built C4 diagrams. Pre-formatted ADRs. Cost-of-ownership breakdowns ready for a board deck. Security architecture already framed. Business Continuity planned and ready to practice.

You bring the context. The structure is already there. Forget the grunt work of formatting diagrams. Finally you have the bandwidth to think one step ahead of the business and truly shape a successful engagement.

Senior engineers focus on a part, hopefully vertical value more closer to the target userbase. Principal engineers focus on the big picture and how the ecosystem fits, how regulation, safety, security, reliability and team capability influences the outcome.

And they translate to decision makers above - how each dimension impacts the business and propose to change effective levers.

Most senior engineer I've worked with who hit a ceiling had the same pattern:

• They prepared the right solution - deeply understood the tech.
• They presented it at the wrong altitude - wandered off the details.
• They got "let me think about it" - lost the attention and trust midway.
• They repeated the cycle - unknowing even they failed influencing in the first place.

What changed for the ones who broke through was their mindset: derive business impact of your solution.

Then simplify it to the core of the decision the leaders, executives need to follow. Raise the view to bird's eye - using C4 it is in your veins - and show the trade-offs leaders can reason about.

I got non-tech consulting partners to understand complex systems just by the right few boxes drawn on the second day I joined onto a programme running for half a year - they never understood what they built until then.

Next, learn to write and ADR any stakeholder could actually read and argue with. The decision is rarely about a tech anyway, it is about their trade-offs. Any leader worth their compensation can reason about trade-offs.

Finally, connect a technical decision to a cost line item or a regulatory risk.

Client wants a complex push notification back-off system to not annoy the user. Show the cost while the basic product functionality is not working and they thank you for the insight. Project saved.

That's the jump. From "great developer" to "the engineer who changes the outcome".

At one of my clients, the C4 component diagram I drew on their team room's whiteboard stayed there for a year after I left. It was so useful for them, they didn't want to clear the expensive, large space to use it for anything else.

The OTF Tech North Star packages are the exact treasure trove to teach you this structure, by real examples. Study how a principal engineer thinks then apply it to your own situation. You won't regret it.

Those enterprise diagrams are not wrong, exactly. They're just designed to impress in a review, not to guide a team.

They get drawn once. They live on a Confluence page nobody finds. They're out of date six weeks after the sprint that created them. And when a new engineer joins and asks "why did we choose this approach?" — nobody can answer.

The diagram exists. It is huge, boxes become dots on zoom out. The decision is lost. The team is confused. Each member understands it slightly differently.

Real architecture documentation does three things:

1. It shows where you're going, not just where you are.
2. It records why, not just what.
3. It lives close enough to the work that it stays honest.

My Tech North Stars are built to do all three. Without becoming the next edition of "War and Peace".

Stay tuned, the first package is about to drop soon.

For years, every time I joined a new engagement, I rebuilt the same architecture artefacts from scratch. C4 diagrams. ADRs. Cost breakdowns. Security layers.

Different industry, different company, different team — but the same skeleton underneath every time.

Banking. Ecommerce. Logistics. Even game development. Eight countries. Twenty-something projects. The patterns don't change as much as you'd think.

About a year ago I started writing down the patterns instead of just applying them. Partly for myself, partly because the engineers I work with kept saying: "I don't get it, why this decision? Why not this better one?" Partly because I built my startup as CTO, making the same decisions again, for the 21st time.

Decisions, that need their "why" and context so the team buys in and supports all the way.

Not a whiteboard full of boxes. Not a 200-page enterprise framework and endless pages no-one will read. Something they could open, understand in an afternoon, and adapt to their situation by end of week.

That's what an Off-The-shelF (OTF) Tech North Star is.

Off-the-shelf architecture packages — C4 diagrams, ADRs, cost and security angles — for the archetypes I've seen work at the scale that matches certain projects.

Not theoretical. Based on real deliveries, under real constraints, with real teams. From digital channels to full-on enterprise scale systems.

Built for the engineer who needs to stop starting from a blank page and start delivering at the level of a principal leader.

It launches in the coming weeks.

Fun fact. My system diagrams usually live on the team rooms' whiteboards for years, they are so valuable to get everyone aligned in the room. Condensed, well thought out, up-to-date blueprint is king for long running projects.

Check out what I am building for this topic at technorthstars.hu.

It's actually a multiplier lever they're giving up at the start.

Here's what a proper Tech North Star contains — and what each part is worth:

C4 diagrams (Context -> Container -> Component) No complicated and cryptic UML. Not whiteboard screenshots deciphered by sages. Layered maps that let the board, product, and engineering have the same conversation without anyone translating. From bird's eye to ground floor plan, connecting context and detail.

Architecture Decision Records (ADRs) Every non-obvious choice, written down, with the "why" — not just the "what." So when the team changes or priorities shift, you argue from facts, not feelings. And you focus on decisions that matter, not on wishes and dreams individuals bring.

Cost-of-ownership analysis CapEx and OpEx laid out clearly. The thing that makes or breaks a budget conversation with a CFO. Or risk being cut when the bottom line tightens.

Security architecture Never an afterthought. Built into the baseline so auditors stop being a surprise. Data, governance, encryptions and signatures, rotation and procedures, all critical to keep operating.

Tech stack trade-offs The reasoning that lives in the architect's head, externalised. So the decision can be challenged, improved, and survived past that architect's exit.

Business Continuity Plan The risk matrix and the collection of pre-planned steps to mitigate or recover when the unlikely happens. The checklist that saves your business overnight from bankruptcy.

This is the skeleton that separates "we have a plan" from "we have alignment."

Every project I've led that didn't have this cost more and delivered less. Without exception.

As you see, the Tech North Star is much more than just tech. Stay tuned and in the next weeks I show you what it can do for your business. And release the first off-the-shelf variant.

That first variant is out soon — check out the Sales Funnel Tech North Star.

CEO, Product Manager, CTO, architect, tech lead and the engineers all have a mental image about what and how they are building. But short of hours and hours of 1-on-1 communication daily, their thinking drifts away from each other.

All well intentioned, none incompetent.

Yet they argue about coding language and tech stack instead of which experiment to run with customers.

They argue about increasing headcount or optimizing processes before even understanding the goal they need reaching.

They burn the midnight oil to reach an artificial deadline instead of asking, what do we gain by it or by delaying it?

This just means they never had a shared map.

I've seen this playing out over and over again on my 20+ projects across countries, even continents. Banking, telco, automotive and logistics. Even in game dev it is always the same. No matter the industry, no matter the scale.

Decisions are revisited, causing further delays without value to show for. Scope creeps in like water through soil, drowning the project in inefficiency. Every new engineer questions foundational elements before business value was even created, further slowing down progress.

Until one day, the project gets cut, the company reorganizes, the product shelved with all cost wasted. A small document could have avoided the outcome.

A map being updated as we go fixes the alignment with rather small overhead. This is a Tech North Star, that describes the agreement in clear language, what and how do we build, and why we decide this way.

I have spent countless hours in the last 10 years building these for teams, every time with a resounding success (one of my arch diagram stayed up on a whiteboard for over a year, referenced almost daily even in stakeholder convos).

In the coming weeks, I start releasing off-the-shelf versions.

More on that soon.

Check out what I am building for this topic at technorthstars.hu.

So many details you can say a digital transformation stalls on:

• missing talent or experience,
• not the right tech or architecture,
• org schema wasn't revised well,
• internal politics and pushback,
• misalignment of stakeholders.

Easy to hide behind all of these excuses. They are all forseable from day 0, yet they end up in the post-mortem or on steerco decks months after the start of spending? Yep, always.

If so many pitfalls for a project and known ahead of time, why would you even attempt it? Market pressure, loss of market share, competitiveness, my peer companies will beat me, etc. Or just pure "let's make our org the best it can be" good intentions behind. In our modern world, there is not really a choice to go digital on as many aspects as you can.

But then how not to loose the company on the new bet? Every leader wants to be a hero, a saviour of the company, a market genius. But the most successful ones do one thing right: hedge their bets.

Take a calculated risk, prove it works on the minimum cost possible and then double down to scale it.

Choose a smaller vertical slice of your company and transform that first. A new digital sales channel while you operate all other areas. Maybe lower a little bit their operations, like 10% to move in-house talent to the new initiative. Experienced operators learning new skills will beat any new hires in DX.

Talent shortage? You need 4-5 really good people, augmented by 1-2 from the market. Hard to fail on this in a thousands of people org.

Not the right tech or architecture? Start with a Tech North Star of how it should look like in 10 years and build only the new pillar on it. Don't fall back on existing ones, keep to the new approach for the whole project, scrap or integrate afterward.

Org schema wasn't revised well? Smaller orgs are easier to shift and change before scale, learn and integrate the insights before costly office politics kick in.

Internal politics? Pushback? Easier to isolate a small team with a clear KPI/OKR for them, support them from top when they inevitable hit red-tape roadblocks. Success beats politics, hard to argue with "but it drive 20% revenue growth" in steercos.

Misalignment of stakeholders? Minimize resposnible people. 1 decision maker with budget and ownership at the same time. Bring on board the others based on success metrics, not on promises. Smaller scope makes alignment easier too.

Focus your digital transformation to a 3-4 months runs, each with tangible results. The only way for a permanent improvement of your organization.

What was the worst problem you had to face during a digital transformation?

Stay with me for a second.

When 3D printing came along, there were a lot of voices it will revolutionize manufacturing. Had its mini-boom, and by today it is normalized along its natural constraints. It did revolutionize a very specific part: prototyping. But scale remains part of other, specialized processes and manufacturing develops further.

See the parallel? I think that is where genAI eventually really end up: prototyping digital products has been revolutionized. However its constraints still unknown at this point.

What is a chocolate bar? A temporary good feeling, maybe even a pinch of energy and a tickle to your brain’s happiness spots. But when you consumed it, it is gone, and costly to replenish for next round. The more you eat, the less one piece feels satisfying. And the hidden costs appear way down the line. I think now it is a perfect parallel for genAI.

It feels good to use in the moment, but the hidden costs kick like a horse way later:

• Subsidized market: current consumer prices are still undercutting real costs and opaque business deals make it hard to measure up real costs and where current balance should lie.
• Loss of reasoning: you and your team unable to own the output as they never did the hard work of coming up with in the first place.
• Mental atrophy: losing necessary thinking skills by outsourcing (brain is like a muscle, oversimplified but catchy comparison).
• Value misattribution: we had a copyright system for a good reason, the original thinkers need to be valued appropriately to keep a market reward so they invest time and energy (I am a writer myself, and cheapening a craft makes it demoralizing at the least).
• Attack surface explosion: non-engineers coding any of their own tools/problems create enormous IT security surface area we don’t have tools or processes yet to handle. At least not stably and not economically.

I frequently use genAI myself for coding and prototyping, it can be great but I already feel the negatives on my own skin every day. I don’t think the world was ever constrained by how much code we can write.

It is indeed constrained by how costly the code is. Just code doesn’t have a linear or simple cost structure. Most of the cost is in the understanding of a problem, designing a dozen or more solution, and try them until one fits. You can automatically test if code works but can’t always test correctness.

And making code cheap now just creates a world where everyone asks only the “can I do it?”, rather we need to ask as always: “should we do it?”

Digital transformations (or DX in some regions) are huge undertakings, a serious capital investment from any organization taking it seriously. However, do they really have to be?

I think DX supposed to describe the journey, not the type of investments or project you make. It is supposed to be a chain of projects, each aiming to improve a facet of your business on its own. Each to be done fast, maximum months, and follow up for real impact on your business.

As you move through the chain of projects aimed to transform your business, be it core modernization, legacy upgrades, new sales channels or any digital product or improvements, it provides the insights needed to correct and change direction.

This is the real essence of a transformed organization. When its DNA incorporates change. Thought out, impactful, measured change. And when that change becomes the default, you finally have an organization that will stand the test of time.

Tech, consultants, services, all come and go. Customer needs are constant. Serving them effectively is your market. All other aspects change with time as your organization needs to adapt too.

Do you run a transformation right now? What is the last tangible benefit you can point to that your transformation delivered? If the answer is underwhelming, shoot a DM and let's connect. A delivery-led transformation always aims at business value first, through end-customer satisfaction, rather than maximizing billable hours or seat based pricing or whatever.

Let's build your timeless business together.

Instead of the promised research focus, I had a different mood and creative energies lately turning me back to the new combat mechanics. I scaffolded a simple block-out in ThreeJS integrated into my demo to start visualizing this experience and it made me think more deeply.

With endless scope as any project can struggle with, my scope is about to balloon if I don't structure it. In the end, simple and elegant solutions play better, create more engagement and can bring an idea to wider audience.

We are all familiar with simple games and there is a good reason for the commonality among children. They are simple to learn, yet provide wide range of experiences. Can't use infinite, as they are all finite state machines, even chess with its astronomical numbers, there are still finite steps possible in the game.

Chess - the ever-lasting strategy game

Let's start with this old game, very much inspiring endless takes and genres. In sci-fi, almost always there is a variation put into three dimensions or more, both Star Trek and Andromeda series features games for storytelling or worldbuilding. Saw plenty of takes, even on latest Hungarian Game Dev expo a team pitched a new game for publishers entirely based on Chess, made real time.

Originally, I didn't wanted to do anything with Chess, it is so overused. But I have to agree, it has a framework hard to ignore for any good game:

• a set of pieces you control,
• a set of rules how those pieces move,
• clarity how the pieces interact,
• and a clear goal (take the opposite King).

And out of this few rules, born a game easy to learn, hard to master. So hard to master that there are people earning a life playing the game. Queen's gambit, anyone?

Putting Perseus Patrol's combat engagements into the same framework:

• have a set of pieces you control, be ground, air or space units,
• a set of rules how those pieces move, traverse layers,
• clear rules how the pieces interact with distance, direction, damage and other actions,
• and a clear goal for each mission, e.g. capture, hold, defend, exterminate.

Chess is turn based between two minds. Perseus Patrol will be real time, a major difference, yet what real time is really? Opposing minds still take turns acting and reacting, just they don't have a limit when they can move their pieces.

The key interaction seems to be the moving the pieces and let's dive a bit more into this. Chess has only movement, while space sim strategy games have a bit more options to do. A vessel can move close enough to another, but maybe not with the intent to attack. Maybe just boarding, or trading, sharing resources, to scan, etc. Yet all actions unlocked by the distance the pieces are from each other on the board.

Reminding ourselves from the 6th devlog, the layers are: subsurface, surface, aerial, atmospheric and orbital (with deep space acting as reserve layer).

We can imagine each layer as a chessboard with the subsurface and surface layers having natural and artificial obstacles, while the other layers having no obstacles, only active pieces.

Rock, paper, scrissors - simplicity rules

We all know this child's game. And we all know about its variations to more nerdy extensions a'la Big Bang Theory. Still fascinating for me that so many RTS games adapted it and made an otherwise dull game good. Just think of StarCraft and that you can't just build a single unit and win the game. You need to create a mix of units to be able to take on the enemy, or you risk being countered.

This is thanks to the simplicity of the rock-paper-scrissors. Where there are clear rules, if two units meet in one-to-one, one of them wins most of the time. An infantry that can close the distance fast will always beat a slowly hitting anti-armor tank. A fast moving bike will always destroy your infantry if you can't catch them with something armored. And so on.

Using this logic in a three dimensional space, a fast moving bomber could take on cruisers in a swarm and win if there is no fighter cover as they could outmanouver the slow and heavy ship and hit it from one direction.

Mapping unit classes

Chess has the pawn, rook, bishop, knight, queen and king, each with its own movement pattern and speed.

Rock, paper, scrissors define a win and counter logic.

Unit class

Strengths

Weaknesses

Good against

Infantry [surface, subsurface]

Agile, traversing terrain. Adaptable kit in squads. Low armor and health, squishy. Heavy armor

Heavy Armor [surface]

Can take punches, can mount bigger guns. Needs space, very slow, expensive. Light armor, Heavy armor

Light Armor [surface, subsurface]

Moderate armor, fast shooting of moderate guns. Limited terrain, slower. Infantry, Fighter, Bomber

Fighter [air, atmo, orbit]

Fast moving, fast shooting. Weak guns, low armor, squishy. Light and Heavy Bombers, Fighters, Destroyers

Heavy fighter [atmo, orbit]

Fast, manouverable, armed with ship-to-ship. Weak, squishy. Destroyers, cruisers, carriers.

Light Bomber [air, atmo, orbit]

Precise, close air support. Weak armor, squishy. Light and Heavy Armor, group of exposed Infantry, Cruisers.

Heavy Bomber [air, atmo, orbit]

Area-denial, area of effect weapons. Slow, can't protect against aerial threats. Heavy Armor, large group of Infantry in bunkers, weapon emplacements. Cruisers and Carriers.

Transport [orbit to surface]

Deploys surface units from carriers. Some armor to protect from small and light guns. No protection.​

Destroyer [atmo, orbit]

Heavily armed with ship-to-ship guns and missiles. Almost no flak and small ship counter. Frigate, Cruiser, Carrier.

Frigate [atmo, orbit]

Lots of flak and small but plenty of guns to target swarms of fighters. Medium armor, low damage to armored ship hulls so Destroyers can outlast them even one on one. Destroyer, Fighters, Heavy Fighters, Bombers.

Cruiser [orbit]

Ship-to-ship combat specialization, small complement of figthers and bombers. Low protection against small ships and can be outnumbered easily. Frigates, Cruisers.

Carrier [orbit]

Can act as orbital bombardment platform, hosts and deployes Fighters, Bombers and Transports. Light protection in direct combat, slow charge and use of main weapons.​

Scope management is critical to success

As you can see if you follow my devlogs, the scope is just growing over any single developer can do in a reasonable amount of time. Best way to do this is to check each game mechanics and their parts against a single question:

• Is this core gameplay?

Obvious candidate to ask for, is subsurface a core gameplay element? I don't think so. It gives great options for a variety of planets and usage of terrain, however these are just widening the options a player can take. The core gameplay is about the management of multi-layer units and playing a real time chess against your opponent.

Cutting scope without damaging the core gameplay is essential for a successful project. Especially for a "pet" project. Even more so for a multi-million dollar AAA, where the leaks are even harder to stop when they already started.

In my management consulting years, almost all of the projects succeeded purely because we cut scope smartly. 2 months until deadline, decision between rebuilding a system part taking 3 months or integrating the old one that stands out from the experience, but takes two weeks. I fight for the integrate, most of the team already low on morale as that "won't be nice". But nice doesn't matter if the whole project is at risk of cancellation before it could reach the users. So we went with the integration. 1 step out of 15 was lower quality, older. Didn't matter for the users. The other 14 steps made up for it. Delivered barely on time, rolled out just after deadline and... the product is a resounding success in terms of investment.

Scope cutting is key. If you can't get people on board to cut, it will always bloat you to death. And a project that never turned revenue is a learning opportunity at best. An investment failure and a bad lesson for the organization. Career ending at worst.

What else can I cut from the game scope?

Most of the units are there for countering each other, but a rationalization can be done as a next step. Carrier can't be cut, it is the main story element 🙂

Summary

Simple game logics sell as people know them and they can learn quickly even if they are overused, can be used as inspiration.

Chess is often used for sci-fi settings, combat engagements can be thought of multi-layered chess boards.

Rock, paper, scrissors principles keep the combat fresh instead of the dullness of using a single God unit for everything.

Scope cutting is key for project success.

Next time, I try to focus on the research side of these. I may diverge into more details on the units and how they interact, especially the role of the layers. Let's see what the future brings!

• game theory and crisis bargaining,
• escalation ladder.

Theory is nice and needed, but practice makes it enjoyable for the players. To bring it even further into reality, let’s simulate logically what happens with the first decision each colony can make:

• stay/join the federation,
• leave to be independent.

To complete the mix, what is leading up to a decision like that?

1. Motivation differences create friction,
2. friction escalates to thresholds,
3. thresholds trigger change in state,
4. enough state change and it results in alliance broken or strengthened.

To entice a colony to be part of something larger, the “larger” has to sooth the colony’s needs. In a world with four major action area (military, engineering, science and diplomacy) the needs are corresponding to the same areas too:

• to be safe, e.g. its or its allies military power outweights the dangers in the local area, to use force projection to secure interests,
• to grow, e.g. able to feed their citizens, house them, economical prosperity,
• to learn, e.g. new techniques and scientific achievements in collaboration,
• and to influence, e.g. culturally or politically exert concessions, change minds and hearths, and get early warnings of adversaries.

If any of these are fulfilled by an alliance, the colony is warming up to that faction or getting more supportive of it even.

The Federation

Treating an alliance as a living being, it grows and shrinks in a natural way by their elements interacting with each other. This means that the “larger” entity is only a self-determinism of each actor independently and exists until at least one colony is supporting the entity.

Let’s simplify into positive and negative factors how a single colony’s relationship to the alliance changes. The actions are not exhaustive, just representative:

• Military angle:positive:policing without civilian losses
• eliminating outlaws
• Steeldome visits delivering supplies negative:
• mobilizing military forces without reason
• attacking its interests
• blockade of its trade Engineering:
• positive:deploy repair crews
• build new facilities
• construct civilian ships negative:
• remove repair crews without finishing
• deconstruct facilities for their raw materials
• deconstruct civilian ships for their raw materials Science:
• positive:share technology
• improve facilities negative:
• scan owned facilities
• scan force deployments Diplomacy:
• positive:share culture
• networking and schmoozing
• share intelligence negative:
• bribing
• spying
• stealing
• assassination

The main idea is that these actions can be taken by any colony or core world against any other, influencing their relationships. The core world of an alliance holds it together and when its influence is failing to reach a certain threshold, the influenced will secede from the alliance. If another alliance builds up enough influence, it may join them and this cycle can be reversed by the player with effort put into it.

The key will be to design a system that allows for a sandbox like behavior yet supports the narrative of a failing but originally good alliance’s last “hours”.

Could allow even the player to secede from the Federation and join another faction or start his/her own!

Case studies

Learning from the greats will definitely help in cracking the alliance model.

Civilizations​

https://civilization.fandom.com/wiki/Alliance_(Civ6)

In this series, alliance mechanics changed a lot over the episodes, yet the underlying phylosophy I think was always the same: accrue points based on trade and similarity, lose with military movements. The game is centered around the “can your civilization stand the test of time” theme which pushes the alliance system to a secondary support role in my eyes. Most playthroughs do not care about maintaining any alliance, more like pushing down the confrontations until you are strong enough to wither any war scenarios and find win conditions. Still, using benefits from this system could allow for the carrot part of the carrot and stick based relationship building.

In my game, the parallel would be if the civilization you control is composed of an alliance of the settlements.

Imperium Galactica II​

Even earlier model, very similar to how Civilizations handle the relationships between civs, including the spying and diplomacy. Most probably it was inspired by earlier Civ instalments.

While great for its time, and still stands to have fun playing with it nowadays, the systems are too simplistic for my game. When the theme is centered around complex group behaviors, comparing powers and giving a basic behavior of the sides won’t cut it.

Hearts of Iron​

Haven’t played it, but read about it only. Seems very player decision centric approach, where the AI mimics similarly the player decisions. It is a great game but not the direction I am looking for.

Maybe I am going wrong about this research approach. Most RTS are designed like a god-game, the player is the ultimate decision maker where one city deciding allegiance is very simple: it is only for challenging the player to handle some resource constraint:

• Civ’s morale and growth rate,
• IG II’s empire goals,
• HoI’s military powers and intelligence,

etc.

In Perseus Patrol, the player is the ultimate decision maker for the ship only as its captain. These mechanics will be interesting for ship morale and internal turmoils to give depth to dilemmas and player decisions. However too shallow to model the inter-galactic politics after this. A new approach is needed.

Game of Life​

A simple model we learn early in programming. Only two rules and you can create a non-stable system where for humans, it seems like a living noise.

Alliance dynamics​

Learning of how scholars think of modeling alliance and coalition behaviors could be the unlock I am looking for.

https://repository.ubn.ru.nl/bitstream/handle/2066/30918/30918_;jsessionid=80ECE7CED75FA6125F503B4D7EEBB6E2?sequence=1

https://www.sciencedirect.com/science/article/pii/S0972860016301621

https://webs-deim.urv.cat/~juanalberto.rodriguez/Tesis-Ismael-Gonzalez-Yero.pdf

http://slantchev.ucsd.edu/courses/pdf/ramsay-fang-alliances6.5.pdf

Quick scan of these documents show one insight for me: alliances can be modelled as cluster of points in a graph.

This matches perfectly with the celestial model I built, each colony is a vertex of that graph, the relationship between the colonies are the adjacency strengths. Using these, I could build an algorithm that defines the alliances forming, with some threshold crossed, a new alliance can be formed or an existing one dissolved.

A* route calculation, water flow algorithm​

Thinking of an alliance as a concept radiating from its core world, each colony that belongs to the alliance should have a strong enough route. This route can be calculated like water flowing on terrain. Start from the core world and expand the wave, weakening it with each relationship it has to “flow” through. If there are more than one route, like core world is close enough to multiple colonies, then a single colony’s allegiance can be calculated as a sum of core world direct effect and the nearby other colony’s effect (indirectly from core world).

This can help model a dynamic effect of an alliance growing or shrinking with threshold values deciding. If a colony shrinks below set value to a e.g. the Federation, it may secede into independent status. If its allegiance grows to any alliance above a threshold, it may join to that alliance. Or in the case of independent colonies growing allegiance to each other, form a new alliance themselves.

Simplest possible model: solidarity​

https://hackaday.com/2025/06/25/simulating-empires-with-procedurally-generated-history/

https://www.youtube.com/embed/1p3tMNbFdCs?feature=oembed

An interesting idea presented by Fractal Philosophy, who found Peter Turchin’s concept:

https://peterturchin.com/does-history-cycle/#:~:text=Ibn%20Khaldun%2C%20as%20many%20of%20my%20readers,and%20wanings%20of%20collective%20solidarity%2C%20or%20asabiya.

In my crude words, high solidarity between members creates the empire/alliance, over time the solidarity wanes leading to a breakdown of the empire. And the cycle starts again.

This concept worth more deep dive as could give a simple enough to understand yet feeling living enough to be interesting backdrop for the alliance system in Perseus Patrol.

Summary

In this article I try to expand on the concept of alliances in Perseus Patrol and got to the conclusion:

1. Previous games are not focusing enough on alliance dynamics to get inspiration or model my solution over theirs.
2. Instead foundational research needs to be learned and discovered the alliance dynamics from game theory as a good direction.
3. Modeling expansion and shrinking of alliances can be compared to water flowing on terrain and use similar routing and wave algorithms to simulate.
4. Introducing threshold values enable the simulation to dissolve or create alliances dynamically.
5. Using the solidarity concept can simplify and present the player with a number to drive with decisions.

Next steps will be very complicated for this:

1. Read in depth the found research material,
2. Design the concept with representation (UI/UX) in mind,
3. Work out a simulation algorithm for alliances,
4. And procedurally generate the starting point of the story.

Next, I will dive into the research system implemented and being tested for Steeldome’s improvements.