Well here's the usual shot of the convention center's main entrance. It doesn't look all that different from last year, but that's just because you can't see all the construction that's going on just to the left of the picture. It seems they're adding a new hotel to the convention center on the side opposite the Hilton, and at the same time they're expanding the convention center as well. Looks like we might have more space when we come back next year... although since I come back to find most of the construction I saw last year around the city still ongoing... well, we'll see.

Today I attended the first day of the Game Design Workshop, which is run by Rob Fermier, Austin Grossman, Robin Hunicke, Marc LeBlanc, Frank Lantz, Katie Salen, Tim Stellmach, and Art Min. Marc basically ran the first part of the show as he introduced everyone in the packed room to the ideals of game design.

Basically, Marc broke down the process of which a game comes across to the player as the MDA framework. MDA is an acronym which stands for Mechanics, Dynamics, and Aesthetics. The diagram below shows how each process drives the next.

As you can see, the process starts from the designer coming up with the Mechanics, or rules, of the game. The Mechanics then go into affect and produce Dynamics, which are emergent effects of the Mechanics. The Dynamics then translate into the Aesthetics which are perceived by the player. This is better defined as follows:

Mechanics - the rules and concepts that formally specify the game-as-system
Dynamics - the run-time behaviour of the game-as-system
Aesthetics - the desirable emotional response evoked by the game dynamics

Next, Marc moved on to the topic of making games "fun" by combining a number of aesthetic goals. He listed eight of his own as example:

1. Sensation - here the player gets some sort of satisfaction or maybe evil glee or some sort of sensual feedback through the gameplay
2. Fantasy - the game setting is make-believe and sends the player off to a galaxy far, far away
3. Narrative - the game presents drama in the form of rising tensions, climax and conflict
4. Challenge - the game includes obstacles such as objects, puzzles, bosses, etc
5. Fellowship - the game encourages player interaction and/or teamwork to accomplish tasks
6. Discovery - the game provides uncharted territory in which the player must explore, or maybe a partial tech-tree the user has to expand
7. Expression - the game gives the player some way to express herself, such as customizable game characters
8. Masochism - here the player simply succumbs to the game mechanics and lets them take him along for the ride

After this we went over the idea of aesthetic models, or models that describe how we can accomplish our set aesthetic goals. Several examples he gave were:

Goal: Challenge
Model: challenging games provide the player with difficult but tractable problems. Players are rewarded for success; more difficult challenges yield greater rewards.
Failure modes: problems are trivial, or too hard; rewards don't match difficulty

Goal: Competition
Model: a game is competitive if some players are adversaries (victory is mutually exclusive) and players have an ongoing emotional investment in defeating each other.
Failure modes: some players think they can't win; players can't assess who is winning

As you can see, these models are very useful for looking at a game and determining whether or not the game is acheiving the type of aesthetic you want the game to express. It's also a good idea to model each aesthetic seperately rather than try to create a whole unifying theory for the game aesthetic, since Marc insists that there is none (and I'm inclined to agree). So looking at the examples above we see that each goal is accompanied by its own model - the model describes the situation in which the goal is acheived. If the game plays according to the model, then we have succeeded. However we also must list states that define the failure of a model. If the game plays and happens to match any of those states, then it's time to go back and rethink the way things are being done. Aesthetic models are an important part of the early design process since they will keep you on track as you design, produce, and play test the game. In addition, Marc provided three properties that make up good models:

1. it is formal; rigorously defined
2. it is abstract; widely applicable
3. it is proven; known to work

In addition to aesthetic models Marc also discussed dynamic models. Dynamic models are important because you can use them to help predict the system dynamics of a game. For example if our game has a non-renewable resource, then we can predict certain behaviors in our game systems:

• A non-renewable resource will eventually be totally depleted
• If our game has a non-renewable resource whose depletion ends the game:
  1. We know that the game will eventually end
  2. We can use estimates of the depletion rate to predict the length of the game
• A non-renewable resource cab create a sense of forward-progress ("inevitability") necessary for drama

Real-time strategy games are a good example of games that make use of dynamic modeling. The various interactions between game units is a dynamic model, and helps the designer balance the game as it is playtested.

Marc wrapped up by moving on to the tuning process, an iterative process by which the game is reviewed and refined until it satisfies all its aesthetic goals and dynamic models. The process is shown in the diagram below:

Here you can see the iteration and the evaluation that goes on with each cycle of the tuning process. It;s very important that when you tune you game that you do not get distracted by problems in the process. Note that the Analyze and Revise bubbles come after the Test bubble - they aren't inside it. This was something we learned quickly as a group in the next part of the tutorial. As we tested our game concept we kept wanting to fix the problems right then and there rather than play through and finish the game. This led to endless on-the-spot tuning that really got us no where since we lost the big picture along the way.

Marc also provided us with a list of how MDA models are used in tuning:

• Aesthetic models
  • articulate goals
  • point out flaws
  • measure progress
• Dynamic models
  • pinpoint problems
• Both
  • evaluate possible revisions

After Marc had finished his lecture we broke up into three seperate rooms. Each room was doing the same thing it was just that we needed groups of size and one room wouldn't have held enough tables for all the groups we had total. Our first excersise as a group of six at a table was to play the game SiSSYFiGHT 3000. This game is a slimmed down version of SiSSYFiGHT 2000, a game designed by Eric Zimmerman (gameLab) and available online at www.sissyfight.com. What is it you ask? It's a game that simulates a schoolyard fight between little girls. Talk about extreme role playing. The rules are fairly simple: Each girl starts out with 10 Self-Esteem chips and the goal of the game is to reduce your opponent's self-esteem to zero. The game is won when one or two players remain in the game. The game is played by each player assigning himself a color via cards that were given out with the tutorial packet. Once everyone has a color each player chooses a color and an Action card in secret. The color card targets a player and the Action card describes what is to be done to that player. People can solo attack a player to make him loose one Self-Esteem, or team up with other players with team attack and make that player lose two Self-Esteem for each attack. Alternatively a player can defend against an attack, but if no attack comes he loses a chip. To make things even better, all conniving must be spoken aloud, meaning if you want to gang up on someone you have to tell everyone else at the table "hey guys, let's all gang up on Red and knock him outta the game!".

It was fun playing the game and afterwards we were led through a breakdown of the game's MDA. When the room was asked what aesthetics the game represented, some of the answers were:

• Fantasy - you're a little girl
• Fellowship - you can team up to work together since two players can win together
• Challenge - persisting in the game; not losing all your Self-Esteem

After we discussed the dynamics of the game a little more, we were turned loose to develop our own game based around (or loosly around, in my group's case) the SiSSYFiGHT concept. After brainstorming around the table we had several promising ideas:

• Shiv - you're a prison inmate with a lot of angst and the urge to shiv (stab fellow inmates). You have to collect and trade resources (which we represented by suites of a deck of cards) to buy the shiv (we used a plastic knife from lunch as a prop) and then when lunchtime came around every two rounds the person with the shiv could stab someone and take him out of the game.
• Pimp Daddy - you have two chip piles, life force and your collection of ho's. That's about as far as we got :P
• Cattle Rustler - you had to collect chips (cattle) and steal chips from other players to increase your stock of cattle.

In the end we decided to go with Shiv. It took us a while to ground the concept into something playable, and once we started playing we began encountering the problem I mentioned eralier. We had a set of rules laid out but as we played we discovered various dynamics that resulted in certain mechanics no longer making any sense or working properly. So we attempted to come up with an answer on the fly and continue on, but soon things became jumbled and we began adding more and more and more things to the game before we realized we had almost lost sight of the original set of rules we had started with! So then we backed up and began again with the original rules (mostly) and played through, taking notes along the way. After we finished a round of play (one of the guys did get shivved actually - poor bastard) we went back and revised the rule set to better accomodate some of the dynamics that popped up during play. We started again and another person was about to get shivved when time ran out - shucks.

The next part of the tutorial had us in yet another room playing yet another game. This one, called Three Musketeers (taken from the book "A Gamut of Games" by Sid Sackson - it was designed by Haar Hoolin), was pretty interesting, although once you figured our the strategy it became pretty mundane. Here's the way you create and set up the board:

The three grey peices are (you guessed it) the Three Musketeers themselves, meanwhile the black pieces are the Cardinal's men. Rules are as follows:

1. Each player moves one peice each turn. The Musketeer moves first
2. The Musketeer moves by sliding one of his peices to an adjacent space occupied by an enemy. The enemt peice is captured and removed from the board
3. The Cardinal moves by sliding one of his men into an adjacent empty space
4. Diagonal moves by either player are not allowed
5. The Cardinal's goal is to maneuver the Musketeer peices into the same row or column. If this ever happens, the Cardinal wins
6. If the Musketeer player is unable to move because there are no enemies adjacent to any of his peices, he wins

The trick for the Cardinal is to take advantage of the fact that the Musketeers have to take a Cardinal peice and that they cannot move on a diagonal. This means as the Cardinal you can position your peices in such a way that you can funnel the musketeer into a loss position by simply denying him the option of moving in any direction but the way you want him to go. This is a rather late-game strategy as you then have room on the board to move peices about more freely. As the Musketeer you must keep you peices as far away from each other as possible, but since you lose if you allow your peices to align in a row or column (meaning the peices to not have to be adjacent to one another a la tic-tac-toe) you can see that movement can be rather limited. It's best to have two Musketeers on one side of the board and one on the other. After I played three games with my partner (and lost every one I will admit) - we made up our own little game on the fly where you stacked the poker chips we were using as playing peices and took turns sliding a chip at the bottom of the stack to knock out the bottom chip. We would keep going until one of us toppled the stack. Ahhh the idle mind....

Finally (yes, there is a finally) came the best part of all. At the end of the day we had the pick of three electives, and I chose Iron Man Designer. The idea was to have a team of six people, a bag of items, and one hour to make a game using the items in the bag (the bag too, actually). What did we get? A pack of alphabet cards (letters on one side, associated pictures on the other, like Z = zebra), six plastic easter eggs, plastic coins, three little rubber animals (a frog, salamander and snake), a rubber band (it was used to wrap the alphabet cards), a small tupperware-type container, and a brown paper bag. One hour later here were the results:

Group 1: My group had a rocky start. We wanted to do a strategy game (in an hour?? sure why not? :P) but we couldn't figure out how to represent a map using the alphabet cards. We tried categorizing the cards and using that as terrain in a 5x5 grid and use the money as various units, but we soon concluded that that was way to complex a concept for a hour. So then I thought of the card game Magic and how you tap cards (turn them sideways) and thought of a game where you have a grid of cards and have to traverse them somehow. After describing this basic concept the rest of the team came up with their own ideas. We had like 30 mintues left at this point so the pressure was seriously starting to build. It took us almost 15 more minutes to finally get the game in a some-what playable state. We had a 4x8 grid of cards. There were two players, each with four egg shell halves (two pair) on his side of the grid, so each pair was the same color. The object of the game was to move your egg shells across the board to the other player's four starting cards. Each turn you coud move an eggshell and place down money to turn a card. You could not move diagonally. To move to another card, that card must be facing you. You can make a card face you by putting down money (perhaps starting with a penny since that was the lowest and most common coin) to turn the card towards you. If you wanted to turn a card with a penny already on it, you had to use a nickel. When you got an eggshell to the other side you got your money back. If two opposing eggshells blocked each other (like pawns in chess) you had the option of moving sideways or leap-frogging a similar colored eggshell to bump back the other player's eggshell. And to think that we managed to come up with all this in 15-20 minutes! It was some hectic play testing, let me tell you :) Mad props to my group members.

Here's a visual to help you understand some of what I said. You can see the money down and the turned cards.
See how the Yellow eggshell in the lower right corner is blocked by a turned card. To turn it towards the card I
want to move from I would have to pay a nickel. Also note the two Purple eggshells and the Orange one.
The Purples just leap-frogged and bumped the Orange guy back a card.

Group 2: To be honest I didn't quite understand the game these guys made up, so I won't butcher it by explaining it here. Although if I can get it clarified tomorrow I'll definetly update this.

I just wish i understood it...

Group 3: These guys must have been under the same pressure my group had but they still didn't manage to turn out anything substantial in the hour alloted. Looked like they were moving towards something interesting though...

This group bombed but showed promise

Group 4: These guys had a Sorry-type game with a square game board made of cards. They had the cards categorized and they had made a paper dice with scissors and the paper bag. The red container in the middle was a little coin shaker that provided them with another random value source. When a player landed on the same type of card as another player he could send that player back a certain number of spaces, hence the Sorry reference. I forget what the victory conditions where though, perhaps a certain number of revolutions around the game board.

Sorry!

Group 5: These guys had a really funny game. They placed five of the plastic eggs in the middle and each of them had an embarrasing thing to do inside of them. One player would start with the deck of alphabet cards and shake the coin shaker (like Group 4's). Depending on the outcome of the shake the dealer would either shuffle the cards and pass them to the left or deal out five cards with the letter showing. At this point it worked much like Slaps. As the player dealt the cards one by one onto the table, if a vowel turned up the other five players woud grab for an egg. The last one to grab an egg had to open it and do whatever it said inside. In this case, the loser of the game they demoed for all of us had to say "Diakatana is great!". Oh the PAIN!!

She had to say "Diakatana" and "great" in the same sentence. Utter cruelty!

Group 6: The final group also had a rather creative game. One person would wear a bag over his head and an alphabet card would be dealt onto the table. In the easy mode the card would go face-up with the picture showing. The other five players would then pick five cards (I think it was five...) and one card at a time try and describe the image using a word that starts with the letter on the card. The play goes around the table and you want to be the one to give the bagged person the correct clue. The group also came up with a cool timer by spinning the tupperware-like container (you know, the wooooog, wooog, woog, woog woogogogoggogg) until it stopped... wooging. The other type of play (hard mode) was where the one card was played face-down with the letter showing, and the other players had to say words that began with the letter on the card they had that would make the bagged player say a word beginning with the letter shown on the card in the center of the table. So in other words it was sort of like charades and those types of word and image association games. Very neat.

It's an Ostrich card on that table - but baghead doesn't know that

All told it was a great day, and only the first! This tutorial continues tomorrow *checks watch* I mean, today, So look for the next report later tonight... I mean, very early tomorrow morning :P

*zombies off

Today, for me, was all about the MGDC, the Mobile Game Developer’s Conference.

First impressions: you know you’re at a mobile GDC when everyone around you is carrying a tricked-out cell phone. It’s very telling to see what the mobile game developers and industry insiders are carrying, and what features they’re demonstrating to each other. Camera and photo album functionality seem to be popular, and there’s a lot of talk about cell phone specific games (for example: a fishing simulation that uses GPS to determine where you are, and therefore what kinds of fish you can catch).

I’m looking forward to seeing some of the new cell phone hardware on the Expo floor.

Norbert Chang, CEO of enorbus, discussed the challenges and benefits to developing games in China. Quite a lot of money can be made in this market, but a developer must be aggressive in pursuing the deals. There can be a considerable amount of bureaucracy and one should expect the telecom companies to be concerned about content. "Dating" while a popular draw to multiplayer SMS games would never be called that. It would be more generally framed as "Meeting people."

At the current time, SMS games and WAP comics are generating most of the profits but 3G services are coming. With the one-child, one-couple policy, Chinese people have a lot of money to spend on that one child. Right now, those children are demanding cell phones for use in college life. A lot of growth in this market is expected.

Another challenge is the fragmentation of the market. Each province in China has its own telecom provider as well as its own dialect and tastes. For instance, people in Shanghai speak Shanghainese and prefer basketball games. Therefore, games must be created for regional markets rather than mass market.

Dave "DC" Collier (Gamelet) and Matthem Bellows, publisher of Wireless Gaming Review, showcased various single player and multiplayer mobile games around the world. According to analysts Informa, globally $28 billion was spent on mobile gaming in 2001. All game genres were on display: Sim, RPG, puzzle, strategy, sports, and some inscrutable services such as the dog translating "BowLingual." 3D games and games that integrated the camera or locational features into gameplay whetted the interest of many interested in developing games for the U.S. Market. However, a common lament heard was "Well, maybe in Japan, but that (game/concept/cool idea) wouldn't work in the U.S." Example: "Let's Go By Train!", a train-riding simulation.

Scott Edison (AT&T Wireless), Jason Ford (Sprint PCS), Darcy McNeill (Telus Mobility), and Jerry Rocha (Cingular Wireless) each presented short 10-minute overviews of the developer support programs and pricing plans offered by the carriers. This was followed by a moderated Q&A session, which became adversarial towards the end. The representatives from the carriers repeated the need to appeal to a mainstream market that would view a cell phone as a communication device rather than an entertainment center. Others in the audience disagreed or wanted to know exact numbers of sales or downloads. The session was informative, but more as a preview.

Cingular, which admits to being late to this market, has a program called Cingular QuickStart. 75% of the billings would go to the developer.

Telus, the Canadian carrier, is charging not by KB or minutes, but by game events. A game may cost 25 cents, 50 cents, and so forth. Developers are encouraged to have a demo or smaller versions of a game that would be sold at 25 cents so that the consumer could try it out without much cost. The split is expected to be at 80%. There would be a filestore for the consumer to save downloaded Java games.

Sprint has a plan of $10 a month for unlimited data downloads. They generally work with known entities and prefer card or puzzle games for mainstream audience. Their development deal is "You set the price, split the revenue with Sprint." He says to check out the Sprint developer site.

AT&T Wireless has over 200 games and is offering location-based services. mMode, AT&T Wireless' magazine sent to subscribers, showcases content. The Comprehensive Developers program is at http://www.attws.com/developer. A developer would host its own store on its website.

The Second will showcase more carriers.

Today we attended the "Advanced Visual Effects with Direct3D" tutorial presented by a joint ATI and NVIDIA team consisting of: Cem Cebenoyan, Sim Dietrich, Simon Green, Richard Huddy, Greg James, Jason Mitchell, Ashu Rege, Guennadi Riguer, John Spitzer, Alex Vlachos, and Matthias Wloka. Designed to present an advanced look at the Direct3D technologies in DirectX 9, this tutorial was packed with so many attendants that they ran out of handouts.

We arrived just a few minutes before the tutorial started, and while normally this would not be a problem, we were among the many that had trouble finding a seat. Once everyone had settled in their chairs or along the wall, Jason Mitchell from ATI, Cem Cebenoyan from NVIDIA, and Sim Dietrich from NVIDIA started the lecture with a very detailed introduction to the new features and shader models available in DirectX 9. While the content and presentation was great, the presenters tried to cover too much in too short of a time.

The main focus of the introduction was on the architecture and implementation of the vertex and pixel shaders available in DirectX 9. Of particular interest in this part of the tutorial was:

The addition of new stream component types.

Use of stream offsets, which allow multiple objects in a single vertex buffer. This is not for post-transform vertices.

Slope scale bias - allows a much smaller value of depth bias without the artifacts

Asynchronous querying of the hardware allows you to query the hardware with an occlusion query (only one currently supported on DX9 cards), which returns the number of pixels that survive the frame buffer. Example uses include occlusion culling, lens flare effects, and order-independent transparency. They gave a light halo example where you render the light geometry with the query surrounding the render calls (see the DX9 documentation), and depending on the number of pixels passing, you fade in or fade out the halo.

Other discussion included Vertex Shaders 2.0 and Vertex Shaders 3.0. The features for VS3.0 included longer programs (512 minimum instructions), dynamic flow control, and access to textures (vertex texturing). Only problem is that there isn't any hardware support yet.

Pixel Shaders 2.0 is an expansion of PS1.x, and includes samplers, but doesn't have flow control like VS3.0. Pixel Shaders 3.0 included features like longer programs (512 minimum intstructions), flow control, access to vFace and vPos.xy, center vs. centroid sampling, and arbitrary swizzling. Vertex Shaders and Pixel Shaders were covered in detail, but a review of these topics here would take much too long (the slides are downloadable though!). An interesting point was made throughout the introduction about how the hardware is working toward a common shader pipeline, as opposed to the separate vertex and pixel shader pipelines. Version 3.0 of the shaders is the next step toward this unified pipeline.

At this point in the tutorial, we broke for an hour and a half of lunchtime, during which we caught up with our GameDev.net counterparts and enjoyed a nice selection of sandwiches, pasta, brownie, and a drink. All for free! :)

When lunch was over, we headed back to the tutorial room and took our seats. The next topic presented was on D3DX effects and the DirectX 9 High Level Shader Language, presented by Ashu Rege of NVIDIA and Guennadi Riguer of ATI. Ashu Rege provided a convincing presentation on why HLSL is an extremely helpful tool.

His primary argument is that the current game production pipeline separates the development of models, textures, and maps by the art teams, and the programming of shaders and game code by the programmers. He bases this argument on the notion that writing shaders is a creative activity, and this creativity creates a conflict between artists and programmers. The result is that the images rendered in the artist tools are not properly represented in the final in-game images.

HLSL provides more accessible shaders, but he says that HLSL is not the complete solution, because you need a shading context - effects are more than just shaders (i.e. states).

Instead, he argues that DirectX FX is the "solution", because it contains HLSL and assists in vertex and pixel shader development. With FX, developers can put shader information in one file, and with a plugin for artists and DirectX for programmers, the same image can be rendered in both artist tools and the final image rendered in the game.

Without going into extreme detail, here is how to use FX:

1. Load the effect
2. Validate the effect techniques for HW
3. Detect parameters for technique
4. Render loop (for each object in scene)
- set techniques
- set parameter value for techniques
- for each pass in technique
- set state for pass
- draw object

After this very interesting presentation on DirectX FX, things in the tutorial took a major slowdown as Guennadi Riguer took the stage to discuss the HLSL language. After later coming back to the hotel room and looking in the DirectX 9 documentation, we were rather disappointed to see an almost exact replication of the presentation. Anyway, the positive side is that HLSL is very simple and very easy to use. If you know C, then you'll be able to program shaders in the HLSL.

The best part of the tutorial came up next with Matthias Wloka of NVIDIA and Richard Huddy of ATI discussing how to improve performance in your DirectX 9 applications. The core of the presentation focused on how game developers are still not utilizing the full capabilities of the TnL video cards. Richard Huddy started his segment off with these statements providing an overview of the main causes for decreased performance:

Too many state changes

Don't batch triangles

Misuse vertex buffers

Lock critical resources at bad times

He then provided a slide from last year's GDC, which included a list of statistics for game renderers that he said game developers should be able to accomplish. When he asked the audience if anyone had accomplished any of these feats, nobody raised their hand (i.e. one such item was "greater than 0.5 million poly's per second). He then proceeded to go into detail on the usage of DirectX 9 for high performance graphics.

Pass Reduction - use the most powerful shader model the hardware supports. In other words, if the card supports PS3.0, use it.

Resource Management - create the most important resources first (i.e. targets, shaders, textures, VB's, IB's, etc), where "most important" is defined as "most frequently used". He says that while this may seem counter-intuitive, it works, and that's all that matters. He also said to never call a Create() function in the main loop. You should create the main color and Z buffers before doing anything else, where the "main buffer" is the one through which the largest number of pixels pass.

Sorting - sort roughly front to back. Again, this is counter-intuitive with alpha blending, but the idea is to sort front to back as often as you can. He says you should also sort by vertex shader (or by pixel shader, or by texture). When you change the vertex or pixel shader, it's est to go back to that shader ASAP. Also, short shaders (low number of instructions) are "faster^2" when sorted.

Clearing - use clear once per frame. You should clear the whole render target, and clear the color, Z, and stencil buffers together, unless you can just clear the Z/stencil. Never use 2 triangles to clear.

Vertex Buffers - Use the standard DirectX 8/9 vertex buffer handling algorithm with DISCARD and NOOVERWRITE, etc. Specify write-only if possible, and use POOL_DEFAULT is possible. Vertex Buffer size should be roughly 2-4 megabytes for best performance.

Index Buffers - treat index buffers exactly as VB's, except you should always choose the smallest element possible (i.e. use 32-bit indices only if needed, but use 16-bit wherever possible). Also, keep your index buffer out of system memory.

Updating IB and VB - need to be updated with sequential DWORD writes.

Handling Render States - minimal changes. Weed out redundant states changes. It's expensive to switch between vertex shader and fixed function, switching vertex shaders, and changing textures.

How to Draw Stuff - DrawIndexPrimitive with strips or list. Minimize the calls to DrawIndexPrimitive, and give the card 100's of triangles per call.

Vertex Data - don't scatter the data. The fewer the streams the better. Compress it if you can to 16-bits or less per component. Avoid spilling into the AGP, and power of 2 sizes help with 32 bytes being the best. Also, avoid random access patterns where possible by reordering vertex data before the main loop at app startup or authoring times.

Next, Matthias Wloka came up and provided an indepth and very interesting analysis to answer the question "How many triangles should I put in my batch?" His answer: "It should be, 'How many batches per frame?" His analysis led to a proof that right now, game developers are still CPU limited because they are not using the full capabilities of the TnL cards. The primary fault: developers have way too many batch calls per frame and not enough triangle data in each batch to warrant good performance. His analysis led to a formula he created to calculate the number of batches developers should use per second, but we didn't get a chance to write it down. You'll be able to download the presentation slides from NVIDIA and ATI in the coming days, though, so if you're interested, we encourage you to check them out. (Note: Matthias also showed a graph that showed how OpenGL was currently faster than Direct3D by 1.7 to 2.3 times when using small batches, although there was not a complete understanding of why. There is no such effect when using the proper sized batches).

The last segment of the tutorial, presented by Alex Vlaches of ATI and Greg James of NVIDIA, focused on using all of these advanced features of DirectX 9 to create special effects. The main special effects covered included the "glow effect" used in Tron 2.0 (soon to be released), volume fog created from polygon hulls, and more advanced hair rendering for animals. We'd post more information on these special effects here, but it would be more worthwhile to just download the presentations and demos on the NVIDIA and ATI websites.

In all, the tutorial was a great experience and provided everyone a portal into the cutting edge of realtime 3D graphics now and into the very near future. Sometimes the presentation was a little dry and worth falling asleep to, but the presenters stayed focused and provided a wealth of information for developers of all skills interested in Direct3D.

The most bizarre piece of company propaganda thus far has come from TKO Software. Along with the typical press-release about wireless whatzits came a handsome glossy photo of the company CEO.

I guess it does inspire confidence in me that the CEO of TKO is spending company money on software development and not memberships in the Hair Club For Men.

About 2/3 of the way through the tutorial, I took a break to attend an appointment with a couple of fast-talking muckety-mucks at Metrowerks. Metrowerks definitely took the smart route in the compiler market. When Symantec and Sybase purchased compiler companies, they immediately got grand designs to become the next Microsoft and leaned towards application development. . .with disasterous results. Metrowerks, after their purchase by Motorola, decided to become the biggest vendor of tools for embedded systems. The time was right because smart phones and game consoles were reaching the point where you could write software for 'em with something other than an assembler. In any case, they're all about embedded now. They've got nice compiling and debugging facilities for just about every smart phone, handheld, and embedded gizmo out there.

One of their big announcements was a very streamlined new system for programming the Nintendo GameCube. The old GC development kits were a real problem. It consisted of a GC-of-sorts built on PCI cards that you slapped into another computer. It was very expensive and you still didn't get a good idea of how your game ran on the real box. The new system consists of a special developer-GC with a network adapter and the ability to play stuff burned on disks. You can now just write your code on your computer and the GC can run the code over the network or via a disk you burned for it. You can also debug over the network. The most obvious advantage to this is price. It drops the price of GC development from over $6k down to about $500.

I attended the Gary Rosenzweig 8-hour tutorial on writing games using Macromedia Flash and Director. Since Gary's the guy who wrote the book on the topic (he's got about four books about Director and Flash on the market now), he was very good at his subject. My only complaint was that Flash and Director, while they look similar, are two very different products and trying to cover them both in one day kept him from covering either with any depth. You could've easily spent 8 hours on Flash, 8 on Director, and another 8 on Director 3D and Havok physics. But he's only one guy, so that wasn't in the cards.

When you register, the kind folks of the GDC provide you with a bag to tote your conference proceedings and various company adware with you around the convention center. Here's the contents of this year's bag. As you can see, there isn't a ton of useful stuff besides the proceedings on CD-ROM and a couple conference schedules so you know what's going on. Free Diet Cokes are always good too though (for those that drink diet of course)!



Editor's note: This was posted earlier in the day by other staff, but it was accidentally deleted.