Category: Bad Ideas
I’m not a novelist. I can write, and with sufficient editing, I can even write passable English text, but it’s not really something that I’ve put a lot of effort into, and so not something that I’m good at. My real time investment in writing has been writing software, which is read only by compilers and interpreters, and so what it lacks in excitement, narrative, and plausible dialog, it makes up for in conciseness and precision.
My ideas for National Novel Writing Month (November, for those as don’t know) then, are coding a program that writes novels, and coding a program that takes novels as inputs and generates interactive fiction (text adventure games) from them. Both of these are problems with infinite hair, and are arguably AI-Hard problems (that is, problems whose solution is on par, difficulty-wise, with creating a human-level general-purpose AI). On the other hand, writing a good novel is probably also quite hard.
I think the most reasonable approach for the novel generator would be a recursively-defined novel description language, which selects from tropes and plot stubs, generates characters, and so forth, based on relatively simple rules. The complexity would come from applying the rules over and over, so a simple quest to throw a ring into a volcano grows branches on branches on branches until it is One Damn Thing After Another Until All The Orcs Are Dead. The goal of the program would be to use generative content and emergent behavior to do most of the writing, and leave me to fill out the turns of phrase and details (or generate them a la Dwarf Fortress, which menaces with spikes of ivory). Done badly, this would read like a Mad Lib. Done well, it would read like a Mad Lib filled out by people who don’t say “dongs” every time they are asked for a noun.
Making interactive fiction (IF) out of novels would be substantially harder. The novel parser would have to read English, which is actually quite a trick. English has multiple words for one meaning and multiple meanings for one word, highly flexible structure, and counts on the reader to sort it all out. On top of that, most of the awesome tricks one can pull in English are more a matter of exploiting shared cultural context with your reader than they are particular sequences of words. If I wrote such a parser in one month, or at all, a lot of linguistics researchers would be out of work.
Assume I went for one tiny part of the problem: identifying the locations in the novel. The same place might be described as “where that party was”, “Joe’s house”, “the darkened house”, and “a pit of iniquity”. Only the events of the novel link them, and so the program would have to determine that these totally different words referred to the same place. The best approximation I could likely come up with is identifying all the things in the novel that sound like places, and then performing some sort of clustering based on what words are mentioned close to mentions of those places. This would likely lead to a bunch of spurious places getting generated, and real places getting overlooked. There is an entire company, called Metacarta, that did this sort of analysis on much more constrained data sets, and even then it was a difficult problem for a team of people who were likely smarter than me.
However, doing a good job of adapting novels to interactive fiction might not be the best approach. It might be better to get a rough cut of the software together to do anything at all, and gradually improve it until it writes things that are playable curios, rather than detailed simulations of well-loved novels. It wouldn’t be a matter of playing through “A Game of Thrones” so much as it would be “poking around in a demented dreamscape based loosely on ‘A Game of Thrones'”.
This is actually related to another idea that I had, which is sort of a rails shooter based on the consequences of shooting things. You play through the game, riding the rails and shooting enemies of varying levels of craftiness and menace. When you reach the end of the level, you just loop through it again, passing the bodies of everything you killed, and getting another shot at everything you missed. This repeats until you have killed everything in the game world, whereupon you continue to loop, passing through scenes of slaughter as the heroic music fades and is replaced with silence and the buzzing of flies. Perhaps, if you let it run long enough, the dead bodies would rot to skeletons. Now, of course, I’ve spoiled it for you, but I’ll probably never get around to writing it, so at least you’ve had the idea.
This is the talk I gave at Notacon in 2008. It’s kind of goofy, but provides a broad overview of wireheading/neurohacking technologies.
I am working on a portable projector to take to an arts festival in Toronto. I was planning to power it from a 12V lead/acid battery, which would be stepped up to 110VAC by an inverter, which would then be stepped back down to 36VDC at 3A (regulated) to drive an 8000 lumen LED. Tonight, I hooked up the LED, inverter, and battery. It almost works, but the inverter is too wimpy to drive the LED. Instead what happens is there is a brilliant flash as the LED lights, the inverter output voltage drops, the LED driver resets, and then there is another flash and the cycle repeats.
Obviously, this will never do. The inverter is supposed to be good for 140 Watts, and so driving a 100 Watt LED sounds like it should be a piece of cake, but at 110V, the extra 40 watts is really only 360mA (W=VI, so I = W/V (Sort of. For non-resistive loads, there’s power factor correction)). If there’s any extra draw in the LED driver as it starts up, it could eat that right up. It’s also possible that the power rating on the inverter was simply a lie.
Switching to a 200 watt inverter didn’t fix the problem, nor did adding a 17,200uF capacitor in parallel with the battery. However, I did check the battery voltage immediately after running the system, and it was around 11.3V. That’s mighty low for a 12V SLA, so I’m going to borrow the 12V battery charger from work and try it on my batteries. It may be that I just didn’t have a sufficient charge. If that is the problem, it may mean I need to switch to a halogen spotlight, as the 12V batteries may discharge too quickly.
When I added the ICSP header to my ToyBrain boards, I mirrored the footprint so that some of the routing would be easier. I did not, however, correct the actual wiring, so now the ICSP header comes off the wrong side of the board.
This is going to be easy to fix in the next revision, but for now I’m going to roll up a little adapter to get the boards programmed.
More later, when it’s closer to noon than midnight.
I was reading up on HTTP status codes, and I got a bad idea. There are a small number of official status codes, like the ubiquitous 404 (file not found), an even smaller number of less-official status codes, like 418 (I am a teapot), and a lot of undefined status codes.
So what happens if a browser gets an undefined status code? What if it gets a malformed code? Writing a simple test for this would be easy. It would just be a web app framework that returns whatever you pass it on the URL as the error code, so www.example.com/errorCodes/200 would get you HTTP OK, while www.example.com/errorCodes/499 would get you the undefined code 499.
I would hope that the browser runs the code past its short list of defined codes, doesn’t recognize it, and shows an error page to the user saying something like “The server returned an invalid error message. It may be misconfigured. Please try back later.”
However, some browsers may mishandle the message, and hand anything that starts off with, say, 2xx to the page renderer, whereupon things might go horribly awry. I hope modern browsers are immune to this sort of shenanigans, but it may be no one has beaten on them in that particular way.
The Seizuredome light is an icosahedron made out of aluminum. Each face is 5.5 inches on a side, so the whole thing ends up being about the size of a soccer ball. Each face has three 1″ aluminum spikes sticking out of it, so that when it is not hanging, it does not rest on any of the LEDs.
The light started life as a sheet of aluminum, 24″ on a side. I plotted the net of the icosahedron by constructing a bunch of equilateral triangles with a compass and straightedge. Geometry class is only useless if you’re not planning to make anything interesting in your life.
After that was all plotted out, I cut it out with tin snips and cut arcs out of the corners with a nibbler. The arcs will make the finished shape have a hole at each vertex. Those holes are where I will run the wires for the LEDs, but they also let me more or less ignore the thickness of the material, which would otherwise possibly make the corners look bad.
Then I drilled holes in all the pieces. The holes in the faces are for LED and spike mounting. The ones in the tabs are for rivets that hold the shapes together.
I bent the flat shapes in an improvised metal brake to get them 3-D, and then riveted them together to hold the shape.
The finished shape seems to fit together pretty well.
I added more holes for sheet metal screws. I also added a flat plastic platform inside, so that the electronics have something to rest on, and screwed the spikes to the outside. The spikes are intended to be ornaments for punk clothing, but they mount with screws, so you can stick them on anything you can drill a hole in.
The electronics are also mostly together. I just have to finish up the code, and then mount the control circuit inside, the LEDs outside, and add a power switch.
I started this blog to keep a sort of running list of what projects I have going on and my progress on each of them. Instead of doing that, I’ve been working on the projects and ignoring the blog.
My main project right now is the Seizuredome. The “dome” part is an icosahedron made out of electrical conduit. Five of the faces of the icosahedron are left off, and it rests on the ground on that side, forming a sort of dome. I used the construction techniques from Desert Domes to build the frame, but the process is essentially flattening the ends of the pieces of pipe and drilling holes in them so they can be held together with bolts. There is a picture of the completed dome frame in a previous post. That frame will be covered with mylar “space blankets” to provide a reflective surface.
The “seizure” part of the dome is a little more complicated. If you close your eyes and look at a bright light, you can still sort-of see the light, as a red glow through your eyelids. If that light pulses in the 5-20Hz range, you would expect to see the blinking through your eyelids. Instead, most people end up seeing colorful patterns, like swirling fractals, tye-die designs, spiderwebs, and such. What happens is that the blinking signal is close enough to the patterns of electrical activity in the brain that it can drive the dominant frequencies of neural activity to synchronize with it, resulting in hallucinations and mildly altered states of consciousness. You can buy goggles with blinking lights in them, or make your own devices, which will allow one person to do this. I’m building a photic driver for multiple users.
The Seizuredome will have a bright red strobing light in its center. This light is made of 20 1-watt red LEDs mounted on the surface of an aluminum icosahedron. Each LED is driven by a constant-current driver, which is controlled by a TLC5940 LED driver chip. The TLC5940 chips are controlled by an Arduino. Power for the whole thing is supplied by a LM7805 supply with a beefy pass transistor. That light will be hung inside the reflective dome, illuminating the inside. Since the light is suspended inside a reflective dome, there will probably be no place inside the dome that isn’t strobing red, so users inside the dome will be able to see the psychedelic show by entering the dome and closing their eyes.
That still doesn’t really answer why I called it the Seizuredome, though. I turns out that some people are photosensitive epileptics, but don’t know it. Strobing lights of the frequencies most likely to cause seizures by interfering with neural electrical activity are rare, and don’t usually last long enough to trigger seizures. As a result, it’s possible for someone to grow up without ever seeing a blinking light that is intense enough for a long enough time to cause a seizure.
This is the framework for a geodesic dome. It will be wrapped in mylar blankets to make the interior reflective and lit with a very powerful red LED strobe. Anyone inside it will be able to get brain-machine-like effects by sitting and looking at the strobe.
Of course, it could also cause seizures in previously undiagnosed photosensitive epileptics, so there will have to be warning signs.
Now available at my GitHub repo. Note that using these scripts is probably a horrible violation of Wizards of the Coast’s ToS for their website, and can probably get you banned.
Captchas are those distorted snippets of text that some web sites use to try to prevent spammers and bots from automatically registering accounts. The idea is that a human can read the words, but a computer cannot, and so only a human can fill out the text box correctly.
However, it’s probably possible to get humans to crack the captcha for fun. Imagine a “missile defense” typing tutor and game, where each incoming missile is a captcha text. If you type the text, it goes away. Since the game can’t tell what the texts are to begin, it would send the same word to multiple players and only block the “incoming missile” when multiple players typed in the same thing. From that, it could build a massive database of images and corresponding text, which could then be used to register accounts. Alternatively, someone who wants to crack a captcha could submit it to a server, which would then include that captcha in all the currently-running games and reply with the text when several people typed the same thing.