Week 7: Connecting the IoT Pipeline

We’ve been learning about the individual pieces of an IoT pipeline and how to use them. This week we connected all the pieces.

But first!
I noticed my sensors had ceased publishing to the MQTT broker a few days earlier. I logged into the InfluxDB and used one of the helpful queries from last week to determine the most recent readings:

Since I’m only one publishing to the red topic in our shared class database, it was a simple query:

> precision rfc3339
> select last(value) from red tz('America/New_York')
name: red
time                              last
----                              ----
2019-03-13T10:48:58.7449232-04:00 84

Writing queries is fun, so just to double-check:

> select last(value) from temperature where device = 'device_en' tz('America/New_York')
name: temperature
time                                last
----                                ----
2019-03-13T10:48:58.712896503-04:00 65.3

Yep, the last reading was posted on March 13, 2019, at 10:48am, three days prior to these queries. I’m not sure why it stopped.

I decided to take the opportunity to update my Arduino code to include color temperature and lux (perceived brightness) readings from the TCS34725 sensor. I originally wanted to include these but my initial tests five weeks ago gave readings that were all over the place depending on how I was initiating the sensor. Tom suggested I used this for more accuracy:

Adafruit_TCS34725 tcs = Adafruit_TCS34725(TCS34725_INTEGRATIONTIME_700MS, TCS34725_GAIN_1X);

…as well as use this updated method to calculate color temperature:

colorTemp = tcs.calculateColorTemperature_dn40(red, green, blue, clear);

Note: I had to update the TCS34725 library to version 1.3.0 to access that dn40 algorithm.

Updated Code on Github


Part 1: Processing MQTT Data
A quick recap before we continue. So far I learned how to publish sensor data from my WiFi-connected Arduino MKR1000 to a server using MQTT protocol. That server, which was set up especially for this class, is running Mosquitto, an open source MQTT broker, and I can subscribe to the broker’s data topics to see my sensor’s data in real time. I also figured out how to connect my Arduino to a power supply to publish data continuously to the broker to start logging it over an extended period of time. To save this data, Don wrote a Node.js script on the same server that subscribes to the MQTT topics and then inserts data into a shared class PostgreSQL database living elsewhere on AWS. We practiced writing SQL queries against that PostgresQL database, as well as a few other databases (InfluxDB, MongoDB, and TimescaleDB) for comparison.

For this week, we learned how to write our own Node.js script to subscribe to the MQTT topics we care about and save them into a database. Because I’m interested in setting up my own Timescale database in the future, I modified the provided code to subscribe to the MQTT topic for my device and send the values for all readings (temperature, humidity, red, green, blue, color temperature, and lux) into my personal database in the TimescaleDB. I really didn’t do much work here—just set MQTT subscription route to my device. However, I solidified my conceptual understanding of what’s happening behind the scenes. (Note that this Node.js script only runs when launched from my Terminal and while my computer is active.)

Here’s a screenshot indicating that the specified values were inserted into the database.

Here’s a screenshot indicating that the specified values were inserted into the database.

I logged into that database to ensure that the data was indeed there.

I logged into that database to ensure that the data was indeed there.

Code on Github

Part 2: Graphing
Next I wrote an Express server, again guided by the example in class, to query data from a database and visualize the results using Google Charts. Instead of using my personal database as mentioned above, I queried the shared class Timescale database because I wanted to graph all the data that my Arduino has been sending for the past couple of weeks, in addition to the newly added color temperature and lux values.

In class, our example server let us select the device to display all the values for one designated measurement, in this case, temperature. For this exercise, I rewrote the server to allow me to select and graph any measurement from my particular device.

Step 1. First, I rewrote the example code with a server route that provided me with a list of all the measurements for my particular devices. All the code is linked below, but here’s the output:

Request: http://localhost:4000/measurements

Response: ["blue","colorTemp","green","humidity","lux","red","temperature"]
I logged into TimescaleDB database to draft the SQL query before incorporating it into my JavaScript server code.

I logged into TimescaleDB database to draft the SQL query before incorporating it into my JavaScript server code.

Step 2. Next, I created a route to return the specific values for a specific measurement type. Again, I practiced the query in the query beforehand inside the TimescaleDB database.

Request: http://localhost:4000/lux

Response (abbreviated): [{"recorded_at":"2019-03-16T23:23:31.428Z","reading":48},{"recorded_at":"2019-03-16T23:33:31.342Z","reading":46},…]

More practice!

More practice!

Step 3. With that working, I modified the front end files to make requests to server, retrieve the data, graph it using the Google Charts library.

Screenshots TBA!

Actually, figuring this out wasn’t as straight forward as these three steps, but it all makes sense now.

Code on Github

Week 7: Playtest 2

Playtest Thursday @ NYU Game Center • Mar 14
Returned to Playtest Thursday with my game now in paper form: a deck consisting of hypothetical question cards and random words. After the reception of my presentation earlier in the week, I was unsure how it would play with groups of strangers, but then again, this is an audience that’s invested in playing and making games.

So glad I went. It was so much fun! I played four rounds. To my knowledge, only one of my playtesters was a NYU student.

Round 1: Two Players
I ditched the rule sheets from last week’s playtest and following Greg and Jenny’s advice, orally gave the rules and with some example cards, demoed crafting a sentence with a word in response to a topic question. Each player got three cards. In my mind, I explained that players should placed any snuck word face down on the table at the end of their speaking turn, but in reality, my playing partner waited until I played my card to deposit his cards on the table. At that point the conversation had run kinda flat anyway so it was a good stopping point. Before the start, I described that at the end we could guess the words that our opponent had snuck—one guess for each card placed on the table. This game wants to be two things: either an icebreaker to get to know people or a cutthroat competition. My opponent said it felt weird to analyze my speech and watch for tells while engaging in this beyond-small-talk-convo (my words)—yes, I want this! Biggest take away from this round was the need for a timer to cap the conversation and set a sense of urgency.

Round 2: Two Players
More practice explaining the format of the new analog game! Each player got three cards. I set a timer: number of minutes equal to the number of players. (It can’t be too long because there’s a chance you won’t remember those words that seemed out of place.) Player who draw the topic question starts the conversation. At then, one guess per “snuck” card. If the guesser is right, they get the card. If they are wrong, nothing happens. Player with the most snuck cards in front of them wins. The timer definitely helped frame the play, but we decided that two minutes might have been two short.

Round 3: Four Players
What a fun bunch! So much to keep track of with more people playing. Only of the four people knew each other. Timer set for four minutes, and players commented that this felt fine. One player admitted after the game that he was unsure of what to do at the start, which was fantastic, because he won the round through his fantastic improv storytelling. (Maybe for some it’s one those games that’s tricky to wrap your head around until after you play it once.) No defined way for more than two people to handle the “guess-your-words” part after the conversation ends, but we had fun doing it anyway and retelling major moments of the conversation. An observed strategy was to say a bunch of words in succession to hide your word in the mix. It was suggested that players should call each other out on their words in the middle of game: maybe there’s a big buzzer in the middle of the table that folks can hit when they suspect a word. What if players wrote down suspected snuck words on scratch paper during game play?

Round 4: Three Players
Two players knew each other from the previous round. Revealed strategy by a player at the end: hide a word in response to another player’s statement; they’ll be so wrapped in their statement they won’t focus as closely on the response. Still did not have a solution to handle the word guessing after the timer was up so we free-formed it: everyone went in order and guessed words of other players. Again it was entertaining to dissect the highlights and retell the story of the dialogue. One player loved how open-ended nature of the game and how much of the content was player-driven. YES!

Consider Next
Figure out how to catch words at end of game or during conversation (which might impact length of timer).

One way to prevent players from spouting off lists of words is to introduce a rule called, bulldozing. If a violation occurs then bulldozing against a player can be called and other players can vote to penalize that player. But how—by kicking them out the round?

Overall, my playtesters and I had a blast. They love the core idea and now it’s just a matter of refining the mechanics. I also HAVE to rethink how to present this game to an audience that can’t play it immediately. I want the audience to feel the smiles and the laughs from playtesters at my table tonight. Thanks so much, everyone!

IMG_0763.JPG
IMG_0770.JPG

Week 7: Lessons Learned and Small Talk Cracked

Screen Shot 2019-03-13 at 4.02.53 PM.png

Much happened this week, including a confusing and not-so-fun for me midterm presentation. BUT, it led to some reflection and reading that helped me crack the nut of small talk that’s been bothering me. So at least I got that out this thesis process!

Office Hours Notes
The week started with back-to-back office hours with experienced game designers, Greg Trefry and Jenny Lim. It was super helpful to sit and soak in the questions they asked. Here’s a quick recap for future reference:

What’s the overall tone and feeling?

  • If it’s a casual, social game, then trying playing it in the desired environment — like a bar.

  • Note the length of a round. For a social game, that might be 10-15 minutes.

  • What kinds of statements are made when someone pulls a power move? (Oh man! That’s a good one!! kinda thing)

  • Are there any natural rhythms that you observe and can tap into?

  • Earnest, obnoxious, or slightly subversive —> is there a theme to the content that gives people information about how they are suppose to behave?

Regarding playtesting:

  • Ask play testers what kinds of games they like to play

  • Try to play with as many different groups as possible, even folks who don’t really want to play

  • It’s okay for me to give out the rules vocally at first (especially while I’m trying to figure out what they are myself)

  • Try out as many mechanics as possible

Think about the narrative skin:

  • All of the visual clues (title, logo design, shapes of playing pieces, etc) that tell users how to behave or how they are in a game, e.g. chess pieces immediately indicate that the two sides are fighting each other

  • Think of the titles: Apples to Apples (comparison is implied) and Exploding Kittens (something crazy is about to happen to some baby cats)

  • Regarding an appropriate title for this game, think about what people say in response to a stupid pun…or dumb things that people sneak into conversation

  • Apples to Apples and Cards Against Humanity are the same game, but they have different “skins” —> choosing one of these will impact the tone and content of the topic questions and words (e.g. family fun vs subversive, super silly vs. more serious)

Play lots of games (or watch people play on Youtube and read up on the rules). These were mentioned:

  • Balderdash

  • Punderdome

  • Buffalo

  • Mary Flannigan

Practical tips regarding my game:

  • Simple is good; sometimes folks start off with overcomplicated rules

  • For casual games like this, maybe 2-3 rules max

  • It’s good to give folks lots of words so they don’t feel stuck with one they know (if they don’t know a word, then make it okay to swap it for a new word card)

  • When describing the game, it helps to compare it to parts of games that people might be familiar with already

  • Remember that game designing is like baking: you take a little from one game and little from other games and you mix it altogether in your own way

Midterm Presentation
With only five minutes of presentation time allotted, my approach was to give the general gist of the game without the specifics. I started with the importance of conversation in our lives and *thinly* linked it to how we might play with the rules of conversation within the frame of a game. There wasn’t enough time to play a round, so I delivered a quick setup, hoping that the audience for a brief moment would consider the challenge of answering the hypothetical (pictured below) with one of listed words in a nonchalant way. I posed possibilities for how this game might be shaped: for the joy of that kind of problem solving, to stimulate quality conversation, to practice listening skills, to learn new vocabulary, or to practice words in a new language. I took a hint from the advice list above and compared the gameplay with aspects of well-known games (like conversation icebreakers and a pinch of Balderdash—at least that’s what keeps coming up for people).

My immediate impression was that outside reviewers were confused and not necessarily convinced of the game’s “fun” potential. They suggested that I model the game turn for turn. They wanted to know how people would get caught and what would keep players from spouting off a flood of random words to hide their word(s) in the mix. There was a call for more structure to the game and strategies to preserve the flow of the conversation…buuut I like the awkwardness of calling someone out in the middle of a good flow. I remembered that we received very similar remarks from some of the outside critics who joined our final playtest in Collective Play last spring.

I was frustrated by the response. My friends and family dig the idea and repeatedly express interest in playing. So I did a lot of thinking, took a walk, read a bunch of essays from The Discourse Reader, and then it all started to click: this game has different goals depending on the nature of the group playing. More on that in a moment.

In the essay, “On Face-Work: An Analysis of Ritual Elements in Social Interaction,” sociologist Erving Goffman frames conversation as a exchange that follows '“ground rules of social interaction.” Conversation requires a commitment by all participants to achieve consensus, of which a crucial aspect is working to maintain your self-esteem and credibility (saving face) as well as that of your recipient(s):

"Much of the activity occurring during an encounter can be understood as an effort on everyone’s part to get through the occasion and all the unanticipated and unintentional events that cast participants in an undesirable light, without disrupting the relationships of the participants (p. 309?)”

My game directly pushes against this project of maintaining a sense of order in the interaction. By accepting an agenda to hide words in the conversation, players must consider their opponents’ comments with caution and suspicion without an outward display of those feelings. 

Digging deeper, Penelope Brown and Stephen C. Levinson’s, in their essay, “Politeness: Some Universals in Language Usage,” outlines face-threatening acts and among those that “indicate (potentially) that the speaker does not care about the addressee’s feelings [and] wants” are “contradictions or disagreements [and] challenges (p.314).” I’d argue that this is what occurs when you call someone out for sneaking a word: you’re outright accusing another player of deception. But if you know the other players well enough, such that you trust them and you have some history of playing and suspending disbelief together, then this game poses a direct but inane contradiction to those secure feelings. And that’s the fun: in your sly conversational style, you’re still just pretending. And in this situation, maybe the title of the game, Gotcha!, makes perfect sense.

HOWEVER, if you’re playing with strangers or new acquaintances, then you’ve yet to establish a history of shared experiences and closeness. Even within the frame of play, I’d argue and agree that it’s too uncomfortable and threatening to be constantly suspicious and on guard right away with someone new—I mean, for some, is that possibly where you’re already starting with someone that you’ve just met?

I had a hint of this myself when I played the game with a new friend at last week’s Playtest Thursday. We had already spent some time together; I playtested her game first. But even though she was sweet and generous to give me her time, I was a bit nervous. We didn’t get that far because the current digital version was too buggy, but now I realize how crucial those uncomfortable moments were for me to experience.

To connect it back to Collective Play, I spent 11 weeks with my fellow students playing all sorts of games and being vulnerable in unexpected ways. We were used to pretending with one another because we did it every week. Not so the case for the outside guests who visited our class.

So perhaps the midterm reviewers could not imagine themselves playing this game with folks in the room because they did not know them very well. I would be confused about the game and ask for more structure, too!

Now I understand why small talk is so important: it offers a way to get to know new people and build a sense of mutual understanding, connection, and maybe also, trust. We can all agree that weather is a shared experience and is probably the numero uno topic that comes to mind on the subject of small talk. Nikolas Coupland and Virpi Ylanne, in “Relational Frames in Weather Talk,” note that “it is striking how speakers design their comments about the weather to elicit evaluative consensus” and in fact:

“Sharing in weather talk…as illustrated in the three extracts [in this essay], can go well beyond consensual evaluation, toward intimacy. Through talking evaluatively about the weather, speaker can introduce details about their personal lives and feelings and explore those of their addressees (p. 354).”

Ohhh, well yeah. Of course! Now that the process has been described, it’s so obvious. Because the weather is a universal, shared experience, and it’s neutral, there’s a greater possibility that we can arrive at consensus relatively easy and along the way, reveal information about how it’s affecting us personally that also gives clues to our personality and worldview. If we choose to, of course, otherwise small talk “offers us mini-scripts to pass through [liminal spaces] in a non-threatening and socially acceptable way (p. 290).” (OMG, did I really spend seven weeks of the semester to get here?!)

So for strangers, the premise to play this game might be too threatening if the waters between them have not yet been tested. No doubt the Gotcha! title makes that process even more daunting and totally inappropriate. I suppose the next question is: is there a mode for this game that works for the “stranger audience?” One that allows people to build up some familiarity via low stakes means? Is it more attractive and advantageous for them to collaborate and work together instead of against each other? What would that look like?

Finally, I identified yet a third group of players with a separate set of conditions. In the context of our university, this would be our international students, for many of whom English is not their native language. In my conversations with some of them, this game has been received well as an opportunity to practice new words, especially with others who have the same agenda.

I’m hard pressed to see these three groups mix together to play this game.

And so what’s next? If' I’m to test again at the Game Center for a “stranger audience,” then I need to rethink my approach, the rules, the title… and perhaps develop this in parallel for the “friends crowd”…? Hmmm…