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.

The Game Designer

So, I’ve been working at Black Lantern Studios for the past two weeks now in the Game Design department. For those of you who don’t know what exactly a ‘Game Designer’ does for a studio, here’s a quick rundown:
  • Game ideas
Game Designers get the privilege of taking an idea for a game and actually making it into a game. They have to foresee all possible problems with an idea, come up with compelling ways to make the idea a game, and watch the implementation from beginning to end.
  • Storyline
For the games that have a storyline, the Game Designer has to write it. Depending on the complexity and audience, the story can be very simple or very complex. Because BLS has a focused more on children's games in the past, a lot of the storylines haven't been incredibly in-depth. This isn’t to say it’s not a lot of hard work because of constraints, but allows much more room to reuse children themes without sounding stale.
  • Psychic and Fortune Telling
Designers give a game to programmers and artists in a huge document called a Design Document. This document is essentially the ‘Bible’ to how the game is supposed to work. Because this document is so vital, designers must write it so that it makes sense to all who reads it. They have to put themselves in the role of someone who didn’t come up with the idea and look at anything they write completely objectively. They also have to make sure they plan out the game. If the programmers and artists spend work hours only to find that a designer wrote the wrong thing in the Design Document, it can create headaches for all departments.

So, with that being said, I bet you’d like to hear what I’ve been doing! Well, to be honest, not much yet. Most of what I’ve been doing has not been design tasks (manual XML conversion, bug testing), but soon, I promise! However, there is one design duty I’ve been working on called ‘Balancing.’

Balancing is usually done once a game is built and in a relatively playable form. It allows for designers to go back and look at the design implemented by the programmers and make sure that it will not be too hard or too easy for players.

A good example of this would be in the Half-Life 2 games.

Valve has a nice setup for balancing in their games. They have a group of people each playing through a HL2 level and, each time a player dies, they record where the player died and how he died. After all players have beaten the game, they aggregate all that data and look for where players died the most.

If a lot of players die while trying to kill a particular boss, it’s a good sign that maybe that boss is over powered, or the player is under powered. This is also useful to find places in a level where there is bad level design. For instance, if a player has to jump over a pit, and a lot of players were shown to fall into the pit and die, it’s a good sign that there’s something wrong with that part of the level.

Balancing is a very important part of keeping your game playable. Gamers are very finicky. If they find themselves dying because of bad design, it can turn them off from playing that game. The real trick is to make a game challenging for all types of gamers, which turns out to be a very fine line to walk.
I have a few things to say about the industry, but I’ll hold off until next post.

Monday, June 2, 2008

In the beginning..

To start off, here’s a little introduction about me and where I’m coming from.

I’m a 22 year old Information Technology major at the University of Missouri-Columbia. I began working on games in my early teens with a piece of software called RPG Maker 95. Although a lot of the programming was hidden behind the scenes, the software let me produce games quickly and focus more on story and character development. I never finished a full game, but I learned a few key concepts for future use.

After that, I took a hiatus from game creation to focus more on creative writing. The programming side of games seemed really complex and impossible to me, especially with some of the math related stuff. I would look at someone’s code and try to understand it and come up empty handed and disheartened. So, I did something that was relatively easy for me and wrote random blog posts, songs and stories. Some I was proud of, others made me feel silly for writing them.

What got me into programming, as much as I hate to say it, was a Visual Basic class taught at my high school. The simplicity of the language made it possible for me to better understand the beginnings of how computer programming worked. I didn’t know it then, but that was just the tip of the iceberg.

After graduation, I moved onto Community College where I learned to program in C and found myself writing much less than I once did. I really began to feel the tug between the two sides of my brain: the creative writer and the logical programmer. Programming gave me the freedom to create useful things, where my writing was a tool to expand my vocabulary and express myself.

Throughout this period, I hadn’t thought about getting back into game development until I bought a Nintendo DS and stumbled onto the huge online homebrew community and the open source library Palib. I soon found myself back working on games.

There was just one problem: I wasn’t very good at programming. But that didn’t matter! I would use it to get better. And that’s exactly what I did. As I programmed stuff, I learned about structures, memory management, and other stuff that was really foreign to me in the unimplemented context. I also got the courage to go through the Calculus sequence and, although I managed to only get a C in a lot of those classes, I took away exactly what I needed to learn from them through implementation.

Since then I’ve moved between the Nintendo DS and PC game programming. All of this got me an internship working for a company called Black Lantern Studios in Springfield, MO, which is the reasoning behind this blog. It’ll be used as an account of my time spent at BLS, what I’ve been doing, things I’m learning, and other things I think might be useful to my future-self and maybe some kid looking to get into game development.