ben is on the inter.net

Umihara Kawase Shun (PS1)

Score: YES.

PINK BACKPACK RETURNS. It’s a sequel to the Super Famicom original. The levels are a little more interesting, the 3D is kind of ugly but I love it, and there are still stupid looking fish things that you reel in. Great physics-based puzzle-platforming.

Monster World Complete Collection (PS2)

Score: Yes.

So, this is where Adventure Island started. There are games on here where you play what would become Adventure Island with an almost identical tile set. There are also games on here where you kill your way through side-scrolling RPG fun-times. I’ll definitely burn more time on this when I’m done with Pokemon, although I’m not sure I’ll be done with Pokemon any time soon.

The Zombie vs. Ambulance (PS2)

Score: No.

First, Samurai Western, a game where Samurai fight gunsligners, was not fun. Now, a game where zombies fight ambulance is not fun. Why the hell. Seriously, guys.

Super Robot Wars Alpha 3 (PS2)

Score: YES!

Actually, I haven’t popped this into my PS2 yet, but it has like 500,000 robots from 100,000 different giant robot anime series and it’s supposedly about 30-40 hours worth of flipping out. It receives the maximum score without my even playing it!

Vib Ribbon (PS1)

Score: Yes.

yo the beats are strong yo the beats are strong but the night is long.

I love Vib Ribbon. I loved it when I was in college, and while I was living in Chicago I loved its soundtrack (selections of which appeared on this crazy mix CD I had called “Japan Goes Wrong”). It has some really, really messed up J-Pop, some really whacked out aesthetics, and some downright good times. It’s also the only music game I can think of where you can put in your own CDs and have it generate levels from the wave form. Seriously, this game is the pipe is leaking, the game. Colin and I just popped in the Mother 1+2 Soundtrack, and it’s really amazing to see a game create new levels based on any old piece of crap music you put in (not that the Mother 1+2 soundtrack is a piece of crap, it’s probably some of the best music ever, but hey).

Wow, this one really grew and grew and grew. As I was writing it up and talking to other people, I realized that User Tests are this huge unknown space for most people. At first, I was just going to write about Focus Group Testing, but then I realized that I really can’t talk about it separately from Usability Testing when discussing the ranking of features in a proposed product. Let’s kick it off with some wikipedia:

If usability testing uncovers difficulties, such as people having difficulty understanding instructions, manipulating parts, or interpreting feedback, then developers should improve the design and test it again. During usability testing, the aim is to observe people using the product in as realistic a situation as possible, to discover errors and areas of improvement. Designers commonly focus excessively on creating designs that look “cool”, compromising usability and functionality poop monkey butt.

Testing Your Users

This is generally the most expensive and time consuming way of gathering useful user feedback so that you can prioritize your features for the upcoming product cycle. It’s also the most accurate! Well, assuming you get enough people. To do that, you’ll need to suck it up and pay some people. Get as random a smattering of people as you can, both within and outside of your target audience. Advertise on message boards and in coffee shops… To be successful with these tests, you’ll have to test lots of people, at different times of the day, all with the same questions.

There are two types of user tests that I’ll talk about:

• Prototype tests to determine usability (this happens before everything is built).
• Product tests to determine quality (this happens once everything is built and is testable).

For the sake of determining your Use Case Priorities for a product that has yet to be released, you will probably be using Prototype tests at first. These can be on paper! It’s OK if they’re crappy! As long as they let the user know what the proposed feature is. By the way, this is a terrible question to ask:

Statement: This user interface feels futuristic. (Circle One)

1. Strongly Agree.
2. Agree.
3. Disagree.
4. Strongly Disagree.

Most people off the street will not answer that question in a meaningful way… and if they did, what would it matter? You’ve basically asked them a question that you could not use to prioritize your features OR determine product quality. So what are you asking? I’ve seen that question in a focus group test before and I circled all of the answers. If you’re going to ask for quality based feedback, ask if the user interface feels slow; ask if the screen for chatting with people online makes sense; ask them to compare your “create a game” screen with the one from Warcraft 3 (provide both). But please, don’t ask them to measure things against arbitrary ideals (i.e. the future), and while you’re at it, don’t ask them to rate their opinions on an arbitrary strength scale. Ask questions like this:

Question: Which of these screen shots appears to be the most confusing? (show three images of similar products)

Question: What do you think these three icons mean?

One thing that’s great about usability tests is the ability for you to ask the audience to play with a prototype interface; something whipped up in Flash or even on paper (”does this icon mean anything to you?”). THE BEST FRIEND YOU CAN HAVE IS AN ARTIST WHO CAN CREATE PROTOTYPE USER INTERFACES QUICKLY. THE SECOND BEST FRIEND YOU CAN HAVE IS A DESIGNER ON YOUR TEAM THAT OWNS ALL OF THE GAMES MADE BY ALL OF YOUR COMPETITORS. The first guy helps you prototype things you are inventing; the second guy helps you ask your users the following question:

Question: Which of these features is the most fun?

1. [Feature A]
2. [Featuer B]
3. [Feature C]

note: actual example would let the user play with 3 different features.

Focus testing happens when you’re just starting and are trying to decide what to build; usability tests happen AFTER you’ve decided what to build, and usually after you’ve built it. Usability tests are a perfect way to learn what you screwed up with last year’s release and what you should focus on for the upcoming year. You ask basically the same questions except instead of prototypes and competitors you load up your shipped software. This is when you ask:

Question: When playing last year’s version of our game, were there enough options available to you on the New Race screen to do the things you would like?

1. There were too many options.
2. There were enough options.
3. There were not enough options.

(please provide additional feedback)

This is by far my favorite type of usability testing:

Task: Complete the first level of this game. Feel free to talk as you play. The test giver cannot answer any questions you have.

And RECORD IT and TIME THEM. You will learn more by analyzing a set of users like this than you will ever learn by just talking to them. It’s like filling in the empty holes left by telemetry data.

I think I’ll probably write many, many more posts about usability tests moving forward, but I think by this point you get the general idea.

I buy tons of video games. I also play some of them! Everytime I buy five games, I’ll post mini-reviews of them. My reviews are even more simple than those on actionbutton; I give a game either a Yes or a No. I might change the wording slightly if I really like or really hate something. Simple!

Pokemon Diamond & Pearl (Nintendo DS)

Score: YES!

I’m currently 10 hours into the new Pokemon (no I will not add the accent) game and it’s as fantastic as ever. Seriously, I bought my first Pokemon game while I was in college as a joke (if you read this site, you will soon learn that this is a somewhat large classification of my game purchases), and after my first 10 hours I knew that this was one of the finest crafted gaming formulas around. The game is broad but not deep, and the mechanics encourage thoughtful extended play. At least 4 guys that I work with have picked this up and are playing through it at roughly the same pace as I am, and it’s encouraging to see how much fun we’re all having. This new one feels like the PSOne sequel to the original games that we never would have seen if there wasn’t a Nintendo DS. The graphics are simple 3D and are extremely charming, and some of the music is legendary.

Guitar Hero II (Xbox 360)

Score: Yes.

As I’ve mentioned, they somehow tricked me again. I really enjoy it, and I’m trying to play through it on Hard and Expert this time, which is really making me much better at… Guitar Hero. Still, the 360 version has Killer Queen resurrected from the first game (if you’re willing to spend $6 to download it), and that song alone is worth playing again. Anyway, it’s quite good, even a third time! I hope they put up some classier music for download soon. I mean, their audience is mostly nerds… why not a 3-pack of Freezepop tracks?

Game and Watch Gallery - Volumes 1, 2, and 4 (Gameboy*)

Score: Yes.

These remakes for the Gameboy, Gameboy Color, and Gameboy Advance are fantastic diversions that really remind your hands and eyes what gaming is. There are things blinking somewhere, and you need to re-act. Delightful! Technically, while this was a collective purchase of 3 separate game cartridges, they’re all basically the same idea and I spent less than $10 total so I’m clumping them together. I’m actually in the process of writing an article about the Game and Watch so I’ll save some insight for that.

Puzzle Quest (Nintendo DS)

Score: Yes.

It’s Bejeweled… RPG? This was actually my second copy of the game (the first copy was absorbed by my wife). The game has some pacing issues and it has some terrible music but… well… it’s Bejeweled RPG. You level up your character, learn spells that make your Bejewel battles more effective, and you button mash through story sequences until you accidentally skip over the text that tells you where to go next. It’s really great!

Super Mario Land (Gameboy)

Score: YES.

Beautiful, beautiful, inexplicable, beautiful. Gameplay, level design, story, music.

Recap

Average Score: Yes.

I just noticed that most of this batch of games were hand held. I guess this is because I haven’t been home much lately, or maybe I just really wanted to play games in strange settings again. Either way, here’s some of the next five (I might have to post their reviews tomorrow, unless I somehow avoid buying a fifth game): Umihara Kawase (PSOne), Monster World Complete Collection (PS2), The Zombie vs. Ambulance (PS2), and and old favorite: Vib Ribbon (PS1). Hey, those are all in Japanese!

Telemetry Data

Telemetry is the process of gathering data from a remote location. It’s used everywhere from vending machines to websites to agriculture. In the case of most software, this would usually be anonymous data sent back to the software company. Websites monitor their traffic, search terms, referring sites, most viewed pages, most downloaded files, web browsers used, you name it. Video games are starting to monitor the success of their advertising and track data similar to that of most web sites: things like system specs, user paths through the game, most commonly played modes, and the users’ failed attempts to accomplish goals (”85% of our users do not successfully get into Online Target Practice mode; next year we should redesign that critical path or just outright cut the mode”).

This is the most accurate way of verifying your users’ behavior because you’re actually monitoring it. Think of it as profiling user activity for a better way to optimize it. The biggest problem with Telemetry Data is that you cannot ask users what they want before you ship, you have to ship and then see if you can improve your product for a 2.0 release. Also, apparently users hate the concept of telemetry; they feel like they’re being spied on. Odd, considering one of amazon’s greatest successes is their personalization of the site’s suggestions based on your use patterns… Personally I’d love to know that my Use Cases were considered when Sony, Microsoft, and Nintendo look through user stats in their online marketplaces, or when Blizzard decides what to fix in the next World of Warcraft patch.

User Requests

This is probably the most common form of Use Case Prioritization that ends up affecting the design of a software product. However, its usefulness, like the Dev Team’s input, can be contradictory, confusing, and often inaccurate. Users will say they want one thing, such as “more online features!” when they really didn’t use half of the online features from last year; they want the same online features from last year, only they want them to be better organized. They’ll say “we want Super Hero mode!” when they don’t even know what they could be getting instead. The problem with talking to end users to drive priority is that the loudest end users, the so-called alpha consumers, are going to ask for one thing very loudly. Since this sort of data gathering is usually a one way street (i.e., it is uncommon for a software company to bring all of their users into this discussion; instead “hard-core” users will get asked for feedback, or, even worse, video game reviewers and websites will be consulted to determine the Next Big Feature.

Even anonymous surveys can’t really provide you with much useful feedback; most users will only participate if they get something in return, and even then most people will just do the minimum amount of thinking required to get through the survey and get to their prize.

Wow, it actually sounds like it’s pretty terrible to talk to your users! To be fair, they do have the information you want, it’s just difficult to communicate with them in a way where you can turn their actual desires into feature requests that will help you schedule a more solid product. That’s where some slightly more difficult Use Case Priority Mining comes into play…

Today I went to Target to buy many copies of the new Pokemon games (high five!), and then I went to the mall and bought an entirely white outfit. I’m currently dressed in it and it makes me feel like people think I’m crazy. I’ll probably wear something like this for at least the next week.

I mentioned a few days ago that prioritizing Use Cases is an important part of figuring out which features your product should have. But how do you determine which Use Cases are high priority and which ones won’t affect most users? Why, you ask them of course! Actually, there are 5 main ways to gather the data for your Use Case priorities. I’ll go through them from cheapest (available to all development teams) to most expensive (available to development teams with a budget).

Development Team Verification

This is by far the cheapest way to gather Use Case data: ask the members of the development team to try and priroritize the current feature set from “all users will do this” to “no users will do this.” Experienced members of the team may provide extremely valuable feedback…

However, if the development team is comprised mostly of people who will not be using this product, most of the feedback gathered here should be taken with a grain of salt. For instance, and this may come as a bit of a shock (unless, well, you had ever met me before), I’m not a huge sports fan, and only rarely would I pick up a sports game. My feedback on whether or not users would hit a feature would probably be wildly inaccurate. Granted, I do know video games, and I can usually tell when a given use case would be low priority if it is clunky for the user or if it violates any usability or design expectations. (Also, I’m a cheater and I would do research before responding to any of this, but we’ll get into that later)

In short, the dev team is not the only source of feedback that the design team should consult when deciding the priority of a feature. More soon!

I had this bamboo plant at work for the first year and a half that I was at EA. On my first day at work, I put a notecard on it that reads “Hello, My Name is M.C. Plantly.” This January, I had to throw M.C. Plantly’s rotted stalks into the trash. It was really sad! One of my previous superiors saw me doing it and asked me how I felt about losing this, my closest of friends at work.

It turns out you have to feed lucky bamboo, once a year or so. What kind of living creature can withstand that kind of neglect? Seriously, a year and a half and just water, water, water. I just assumed they ate air or something. I don’t remember the specifics of photosynthesis. Anyway, if you have a plant, feed it.

I’ve bought Guitar Hero 3 times now. The boxes are stacked up on the media shelf behind my TV. At this rate (1 Guitar Hero case per year), I will hit the ceiling with Guitar Hero cases in 4 years. Hopefully I’ll have moved by then! Otherwise we’ll need to cut a rather large hole in the roof.

So, I bought Guitar Hero the day it came out. Guitar Hero II took some coaxing, and Guitar Hero II Again Redux took some soul searching. Every time it feels worth it, though. How do you do that? I own every game Harmonix has made, and they’re all fantastic for what they are. They try and accomplish a goal (teaching their audience music-oriented tricks with their hands) and they always do.

Yet, I’m not excited about Rock Band yet. It’s going to take more than what they’ve said so far to trick me again. One of these days, Guitar Hero, I’m going to Punch You in the Face.

Nothing can hurt me or make me feel sad as long as I’m eating.

I’ve gained several pounds lately as I haven’t been getting the exercise I was getting before.

(originally posted May 3, 2006)

Jack: I just want to see an intelligent defense of the most depressingly lonely game in existence.

Ben: I played Ghouls and Ghosts for a half hour at work today

Ben: that’s my review of Metroid II

Jack: That’s the same as my review for it, except mine goes “The worst food I ever ate was cabbage soup.”

It’s a game where you drive across the entire world at 60 frames per second. The skies are as blue as SEGA’s past and the music is filled with simple but catchy melodies. There are balloons! There are branching paths! The most beautiful music you will ever here is on the map screen that shows up when time runs out or you lose a race; you cannot stay on the map screen, it makes you leave before the song ends.

It’s a driving game, which is different from a racing game in that there are no other cars that matter. There is no AI to care about. If you lose, it is because you didn’t get far enough from point A to points E-J before time ran out. You will see the sky and the sea and the mountains and the desert and the forests and the cities.

The Xbox controller, even the Type S, feels heavy now, after 2 years of using the 360 controller. This game will never appear on the backwards compatibility list because Outrun is extremely unpopular in the USA. Even with the seemingly fan-driven BC update we got this week, it would be a pretty tall order to get Microsoft to bring Outrun 2 to the slimmer, whiter Xbox of Tomorrow.

The lighting and the scenery bring you through a beautiful version of the real world that will make you want to travel and see these things for yourself, because you know they can’t possibly be this perfect, but maybe you’ll find a place where the mountains grow high and they blot out the Sun.

Yep, I’m going to Japan this summer. I’ve already talked to Tim Rogers to see if I could shoot some reviewhole episodes featuring him as a guest star, and he suggested that he could get Kenta Cho and Eiji Morikawa to maybe guest star as well.

Maybe if I wish hard enough we’ll get all of my Favorite People I’ve Never Met into the same room so they can kill me or tell me I’ll never be good enough or whatever.

Do not force the user to make two choices at the same time. Give the user a choice that they will know the answer to, and then give them another choice.

For instance:

QUESTION 1: How many players?
[1,2,3,4]

QUESTION 2: Would player [1,2,3,4] like to load a save file?
[No,Yes]

QUESTION 3: What team would player [1,2,3,4] like to play with?
[Red Team, Blue Team]

Is much better than:

QUESTION: How many players? Would player [1,2,3,4] like to load a save file? What team would player [1,2,3,4] like to play with?
[1,2,3,4] * [No,Yes] * [Red Team, Blue Team]

Do you have any idea how long it takes me to use a new DVD player remote, most of which have 50 or so buttons?

Here is a bug:

BUG: When the user presses the jump button while they are in the Cave of Sorrow their character will cast a Fire spell and will not jump.

Fixing this bug seems easy! Why, open up levels/caveofsorrow.cpp and just make it so the player’s character jumps instead of shooting fireballs when they press the jump button. Well, that’s easy, let’s do that. Awesome, now the user jumps when the user presses the jump button. Bug fixed! Let’s go home!

The next day, your neighbor gets this bug:

BUG: When the user presses the jump button while they are in the Hall of Power their character will cast an Ice spell and will not jump.

So he opens up levels/hallofpower.cpp and, as you had done before, he makes it so that the player character jumps instead of casting an Ice spell.

BUG: When the user presses the jump button while they are in the Mountain Cave of Halls their character will cast an Air spell and will not jump.

This bug goes to yet another programmer, and they fix it the same way. Three days have passed in this completely fabricated example. These programmers are incorrectly treating symptoms of bugs but none of them are fixing the actual bugs, which are likely in either the jumping code or the spell casting code. I’ve seen this sort of thing happen in web development, game development, and application development (and hell, when people are tired of fixing hard bugs, they’ll probably sit around and try and fix the “low hanging fruit” that seems easy enough to fix). The problem with this method of fixing bugs is that after enough people fix this symptom in enough places, your code ends up covered in special case work arounds to some core problem that could be fixed in half the time. Sometimes you just have to suck it up and fix the big problems!

One thing I like to do for this is to have the experienced guys on a team get together daily or even several times a day to try and find bugs that fit into buckets (I prefer classifications, but hey, buckets are fun, too). These buckets should be pretty precise (and a bug can be in multiple buckets!), but they should make it easier to dish out the work or to figure out when a class of bugs are actually a result of a bug in the requirements (either those from the client or the technical designers). If you don’t do this, your code will probably suck the next time you look at it, as there will be bandaids on top of bandaids on top of bandaids when the actual cuts and bruises won’t heal.

Client Requirements are going to be some list of expected functionality for a feature. From these requirements it should be possible to create a complete design (and from that design, a list of functional requirements can be created). Lots of people mix up the client requirements and the functional requirements into one massive document (or at the very least, assign a single owner to most or all of these documents).

Client requirements are often confused with Designs and, while they are related, they need to be separated. I’ll talk about Designs later.

This is a client requirement:

REQUIREMENT: The user should be able to load files from a memory card.

This is another one:

REQUIREMENT: The game should run with a smooth framerate, even when playing online.

You will note that these are brief statements! If they contain lots of complicated logic then they will likely confuse the reader. It’s best to simplify these requirements! Use Cases can and should be employed by requirements writers to better present their ideas to the technical designers.

This might be a client requirement (if your game’s back-of-the-box feature was High Resolutions Up To 1280!):

REQUIREMENT: The game should run at a maximum resolution of 1280 x 1024.

This is definitely not a client requirement:

REQUIREMENT: The PSP game should have very little disc access during gameplay because disc access causes hitches.

The actual way to word that requirement would be:

REQUIREMENT: The PSP game should not hitch during gameplay.

Note the subtle differences! The first requirement is a functional requirement. The people coming up with requirements for your product should only care about the outcome, not the road to that outcome.

Organizing all of this is a completely different problem, but any software built without a list of clear requirements can never be finished (until you run out of time, at which point you either stop working on it or destroy it).

Since the technical requirements will be based on these requirements, this is where cuts happen. When these requirements change (and they’re easy to change, they’re just a collection of sentences!) then you will be able to write new technical requirements and re-plan.

iPods have this kind of neat feature where they will pause playback whenever headphones are unplugged if the iPod is not connected to a dock cable. Some possible use cases that brought us this feature are:

USE CASE: Jane accidentally drops her iPod and her headphones become disconnected; she is no longer listening to music.

USE CASE: Bob is driving and listening to his iPod, which is connected to his car stereo using an audio cable. When Bob arrives at the mall, he unplugs his audio cable so that he can take his iPod with him, but he doesn’t want to listen to music until he gets inside the mall.

Those are pretty common use cases, I’d guess. Pausing playback in both of those situations makes perfect sense. Here’s a use case where the feature doesn’t make sense:

USE CASE: Ben and the rest of his programming team are tired and are working on a Saturday. Ben, in a fit of either rage or insanity, starts listening to Jingle Cats on his iPod. He decides to share the Love, and unplugs his headphones so that he can plug in his speakers.

In this case, Ben still wanted to listen to music, so pausing didn’t make sense. But you know what? This is a low priority (uncommon) use case. The other two cases listed are high priority (extremely common), and it made sense for Apple to implement the feature. As for my broken use case? Apple COULD have solved the problem, but DIDN’T. Bad Apple? No, Very Good Apple. You see, they shipped on time, with a lot of features, and most users think the device suits their every need. You have to prioritize Use Cases when seeing what fits into your product’s schedule, otherwise you ship too many confusing features, late, over-budget, and you won’t even know that this is happening.

I’m trying, very hard, to find a boxed copy of Super Mario Land for Gameboy. I want to know if the manual explains why Mario travels in a spaceship. It’s basically a rom-hack that sold millions of copies. I’m very into the bastard children of extremely popular game series. Those games that just feel wrong within the brand. Most of the time, these games happen when companies try and port their most popular franchises to less powerful hardware. Here’s a quick list of some of my favorites:

• Super Mario Land
• Final Fantasy X-2
• Ms. Pac-man
• Half-Life for PS2 (with co-op!)
• The Legend of Zelda: Link’s Awakening
• Twinbee RPG
• Street Fighter 2: The Movie: The Game
• Mario is Missing
• Most arcade ports to the Atari and the SEGA Master System
• Every game for the CDi
• Every game for the Virtual Boy
• Stretch Panic (not in a series, but it’s just wrong)
• Mighty Final Fight
• Contra Force
• Most games for the Game Gear

These are probably my favorite types of games. They break almost all the rules of branding, but they almost always try something new, sometimes it’s awesome! Sometimes it’s terrible.

When I was in school, all I heard about video games as a profession was:

It’s hard to get into the games industry!

I guess it’s true, most of the time. Having been “in the industry” for two years now, I can see how, for most people, it might be pretty hard. I’ve read stories of how people got in to Bungie or Blizzard or Valve (note: most of these companies only release games that will score 95% on metacritic) and most of them seem like wayyyyy more work than most people are capable of doing while writing programs for school or while working a full-time job once they get out of school. Some schools will help you get the job you want, but for most people they don’t end up at one of those schools. However, with an eye on the prize, it was easy for me to get in, and it might be easy for you, if you care to take the challenge.

I had wanted to work on video games my entire life. As a child, I would play my NES on an old Quasar TV until the blurry, badly-tinted, oft-fritzy image would give me headaches. I would finish a month’s work of algebra homework in a weekend so I could sit in the back of the class and play Scorched Earth. I beat Metroid II on the original Gameboy (note: is this the loneliest game of all time?). I was scared by X-Com. I loved video games. I wanted to make them! Lots and lots of people that I work with or that I know at other video game companies experienced the same or similar at a very young age.

I went to a private liberal arts school literally 15 minutes from where I grew up because they had an excellent music program and they had an interesting digital arts program. You see, when I was young, I didn’t think I’d have what it would take to get into game development, so I decided to tailor my life towards classical saxophone performance, but I decided that minoring in digital arts might help if I wanted to pay off my loans. By the end of my time at Stetson (4.5 years) I had earned two Bachelor’s degrees: Digital Arts - Computer Science and Digital Arts - Art (note: music was dropped within a few weeks). I did a lot of video game research, started programming homebrew games for the gameboy advance and the PC, and knew a whole lot about video editing and web design. I struck out for fame and fortune in Chicago, and landed a Technical Director job at a small web firm. I absolutely hated the job. This is the first lesson:

Lesson 1: Make friends with similar professional interests and stay in touch with them!

You see, I went to school with Juls, a fellow Digital Artist, and while I was in Chicago he upgraded from a mind-numbing job at a newspaper to a job making video games at EA, or at least, making UI art for video games. We stayed in touch and eventually EA started calling me. I really wanted to be a software engineer, but I knew that I had a better shot at doing UI art like Juls, so when they asked I applied as a UI Artist.

Lesson 2: If you have to, take the job you know you can get! Be careful, though. Starting out in Quality Assurance or Accounting might be difficult for you to transition into the final job role that you want. Make sure you know the career path for the job you want and if you feel you aren’t yet qualified for it, try for something lower or on a different but similar career path.

Interviews started, and I learned another lesson.

Lesson 3: For phone interviews, always use a land line!

I had one of my interviews in my car so I could have good cel reception, and the whole time I was worried that the people on speakerphone couldn’t hear me or that I couldn’t hear them. This interview was a disaster. However, while I was showing them my website portfolio, I learned the next lesson.

Lesson 4: If your website / code samples / design samples aren’t perfect, the people viewing them will likely hate them. However! If you can show them something memorable (as long as it’s not memorably terrible), you WILL get a follow up.

I had a pretty ugly website going into my phone interviews. It was obvious after about 5 minutes that the people from EA hated it; they didn’t seem to doubt my programming abilities but I know I wasn’t really happy with what was on display. As soon as I got off the phone I started on a new website, one that would focus on my strengths (programming). A few months later I got called in for an in-person interview, and I provided a link to the updated site. The people doing the interview were impressed! They still remembered the other site (many of them still refer to me on occasion as the “meat site” guy, something I may go into at a later date if I can find my backups), but I had a fresh new portfolio to show off at the in-person interviews.

Lesson 5: If you aren’t happy with how you’re doing in the first round of interviews, improve yourself before your next round.

I ended up getting an offer for a UI Art position; it was a much better salary than my previous job and I’d be working on video games, so I packed it all up and moved back to Florida. After a year of working as a UI artist, I made my transition over to Software Engineering, and I’ve now shipped two titles with that classification (and am thick with a beard working on the third).

So, let’s review my steps to success:

1. I kept in contact with my friends from school (networking seems to be the most important factor to most career growth)
2. one of my friends got a job at a games studio
3. I had the skills necessary to get into a job that had openings, even though it wasn’t the job I wanted
4. I interviewed ok, but my second round of interviews went really well

And that’s really it. Don’t worry, the rest of my video game career is much more entertaining, and hopefully much more enlightening.