by James Somers, February 23, 2010
About two years ago I was introduced to j-archive.com by a couple of friends who were “playing” one of the thousands of Jeopardy! games hosted on the site. What they were really doing, though, was rolling a mouse over each of the clues—laboriously typed up and submitted by nerdy volunteers, who have so far archived more than 3,300 actual episodes—and sort of quizzing themselves. There was no frantic buzzing in, no score-keeping, no wagering. It was a fraction of the fun that it could be.
One of these friends of mine, thinking that I was a more competent programmer than I actually was, suggested that I build a playable version of this wonderful archive. I considered it for a moment, convinced myself that it would be too complicated and difficult, and declined.
Fast forward six months, and, with the same friends, at the same house, under essentially the same circumstances, we had the exact same conversation. But by now I had one or two modest Rails projects under by belt, and the idea seemed quite plausible. Simple, even.
I made no promises, but that night I spent the next two or three hours before bed thinking about my approach, and the next day I set to work in a frenzy fueled mostly by the prospect of surprising my buddies with a minimal version. Six or seven hours later I had one, and though it was only stocked with about a hundred episodes, had no final jeopardy, didn’t include wagering or daily doubles, and was littered with all sorts of little bugs, it worked, and my friends and I got a huge kick out of huddling around the laptop and competing.
It’s often said that software is best developed incrementally, with lots of feedback from users. That way you can slowly ratchet your way up to a product that people actually want, rather than trying to blindly design a perfect system ab initio.
This is exactly what happened with what I ended up calling “Jimbo Jeopardy!” We’d be a few games in and someone would suggest that I add indicators for whose turn it was, or they’d remark that it’d be neat if I added the “think” music to final jeopardy. So I’d step aside and hack away for half an hour or so, add the feature or fix the bug, and we’d get back to playing. If the request called for something more involved—like when I was asked to add “correctors” that would (a) display the outcome of each question and (b) allow players to tweak scores (if someone mistyped an answer, for instance), or to change the algorithm that decides when to allow players to buzz in—I would take a late night or two before coming back with a new-and-improved version of the game. So I was continuously debuting new ideas and encouraging different people to try it out.
I knew I was onto something when people would call me asking if I could bring the laptop by to play. The game was fun. More fun, I think, than the official versions of the game that Sony puts out. Why?
- For whatever reason, they write new clues for the computer games, and because it takes a long time to write new clues, there aren’t that many—they boast about having “over 3,000.” Jimbo Jeopardy! has 187,217.
- As a corollary to the first point, the clues in these official games aren’t culled from actual episodes, so they don’t necessarily cohere in the right way. What people want is to play games that are just like the shows.
- Finally, all of the officially licensed versions of the game use a multiple choice guessing system. Needless to say this was a terrible decision, since it makes every question about an order of magnitude easier than it ought to be.
Even though I had built the game in Rails, and even though my friends would ask me from time to time for versions they could play on their own computers, I hesitated for a while to put the project online. Instead, I actually installed my full development stack on several friends’ computers, Mac and Windows, so that they could play without me; I created clickable icons for the commands that started the server, and even tied the project folder to a Dropbox so that I could synch code across systems. This, in retrospect, was a laughably ridiculous hack.
So when I got some spare time after graduation, I finally pushed the code to jimbojeopardy.com.
About a month or so after it “launched,” a friend of mine who was slated to appear on the real live version of the show asked if I had something he could use to study. I thought the version I had up at that point was adequate, but that it would be nice if there were something geared a little more toward deliberate practice.
So once again, I spent the next night trying to surprise a friend with something cool—what ended up being the “Blast!” version of the game. There you can carve out a list of questions from the database based on whatever dollar amounts, seasons, categories, or search terms you’re most interested in. The system then creates a rapid-fire “flash card”-style single-player timed game, at the end of which you’re quizzed on the questions you skipped or answered incorrectly.
Anyway, I’m constantly tweaking the site, trying to fix bugs, keep load times down, etc. But there is still lots of work to do. In particular, I’m planning to build tools for aggregating analytics about which questions and categories are hardest, what people guess for each clue, how much they decide to wager in various situations, etc.—with versions that let users track their own play, too—and if I get the time, I’d like to make a version that will let people play over the web, rather than having to all sit down at the same computer (even though it’s arguably more fun with friends in the same room).
I encourage you to try it, and, of course, to let me know what you think.