When we last left our heroes, you’ll remember that I had just put together the barebones of an interface to view characters within the game. Left to my own devices, I had scribbled together some wood grain to match Eileen’s, and quickly became quite exhausted from the effort.

Remember?

I didn’t update last week, but Kevin and I worked on plugging in this monster to the rest of the game. Most of our sorrows come from trying to get our Inky scripting language scenes to talk to our Phaser.js code. And yes, our own human failures. This week, I worked on the actually adding characters to this interface.

It seems like I’m always trying to make rows and columns of things, no matter where or what I’m coding.

Those magic number are necessary, because you’ve got to start somewhere, kids. The result:

You may notice the interface currently features *one* character – but that’s okay! It works! And when we have the other 19 sprites, it’s going to be a really easy switch. So far, I’ve gotten it working so that the right hand box updates with character info when you click… but I’m not very happy about the interface. It is presently functional… but lacks charm. I’m hoping 19 additional character sprites will help out with that, but I might try to add a little something extra to the interactions (if there’s time).

The final thing I finished today was having the interface react to what is known in other parts of the game. Basically, if the main character shares a particular piece of personally identifiable information, I update this interface by greying out characters who do not share that characteristic. It’s sort of a view into what the world of the game knows about who Franklin is. Here’s what it looks like when Franklin / the player has shared his birthday with the powers that be:

The showcase is fast upon our heels, and we’ve got lists on lists on lists. Look how playful I am on Slack:

We have a hackathon-style weekend planned next week, and I’m hoping to start each day with a 20 minute phone call to have each of us go around and state what we’d like to get done that day, with check-in phone calls every 3 hours. Isn’t remote work fun??

After last week’s Physical Computing class, we were challenged to construct a circuit with a “creative switch” for homework. We had gone over series circuits in class, and Danny showed us a few simple switches. My favorite was his impromptu “wind sensor”, which required the user to blow across a sheet of aluminum foil that then came in contact with a conductive wire that closed his circuit (and lit up an LED).

For my creative switch, I wanted to force myself to use the simplest components possible. I decided to keep the same basic circuit we built in class (a power source, an LED, a 220 ohm resistor, and switch in series), and focus my energies on making the switch something interesting.

I came up the following design:

The design was inspired, in part, by a certain poem that has gained a surprising amount of popularity on Twitter:

The point is to be alerted when someone has eaten your plums and your icebox has become quite empty. I imagined a future, more terrible iteration of this design that might include tweeting variations of the William Carlos Williams poem each time icebox in question was pillaged.

Soon after I sent out to prototype it, the design shifted to accomodate for available materials.

I grabbed some cardboard and a battery case from the junk shelf. I knew I needed some sort of platform to place my hypothetical plums, and that it would need to move up and down. With the help of the shop staff (thank you, Alden!) and borrowed wire cutters, I was able to grab the springs from the battery case for my platform.

I attached two metal springs to the bottom cardboard panel of my contraption.

I noticed that the springs were quite strong, so rather than attaching two more springs in the remaining corners, I folded up a bit of cardboard (barely half an inch thick) accordion-style to mimic the metal springs, with considerably less strength. I then attached a panel of cardboard on top of those springs and bits of cardboard. When the glue dried, I had a platform that flattened when pressure or weight was applied, and then bounced back to a starting height when the pressure or weight was removed.

I also added a narrow but tall strip of cardboard perpendicular to my platform. I added copper take to this strip, taking care to make sure that the copper right at the starting height of the platform. I added the take copper tape to the edge of that platform that would come in contact with the perpendicular strip. Ideally, we would want the copper of the platform to come in contact with the copper of the strip when an object was removed from the platform, and an alarm or indicator needed to be set off (i.e. the circuit needed to be closed).

I added this basic switch into our basic LED-resistor-in-series circuit. (Hopefully, you can better see how contact involving the copper tape works in the image below).

I ended up staying with an LED after briefly considering a buzzer in its stead. (There were lots of other people quietly working, and I didn’t want to alienate new potential friends!)

In its finished stages, it seemed the springs were too strong to be much moved by fruits. I ended up placing heavy books on it, in order to make it work. In the future, if I were truly going to use this for an at-risk icebox, I would probably use weaker springs.

I do want to point out that the use of this device is not limited to theft detection. It can also alert someone that the quantity of some frequently consumed thing has diminished, and that it is time to restock (e.g. a baker’s flour supply).

This week, in Introduction to Physical Computing, we read a few pieces including the first couple of chapters of Chris Crawford’s Art of Interactive Design. I found Crawford’s definition of interactivity somewhat challenging – not so much the broad metaphor of interaction a conversation between two parties (broken down into listening, thinking, speaking), but rather, the consideration of what counts as thinking or even processing. It is easy to see how interactions between two human parties involve thinking followed by (hopefully) meaningful speech. But, I’m cautious about discounting kinds of thinking that occur on different timescales or in different forms (or at least, privileging one kind of “interaction” over others).

That being said, I appreciated that Crawford introduced that notion of a continuum of interactivity. This, I found to be an effective framework for thinking through the issue. And to temper my earlier statement regarding privileging certain types of interaction, I can certainly see why that would be necessarily within the context of our Physical Computing class (rather than in an philosophical consideration of the term) to look at more robust forms of interactivity.

The more pleasurable forms of interactivity allow for a certain amount of serendipity. It is not necessarily a satisfying interaction if you can predict its likely outcome. Somewhat along those lines, it is more interesting when an interactive object or experience builds upon earlier interactions – which is to say, it is not enough that the conversation involves mere processing. Ideally, it involves a form of memory, to allow the parties to build on earlier interactions.

A question I would like to continue pursuing through this class is whether an experience can be interactive in a way that is different from an object (think interactive plays versus a mad-lib book). What are the ways in which even “robust” interactivity (for example, failures to communicate in human conversation) misses the mark? And is interactivity in the eye of beholder?

I meant to capture it before we dug in, but this is clearly better. (Simon & The Whale)

In the spirit of documentation, I’m going to be writing a few posts on what I’ve been working on for Alchemy, a game funded by the Brown Institute’s Magic Grant. For now, I’m just going to drop in media res into what I’ve been up to this weekend (with the dream of someday writing up a few retrospective posts on other aspects of the game).

One of the challenges of having members of our time in separate locations is that rapidly prototyping new interfaces can be tricky. This weekend, I wanted to create a way to display a sort of “yearbook” of the characters from the game. The “yearbook” would actually function much like a “Guess Who” board as the game is being played and importantly, provide a peek into what the authorities in the fictional world of Alchemy know about its primary character (and all other characters in the game).

We’re quickly approaching final presentations at Stanford, so ideally, I wanted my prototype to be something that could be easily changed into a more final form by Eileen, our artist, and I attempted to keep that in mind when building the present iteration.

To keep in style with some of Eileen’s other work, I decided to recreate the wood-grain she had made for the recipe book in the game, seen below:

To make my wood grain, I began with a new document in Photoshop, separating the background color and wood grain details into different layers that could be easily edited, recolored, etc. In Illustrator, in a new 800x600 document, I laid out small rectangles into a row of five and then, copied that row 4x to form “yearbook” for 20 characters. I made some adjustments to the fill and stroke type of the rectangles to match the “charcoal” pen style Eileen has used in some other parts of the game. I also added two rectangles on the righthand side to act as placeholders for the informational boxes.

The version of the “yearbook” I came up with looks like this:

Each of the twenty boxes will eventually have a sprites of various characters, and the righthand rectanges will update with each character’s name and information when the player hovers. Ideally, Eileen can make the character sprites with transparent backgrounds, and we can manage the player interactions with the sprites in Phaser.

For now, I created a new scene in our game by adding Identifier.js and updating Scene.js, Preload.js, and index.html as needed (ugh, I always forget to update index.html until errors are thrown up).

Kevin, our most experienced developer, had already created had some running code for an different interface for showing characters (a kind of terrible scatterplot that we are getting rid of). I adjusted his code to redirect to the new yearbook interface (or Identifier), and after a thousand tiny bugs, it was up and running.

Next up, I need to let Eileen know of our updated art asset needs and work on adding some potential user interactions into the yearbook/Identifier interface.