Paper Darts Choosatron Station

Paper Darts has been extremely supportive of my Choosatron project from the moment they heard about it. They wanted to do what they could to help, but at the time I just needed to get it to work. Once the first prototype worked (named ‘Argyle’) they asked if I would be willing to bring it to their Paper Darts Volume 4 Release Party (buy the book)! They also posted an interview with me about the Choosatron here. Both an incredible honor, especially for someone not used to being involved with the literary community of our fair Twin Cities. It also served as a fantastic deadline for the second prototype, and gathering submitted stories. I was able to convince various clever friends and talented writers to write stories for me, and managed to get three completed and tested before the event. I was working over the last few months to acquire better/cheaper hardware to build the improved second prototype (named ‘Bomber’).

The second Choosatron prototype.

Time has been sparse but I managed to get the guts of Bomber working before heading to California for work which took nine potentially productive days away. Once I returned it was four days until the event, and I still had no enclosure for Bomber, and I needed to write more code! At the same time I was making sure the three submitted stories (from Robert Valentine, Rob Callahan, and Wes Burdine) worked properly on the Choosatron…this meant updates to my conversion scripts and other small fixes. I worked late Wednesday night, soldering at 4:30am, and half of Thursday right up until I had to leave for the event, but I made it.

Bomber is beautiful! I ended up using foam-core which looks very nice, is sturdy, and I could cut it all by hand. It also allowed for flexibility in design as I just tried different methods to mount and contain it all, until it worked. I achieved all my goals as it’s compact, components are secure, SD card is easy to access, USB port similarly easy, a functional coin return, and coin storage. I can continue to develop with it and easily transport it for demoing.

For the release party I didn’t have the keyboard screwed in, just taped from underneath, so people did freak out whenever they hit the buttons too hard and it popped through. I assured them it was fine and stuck it back on. The day after this was immediately corrected.

The most exciting part of the event was getting approached by the program coordinator for The Loft Literary Center, Jennifer Dodgson. After getting the first prototype working I loved the idea that this could be used as an educational tool. She asked me what I thought about teaching a class using the Choosatron, and I was dumbfounded at my luck! I didn’t know much about The Loft at the time, so only got more excited as I realized what an amazing place this was for teaching young people. Needless to say I jumped on the opportunity and unless it turns out no one is interested, I will be teaching “Interactive Fiction and Game Design with the Choosatron” next summer. Wordy title I know. Each student will get to build their own Choosatron, and write stories to play on them!

For me personally this is a big deal. I come from a family of teachers but haven’t had the opportunity to teach kids myself, but have always wanted to, so I’m excited about the personal growth I think this will provide me. It also means more reasons and deadlines to keep the project alive instead of putting it on the shelf to gather dust like so many other things. The future is bright for the Choosatron, and more so for it’s mission. I’m proud of what I’ve managed to make happen in a relatively short amount of time (especially considering this was a side, side, side project), and look forward to it’s future!

Bomber’s Guts

As mentioned before, two bits of feedback I wanted to immediately add are prepending the choice made as the new passage prints, and properly word wrap text so it’s easier to read. The logic behind word wrapping isn’t very complex. Start with how many columns you have available (32 in my case), take your first line of text, and from the end look at each character until you find a space. If one is found, set it as the end of the line (‘\0′ to terminate the char array), record the index, and print. Then start one past your index + columns (32), and do it all over again. If a space isn’t found, print all 32 characters since wrapping isn’t possible. Rinse, repeat.

It ended up being slightly more complicated in my case because of two reasons. First, to prepend the choice number creating an offset. If this was part of the text already it wouldn’t be an issue, but the text is loaded from flash memory on demand, filling its buffer, printing, and repeating until the entire file contents have printed. Of course this means we have the same offset problem every time we fill the buffer and have more to print since the column position could be anywhere in the line.

It was already late at night when I decided to tackle this issue, so I was annoying myself with some silly mistakes as I stepped through the logic coming up with a solution, and there were a couple ways I could go.

1. Only read the required number of characters for each line at a time. This seems like it would be helpful, but ends up being a pain dealing with the tiny bits of leftover that need to be tacked on the next line, and means a lot of file reads. Meh.
2. Do lots of memory copies to always send the word wrapping function the complete text to be printed. This is slower, and has a very high risk of running into memory limits if not done very carefully, and as a result will mean more file reads. It really just makes the problem it’s trying to solve worse. Argh.
3. Keep track of a ‘rewind’ character count. Load enough content to know if the first line should wrap, rewind to the position just after that wrapped first line, and load more content until the buffer is full. Then the wrapping function starts with a fresh line!

Of course, I didn’t have those and other ideas all together…the third was a fight to get to. There is also an ‘indent’ to make sure I can send variable numbers of columns for wrapping, useful in special cases. Moving forward!

Amazingly I got everything done and was able to show off my little contraption for the first time. At first everyone seemed a bit bewildered, not entirely sure what the damn thing was…but it sank in and people seemed to get really behind it. The impression I’ve gotten by everyone that’s touched it is that although it’s a very strange project, it’s also very unique and quite a bit of fun. I still only have my single test story written as I’ve been focusing on the hardware and software end, so I think with more and better stories it can only improve.

Choosatron’s First Home

Anytime you build a project that requires that others contribute in order for it to reach it’s full potential you’ve got a challenge on your hands. People are busy. Even the ones that LOVE your idea, and WANT to contribute, have plenty going on to make that difficult. The fact is that talented creative people are always in demand, and even the promise of getting paid isn’t necessarily going to change that. There are numerous other creative projects I’ve been trying to move forward that require design and visual work, but that seems to be where my progress starts to halt. I sincerely hope that the Choosatron doesn’t fall victim to this same blight. I’m too in love with the idea of collaborating to create work beyond one individual to let my hope die. We’ll see!

I brought it to work and did some user testing to see what people had trouble with, what they liked, and how I could tweak the experience a bit. There was some great feedback like implementing true word wrapping so reading is easier, and fixing the absurdly short time limit for continuing a story. I’m working on finished some of this sort of polish, along with internal logging so I don’t have to manually write down the choices people make, and how long it takes to play. There has also been a fair bit of interest in this potentially turning into a Kickstarter project, so people can purchase/build their own and the community of authors can grow. There are plenty of things I need to figure out before I’d consider that, but it would be fun! I’ve been researching how I can bring the cost down which has exposed some very interesting possibilities.

Along with that I’d like to look into interactive fiction formats that already exist (other than Twine) to see if I can open a big door by creating support for them. Even writing a Twine addon to natively support the Choosatron’s features (like autojump) would go a long way toward cleaning up the user experience as an author.

In the end, this project is really just the first in a series I’ve wanted to do, with increasing complexity and deeper exploration of story telling and game design. The intention isn’t to make a product to sell, but to explore immersing people using interactive applications to see what we might be missing in our current definitions and divisions of game, story, and genre. Of course, the next step might be getting the Choosatron into something a bit more permanent than a cardboard box!

So far the only vendor I’ve found is Alfa Zeta to purchase flip-dot components, and I’m currently waiting for them to get in touch with pricing. Would be soooo cool though. They have links to plenty of demo videos, but here is one that is an incredibly advanced use of flip-dots:

12v to 9v, 1.5amp Output

The Arduino and components directly connected would all be happy with putting in 12v and having the arduino regulate it, but the printer needed too much raw power and 5v ends up printing too light. So! What I needed was something to take the 12v down to 9v after powering the acceptor, while still providing close to 2amps of output. I did some research and discovered I wanted a voltage regulator, so decided to hit ebay. I first found the nice little guy to the right which was what I wanted except only giving 1.5amps. I decided to get them anyway because it was cheap and quick to ship being in the US. Who knows when they will come in handy, and it’s still something I can do some testing with.

12v to 9v w/ 3amp Output

I kept looking however, and found exactly what I was looking for. 12v to 9v, and 3amps output! There was a 2amp output as well, but since I found a 12v 3amp power supply I might as well be able to support it. This part was only available in China, but cheap so I purchased. It took 3-4 weeks until it finally arrived! I had gotten the L7809 regulators and verified that they did in fact work as advertised. Hooked it all up, printed, and got a faint lettering due to the lack of power. Just days ago I got the part I was really waiting for! It had been such a long wait I had already started doubting it would fix my printing problems. I had played around with running the printer on 12v, but it would print a little too fast, and though it was darker than with the small regulator, it wasn’t good enough and I didn’t want to hurt the printer.

Well, I plugged the new voltage regulator in, fired up the Choosatron, and wow…after all the hours with both the hardware, and programming the software, FINALLY seeing it truly work! Beautiful, rich text. Take a look below! Just in time too as I’m planning on bringing it by an Arduino group meeting this coming Thursday.

I also completely finished the points feature, getting continues fully supported (if ending quality 1-4 of 5, insert a coin to continue, get prompted for how many choices back you want to move), as well as authors getting to set what a ‘perfect score’ is, along with a ‘continue penalty’. Phew! So much awesome stuff. The writing guide is finally online, along with a test story I wrote to help people get started. Take a look here!

So dark and perfect!

First Perfect Print

Path 1: “…After singing along to the radio with your friend for hours, the cabin is finally in sight.”

Path 2: “…you awaken from the bizarre dream, your friend pointing ahead to the cabin up ahead.”

\/

“The gravel crunches under the tires as you park. It really is a beautiful cabin you think to yourself. Should be a great weekend.”

See what I mean? So with this in place I was able to play through, but suddenly…it stopped. Noooo! I happened to have a log statement outputting free kilobytes of memory before each passage is output, and it was heading steadily downward.

968…906…842…780…724…662…death.

No question, a nice juicy memory leak. A very consistent one losing about 62kb per passage. I walked through my code carefully, making sure that each path and passage element is correctly freed. Then I started commenting items out to keep the case as simple as possible. No change whatsoever. Only change was the memory leak was slightly less the more data I loaded in each chunk of the passages.

Choosatron Bits

Interesting…that means the fewer file.open() calls I make, the less memory is leaked despite loading the same number of bytes. At this point I did what any decent programmer would do: pick the best keywords for what I understand about my problem thus far, and google it. This, my friend, was a situation where something could have easily taken days to fix, but I noticed enough clues to find a problem I was not alone in. I immediately found an issue filed here: Arduino Issue 814. The gist is simple:

When a file is opened a malloc() is performed to get memory. When a file is closed the memory is freed. If the file object is destroyed before the file is closed, the memory is never freed.

File::~File(void) {
  close(); // <-- The FIX
  //  Serial.print("Deleted file object");
}

Hmm…my code looks like it’s closing files properly, but it’s worth trying the one line fix. I add it to the library, recompile, upload, run…968…947…947…947…947…and this continued to the end. Then I played again. Then I continued. NO LEAKS. This is one of the most incredible feelings in the world, especially when memory management is allll up to you. I’m using the Micro SD card as my memory (essentially) so not leaking it all over the place when I use it is a plus.

The Choosatron Deluxe Adventure Matrix™ software is working! It’s not done, but this is where it gets really fun. Getting people to write content for it, demoing it, and of course polishing the code and adding more features for authors to play with. Next step is setting up the power regulator, power input, and power button so I can take the experiment where the people are. Hopefully I’ll have it with me at CONvergence a couple days from now for some geeky attention.

Suddenly, which is code for ‘I did something seemingly innocuous with terrible consequences’, I was getting incredibly bizarre behavior where output would just cease. Sometimes it would get further along than others, which meant I didn’t notice immediately after making the change causing it. The first red herring was when, hours into debugging, I hit one of the keypad buttons used for input. It printed “INSERT 2 COINS TO PLAY”. But that means…it reset somehow! I read about how serial communication can reset the arduino, though I didn’t understand it correctly and tried to immediately blame this for my problem.

I ordered a box of capacitors, which I needed anyway, so that I could keep the arduino from resetting. I tried it and nothing. I then realized that this couldn’t possibly have anything to do with my problem and started again! Then I found that if I didn’t use the clever macro to store log statement strings in Flash memory, like Serial.println(F(“Flash string”)), it seemed to work again! Why it’s obviously the macro to blame, not MY programming! But things got weird again, just much deeper than before.

What…the…hell…

Well…early on my scheme for dealing with the data I needed to load involved opening a file at a path, loading all the data, parsing, and moving on. So I did something that even at the time was something I new was a bad practice. A char array is passed in, I use it for what I need, free it, and do my work. Do you see the problem?

byte getByteFromFile(char *path, unsigned long index = 0) {
  File file = SD.open(path);
  free(path);
  byte b;
  if (file) {
    if ((index != 0) && (index <= file.size())) {
      file.seek(index);
    }
    b = file.read();
  } else {
    _print(F("[ERROR] File not found: "));
    _println(path);
  }
  file.close();
  return b;
}

I’ll make it more obvious, though an experienced programmer should already be annoyed at what I did, a nasty shortcut. With memory constrictions so tight, parsing data was getting painful. Here I have virtually unlimited memory on the microSD card and I’m trying to do everything in 2k of memory! I changed my scheme to virtually eliminate the need for parsing by having a much more verbose directory structure. Not as human friendly, but micro-controller work rarely is, and it’s all generated by Python scripts I wrote anyway. It was so convenient to use the same path char array over and over…yeah, that’s right. With the function above, when you use it, it gets freed (line 03), and the caller doesn’t know that. NEVER MANAGE MEMORY FOR SOMEONE ELSE. Keep it in scope people. Removed the free and suddenly the world was sunshine and roses once again!

He Who Controls the Swede Controls the Universe!

Dune Shield Fight

What’s better than sitting around drinking in the sun on Memorial Day weekend? Filming a swede for the bizarre, technically complicated, science-fiction adventure directed by David Lynch, that’s what! If you haven’t figured it out yet, I’m talking about the 1984 film Dune. After months of preparation fitting in those spare moments between work and life we finally got to our weekend of principle shooting.

I’m happy with how smoothly our process went in terms of planning and preparation. Melissa, Brian, and myself (the three in charge), watched the film while taking notes about what we liked, funny quotes, and spoof ideas. Two days later Brian and I watched it again to write the script. Our goal was to have a finished script after only two viewings to prove that sweding even a complex moving was possible with schedules as busy as ours. I made a simple template in Celtx for each scene as we stopped and started the movie, condensing and poking fun. Here are the elements we captured for each scene:

• Shooting Location ID
• Characters Present
• Props Required
• Movie Timestamp for Reference
• Shooting Notes
• Script (Action & Dialogue)

Our template while writing the script made it very easy for us to organize locations, people, and props when we began planning. I’ll admit that I’m someone who likes control when working on projects, although I easily relinquish it to those I trust. I also get a little obsessed with planning, which is very contrary to the spirit of Sweding. Brian and Melissa both kept reminding me that things would work out, and part of the fun is solving problems as they arise instead of trying to anticipate everything. It’s been a good exercise for me in that regard. Still, when life is busy, getting a cast together and finding a solid block of time to shoot isn’t always easy. Luckily we know a lot of people who are instantly on board any half-baked projects we come up with. For the most part anyway…

Swede Scene Grid

The responsibility for procuring and creating props was divided between Melissa and I (as Brian was working nights temporarily, though he helped me with some of the bigger ones) and we worked independently unconcerned about how each was going about their task. We would talk, but really only to brag about how awesome a prop turned out. We decided on Memorial Weekend for shooting, and so the dealing for all props as well. A little over two weeks before, an email went to everyone interested with the roles we chose for them, and rough details on how the shoot would be conducted. Finally our weekend came and the real challenge had begun!

Melissa (bless her heart) created an excel spreadsheet using the location and actor grids we had put in our Sweding Notebook. This allowed us to select which actors were present, and get back a list of scenes we would be able to film. This was invaluable because if you’ve ever worked on volunteer projects before you’d know that people will show up anywhere from zero to four hours late. Even the devoted ones. It has more to do with personality than passion for the project. Frantically trying to manually find scenes that can be done with random attendants is hell. Melissa is awesome.

We told the actors to show up Saturday & Sunday, 10am – 6pm. Only one actor specifically couldn’t show up both days, so we lucked out there. Melissa and I met at 9am on Saturday to sync up, and people began to arrive just after 10. We worked for eleven hours until we finished for the day. At 6pm we were close enough to finishing a set of scenes that would allow four of our actors to take Sunday off, so we powered through!

Sunday was nice and fast, though HOT. Our still suits are black garbage bags, so the gallons of sweat we produced in the 90+ degrees was substantial. Not to mention we filmed in my attic a bit more, which was an absolute oven. Shooting went from 10am to 3pm, with an hour of cleanup until I was able to take a shower and lay on the couch. I’m really proud of what we got accomplished in those two days, and how easy to work with most everyone was. It even seemed like people were having a good time, so that’s a plus!

With the weekend over we still have to shoot the special fx sequences, but here are some stats of the production so far:

• 2 Viewings to a Completed Script
• 9 Actors
• 17 Characters
• 18 Locations
• 42 Scenes
• 70+ Props
• 2 Days Shooting for Principle Photography

I’m excited to have our Dune Swede finished and looking forward to doing swedes that are much simpler from a technical perspective. Stay tuned for more on our latest swede!