|
Have you ever had a boss who couldn't make up their mind on the design? They make edicts about what will not be in the game, but the most they can contribute to what is in the game is a vague reference to other games. Even with the things they're sure about, they'll back away from those decisions and toss out weeks of work. It's that utter lack of conviction that I want to discuss here.
How on earth does someone like this get in charge of design? Sometimes they have worked so hard and earned an
opportunity to lead, but they get in over their head. They lack the vision, imagination and the
confidence that a lead designer needs to succeed. Sometimes they're not designers. They're managers, art directors, producers or studio heads who design by making edicts without a deep understanding of what their decision means. Regardless, I think anyone who has worked for a decade or more in this industry has encountered this situation.
Example #1: The HUDless Design Movement
About five or six years ago, there was a widespread drive to remove the HUD from our games. This coincided with the evolution of 3D graphics capabilities of the 360 and PS3. Realism was the big selling point for the game, and a HUD made something too "gamey". Many games tried to remove the HUD entirely or compromised with toggling the HUD on as needed.
This is what I would call a design edict that came from art and championed by producers. Unfortunately, it threw out the baby with the bathwater. Gone was the very important means in which to communicate with a player. And what did it get us? Well, for all of us that did focus testing on these HUDless schemes, it got us a lot of confused and frustrated players who didn't have an objective marker to tell them where to go, a health bar to warn them they were dying, or any idea what weapon they had holstered.
The edict gave way under pressure from focus tests. The HUDs came back, but not before some serious frustration on wasted efforts to work around the edict and some damage to the design. Imagine how linear levels get when you're not allowed to use objective markers. Imagine players not finding or using weapons because they're not called out on the HUD prompting the player to pick them up.
In short, someone high up in the design chain said "No" to HUD with vague hopes that the environment art, level layout and character animation and FX would make up for the loss of an important means of communication. Eventually, they were proven wrong.
Innovation often occurs by defying tradition. However, you can't just
refuse to do something without replacing it with something equally
effective.
Example #2: The "No" Identity
I've literally had a boss say to me. "Sorry, you can't do that. It's not what Halo would do." In fact, "What would Halo do?" was his motto. In this case, he's not defying tradition as in the previous example, he's just not thinking beyond his competition.
It's all well and good to model your design after some successful game, but it's not a recipe for your own success. Every game in development will ALSO have the advantage of learning from Halo's success. Your game will never stand out if it limits itself to only being as good as a game published a year or two ago. Your game needs a unique identity to stand a chance of being successful.
In my case, my boss eventually figured out that our game had no identity but far too late in production to make us successful.
Example #3: Designer Apathy to Ammo & Health Pick-Ups
Pick-ups or "gimmes" have long been a way to reward a player. They drop from enemies or can be found out in the world. It's a traditional part of gaming since the 16-bit days. The problem is a thousand games have relied on pick-ups to be the bulk of their gameplay. Some designers have abandoned tradition by doing away with the need to pick-up ammo or health.
That's all fine as long as they replace it with something more compelling. Case in point: Gears of War. Gone is the health pick-up, but in it's place are superior cover and coop systems.
But what if your lead or producer or director just says, "Hey, no pick-ups! We'll just regenerate health over time and you're equipped with what you start out with." Now that game mechanic is gone and there's no reason to explore the map except for some stupid achievement pick-up like war-journal pages or skulls. That would be like Gears of War without the cover system and coop system for restoring health. It would be empty and boring - the end product of a design leadership that only knows how to say "No."
Learning to say "Yes" and "No"
Strong design leads have convinction. They say "Yes" to the ideas they think are good and "No" to ideas that detract from the game. They back their decisions by being analytical and prepared to present and defend better ideas.
Good design leads add a positive force to the decision-making process by suggesting ideas of their own or promoting others' ideas. They don't eliminate ideas simply because they didn't exist in other games. They don't throw out a traditional solution to a problem without solving it another way. They offer concrete examples of what they want and don't want, not some vague, half-thought out reference to other games.
Good design leads don't automatically say "Yes" to every idea either. They show backbone not just to their team but to their boss. Heaven knows bosses don't always know the impact of their suggestions, but a good lead will explain the impact in a way that helps a boss or co-worker or subordinate rethink their suggestion. In theory the design lead was hired to make decisions, not just do what they're told. They shouldn't be afraid to say "No".
Good design leads are capable of prioritizing and pushing for the best and most
important ideas and dropping less important ones when negotiating with art
and tech directors for implemented features.
Whether you are a lead designer, manage one, or just aspire to be one, you should understand the importance of being able to say both "Yes" and "No" in design decisions. It's a balance that you have get right if the game will be successful.
|
I think that if you (and I mean designers) can't figure out an elegant way to convey all the information a player needs to the play your game, that is both easy to understand and instantly recognizable, you'll need to have some sort of HUD. You can no longer expect players to read the manual to figure this information out; either it's as easy to see as a HUD or it's detrimental to the experience. That's a bit of a rant, I apologize.
On another point, there is a lot of talk about game design being particularly cookie-cutter in the big budget realm. The mutterings are that companies are wary about funding multimillion dollar games that are too big of risks when it comes to drastic innovation. I do not have experience with those kinds of budgets, so this is really spitballing here, but do you happen to think that's why some designers are relying too much on riding in Halo's wake (or Call of Duty's, Final Fantasy's, etc.)? I'm not saying it's good design, but there might be extenuating circumstances.
1) "I'll think about it," the trick there is *actually* pondering the idea and how it would affect different parts of the game and then come back with what you worked out. Too frequently "I'll think about it," is just another way of saying "no," which is a shame. I mean, thinking about the game mechanics is 95% of a Designer's job.
2) "That works, but..." is what I use when an idea is floated that has an immediate issue that pops up. These are useful in meetings, and creates a back and forth of finding a solution or another method for the same results. For example, the HUDless concept would get eaten by this reply, since a usuable solution could probably gut the Core gameplay depending on the game.
Yeah, and that's a shame. It's a really interesting issue that I'd love to see a talk or discussion on, i.e. "Finding a Equilibrium Between 'Established' and "Innovative' in Big Budget Titles".
"Yes." Translation: "You can do whatever you want, but you'll have to figure it out yourself; I'm clearly too busy/important to help you. Oh, and don't get it wrong, or else."
"No." Translation: "I am a human roadblock. You will follow my required process. I will not tell you what that process is. If you ask, I will assume the attitude that it's something you should (somehow) already know."
"Yes, but." Translation: "Progress is dangerous. Do you *realize* just how many things might go wrong? It's my job to object continuously to every little thing you will ever propose, and to write emails to your manager disclaiming all responsibility if anything bad ever happens."
"No, but." Translation: "No, that won't work, but here's the information you need to accomplish your goal."
I love the "no, but" people.
If only there were more of them.
As a producer I attribute blind allegiance to game trends and the use of excuses like "because it's cool" or "because *blank* game did it" to be the by-product of a lazy attitude in an industry more than willing to promote lazy people to positions of authority. Show me more critical thinkers per capita in the games biz, and I'll show you an industry that might actually be trying to finally grow up, one person at a time.
And yes, you read right. I'm not asking wich skills, creativity or talent I need, I'm asking about time, isn't that the read must in this business?
I found it funny that you just mentionned Halo, because all game developers recognize the success of that franchise, a lot of developers tried to copy some Halo elements in their own games, but nobody seem to have understood what made Halo so great and even Modern Warfare 2 proves it all:
- Matchmaking System (Social & Serious)
- Ranking System (Level per Gametype by Win/Loses + Grade = Overall XP)
- Lobby and Invite System
It wasn't the auto-aim, the energy shield, the map control, the gunplay, etc. The game is just accessible and look stable (even if it's not)....
Understanding everyone's role and balancing their needs to filter out design possibilities before I propose them was very important. Nobody is 100% disciplined about what tasks they'll take on, and beating schedule pressure before it caused a firefighting situation was always the #1 priority in work-for-hire, so I tried hard to make everything a slam dunk. The design has so much influence in this regard, and the kinds of projects I was seeing were so tightly constrained for the features demanded(3D games in eight months? six months? five months?), it really came down to the wire to answer "how can we pull this experience off cheaply?" Quality products were perpetually a distant dream.
The biggest problem I had was that the vast majority of solutions for delivering a cheap but satisfying experience were tradeoffs that sacrificed surface fidelity. The development team would always buy into the sweeping limitations required, but publishers found it hard to swallow - they wanted a pretty back-of-the-box that could boast expensive gimmick features.
Being available to make detailed decisions and keeping everyone on the same page was my main role as designer, more than any specific tasks I did. While I'm probably guilty of being too hands-on, in my view, if I delegate carelessly, the game is only going to become more and more inconsistent. But if I'm there for the small things, it helps everyone see and respond to my actual vision for the design(which can't be fully conveyed via general overviews, documentation, or even prototypes) Then I can take their input, fit in back into the vision, and gradually get something together that everyone is confident about.
I rarely gave a straight yes/no answer to anything, because I would think out loud about the problem first: "If we do this, then we have to do x....and the player is going to be affected in y way....reviewers will probably say z....but if we do things this other way...." and my hope was always to get everyone involved in the design by delivering a best guess at the consequences, and to leave my opinion for last.
The upper ranks were full of the "edict" problem - making downright ill-informed decisions and going over the natural decision-making process. That isn't just a communications problem, but a role/expectations problem. Showboating, vanity features and heavy-handed ultimatums are extremely expensive and on all too many occasions, I was left with nothing to design because the design was imposed for me. Lesson for those who want to manage: Understand the natural ordering and inclinations of the people you're managing, and channel it in a healthy way. Don't try to defeat it.
"I've literally had a boss say to me. 'Sorry, you can't do that. It's not what Halo would do.' In fact, 'What would Halo do?' was his motto. In this case, he's not defying tradition as in the previous example, he's just not thinking beyond his competition."
If you were working for Halo's competition, then you probably were on a big budget team. Companies in these types of situations simply can't afford to take the types of risks that involve deviating from proven formulas. That is just a financial reality, and it is why most of the truly innovative games are coming from independent studios.
Actually, I see that you have already addressed it in a follow-up comment.
"There's safety in doing what's been done. There's less risk for a designer..."
My only beef with this article isn't in the presentation, it's in the application. How a lead's input and feedback is perceived by the team is subjective to the emotions of teammates.
For instance, a lead can be the kind of person who says both yes and no, but if they say "no" to the same person (because, for example, that person frequently brings ideas to the table which warrant a "no"), they will be perceived as a naysayer by that person or friends of that person who don't have an objective viewpoint on the situation.
I could see many using this as an excuse to place blame or call BS on a lead that may not deserve it.
Your lead is usually going to be your lead because they've managed to consistently display understanding for the big picture.
What might be more practical is an article for leads on how to say "No" more tactfully in a way that educates the team and puts everyone on the same page.
To be fair, there are bad leads and naysayers out there, and they need to be called out and educated. I just wouldn't want anyone to take an alarmist standpoint on the prospect of a leader who frequently says "No", because as this article states, they may be justified.
The thing is: if you work with highly creative people you will get a lot of ideas, and these ideas will >fight to death<. Unfortunately every person have a different take on what direction the game should go, that is what creative people do. I, as game designer, happen to _need_ to say no a big part of the time, because it is just not what I want for the game. I need to follow my own ideas, not everyone else's, and I need people to understand that and work with me.
When Geoff Keighley asked the Modern Warfare 2 developers if the game came out the way it was envisioned to be, they laughed out loud. Not being sure about something: we, by definition, can't be! Not if you are creating something new! We are touching new ground, we are not sure where we are going...
The best thing the team does is to make suggestions, but in the end, the team must try to follow the game designer's direction with the best of their effort.
I do believe that there is a lot we can allow the team to do, and we should! But if you want to be able to direct your game effort to a concise direction, being it Halo-like or PutYourAmazingNewGameConceptHere, your team must be fully on board WITH you. I mean, if you exercise any role in the team and you constantly _fight_ your game design directions for whatever reason, well... you are any leader's nightmare. You need to stop it, just help him achieve whatever he is striving to achieve!
For instance, imagine someone working on "Beetle Juice" with Tim Burton, but he is thinking "Man, this movie is becoming far too creepy for the audience". Everytime this guy makes something for the movie he tries to "fix it", maybe make it "palatable". Tim Burton would say to this guy that he is going another direction, these ideas could be interesting if placed in other movies, but not in his!
Also, the strange thing this article seems to say is that game designers shouldn't design: instead, they should pick ideas from the team whenever they came up, catalog them as "great" or "bad" and create, in real time, a "giant robot warrior"... Your team member doesn't believe hudless will work? Just change it to his liking!
It also demands that game designers should most of the time understand exactly what they want, which is also almost impossible from both software development perspective and from the game design perspective, which are generally iterative.
Anyone agrees with me or am I just a 'No' sayer? :)
At some level there needs to be one person who decides what is to be done -- someone needs to define the overarching vision for the product. At that level, it's very important that there be a single, consistent statement of "what" the end experience should be.
But that leaves plenty of room for others to help achieve that vision by coming up with ideas for "how" to accomplish its structural elements. At that level, it can actually be better for the person who controls the vision to give the other team members some distance. It's important for one person to maintain a single clear vision of what is to be achieved, and to review proposed mechanics to assess how well they serve the vision, but one person is unlikely to be able to think of all the possible ways to achieve that vision.
So I think there's room here for everyone working on a development project to be successful by keeping the "what" and the "how" distinct. The creative lead needs to establish the guiding vision and be prepared to say "no" to any actions that would undermine that vision or fail to adequately support it. At the same time, leads need to be open to saying "yes" to different ways of achieving the top-level vision. If there's a better way to do something at an acceptable cost, and it serves the vision, no one's ego should obstruct it.
Of course, that means whoever gets to specify the vision had better know what they're doing. :)