Tuesday, May 29, 2012

Mockup Update

Quick update: Here's a mockup of one of the bosses in the 'Bunker' area of the game. As you fight it, the corrosive acid rises and lowers. Was definitely listening to old Contra music while making it.


Monday, May 14, 2012

What Game Designers are Not

I just read a little interview with the director of Diablo 3, Jay Wilson, and I thought he made a pretty excellent point during the talk:

"And so a lot of the times I think you see people get into design because they have a lot of ideas and they think, 'If I'm the designer, then everybody just has to do my ideas.' And I would say if that's your reason to get into design, please don't go into design. That's a terrible direction to come from."
"If anything, your goal as a designer should be, 'I can't wait to get somebody else's ideas into this game,' because you're not going to be the one making it. Your art team and your programming team are going to do a ton of the hands-on work. You're not even going to be able to work until they do their job."

This is great, and I think very truthful of a lot of gamers who want to break into the industry. They think to themselves: 'I can't do art, I can't program, I can't compose music; but hey! I have a lot of ideas. That's what game designers do, right?'

Unfortunately, everyone has ideas! An idea man is not useful, because ideas are the only thing he can provide.
Most game designers have a background in art or coding, because the more disciplines or fields of knowledge they have, the better they will be able to filter their own ideas or ideas from the rest of the team, into a big pot of good ideas (hopefully) that we would call the game.


Wilson continues:

We get anywhere from 400 to 700 skill ideas. And there's a whole bunch of them that are awesome, but either aren't right for the class, or they aren't right for the game. That's the designer's job: to know the difference. It's not an artist or producer's job to know that. It's the designer's job to know that."

 The Game Designer is just that; they control and design the infrastructure of the play mechanics of the game. They do not just toss out ideas and expect others to make a game.

Of course, in small teams such as Dead Gear, where I essentially perform the Level Design, Game Design and Artist roles all at once, I believe the Designer has a bit more say in what the actual game should consist of.

But overall, and I've heard this echoed by tons of successful Game Designers, the main role of the Designer is to LISTEN. You listen to your team, you listen to your playtesters, you listen to everyone. It is arrogant to believe that good ideas can not come from people who aren't designers. That being said, the Designer needs to fight for the good ideas, and stick to a particular vision; otherwise you run the risk of draining time, resources and team morale by redesigning things over and over based on people's comments.

-Alex

Friday, May 11, 2012

The Importance of Illustration in a GDD


As I create pages within the game document and direct tasks for coding, it's become more and more apparent that in a good design document, the game designer should illustrate almost everything to better convey what they see in their mind.

I'm personally guilty of writing everything down in finely organized text and charts, with my own imagination filling in the blanks. The obvious danger of this is that the rest of the team will simply not be able to comprehend what your ideas are unless you make it as clear as possible. I'm an artist by trade, so the easiest way to go about that is just drawing or making a mockup.

After all, while this section in the GDD may convey most of the necessary information:


Something as simple as adding a little sketch can really help.




Or rather than giving a detailed text explanation about how swimming mechanics should work, I found that simply making an easy little image document (in addition to the detailed explanation) made things more clear:



So, lesson learned. When in doubt about explaining unclear mechanics, always take the time to create a visual example for the rest of the team, and save everyone a lot of time.

-Alex