Catching up (part 2)

My previous post contained some of the links I’ve gathered in the last 6 months. Here’s another post to try to clear out the backlog. This time covering gameplay and graphics.

Gameplay

I have talked before about how imperative it is to do extensive play testing (NOT focus testing, they are different concepts). For another story on the importance of doing thorough play testing and how “the customer is always right”, see the Schizoid Post Mortem (and this post too).

The Mystery Man on Film blogger posted a link to a 125-page PDF-file transcript of the original 1978 story conference between Steven Spielberg, George Lucas, and Lawrence Kasdan for Raiders of the Lost Ark. Some people will geek out over the transscript for sure. More interestingly, I think, is the Mystery Man sharing 10 valuable screenwriting lessons that he extracted from the transcript.

Even though single, baked, animations may be really good, we still have pretty shitty dynamic animation in games and what’s there is usually faked. We definitely need to improve this over the next few years. Rune Skovbo Johansen has done some really nice work in this area. First check out his videos (Locomotion System Demo and Semi-Procedural Animation for Character Locomotion) and then read the slides for his GDC 2009 “Dynamic Walking with Semi-Procedural Animation” talk.

Another nice character animation work is linked from Zach Baker’s blog post: The Character Animation Control We Only Dreamed of On True Crime.

For cameras, one of the better systems out there is the camera system we have in the God of War games. Phil, who did all the work, spilled the beans on how our system work in his GDC 2008 talk Designing and Implementing a Dynamic Camera System. Another good camera read is The Full Spectrum Warrior Camera System. Gavin James, formerly of Naughty Dog, had a really good GDC talk several years back on the camera system used at ND. Sadly neither Google nor the piss-poor joke that is the GDC website was helpful in locating Gavin’s slides, but if you can find them they are a good read.

On the AI side, games still have really stupid looking characters that keep running after they’re stopped against a wall and other shit like that. Many of the “looks stupid” problems are due to not having top-level manager code that puts a stop to the silly stuff. Some problems are down to lack of planning and some are due to poor pathfinding.

On the pathfinding side, Paul Tozour has a nice article on pathfinding (though his pro-navigation mesh and very anti-waypoints article fails to discuss how to do nav meshes to deal with transforming terrain).

This article discusses the use of potential fields for planning and navigation in games. I think using potential fields as a basis for planning is viable. However, it is trivially obvious that potential fields alone can never serve as a basis for navigation (as that equates to hill-climbing, which is a local and not global search method). Using potential fields to bias a (non-admissible) A* search to reduce search effort is fine though.

For some game AI research papers, check out these quick links to past AI conferences and symposia within the newly opened AAAI digital library.

And here’s a link to some academic AI research on dynamic pathfinding.

Uncharted 2 is soon out, and looking amazing I might add, but Uncharted was pretty darn good too. Michael Abbott wrote a good piece on part of what made Uncharted good. Michael also linked to this article about the music of Uncharted.

Trophies/achievements are a big deal in games these days. Trent Polack has a good article on the topic.

Graphics

The Gran Turismo website has an article which talks about how the team hooked up four PS3’s working together to display GT4 at 3840×2160 resolution and GT5 Prologue at 240fps. Very cool indeed.

Inside the Digitial Foundry is an interesting blog that analyzes video captures of games, sometimes with neat observations. For example, in WipEout HD’s 1080p Sleight of Hand they note that WipEout HD is “operating with a dynamic framebuffer. Resolution can alter on a frame-by-frame basis”, using the hardware horizontal scaler, to control framerate and avoid tearing.

The Graphics Size Coding blog discusses greating neat Demo-like effects with a minimum of code.

It really does seem like no link summary is complete without some shadow links. This one is no exception. First, Ignacio has a good post about Gaussian filtering of shadow maps, though his observation is (as with almost everything) previously known. This pair of forum post by Jonathan “LoneSock” Dummer discuss variants of VSM. Brian Richardson offers up some screen shots of different shadow methods in Quick Probabilistic Shadow Map Comparisons. Finally, there are so ridiculuously many shadow presentations coming out of NVidia alone, that they had to create a section just for their shadow papers.

Brian Karis links to my LogLUV post while pointing out that there’s another kid in town: RGBM color encoding. In fact, we are using a version of RGBM (different from Brian’s), not LogLUV, to represent HDR in God of War III. A third version of RGBM is described by Malte Clasen in HDR values in 8 bit RGBA pixels.

Speaking of frame buffer formats, Richard Mitton describes a (I think) tongue-in-cheeek format in Two-channel framebuffers for next-gen color schemes. Even more creatively, Tim Farrar (whose blog has moved) describes an interesting thought in 32-bpp HDR Blending Idea.

Maciej Sinilo wrote a good post on software occlusion culling. I know of several games (from different companies) that have used software-rasterized occlusion culling methods similar to what is described.

This was an interesting post about motion compensation using image data from the previous frame.

Matt Pettineo has several good posts on his blog. The one about Reconstructing Position From Depth should be useful to many.

Naty gives us a thorough schooling of the difference between deferred shading and deferred lighting, and also points out that “light pre-pass” is an ad hoc and broken version of deferred lighting, and probably not worth pursuing. Dean Calver’s old article on deferred lighting is also worth (re-)reading. And on the topic of deferred lighting, Adrian Bentley talks about the (non-)use of stenciling to accelerate same. Lastly, Adrian Stone makes an argument for deferred shading and against deferred lighting.

Tim Farrar pointed to GAME Watch’s two part article on the engine for Resident Evil 5 (Biohazard 5). Tim has summarized the key information from the articles in his blog post.

Aurelio joins the crowd who think graph based shader editors get a little too much attention.

Humus has a great pair of posts, related to what I recently wrote about optimizing particles. The first post talks about trimming empty pixels when rendering particles (and follow-up). The second post points out that the resulting convex hull after the previous optimization should not be rendered as an n-gon fan but rather with the largest triangles possible. Humus also has a good couple of notes about Z.

DXT compression is much more tricky than you think. Ignacio hints at why in GPU DXT Decompression. That’s why you use NVidia’s texture tools.

Miscellaneous

Saving the best for last, Keith Boesky has a really sharp blog where he is posting some very astute observations. A must-read piece is Game Marketing: The Proctologists are Doing Brain Surgery Edition about how truly feeble the marketing people are working on marketing games (and boy are they feeble). Another must-read piece is Game Prices Are Falling: Did We Really Think This Through Edition on pricing games.

And for a final tool, if you don’t have the attention span to read these two very long articles (which would be tragic) try the summarize tool at Tools4Noobs. Here’s Keith’s two articles again: on marketing and on prices.

5 thoughts on “Catching up (part 2)”

  1. Hi Christer, interesting links.

    Since the first part of your blog was about gameplay, I thought I’d ask you how the mechanic design and implementation process worked on previous GoW games. Specifically, what was the job title of the person who designed the combat system? What about the actual implementation? Same person? Maybe a small cross-discipline team?

    These tweener tasks are tricky because they generally involve alot of complexity, but are very heavy on the design side as well.

    Most approaches I’ve heard are something like: ” We have this one programmer who really likes fighting games …”.

  2. All the combat is created by designers who specialize in combat. They use a scripting language developed by one of the programmers. The whole system is fully data-driven so most characters are added completely without programmer intervention.

    Even so, you still need character artists to model and texture the character, technical artists to rig and skin it, animators to create all the animations (by hand), and combat designers breathe life into the characters by defining behaviors. For some characters, the programmers may have to add additional features to the scripting language to support some special need, but this is the exception.

    On top of this is AI behaviors for navigation and attack logic. Again, the basic systems were written by one of the programmers, but level designers add markup data to the levels, write script code, and adjust tweaker settings to control how enemies spawn, etc.

  3. I actually implemented a system/tool that does exactly what you’re talking about it, and it’s useful, but you have to be fairly technical to get alot out of it. Designers can get basic characters into the game by themselves, but if they want to add a character that has, for example, complicated platforming behavior, they would need a programmer or scripter to help them flesh out the additional functionality.

    One problem we’ve had is finding the right sort of person for that technical designer/mechanic specialist role. I’ve found that junior programmers generally do a better job than pure designers. Of course the meaning of designer, junior programmer, or gameplay engineer varies across studios. At my studio, a designer does little-to-no scripting, and gameplay engineers do most of the scripting for things like AI behaviors or boss encounters.

    It sounds like the designers at Santa Monica are more a bit more technical, though.

Leave a Reply