Presenters: Tom Barnet-Lamb and Richard Evans

In an attempt to bring both depth and breadth to AI in games, Tom Barnet-Lamb and Richard Evans presented a (IP lawyer sanitized) version of a new technique they have created.

"Depth" refers to how autonomous the individual game AI agents are (as opposed to how autonomous they *appear*), while "breadth" refers to how wide a range of actions and reactions the agents have at their disposal. Though many games to date seem to be either deep or broad, these games are seldom, if ever, both deep *and* broad. This technique attempts to remedy that.

The basis for the technique are "social processes". In simple terms, a social process is a persistant process that provides a framework for organizing knowledge. A social process comes into existance when two or more "people" are in a particular context with particular beliefs. For example, a wedding ceremony is a social process. Within the context of the wedding, each participant has accepted and expected roles. The context of the wedding also dictates behaviors, such as giving away the bride, reciting vows, and kissing the bride.

Another example is the reaction of a crowd at a sporting event. When a point is scored, the fans get excited and perform various antics. These antics, which would not normally occur (such as screaming, shouting and jumping up and down) are acceptable and even expected inside the social context of the stadium.

Social processes are implemented as a finite state machine (FSM). When an AI agent needs to choose an action, he will review the currently active social processes and evaluate possible actions within those social processes. Based on the agents current goals and desires, an action will then be chosen.

Social processes, in other words, remove the "burden of thought" from the individual AI agents. The agents are then able to use their current social context as a cue for what their next action should be (or should not be).

Roundtable host: Darrel Porcher
IGDA Roundtable

I wasn't sure what to expect when I attended this roundtable. However, I was impressed by the level of civility displayed in discussing what can be a very contentious subject.

Racial stereotypes were discussed, particularly in relation to "Ready to Rumble" and its extreme racial stereotypes such as "Afro Thunder". Some people considered "Afro Thunder" to be such an absurd, extreme stereotype that it was harmless, even humorous. To others the character was quite offensive. Similarly with a character in "Final Fantasy VII".

A good portion of the roundtable was devoted to ways to encourage more young people of color to become involved in the game development industry. Giving back to the community you came from was seen as the most effective method.

Roundtable host: Ellen Beeman
IGDA Roundtable

Though I was the only man in the room for a while, by the end of the roundtable, as many as 5 men had joined the more than 30 women in the discussion.

The roundtable discussion focused on what it is (and was) like as a woman working in this male-dominated industry. Though there were a few "horror stories" of mistreatment and inappropriate behavior and comments from male co-workers, the overall focus of the roundtable was more positive than negative.

The importance of mentors was discussed, as everyone in the industry it seems, male or female, came into the industry via someone they know who was already in. So all in attendance were encouraged to be a mentor to girls who were interested in the game development industry, and not just passively.

For more information:
http://www.igda.org/women

Roundtable host: Francois Dominic Laramee

The initial discussion concerned perceived effects of either the economic recession of 2001, or the events of 9/11 on the freelance segment of the industry. Overall, the people in attendance seemed to think that the recession had more effect on their business, with 9/11 causing a temporary change (sometimes up, sometimes down). A European-based developer indicated that available work in Europe had actually increased in the same time period.

Freelancing has grown in recent years, with more people setting up shop on their own. This increase in competition however all means there is more work for everyone. It was noted that there seemed to be more oppurtunities for entire projects than piece work, particularly for programmers.

When asked why they were freelancers, the primary reasons given were: control of which projects they work on, payment for their work regardless of the fate of the overall project, and choice of where to live.

Freelancers marketed themselves in various ways, but the single most important technique was networking--leveraging who you know. Producers represent the best group of industry people "to know" in this regard. Speaking engagements, writing articles, and other tactics to increase name recognition and exposure were also used.

Presenter: Steve Reid, Red Storm Entertainment

Steve Reid shared his method of providing art direction, based on his experience as art director for Red Storm Entertainment. As an art director, he says, you are no longer able to focus only on art. "It's not just about color" anymore. An art director must learn such management skills as scheduling, team building, public speaking, and time management.

One of the most important tasks of the art director is to provide regular, constructive critiques of the work of all artists under him. These critiques can be public or private, depending on the circumstances, but must be consistently handled for all artists. Obviously, not every one likes to give or receive criticism, so the art director must work on his communication and management skills.

The art director is responsible to the company to control the creative output of the artists, but, at the same time, he must also respect the desires of the artists for creative freedom. Regular critiques allow the art director to be aware of how the artists are doing, as well as give artist much need direction for creating content proper to the current project.

Some tips for critiquing:

• Understand that everyone is different, and responds to criticism differently, so tailor the critique to the artist (within reason).
• Show and tell the artist how to improve the image.
• Include a "shopping list" of possible changes so the artist is involved in the process.
• Don't waste time gilding lillies that the player will never notice or even see.

After attending many programming courses over the last few years, I decided it was time to branch out and cover some other interesting topics, so I went to Dustin Browder's talk on Real Time Strategy Balance and Design.

Dustin was the lead designer on Red Alert 2, Red Alert 2: Yuri's Revenge, Heavy Gear, and Mechwarrior 2: Mercenaries, and his expertise in his subject is obvious. I had high hopes for this talk, and for the most part, it lived up to my expectataions.

The talk started by stressing the importance of balance, and the two main game balance paradigm. On one hand, there's the "Opposed Ideology" design of games like Command and Conquer, where there are exactly two forces (i.e., GDI and NOD). The weaknesses of one force are the strengths of another, and vice versa.

On the other hand, there's the "mirrored abilities" approach to RTS balance. Mirrored abilities works well where you have several different forces (or races), like in StarCraft. The essence of mirrored abilities design dictates that each race contain a core set of units which are practically equal to one another (though they make take on different appearances or be "tinted" towards the particular traits of each force). That is, every race in StarCraft has essentially the same unit types, even though they are somewhat camoflauged.

Next, Dustin spent some time talking about the technical process of balancing a game, on a unit-by-unit basis. He stressed the importance of having well defined, well-communicated unit types. A player should know by looking at, hearing, and reading the description of a unit how powerful it is and what its strengths are. For example, a name like "Apocolypse Tank," combined with an image of a super-strong tank and heavy sound effects, leaves no doubt in the player's mind that the tank they've just constructed means serious business. Conversely, a unit with a vague name "Assault Tank," a vague image, and stock sound effects does not clearly convey to the player what its particular strengths and weaknesses are, and what it should be used for - the player is left wondering, and the result is a game hampered by bad design.

He also pointed out a common rookie designer's mistake: assuming that all unit interactions matter. That is, assuming that every single unit must be perfectly balanced when faced with every other unit. In practice, Dustin asserted, this is overkill and makes the game design problem insolvably complex. A better method would be to concentrate on the most common and most important unit interactions - if a large part of a game involves Tanks facing off against Infantry, then concentrate on that interaction, and don't worry about the interaction between one obscure unit and another.

Another important thing to keep in mind is the "combat chain," or arms race. That is: player 1 builds weapon X, so player 2 in response builds weapon x+1, which causes player 1 to build x+2, and so on. Left unchecked, combat chains break, ultimately culminating in one "super unit" which has no defense. A better design strategy is to have the combat chain circle back on itself, as in the classic Rock/Paper/Scissors game. Rock beats scissors, scissors beats paper, and paper beats rock - it's a complete circle. Circular dependencies like this are common in RTS games because they enable deep strategies to take place. Of course, the disadvantage is that a player may not always know immediately the defense unit for a given attack unit. It's easy to deduce that "bigger rock" beats "smaller rock," but not so easy to deduce that paper beats rock.

You also need to pay attention to the maximum unit count. Say a certain powerful unit is defeated by four less-powerful units. In a game without a maximum unit count, everything's fine, but if you cap the unit counts for each player at (say) 50 units, and a player builds 40 strong units, another player would need 160 less-powerful units, wouldn't be able to do that, and would lose due to a lack of game balance.

Dustin also stressed the importance of early and often play testing, preferably using people who knew the game inside and out and who didn't have so much of an ego that they couldn't say things like "I won, but I won unfairly, and here's why." Having a team of good play testers is critical to shipping a good RTS game. Get them however you can - make your team your testers, recruit them from the internet, do anything - just make sure you have them.

All in all this was a good, in-depth, and well focused lecture. Dustin started with a good introduction to the subject, then moved quickly to advanced techniques that RTS game designers could actually USE. Good stuff!

Mason McCuskey
Spin Studios
www.spin-studios.com

This is one of the round tables I try to attend every year. Basically, a whole bunch of independent game developers (with different success levels) all gather round and talk about what problems they've faced and what techniques they've found useful.

This year's roundtable was moderated by Kent Quirk, who runs Cognitoy, makers of MindRover. Kent moderated the roundtable well, ensuring that the conversation was never dominated by one or two people, and that we touched on a variety of topics.

The biggest topic was on how to find and hire subcontractors (artists, musicians, and even developers). We discussed how we've found our development partners (often by serendipity - an old high school friend or a contact made by chance at a previous GDC), and what techniques we've used to make sure that the stuff they developed fit into our vision for our game.

A common problem for most independent game developers seems to be a lack of preparation. All to frequently an indie will hire an artist without having a complete design document. This leads to wasted time and wasted money, as content is frequently discarded as the spirit of the game comes into focus. One of the things you can do to greatly increase your chances of having a smooth development cycle is to plan, plan, plan - get your design doc complete before you start recruiting artists, and get your script complete before you hire voice talent.

The second portion of the talk was all about dealing with publishers. Kent spoke freely from his own experience, which was very valuable to indies who had never tried to self-publish a boxed game. He conveyed that retail was a tough market to be in, and explained that often times retailers' accounting methods left the developer seeing very little (or no) money.

Several people also commented on the difficulty of approaching a publisher or a venture captialist. In short, when it comes to publishers negotiating with independent, unproven developers, the publishers hold all the cards - it's the developer that's bearing the most risk. Venture captial, on the other hand, is almost impossible to get nowadays - most VC firms want a "sure thing," and trying to determine if even a well designed game with excellent IP will sell predictably is difficult.

In general, this was a great discussion for independent developers, and a great chance to meet some of your peers if you're in the independent development community. I hope the GDC organizers continue this, and I hope that if you find yourself trying to get a game published, and able to go to the GDC, you save an hour for this discussion.

Mason McCuskey
Spin Studios
www.spin-studios.com

This year, the first talk I went to was Sue Bohle's lecture, "How to Get Positive Coverage for Your Company."This was definitely off the beaten path for me - in the past I have concentrated on the programming track, so it was neat to start this year with a business and legal tidbit.

It was a good talk, and presented several practical techniques for getting your game reported by web sites and print media.  Sue Bohle has more than 30 years of public relations experience, and her experience enabled her to create a lecture that explained the basics of dealing with reporters and PR in general.

Here were some of the more useful gems:

• Never send unsolicited games.  Send an email to your contact first, explaining the game (keep it short) and asking if they'd like to see it.  Only send it if they say yes.
• Hands on demos are best.  If you can travel to the reviewer or previewer's office and show the game in person, do so.
• Exclusive content (screenshots, art, etc.) is generally a good thing.
• Covers are very tough to get.  You need a solid license and a major publisher, and need to arrange things 6-8 months in advance.
• A good rule of thumb is to try to get your game mentioned at least once a month or once every two months.  In the early phases, release early screenshots or interviews with developers explaining how your game rocks.  In later phases, submit news bites and exclusive content, along with demo CDs and other pack-ins, like posters.
• Always be familiar with the publication of the editor or reviewer you're trying to get to look at your game.  Make your pitches personal, keep them short, and concentrate on what makes your game unique.  A clever sound-bite sentence like "Our game is the 900 lb gorilla of RTS games," can go a long way.
• Always prepare for an interview.  Never let an editor interview you if you haven't had at least some time to think about what they might ask and how you might respond.
• When interviewing, keep your answers brief, repeat the question they've asked, don't respond right away, and most importantly: SLOW DOWN.  You get yourself in trouble by responding quickly and droning on and on.  Also, pace your speech so that the reporter has time to write down what you're saying!
• If you don't know the answer to something, say so.  Never lie or try to answer it on the fly.  Hand it off to someone on your team - "I don't know, but I'm going to have Bob look at that and get back to you."
• If you don't want to answer a question, you don't have to, but don't be rude about it.  Never just say "No Comment."  Explain to the reporter why you're not answering their question.  "I'm sorry, but I can't tell you that because it might give our competitors insight into what we're doing."
• If you get a really nasty question, cut it off immediately and definitively - "No, I don't agree."  Then bridge back to your main point.
• Avoid "selling" the reporter.  Reporters are put off by hype and sales pitches.  Instead, try to explain and educate them on your title.

  There were some other tips as well, but I didn't include these since they focused on TV interviews and other things not really common for an independent developer.  In summary, this was a talk full of useful information, and something I think any serious independent gamer should pay attention to.

  Mason McCuskey
  Spin Studios
  www.spin-studios.com

After starting with a non-programming talk, I was happy to attend my first hardcore programming lecture. Jeff Landers, God among programmers, spent an hour explaining how to create realistic fluid movement. Thankfully, this was not a talk about how to render water - Jeff concentrated on the physics of making water move realistically. Since we all know that Jeff's a great speaker and knowledgable presenter, I'm going to skip the review of the speech and just do a quick technical recap.

Jeff began the presentation by talking about the scientific way to simulate water, using the Navier-Stokes equations. If you haven't heard of them before, Jeff likened the Navier-Stokes equations to the F=ma equation we all know and love. They're the foundation of virtually all fluid simulation.

Jeff explained one method (the Cell and Marker method) for extracting realistic water out of the Navier-Stokes equations directly. I'm not doing it justice here, but essentially Cell and Marker divides the fluid into a grid, and then calulcates the pressure for each cell, as well as the velocities for each edge of each cell in the grid. Using this information, it's possible not only to render realistic water, but also to place objects on the surface of the water and have them move along with the fluid's flow.

Unfortunately, Cell and Marker isn't really suitable for games, because the process of calculating pressures and edge velocities can be really slow. You may have to iteratate over the entire grid several times each frame in order to get correct pressure calculations.

So, after a brief detour into some other water hacks based on Navier-Stokes equations, Jeff started explaining how to take Cell and Marker and boil it down into something that can be used in a game. He started explaining how 2D Navier-Stokes equations allow you to incorporate realisitic (and 3D!) lakes and rivers into your game.

Again, the 30-second summary: 2D Navier-Stokes sacrifice some functionality in exchange for fast processing. If you don't need a perfect representation of the entire volume of water, you can pretend your body of water is 2D, by making each cell in your water grid represent a vertical "box" of water. You also make some other sacrifices during the calculation stage, which are detailed in Jeff's sample, and help to bring the simulation into a decent frame rate.

I strongly encourage those of you who require realistic bodies of water in your game to check out the detailed examples and descriptions on Jeff's website, . The technique works great, and when combined with some clever pixel shading and bump mapping, can create some truly incredible looking water. It's also possible to place objects on the surface of the water and have them move realisitically, and interaction between the ground and the water looks great.

Overall, this was a great talk, but then again I could have told you that just by knowing Jeff Landers was the presenter. "Taming a Wild River" was both a good survey of different water techniques, as well as a detailed discussion on how you can use one specific technique in one specific circumstance.

Mason McCuskey
Spin Studios
www.spin-studios.com

I bumped into Dave Mark again in a Rookie Studios roundtable moderated by Kent Quirk of Cognitoy, which I won't bother posting about because by that time sleep had begun to catch up to me and I was nodding off quite frequently. So I basically remember very little. Anyways we both attended the "AI in Strategy Games" roundtable together, which turned out rather well. It was moderated by Denis Papp, and was packed full of people - they had to open the doors because the room was getting so hot. Discussion wound its way through various topics, including talks about how the AI worked in Shogun, which Denis was lead programmer for, formations, influence mapping, and difficulty, among others. For the Shogun AI, Denis started listing the steps it took to make decisions:

• Analyze the map for resources, chokepoints, etc
• Identify goals
  • Attack
  • Defend
  • Explore
  • Build
  • Recruit
  • …
• Analyze resources
• Solve any resource allocation problems, sometimes using a heuristics model to match resources to goals.

A couple of other points were brought up during the discussions:

• AI can be good when deterministic in order to aid in debugging since it produces predictable and similar results in order to make it easier to recreate bugs.
• AI vs. AI is good for finding bugs in gameplay mechanics

Denis Papp

It was also cool when a guy from Blizzard began speaking up a lot about the way StarCraft uses these various techniques in its AI. For example he told how the games uses influence maps in order to find chokepoints, and then it also uses the maps to help in the unit pathfinding, so there is sort of a two-level pathfinding architecture, first the influence map is calculated then the A* algorithm comes into play after a general route has be chosen with the influence map. I meant to talk to him after the roundtable by I didn't get to him first and didn't have time to wait in line to chit chat, unfortunately.

The Blizzard dude in the center, with Dave Mark in the foreground

Formations were also discussed, but not really so much in the light of flocking. Denis gave one example of the formations in Shogun where if for some reason a unit gets thrown off the path (due to an obstacle or something) and has to rejoin the group, they actually let the unit travel faster than normal to catch up rather than have it calculate where it has to be at a certain time in order to rejoin the group at its current rate of travel. This is a good example of how game developers "cheat" on their AI.

Difficulty was also talked about, like how to scale the AI in order to keep it challenging to the player while at the same time making it a fun experience. Difficulty levels is, of course, the obvious solution, I gave out the suggestion of rubberbanding that I got from the AI tutorial on Tuesday, which one developer said was always "annoying" to him. Rubberbanding is when if you're doing good, the AI challenges you, but if you're doing bad, the AI seems to crash or fall a lot more often - this is best used in racing games. We also talked about making and AI challenging but still letting the player win and feel he has accomplished something.

This roundtable is supposed to be an ongoing thing, meeting each day at a different time, but I won't be able to hit the other two, unfortunately. I walked away from this one with a much better idea on implementing certain techniques however. There were also some noted atendees:

Steve Woodcock (ferretman) in the center	Eric Dybsand (sic), AKA Geta, in the center

In the morning, I attended Ernest Adams' lecture, entitled "Why We Shouldn't Make Games". As usual, Adams (complete with trademark top hat) delivered a thought provoking lecture. The topic wasn't really why we should not be making games, but rather why we should not allow (and cause) ourselves to be pidgeon-holed into the "You Make Games, and Thus Aren't Really Doing Something Serious" type of category. Essentially, the gist of Adams' lecture was that we should break out of the stereotype that we have created for ourselves, especially if we wish to develop as an art form. One of my favorite comments he made was that musicians, if limited to only using 4/4 time would never have invented jazz, and the same sort of thing goes for the Interactive Entertainment industry. If we continue to see ourselves and allow ourselves to be seen simply as "Game Developers", we will continue to be lumped in with people who make toys, and toys are not considered important.

(click to enlarge)

3DLabs sponsored a session to go over their proposal for OpenGL 2.0. If you haven't already read the whitepaper (available on their website, or at OpenGL.org), here are some of the main things that they are suggesting:

• A common, high-level programmable shader language. Vertex, fragment, and image format programmability are desired.
• Because of the standardization of programmability, much of core OpenGL could be depricated (in fact, they're suggesting that a "pure" OpenGL 2 could evolve, in addition to standard OpenGL 2, which would not maintain backward compatability).
• Many extensions, which aren't made obsolete by the programmability changes, would be made part of the core.

For details, be sure to check the whitepaper.

My morning consisted of waking up after a 3 hour nap and arriving at the conference at 8:30, where I grabbed some breakfast and headed over to the Hilton to attend "A Beginners Guide: The Building of a Game Industry Professional." This was a session run by David Weinstein and John Feil targeted towards the student and enthusiast looking to get into the industry. The session didn't present anything new to me in general, but I did walk away with these great points:

• Take any job you can get. Even if you want to be a programmer or artist and get offered a Q&A job, take it. A lot of companies hire out of their Q&A departments so more than likely after a few months of showing your enthusiasm you will be recognized.
• ~80% of jobs available aren't listed. This is an important point. Don't be afraid to ask developers what they need or send your resume out. You may hit a developer who says "Hey! We need a guy like that!"
• Write plug-ins. Writing plug-ins for 3DSMax, Maya, Photoshop, etc is a great way to display skill. Most entry-level programmers are assigned tools to develop, so showing you can do plug-ins is a plus.
• Finish the game. Let's be perfectly clear about one thing: there are people making games, and there are people finishing games. Everyone who wants to be a game developer starts a game, few ever finish. No matter how crappy or simple it may look - a fun, playable game will set you light years ahead of the pack.
• What's "entry-level"? If you have shipped at least one commercial title, you are not an entry-level anything.