Big Huge Games: A Year (Or Two) In the Life of a Startup posted 4/1 at 5:34:52 PM PST by Gaiiden
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, 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:
And then of course there were things they weren't so focused on:
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:
The above list is all the things BHG decided not to include in its company strategy, which Brian explained next in his "Big Huge Strategies" slide:
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:
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"
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:
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:
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?
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":
That looks like a good set of Golden Rules to me. After that we plunged into the company culture:
"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:
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:
And to conclude it all, Tim spoke about publisher relationships:
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
The After Party posted 4/1 at 9:52:10 AM PST by Dave Astle
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.
Towards AI Standards posted 3/27 at 5:40:33 PM PST by Gaiiden
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.
The focus for creating a standard AI interface was to
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.
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.
Complexity Demons posted 3/25 at 3:18:51 PM PST by DavidRM
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.
You should never leave pre-production until you're ready.
"Find your game in pre-production, then make it."
Learning From The Classics: a Discussion on What Made Games posted 3/25 at 1:59:31 PM PST by Mason McCuskey
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.
Avatars Online posted 3/23 at 3:01:58 PM PST by DavidRM
"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.
Startup Horror Stories posted 3/23 at 11:15:24 AM PST by Mason McCuskey
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..