Game Developers Conference Canada 2010

There were quite a few members from our club that attended the Game Developers Conference this year. This page contains comments and notes from those who attended.

Comments from those who attended

Eric Raue: While not as large as the one in the states, the one here provides great networking opportunities and resources to help you get into the industry. The volunteer experience is great and as a reward you are able to attend any lectures you want when you are not on your shift. Be prepared, bring business cards — even if you aren't there to network. There are a lot of business types.

Conference Talks


Add notes you took at the different sessions you attended. If you have notes to add to one someone else wrote, go ahead.

Improving Programming Estimates

Adriana Lopez (BioWare)

She went over a pretty academic discussion of estimates and absolutely no information how it related to their games. Still, there were some interesting points.

  • Estimates need to be done by the people doing the work
  • Accurate = range, precise = narrow range
  • Cost of underestimation is way higher than over estimation
  • Managers think you can do it faster
  • Estimations cannot be done with incomplete results. Examples: too early in project, have to see it first, functional vs. non-functional.
  • There is a difference between incomplete (not finished) and unstable (done, but buggy; usually code hacks)
  • Do not provide off the cuff answers
  • Technique 1: Establish a baseline for estimates so everyone has the same idea.
    • For example estimates are done in whole days.
    • Could estimate complexity instead
    • Estimates can be in your own units, example in beers.
    • Allow ranges such as a Fibonacci sequence so the longer the estimate is the more fluctuation there is.
  • Technique 2: collaboration, ask a colleague's opinion.
  • Technique 3: Triangulation, compare with previous work
  • Technique 4: Decomposition, use a tool to help you break tasks down into components.
  • Track your estimates to see how accurate you are and refine your estimation abilities.

Rendering with Conviction (Splinter Cell)

Stephen Hill (Ubisoft)

They reinvented the Splinter Cell series by focusing on "active stealth," which means players are less reliant on gadgets and utilize the environment more. They reused their old game engine but it did not have multi-threaded support and used BSPs/portals. One of the first things they did was replace BSPs/portals with occlusion queries. This changed the way artists and designers interacted with the pipeline for the worse since they were required to learn a 3D package and couldn't block out levels as easily.

Occlusion Queries:
There is no silver bullet. Latency and popping are two big problems to deal with technically. There were also mental barriers of time required to implement such a system, fear, uncertainty, and pragmatism. They used a hierarchical z buffer similar to how a mip map works. First render occluders, then build a z buffer hierarchy, then test for out of bounds. This process allows them to integrate cpu tasks for determining when to stream in textures. They are also able to generate shadows this way (or it might have been optimize). It is super fast and brute force is okay. There were some human issues with this system because designers thought a big object is expensive and they put occluders in the wrong locations. One bug they encountered was a door occluder that worked fine except when the player crouched since normally you could not look into that room. Another problem was if the level geometry changed they forgot to update the occluders. Also the results are different depending on the hardware (floating point calculations). The ultimate goal is to make occluders fully transparent.

Ambient occlusion (AO):

If you're not familiar with this topic read this wikipedia entry. One technique almost everyone uses is a screen space Ambient Occlusion (SSAO) algorithm, which is really cheap and fast. They decided to create their own because SSAO has weird bleeding artifacts, their solution was super fast 2-3ms, and their solution gave more artistic control over individual objects. They baked AO into textures using a GPU depth peeling technique. See this paper by Hachisuka 2005 for details. If they used cube maps they wouldn't be able to do concave areas of the models so they used low res volume textures since AO is generally soft. Characters were made out of ellipsoids and AO was applied to them instead of the complex character models.

Future work:
Their AO system can be used to create neon lights (just replace the colour for that object's AO) creating a shape light. They want to explore how to use this on clothing folds and how to stream higher resolution volume textures.

Lighting Your Game the Beast Way

David Larsson (Illuminate Labs)

Their technology has been using on top titles like God of War III, Mirrors Edge, Mass Effect and more. He first went over the basics of baked lighting and why it is important. The two main reasons for using light maps are quality and workflow. Light maps are different than textures since each one is unique, which means they take up more space. In order to use normal maps properly with them they must be the same resolution. However, if the normal map stores the entire hemisphere instead of a bent normal they can be much lower in resolution. Unfortunately this wasn't explained in great detail. One feature of Beast is texture atlassing, which is the process of combining textures to use wasted UV space. One of the problems with this method is to avoid colour bleeding due to bilinear interpolation.

Movable objects present a really difficult lighting problem in games since light maps won't work. The solution implemented in their technology is using light probes, which are spherical harmonic maps (think shiny spheres) placed in a 3D grid around the environment. As an object passes through the grid, the lighting is interpolated from the nearby spheres which have the precomputed lighting. The results look great.

At the end he showed a video of a preview tool allowing artists to adjust parameters and see almost instantaneous results. However, this demo was running on a system that had 48 cores. An Unreal map consisting of almost 2 million polygons was demonstrated to prove it wasn't just a toy.

Forza Motorsport 3 Audio: Design Process and Pipeline

Greg Shaw, Mike Caviezel (Turn 10 Studios, Microsoft)

The talk focused on how they broke car sounds into meaningful parts and how they setup sound recording to achieve them. There was not a lot of details provided from the programming side. One comment that was repeated multiple times is that the game industry is in need of passionate audio programmers. They first explained how a 4 stroke engine works and how it is essentially a complicated wind/brass instrument. When developing sound systems they thought in modules: engine exhaust, bolt on sounds, and tire sounds, which are layered and form the main components. They broke it down even further with a detailed diagram outlining the components of each: transmission, turbo, supercharger, exhaust pops, cam valves (engine ambiance), and car wind among others.

Recording the sound:
They no longer record stock forms of cars because they were often boring to listen to and it is easier to dumb sound down than make it better. They mostly used a dynamonitor and track recording. Putting the car into Neutral is another way but less authentic. Most of the cars they recorded were rented or borrowed by private owners. The first thing they always did was a "power pull" (start up, full throttle, shut off) to test the car to see if everything is performing properly and sounding good. Then they recorded short loops at steady pitches, every 500 rpm at full throttle. Sounds for idle, startup/shutoff, and free-run were also recorded. They used Pro Tools to edit the sounds. Since RPM measurement is not exact they tuned individual loops against absolute pitch sine waves (RPM = fundamentalFrequency*60/ # Cylinders).

Implementing the sound:
They relied on the physics system to provide detailed information to create realistic sounds. Often if the car sounded wrong it was a physics problem and not an audio one. If it still sounded weird they could easily add "springs" (adjustments to flexible ranges) to fix the sound when these issues occurred. For example lowering the redline RPM sound by 500. Their focus was first impact, then accuracy and then variety. It is all the little details that matter like shift times, flywheel inertia, and idle vs. redline. When bringing the sounds into the game they first put the raw sounds in just to make sure everything sounds reasonable (could ship if necessary). Then they do a hand tweaked DSP pass, which definitely is shippable. Finally if they have time they will do a third pass to refine it even further.

Tires:
Single most important audio in the game because it gives audio feedback of how the rubber meets the road. The sound of tires rolling over surfaces communicates speed to the player. A howling noise is peak grip while screeching is slipping. The downforce exerted on outside and inside wheels while turning is different and needs to be recorded separately. This is the most CPU intensive audio part of the game since there are 4 tires on a maximum of 8 cars in the game. They recorded audio for all types of surfaces and downforces.

Types of audio mixes:
The audio mixes are different depending on the camera angle and type of race. If it is a hotlap the player's car is more important than anything else while in a race the other cars are very important. Watching replays and different camera perspectives (cockpit, bumper, follow near, follow far) also warrants different audio mixes. It is time consuming to do all of them so you need to pick your battles. Sound designers frequently request control over roll offs instead of just linear or exponential. During replays players want to hear longer roll offs.

Using Telemetry to Improve Zombie Killing

Dee Jay Randall, Top Niwinski (Blue Castle Games)

This Gamasutra article does an excellent job outlining the talk. Below are some additional notes.

  • The telemetry system is a separate thread that only takes up 65 KB of RAM. The thread is based on the producer-consumer model and if the buffer is full messages are dropped. What is needed is a sampling of data, not all of it. Data sent per user is around 1 KB/s.
  • Their attitude was don't optimize until it's a problem
  • Why not storing telemetry as a text file?
    • Manual collection required
    • No tools for SELECT and JOIN operations
    • There are many high level tools for SQL
  • Using text to visualize data is only good for small and finite sets of answers
  • 3D visualizing data allows developers to fly around and see the relation between data
  • They would like to look into using Google Charts in the future
  • Georg Zoeller's talk titled "Development Telemetry in Video Games Projects" is worth checking out (slides here)
  • A function was added to track high watermarks (how big a data structure gets) so you can optimize them. Just add one and a few days later you will have your answer.
  • The telemetry system works really well with QA since it allows them to attach screenshots and debug information so developers can immediately jump to the problem area. Probably the most impressive feature is that you can see nearby bugs meaning there might be less duplicate bugs entered.
  • Designers don't know SQL so a noun based drop down box query entry system was used.

Preparation (Don't Give Us a Reason to Reject You!)

Jim Rivers (Obsidian Entertainment)

Jim provided a clear list of do's and don'ts for creating resumes, cover letters, networking, websites, and tips for interviews. He sees hundreds of resumes a month and it is surprising how frequently a lot of obvious don'ts happen.

Resumes:

  • A functional resume is a really good format to follow.
  • Research the company you are applying for
  • Keep it to one page unless you have something like 10 years experience
  • Word or PDF
  • Must have a link to a website (especially for artists, he said he gets a lot of artists that don't have a portfolio website)
  • At a conference like GDC (in America) he usually gets around 1,100 resumes.
  • Create a master resume that contains everything you could possibly say about yourself and then take pieces of it to tailor your resume to the specific job.
  • Do not add fluff (some people will say the same thing 3 different ways when 1 will do)
  • No logos or art (even if an artist), just simple black and white
  • Use standard fonts (told a story about some guy emailing a font that needed to be installed before it could be viewed)
  • Do not list hobbies unless it makes sense for the job (ie. surfing for a company that makes surfing games)
  • Include in this order: Name, address, email, website (important), phone, objective summary (be VERY specific, "Game Designer" won't cut it), Skills, Work or industry experience, education.
  • The reason for this order is he prefers to look at skills over education and experience.
  • Have a professional voice mail
  • Be proud of your degree, you spent a lot of time to get it.

Cover Letters:

  • fanboy/fangirl a bit (they like the ego stroking)
  • convey your passion
  • research the company
  • be confident
  • state what you can bring to the team
  • Don't tell a life story (someone wrote a 10 page cover letter), beg, more than one page.
  • Format: Dear Name
    • Intro - create interest, attract attention
    • The body - why you want to work there (most important, show your research)
    • Closing - tell us you would like to be interviewed and what you can bring to the team.
    • Sincerely goes a long way
    • Name written, name printed

Websites:

  • This makes or breaks you
  • Clearly state exactly what you are. For example "Character Artist" or "Level Designer"
  • Link to a downloadable resume (they like passing it around via email and keeping it on file)
  • Your best work only
  • The rule of thumb is "extra steps are bad" don't make them work to get at information
  • 2-5 examples, not everything
  • Use categories to help them navigate your work
  • Link to friends' websites since if they like you they will check out your friends and vice versa.
  • Show that you keep your work organized (example for artists below)
    • Polycounts
    • Show texture maps
    • Show number of maps (were you smart?)
    • remember: ZBrush and Mudbox do not have to be used for all projects just because you can
    • Show your reference art
    • Must be lit and textured
    • It is okay if you don't create your own concept art and this shows how you are able to work with art created by someone else.
    • Find interesting concept art on websites like cgsociety and conceptart.org and get permission by the artist to model it in 3D. They will probably ask to see some of your work before letting you. Both of you will benefit from networking and to show how your work can be used by other artists.
  • Do not post work that is not yours (make it clear what is yours)
  • Do not post work that screams collage, instead personal projects on your own time show your passion and dedication and usually turn out better.
  • Quality over quantity
  • Do not post anime drawings on your website.
  • The war genre is very big
  • If you use a free webspace that has ads you do not have control over what ads pop up.
  • Do not post risqué or politically focused content.
  • no dead links (some companies will not hire you if you have one, Obsidian has a 2 dead link policy)
  • No work in progress content period. He asked some artists why they said that and their response was this shows you are unable to complete projects and are lazy.

Business Cards:

  • Keep it professional
  • Include your website
  • What are you?

Networking:

  • Hello, handshake, smile
  • Use connections
  • Professors are good existing ties
  • Join associations like IGDA which are good for answering any questions you might have.
  • Research linkedin employees for a company you are applying for
  • Network through online forums and blogs
  • Keep the conversations short and sweet
  • Take notes on business cards (Jim was surprised that so many people did it this conference)
  • Just email to say hello (he takes a chunk of contacts and does this sometimes)
  • Don't stalk, come off as needy, don't be selfish (introduce friends since if you work well together that's good for the team), don't ask for a job.
  • Know your targets
  • Have a wingman
  • be the information hub
  • follow up or lose
  • be professional
  • don't be a wuss, clingy, a fanboy/girl, or a card collector (throw out ones that don't matter or just don't exchange)

Interviews:

  • You should know what kind of facial expressions you make at all times so practice in the mirror
  • At obsidian there are 4 interviews in a day, lunch in between and this also is part of the interview.
  • Do bathe, be on time, be prepared, listen first then answer, get business cards, be professional.
  • Don't blow off an interview, the industry is small and everyone hears about bad people (there is a blacklist)
  • Don't lie

From the Q&A

  • Concept artist and writer are two of the toughest jobs to get.
  • 5-15 art pieces
  • A big plus if you can show it off running in game
  • Not looking for composers but someone who is able to do sound design

Reflection for Tools Development

Jeremy Walker (Ubisoft Vancouver Inc.)

This talk was about the use of reflection as a means of exposing game objects to external tools. A general asset management system called Content Framework was demonstrated.

The Problem:

  • Reflection is a technique common in higher-level languages like Java, C#, etc. but is not available in C++ natively. So we do it ourselves.
  • Often times a system is setup in a way which is fast to do initially, but is not extendable or reusable.
  • If we can lower the time it takes to implement a system in a nice, re-usable way people will do that instead of hardcoding. This is where reflection comes in.
  • Monolithic engines are easy to setup, but hard to reuse between project. So we decouple packages.
  • Hard to completely decouple, some sort of hybrid is probably going to happen.

Discovery pattern:

  • Compile time errors can happen when some property is updated somewhere, and a dependency is not.
  • Solution is to have a system look for resources and not to hard code them. Compilers do this with function registration/discovery.

Uses of Reflection:

  • Serialization. This is a big one, who wants to write save/load code for each asset in there pipeline manually?
  • Scripting. Automate the generation of binding code. Packages such as tolua do this, but only for scripting.
  • UI editing. Present a properties view of all the UI properties like in VC++ or Qt Designer.

Reflection Approaches:

  • Macros. Hard to get working, let alone optimize.
  • Code parsers. Now this is clever — use Doxygen to output XML information about your program, then parse that XML (easy). Comment annotation exposes other information.
  • Type definition language. Genereates C++ headers which are then compiled. Uses its own simple language.
  • On the tools side, use proxy classes to represent in game types. You don't have access to the actual type, only their info.

Problems with Reflection:

  • Types out of sync. Solution: use checksums or auto-sync (discovery).
  • Tools coupled to game. Avoid overusing proxy classes and instead try to use polymorphic proxy classes.
  • Memory usage. Move over to a binary type system instead of text. Use runtime diagnostics to see which reflected types aren't used and can be removed.

Content Framework:

  • Uses reflection across the board. Provides default editors for reflected types.
  • Registry for tools packages with plugins. Decouple package releases.
  • Discovery based.
  • Custom asset types for 3rd party types (.tga edited using Photoshop)
  • Same build step for all assets.
  • Live previewing and hot swaps of assets in game.
  • Redo/Undo
  • Lean mode for final build.

Keynote: Building Social Games: Games at the Speed of Light

Bill Mooney (Zynga)

About how social games are on the rise, and 8 tips for making social games

Regarding their method:
1) Start Small

  • simple loops
  • social interactions are key
    • pokes
    • social missions (similar to co-op raids)
    • gifting/trading

2) Go Fast

  • Farmville and MafiaWars took 5 weeks to launch
  • add new features weekly

3) Test Everything

  • measure user behaviour
  • ignore the HiPPO (Highest Paid Person's Oppinion) or at least don't do it just because they say so

4) Create User Delight

  • listen to your users, they will tell you what they want

5) Add Depth

  • create an on-going play experience
  • ensure your player has something to come back for

6) Empower Users

  • play, invest, express
    • play: satisfying for players
    • invest: do people get engaged? involved? what about hardcore players? groups?
    • express: allow user expression and customization

Regarding the team:
7) Hire Smart

  • when they hire, they look for someone that is:
    • a gamer
    • analytical
    • humble
    • driven

8) Create (Enough) Owners

  • too fast to micromanage
  • share the load
  • trust your people

Striking it Rich with iPhone Games: The geoDefense Example

David Whatley (Critical Thought Games (his one man company))

The big goal is $$
The obvious thing that most people don't pay attention to is trying to maximize the revenue and minimize cost
cost = risk
and risk = time x development + tools

keys to lower cost

  • small team
  • constrained scope

geoDefense as an example:

  • borrow an art style. in this case, 'geo style'
  • stick to something you know. - tower defense
  • it doesn't have to be something new
  • outsource what you hate. - public relations
  • plan your time. - with PR out of the way: 50% design, 35% code, 15% art

Post Mortem

  • high margins
  • time to market: fast
  • design is key
  • public relations are key
    • PR > media > Apple > Apple PR > Apple promo (<— gold!)

On making the sequal:
Self Assessment

  • first product
    • critical and commercial success
  • PR firm
    • works, can better utilize
  • have assets
    • cash
    • enthusiastic audience
    • media attention

Approach

  • reuse 90% of the work
  • trade cash for market time
    • hire level designer
  • focus on gameplay
  • promotion is key

How to Do This

  • X factor
    • fun compelling game
  • clearly establish business goals
  • assess your situation
    • resources, skills weaknesses
    • risk tolerance
  • constrain your product goals
  • assemble your team
  • focus on your audience
  • make use of open source code

10 Tips (and more) to Make Your iPhone Game More Successful

Alan Martin (Vogster Entertainment)

Development

1) Content Updates

  • plan content updates early
  • why to update
    • bug fixes
    • marketing opportunities
    • keep players engaged
  • what to update
    • bug fixes / customer feedback
    • in app purchases
    • free DLC
    • new/unfinished features
  • when updating
    • put effort into the description
    • tease the update in the community
    • plan approximate schedules early

2) Lite Version

  • if possible, plan a lite version
  • include enough to hook players quickly
  • don't give it all away
  • don't call it a demo, apple will reject it
  • don't include references to other platforms, this will also make apple reject it

3) Achievements

  • plan/start early
  • do include at some point, even if it's after launch
  • partner with a free service to maximize exposure in the community
    • OpenFeint
    • Plus+
    • iAchievements

Pre-Release

4) Title & Keywords

  • look at similar games for reference
  • does the name convey the game? does it convey fun?
  • remember the limited display space, you don't want to end up with 'Super Wizard Adve…'
  • take the time to come up something good
  • keywords:
    • 100 characters max including commas. don't use spaces
    • don't use others' trademarks, apple will reject it

5) Localization

  • if not the game content, at least the app store elements
  • what to localize:
    • description
    • name
    • keywords
    • 'sale' words/phrases
    • website names/reviews

6) Screenshots

  • check the competition
  • have variety
  • be sure they're representative
  • no horizontals on some devices
  • you get a separate set of pictures for the iPad
  • localize

7) Icons

  • should stand out
  • also plan for variations like 'sale'

8) Price

  • be competetive
  • don't underprice
  • leave room for change or a sale
  • check the prices of similar games

Post-Release

9) Editors

  • reach out to publication editors
  • do it beforehand so there is a relationship when you release
  • find emails, write nice letters
  • use your promotional codes to get reviews, 50 per update, only good in US

10) Check Rankings

  • check rankings/sales daily
  • be prepared to adjust price/store elements
  • most important thing is getting into top 25 in any category
  • if you're the #1 app, you sell 15-20k per day
  • use all your sub-categories

10+) Working With Apple

  • don't get impatient
  • take advantage of it if they contact you, listen!
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License