In this coverage..

Page 1: Online Games Under Construction: Run Your Beta Right

Online game betas are about more than just testing your product and are often a missed opportunity for developers. Though it takes planning, betas can be an effective part of your marketing and community building efforts and in many can help grow your potential audience more than traditional marketing alone. This lecture will discuss the best practices and tactics on how to get the most out of your beta.

Page 2: Pirates of the Burning Sea: A Post-Partum

Well, it took five years, but Flying Lab Software has finally launched its Age of Sail MMO! Come hear the ups and downs of the project and all the things the team learned along the way. All of the successes and failures encountered while building a new MMO with a new team are presented.

Page 3: Special Ops: The Writer of the Future

SPEC OPS - THE WRITER YOU WILL NEED TO BE: The future writer will need to be fast and versatile to survive in a constantly changing and adapting mediasphere. They will have to be adept at boldly assault mediums that don't use writers and work with clients don't know they need writers -ex: social networks, virtual worlds and casual games will find unexpected need for writers. They will have to survive both on the assigned project and the spec project and must know how to budget time, effort and resources to balance their attack. This talk will also cover the skills, tools and attitudes the future writer will need. Flint Dille is an Austin Speaker Vet and writer/designer of over 50 games. Currently, he's also designing for virtual worlds and social networks. His new book, The Ultimate Guide to Videogame Writing and Design, co-written with John Zuur Platten, was released last month.

Page 4: Wake Up and Smell the Metrics! A Rant on Metrics-Driven Development in Online Games

We live in Darwinian times as the traditions of the old boxed goods industry shift online, investigating entirely new ways of reaching and retaining customers. But in many ways we have retained the old mentalities of guessing and hacking our way to success or failure. Running an online game is a service, and we have unprecedented access to customer and operational data. This session presents a business case on applying metrics to lower recurring costs and make games stickier based on measured data, not risky guesses. Some basic implementation plans are given to jumpstart your game into the world of metrics-driven development.

Page 5: It's Who You Get to Know

"It's not who you know - it's who you get to know." In this session, you'll learn where to meet people in the game industry, how to impress them, and what to say when you don't know what to say, starting with your fellow Career Seminar attendees. Will they become future competitors in the job market, or will they become a supportive network of industry insiders? Darius Kazemi will teach you how to make sure the latter is the case.

Online Games Under Construction: Run Your Beta Right

Jonathan Hanna (Sr. Producer, John Galt Games), Richard Weil (Director of Community Relations, Cartoon Network), April Burba

Treat your beta as Live

When you run your Beta, don't just pretend that the game has gone live, act as if the game has gone live, because it has! Sure you're not opening up to hundreds of thousands of players but you're still servicing the game to several hundred, maybe even several thousands of people and they will demand a service equivalent of the kind they get for a regular online game. So obviously you won't have everything that the final live service will have, and your players will understand that the game is not complete, but do not use this as an excuse to hide behind when things go south for some reason and people get upset. For instance if a batch of players get their accounts wiped without being notified because a database was reset to get new metrics data, they won't be like "oh, well - it's a beta so no big deal." No, they will be very upset because they won't know it was a wipe, will think it's a service issue and will believe that perceived quality of the product will carry over into the final version and stop playing. So treat it as a live service and keep all your players informed. Many may sign up for a beta without a full understanding of what it means to participate in such a program, so make sure that every player involved understands what will be expected of them during the process.

Players are not testing during a beta, they are previewing. During their play the development team is pulling down data and using that to clean up the experience and squash any bugs. You should not have to make your players directly participate in the testing process by having them submit bug or crash reports themselves - they should be left alone to play the game and have fun while the game logs any errors or crashes to send back to the dev team. If they come across a problem with the game play, you'll no doubt have forums set up where they can voice those complaints.

Goals for a beta

Several things you want to strive for when carrying out a beta:

• Building Community - keep players involved in the beta process by giving them reasons to play the game and work with each other to explore areas and uncover any problems.
• Setting a tone - take this time to work out with your dev team how to approach communicating with the community. Obviously you don't want the dev team becoming too chummy with the community, as that can lead the players to believe they carry great weight in design decisions. On the other hand you don't want the team being too stand-offish and making the community think their ideas are not being heard. Strike the balance.
• Building a contact list - get to know valuable players in the community; they may be leveraged later on as managers for various contents and community events.
• Define internal processes - work with your dev team on how to handle community issues (issues players have with each other) and how to support the players that have issues with the game.
• Marketing/PR - use the players to hype up your game. Get them hooked on cool features that they can use to tease any of their friends not involved in the beta. Find out what works and what doesn't and apply that to your overall campaign.
• Testing new ideas - this is the best time to implement new ideas or features, when the impact is relatively small and maneageble. Beta considerations

Don't forget you're creating a service, not just a game, and that you'll be forging long-term relationships with your user base. As such, when your game switches from beta to live, the massive influx of new players will push the beta players off their pillars and mix them up with "the rest of the crowd". Make sure you keep them involved still or they could feel pushed aside after the end of the beta period, and that the effort they put into the game was for naught.

Expect churn. Churn is the term used to describe the turn-over of players in your beta. You will have beta players become discouraged for many reasons, including them just not liking the game. Whatever the reason is, let them go and don't try to force them to stay - take their reason for leaving into account.

Necessary evils will have to be performed over the course of a beta, and you should both make players aware of this at the start, and make them have to deal with it as few times as possible. These include character resets, server downtime, stress tests and lots of game updates.

Don't muddle your player's minds with over-complex NDA's. If you must make players sign NDA's so they can't blab about the game, be sure to lighten-up on the legalese and make it clear what players can and cannot talk about in relation to the game during the beta process.

Getting and keeping players

Let players be able to form guilds or groups in the game from the start. Better yet, make it available for people to register for the beta as a group.

Once a player registers for the beta, let them come back and update their registration (if they have not yet been selected) in case they made any changes to their hardware configurations. Obviously make sure the dev team is notified of these changes in case they're looking for more people running, for instance, a certain graphics card model.

Allow players to turn around and invite friends into the beta. This doesn't have to be at the very start, but at some point when you're ready to expand the beta, instead of selecting new users, let the current player base bring in new users. This is a nice "reward" for beta players, and makes them want to play more now that they have more friends in the game as well.

Run lots of events for focus-testing purposes. For example, if there's a new dungeon that you want stress tested, challenge players to beat said dungeon in a certain amount of time to win a prize. Contests like these are good ways to energize the community while taking in valuable data. City of Heroes ran a costume contest to test their costume design feature. Be careful though that you don't make such things appear to be common-place, or beta players may feel like the service has been devalued once the switch is made to live and less contests are offered (unless you plan to keep up regular events into live).

Beta lessons

Your beta is a huge focus test for your game, be sure to record as much data as you can!

Use aggressive surveys, give out rewards for completing them, and let them be completed both in-game and out, as well as anonymously.

Talk to churned-out players and learn why they're leaving.

Metrics! (for more on metrics, see this talk)

Speak up on issues you receive from the community and address them. Ask yourselves: why will your product fail?

Using your beta for sales

As mentioned before, don't let the NDA ruin the player's ability to talk up your game to their friends and even the world at large. Be specific but at the same time clear enough that player's understand what they can and cannot say, rather than be confused and choose not to speak for fear of legal action. If NDA breaks do happen, combat them in a positive way.

Run journals, Q&A, etc., that keep the public in the loop about what's going on with the beta. Don't forget about your non-beta audience that is still waiting to hop into the game.

Have a link to the beta signup page placed in publicity pieces.

Coverage by Drew Sikora

Pirates of the Burning Sea: A Post-Partum

Joe Ludwig (Chief Technical Officer, Divide By Zero Games)

Pirates of the Burning Sea is a game that includes 4 nations, 5 careers, 3 sword fighting schools, a player-driven economy and tactical ship combat (one of its main highlights among fans). It began in October 2002 with 4 people planning on a 6-12 month development schedule. It was launched January 22nd, 2008 after accruing 66 additional development team members - and oh yea, over 5 years had passed too. D'oh!

Here are some lessons that the team learned over the years.

Lesson #1: Know how big your game is when you start

For five years, the team was constantly only 12 months away from being done, increasing the scope of the game a little bit each month. This scope creep also led to several downsides:

• Shoddy tools - development of new features constantly had tools being tossed out and new ones being created. There were never any well-polished and useful tools
• Never a good time to hire - bringing a new programmer to the team brought many months of training along with him to get him up to speed and keep him up to speed with the constantly increasing scope.
• Never good time to fire - once a programmer was trained up, letting him go became an insanely expensive proposition.

The team was stuck in the boiling frog situation.

Lesson #2: Figure out what game you're making as quickly as possible

Four separate visions of the game led to conflicting ideas as to what the game should be.

• The lead designer wanted deep combat simulation and a realistic, historic setting (this became the core vision eventually)
• The executive producer wanted an MMO, but with good graphics, foundation in naval traditions, and Starfleet Command-style combat.
• The content lead wanted rich single-player style content and an emphasis on storytelling
• The lead programmer (Joe) said "no" to everything and wanted a 6-month project, a minimal feature set to grow after launch and keeping the costs low so a tiny player base could pay for the team

Two years later they finally had an overview spec that was 50 pages long and written primarily by the lead designer and content lead, inspired by a sci-fi game project that had previously fallen through. Still, the vision and design didn't have a single owner, making it politically weak, and was very high level.

The team is still paying for the decisions made. Good graphics caused higher system specs and needlessly complex ship models; naval traditions caused a decrease emphasis on the Pirate flavor; single-player content caused lack of focus on group play.

Lesson #3: Don't make scheduling harder than it has to be

The team over-thought many of their scheduling issues, using Excel for simple task lists, which was easy to track but did not support dependencies and were only able to focus on one milestone at a time for 2-3 months. It did not scale well past 15 people. They also tried critical chain using Project, which worked well from 20-50 people and tracks dependencies, but it carried a high overhead. When the team grew even larger to 60-70 people they started using task lists in email and agile development in 1 month sprints, which shoved more scheduling work onto leads and required some QA time after sprint (3wks developing, 2wks fixing bugs).

Lesson #4: Don't save polish for the end

The game launched with thousands of known bugs, which the testers were good at finding but the programmers had no time to fix because the service was now live. Only critical bugs ended up being fixed in the last 6 months. Programmers would leave uncommon bugs for later and never return to them, but with thousands of players, uncommon bugs become common. Because mission designers always had new missions to create, basic playability problems existed in many.

Lesson #5: Don't abandon content quality in pursuit of content quantity

At some point they decided it would be a great idea to have 1000+ missions, but ended up instead with cookie-cutter missions and a lot of repeated content between nations.

Lesson #6: Deal with client performance at the start

Make sure you target the minimum spec for your game from the start. It's easier to scale up than down so make it as low as possible. Make the game look great on the minimum spec and test it there constantly. Define art budgets based on the minimum spec.

Lesson #7: Make sure everyone is on the same side

Mission designer were throwing incomplete missions over to QA which was reporting back a lot of legitimate bugs but also a lot of spurious bugs. Both sides developed an antagonistic relationship with each other rather than learning to work together. One tester even posted countless unimportant issues just to try to draw attention to himself as a diligent tester - make sure only bugs that need fixing are the ones getting reported.

Lesson #8: Don't be afraid to get rid of people who aren't working out

The team let go 5 people in 5 years - make firings strategic. If a person fights constantly against the team or makes all the people they come in contact with unhappy, they are simply not worth keeping. Period.

Lesson #9: Take care of your company culture

Make sure your team is happy. People enjoyed working on the project (good-natured ribbing and photoshopping, afternoon coffee trains). There was an open door policy and only minor crunch time at the end of some sprints. The CEO was quite the cheerleader, motivating people, and there was a very low turnover.

Lesson #10: Closed beta shouldn't take two years

2 years of beta burned out valuable community members and distracted the team from implementing core systems. It also didn't provide much actionable feedback as the game was constantly in too much flux and the population was too low for too long.

Lesson #11: Hire some experienced people for key positions

Only three team members had previous experience launching an MMO title, and only two of them were in lead positions. The art department was staffed mostly by former interns, who were not entirely reliable at first. The content department was mostly entry-level people. Contracters were never very well implemented thanks to the projects shaky schedule. Some more veteran team members could have avoided problems.

Lesson #12: Build more tools

One of the biggest regrets was not having the proper tools to make many tasks easier. Don't just build them, make sure they become an integral part of the development process and are not tossed out with each iteration.

Lesson #13: Hire a great art director

But do it at the beginning of the project instead of halfway through

Lesson #14: Players love character customization

17 slots with a dozen different pieces per slot and two colors per piece equals millions of combinations, almost all of it available at initial character creation. Data showed that players were spending 45-60 minutes creating their characters - not out of frustration or difficulty, but just playing with all the options, including peg legs of course. Unique clothing could be unlocked by missions and appearance didn't depend on stats.

Lesson #15: Unique combat systems are a blessing and a curse

Combat system hailed as best aspect of gameplay, with simulation of armor faces, gun recharge (up to 5 batteries), crew status, sail status, position of ship to enemy, land and wind. Very polished and well tuned after 7 major iterations, places great value on player skill.

Unlike any other forms of MMO player combat, which makes it hard to teach, and is slower-paced than many other game's combat systems. Also requires much more attention that standard MMO combat as well as more skill at the high-end.

Lesson #16: Don't try to cram and entire new combat system in a year

Team attempted to implement avatar PvP combat, but did not come out nearly as clean as ship-to-ship combat, was added too late to have time to iterate.

Lesson #17: Love your community and they'll love you back

Everyone on the launch team writes dev blogs and posts to the forums. When they screw up, they own up to it immediately. The team listens to players and often makes changes to the game based in their feedback. Community relations are considered every employee's job.

Even negative game reviews have pointed out how active the team is. Players ended up being more likely to give team the benefit of the doubt. Forums matured much more than many other games'. Team cites use of a dedicated community director for success of forums and the community as a whole.

Coverage by Drew Sikora

Special Ops: The Writer of the Future

Flint Dille (Writer/Game Designer, Ground Zero Productions)

The writer of the future

The main thing facing writers in today's media-rich atmosphere is change. Constant, unending and rapid change. Therefore, adaptation is key. This, according to Flint, is the main trait that writers have to have to be able to succeed in today's industry. Having written for over 25 years, Flint brings a lot of experience to the table, and not just in terms of games - he's also done various other media including TV, movies and comics. This versatility has allowed him and other authors like himself to keep pace with the evolving industry, especially during a time when everyone is able to express themselves on the internet through blogs and personal websites.

These days, extensibility is also a key trait for writers in terms of the material that they create. Products today are not staying within one medium any longer. Books become movies, movies become TV shows, games become books or movies - there are no more one-off stories. Everyone is looking for the next franchise or a way to move a story beyond the medium it was originally created for. Not only that, but everyone's still crazy about prequels and sequels and spin-offs.

Flint also points out the the line between fiction and non-fiction keeps getting blurred more and more. The DaVinci Code can have you believing that it's real, and a lot of it actually is. This mixing of fiction and non-fiction will give people pause and make them think about what's real in a story and what is fake. Some may even get it wrong. With interactive mediums like games, this can become even more surreal - take for example the Pini Society.

Only in the last few years have games reached a point where story has become as involved with the game as the gameplay itself, and developers have been brought to task for blending the two in a not-so-favorable manner. To allay this, more studios began hiring real writers from movies, TV, books and other media to create more compelling stories for their games.

Becoming a writer

While many of you reading this no doubt seek to become involved with writing for games, Flint spoke more about being a writer in the general sense. Sure, you can say that you specialize in games, but don't plan on writing just for games. There still isn't so much of a demand for writers that finding a job at a studio will be easy. I'm getting ahead of myself though.

Start off by gaining cred, as in credibility. Make sure you have published work to shop around to people in the various media industries. If you're not good at the whole networking thing or don't yet have a lot of contacts, you'll probably going to want to look into getting yourself an agent that can sell you properly. You can even take an entry-level industry job as a means to build cred and make contacts in the industry - it doesn't have to be a writing job so long as your getting experience working in teams and on games.

While you're building your cred, also be sure to work on your persona, or the distinctive traits that people can recognize as you. Flint pointed to a guy in the room with a fedora hat and was like "I'll remember the guy with the hat." I have a friend who likes to wear orange shirts to conferences. Besides appearance, make sure you come off to people as like-able and easy to work with. Be humble above all else.

Once you're established, you have the choice of going freelance or exclusive. Flint warns against signing any sort of exclusive deals early on in your career, even several years into your career. Why? Well personally Flint just doesn't think he could stand working on the same project for 2 years. Besides that, there's also the facts that you won't be seen as "on the market" and your contacts may dry up, and once the job is done - then what? There's no guarantee you'll have another project starting up right afterwards.

Going freelance means you're working more than one project at a time, possibly even across more than one type of media. Not only do things stay fresh, but your constant searching for work brings more people to you and allows you to grow your network of contacts so that one day you may actually have people calling you up with projects to take on. If you're a freelancer, it will also be worth joining up with the Writers Guild of America. The WGA can provide you with the benefits you need to maintain a healthy lifestyle. These benefits usually come with an exclusive deal when working at a studio.

Writing lifestyle

Once you're established, you want to keep a steady stream of projects coming in to pay the bills, but you also want to keep a side project or two active that will really revitalize your career. Don't focus so much on pulling down the dollars that you lose sight of any of your own goals. Flint is friends with Frank Miller and cited how Frank walked away from many a lucrative contract when he finally could afford to, in order to retreat to Virginia and work on his graphic novels. Now he's back into movies and doing better than ever, because he was able to stop chasing the money.

Make sure you realize and address your weaknesses. Not good at editing your own editor? Make sure you find a good editor to work with. Not good at selling yourself to get work? Hire an agent to take care of that for you. A lot of companies only work through agents anyways. Take classes to improve your writing in areas you feel you don't have a lot of confidence. Not good with the legalese? Hire a lawyer. Generally you should always consult a lawyer when dealing with contracts, especially when you first start out - but if you deal often enough, having one on tap is beneficial.

There are a few cardinal rules to keep in mind when writing:

• Never ever miss a deadline, either by simply failing to submit work on time or rushing and handing in work that is not up to par.
• Write every day. Whether you decided to write for a certain amount of time, a certain number of pages or a certain number of words, set a goal and stick to it.
• Have something deliverable each week - whether you wrote it all in a day or over the entire week, this is the only tangible progress you are able to show to a client.

Flint likes to capture ideas when he's away from his desk using an audio recorder - which he said used to look stupid but nowadays everyone's talking to themselves (thanks to cell phone headsets) so it's not so bad anymore :P He also makes sure to file away ideas for later. You should have a creative journal or notebook that has a bunch of plotlines and story drafts and outlines - don't toss away any ideas because they're all going to seem the same to you, but presenting them to someone else in the future may yield some more work.

Flint also likes to use templates, like a script layout or a novel outline, to quickly draft ideas and in a format that people will expect and be able to interpret.

Don't forget to keep developing your "soft skills", as Flint calls them, or your people skills: working/relating in a team or group. Flint says one of the most common traits that he finds among writers of his experience still active in the industry is that they are willing to do favors, many times for free, with the understanding that they will be repaid in kind eventually.

Flint described his workspace as simple - a laptop that traveled wherever he went (the proverbial hat you hang) a phone, Internet (although he does admit it can be more of a distraction than anything these days) and quiet space. He also like to shake up the environment to keep

Coverage by Drew Sikora

Wake Up and Smell the Metrics! A Rant on Metrics-Driven Development in Online Games

Larry Mellon (Virtual Worlds Consultant), Darius Kazemi (President, Orbus Gameworks)

If you don't know what metrics are, then you should refer to a talk last year by Darius at the Online Games Developer Conference. His slides contain copious notes and offer a great in-depth look into what metrics are and how they're useful to game development. If you don't want to take the time to read the slides, the short and skinny version is that metrics are data that you collect, collate and correlate from the game world. How many people are using this item? How many players know this player? How many players that know this player share this item with that player? As you can see, the queries can quickly become complicated and many levels deep into data pulled from a game. How do you know what data to pull? How do you use the data? What effect does this knowledge have on the development of your game?

These are all questions that metrics evangelists Darius and Larry are out to answer for people. Many companies these days that are using metrics are either using them incorrectly or poorly by not using the data to corroborate facts or simply not investing enough developer dollars into the proper tools needed to collect the data that would be useful to them. This is mainly because a lot of studio executives do not understand the need for a metrics system. All the more frustrating is the fact that metrics are being used to great effect in all other industries, including TV, cell phones, casinos... in fact back in 2000, John Boushy, Harrah's CIO stated "[implementing metrics tracking] is one of the best investments that we have ever made as a corporation and will prove to forge key new business strategies and opportunities in the future." What's even more flabbergasting is that by their very nature online games are built from databases - the infrastructure is already there! Companies like Harrah's have to spend extra millions of dollars to set up the infrastructure their metrics system relies on, whereas games merely need to build on top of existing databases.

Seeing that Darius and Larry have released the slides to this presentation, along with the notes they basically read word-for-word, I'm going to stop here and let you get more from the slides. Larry includes a number of examples with his work on The Sims Online that help drive home the usefulness of a proper metrics system, but one example I don't believe was included was from Darius when he was working on Dungeons & Dragons Online. He came across a group of designer arguing over this one item in the game that was being abused and throwing things out of balance, and they were trying to decide whether to just cut it or keep it but redesign it so they don't totally piss off the players who own it. Darius went back to his desk, pulled up that item's usage in the game along with the number of players who own it and found the numbers to be absurdly low. He came back to the group and told them and the lead designer said "argument over" and they cut the item out.

Coverage by Drew Sikora

It's Who You Get to Know

Darius Kazemi (President, Orbus Gameworks)

"It's not what you know, it's who you know." Sound familiar? Everyone hears this quote at some point in their lives, because it's so true. Once when I said it to my Grandfather during a conversation he came back at me with "it's not who you know, it's who knows you". That one gave me pause for a second. It's important to remember that networking goes both ways. Not only are you meeting people to gain contacts in the industry, the people you are meeting will also be adding you to their contacts.

Darius has used networking to his advantage since college. He read a book that included a passage about Linden Johnson, when he was just starting as a secretary for congressmen. In the dorm where the other page boys lived, his first day he took 4 showers, and the next morning brushed his teeth 5 times. He did this so he could meet with as many other page boys as possible and start to get ahead, which he said was the same as meeting as many people as possible. Then he went on to become president of the United States. Darius took this story to heart and spent three hour dinners in the college cafeteria during freshman year - by the time he was a sophomore he knew everyone in his class.

Where do you meet people?

The best place to meet with other game developers are conferences like GDC, or consumer shows like PAX. If you can't afford the cost of travel and passes, a more local option may be a chapter of the International Game Developers Association (IGDA). They have chapters all over the world in addition to many states and cities in the US. Darius' first job, with Turbine, was obtained through a Boston chapter member that he knew who offered him the QA position before it was even posted on the market. This is something that happens very, very often. In fact, the majority of game positions are filled without posting anything to the job market. If you attend a chapter meeting, don't bring your resume or accost people asking for jobs. Chat and be social, hand out your card and they'll see you're a student or freelancer.

If you don't have a local chapter in your area, start one! Alternatively you can leverage the web by creating a personal website or blog that you can use to attract people to you or your project. Also go out and find blogs of other game developers to read. Leaving insightful and helpful comments on their posts can bring attention to you as well, be sure to link back to your own blog if you have one. It's harder to distinguish yourself if a lot of people are posting as well, so be sure to appear knowledgeable and concise.

How to meet people?

When people are out at conferences, Darius finds that most of them chase after the luminaries, the well-known developers. The problem with this is that they're well known, which means everyone else will also be chasing a moment of their time, they're most likely not going to remember you (I've re-introduced myself to Warren Spector three times over the years - but who can blame the guy?) and they usually don't have a lot of time to talk. However, if you do manage to get some extended face time in a more informal setting, like perhaps knowing a friend at Maxis who knows Will Wright and invites you out to dinner with Will and several other Maxis employees - that's not an opportunity to pass up.

The best thing to do is get to know other attendees at a conference or chapter meeting, as there are tons of other developers with just as much game experience as Dave Perry but without the well-known persona. Also, there's no reason not to become friends with other students and industry hopefuls as well. You may think they don't have anything to offer you, but this short-term thinking is very bad. Eventually these people will also have industry positions, some maybe before you, and you can then turn to them for help in getting your own industry position.

Parties and other events can be awkward for people who aren't very out-going. If you're shy and at a social event, the first thing to do is find the person in the room who looks even more uncomfortable then you. Go over and try to strike up a conversation, they'll probably be surprised at first that someone is talking to them but are no doubt hoping someone will at the same time. Sometimes groups of people cluster in a loose circle that you can sort of edge into. It's perfectly acceptable to stand off and just listen, see who's a part of the conversation and what it's about. If you have something you can add that is beneficial to the discussion, do so. If the circle of people is tight and secluded, you can generally assume it's a private conversation.

If it's your turn to talk to someone, make sure you have a quick pitch about yourself - nothing longer than 10-15 seconds or 2-3 sentences - that describes who you are and what you do. Make sure you don't ramble on and give the other person or persons plenty of time and opportunity to talk about themselves as well.

At the end of the day many people (like me) like to go home and make notes on the business cards they collected as to who they met, where, why, and any other random facts. Darius liked to do something similar, but a bit more involved. He would write down in a notebook the person's info like name, title and company, where they met, how they met, and anything key things he could remember from their conversation, like whether they were married, about to publish a new product, had kids, looking for work, interested in a new tech coming out, etc. This also helped him to train his mind into remembering important things like names and titles.

One of the most important things Darius stressed is not to wait until you're ready to join the industry to go out and start meeting people. You want to have contacts in place already so that you can turn to them for help in getting your first job. Darius attended the GDC when he was still a sophomore in college, three years out from getting a job. When he graduated, his industry contacts helped with lots of advice in landing his first position.

Coverage by Drew Sikora

AGDC Image Gallery

Our humble abode at the Homestead Studios (photo by Drew Sikora)

My half-rack of ribs with fixins at the Ironworks Barbecue right outside the convention center. One hint: if you show up at noon, the line extends out the door. If you show up right when the place opens at 11, you'll get right in. As a bonus, the blackberry cobbler (pictured on the right) is right out of the oven and is still warm. Oooooh (photo by John Hattan)

Grant Skinner (gskinner.com) Graham Wihlidal (bioware) and Drew pose in front of Ironworks (photo by John Hattan)

Looking down one of the conference halls (photo by Drew Sikora)

The IGDA presence, reduced to a small booth area in a corner of the convention hall (photo by Drew Sikora)

Across from the sequestered IGDA area was the equally sequestered IGF showcase pavilion (photo by Drew Sikora)

Traffic did pick up a bit once the Expo opened, as the main doors were around the corner (photo by Drew Sikora)

Some shots from the only second-floor booth on the Expo floor (Photo by Drew Sikora)

Getting some spy shots of the GG booth. Hey GG, what's that running on a Mac? ;) (photo by Drew Sikora)

The lovely Deborah working the booth during a rare quiet moment (photo by Drew Sikora)

Crowds check out the Torque games on display (photo by Drew Sikora)

Roller derby chicks skating the Expo floor, checking unwary developers (photo by Drew Sikora)

Most comfortable with their own goofiness were the group from Frozen Codebase (http://www.frozencodebase.com). I still don't know what they were selling, but they certainly appeared to have fun selling it, what with roller derby girls giving away skateboards (photo by John Hattan)

RGNGames.com. They have some exciting things coming out for independent game developers. Keep an eye on 'em (photo by John Hattan)

The usual comfiness of the Intel networking lounge (photo by Drew Sikora)

BioWare outdoes Intel with bean bag chairs FTW (photo by Drew Sikora)

Interzone pwns them all with this nicely-design booth (photo by Drew Sikora)

C'mon, say it with me now: "something, something, something.... Darkstar" (photo by Drew Sikora)

Intel fights back tho with a cool LED-lit clear plastic case mod (photo by Drew Sikora)

The Baton Rouge Area Digital Industries Consortium (http://www.bradic.org) had the finest selection of freebies. While the USB plasma-sphere was cool, I felt that the mini USB hub (the silver Zippo-lighter looking thing) would've been more useful in the long run, so I took that (photo by John Hattan)

You can't see it in action, but the chair has a blue Cylon eye on the back of it under the Sparco tag (photo by Drew Sikora)

The UT Videogame Archive was a great idea, but their presentation could've been better. It took 'em most of a day to get their ancient pong-prototype (the wooden boxes at the base of the TV) connected to the TV. This gizmo was ancient even by pong standards, as it had no scoring or ability to control the ball's direction with the paddle.

Now look at those pong-paddles on the screen. Now that's what you call a pixel! You can barely even see pixels nowadays. Back in the heyday of pong, pixels were as big as your thumbnail!

Actually the archivist corrected me. Turns out that the paddles are 2x2 pixels. The ball itself (not pictured) was a single pixel (photo by John Hattan)

Can't come home without the swag! Those are candy cigarettes in the red box. Candy cigarettes!! (photo by Drew Sikora)