Programming the World Sketches

Glen Chiacchieri — April 12, 2016

Last week at lunch I showed some early sketches I made to understand Bret's proposed object model. I was/am hoping that it's also possible to work backward from representations of how Laser Socks and MoleTank work toward how our object model should work. The first sketch was this quick one of MoleTank:

It's just a rough outline of how the objects communicate, what states they have, and action/contexts cause state to be modified.

Laser Socks Diagram

This week, I've been toying around with some other representations.

I started sketching out a Laser Socks representation much larger on a whiteboard and came up with this:

You'll notice I added a box for "systems-level" stuff near the top (in case someone wanted to dig into how that stuff worked), and also showed the particular instances of the objects with whatever their particular state was.

Making this diagram, I felt a tension between the abstract schematic of how these objects worked and the status of objects in the world. For example, it felt kind of messy to show two versions of each object, each annotated with its current state. I also didn't like how flat the diagram was and that there was a separation between the actual physical Progress Bar object and its image in the diagram.

I hypothesized that maybe the abstract communications of the objects should be separate from their particular running instances, which lead me to my next sketches.

Physical Inspectorators

Here, I've physically annotated Laser Socks objects with two Inspectorators:

Each Inspectorator shows the current and recent states of the closest object. Here's what it might show if it was placed next to the nearest Progress Bar:

(excuse the sloppiness of both presentation and concepts)

From top to bottom:

Here's what it might look like for an Arena:

(Much less information because it's a dumber object.)

Something I like about these inspectors is that they're physically in the world next to other physical objects. If you want to know about a particular object's current behavior, you put an inspector next to it. You can have a lot of inspectors laid out at once and see all the objects operating in real-time. With better visual design, you could see more important information from a distance and fine detail by moving closer (like in many of Bret's posters).

While thinking about these inspectors, I started to noticing some subtle things about the object model. For example, there are several types of queries you can do that feel like they overlap a bit:

I'm not sure if the overlap I'm detecting matters or anything, but it does have some implications for how you see the recent history of this stuff. (For example, you should be able to inspect a progress bar and see when its nearest Arena was lasered, but right now that doesn't seem part of the Progress Bar's history.)

So anyway, physical inspectors may be a way to see the history and functioning of physical objects, but how do you program them?

Physical Schematic

I liked the idea of having an abstract class diagram, but it seemed like it should be more physical, so I made a tiny Laser Socks:

What is this, a Laser Socks for ants?!

It may be hard to see in this picture, but there is a physical start button, progress bar, and black plastic arena on a big piece of paper. I imagined this as a live schematic. When you laser the tiny socks on the tiny arena, the tiny progress bar would fill up. The objects' state and illumination code are also on this diagram.

I tried to draw how the objects were communicating (using red waves to show that Progress Bar was detecting their lasered observable). Maybe some or all of this is displayed dynamically, so when you move the physical objects around the connections change. Or maybe the red waves themselves should be physical objects? I dunno. I also tried to annotate the connection between objects with the code that runs as a result of that path being activated (like score being set to 0 when the start button is pressed).

This brings up some weird philosophical questions about the difference between a model and reality (and determining from a model what is inside or outside a system's concern), but as always in these matters we can look to the wisdom of The Simpsons for the answer to these questions. (this is apparently one of Dave's favorite Simpsons jokes)

Stage Design

April 19, 2016

I tried a different thing this time:

Something I found lacking in the schematic designs was a coherent sequence to follow if you weren't already familiar with how the program worked. I thought about the way I explain Laser Socks to people in conversation and tried to illustrate something along those lines. In the working system, maybe there is some kind of template and to program these objects you fill out the template? I don't know.

Anyway, the first section is meant to set the stage, introduce the "characters" this program will be describing.

The second section shows the state, attempting to be explicit about which objects remember which values. This might be analogous to "characterization".

The third section is meant to show how all the objects are related, like in the schematic diagrams. I wanted one interaction per "panel" so they wouldn't be all jumbled up together. This is something like the "plot", how all the characters interact. Each panel would probably highlight whenever that interaction was taking place in the working system. I'm not totally happy with how this section turned out and I'm not sure why.

I was also experimenting with color and icons because the thing I made yesterday was so drab.