Cyberpunk 2077's Chimera Tank Took Two Years and Four Rebuilds

It took two years to get one tank fight right.
Staff at CD Projekt Red have described the struggle to build the Chimera, a boss battle in Cyberpunk 2077: Phantom Liberty, the paid expansion to its science-fiction role-playing game.
The account came in an episode of AnsweRED, the studio's official podcast, which takes listeners inside production. This instalment focused on production challenges, the awkward problems that force rethinks mid-project. Eurogamer reported the conversation in an article published 25 September 2026.
Art director Paweł Mielniczuk said the team needed two years of iteration to make the Chimera fight work. Iteration, in game development, means building a rough version, testing it in play, then refining or replacing it. It is slow work. For this fight, it stretched across months of trial and revision.
Four versions. Two years.
Mielniczuk said the Chimera tank itself was done four times. Each version changed its equipment and weapons. The goal was an enemy that looked threatening, moved clearly in combat and gave players readable cues on what to do next.
Creative director Igor Sarzyński described the Chimera as one of the most expensive art assets the studio has ever made. He gave no budget figure. In production terms, the cost he pointed to was staff time: modelling, texturing, animation and the rework each new pass demanded.
What makes this stand out is the weight placed on a single encounter. A boss fight, a locked battle against one powerful foe, has to teach, test and entertain in a few minutes. When it fails, players feel it at once. When it works, few notice the labour behind it.
That labour is shared. An art director guides how a game looks. A creative director guides how it plays and how its story and systems fit together. On the Chimera, both sides had to align. A striking design meant little if the fight felt unfair or confusing. A clever combat idea meant little if players could not read it in the heat of action.
The podcast did not present the rework as failure. Mielniczuk framed it as process. Build, test, change. Build again.


