Mrs.Bairdy

The session was presented a quasi-RPG with slides detailing the adventure etc. Steve’s a great speaker with bags of personality & the session was packed full of great anecdotes (e.g.getting chased down while running for being lippy to a guy in a park & how it impacts his dealings with publishers). He spent the initial chunk of the session going over the background of the company, how Puzzle Quest came about & the issues with signing the game on with a publisher. I’m skipping this chunk – it’s well covered on GameSpot etc.

Hurdles
Code portability – fundamentally a PC developer, totally underestimated the complexities in porting code to consoles (STL, lisp etc).
System constrains – huge issue. Again, totally underestimated this. They thoroughly screwed up their cart size, agreeing to a 8 times smaller cart through not realizing that “8MB” means 8Megabit, not megabyte (their front end screens for the DS blew the cart size originally!!).
TCRs a big wrench too.

Testing
“Test early, test often” – weekly afternoon tests etc. Previously, team was against focus group led development, but their use in PQ changed attitudes. Focus groups showed name wrong & that the gender appeal was low – led to reworked art & characters aimed at women.

Localisation
Too much text for a game of this size/scope (100k+ words) across all SKUs, leading to time issues & space issues. Partly caused by issues for FIGS in Europe (French, Italian, German, Spanish) – so much descriptive text ingame for weapons, things etc that in English are gender neutral need correct genders for FIGS. This caused a lot of translation time & space & energy to get taken up. In the future, will reduce this flowery language! Japanese language issues caused by the look of the avatars – combination of old/young + male/female looking avatars caused three different language permutations for gender.

The Release
Strong “word of mouth” based on their PC demo of the handheld versions & coverage on sites like Penny Arcade but the game’s lack of immediate impressiveness caused retail buyers to not stock many copies of the game, which they believe led to lost sales. The continued word of mouth kept it in the public eye despite a small marketing budget. Its success reinforced Steve’s belief that good games sell.

The Positives
- Time spent polishing is time well spent.
- “Test! Test! Test! Test!”
- Good design is still important in this day & age. The initial mix of the team was almost all designers – a different initial mix may have led to a more technically advanced game that was a poorer design but more impressive looking – which may not be a bad thing for another company or game.
- Focus groups are awesome.
- Good QA teams are awesome! (It sounded like they shipped with 3000 bugs??) Talked about the high profile PSP bug that slipped past their internal testers, publisher testers & Sony/MS QA…

Next Time
- More closely working with marketing to better sell the next game to retail and the press.
- Improve their build pipeline (unit testing etc)
- Greater respect for what the casual gamer/market wants, e.g. they filled the game with RPG game staples like classes that present a hugely important choice right at the start of the game with no indication of the impact or real details.
- Next game is funded by the DMF (government organisation) – “no interest loan” repayable on completion.

Takeaways
I adore Puzzle Quest and was curious to hear what Steve had to say and this was a nice lowkey end to this busy GDC. Nothing desperately new or ear-opening, but it was good to hear. Mid-level developers, and publishers are getting squeezed between AAA & budget. Longterm PC developers still underestimate the impact of switching to consoles. A lot of Puzzle Quest seems to be “happy accidents” in design & production in a lot of ways. I think their iterative design process works for them, but wouldn’t for a larger team or bigger budget – “clear goal, loose plan” would should scare producers! For small publishers/devs, working with press & key websites online to build word of mouth is utterly, utterly important.

“Don’t Mess with Great Gameplay! How WIPEOUT Innovated on PSP” by Clark Davies

Main elements from development of Wipeout Pure – inhouse graphical design (no DR), easier track building for designers, DLC & better handling in-game.

For Pulse, the key element was responding to feedback – novices need ’safe’ intro to gameplay so solo events given early prominence and zone mode became emergent tutorial – the lack of weapons & acceleration meant new players only had to focus on learning handling. Code wise, emphasis on improving handling & AI improvements.

How to take Wipeout forward? psp hardware, new tools to empower & community.

PSP Hardware. Looked at PSP hardware & decided to leverage unique features – mp3 custom soundtracks, jpeg save for in-game screenshots, PSN support for logon and wifi data sharing.

Handheld – focus on bitesize gameplay
- short races, shallow menus
- auto save & auto load
- custom controls
- loyalty points & unlocks so every gameplay session is positive for the player.

New Tools – ship skin editor in flash. Used flash instead of in-game tool for mouse precision & easy import of textures from other professional tools (i.e. photoshop).
- single player campaign editor for grids with full custom race controls with more functionality than regular game grid.
- already fan sites for sharing these grids (viewed as a big win).

Community Took lots of care to not step on toes of existing hardcore community (wipeoutzone.com) with new site (wipeout-game.com). Took 8 months + 2 developers. Put link to website on the game’s front menu using in-game web browser. Website can load game profiles & show rankings, records, loyalty points etc. Long term plans to improve stat tracking, skin sharing, Wipeout HD support, galleries etc.

Lessons:
Innovation + evolution don’t have to be just gameplay. Pulse viewed as a succes through combination of existing & new features. All decisions made were player-centric – how can they improve things for the player? Pulse has a huge bunch of features over the competition for community.

My Notes:
Not sure how much this focus on community would apply to story based games. Any game with multiplayer communities should learn these lessons – see success of Halo 3 video footage for great example. Building communities keeps people playing your franchise.

“Massive D: STRANGLEHOLD’s Breakable Object System” by Steven Ellmore

“None of this is rocket science”

“Breakable Objects”
Tool pipeline for constructing fragments/breakables
- mixture of off the shelf maya tools/custom scripts
- time consuming to author by artists
Custom tool to associate rules with fragments in object:
- rules for breaking (when)
- actions for breaking (how – not just ‘break’, thing likes tip, tear etc)
- weapon specific rules
One action type (send event to AI) gave birth to emergent behaviour like suppressive fire & other cool interactions like player shooting chunks of object, falling on AI, causing the AI to jump onto other objects & break them.
Breakables classified into four types:
- static
- normal
- debris
- effects
Used pattern styles to speed up asset creation, e.g. pictureframes breaking into one regular pattern. This gave cheap variation, but lead to technical challenges with propogating material breaks with templated replacements.
Eventually came up with not just linear breaks, tree recursion with inheritance generating complex behaviour.
Biggest issue – interpenetration big unsolved issue with breakables. Authored content to avoid it where possible.

“WooGlue”
Dynamic connectivity graph of fragments/actors, can be visualised as a tree with fragments on leaves. When told to break, used “connected components” algorithm (google it) to figure out how to split the thing. Allowed for things like breaking legs off tables but keep the table as a valid actor for cover etc. First test case was a heavily damagable car. Big win for the team once they got this working.

“Supporting Thousands of Breakables”
Edge driven – no movement, no update. Don’t call tick() on empty functions!
Limit polling!
Aggressively, but temporarily, remove objects that aren’t visible – make their sleep but stay in memory. Remove means not process physics/visual systems of the object, but keep the logic around for consistency – if something spawns or breaks into that space, we need to know about the sleeping object to prevent interpenetration!
When streaming out volumes, don’t forget about these objects so they don’t suddenly awaken without collision data to keep them from falling(???) – (got to be a better way of handling this).

Hibernate! More aggressive – destroys object but serializes persistance for breakable state! So whenever streaming unloads a volume with breakables, we’re saving data, and when reloaded, recreate the breakable using this saved data so we can restore it “as was” keeping the room filled with the carnage the player did without keeping the breakables around. (NICE!)

Limit Spawning! Only spawn 5 to 10 fragments per frame.Multiple frames to create all fragments for one breakables. If massive mayhem going on, skips some of the effects & fragments.
Important to keep original visual representation in rendered until all spawning is completed, then ditch original rep – keeps collisions/logic correct to avoid interpenetration etc. Particles hide a lot of these delays etc of course

“Lessons”
Current system is heavily art intensive – better tools will give better results by decreasing art creation time.
Supporting large number requires system wide architecture to back it up.
Huge plus in final game, took a while for designers to figure this tech & the implications of it (emergent behaviour, set pieces etc).
Next gen – DMM-like material stresses, fracture analysis etc using better WooGlue graph analysis to split graph & create multiple logical actors with the split fragments (e.g. breaking a table into two large chunks that can still be used as cover pieces – current system can’t split them into seperate actors).

My thoughts: Good straightforward talk covering good solid use of technology that gives great results without requiring cutting edge next-gen math/tech – as they said, I’m sure with time on tools, they’ll greatly improve their pipeline. Good food for thought with regards to our own tech moving forward.

Back home after a long day. GDC was super busy this year, the busiest I’ve seen it. Every session I was in was packed, with Chris Hecker’s in particular being standing room only. Here’s the sessions I saw:

Master Metrics: The Science behind the Art of Game Design
Two academics going over research from various academics & companies about “metrics” for game design – quantifying information about game design & the practicalities of it. This was beginning to look really dull with comparisons to early flight experiments, but it got more interesting. Some great data on measuring the first five minutes of games vs movies, quantifying what ‘beats’ they hit with regards to gameplay & storytelling etc. Some great thoughts on brainstorming ideas from Dave Perry (of all people) & Naughty Dog for example. I liked this.

MS Keynote
Dull was my reaction & everyone else I talked to said the same thing. Ho hum.

Automating Regression Discovery: Finding the Wrenches in the GEARS OF WAR
How can game developers automate their build process to improve their code + data stability, and improve their runtime performance? CCTray + automatically generated build reports are your friend. Turns out we’re doing almost all of the same things as Epic, which is good to know. They’ve got some interesting uses of heat maps (see Halo 3) too.

Lunch
Turkey sandwich with ex-co-workers I haven’t seen for a while. Fun!

Your Shameful Secret Addiction to Crunch
A talk by the owner of Relentless (devs of Buzz!) about the structure of the company & how they do no crunch (aka overtime). Regurgitating a whole bunch of articles/discussions from the same company, so this was a little dull. Once again, he skips the question of “what about us doing games that aren’t quiz games?”. Session was utterly packed.

Structure VS. Style
Fantastic talk by Chris Hecker (of Maxis/Spore fame) about key “things” in development that have helped us step forward (such as the tri) & how we need a similar leap forward in AI. Really interesting, really forward thinging & possibly completely wrong – as Hecker even said himself. Great talk though. Dumb question session after.

Beer
Met a few friends from Dallas. Guinness. Yum.

A simple ‘work in progress’ sketch, done using traer physics, featuring an octopus-like creature that goes where the mouse is when the mouse button is pressed. Completely lacking in usefulness, but I like the potential of the legs. Not sure where to take it.

Octopus

Heavily inspired by a sketch in Ira Greenberg’s excellent “Processing: Creative Coding and Computational Art”, this is a simple sketch randomly generating ‘distressed cubes’ at 30fps, written while my wife watched Dante’s Peak

This week at work, we had a really cool presentation about the “Demo Scene” by three guys from Europe. These audio-visual demos were a big influence on me growing up, I even knocked up some simple demo effects in STOS on the good ol’ Atari ST that I was immensely proud of at the time. So it was interesting to see where the ’scene’ is these days and the outreach by these guys to the games industry (and the likes of Pixar, ILM etc) to get involved in what they’re upto.

The talk was definitely inspiring, and tied in to the whole ‘generative art’ (though that’s a format one guy was a little dismissive of) aspect of processing. These guys are top notch coders, with the emphasis on creating something new & most importantly, impressive – it’s that “kudos” that the scene (a very social beast) lives & dies on. You’re out to impress with everything you do.

Again, inspiring & impressive.

Turing’s Delirium by Paz Soldán.
A novel about hacking, cybercrime, the nature of cryptography, revolution & personal responsibility, set in a Bolivia caught in the middle of changing from 20th century third world dictatorship to 21st century modern economy. This is a novel of Big Important Concepts, however it’s really well written & well researched. I wasn’t desperately keen on the electric ant concept, but I understood where he was going with it. I’m a sucker for books relating to Turing, albeit slight in this case. The setting of South America is a nice change to the usual cyberpunk metropolis sprawls.

Yes Man by Danny Wallace.
What happens if you say yes to every question? That’s the basic premise of this book charting the journey taken by Wallace as he pledges to say yes more often for a year. Adapted from his diary of the year, Wallace is funny, down to earth, in the same style as Nick Hornsby etc. Wallace was stuck in a rut, when a chance encounter on a late night London bus makes him evaluate where he is in life & take a pledge to say yes. What happens if you say yes to every proposition you get? The book sags a little in the middle, but it packs a nice emotional punch towards the end. I likes.

Adrian Mole and the Weapons of Mass Destruction by Sue Townsend
I adored the Adrian Mole books as a teenager – funny, down to earth but over the top (and a fantastic adventure game by Level 9). This is the latest one, set during the Blair years, with Mole now an utterly boorish character. Absolutely hated this. All the fun of the characters have been sucked out & the political satire is dull & obvious.

Processing: Creative Coding and Computational Art by Ira Greenberg.
A handbook for the programming language/environment Processing, teaching the basics of programming/maths for artists/designers, and going into a number of techniques for generative art. Not everyone’s cup of tea or directly related to anything I’m working on in my dayjob, but I enjoy mucking about in Processing. Some nice examples & ideas in this, even if the ‘learn to code’ stuff is for beginners

Creating Fractals by Roger Stevens
Pretty mathematical pictures & the maths to generate them. Not the greatest book about fractals, and it’s a little simplistic at times unfortunately.

I wish I’d written this article, as it’s pretty darn good, summing up some really common ‘mistakes’ we see again & again in games – simple things like turning the ‘long’ way to face a target.