"We didn't step on this kid's rights."
From
here. Also notice how he was slapped with threatening to use weapons of mass destruction.
Also, on the school system site there's now
this. Which solves the problem,
in fantasy land.
Eats Like a Meal.
God of War II has more examples of didactic design done right in its first hour than any other game I've ever seen has in its entirety.
It is also a very good game.
After a long hiatus, Jeff and I finally updated
Vocabulicious last week. We're pretty excited about this release - 15 months in, the game has left its bare-bones roots behind and fast approaches "
casual game" status. (Ooooo.) A new feature in this release provided an opportunity to revisit the player's workflow, so that's what I'm going to talk about.
The initial version of the game had no high score table, so the workflow diagram looked like this:
The user chose either a timed or untimed game, and then played the chosen game until he or she lost (failed to finish the round). Upon losing, the game cycled back to the game-type selection screen.
1.03 added a high-score list for timed mode, which necessitated the ability to enter a name when a high score was achieved:
To reduce the hits to Jeff's database, the game remembered the lowest score on the high-score list upon starting a new game, and it determined whether or not a high score was achieved by comparing to that stored value. If the player's score was higher than the stored value, the game prompted the user to enter his or her name and upload the score. This system worked fairly well, but it had a few drawbacks that degraded the experience over time. First of all, the name entry prompt wasn't really in the ideal place for a game that involves rapid typing: many users typed right over the "Congratulations! Enter your name" prompt, resulting in wrong names (or "Player", the default) being credited. This was certainly a problem, but another, larger one soon grew to overshadow it.
The original purpose of providing the public high-score board was to promote playing the game. Unfortunately, the naive method of simply listing the top ten highest scores ended up turning the list into the "top ten scores from the highest-scoring players" list. The high-score list became dominated by one or two names, and pretty well shut out everyone else.
After a robust debate, Jeff and I arrived at a solution: turn the "high-score" list into a "high-scoring player" list.
This list shows the ten highest scores
achieved by different players. We think this display is much better: it'll be more resistant to abuse, as it incentivizes sticking with a single name, and it lessens the effect of a player who simply plays more rounds than anyone else.
Unfortunately, this approach also has a big workflow drawback, because it makes determining whether or not a player has achieved a high score more difficult. In order to know whether or not a player has broken a record, we need to know the player's name while he or she is playing. We need to associate a name with the player up-front.
We didn't want to do this, because it makes the game more difficult to just jump into. It makes it less "pick up and play." We've tried to mitigate this by saving the player's name, and just prompting for confirmation on subsequent startups. This makes the login procedure a one-click procedure for repeat players, but it's still too bad. The alternative, using the saved name by default and just allowing the player to edit the saved name, may end up being the smarter move in the long run. Time will tell.
This approach hasn't been all bad news, though. For one, we no longer need to prompt for name entry when a player beats his or her record – since we already know the player's name, we can just go ahead and upload the score. This makes the end-game scenario simpler, and also decreases the likelihood that a wrong name will be entered by accident. That's nice.
This approach also allows us to keep track of a player's personal best, even if he or she isn't on the high-score list. By knowing the player's name on startup, Vocabulicious can always provide the highest score the player has achieved. We think this is a nice touch.
And finally, this approach hopefully lets us avoid a username/password authentication system (which causes all sorts of headaches, and adds all sorts of complexity), because logging in under another player's name doesn't allow an attacker to do any harm. Worst case: an attacker can increase a victim's high score. The horror.
My man
Jesse Kriss sent me a link to his research group's collaborative data analysis site,
Many Eyes, but of course I've put off writing it up for weeks. Well, now it's on Slashdot, so .. it's probably been long enough. Sorry, Jesse.
Many Eyes is a site wherein users contribute data sets, visual analyses of said data sets, or both. The user-contributed visualizations are customized from stock types, from simple charts to complex node-and-edge graphs. It's an interesting idea, in that it provides both a convenient place to go for weird data as well as an easy gathering point for discussing and contesting the resultant analyses.
To put on the poop hat for a minute, it is somewhat concerning that the range of visualizations will almost certainly end up producing
incorrect assessments of statistical likelihood, but I suppose the appropriate response to an incorrect analysis on the site is just to link to a better analysis from the same data set. Aside from that (and
the other common criticism), though, it's a great idea, and well implemented. It'd be nice to get some data on game console sales in there; that might
shut Sony up for a few minutes.
The Internet houses many remarkable things. One of these is
retroactive source code for the original NES Metroid. This document was created by copying a Metroid game cartridge's binary data, and reconstructing a reasonable facsimile of the original game code from it. Then, and this is pretty ridiculous if you've never tried it, this guy sat down, read all of the code,
figured out what it all did, and commented it. That's dedication.
(And if you liked that, check out the same guy's excellent, lucid
explanation of the Metroid level rendering system. This proves pretty well that he did in fact figure out how the game works.)
IBM has some great
whitepapers up regarding PS3 Linux and basic Cell programming technique. Of them,
part 1 of the high-performance applications series has the best blend of code and explanation. Search for "Listing 1" to see a code snippet that really says it all: threads are created, sent off to the SPEs (the seven "synergistic" independent processors), and then waited upon for results. Architecting any kind of application around this model sounds difficult, but it's still cool to see the basic structure laid bare.
