⚡ Hostile Mars Devlog: Reactor Power, Trap Strategy, and Smarter Bots

December and January

December and January were big production months for Hostile Mars, and a lot of the work was aimed at making moment-to-moment gameplay decisions feel sharper and more impactful. We also have some concept work from the team to show. This devlog is a mix of gameplay-facing improvements and the deeper systems upgrades that let us keep accelerating development.

Power is built, not granted

Power generation in Hostile Mars is shifting toward something you actually construct and expand.

• Reactors generate your power. If you want more available power, you build more reactors (and keep them connected to your grid).

• Reactor capacity is tied to progression. As you push deeper into wave progression, you unlock additional reactor slots in that region. Early on, you are forced to make real choices with limited power.

• It is not just “build X reactors and you are done.” Reactors can be upgraded, so progression is not a simple linear march toward a higher reactor count. You can invest into fewer reactors and improve them, or expand toward the cap when you unlock more slots.

• Result: power becomes a planning problem, not a background stat. Do you use your resources to upgrade reactor capacity and build more defenses, or upgrade what you already have and squeeze more out of your current footprint?

Trap placement consequences

A big chunk of December and January was stress-testing one core promise: defenses should not be “place anywhere, win anyway.”

We built a test lineup of around 10 different defenses, chosen to represent the full spread of trap behaviors, then started designing around how they overlap and how they fail.

• Different traps control space in different ways. Some are directional, some hit an area, some are single-target. Some are instant burst, some are multi-target, and some apply damage over time like acid. The point is that every trap has a shape and a job, and the layout needs to respect that.

• Spamming one trap should never be the answer. We put serious thought into making sure the game rewards mixing defense types, because a “just build 30 of the best one” strategy is basically game design malpractice.

• Enemy variety changes what “good” means. The same defensive layout can perform totally differently depending on what the region sends at you. A setup that melts one enemy type might get embarrassed by another, which forces you to adapt instead of solving the game once.

The goal is simple: your choices matter. What you build, where you place it, and what you pair it with should be the difference between holding the line and watching your base get remodeled by hostile machinery.

(Concept work for two traps we're working on)

Pathing with tagged surfaces

Bots now have preferences when pathing, they will prioritize going on panels over bare ground. They even try to stay on the center of panels, almost following the grid, rather than cutting it close to the edges. This makes it easier to layout traps as bots more predictably follow panels, especially around corners. It also allows us to raise the terrain to be nearly aligned with the ground panels such that bots can drive off an on panels from anywhere, and still have the bots follow the “road” without needing walls to prevent shortcuts.

Enemy code improvements

Long story short, we’ve made the enemy code a lot more workable! It used to be like a gigantic clock where each gear meshes in a different building, with invisible ties to other parts. Now it’s laid out in plain view in one central place, which makes it much easier for us to keep refining bot behaviors.

For a technical explanation: the bots are entirely done in ECS. We used to split each behavior across a few components and systems, with logic spread between queries and jobs across several files. On top of that, we often needed extra “glue” code to link behaviors together. The new version moves jobs into regular functions, components into regular structs, and removes the queries and systems. We call these structs “building blocks.”

Each building block is split into a shared parameter struct and a per-instance struct for better memory efficiency. Now we have a single system per bot, with one component holding all per-instance data and a blob asset holding all shared data through composition of those building blocks. Instead of many queries deciding when to execute jobs, we run one job and use regular code to call the various functions. The end result is significantly less code, no glue needed, no caching components or allocations, since temporary data between jobs now stays inside a single job, while still being more flexible than the previous system.

More Art

We’re not totally sure what these are yet, but the art team swears they belong in the game.

Steam post image

Steam post image

Steam post image

That’s it for our December and January progress.

A lot of what we pushed forward this cycle is about making the game reward good decisions: power is something you expand and upgrade, trap choices have real tradeoffs, and enemy behavior is becoming far more consistent and extensible as we keep dialing in combat. We’re going to keep turning these foundation changes into more and more “you can feel it immediately” gameplay moments as we move through production.

Thanks for sticking with us and for caring about the details. More updates soon.

-HM Team