Effective Networking (Be Educated)

Possibly the easiest thing to do to increase your networking skill involves little to no actual networking at all: you need to read. Become educated about the industry. Learn what the development roles are, what the vocabulary is, and, most importantly, who the major and minor players in the history of the industry are.

Industry Roles

You need to know about the different roles people play at a game company. The first reason to learn about development roles is so you don’t look like a complete newbie. The second, and more important reason, is so you can start a conversation with anyone. For example, if you meet someone who says they work in quality assurance (QA), you can ask them, “Oh, what kind of bug tracking software do you use?” If someone’s a programmer, you can say, “Do you work on engine code or more on the scripting side?” If you meet a producer, you can ask, “How big is your team? Do you think that affects communication between programmers and artists?” And so on.

Another really important thing to learn about is the complex macro relationship between development studios and publishers. A lot of people assume that the development studios handle all the development, and that the publishers just market and distribute a finished product–but that’s not quite right. For example, most developers only have one or two QA testers acting as liasons, while the publishers handle the bulk of the testing! This is related to the reason why, when you go for tech support for a game developed by Studio A, you’re often sent to the website of Publisher B. I’m sure someone could write about this stuff at length.

There are a lot of books out there that go into industry roles in pretty exacting detail. If you want a great picture of what goes on day-to-day at a real game company, along with summaries of what all the different roles at a company are (from management to development), I highly recommend reading Game Development and Production, by Erik Bethke. He goes into the often excruciatingly boring details about who writes engine code, who creates game content, who tests, who handles daily scheduling versus yearly scheduling, the role of publisher relations, etc. Another excellent primer for this process is Game Design: Theory and Practice, by Richard Rouse II, which focuses more on the “what designers need to know” aspects.

Vocabulary

If you’re going to walk the walk, first you have to learn how to talk the talk. Do you know what the difference between an alpha and a beta is? Do you know what iterative process is? How about emergent behavior? Neural networks? Normal mapping? The difference between a positive feedback loop and a negative feedback loop? Ludology vs. narratology? Casual games? Serious games? IGDA? ESA? ESRB? IEMA? IGJA?

And please, don’t get caught calling it “the gaming industry.”

Like any industry, we have a lot of jargon. If you’re going to fit in, you should at least famliarize yourself with jargon from all subdisciplines of game development. This includes art, programming, and design, but also management and even academia.

Here is one simple example of a jargon failure. Often, I will be at a networking event, and a hungry young student will come up to me and ask how they can get “a Q & A job.” The problem is, there is no such thing as a Q & A job in the game industry, and if you ask for one, you are demonstrating your ignorance. Or at least your lack of eloquence. What this person means to ask for is a QA job. If you are looking to break into the video game industry, QA is a great place to start. QA stands for “Quality Assurance”. While I suppose in a very broad sense, the early build of a game is posing a question (“Does this build suck?”), and it is the QA tester’s job to provide the answer (“YES!”), it would be exceedingly silly to think of things in these terms.

Tom Sloper has ranted about this before, too.

So yeah, get your jargon right or you’ll look like a doofus.

History

There are myriad reasons to learn about the history of the game industry.

First of all, when you’re networking, you’re dealing with people. And people love to gossip. But you can’t participate in gossip about Company A if you’ve never heard of them.

Second, knowing local history helps, especially at a regional meeting. If you’re in Boston, you’d better know a thing or two about Infocom and Looking Glass. If you’re in Maryland, read about the history of Microprose. If you’re in California… well, you have a lot of studying to do. But the main benefit of this is that upper management tends to be older, which means that they probably started out in one of the seminal game companies. When you eventually do meet Experienced People, your knowledge of this history will definitely impress them, as they believe (correctly, I’m sad to say) that most people born after 1980 have never heard of these companies or played their games. For the record, I have graciously posted an example of my failure to know my history.

Also, here’s another thing, sort of a side note but sort of related. If you live in the United States, don’t bother delving too deep into the history of Japanese game companies. If you absolutely love Final Fantasy, that’s great, but knowing the history of Squaresoft is not going to be a huge help when networking in this country. One thing I’ve noticed is that Japan and the US are still very isolated from one another. If you get 1000 American game developers in a room and ask them “Who here has worked with someone who worked at Looking Glass?” you would see something like 200 hands go up. If you asked those same developers “Who here has worked with someone who worked at Squaresoft?” I’d bet a lot of money that you might see 3 hands go up.

Resources

Be sure to read for both breadth and depth. I’m putting a sort of annotated bibliography here of all the books and websites that I read, so you can have a place to start. But this is just a starting point. My best advice to you is to read first for breadth, and then find the areas that truly excite you and delve into those.

Books

Game Development and Production, by Erik Bethke. This book provides an excellent, if sometimes dry, overview of everything it takes to run a game company.

Game Design: Theory and Practice, by Richard Rouse II. Probably the best starter book out there for the aspiring game designer. It not only teaches you design principles, but it teaches you how to interact with the rest of the game company, and provides the necessary communcation tools (SPECS!) you need to do so.

Masters of Doom, by David Kushner. The inside story of iD Software also teaches you about some of the colorful personalities and typical clashes you’ll see from time to time.

The Fat Man on Game Audio, by George Sanger. While this looks like a book about audio (and it is, to some extent), the best part about this book is when the Fat Man offers insight into the machinations game industry. A must-read.

Magazines

Game Developer. Written by developers, for developers, you can learn a lot about what problems game developers are currently concerned with. This is a very good place to pick up on new jargon, as well.

Websites

Gamasutra. This website (run by the same people who run Game Developer magazine) is the primary web resource for people who want to know about game development. Again, this is largely because it publishes news and features written by developers, for developers.

Gamesindustry.biz. While Gamasutra offers some business-related news, this UK-based site is an invaluable resource for people looking to learn about the macro stuff that goes on in the industry (mergers, layoffs, game sales, etc.).

The Escapist. For being a relative newcomer, The Escapist has amassed a wonderful selection of pieces. Particularly relevant to this article is the fact that they cover the history of current and long-dead game companies with a fanatical attention to detail.

Tom Sloper’s Game Biz Advice. I hope that one day my blog amasses a collection of articles as useful as Tom’s. This is amazingly good stuff, and part of the reason I focus on networking and not on general “breaking in” advice is that I wouldn’t want to compete with the wisdom of his words.

Art

I’m woefully deficient at the whole art aspect of making games. However, Michelle Clay isn’t. Check out this great advice she gives aspiring game artists.

Other Stuff

A Hole in the Desert. A free excerpt from Michael Rubin’s history of LucasFilm. This chapter contains a very nice history of the rise and fall of Atari, and then examines Atari’s relationship with LucasFilm. Then it goes into some early LucasArts history. This is the story of the early days of the American games industry. Read it!