Wednesday, June 18, 2008

Keeping Peace and Secrets

Hey all. So, I mentioned in the last post that I had a few things I wanted to talk about with regard to the industry. I’ve never really worked at a company that develops games, so a lot of the inner workings were very foreign to me. But, I’ve learned a few things in the past two weeks.

First off, I mentioned above that designers have to be very clear when writing Design Documents. There are tons of reasons this needs to be done, not only for the obvious reasons, but for something that I hadn’t thought of before: departmental peace.

Take this scenario: The designer finishes a design document and sends it off to programming and art to be implemented. When the first build comes to the designers, they notice that something in the game isn’t right: it doesn’t do X! Design goes over to programming to ask them why X isn’t in the game. Programming goes around to figure out who was assigned to program X and why they didn’t. After this, either two things have happened:

1. X wasn’t in the Design Document, so the programmer didn’t know!
2. The programmer forgot X, or thought X wasn’t a very good idea and modified it.

So, there’s nothing really great about this situation. Either the designer is mad because the programmer didn’t implement the design the designer worked hard to create, or the programmer is mad because the designer came over accusing the programmer of not doing something didn’t know he was supposed to do.

Now, this wouldn’t be a problem if it was a freak occurrence. However, the nature of working on a large project with multiple people lends itself to miscommunication and mistakes. There are just too many long nights and strict milestones for things to go completely smooth. This isn’t to say there aren’t some projects that are better than others, but the problem exists and can build walls between departments.

This is why a thorough Design Document is a MUST on any large project. Give the programmers the freedom to be programmers, give the artists freedom to be artists, and write a Design Document so that both can execute the game as if you were there.

Another thing! I can’t discuss many of the projects I’m working on. This one I knew before I took the job, but it’s interesting to be reading news websites and see rumors about the release of game X and know that your company is working on it. It can also make things very awkward when trying to explain what I’ve been working on when I can’t mention what I’ve been working on. But I think, so far, I’ve done pretty well. Hurray for day 3.

There’s one more thing I want to make clear about working in the industry. When I was younger, making games seemed like the best job in the world. Although it is a really fun job, I want to disillusion some of you who think its all fun and games: It’s really not.

If you want to get into game design, you HAVE to get good at something that isn’t games. This could mean programming, or writing, or drawing or something that exists outside of what is considered a ‘Game’. ‘Designing Games’ professionally isn’t something you really get to do unless you’ve been in the industry for a while. And even then, you have to prove that you’re good at it.

My advice to anyone who wants to get into game design is to point your productive arrows all in one direction. This means going to college and focus on something you can make games with (art, programming, writing, sound, just to name a few), buying books and absorbing anything and everything about the subject you can and its relation to game design, and use some of that time you would normally spend playing games to come up with game ideas and flesh them out. And then, after all this, what little time you have left you can use to play video games.

For the longest time I told myself that I wanted to get into making games, but never did anything outside of it. It’s not until you force yourself to sit down, go through all hurdles, and start working do things start coming together.

No comments: