When you’re building a systems-driven action game, abilities tend to grow fast. Very fast.

In Temtem: Swarm, what started as a relatively straightforward ability framework gradually expanded into a large ecosystem of interacting mechanics. Today, the game features more than 250 techniques across players and enemies, all operating within a layered architecture of perks, modifiers, and stats.

Designing that many abilities isn’t just a content challenge. It quickly becomes a technical and systemic problem: how do you maintain clarity, scalability, and balance while allowing for meaningful build diversity?

To solve this, we built a modular perk and stat framework that allows designers to expand the system without constantly reinventing the underlying logic.

Three Layers of Player Perks

In Temtem: Swarm, player progression is built around three main types of perks that shape a run in different ways: Skills, Gears, and Techniques. Skills are obtained through the Skill Tree before starting a match. These upgrades define the structural direction of a build, giving players control over core stats and progression paths before the action begins.

Gears function as passive stat upgrades that enhance the player’s Temtem during gameplay. They act as complementary modifiers that reinforce a specific strategy or stat focus.

Finally, Techniques are the actual abilities that Temtem execute in combat. They define the moment-to-moment gameplay and are where most of the mechanical expression of the system happens. All three of these layers plug directly into the same custom stat system, which allows them to interact in a consistent and predictable way.

Unified Stat Modifier System

At the core of Temtem: Swarm’s design is a stat architecture that treats every upgrade as a modifier applied to a base value.

Take the stat MaxHealth as an example. If a Temtem like Platypet has a base value of 200 HP, upgrading the Max Health Skill will apply percentage modifiers directly to that base value.

• Level 1 of the skill increases MaxHealth by 5%, bringing Platypet to 210 HP.
• Level 2 increases it by 10%, resulting in 220 HP.

These modifiers are fully stackable with other perks in the system.

If the player also equips and maximizes the gear Lunch Box, which provides an additional 45% MaxHealth bonus, the calculation becomes:

200 + 10% + 45% = 310 HP

Because all bonuses run through the same stat modifier layer, stacking effects remain predictable and easy to balance.

The system also supports temporary modifiers, which allow enemy abilities to interact with the same stat structure. For example, if a Temtem poisons the player, the status effect can apply something like a –20% modifier to a stat for the duration of the debuff.

The key advantage here is that everything speaks the same language: permanent upgrades, gear bonuses, and status effects all operate through the same modifier pipeline.

Techniques as Data-Driven Abilities

The same stat architecture also powers the way techniques themselves scale.

When implementing a new ability, designers don’t need to write bespoke logic for every upgrade level. Instead, they simply fill out a technique template and define how specific stats evolve as the ability levels up. For example, the technique DC Beam includes a stat called Projectiles.

At level 1, the technique fires a single projectile. At its maximum level, that value increases to three projectiles.

Because this stat is also part of the global stat system, it can combine with other projectile bonuses the player has accumulated through skills or gear. The result is a flexible design space where abilities can scale in interesting ways without requiring additional custom code.

This data-driven approach allowed us to iterate quickly and experiment with different upgrade curves without rewriting core gameplay logic.

Scripting over 250 techniques

Once the number of abilities grows beyond a certain point, implementation becomes less about the individual ability and more about the structure that supports them.

With over 250 techniques across both players and enemies, we needed a scripting hierarchy that allowed us to:

• Add new techniques quickly
• Maintain shared functionality in one place
• Perform balance changes without touching dozens of scripts

To achieve this, we built a class hierarchy for techniques.

At the top sits the base class Technique, which contains the shared functionality common to every ability in the game. This includes core behaviors like cooldown handling, stat interaction, and activation logic.

From there, the hierarchy branches into two specialized classes: PlayerTechnique & EnemyTechnique. This separation allows us to manage differences between player abilities and enemy attacks without cluttering the base logic.

Finally, player techniques are divided into two categories:

• Active Techniques: These require direct player input; the player presses a key to trigger the ability.
• Passive Techniques: these trigger automatically once their cooldown finishes, allowing for gameplay patterns that feel reactive or systemic rather than purely input-driven.
• This layered structure keeps the codebase organized while allowing the system to expand without becoming fragile.

Designing for growth

One of the biggest lessons from developing Temtem: Swarm is that ability systems rarely stay small.

A feature that begins with a handful of mechanics can quickly evolve into hundreds of abilities interacting across multiple layers of progression. Without the right architecture, iteration slows down and balancing becomes painful.

By building a modular stat modifier system, a data-driven ability template, and a clear scripting hierarchy, we were able to keep the system scalable even as the number of techniques grew.

And perhaps more importantly, it gave designers the freedom to experiment. Because when your underlying systems are stable, adding the 251st technique becomes just as straightforward as adding the first.

GGTech Studios, Co-Developer of TemTem: Swarm