After that talk, I went to a few shorter lectures, one on designing player failure and one on the paper prototypes of Spore. The failure design one was interesting because the guy was a games researcher at MIT and he discovered that the idea that casual game players hate failing is a myth. It turns out that it matters less how many times you fail, but more on how failure is treated (ie, what's the failure cost). Failure cost was figured out by multiplying the failure count (how many times you fail), failure communication (was the player insulted when he failed? Encouraged? Merely told he failed?), failure setback (how much time did the player just lose because of that failure?), and the failure repitition (do they repeat the same game as in Mega Man when they fail or is it more randomized?). Another interesting point was how if you play a game, you like it, you want to show it off to a friend, you play really well at it, and then they lose horribly, your friend is going to hate that game because they feel like they're the only one who is bad it. I've lived this example with Ticket to Ride. I don't like that game because the first (and only) time I played it, my brother and sister-in-law did so much better at me that I just lost all interest in that game entirely. It was no fault of my brother or sister-in-law, that's just what happens if the failure cost gets to high for someone...or something like that...
The Paper Protoypes of Spore talk was interesting, but it had less to get from it. There were basically two slides of takeaway information, but that was near the end so he was blazing through it, which meant I didn't get to take very good notes. All I got is that you should make paper prototypes of your game's systems to balance them, you should focus on the key idea you're testing at the time, be abstract with your prototype (don't try and match the controls of the game, etc), it doesn't have to be fun (you're not making a sellable game with the paper prototype), and it helps build a vocabulary when discussing that system that just pops up when you start playing the paper prototype.
The second to last lecture I went to was about a state-based scripting system used in the PS3 games Uncharted and Uncharted 2. It was interesting, but I didn't take any notes, so I'm not sure what I learned other than that having a scripting system allows designers to do a lot of the work programmers would have to do. I'm not sure how we can use it with Delta3D since we A) don't have any designers and B) don't work on anything with more than one level usually, so it's just easier to program it.
The last thing I went to at GDC this year was titled "Games Have Feelings Too!". I'm really not sure what to pull away from this. Basically it was an hour long lecture about how game is art now, Citizen Kane was a failure at its time, so we shouldn't expect anything different with our Citizen Kane (ie super artsy game), and games evoke the more subtle feelings. Sometimes. It was interesting, but I didn't really get anything out of it.
Regarding scripting systems, they can always be useful if they're done right, and depending on what you're trying to program. It basically allows you to use really high level object oriented programming, which is always good. Among other things, it means when you change the code you don't have to recompile.
ReplyDelete