Thursday, January 31, 2008
Corporate Networking: Filling Gaps
One of the most important skills you can have as a new person at a company is the ability to detect gaps, and then fill them in.
Gaps are the little spaces between the pieces that make up organizational puzzle of any company. These are roles or projects that either don't exist and should (a true gap), or do exist but are neglected and have fallen by the wayside (a responsibility gap). If you can fill in a gap, you have become an extremely valuable employee. Let's dig a little deeper into the two kinds of gaps.
True Gaps
A true gap is either a project or a position in a company that doesn't exist, and yet the need is there. It can be tricky to detect a true gap: sometimes nobody knows that this gap exists, and sometimes there are people who are aware but feel like they can't do anything about it.
I'll give you an example. You've been working diligently in QA for about two months now, and you've got this sneaking suspicion that things are a little... repetitive. Your boss has asked you to test weapon animations in the game: load up every weapon and attack with it, make sure that the animation isn't broken.
The problem is that this game is an action-RPG, and there are 2,000 weapons and weapon variants, and it takes about 10 seconds to type the command to spawn a weapon, equip it, and use it. Hmm. That's 20,000 seconds, or 5.5 hours of testing. How would you solve this problem? One solution is to plug away at it for 6 hours.
Another solution is to automate things. You can spend those five hours learning how to use something like AutoIt, which is a basic scripting language that lets you write a program that tells the computer to do things with the keyboard and mouse in a given order. If you have any programming experience at all (I'm talking intro to programming in high school or whatever), you should be able to write a script that says: click here, type "spawn weapon a", click there and there, hit enter. You don't even have to be smart enough to figure out how to write a loop: just grab a list of all the weapon names from source control, dump into Excel, use the CONCATENATE() function creatively and all of a sudden you've generated 2,000 lines of script, one for each weapon. Then all you have to do is set the script running before you leave the office for the night, and run a video capture program like FRAPS. Show up a little early the next morning and you've got 8 hours of video of the computer doing your work for you. Now you can just spend an hour skimming through the video for animation problems.
It's not a perfect solution, and you might have spent more time solving it through automation than you would have otherwise, but you know what: now you know automation, and you can show your supervisor what you did. And all you have to do is say these magic words: "So Boss, if there's anything else that comes up that you might want automated, let me know. I can handle it." Before you know it you're the automation expert on the team. For those of you QA testers who want a good way to transfer into programming: this is one way to do it.
(Sometimes you can get away with doing this kind of project without permission from your boss. As Chris Hecker once put it: if it'll take a few hours and doesn't interfere with your other tasks, just do it. The end result will justify the time you spent. It's much easier to convince your boss that automation is good by showing her something cool than by pleading for a chance to spend time on it.)
The point is that you took the extra step to offer your services in the future. What you're really saying to your boss is: there is an automation gap in this department, and I am here to fill it.
Another way to sniff out true gaps is to pay attention to what people around you are saying. Is there complaining going on? Because where there's complaining, there's a problem. And where there's a problem, there is sometimes a solution. And sometimes you are the person who can provide that solution.
Responsibility Gaps
I owe my career path to a responsibility gap. When I was at Turbine, we had a metrics project, but there were only a few people working on it, and those people were only on the project 5% of the time. It wasn't their fault, they were pretty overextended. The problem was that nobody was using the metrics, and with no end user, there wasn't much motivation from developers or management to put any real effort into it.
One day I noticed that we had these metrics reports going out, but they looked a little... thin. I asked my boss about them, and he said, "Talk to so-and-so about it." So I did. And that person was more than happy to teach me about a system that he really didn't want anything to do with because he had 100 other things on his plate. So I figured I could learn the stuff. I spent three days learning SQL and spent two weeks (with my boss' permission) putting together a killer metrics demo. It was great, everyone loved it, and I got promoted into a position where I became "the metrics guy" at the company.
Do you see overextended coworkers? People with a dozen different jobs whose eyes yearn wearily for the sweet, sweet sleep of unemployment? Projects that have no discernible progress to report every week during the all-hands meeting? Ask if you can help. Even better, if you're feeling bold, propose a way you can help. People love handing off responsibility: it's yours for the taking.
Gaps are the little spaces between the pieces that make up organizational puzzle of any company. These are roles or projects that either don't exist and should (a true gap), or do exist but are neglected and have fallen by the wayside (a responsibility gap). If you can fill in a gap, you have become an extremely valuable employee. Let's dig a little deeper into the two kinds of gaps.
True Gaps
A true gap is either a project or a position in a company that doesn't exist, and yet the need is there. It can be tricky to detect a true gap: sometimes nobody knows that this gap exists, and sometimes there are people who are aware but feel like they can't do anything about it.
I'll give you an example. You've been working diligently in QA for about two months now, and you've got this sneaking suspicion that things are a little... repetitive. Your boss has asked you to test weapon animations in the game: load up every weapon and attack with it, make sure that the animation isn't broken.
The problem is that this game is an action-RPG, and there are 2,000 weapons and weapon variants, and it takes about 10 seconds to type the command to spawn a weapon, equip it, and use it. Hmm. That's 20,000 seconds, or 5.5 hours of testing. How would you solve this problem? One solution is to plug away at it for 6 hours.
Another solution is to automate things. You can spend those five hours learning how to use something like AutoIt, which is a basic scripting language that lets you write a program that tells the computer to do things with the keyboard and mouse in a given order. If you have any programming experience at all (I'm talking intro to programming in high school or whatever), you should be able to write a script that says: click here, type "spawn weapon a", click there and there, hit enter. You don't even have to be smart enough to figure out how to write a loop: just grab a list of all the weapon names from source control, dump into Excel, use the CONCATENATE() function creatively and all of a sudden you've generated 2,000 lines of script, one for each weapon. Then all you have to do is set the script running before you leave the office for the night, and run a video capture program like FRAPS. Show up a little early the next morning and you've got 8 hours of video of the computer doing your work for you. Now you can just spend an hour skimming through the video for animation problems.
It's not a perfect solution, and you might have spent more time solving it through automation than you would have otherwise, but you know what: now you know automation, and you can show your supervisor what you did. And all you have to do is say these magic words: "So Boss, if there's anything else that comes up that you might want automated, let me know. I can handle it." Before you know it you're the automation expert on the team. For those of you QA testers who want a good way to transfer into programming: this is one way to do it.
(Sometimes you can get away with doing this kind of project without permission from your boss. As Chris Hecker once put it: if it'll take a few hours and doesn't interfere with your other tasks, just do it. The end result will justify the time you spent. It's much easier to convince your boss that automation is good by showing her something cool than by pleading for a chance to spend time on it.)
The point is that you took the extra step to offer your services in the future. What you're really saying to your boss is: there is an automation gap in this department, and I am here to fill it.
Another way to sniff out true gaps is to pay attention to what people around you are saying. Is there complaining going on? Because where there's complaining, there's a problem. And where there's a problem, there is sometimes a solution. And sometimes you are the person who can provide that solution.
Responsibility Gaps
I owe my career path to a responsibility gap. When I was at Turbine, we had a metrics project, but there were only a few people working on it, and those people were only on the project 5% of the time. It wasn't their fault, they were pretty overextended. The problem was that nobody was using the metrics, and with no end user, there wasn't much motivation from developers or management to put any real effort into it.
One day I noticed that we had these metrics reports going out, but they looked a little... thin. I asked my boss about them, and he said, "Talk to so-and-so about it." So I did. And that person was more than happy to teach me about a system that he really didn't want anything to do with because he had 100 other things on his plate. So I figured I could learn the stuff. I spent three days learning SQL and spent two weeks (with my boss' permission) putting together a killer metrics demo. It was great, everyone loved it, and I got promoted into a position where I became "the metrics guy" at the company.
Do you see overextended coworkers? People with a dozen different jobs whose eyes yearn wearily for the sweet, sweet sleep of unemployment? Projects that have no discernible progress to report every week during the all-hands meeting? Ask if you can help. Even better, if you're feeling bold, propose a way you can help. People love handing off responsibility: it's yours for the taking.
Labels: corporate, networking
Corporate Networking Feedback
I got some excellent feedback on my First Few Months post, especially from David, Will Jennings, Joe Ludwig, and Ian Schrieber. (The latter three are all experienced game industry pros. David might be, but I know a few a Daves, so I can't really say.)
Here are the basic points they covered, although you should read them in their entirety. If you think I'm going to expand most of these out into articles of their own... you are correct.
Here are the basic points they covered, although you should read them in their entirety. If you think I'm going to expand most of these out into articles of their own... you are correct.
- be respectful (no talking on your cell, excessive breaks, etc)
- show up on time, even a little early
- be self-motivated. when you finish a task, ask for more work
- find out what your real job is
- establish a feedback loop with your supervisor
- look for mentors anywhere in the company you can
- learn everyone's name (taking notes helps)
- be on the lookout for problems you can solve, and solve them
- step up and take responsibility for tasks that nobody "owns"
- don't be afraid to ask for favors
Labels: corporate, networking
Wednesday, January 30, 2008
No More Heroes: One Little Question
EDIT: Jeff figured it out. You have to load up your friend's game, leave the apartment, when you're outside press +, and then use the menus there to start a new game. That's some craptacular UI.
I'm playing No More Heroes. I love it. My question is: does anyone know how to play the game with multiple "profiles"? Craig wants to play it and I can't figure out how he can start his own new game--when the game loads up, it goes right into my game.
Is this some kind of ridiculous ploy to get people to buy more copies of the game?
I'm playing No More Heroes. I love it. My question is: does anyone know how to play the game with multiple "profiles"? Craig wants to play it and I can't figure out how he can start his own new game--when the game loads up, it goes right into my game.
Is this some kind of ridiculous ploy to get people to buy more copies of the game?
Labels: question
Tuesday, January 29, 2008
Corporate Networking: The First Few Months
This is the first part of a sub-series of networking articles about a topic that has always fascinated me: networking within a corporation. How do you go from zero to hero at a given company? I'll be writing this from my experience starting in QA at a mid-size (250-person) development studio. My advice almost certainly needs to be modified for a very small (5 person) company, and I'm curious as to how it scales for large (1000+ person) companies. Feedback is encouraged.
When you're a new low-level hire at a game company (let's say you're in QA) and trying to get yourself known around the office as someone who's competent, you'll quickly find yourself in an apparent catch-22. You need to be humble, you should not step on anyone's toes, and yet if you're too humble nobody will ever know how awesome you are and you will toil in silence.
How do you rise up as a star at a company without looking like a self-promoting jackal? It happens in stages, and today we begin with stage one.
For the first month to three months, you want to be excellent, be silent, and be observant.
Being Excellent
When you start working somewhere, you just want to spend a while being an excellent worker. If you're a QA tester, focus on writing great bugs, and and running through testplans and regressions quickly, but carefully. (FYI, a test plan is basically a checklist of things you need to test to see if they're working. Regressions are bugs that have been reported as fixed, and you're double-checking to make sure they were actually fixed.)
You get to be a great QA tester largely by focusing on your work. I've seen it time and time again. Good testers are the ones whose eyes are bleeding by the end of the day and have gotten into a state of flow while working. The bad testers are the ones who are distracted all the time. Not that a good tester can't take a break, but it's a matter of scheduling breaks so your flow is not interrupted.
But anyway, you want to focus on basic, quality work. While this isn't going to make you famous in the company, it will certainly endear you to your immediate supervisor, which is absolutely critical.
Be Silent
I am a huge fan of rocking the boat, changing process that doesn't work, righting the wrongs within a company. However, don't do this your first few months on the job. You will only gain enemies. If you attempt to change things, you're probably not even changing the right things for the right reasons, because you haven't taken the time to learn about your environment.
Now you should obviously speak up if you have questions about the way things are done. "How do I XYZ? Who is in charge of the graphics engine?" Those are fine things to ask. But keep quiet on the controversial stuff. For now.
Be Observant
The best part about shutting the fuck up is that it forces you to listen, observe, and learn. Pay very close attention to who is liked and disliked on your team. I learned a lot from noting which testers were considered annoying pests by the development team and reading the bugs filed by those testers to learn how to not piss off the development team. At the same time, a tester can be very annoying to the dev team but they might be a huge asset to QA for the same reason. So make sure to note who is liked and disliked by whom, and theorize as to what reasons.
The best thing about being in QA is that 90% of meaningful corporate communication lives on a bug server with archives that you can search through. Learn about the different personalities this way. It helps if you literally draw a map of who is friends and enemies with whom. I actually did this.
Most importantly, learn about the process at your company. Learn why it's in place. Learn who is invested in that process, and learn who secretly hates it.
Humility
The first few months at a company require restraint and full-on humility. You'll be an excellent worker and will probably not receive any recognition in return. That's okay, because you're learning about the organization, and in doing so you're learning different avenues in which you can promote your own awesomeness without coming off as a complete asshole.
When you're a new low-level hire at a game company (let's say you're in QA) and trying to get yourself known around the office as someone who's competent, you'll quickly find yourself in an apparent catch-22. You need to be humble, you should not step on anyone's toes, and yet if you're too humble nobody will ever know how awesome you are and you will toil in silence.
How do you rise up as a star at a company without looking like a self-promoting jackal? It happens in stages, and today we begin with stage one.
For the first month to three months, you want to be excellent, be silent, and be observant.
Being Excellent
When you start working somewhere, you just want to spend a while being an excellent worker. If you're a QA tester, focus on writing great bugs, and and running through testplans and regressions quickly, but carefully. (FYI, a test plan is basically a checklist of things you need to test to see if they're working. Regressions are bugs that have been reported as fixed, and you're double-checking to make sure they were actually fixed.)
You get to be a great QA tester largely by focusing on your work. I've seen it time and time again. Good testers are the ones whose eyes are bleeding by the end of the day and have gotten into a state of flow while working. The bad testers are the ones who are distracted all the time. Not that a good tester can't take a break, but it's a matter of scheduling breaks so your flow is not interrupted.
But anyway, you want to focus on basic, quality work. While this isn't going to make you famous in the company, it will certainly endear you to your immediate supervisor, which is absolutely critical.
Be Silent
I am a huge fan of rocking the boat, changing process that doesn't work, righting the wrongs within a company. However, don't do this your first few months on the job. You will only gain enemies. If you attempt to change things, you're probably not even changing the right things for the right reasons, because you haven't taken the time to learn about your environment.
Now you should obviously speak up if you have questions about the way things are done. "How do I XYZ? Who is in charge of the graphics engine?" Those are fine things to ask. But keep quiet on the controversial stuff. For now.
Be Observant
The best part about shutting the fuck up is that it forces you to listen, observe, and learn. Pay very close attention to who is liked and disliked on your team. I learned a lot from noting which testers were considered annoying pests by the development team and reading the bugs filed by those testers to learn how to not piss off the development team. At the same time, a tester can be very annoying to the dev team but they might be a huge asset to QA for the same reason. So make sure to note who is liked and disliked by whom, and theorize as to what reasons.
The best thing about being in QA is that 90% of meaningful corporate communication lives on a bug server with archives that you can search through. Learn about the different personalities this way. It helps if you literally draw a map of who is friends and enemies with whom. I actually did this.
Most importantly, learn about the process at your company. Learn why it's in place. Learn who is invested in that process, and learn who secretly hates it.
Humility
The first few months at a company require restraint and full-on humility. You'll be an excellent worker and will probably not receive any recognition in return. That's okay, because you're learning about the organization, and in doing so you're learning different avenues in which you can promote your own awesomeness without coming off as a complete asshole.
Labels: corporate, networking
Saturday, January 26, 2008
GLaDOS: Anonymous?
It's sort of funny listening to GLaDOS rant about Scientology.
Friday, January 25, 2008
Networking 201?
So last year I gave a talk at the Game Career Seminar at GDC. The talk was called "Networking 101," and it consisted of me going over networking basics mostly aimed toward college students trying to get that first game industry job.
CMP has been kind enough to invite me to give another networking talk at GDC. It's still part of the Game Career Seminar, but this time it needs to be more of a "Networking 201" kind of talk, aimed more toward people who have got their foot in the door but want to take their career to the next level.
A big part of this talk is going to be about networking inside a (large-ish) company. How do you go from the first day of QA to being someone that everyone in your company knows and likes? This involves analyzing communications between people at the company to determine prevalent attitudes and personalities. You also have to be friendly and helpful, but not so humble that nobody recognizes your achievements. It's a delicate balance, and one that I plan on addressing.
I will also cover how to continue networking in the industry in general once you're actually a part of the industry.
Does anyone have any questions related to this topic that they'd like to see answered in a talk? (I'll answer 'em here too, to the best of my ability.)
CMP has been kind enough to invite me to give another networking talk at GDC. It's still part of the Game Career Seminar, but this time it needs to be more of a "Networking 201" kind of talk, aimed more toward people who have got their foot in the door but want to take their career to the next level.
A big part of this talk is going to be about networking inside a (large-ish) company. How do you go from the first day of QA to being someone that everyone in your company knows and likes? This involves analyzing communications between people at the company to determine prevalent attitudes and personalities. You also have to be friendly and helpful, but not so humble that nobody recognizes your achievements. It's a delicate balance, and one that I plan on addressing.
I will also cover how to continue networking in the industry in general once you're actually a part of the industry.
Does anyone have any questions related to this topic that they'd like to see answered in a talk? (I'll answer 'em here too, to the best of my ability.)
Labels: networking
Thursday, January 24, 2008
About My Last Post (Cameras and Games)
So I posted a game idea yesterday. I'm flattered that so many people took the time to analyze it bit by bit. But I was mostly being lazy when I posted the entry. Obviously it wouldn't have to be Mario you're following around. I just used that as a stand-in for "generic platformer hero." And some of you got the fact that it's mostly meant to play satirically. Not for the "fun gameplay" element, but more, "oh wow being a camerman for the hero really sucks" kind of amusement.
It would definitely be a short, stupid game along the lines of what Daniel commented, although I would be interested to prototype it in both 2D and 3D. Mostly because 3D is where camera placement becomes an interesting problem space. But it may be too complicated, and there might be a better way to simulate it in 2D.
One thing I didn't realize until recently was that in the original Super Mario 64, there was an actual character (I believe it was a Lakitu) cameraman. Cameras in 3D games were so new that Nintendo felt they had to contextualize the camera by giving it a personality. A more recent example of camera-with-personality is Skate, where the camera is controlled by your best friend who occasionally makes comments about your epic bails and whatnot. Except you're controlling the camera and your avatar being filmed. Which means you're playing the protagonist and the protagonist's best friend / documentarian. Also notable was Robot Alchemic Drive, a 2002 game from Enix where you played a small boy remotely controlling a giant robot. The thing is, the camera was always framed first-person from where you were standing as the boy, staring at the giant robot a few blocks away. So you had to position yourself strategically so you could see the action and not be obscured by buildings.
Anyway, I don't see this as a AAA that could sell on store shelves or anything. I'm thinking more along the lines of a quirky free download that plays with our established notions of the disembodied camera and asks, "What of the hard-working folks who make all that running and jumping possible?"
It would definitely be a short, stupid game along the lines of what Daniel commented, although I would be interested to prototype it in both 2D and 3D. Mostly because 3D is where camera placement becomes an interesting problem space. But it may be too complicated, and there might be a better way to simulate it in 2D.
One thing I didn't realize until recently was that in the original Super Mario 64, there was an actual character (I believe it was a Lakitu) cameraman. Cameras in 3D games were so new that Nintendo felt they had to contextualize the camera by giving it a personality. A more recent example of camera-with-personality is Skate, where the camera is controlled by your best friend who occasionally makes comments about your epic bails and whatnot. Except you're controlling the camera and your avatar being filmed. Which means you're playing the protagonist and the protagonist's best friend / documentarian. Also notable was Robot Alchemic Drive, a 2002 game from Enix where you played a small boy remotely controlling a giant robot. The thing is, the camera was always framed first-person from where you were standing as the boy, staring at the giant robot a few blocks away. So you had to position yourself strategically so you could see the action and not be obscured by buildings.
Anyway, I don't see this as a AAA that could sell on store shelves or anything. I'm thinking more along the lines of a quirky free download that plays with our established notions of the disembodied camera and asks, "What of the hard-working folks who make all that running and jumping possible?"
Wednesday, January 23, 2008
Game Idea
So here's a game idea that just occurred to me: you're the cameraman who follows Mario around. The core gameplay would be to frame the hero properly so that the player playing him doesn't screw up.
This seems like a pretty obvious idea--has anyone done this before?
This seems like a pretty obvious idea--has anyone done this before?
Friday, January 18, 2008
GDC Parties?
So, now that I've been thinking about GDC nonstop for the last week, I'm wondering: anyone have the advance word on good parties? Hit me up at parties@orbusgameworks.com, or comment here if you don't mind the world knowing about it. You get me some party info, I'll buy you a drink.
FYI, the only party I know about right now is the IGDA party, and only because it happens every year.
FYI, the only party I know about right now is the IGDA party, and only because it happens every year.
Labels: conferences, parties
Wednesday, January 16, 2008
Business Card Count for GDC
Brenda writes about business cards for GDC, something which I've written about and to this day is one of the top 5 most popular articles on this blog. I want to ruminate a bit on the number of business cards you should bring to GDC.
So the first year I went to GDC, a complete newbie, I brought 200 business cards. I ran out by the end of the conference.
The next year I brought 300. I didn't run out, 300 was enough.
My third and fourth years, 300 was also just about enough.
Year five, I ran out at 300. Although I think the reason for this is I had just started my company and wanted to give people a new card with my company name on it, so I was giving my card to people I knew very well in addition to people I'd never met.
I'm bringing 500 cards this year. I don't think I'll use more than 250, but you never know.
EDIT: Okay, Joe is probably right. I'm a weirdo supernetworker. Most people I've gone to GDC with give away about 100 or 150 cards during the week of the show.
So the first year I went to GDC, a complete newbie, I brought 200 business cards. I ran out by the end of the conference.
The next year I brought 300. I didn't run out, 300 was enough.
My third and fourth years, 300 was also just about enough.
Year five, I ran out at 300. Although I think the reason for this is I had just started my company and wanted to give people a new card with my company name on it, so I was giving my card to people I knew very well in addition to people I'd never met.
I'm bringing 500 cards this year. I don't think I'll use more than 250, but you never know.
EDIT: Okay, Joe is probably right. I'm a weirdo supernetworker. Most people I've gone to GDC with give away about 100 or 150 cards during the week of the show.
Labels: conferences, networking
Track Video Game Bills Through OpenCongress
I recently discovered OpenCongress, which is an amazing website that lets you track what U.S. congressional representatives are up to via RSS. Of interest to readers of this blog is that they have a page/feed where you can get updates on all (national) bills that relate to video games.
Labels: politics
Tuesday, January 15, 2008
Conference Sentiment
Darren pointed me to an absolutely beautiful article on The Escapist, a sentimental look at video game conferences. The last page especially is not unlike what I attempted to evoke in my psychogeography of GDC.
I was going to write something about conferences in general here. With GDC coming up in 4 weeks, it's certainly on my mind. I may still write something. We'll see.
I was going to write something about conferences in general here. With GDC coming up in 4 weeks, it's certainly on my mind. I may still write something. We'll see.
Labels: conferences
Monday, January 14, 2008
Finally Happening
Hasbro is attempting to shut down Scrabulous, the Facebook Scrabble clone. Not that I didn't see this coming, but... darn.
Thursday, January 10, 2008
Stuff That Newbs Should Do
In case you missed it, Chris Hecker and Jon Blow wrote up a set of things that newbies who want to enter the game industry should do. They cover some excellent points, and the article boils down to "make games, and think hard about them." They wrote up the article as a critical response to an article on GameCareerGuide.com with 10 things a game industry newbie should do in 2008.
The list at GameCareerGuide admittedly reads a lot like the advice that I give, except you'll note that in my introduction to my networking articles, I state that I'm writing all of my advice on the assumption that you already know your stuff when it comes to the meat of understanding games. (I even updated the intro to link to the Hecker/Blow article.) The GCG article certainly lacked that context.
The last thing that I want to create with my articles is a bunch of people who don't anything about game development or game design who manage to charm their way into the industry, and then inevitably destroy it within 15 years.
The list at GameCareerGuide admittedly reads a lot like the advice that I give, except you'll note that in my introduction to my networking articles, I state that I'm writing all of my advice on the assumption that you already know your stuff when it comes to the meat of understanding games. (I even updated the intro to link to the Hecker/Blow article.) The GCG article certainly lacked that context.
The last thing that I want to create with my articles is a bunch of people who don't anything about game development or game design who manage to charm their way into the industry, and then inevitably destroy it within 15 years.
Labels: breakingin, networking
Wednesday, January 09, 2008
How To Behave Around Your Idols
Brenda has a nice post on her blog about how you should act when you're meeting famous people who have influenced you in some way. It boils down to "shut up and listen." Sage advice, my friends. Sage advice.
Labels: networking
