I can understand where feeling comes from, and I think a lot of it has to do with the relative ages of people in leadership positions. Depending on the specific game we’re talking about, it’s a type of game that some of us have already iterated on 2, 3, or 4 times. And when it comes to things like dialogue structure and quest design, there’s even more structural commonality between our projects, regardless of the underlying genre or camera perspective.
I’ve been a game developer for 20 years now. Regardless of my intelligence or creativity compared to a junior designer, I have seen enough quests move from idea to document to alpha implementation to beta to launch to have a pretty good sense about how certain approaches are going to go. There are some quest concepts or details that are - and I stress that I do not mean this pejoratively - naïve. The quest designer does not, and could not, understand the technical implications of what they are trying to do.
When it comes to quest design (especially) a little bit of knowledge can be a very dangerous thing, because as with learning any discipline, it’s hard to comprehend how much you don’t know once you get the basics down.
One of my favorite bicycle frame builders is Richard Sachs. He’s been essentially building the same type of brazed steel frames for over 45 years. I have one of his 1978 frames and it looks very similar to the frames he builds now. He’s one of the higher-profile living frame builders and he’s vocal about his opinions. In an interview, he recounted interacting with a talented young frame builder who had been working for a few years, built several dozen frames, and concluded he had pretty much learned everything there was to it. Sachs’ reaction was, “You don’t even know how to make the right kind of mistakes,”
This is one thing for a craft like frame building, where it’s often (today) one person working alone as a hobbyist. It’s another thing in a big team environment like game development where 30-100 people are trying to work together on a big, interconnected project. More experienced leads tend to be more conservative and critical about design, not necessarily because of some ideological stance, but because we have seen things go very wrong and we want to prevent the kind of collateral damage we have seen play out in the past.
Players remember quests like Beyond the Beef, and rightly so, because it’s a very fun quest with a lot of interesting ways to approach and resolve it. What players don’t remember, because they weren’t there, is how long Beyond the Beef took to complete, and the impact it had on the designers’ schedule and the project as a whole. And players don’t remember the cut content, some of it the product of months of a designer’s time, because it was hopelessly broken or inherently not fun to play through. When I write this, it’s not to put blame at on the quest designers. It’s my responsibility to review their work and to approve or disapprove it.
On a game like F:NV, which was almost half-my-career-ago, I very often said, “I don’t think you should do that,” or “I wouldn’t do that,” with an explanation of why and some suggestions for alternative approaches. These days, I am more likely to say, “Don’t do that,” because I have seen 10 out of 12 soft warnings go ignored and yield some really tremendous headaches and heartaches.
In contrast, when I see young teams (and by this I mean inexperienced developers with inexperienced leads) working, I am often pleasantly reminded of what naïveté can produce - as long as you have the time and money to burn through your mistakes.
I talk with and visit a lot of teams at other companies, and there are some high profile developers I’ve visited where their design process is less of a process and more of an ad hoc “fling **** at the wall” experiment that goes on for 3-5 years. Sometimes the cost of this is just time, which is money. Sometimes the cost is polish. Sometimes the cost is burning out half a generation of young developers. Sometimes it’s all of these things.
If you’ve never been at the helm when your project goes so over-budget that the company is in serious peril, this might not seem like a big deal. If you’ve never been in charge when the game comes out and gets slammed for being sloppy, buggy, and messy - when a reviewer straight-up says the team that worked massive overtime to get the game out “phoned it in” - this might not seem like a big deal. And if you haven’t watched the people on your team, people for whom you were responsible, get burned-out or laid off because of crunch, or stress, or a project cancelation, it also might not seem like a big deal.
But if you have been in that position, it’s hard to see the consequences of inaction and not try to mitigate them, consciously or unconsciously, by pushing for more tried-and-true approaches to design. I’m not saying it’s an objectively good thing, but it is, I think, a natural reaction for leaders who see things go wrong over and over.
Personally, I do hope we take more chances at Obsidian in the future, whether it’s on big projects or small ones. Some of this will involve putting less experienced people in leadership roles. Limiting the project scope itself also helps. Small projects and DLCs are easier to experiment with in good conscience because the impact on the company will probably be low if it fails. But when it comes to our big projects, our more experienced leads will have to be more open-minded about letting certain things wander a little bit. There are additional layers of experience and perspective that I will (hopefully) gain if I remain in the industry another 5, 10, 15 years. Hopefully that will allow me and other people working in leadership positions at the company to let people take more risks in good conscience.
I want to help people make the right kinds of mistakes.