Well I wish you luck in your future Paul. Also I like your little LOTR story about game design. Kind of a downer though. :P

Well Said!

wow -- that's a bombshell!! sorry to hear that paul. I was excited to see what would come out of Offset, and all that crazy larabee processing power.

so that was the last straw for you in the game industry, eh? give academia a try. it's all the fun without all the headaches of industry (...and without the pay, sadly).

as for game design, I'll take your word for it, and keep my distance. I prefer to leave design to the public (http://theRestaurantGame.net).

Jeff

Wow, Paul, well said! I hope you're "livin' it up" in Texas! :)

Good luck in all of your future endeavors!

Evil, dirty, nasty Hobittses. We hates them!

Oh, Jeff, I'm sure you're reading too much into it.

As the Disclaimer at the top notes, I'm not referring to any particular projects ... Just rambling because I happen to be in the mood for no particular reason :)

:'(

Design definitely suffers from the issue that so few of the skills that go into it are well-defined and tangible. It's not like engineering, where you can either get the feature done (in time and under budget) or you can't. Being a designer is about convincing people to take your stupid ideas (or your selection of stupid ideas) over their stupid ideas. It's about having authority but never having to pull rank. It sucks!

One of the best designers I worked with had an incredible ability: like all designers, he was barraged with ideas, many of them stupid. On the occasions on which I would offer him my stupid ideas, he would sit down, nod thoughtfully, and listen to my every word, and when I was done, he'd sigh, gaze deep into my eyes and say "I've heard you and I understand you. But I don't agree." And I would leave feeling great.

I bet Barack Obama would be a great video game designer.

I can't agree more with the prior poster, Naimad. As a designer (not in the game industry - I'm a UX/UI designer for software), I am a strong believer in being the guy that facilitates design within the team. Sure, it takes time for me to listen to all ideas, brainstorm with people, etc... but it's my job to be the lens through which information is focused - not the sole source of design and complete arbiter of good design. Like you point out, great ideas can come from anywhere, and a good designer is always a good listener, dropping pride when needed and adopting any idea that makes his/her product stronger. And, if the designer does their job well, the team still feels that sense of ownership and shared responsibility. Plus, the team may learn a thing or two about design, along the way.

Another thing, I believe, is that there's multiple aspects of design. You could maybe break them up into the strategic aspects vs the tactical aspects. By this, I mean the differences between having large scale vision for a product (features, experience goals - what are you really trying to creat?), versus the specific implementation details. The vision part is vital - the tactical details, in my experience, can be massaged and worked out over time - especially if you actually conduct user testing.

But I think I agree with the essence of this post - design by a committee which has equal voting power... it's doomed to fail. But design that is managed by a skilled designer who can filter feedback and translate it into a cohesive vision - that's really ideal. The last thing I'd ever want is a team that feels no ownership for the product they are working on, though, and having a bad design process that blocks external feedback, is one of the quickest routes to that problem, imo.

Alan:

Thank you. I agree with you completely. The challenge is to make sure the process accepts external feedback, and ensures the team has ownership over the design, while also making sure the Ring makes continual progress toward Mordor and the team stays more focused on delivering it to its owner than using it for themselves.

Damian:

I think it's not so much that ideas are "stupid," since very few of them really are. The problem is that ideas have to live in the context of the broader game design and the team's production efforts, and helping team members understand all of those factors and take them into account in the design process is a difficult art form that I haven't yet mastered.

I've had people say to me, "Why did you turn down that idea? That was actually a really good idea!"

In and of itself, yes, it was a good idea.

In the context of the game design, though, it didn't fit. Adding more Jenga bricks in the wrong place can collapse the whole structure. Ideas created in a vacuum usually can't survive outside the vacuum.

Also, I just got an e-mail from a well-known game industry luminary ... I'm not going to post his name since he didn't give me permission to do so, but I was really humbled to receive it.

---

What a brilliant post. I agree with 100% of it and it's one of those things that you just 'get' after years of being a designer. People not seeing the forest for the trees, or not getting the larger vision of the game no matter how many times you try to clarify it. People suggesting mutually exclusive ideas and not seeing the bigger picture.

Not realizing that all that matters is the end product and how consumers will see it. Design by committee doesn't work. Someone, or a very small group of people, have to be responsible for the player experience and make the hard calls that shape the game.

Best of luck in whatever you do next. Your post, while depressing, is actually pretty encouraging in it's message and focus.

I had to come back, cause I've been thinking about this more:

One thing I've found useful in establishing a good perspective on the forest, rather than the trees, is to come up with experience goals early on and, after thinking of design solutions to meet those goals, establishing design principles that can meet those goals for the various features in a product.

For example, on one project I worked on, we wanted to ensure absolute success on the first use of the product, followed by an efficient workflow, so after a few experimental designs, we came up with a principle of "Only make users make decisions when they become absolutely necessary to make." This was a principle that, yes, sometimes we broke, but for the most part we agreed on it as a team and followed it. In the end, we had a consistent experience and a compass for directing the addition of future features.

Another one we have for a recent project is actually in a similar vein, but almost the exact opposite: "Present users with choices when the effects of those choice can be most clearly visualized." This, of course, generates an entirely different workflow and experience, but it accommodates different experience goals for the project.

I know that a lot of things in the world of game design is apples and oranges to what I do, but I wonder how much crossover there may be. For example, the way in which we do user testing is nearly identical. I wonder, though, if the team had a clear view of the forest and relatively clear guidelines for how the forest is constructed, maybe that would cut down on misshapen trees being added along the way? It may also help keep the teams focus on that end user, the player, if your context for design is always centered around the core experience that you defined for the player.

Just some more thoughts... I don't know if it applies or not, but I love sharing, since I'm always learning. :)