Video games like The Witcher 3 are enormous, complicated pieces of machinery with thousands upon thousands of moving parts. Make one mistake and you can break everything — or, as one developer discovered, you can accidentally unlock every door in the game.
In October, I visited CD Projekt Red’s offices in Warsaw, Poland, for my book on the stories behind how games are made (which has a chapter on The Witcher 3). While interviewing the developers there, I heard a few great anecdotes that didn’t make it into the book. Here’s one of them.
Think of this as free DLC.
One day, during the development of The Witcher 3‘s second expansion, Blood and Wine, the designers at CD Projekt Red realised that something was horribly wrong: They could walk into any house in the game — even the ones that were meant to be part of the scenery. “We couldn’t figure out for a long time why it was happening,” said Miles Tost, a level designer on The Witcher 3. “It was terrible, because some buildings wouldn’t have any terrain underneath them and when you walked in, you’d basically just fall into nothingness. For optimization purposes you don’t put content into every single house, only the ones you can actually access.”
Tost and the rest of the design team scoured the game’s world, trying to figure out how this had happened. Doors in The Witcher 3 weren’t automatically attached to buildings — instead, the designers had to place each one manually — so going through them all was a tedious process. Some doors were meant to be always open, while others were meant to be locked with specific keys that you could find in the world. Others, of course, were never supposed to open at all.
Eventually, the developers of The Witcher 3 identified the problem. During a quest in Blood and Wine involving the siege of a castle called Dun Tynne, CD Projekt Red’s quest design team had decided that they didn’t want the player to be able to enter any of the buildings. This was meant to be a linear, streamlined mission — Geralt shouldn’t be getting distracted. The Witcher 3 was supposed to lock all of the doors for the duration of the quest, and then, once the quest was over, unlock those doors once again.
Problem was, as Miles Tost recalled, the game had no way of knowing which doors had been open before the quest and which ones had been locked. So it would just open everything. “This would result in all the doors in the game being unlocked,” Tost said. “And I remember the solution for this was quite bitter — the quest designer had to actually go through every single door in the game and add this tag. ‘This is a door that was closed before, and it should be closed again after.’”
It’s just one example of how a small mistake can be catastrophic for a game’s development, and one of many, many reasons that making games can be such a long, brutal process. “These things happen, and they’re tiny changes that you don’t anticipate, and they result in these huge huge problems,” said Tost. “You don’t really think about how something so small can actually fuck up everything.”
Comments
6 responses to “How A Designer Accidentally Opened Every Door In The Witcher 3”
I would’ve just made a global variable called DoorsCanOpen and set it to false instead “locking” each door and then unlocking them again.
So simple! I bet no-one at CD Projekt Red ever thought of doing that! Surely a team of professional game-developers would know to attempt a solution as elegant and economical as this one, who on earth could they have overlooked this?! Quick, someone get troutmonkey on the next flight to Poland and land him an executive-level dev job so his god-given talents for complex problem-solving can be utilised on The Witcher 4!
Even big companies can leave in stupid design choices in. As a developer there’s lots of times you’ll be working on some convoluted solution to a problem and another dev walks over and is like, “why don’t you just do it like (super simple way)” and you’re like “damn, yeah that’s a heaps better idea”. Other times though you can’t do it the simple way because the bad way is so deeply ingrained into the system (which didn’t need to account for this edge case) that it’d be more work to fix it properly than it’s worth.
In this case it seems that the system was written for designers to use, and designers not being programmers often use sub-optimal solutions as they don’t have access to the code and rely on the limited tools built for them.
Oh, and nice sarcasm. It’s funny because I’m actually a lead programmer, working in the industry for a company that’s currently sitting in the top grossing charts for mobile games.
Sure you are.
I was the lead dev on Shopkins World for the last year, and have worked on every single Shopkins game that has been released at our Company.
http://imgur.com/a/mjVxE
Dude, he has a good point. The problem, as described in the article, doesn’t quite make sense. I feel like something has been lost in translation along the way. One would think that there is no need to manually set data, the door should be able to keep track of its own state. You need to update the door code.
I think the answer might be that this is a workaround for a system where they didn’t want to change code? Like the thing was doable in the existing system, but with one big manual effort on the data?
Now I really want to know how many total doors there are in this game!