GameDevBlog

Notes On Sports

Robert Yang's article in The Escapist on using outdoors games to teach game design is pretty cool.

It reminded me of something I've thought for a while but never shared:  as game simulations become more realistic, designing videogames becomes more like designing sports than designing, say, board or card games.  FPS's have more in common with Capture The Flag than with chess.

Which, for me, is a problem, because I don't like sports.  This is surely partly because I suck at them - always one of the small kids I could never hold my own in any competitive team sport.  (But hey, I'm not a total geek, I used to be an ok surfer.)

But the fact that multiplayer FPS's only engage me for a day or two before I go on to play something else - I wonder if there's something more fundamental there, some fundamental trait of sports and FPS's which drives me away.  I can hold my own in FPS's.  (Sometimes.)  In that arena size doesn't matter.

And I wonder if that fundamental trait is:  slop.  This isn't supposed to be a "sports are bad" post, I'm just rambling about my personal tastes, so maybe the word 'slop' sounds too pejorative.  My point being in these highly complex systems like NFL football and counter-strike it's really hard to get a handle on what's going on, they're unpredictable, anything can happen (there, that's not so pejorative) whereas in board and card games the systems are usually so simple that you can predict the future, sometimes determine the exact right play, know you've got "the nuts".  Board and card games are inherently more...tractable...than sports.  

Not a good or a bad thing.  Just a thing.  Some people prefer it one way, some the other.

But I would say - if you're designing an FPS, sports-design may be more important than boardgame-design.  Whereas if you're designing a turn-based strategy game or RPG, vice-versa.

It occurs to me now that Schizoid is more of a sport than a game, too, by this criteria.  Maybe.  It's a grey area.  The behavior of the enemies is completely predictable, making it fairly tractable.  Still, you could play live-action Schizoid tag:  you have your red-shirts and blue-shirts (or shirts and skins probably easier to come by) and one of each is "it".  Maybe the ones who are "it" wear crowns or something.  When red "it" tags a blue guy they're out.  When blue "it" tags a red guy they're out.  If a blue guy tags blue "it" or red tags red "it" then they get to be "it".  I wonder how it would play out...I'll have to try it some day.

Adventures In XML

I feel like I'm the last developer in the world who is dipping his toes into XML.  So what I have to say about it is probably useless to the rest of you, but here are my latest experiences anyway.

So how's this for not falling prey to speculative generality or premature abstraction:  I don't like to make tools until a clear need is demonstrated, when you can tell that a content creator is going to be a bottleneck and they need workflow improvements.  On Schizoid and through much of our current project code was always the bottleneck. (Actually, just recently it may have become art.  Time to make some art tools.)

To that end, on Schizoid and through much of this project we've had content creators do their creation directly in the code base, editing .h files (well, with Schizoid, C# files) and data structure declarations, piles of curly braces and all.

That all changed recently because Richard's machine had trouble installing Visual Studio, so I thought it was time to do the right thing and put our data in text files.  Not to mention, we're eventually going to have to, for Downloadable Content purposes. It's been many years since I've written code to read data from a text file.  My MO has always been to use fscanf.  

So, time to catch up with the new millennium.  Do I really want XML, for starters.  There was a whole XML - JSON thing going around a while back - my friend Bryan McNett was a big JSON advocate, and he did really cool stuff in the Spidey 3 codebase where you could tag data structures in your h files and a text processor would create the JSON importing code for you.  He's written articles about it but I can't seem to find them.

In the end, I decided to try XML rather than JSON, because there seemed to be more support (XML handily won the Googlefight), but the deciding factor was being able to easily load XML files into Excel.  Having all of our unit data in one big table that's nicely formatted (the alternating dark blue and light blue rows soothe my soul) won me over.  And McNett's .h file markups may have been cool, but we don't have enough different data structures to make the effort of adding another step to our build process worth it.  (Not to mention there's no reason you couldn't theoretically do the same thing with xml.)

The next question becomes - which XML library do I use with C++?  With C# it's built in, yo.  Again I mostly relied on Google - when in doubt, do what's popular.  The second hit was TinyXML, which seemed great.  Free license and small.  Hooking it up and getting started was fairly painless.  I usually felt like it took 2-3 lines of code to do what should take 1,  but some small wrappers and I was ok.

It took me about a day and a half to learn pidgin xml, hook up the library, and get our data converted.  I tried creating a schema to assist in the XML importing to Excel and threw up my hands - it seems to do a fine job on its own, anyway.  We are schemaless.  A schema, I know, would help with data validation.  We do some in code, but not enough, yet.

That's one of the big things I miss about the old way - typing our data straight into the code - is that the compiler validates our data for us, and does a great job.  

One thing I didn't like about the old way was simply formatting the file - you end up with a lot of comma separation and it's easy to lose track of:  is this float here his hitpoints or his armor?  Etc.  The new files are much easier to read and maintain.

What about XML vs. rolling our own format?  This also feels like a win.  Not a huge win--here I am writing a lot of XML glue code instead of a parser--but a material one.

And so, I've finally caught up with the new millenium.

Notes on *Portal* and *Mirror's Edge*

I just had a little epiphany about *Portal* and why its story worked so well.  Warning, spoilers not only of *Portal* but also of *Mirror's Edge* and *Bioshock.*

Compare and contrast with *Mirror's Edge*, the game I've been playing lately, which is great, and I highly recommend it to people who like the Tomb Raiderish genre of "realistic" platforming.  

Still, the story is not on the same level as *Portal*.  Of course, few stories are, but let's talk about the main element of *Portal* - GladOS, the voice in your ear.  The voice in your ear has become a total cliche in videogames and more than half the time I find myself wanting to kill that annoying voice more than I want to kill the enemies he or she is warning me about.  *Mirror's Edge* has one of those annoying voices-in-ear, and when that character died I felt absolutely no sympathy whatsoever.

Now, in *Bioshock* and *Portal* - you actually do get to kill the voice-in-your-ear!  In fact, it's the climax of both games.  It's like the writers recognize that fundamental urge in the gamer, the desire to wipe out that "helpful" unstoppable voice.  And, from a writer's point of view, it's so simple - you've merged two characters, the advisor and the enemy, into one.  And you get a plot twist.  Win, win, win.

And here's the interesting bit - in *Bioshock* and *Portal*, I never hated the voice in my ear the way I hate Merc from Mirror's Edge.  Why?  Is it because Merc or Merc's writers want us to like him?  They're asking us to like him?  So we'll feel the right emotion when his character is killed?  And so we feel coerced, manipulated, annoyed.  

Whereas nobody expects you to like GladOS and yet, for some unexplicable reason, I do.  I should hate her - she's like the earnest cloying grandmother who gives you a big hug that you just want to get away from.  But there's such depth and breadth to her.  She loves you and hates you at the same time.  And she's funny.  One of the real tragedies, when *Portal* ends, is, in fact, that you don't get to spend any more time with GladOS.  And that's because you killed her.  I'm not saying it creates *Shadow of the Colossus* levels of melancholy, but it's there, it works, and I wasn't even aware of why until now.

Now, as for how to create a character like that, well, that I have no idea.  You have to be some kind of genius.

Test StackOverflow, Solve One Of My Problems

Hey, anyone who's familiar with the visual studio 2008 testing framework and wants to help me solve a problem / check out what I posted on StackOverflow:

http://stackoverflow.com/questions/735299/visual-c-test-strange-behavior-all-tests-fail-unable-to-get-type-error

Sweet

It might be gone by the time you read this, but Schizoid is prominently featured as the game to buy on Amazon's XBLA page: http://www.amazon.com/b/?node=979417011.

In other news, my 9 year old nephew is visiting and he freakin' loves it.  In fact, watching him play and seeing how he clearly is having a great time -- and how he can't wait to play again when we make him turn it off -- is some of the best praise I've ever gotten.

In still other news, Skaff plays with his 3-year old son and they're up to level thirty-something.  We need to get youtube up of that or something...

More GDC takeaways

I don't have my notebook with me, so this is from memory, so...on the bright side, you're only getting some of the last most memorable points.

Automated Robot Testing - Paul du Bois.

I've done 'random monkey' testing of various stripes ever since Die By The Sword.  Some places where Paul's system beats any of the ones I've done:

- uses scripting language to set up and execute tests - a test lead can write your automated tests

- can automatically run on any idle dev kit in the office - a single test server machine dispatches tests.  Now that's cool.

Don Daglow always gives inspirational talks that sometimes get me a little misty eyed.  One thing that got my attention:  he's very psyched about distributed virtual teams, which was good to hear, since Schizoid was a virtual team and it's always an awkward conversation with publishers when they find out Torpex is mostly distributed.

I almost missed the Bioware talk on the level process for ME2, the last talk of the show, but I couldn't get in touch with my ride so I decided to go.  Glad I went!  Bioware has done it, they've broken down the silos, gotten the artists and designers together in one room to build levels.  So instead of this constant back-and-forth (designer lays out blueprint, artist models, designer gives feedback, artist remodels, designer scripts, artist makes pretty) where they're throwing levels back-and-forth over the wall like bricks, you get real teamwork.  This is something I've been trying to make happen ever since Spider-Man 1 and always failed.  With Spider-Man 1 we put artists and designers in the same room, but they weren't talking.  Rather than work out why not, I lost the battle and we went back to scripters in one room and artists in another.  The reason it didn't work is obvious in hindsight - we put them in the same room but they weren't working on the same levels!  Duh.  Spider-Man 2 we tried virtual teams - put them on the same e-mail list, had regular meetings, and although this helped, it still wasn't great:  still, one person would typically be working on the level at a time, and resources such as sound and QA that wouldn't be tapped for a while were coming to the meetings but unable to participate.  Things got even worse during my short stint at the beginning of Spidey 3, when all the leads started wanting to come to all the level meetings, so you'd have these comical meetings where the two people who mattered (an artist and a designer) would be discussing their level while one or two art directors, one or two creative directors, a lead designer, and a producer watched.  (On ME2, they do regular level review meetings where the leads check out the level and provide feedback, but they're not always in your dish.) My ultimate solution was to quit and start making a small game to feel like I was working on a Team again.  I still didn't fully "get" Bioware's system - they said they'd put three artists and three designers in the same room - with our tech, it was really inconvenient for more than one artist and one designer to work on a level at the same time - I thought Unreal was just as bad, but maybe I'm mistaken.  Or maybe the mixed teams are working on 2-3 levels at once.

Something that I've noticed a few places lately is timeboxing level development.  High Moon and Bioware Austin do kanban;  the ME2 team doesn't do kanban but they do timebox.  They take their level through various stages of completion with a regular heartbeat, and I forget the actual stages which is a good thing because you'll want to tailor your own stages for your own shop, but it's something like

- concept (writing, concept art, 2d map)
- block world, with dialog and encounters put in as big text boxes (you can check pacing, feel of level already)
- untextured mesh world, combats at "alpha" - no cover yet, enemies don't even shoot back, animatics
- dialog is in, combat is at "beta" (cover & AI active), music in (he said you needed music at this point or game felt anemic - I do the same thing when I prototype, you have to have music in your prototype even if it's just a programmer-art white-box prototype)
- could ship it if you had to - voiceover is in (they bring in their main actors [to a Hollywood studio] many times during production - not something you can afford to do when you hire, say, Tobey Maguire, but it works for them) - texturing, lighting, animations
- "Bring The Awesome" - an extra timebox to give a level that special something.  But they also said they haven't gotten a level to this stage yet.

The length of the timeboxes they arrived at empirically, by putting some levels through the process and using that as a benchmark.

They said it was worthwhile to do deep-dives on some levels while also building all the levels to playable, because upon playing the whole game even in blockworld it revealed the interest curve of the whole game needed a bigger bang at the ending. 

Being a programmer, I always used to rankle at the idea of timeboxes.  "How do I know when it's going to be done to the level of quality we want?"  Over the years, I've come to accept that artists are totally okay with timeboxes.  With designers, it's okay if they're "in the box", placing encounters and drops and doing stuff by-the-book, but for a special-case gimmick level a timebox is probably trouble.  Of course, special case gimmick levels are bad ideas, period, (and Kaplan said the same thing in his talk) - create systems and let the designers work those systems (which is what we did with Schizoid) rather than have a bunch of special case scripts where each level is kind of its own game (Spider-Man 1 and 2, where the level quality was variable to say the least.)  So I'm ready to give timeboxing level development a try.

"No Excuses" : GDC vacation ultimate takeaway!

Pardon me while I name-drop.  We had the chance to talk with Rob Pardo some at DICE and GDC, and from a couple of anecdotes I'm going to make a sweeping generalization - a reason Blizzard outclasses us is because the sorts of problems that I'm tempted to just make excuses about they actually solve.  The example from DICE was a discussion about ladder systems:  my feeling used to be "Use ELO" - like the true skill from Halo matches.  Rob Pardo doesn't think ELO is fun.  Which is the point where I start making excuses:  "It's good enough for chess, for Halo, it works, it matches you with someone at your level."  

But he's got a point - ELO has a number of issues:

It's fun to watch your ranking go up at first, until you hit a plateau, at which point the game can lose interest unless you're one of those "love the plateau" people.  Again, I feel the urge to make an excuse:  At least it's fun at first!  It least it gives you motivation to keep playing for a while!  

And whoever is the best doesn't want to play again, particularly if the game has some variance.  All that can happen is their score goes down.

(I've been playing Spectromancer a lot lately - I suck - but one thing they do notice on the system is that good players create new accounts for themselves so they can smurf - and have the fun of climbing the ladder again.)

I'm not going to tell you how Blizzard plans on solving these issues for Starcraft 2 - that may have been confidential.

One thing that isn't confidential, which was in Kaplan's WoW talk, is "progressive percentages."  It's something they use on the drops during a quest in WoW - if drops were purely random, you'd end up with a couple of problems:

First of all, people are pathologically bad at recognizing true randomness.  When you give someone a list of truly randomly generated numbers or coin flips, they'll see the streaks and often say, "That's not random!"  (How many times have you heard somebody say that about their mp3 player or CD changer?  Problem with random shuffles is often that they actually *are* truly random!  (Though I once had a CD changer in my car that I was so sure wasn't random that I took the trouble to write down every disc & track it played for a while and did a chi-square (well, I asked Mark Nau do the chi-square) and was vindicated - it really did favor a couple of tracks much more than the other tracks, statistically significantly.))

Second, some people, some of your players, will get screwed by randomness.  They'll get bad streaks.  1 out of 32 of your players are going to flip the coin five times and come up with "no drop" every time. 

And they'll come to the programmer and say "Your random number generator is broken."  (Apparently in the early days there were a lot of these sorts of reports on the Blizzard forums.)  And here's where I make my excuse:  when someone comes to me and tells me my random number generator is broken I say, "No it isn't, you're just suffering from the all too human tendency to not be able to recognize truly random numbers."

But it doesn't matter if it's broken or not, all that matters is it *seems* broken.  And the guys at Blizzard fix it.  They don't want to lose that 5% of players who happened to get enough of a bad streak that they decided to quit playing.  But they want to keep some of the feeling of randomness in there.  So - progressive percentages.

Which work like this:  say you want an approximately 50% drop rate.  Instead of it being 50% every time, you make it something like 33% the first time, and if they miss, you make it 50% the next time, and if they miss, you make it 66% the next time, etcetera.  When saving the game from bad streaks you need to be careful you don't kill the good streaks as well.  

Not technically random at all!  But cool, huh?  Blizzard doesn't even let the nature of random numbers mess up their games.  I tell you, next time I find myself saying to some playtester, "Yes, I understand you think there's a problem, but there really isn't, and here's why..." I'm going to have to give myself a good kick.

GDC vacation continued

More from PURE:

1) Rayleigh Light Scattering (whatever that is) looks better than standard hardware supported linear fog.

2) Spherized Normals (whatever that is) on trees made them look less dark.

3) Characters are lit by two hemispheres - a "sun" hemisphere and "ground light" hemisphere.

The Illustrative Rendering of Prince of Persia:  Ben Mattes & Jean-Francois St-Amour

To outline characters, they render twice, first time backfacing with a screen space expansion that artists can control to prevent moustaches.

To get an illustrative look, they do edge detection:  the screen is composited with an edge detection of the screen.  BUT they do not want characters edged, they just want things like, say, shadows of characters edged - so the characters mask themselves out of the edge render before its composited.  

Going from a corrupt world to a sunlit world was mostly a color space transformation - during the transition, objects on the edge sampled a texture to decide which pixels were corrupt vs. uncorrupt.

Mixing Audio: Garry Taylor

1) There's focus again - the audio mix can focus players just like a light.

2) A useful tool, that Killzone 2 has, is being able to mix live while the game is playing and then save a snapshot of the mix.  Sure beats the hell out of quitting the game, going into XACT or whatever, rebalancing everything, then playing the game again - though as a friend pointed out - "Sounds good if your audio technician is your bottleneck resource."

3) Ducking music and audio when VO comes on?  Here's an idea - have the volume of dialog key into a compressor which the music / SFX go through.  I can't quite imagine what it would sound like, myself, but sounds interesting.

4)  Mixing audio should be on the schedule.  (That's my own note.)  Motor Storm took 3 days.

5)  Be able to trigger different mixes via events.

Pairwise Testing:

My main takeaway was "sounds interesting" and there's a website:  pairwise.org

Now Sofi wants me to play Peggle.

What I learned on my GDC vacation

So many people at GDC told me they like the blog that I felt guilty for not writing anything lately.  So here are my GDC takeaways.

Mostly we were pitching.  The game we're pitching, a new Richard Garfield game, has gotten the best response in pitch meetings I've ever seen - we may even be able to sell it on the design document alone.  I can't put my finger on why, but it's an idea that's both fresh and at the same time obvious, and it's something we can do for a relatively small budget, so maybe that has something to do with it.

I tended to go to sessions in topics I know nothing about, figuring I'd learn more that way.  So I went to some art and audio sessions. Not sure that's the wisest course of action - if I learn one thing in a design session, it's probably something I'll be able to directly apply, but if I learn a whole bunch of stuff in an art session, will I find a way to use it?

Focusing a player's attention was a theme in three talks I saw - a lighting talk, an audio talk, and Kaplan's World of Warcraft Quest talk.

The Iwata talk -

1) the prototype for Wii boxing was just made up of colored blocks.  YES!  This is just what I was on about at my leadership forum prototyping talk.  Gameplay first, art later, a necessary step on the way to vertical slice that too few people care about - they get hung up on art.

2) he made it sound like their kill rate was lower than I would have expected - saying Miyamoto games sometimes linger in the prototyping stage for over 2 years, that *sometimes* they get abandoned, but even then the experiment may show up in a later game.  Maybe the kill rate for Miyamoto games is lower than the average kill rate for other Nintendo experiments.  Anyhow, this is one of the ways Nintendo takes the sting off of killing a prototype - the feeling that it's not thrown away, that it might be brought out of the vault at a later date.

*Lighting With Purpose*, by Jay Riddle and Paul Ayliffe - 

1) artists always have better slides than programmers

2) if you haven't started using global illumination, use it - if it's good enough for Hannah Montanna it's good for us

3) light is one of the many ways you can focus a player

4) lighting (and light color) should change as you go through level - for flow, to pull you through emotionally.  See Cinderella, the disney movie.  Turok had a "color script" for this purpose.

5) 4 F's:  form, feel, focus, flow.  (and PURE's 3 V's:  vistas, vertigo, verticality.  Next time I'm making a game design bible, maybe I should come up with a clever acronym or alliteration to get my vision across...)

6) Characters and world should have different lighting rigs / setups.  They said the same thing at the Prince of Persia talk.  It seems obvious now that they say it, but the last time I worked on a renderer I was trying so hard to make the character lighting look like the world lighting it didn't occur to me you might want it to be different on purpose.  PURE used it to do rim lighting, for one thing, and PoP used it to give characters a higher ambient light.

Sofi wants to play WebKinz now, so more later.

How To Vote

I had some trouble seeing the Xbox Live Arcade Awards Voting thingy on my xbox and had to call Bill to have him point it out for me:  when you're in the xbox dash, go up to the Game Marketplace row, and it's a few panels over --  "The 2008 Xbox LIVE Arcade Awards."  Download it and then you can run it from your game library.  Vote Schizoid for a better tomorrow.  (And it looks like you can vote once for each LIVE profile on your system, even if they're silver.  Stuff that ballot box!)