Hello World

Hi everyone! I’ve been working on this project for a few weeks now, and I think it’s finally in a stable enough place to share with the world. So, here goes!

About me

Before we start, a little about me so you understand where I’m coming from. I’ve always been a bit of a meta slave in the games I play, and I find a lot of joy in organizing and optimizing things in life. People often say that gamers will optimize the fun out of a game, but for me, optimizing is often the fun of a game. With that in mind, I thought it would be a fun project to build a Wuthering Waves combat simulator—to better understand how characters perform at different levels of investment and skill expression.

How the combat simulator works

I.R.I.S. simulates Wuthering Waves combat. If you’ve played Genshin Impact, a fairly similar tool would be gcsim. At a high level, you give I.R.I.S. a team and a sequence of inputs—buttons pressed and released at specific times—and it works out the damage events that would result.

To do that, it models how inputs resolve to skills in game and how your characters’ state changes as those skills play out: position, Resonance Energy, Concerto, Forte resources, buffs, and so on. Skills trigger montages (think character animations) and spawn bullets (the game’s term for things like slashes and projectiles). The simulator follows those events, tracks the effects they trigger, and calculates the damage of each hit.

One interesting aspect of I.R.I.S. is how little character or weapon configuration it needs. Much of Wuthering Waves’ combat logic is written in C#, which makes it possible to inspect how the client’s combat loop works. I.R.I.S. follows that logic and uses data extracted from the Unreal Engine assets bundled with the game, along with some character configuration for information that would normally come from the server. That configuration can be surprisingly small: around 50 lines of JSON for a character.

What you can do with I.R.I.S.

• Calculate damage from teams and their skills. Configure a team, pick the skills it casts one after another, and I.R.I.S. works out the inputs that cast them and the damage instances that result.
• Compare builds. Try different weapons, echoes, stats, or Resonance Chains and see how they affect the same encounter. Look at the overall damage change, or dig into individual hits to understand where it came from.
• Compare character investment fairly. I.R.I.S. can calculate a version of the encounter with Standardized: the standard Resonance Chain¹ and an optimized echo substat budget², including the Energy Regen needed to perform the rotation. This gives you a more useful starting point for comparing teams than builds with wildly different levels of investment.
• Browse encounters. Explore saved encounters and open their analysis to see how the teams and their rotations work. For now, you can browse encounters I’ve recreated from Prydwen and WuwaLAB.

Build your first encounter, or browse encounters for a starting point.

Limits to keep in mind

I.R.I.S. is still in development. I want the results to be useful, but there are a few things to keep in mind when comparing them with what happens in game.

The battlefield is simplified. Combat uses one stationary target and flat ground. The simulator tracks character motion and airborne state, but target distance, collisions, and many spatial interactions are simplified. It does not recreate terrain, enemy movement, groups of enemies, or the practical difficulty of landing every hit. Some projectile travel times and positional behavior rely on documented assumptions.

Client coverage is a work in progress. Some mechanics remain unsupported or incomplete. Random outcomes, such as Youhu’s Antique draws, are not fully modeled. Projectile travel and landing times are approximated where needed, and the simulator does not reproduce attacks missing because of positioning or delays between the client and server. That last point matters because ping can affect how an encounter plays out, including whether a swap triggers an Intro and Outro.³

Perfect inputs are possible. The simulator accepts inputs at precise frames, including timings that may be impractical to reproduce consistently in game. I don’t manually verify every saved encounter against a video of someone executing it, so a simulated result should not be taken as proof that an encounter’s inputs can be played exactly as written.

Damage is an expectation. The simulator averages critical damage to make comparisons easier. A single attempt in game can do more or less damage depending on which hits crit.

Next steps

Encounters are now built from skills. Theorycrafters usually think in terms of skills and combos, while the simulator ultimately needs the inputs that resolve to them, so encounter creation now offers the skills each character can cast next and when, and works out the button presses for you.

Next, I want to support video uploads, so you can create an encounter against your own Endstate Matrix recording and compare it with the simulation hit by hit, like the videos on the encounters I’ve recreated from WuwaLAB.

I also want to add more character analysis: how characters scale with pull investment, echo substats, and skill expression.

Prior work

This project builds on a lot of work the Wuthering Waves community has already done. Prydwen and WuwaLAB provide guides and rotations that have been useful starting points for encounters in I.R.I.S. I’d also like to acknowledge ChemX32’s spreadsheet, which informed how I think about comparing character investment.

Footnotes

1. Limited 5-star characters use S0, standard 5-star characters use S2, and 4-star characters and Rovers use S6. Weapons use refinement 1 at level 90, selected from the character’s recommendations. ↩

2. Each character’s echo set has 17 useful substats at average quality (for example Crit. DMG 15.0%, ATK 7.9%), chosen to optimize the team’s damage while meeting its Energy Regen requirements. This is close to, but not identical to, the investment criteria in ChemX32’s spreadsheet. ↩

3. Some abilities grant Concerto when cast, but the server handles that resource gain. With latency, it can be possible to swap before the gain reaches the client. If that gain would have filled the Concerto bar, swapping before it arrives may produce a regular swap rather than an Intro/Outro swap. ↩