You're in luck people. I attended Brian Reynolds and Tim Train's lecture on their company, Big Huge Games, and walked away with a ton of good stuff, mainly because they had wonderful slides that listed few items per slide with much verbal elaboration, giving me time to copy down everything, bwaahahaha. I have two and a half pages of notes sitting in front of me here, so strap yourselves in, this is gonna be one helluva ride!

Brian Reynolds kicks things off

Brian Reynolds, the company President, began by talking about the company structure. The first point Brian made was that they weren't "biz guys" - they were developers through and through. So how the heck do non-biz guys start their own business? That was the focus of the lecture. Since they were developers, they had certain things in mind for their company:

• Stable/fun work environment - if you haven't already, check out their Behind the Scenes section on the website (BigHugeGames.com) for a look at what BHG developers get for digs.
• Creative independence - this definitely eases the mind and promises better workflow.
• Avoid administration hassles and financial risks - these aren't biz guys - remember that! As such they didn't want to get into economic entanglements, and didn't start BHG with the intent of putting all their money into one risky title after another.
• Direct payment of profits and royalties for successful games - they didn't want to end up in a contract deal that gave them royalties after so many months of sale or whatnot, they wanted dividends pronto

And then of course there were things they weren't so focused on:

• Growing the company
• Financial independence from publisher
• Building equity

Keep in mind that this is when the company first started out, and the founders were still looking to build a small games studio first. During the lecture they had some "Road Not Taken" slides showing various things that Big Huge Games chose not to do. The first Road Not Taken slide was about the company itself:

• Staff get stock options - instead of royalties and bonuses, the staff get company holdings.
• Income stays in the company - extra money made goes straight to the company to help build/grow it's financial value.
• Multiple publisher strategy - shopping games to various publishers and signing with more than one.
• Company growth - Financially speaking: reaching a level of self-funding.
• Promise/Goal of an "equity event" - in this case, either going public with an IPO, or selling the company.

• Motivate with royalties and bonuses, downplaying stock options - it's all about the royalties and bonuses, baby. You have to work hard for your money ;)
• Minimize financial risk by spending the publisher's money - heck that's what publishers are there for right? ;) I remember visiting their site about a year or two ago and reading about them pledging to do all this fun stuff - "anything we can justify to the publisher as an expense." Now that's cool.
• Growing and moving towards more publishing advances (exclusive).

Wow, these three things make BHG a kickass company? Almost. They made a lot of other really good decisions as well. To continue, Brian finally delved into something I'm sure he was saving till the end of his talk - the administrative side to everything. Remember, these aren't biz guys, and Brian remarked that when they first decided to start their own company, they spent countless hours thinking of all the management they would have to do. Ick. Here's what they had to worry about:

• Payroll, 401(k)
• Accounting, taxes
• Legal, incorporation, fees
• Health benefits

Now if you too are not a biz guy (I know I'm not) just looking at the above list can be daunting. Payrolls? Taxes? Legal stuff?? Ahhhh!!! Luckily, Reynolds and team soon realized that all of the above listed items could be contracted out to companies that set them up and then managed such administrative assets for them. This let them focus greatly on doing what they do best - make great games

Well hallelujah and let the bell ring. What else have they done? How about a partnership? Yes indeedy, Big Huge Games was founded by four developers, Tim Train, David Inscore, Jason Coleman and Brian Reynolds. Why go with a partnership? Good question! And that was the focus of their next slide, entitled "Road Not Taken: Solo ownership"

• Level of talent - according to Brian, they couldn't have attracted the same level of talent with one person.
• Higher commitment level - under a partnership, you have more reason to prove to the other partners that you are committed to the project.

Brian also had a lot more to say about partnerships, especially since one formed the foundation of Big Huge Games. He began by saying that a partnership should be treated as a marriage:

• Legally binding - as partners, you sign an agreement that lists what each partner gets out of the deal. You are tied to that agreement.
• Rights and responsibilities - as per the agreement, you'll have various rights and responsibilities to the company and your fellow partners.
• Can choose a bad partner - it can happen in marriage, and it can happen here too.

Fortunately for us, Brian was willing to share with us some tips for forming successful partnerships so that we don't have to worry about that third bullet point above:

• Shared vision - your partner(s) should want to make the same type and quality of game as you do.
• Commitment - your partner(s) should be willing to pay the same price as you.
• Friends - it's always good if you already know your partner(s) and have worked with him or them on previous titles.
• Complimentary skill sets - your partner(s) and you should fill each other's gaps nicely. This helps in:
  • Convincing publishers you can do the work and get the job done
  • Convince potential staff you can get funding (always a good thing ;)
  • Overcome "catch-22" situations, but by proceeding very slowly on all fronts

It's great that you can form a successful partnership, but you still have to maintain it, again, just like a marriage. Brian gave out some tips on that too. What a nice guy eh?

• Regular discussions - nothing can break apart a marriage faster than when a couple refuses to speak to one another. Having regular partner meetings helps keep everyone on the same page.
• All major decisions taken as a partnership - no one person should be making the calls in a partnership. Some of the things that should be unanimously decided upon are:
  • Finances - define major and minor decisions
  • Employee - hiring, firing, compensation, etc.
• No concept of "territory" - each and every partner should have an equal stake in the company, thus the notion of "territory" in relation to a person owning this or that, should not be present.
• Discuss issues of partnership or not at all - this goes back to the second point. If you aren't going to talk about thinks as partners, then forget about doing them all together. No one should be going over other's heads on anything.
• Review overall strategy once a year - as an expanded version of point one, an annual meeting is a great thing to have so you can make additions and revisions as a partnership.

Tim Train's turn to speak

After this, it was finally Tim's turn to speak - they gave themselves each 30 minutes to present their part of the lecture. So all this is only 30 minutes in. Great huh? Being the Producer, Tim spoke at length about the company culture as well on how Big Huge Games looks at publishing deals. He started off with BHG's "Guiding Principles":

• Aim for the absolute top
• Practice intellectual honesty
• Employees are everything

That looks like a good set of Golden Rules to me. After that we plunged into the company culture:

• Go all the way - I forget exactly what this was in reference to, but if their in-house entertainment is any example, then a pool table, ping-pong table, bar, game room and 80GB music server seem to fit the bill nicely.
• Selective hiring - the BHG hiring process is exhaustive. First comes the phone interview (I believe with Tim) then another phone interview with their specialist in the position you're applying for, then I think an interview with Tim, and maybe Brian, and then you are passed around to the rest team in groups of 2-3 who take you out to lunch and get to know you. In the end the team's opinion of you factors in just as greatly as what the directors think. *phew* :)
• Employee involvement at all levels - as an example, Tim talked about how artists circulate their work to every other artist for critique, so unit artists look at concept sketches, and concept sketcher look at unit drawings.
• Sensitivity to an employee's "fit" in BHG - this goes back to point two and why they have the interview process they do. There's nothing worse than spending money on a bad-apple who couldn't get along with the rest of the team.
• Employees are the lifeblood of the company.

"And we mean it!" said Tim with conviction to the last bullet point. I'm greatly inclined to believe him. Big Huge Games and publishing was the next topic, starting with what BHG looks for in a publisher:

• Amount of funding - it's always a good thing that the publisher can provide a steady stream of cash.
• Global reach - a publisher should have worldwide localizations, sales, and distribution.
• Marketing and advertising - this should be something the publisher can handle.
• Testing services - good publishers offer testing services, such as bug detection, compatibility testing, game balance, interface usability, and Internet/network playtesting.
• Online multiplayer services - basically a must for the majority of games today.
• Experience and success with genre - this is a dependant case point.

To satisfy all the above publishing requirements, Big Huge Games signed a deal with Microsoft for their first game, Rise of Nations. This filled in for the last bullet point - Microsoft is the publisher for Ensemble Studios, makers of the popular Age of Empires series, a strategy game, which is what Rise of Nations is. I wish I had the picture of Jason kissing Brian on the head during the signing of the publishing deal - that was funny. Anyways I'm down to the final half-page of notes so hang in there! Tim talked more about publishing, focusing in on Big Huge Game's best practices:

• Negotiate for higher royalty rate once product has "earned out."
• In multi-title deal, establish higher royalty rate for sequels to successful products.
• Avoid cross-collateralization.
• Make publisher responsible for worldwide trademark.

And to conclude it all, Tim spoke about publisher relationships:

• Publishers want to know you can execute vision - experience always helps people.
• Clear and testable deliverables - make sure you and the publisher know exactly what the deliverables are.
• Give publisher creative participation - this often leads to more support from the publisher in exchange for letting them get their hands deeper into the project. It's somewhat of a tradeoff, to be sure.
• Brace for bureaucracy with the publisher - sometimes it's simply unavoidable, so the best you can do is prepare for it.
• Spend time on tools and documentation - this is something that companies can overlook, and definitely eases relations when you can show a document to the publisher.
• TEAM software (made by Alexis) - this was a software management tool BHG discovered and has come to love. They recommend it. So go get it. Now. :P

For someone who's followed Big Huge Games on and off since their inception in 2000, I was pleased to see how far they've come since. Brian and Tim gave a great lecture, and it was a pleasure meeting them as well. I can't wait till Rise of Nations comes out. For more info, check out their website - www.bighugegames.com

After the show ended on Saturday, we went to dinner with the Ladies of Premier again. We went to this brewery a couple blocks from the convention center, which appeared to be the place to be, since there was a big group of people from BioWare, and other smaller groups from other companies. The food was excellent, and a good time was had by all.

L to R: Me, Alex, Emi, Mitzi, David Franson, Heather, Mason, TAN. Does this pose look at all familiar?	David and Heather, as we waited for over an hour for our table.
Emi and Mitzi	We're trying to get Premier to replace the "Blade" photo of André on the back of their books with this shot of TAN.

This morning I attended a roundtable on the standardization of AI interfaces. This was moderated by Alexander Nereyek, but also had short lectures from Brian Stout and Joe Toth. There may have been more but I had to leave the session early to attend another.

Alexander Nereyek, Brian Stout, and Joe Toth all gave brief lectures while I was there.

The focus for creating a standard AI interface was to

• Allow developers to focus on the creative tasks
• Enables rapid prototyping
• Creates reusable code
• Helps academia to focus on these tasks

The problems arose when discussion began and realizations became evident, such as the fact that AI interfaces could also hinder creativity and make companies reliant on 3rd party producers to supply the AI. It's also difficult to create a general library for all the various aspects found in AI. For example, pathfinding has unique applications for various problems. Some games actually have several different pathfinding algorithms for certain specific tasks in the game. How can you emulate that with a standard interface? Also, generalization will cause a hit in performance, because the AI routines will not be optimized for use in that particular game. This leads into specialization, which sums it all up rather nicely. Game AI is specialized for a given game. Developers usually toss the AI they had in their last game and totally rework it for their next one.

There's Steve at the far left, and from the right we have Steve Rabin (AI Wisdom) and Niel Kirby (Lucent Tech)	The Ferretman himself, front and center	Eric listens as Steve talks about AI standards

It was also noted that data-driven AI is ultimately the best step towards a standardization, since it allows the possibility of having a general A* routine, yet allow the developer to plug in specific algorithms to customize the routine. Some successes were noted, such as UnrealScript for bots, as well as a few homegrown AI libraries. There was also hope in the us of templates, libraries with specialized path planners, and the finding of standard routines that could be the base for a data-driven AI system. During the discussion, Steve Woodcock (gameai.com) threw in his two cents noting that we are still quite a long ways from any sort of standards, and that in order for us as AI programmer to get our own hardware to play with (AI cards… yummy) we need those standards in place first. After that we had a break, during which I snuck out to attend the Big Huge Games lecture.

Presenter: Andrew Leker

Andrew Leker's presentation was a delightfully straightforward talk about how to reduce the risks of game development by reducing the amount of unnecessary design complexity in our projects.

Beginning by painting design complexity as the "real" enemy of game development, the following steps were recommended:

1. Tell the truth with your goals.

Your goals should "disappoint you". After all, your goals are not a marketing list. In other words, game designers and developers should not buy into their own marketing statements. In our projects we cannot control the time to shipping or the money we're budgeted (within limits) and so we should focus on keeping the scope of our projects reasonable. "Don't build a house when a tent will do."

2. Our mistaken goal: "gameplay" is real.

Games are not supposed to simulate reality. Instead, they are supposed to entertain. Too often, developers get caught up trying to simulate reality when their focus should be on create entertaining games.

3. Design Collapse is good.

As a game design takes shape, it also "takes girth", become larger and more complex. And as a design becomes more complex it becomes more fragile, more easily broken. Designers should remove all but the most promising aspects of the design. "You might lose a month, but you might save a year."

[Reviewer's Note: There was, strangely, no mention of C. S. Lewis's old adage that "anything that doesn't contribute to a work of art detracts from it" (at least, I think it was Lewis, I'll have to look it up, I guess).]

4. Toss your failures.

We should be prepared to "trim savagely" at all times. Rather than wasting time (and therefore money) trying to patch an idea that isn't working, it should be triaged as soon as possible. Removing elements that aren't working can sometimes open up new possibilities that had not been considered prior to that.

5. Environment Design is a Priority.

It's important that the gameplay be "in play" as soon as possible. Too often, level design is put off until the end of the project as all work is focused on "the engine". So make use of the features that are available throughout the development cycle.

6. Pre-Production.

You should never leave pre-production until you're ready.

"Find your game in pre-production, then make it."

As it turns out, my last conference event was a roundtable called Learning From The Classics: a Discussion on What Made Games Great. Essentially, the roundtable talked about the retro games that everybody liked, and tried to find some common themes to extract and apply to the games we're making today.

The attendees were phenomenal. I walked into the room a little skeptical - surely such a topic would draw lots of young, overinflated egos, eager to insist that their favorite childhood game was the best, because "it was cool." However, I was thrilled when I learned that most of the attendees were professional game designers, and some might even be considered legendary. To hear these people speak about what made classic games great was the highlight of the conference for me.

Add to this the excellent moderator, Alex Neuse. Not only were his questions insightful, and his knowledge of retro games deep, but he also did a supurb job ensuring that everyone got a chance to speak, that we stayed on topic, and that we didn't spend too much time on any one topic.

It's been my experience that most of the roundtables at the GDC don't really work. Now I know that when the right moderator and the right attendees come together, they work amazingly well.

Mason McCuskey
Spin Studios
www.spin-studios.com

"Avatars Online" is an insightful, humorous, and sometimes touching documentary of the phenomenon of massively multi-player online games (MMOG).

"Avatars Online" covers Ultima Online, EverQuest, Dark Age of Camelot, and Lineage. The film features interviews with Richard Garriot, Raph Koster, and others from the game development industry as well as game players and "on the street" interviews with "regular" people. There were even interviews with psychology professionals.

Topics covered were the growth of the MMOG market after the release of Ultima Online, the development of friendships and other relationships among the players, and even whether these games were "addicting" or not.

Overall, "Avatars Online" was an enjoyable documentary of this latest trend in games, and how those games are affecting society.

This morning I attended a talk on Startup Horror Stories, by Tim Morten, Chacko Sonny, and John Lafleur. These guys run or just recently used to work for a start-up called Savage.

A presentation on the failures of game development startups isn't pleasant, but it's useful. All three of these guys were eloquent public speaker, and the talk flowed smoothly, with nary an "um" or break in thought. I was really impressed with the speakers' abilities to speak candidly about their experience.

Here are the stories the speakers presented:

Big Promises. Essentially, a former publishing big-wig recruits members from a star development team for a new start-up with himself at the helm. He promised to close funding rapidly, and promised the team an even distribution of equity in the company. He also represented to the publisher that his team was capable of timely delivery.

This turned into a "Big Disappointment." The deal closure dragged on and on, the team never saw any equity in the company, the development milestones whooshed by, and the deal was lost and the company dispersed.

The lessons to learn from this are obvious: question promises made to you. For example, a typicaly development deal takes between 9-12 months, so be wary if someone says they can do one in 2. Always take timeframes the publisher gives you and multiply it by two or three to get the real date.

Also, don't promise what you can't deliver - often in a quest to make the publisher happy the startup shot will say yes to things they can't possibly do, setting themselves up for failure later. Communicate accurately to the publishers about the capabilities of your team.

The Perfect Partner. In this horror story, a star programmer teamed up with the designer of one of the most popular games of all time. They managed to sign a great royalty rate with an excellent publisher.

But, the designer had a drug problem, and the whole thing came crashing down when he was sent to jail for substance abuse issues (oops). The remaining partner was forced to assume the entire burden of leadership, and the team's relationship with their publisher deteriorated until finally the project was cancelled and the company was dead.

The lessons the speakers presented were to know your partners and co-workers. It's very difficult to determine from how someone works in a corporate environment how they really behave. Watch out for red flags and be prepared with a cotengency plan in case one of your partners bails (or can't post bail).

The Passion Project. A successful team spins off from a major development house to pursue their dream project. They come up with an ambitious design and secure a publisher.

Unfortuatenly, their creative vision was their downfall - by refusing to accommodate their publisher's requests for changes, they ruined their relationship, and the publisher was reluctant to market the game properly. This became a self-fulfilling prophecy: a game that isn't marketed usually won't sell well. Consequently, not only did the team's original publisher not want to work with them on another title, but other publishers looked at the dismal sales of their first product and also walked away. So much for that company.

The lesson here is obviously to concede to some creative input from your publisher. The truth is that most publishers really DO know what will make your game sell more copies. They have marketing depts and focus groups, and you can benefit from their knowledge.

A second lesson is to not wait until your first game has already been out for awhile to start courting publishers for your second title. In the example above, these guys might have had a chance if they approached a different publisher before anyone knew that their product was selling badly.

The Dream Contract. Here, a less-experienced developer signed a great deal for a major franchise - a success against astronomical odds. Since this was their first major gig, they greed to a conservative design and a tight schedule.

This turned into "The Impossible Dream." The publisher had unrealistic expectations of what could be done in the specified timeframe, and since the IP was choice, the publisher was constantly monitoring this team's progress. The team missed some key technology milestones, and the project was cancelled by the publisher.

The take away here hits the same chord as the other lessons: don't promise what you can't deliver. Also, communicate with your publisher regularly.

For anyone who wants to join a start-up or is planning to start one themselves, you should definitely check out the slides that will soon be posted on the speaker's web site..

Mason McCuskey
Spin Studios
www.spin-studios.com