Triverse 0.7 improves on territory and introduces adaptive spawning.

Territory now appears around workers (units with external cores) and grows more naturally up to the borders of opposing territory. Territory also appears with a more distinctive border. As before, you can freely build, repair, or extract parts within your territory.

Territory border

Adaptive spawning adjusts the rate of spawning according to the size of the opposing force. I’ve had this change on my list for later, but I expedited it due to feedback and the need for stress testing. The result is that survival mode is slightly more reasonable and won’t flood the player with more waves than necessary (but you’ll still eventually be overwhelmed).

Stress Testing

To repro rare bugs, profile performance, and assess overall balance, it’s useful to have a stress test that runs a large-scale simulation quickly for many iterations. I previously created a scenario for this which randomly spawns opposing units, but it was feed forward, which means it attempts to predefine a good spawning rate and doesn’t account for the dynamic result of the units interacting. The result was that one side would eventually dominate, and any further spawning would be ineffective in restoring balance.

To improve this and allow longer, more stable simulations, I added a feedback mechanism that penalizes spawning based on the number of cores present and the number of opposing cores. This is also used for adaptive difficulty for the survival scenario, although I’d ideally like to replace that spawning entirely with a strategic AI that follows the same rules as the player.

The current stress test maintains around 150 units comprised of 1500 parts, split between two opposing forces. This runs at about 10-20 ticks/sec on a single thread. There are many opportunities for optimization, but first the game needs to be fun at a smaller scale.


I actually prototyped several new parts related to hidden information, a potential upgrade feature, a radar, and several unit/cell inspection options, but none of these features felt like they added enough value to justify their complexity, UI bloat, or burden on the player. I still think they have merit, but it will take more time to implement them in a way that doesn’t make the game worse.

It’s always a bit disappointing to scrap a prototype that originally seemed promising, but it’s also a relief that I won’t need to roll a boulder uphill to make a feature work when it doesn’t quite fit or opens a can of worms. Maybe I’ll revisit some of those prototypes, but for now they have lower priority than improving existing features and making the game more playable.

All Changes