Who would've expected a niche indie artillery game to grow at this pace
Greetings, Operators!
It's hard to believe it's already been three/four months since we first revealed our project on Steam. Time is moving so fast it sometimes feels like it all started just a week ago... Back then, Nick and I thought we'd post a devlog every 1K wishlists β roughly once every two months. Not only did we miss the first one by about five thousandβ¦ now, as we're writing the second devlog, we've just crossed 20,000!
Commissar, record their names.
Mark every recruit who was among the first to summon the courage and answer the call to mobilization.
They stood when others hesitated.
They stepped forward when silence was safer.
Glory to them.
Glory to the sons.
Glory to the fathers.
Glory to the brothers who stand here united.
~ High Command
β β β Previously, I promised that this devlog would be more technical and since I mainly handle marketing, Nick has prepared something for you! β β β
IRON NEST - Mission Loop: From Concept to Gameplay & Replayability
Nick: When I first started prototyping IRON NEST, (Which was the 5th "big gun" prototype game I made this summer and the 1st one, which was not a hot pile of poop) I wanted missions to feel grounded, like you're actually running an artillery gun, not just ticking off objectives.
So instead of a "go here, shoot this" checklist, I'm building everything around a living map: bearings, distances, impact points, and intel all stack together so you can piece together what's happening out there, even though you're stuck inside the turret.
I could've gone with fixed target spots and scripted situations, but that would've murdered replayability, and replayability is a huge pillar of IRON NEST. Honestly because I need to playtest it for 1000s of hours, and I would go insane replaying the same missions that many times.
The first real headache was honestly just⦠space. Unity's UI has a bunch of different coordinate modes, and they all have slightly different opinions on where "here" actually is.
My solution ended up being pretty simple: I decided to base the whole map system on the local space of a world-space UI.
That means the map is basically a flat 2D "plane" in the world, and I can treat it like real space: 1 Unity unit = 1km. Everything on the map: targets, impacts, recon markers, etc. lives on that same plane, so all bearings and distances come straight from that. I could move that plane around, rotate it, scale it, etc. and the system still works.
Next up was figuring out rules and outcomes. Different shell types, sometimes a target may need a single hit, sometimes a full salvo, plus all the Success / Failure / Bonus stuff⦠and I really didn't want that turning into a giant pile of if-statements.
So I kept it data-driven.
Each target/location has a small list of rules (my ShellEffectRules) that say, this shell type + this many hits = this result. Then when a shell lands, the location checks the rules and decides what that impact actually means: blow something up, disable a system, give you credit, trigger visuals, whatever.
The nice part is the "decision" happens right at the impact, and everything else just reacts to it. Clean cause-and-effect, no less hardcoded spaghetti.
Then I moved on to intel. Stuff like bearing lines (083Β°), distance readouts (1.25 km), grid coordinates (B9 4:2), etcβ¦
Because every target/ally/enemy token is being resolved live inside the same shared map space, I'm not locked into fixed positions or scripted moments. I can set up a situation, let the pieces land where they land, and the map intel still makes sense. The mission can evolve, i.e. units moving, dying, arriving, and every new bit of intel can react to it.
This is where the replayability really starts to show up.
Missions aren't locked to one "correct" layout. Spawn zones can pick different positions, stuff can show up mid-mission, and the intel you get is generated from what's actually happening right now.
So even with the same mission template, you can end up with a different map setup. And the same shot can lead to different followup intel depending on who's still alive, what recon/correction level you're working with, and what shells you're using.
Once the loop clicked, the rest fell into place:
Impacts are the single source of truth. When a shell lands, anything inside the blast radius checks its shell rules and decides what happens: damage, rewards, disabling systems, whatever that location is set up to do.
Intel comes in with a rhythm. I've got a queued, typewriter-style printer that feeds you info through triggers (like entering an area), so stuff doesn't just instantly pop onto the UI. It shows up when it makes sense in the moment.
From the player's side, it ends up feeling coherent but still unpredictable. You do something and the world reacts. Bearings actually point where they should. Distances line up. Unit locations are only visually revealed when recon photographs overlap with their actual positions. And the whole narration / intel flow keeps the right cadence even when the mission layout and outcomes change run to run.
Why not pre-script everything?
It's just more fun to play.
Because the map is reacting to what's actually happening, you're not just following a memorized routine. You're making a plan, taking a shot, reading the results, adjusting, and watching the situation change. When the bearings and distances line up and the intel updates at the right time, it feels like you're doing real work, not just solving a pre-made puzzle.
It's also way more fun to build.
Honestly, I don't want to keep replaying the exact same version of a puzzle I already know the answer to. With this setup, I can make a scenario system, hit play, and get surprised too, which makes testing and iterating way more enjoyable (and at the end of the day, having fun making this game is really important to me, call my shelfish).
Now that the map / intel loop is finally behaving, I can shift focus to the stuff that'll really make the game feel alive:
Finishing the internal 3D turret environment, getting the space feeling right, readable, and nice to operate in.
Adding SFX, all the clunks, hisses, hydraulics, printer chatter, shell handling⦠basically the "this machine is real" layer.
Expanding the mission system so it can generate more dynamic little skirmishes between friendly and hostile units.
Like having an actual front line of allied + hostile units, where if you punch a hole in something, your allies will try to push through and take ground, and the whole mission shifts around that.
IRON NEST started with a pretty simple goal: Make big gun go booom. But that ended up turning into this nice little artillery fire command simulation where the player needs to build fire missions out of positions, bearings, distances, and reference points, and make sure the intel all agrees or risk war crimes.
Building Iron Nest: Heavy tourette's simulator is not flashy, but it's honest work.
β β β Operational Summary β β β
Dominik: To formally close this devlog... I wouldn't be myself if I didn't thank you once again. For months now, you've stood with us across every front: Instagram, YouTube, Discord... Your support fuels this operation, and it does not go unnoticed...
As promised: every Operator present on Discord at the moment of release will be recorded in the credits. Your name will be bound to the machine for eternity.
Operational roadmap is as follows:
- Playtests β on Discord
- Steam Next Fest (February) β Demo deployment
- Mid-2026 β full PC release
- Post-PC launch β ports to all major consoles (VR remains under active consideration)
- Next phase β a new project built on the foundations of IRON NEST, but this time multiplayer (co-op confirmed, PvP under evaluation)
Until next time, Operators.
A hive mind without its hive is nothing... just as we are nothing without you.
Nick & Dominik
PS: Merry Christmas from IRON NEST.
Stay warm. Hold the line.
ππ₯ππ£