Code By Number | codebynumber.com

I am as excited as anyone else about Will Wright’s next game, Spore (gameplay video). And I’ve been excited for over a year, ever since the first screens came out.

I am also excited about the idea of emergent gameplay. Two of my favorite designers, Will Wright and Warren Spector, are both exploring the emergent and non-linear gameplay in a way that is very different from other games, including each others’. But they also implement the concepts very well, in my opinion, managing to minimize tedium and maximize challenge and control.

So it is with mild disappointment that I hear this in Forbes’ article about the game:

“It’s an epic game,” said Wright, who estimated that it would take a gamer 79 years without rest to play out every aspect of Spore. “The biggest challenge will be making it seem accessible to people.”

I call ‘BS!’ I’m sure he’s arriving at that number through the combinatorics of his genetic algorithms and non-linear storyline. And I’m sure there’s some validity – there must be a lot of variation, and branches of the game go off in wildly different directions, I’d bet.

But consider this gameplay situation: you’ve played branch A for 10 hours and in the last 30 seconds, you take fork #1. Cool, you reached one of the endings. Now, to take fork #2, which is only different in the last 30 seconds, you still have to play through branch A to that point. But you cannot say that it takes 20 hours to play out every aspect of the game just because of some forking down the line.

On the other hand, if it’s true in a ‘common sense’ evaluation, I tip my hat to Mr. Wright and apologize profusely. But at the same time, I doubt the design behind a game that would take years to play out to conclusion, in the same way I doubt the editing skills of an athor whose book is more than, say, 5 times the size of most novels.

So here’s a problem which I imagine is common for any blind or visually impaired student or scholar: Many academic books are not available on tape through the Library of Congress. So the solution is frequently to get a hard copy of the book and scan it, page by page, into a computer. Then the user performs optical character recognition (OCR) on the scanned images to recognize them as text.

My experience in this case is limited only to Kurzweil 1000, version 8.5 (2 upgrades behind the current version) because that’s the software my (blind) partner uses. So Kurzweil does a decent job recognizing the text, automatically orienting the page, recognizing the language, and converting it to its own proprietary format (which appears to be a text file with additional tags before each word that indicate phonetic pronunciation, or something similar). Up to this point all is well and good. Here’s the problem: In academic books, there are footnotes at the bottom of the page, and Kurzweil doesn’t recognize them as such, and treats them no differently from the book’s text.

The footnotes make the book annoying to read at best, and impossible to understand at worst. The other day, after my 3rd hour of removing footnotes by hand (scroll down, silence the reading, identify the garbled text, select it, remove it, repeat), I got to thinking – there has to be a better way. I have some ideas for simple heuristics to determine what is a footnote, and a few ideas of blue-sky improvements that would be very spiffy. So my current project is to create an application (Java for convenience, portability and, of course, accessibility) that will be a utility designed to help with editing plain text books that have been OCR’d.

Here are the purposes of the program:

• Allow users to edit a scanned book in Kurzweil’s .kes format or in .txt format
• Provide footnote removal tools with adjustable sensitivity/aggression, and the ability to preview the changes
• Provide regular expression search and replace, with some useful pre-made replacements
• Maintain a dictionary of replacements similar to Kurzweil’s “Apply Corrections” function, but with added functionality
• (Maybe) Display frequency-weighted spelling mistakes and the ability to replace them all

And here are some loose initial requirements:

• Accessible to blind and visually impaired users
• Preserves .kes formatting and allows editing without seeing .kes markup
• User-friendly, correct, robust
• Open-source (license to be determined)

As soon as possible, I will be uploading screenshots (well-described, of course) and writing about design decisions, implementation progress and eventually interesting code snippets. Next up: the basic User Interface prototype within a week.