Well, this is a little late, but I realized today that I never posted about this session.

This was the one session at the GDC that I knew I had to go to, being a long-time OpenGL supporter as well as being professionally involved with game development on cell phones (I work for Qualcomm).

Hosted by David Blythe (formerly with SGI) and Neil Trevett (OpenGL ES chair for the Khronos Group), this session mainly focused on the current state of OpenGL ES. The details of the spec are currently under NDA, but on a high level, OpenGL ES is a subset of OpenGL targeted at mobile devices, in particular cell phones. At this point, the spec includes the basics of 3D rendering, including transformation, lighting, and rasterization (including texturing). OpenGL ES is further broken down into "profiles" for specific types of devices. Currently, there are only two profiles, the "entertainment" profile, and another for devices requiring a higher level of security, such as computer systems in cars or airplanes.

Several game developers demonstrated games running on cell phones using OpenGL ES "like" implementations (no one can have an actual OpenGL ES implementation yet because the spec hasn't been finalized, so most of the developers either just guessed at what would be in the spec, or designed separate APIs modeled after OpenGL). Most of the games looked pretty good, and would exceed most people's expectations of what is possible on cell phones.

Ultimately, as the number of mobile devices capable of 3D graphics increases, there is a need for a standard graphics API to use with those devices. OpenGL ES is the natural choice for that role. OpenGL has long been the standard for cross platform graphics and game development, and now OpenGL ES extends that standard to mobile gaming. As IHVs begin to provide OpenGL ES implementations, game developers will be able to more easily develop games for a wide range of devices and reach a very large potential audience.

I attended the roundtable for game programming tricks with some pretty high hopes but it seemed that most people came expecting everyone else to have some ideas. That's not to say that it wasn't good - it just wasn't as good as I expected it would be. I'm going to be cheap right now because Brian Sharp, the moderator for the roundtable, was taking notes (better notes than me I should elaborate), and he'll be posting them up on www.ionstorm.com in the near future, so keep your eyes there.

Today I attended the lecture by Stuart Denman of Surreal Software (creators of Drakar and Drakar 2) called Highly Detailed Continuous Worlds: Streaming Game Resources From Slow Media. The lecture discussed several approaches for loading all types of game data asynchronously in the background while the game continues to run.

Streaming is defined by Denman as the operation when data is loaded as a background operation only when it is needed. The benefits of this approach is that the memory contains “active content” only, it reduces the initial loading time because you only load what you need at the beginning of the level or game, allows for larger levels, and it avoids console limitations.

The impact of such an approach on those working on the game includes:

Game Designers – affects the size and scope of the levels, and the location and distribution of monsters throughout the level to give data enough time to load.

Artists and Sound Guys – affects the amount of unique content (can have more), and the detail of the content (more detailed)

Programmers – “data hardly requires thought”

Classic streaming works by loading a buffer and using it immediately. Denman’s approach to streaming works by loading all data that is close to the player into memory before it needs to be used. An example of a racetrack game was given, where the racetrack is divided into ½ mile segments. With this approach, a vehicle traveling 100 mph would take approximately 18 seconds to go through one of the segments. Since modern hardware can load 80-100 MB of data in that time frame, 18 seconds should be plenty of time to load data asynchronously in the background.

Denman also addressed the need for an ability to separate shared resources from unique resources. He proposed treating all resources separately. The only problem with this approach is that the loading order becomes less predictable.

Data itself is stored in the form of a database instead of a stream. The data could be any kind of data, and the selection of data would be determined through a scenegraph or visibility connectivity algorithm.

Denman also mentioned resource caching, where resources are identified by their type and id, giving a 2^32 possible number of resources. He proposed a C++ class for each type that is derived from a Resource base class, and where each data type has its own cache that is time stamped. Whenever a resource is accessed, the time stamp is renewed to the current time. This results in a least recently used algorithm for flushing the oldest resource when the cache is full. Denman mentions using a hash table to allow for fast lookup services.

Loading is performed through the following steps if the resource is not in the cache:

1. New resource is created
2. Initialize state is set to “pending”
3. Resource’s virtual member Load() is called, which builds date requests
4. Requests queued
5. Requests loaded by separate thread
6. Load complete – processed via callbacks and the resource state is set to “valid” or “invalid”

A “valid” resource is defined as a resource that has been properly and completely loaded. An invalid resource is a resource that has not been properly loaded or if an error condition occurs.

Typically developers will want to use some sort of reference counting schema where each resource keeps a reference count. The cache will not flush a resource unless the reference count is set to zero. The renderer holds a reference count for resources used each frame. Frequently used resources can be locked in the cache. An example of this would be an animation that could happen at any time.

Overall, the lecture was very good and had the right balance of enough low-level and high-level details to enable anyone to implement a similar system.

I decided to take in a couple of roundtable discussions this morning rather than my usual task of attending lectures. First was the sparsely-attended Freelance Developer Discussion. Even though the room wasn't packed, we did have a spirited discussion of freelance-related issues. In attendance was a guy who does Java games for Pogo.com and an artist from the local Art Institute, which apparently has a lot of game art farmed out to it. There were also a couple of newbies in attendance, and we were able to give him a couple of pointers regarding being a one-horse game developer.

Next I attended a discussion of embedded browser-window games. All of the big players in the browser-game world were there (Popcap, Pogo, Shockwave.com, etc). From this I took that folks are generally happy with the big-three browser game technologies (Java, Flash, Shockwave), although Macromedia needs to spend some time speeding up the Flash player. Also, WildTangent doesn't seem to be a player in the mix anymore. Many of the folks had a WT game or two, but either they were poorly-trafficked or users had trouble getting them going. WT's absence from the expo floor this year seems to bear this out.

This year I was invited to attend the IGDA VIP Luncheon, which is something they hold every year to recognize the people that have helped contribute to the IGDA in some substantial way. While you don't receive any personal recognition (there's too many volunteers for that), the chance to sit down to lunch with fellow developers is always worth the while. I missed getting a picture of Graeme's speech, but he did give one. Here's an event pictorial.

(clockwise from bottom) Dave Rohrl (EA), Peter Glover (AtomShockwave), Lee Crawford (Stadeon), Darrell Porcher (Sony), Liam Hislop (Full Sail), and John Welch (AtomShockwave). Tom Sloper was sitting in the chair between Liam and John but he had to leave early. This was my table, btw.	The AI Gang! (clockwise from bottom) Eric Dybsand, Niel Kirby (Lucent), Steve Woodcock (GameAI.com), Alex Nareyek, Alex Champandard (AIDepot.com), and some guy whose name I cannot mention ;)
mmmmm... foooood	The people I know: in the center is Brian Robbins, just to his left is John Feil, and at on the far right we have Graeme Devine (id software)
(left to right) Dave Weinstein (Red Storm), Elonka Dunin (Simutronics) and Dustin Clingman (Full Sail)	Noah Falstein (center) of The Inspiracy gives the camera a big smile
Dave Weinstein chats with Jason Della Rocca (IGDA Program Director)

This morning I attended the Newbie Programmers Gathering over at the IGDA booth. While I didn't consider myself a newbie programmer (Eric Dybsand didn't think so either) in relation to getting a job in the industry I sort of am a newbie. So really for me it was a chance to see Marc Mencher (GameRecruiter.com) again ( I attended a similar roundtable last year with him speaking) and make sure that the decisions I've been making in my life have me on track for an industry job. Dustin Clingman (Full Sail) was also speaking with Marc this year. I walked away with my confidence still intact, and I also have a bunch of tips from the session in this little packet Marc made up. My personal comments are in parenthesis.

Networking Tips

Do's

• It doesn't matter who you're talking to, as long as you're talking
• Networking is a numbers game (the more contacts the better)
• The most important information you want to get from people when networking is the names of other people you can contact
• Networking is really just focused socializing. Do it for life!
• Prepare yourself to network before an event (make sure those business cards are printed)
• After the event, honestly assess your networking performance (the number of cards you managed to collect is a good indicator)
• Tell people your life goals. Prepare a personal positioning pitch. (careful! sometimes while explaining your life's goals you may cause your audience to fall asleep. Rehearse your goal pitch beforhand and keep it short)
• Set a goal for the numebr of new contacts you want to make before the event begins
• Do your research to zero in on specific people (if you're looking to impress, having some knowledge of the games the developer you are talking to has worked on helps a lot)
• Show up early at the event and stand close to the entrance at the beginning and end of the event
• Place your nametag where it can be easily read (that's something I hate about the GDC badge holders - they're way too low and have no strap adjustments)
• Keep the conversation short and sweet, or people will lose interest (even worse, they may tell their friends to avoid you!)
• Listen! Allow people to boast. Show interest. Pay attention. (networking is a 2-way street, in other words)
• Take notes (not something you'll do a lot, trust me, but some cases this is useful)
• Always follow up on new contacts via email (for example)

Don't...

• directly ask for a job (It's important to build relations first and foremost)
• expect to attend game industry functions and leave with a job (just cause there's a job fair doesn't mean they hire on-site)
• monopolize someone's time (if you're talking and that person has to leave, don't try and keep them around - now is the time to pull out your business card and do the exchange)
• tell that joke
• drink too much (not so much that it will affect your judgement, but you have to remember that in parties with loud music you have to talk realy close to each other, and the more alchohol you consume the worse your breath will smell)
• dress inappropriately (obviously the game industry has a very loose dress code, but use some common-sense)
• give a "hard" sell (pushing yourself onto someone will only cause them to back away faster (the first "don't" is the hardest kind of push you can give))
• complain (for any reason!)

Things To Know

Here's a bunch of things that any new game programmer should know.

• Game development doesn't pay - if you're looking for money, you chose the wrong industry. Starting salaries bottom out at $40k/yr and most programmers don't make much more than $60k/yr. High-paid developers as a result of huge game sales and royalties are the exception, not the rule. Game development is an industry that requires extreme amounts of self-motivation, not love for money.
• Degrees are... Okay - I'm not telling you to drop out of school, but many of developers today do not have degrees, or hold degrees in fields totally irrevelant to their current jobs. Most job offers do not require or even list degrees. The majority of game development knowledge can be attained via Web and books. Not only are they cheaper but if you have enough self-motivation you can learn faster. Despite that fact, degrees are still a good way to get a foot in the door.
• Portfolios are better - If you go to a company with a Computer Science degree, the first question they will ask you is - can you program games? If there's any confusion about that, understand that a CS degree does not teach you how to make games. The best way to let a company know that you can make games is to show them a game. There are several ways you can do this (all of which can be combined)
  • Make a demo - this is something a lot of people trip up on. When they think of demos they think of something that will impress a company, so they naturally thing big. This is a mistake. Rather, you should create small, focused demos that showcase your grasp of several key current technologies. This makes it easier for the company to pick up on your skills and decide wether you are what they want (and anything that makes it easier on the company is a good thing).
  • Create tools - tool creation is a major breaking-in point for game programmers. Starting off as a tools developer is a well-trodden path or many developers. Creating file importers and exporters as well as plug-ins for existing applications is a great way to showcase your programming skills.
  • Show code samples - the code that you want to display should be clean of syntax errors and well documented. if you hate documenting then either overcome the hatred or find a new career - companies will not accept someone who will not document on a project with 5-15 programmers all working with the same code base. make sure the code you are showing can stand by itself - if it requires too much support code to understand then it's not a good showcase item.

That was basically it, although Marc was also pushing his new book, Get in the Game! where he gives information on breaking in to various jobs in the industry. Dustin also helped him write the book.

Last year, Liquid Development, in lieu of buying up expensive booth space, stood outside the GDCA and handed out three different little comic books that depicted Jesus and the Devil in a battle for art supremacy - or something like that. I have the comics at home and not with me and it's been a year so my memory is no doubt a little skewed. But anyways the point was that they were funny while advertising Liquid Development as an art house. This year they really went over the top and held an impromptu strike outside the GDC, clamoring for better game art and that all bad art should be jailed and... well, you can read the signs in these pictures. Needless to say when I walked out to head over to the GDCA and saw the picket line and realized who it was, I couldn't stop laughing. Only in this industry can you get away with something like this :)

Yea... that's Liquid Development alright...	Erm... I thought all the signs were about bad art...
more pickateers	Helloooo ladies...

Nokia sponsored this session to inform developers about its new gaming platform. Intended for a mainstream market of ages 18-35, the N-Gage has a 8-way D-pad, ergonomic design for 2 handed play (think GBA), high quality color and 3D Graphics, loudspeaker, backlight and wireless connectivity through Bluetooth and wide area networks. Games will be on MMC cards and packaged by Nokia.

The N-Gage operates on Symbian, which is dedicated to low power, low memory devices. Adrian Sack of Ideaworks 3D, a third party developer, says programmers may be puzzled at first by Symbian but will soon realize how efficient Symbian is at conserving CPU and memory. Ideaworks 3D ported Tomb Raider and Pandemonium for N-Gage.

For qualified developers who are selected by Nokia or those working with third party publishers, Nokia will provide the device, CD-ROM, emulator, libraries, source code examples, documentation, and technical support. Those wishing to make a prototype for submission to Nokia should download the Series 60 emulator, available free on Forum Nokia. More information can be found at www.forum.nokia.com/games