Category Archives: Advanced FOSS

I Went to the Woods: Tracy Fullerton

The following article is an adapted summary of a recent talk given by Tracy Fullerton at the Rochester Institute of Technology.  It is intended both to give a small lens into the views of the speaker, and to expand on those views where necessary to provide clarity  and spark discussion.  This article does not necessarily always represent the views of the author, and it does not necessarily provide a perfect or unfiltered reflection of the speaker’s opinions.

Walden is a survival game about doing more than just surviving.

Based on Henry David Thoreau’s famous work of the same name, the game gives players a simple task; survive in the woods for the space of a full year, ranging through 8 levels and 4 seasons.  Players finish constructing a cabin to live in, gather food, and perform other daily chores – everything they need to do to survive.

But over time, basic survival starts to become menial.  Colors in the game start to become grayer, and tasks start to become a grind.  This is where Walden opens up, and encourages its players to occasionally stop and explore – to collect arrowheads, examine plants, and, every once in a while, to simply stand still and admire a sunset or listen to the distant sounds of a civilization.

It’s not just an aesthetic choice – Walden literally tracks how much time you spend observing these phenomenon (self-deemed “wonders”), and makes the world more colorful, lush, and interesting as you encounter them.

Narrative Dissonance

Walden has been in development for nearly 7 years, and it served as a centerpiece to Tracy Fullerton’s musings on what game narrative is evolving towards: the potential of games to communicate ever more complex and nuanced ideas.

“It’s a big rock that people keep on trying to push up an ill-defined hill”

To this extent, a recurring theme throughout Fullerton’s talk was the role of narrative in games.  In modern games, she explained, narrative is misunderstood and misapplied: a component of interaction that we know is important, but aren’t sure of what to do with it or how to best show it to an audience.  ”It’s a big rock that people keep on trying to push up an ill-defined hill.”

“At their core, games are systems of play, ” Tracy remarked, “but for some reason, and I think valid reasons, we also crave for games to be dramatic, narrative, meaningful, and sublime.”

Tracy may have spent a good portion of her early career looking for ways to push narrative forward in games, experimenting with branching storylines, choose-your-own adventure style interactions, and complex, multi-layered stories, but she came away from her explorations with the opinion that, ironically enough, the games’ authors often liked these experiences more than players.

There was an odd disconnect between the academic ideals of the creators and the people actually looking at them, and the narratives being created had an all-too dreamlike quality: they felt engaging in the moment that the player was experiencing them, but fell apart in the light of day, or when re-communicated to other players.

Frustrated, Tracy decided to try tackling the problems of narrative from, as she put it, more “oblique” angles.

When an author tells a story, Tracy explained, the listener may be thinking of different things.  He/she might misinterpret what’s actually happening in the story, what its themes are, or come away feeling a disconnect from what the author actually wanted to communicated, even though the author and listener were each given the same information.

Learning to Dance

To solve these disconnects, we evolve memes and genres, which contain composite bundles of information that we can apply to every story we enter.  Memes, stereotypes, and our expectations of how they play out allow us to minimize the upfront work required to process complex stories and interactions.  For example, all good guys wear white hats, and we instinctively know to root for people wearing white hats.

Games however, haven’t really learned to use these genres effectively.  They’re simultaneously stereotypical and arcane or obscure: filled with mechanics and hooks that non-gamers can’t relate to, but also rooted in the most predictable and over-told stories, often lacking any surprise or subtlety outside of their mechanics.

“At their core, games are systems of play.”

Traditionally, games have attacked their reputations of triviality and cliche by attempting to brute force more narrative, exposition, and plot twists into whatever short stay they have with a player.  These strategies don’t hit at the roots of the problem though, and yield diminishing returns as we increasingly commit more and more of our resources to them.

To hear Tracy talk about narrative, stories have always been less about the dissemination of abstract information, and more about their tone, themes, and the emotional reactions they draw out of the people that experience them.  She describes the relationship between authors and consumers as a literal dance, where “sharing the narrative and interpreting the narrative is in itself a creative act.”

And rather than try to reiterate over the same three dances over and over or to dominate our partner in a vain attempt to control their movements in that dance, we should embrace the collaborative aspects of atypical narrative.

What do you see?

As an example, Tracy  hearkened back to the earliest days of development on Cloud, arguably one of the most critically acclaimed games she’s worked on.  Originally , the team had an extremely complicated backstory for the main character: an alien who was attempting to wash away pollution from their world.

After taking time off from the story to focus on gameplay and tone though, the team started to notice that the story wasn’t adding much, and indeed was actively in contrast to the simplistic and elegant design and feel to the rest of the game.  So they layered the simplest story possible, about a hospital resident imagining themselves floating in the air.

Many of the themes of pollution and nature remained, but they were exposed in more subtle ways, through levels where players washed decay away with rainclouds, and with vast scenic islands.

What the team found was that people started not only empathizing with the character more, but also bringing their own memories into the experience and investing them into the narrative, and they were able to do this because of purposeful gaps and open areas of the game.

Tracy explained that these gaps “promote professional and amateur expansion.” People are able to fill in many details on their own, to flesh out the narrative of the game on their own; and these newly constructed stories are much more personal and empathetic than they otherwise would be.

“If you ask me about my play of Journey, ” Tracy elaborated, “the feeling of that lost civilization and the fact that there was a lost civilization does give me a feeling, but, really, it gives me a tone.”

That freedom, and the concentration on the tone and theme of a story beyond specific details, treats narrative as a framework upon which players build their own experiences.  It’s, in Tracy’s eyes, a more respectful, cooperative way to make games.

Tying a story to a specific piece of information, an extra level of complexity that forces the player to interact with the games themes only from a specific angle and via a very specific methodology, gets in the way of all of that.  You can risk drowning your audience in an attempt to make sure they “get” every piece of your experience and ignoring the potential cultural and personal gaps between author and consumer.

Again, Tracy emphasizes, this is a dance.

Playing with stories

All of that leads back to Walden, and Tracy’s constant struggle towards games that invoke that elusive sense of sublime.  After 7 years of development, Walden still hasn’t been released, but Tracy seems happy with where the game is going.

“Games have the possibility of being lenses that amplify our personal experiences and our narratives.”

“You can trust in your process and your team as long as you stay centered on what attracted you to a difficult idea,” she explains.

Well-trodden stories and arcs like the Hero’s Journey are great, but Tracy’s looking for new ways of approaching narrative in entirely, and she’s convinced that these atypical frameworks will enable creators to steadily get closer and closer to the ‘sublime’ they’re looking to express.

Tracy reflected on a previous experience she had playing Warcraft and visiting a mountain in the game with a friend.  While playing the game, she suddenly recollected a previous hiking trip in China, and was surprised to find that both the similar and contrasting elements served to underscore and enhance her memories.

She clarified, “Games have the possibility of being lenses that amplify our personal experiences and our narratives.”

Tracy is adamant that it’s through games that she wants to explore this idea.  She’s seen the attitude that art experiences and sublime narratives are separated from games and should be pursued separately, but disagrees.

“I love games and I think they’re one of the most beautiful aesthetic forms we’ve ever created…  When a form changes and when it evolves, that doesn’t mean it divorces itself from its really beautiful roots.”

What I’m Up To: TimeScrub.js

Because I’m in a college class called Advanced FOSS, I get to periodically pick cool things to work on and pretend it’s work.  This is the most recent 4 week project I’m proposing.  It’s been in the back of my mind for a while now, and I’m fairly excited to get an excuse to finally sit down and do it.


TimeScrub.js is going to be a middleware API that records and saves output from simulations (or any program with regular output) over time.  TimeScrub.js exports these “ticks” into a format that can be re-read into another program, like a visualizer, or the original program, allowing for time-travel within simulations.

The goal with TimeScrub.js is to be extremely tight, well-encapsulated, and non-intrusive. I want to encourage simulations to separate into a model-view-controller design pattern.  A simulation could be run in advance to being displayed, allowing better data and visualizations to be shown to the end user.

I’m also am interested in seeing how it could be implemented in deterministic simulations for time-travel, allowing users to go back in time, change a variable, and then re-run the simulation to see what changed.

What I’m using:  

I plan on using Node.js and pure JavaScript.  My secret goal behind this is to figure out in broad terms how to set up a Node.js server and get everything running smoothly in it.  The actual JavaScript parts don’t scare me much, I’m fairly confident I’ll be able to implement the actual library without much trouble at all.

Where I’ll be bundling the final product:

I’ll obviously have the source code available at GitHub, but I’ll also be targeting NPM, the package manager for Node.js.  Targeting Node.js works into the core ethos of the project – the idea is that you run a simulation on dedicated hardware, and either plug the hardware into a monitor and set yourself up with a c

Target Hardware :

I want everything to run on Raspberry Pi.  Since in the back of my head I’m hoping someone could use this software in something like a virtual aquarium or terrarium

Temporary Milestones : 

I’ll have about 4 weeks to get the project to completion.

  • Week 1 (Next week): Planning, pre-documentation.  In the interest of keeping everything scoped well, I don’t want to start coding until I have my entire featureset planned out.  Along with that, I want to have a general idea of how I’m going to do that – ie, what data structures I’ll use, and what things I should be asking for help with.
  • Week 2: Setting up Node.js – I want to get a better sense of what the platform is capable of, and I want to make sure that I understand the inner workings behind what I use.
  • Week 3: Implementation.  I’ve started thinking about what the core features should be and building some data structures in the back of my head, but all of this will obviously be more fleshed out during week 1.
  • Week 4: Packaging, setting up post-documentation, setting up additional tickets on GitHub.  I’m developing this for a couple of reasons, but one of them is that I know I’ll get use out of it.  In the interest of allowing others to do the same, I want the both setup and documentation to be simple, elegant, and easy to follow.  The less work it is for someone I haven’t met to set this up as middleware in their own projects, the better.

Who I’m working with : 

I plan to leverage some of the students in class to a small degree; one of my roommates is a prolific Node.js user, and I know he’ll be able to help me out occasionally when I run into issues.

I also want to get some feedback/advice from one of the professors at my college by the name of Cody Van De Mark.  He’s an amazing coder, with a great understanding of the backend server stuff that I’ve yet to really explore.


JavaScript: Abusing “this”

This post is an adaptation and expansion of a recent lightning talk I gave.  You can find the original slides here.


Let’s talk about the way  this works in JavaScript.

The first thing you learn when you’re studying JavaScript is that you can never assume it works the same way as another language.  For example, in a normal language,  this is a variable that is defined at compile-time.  It’s used within code to refer to a property on the current object you’re writing for. In JavaScript,  this means something else entirely.  It’s easy to miss the differences at first, because when used in a very straightforward manner,   this seems to exhibit some of the same behaviors.  It’s only when you start to experiment that everything breaks down.

If you’re like me, you probably once took an introductory web development class and had all of the confusing stuff with  this explained to you in the following manner, using the following code:

This is a fairly inaccurate way of describing what’s actually going on, and it shouldn’t take us long to poke some holes in it.

The first thing that should spring to mind is that myPublicProperty breaks as soon as we access it without the this keyword. Which is slightly weird. Also, we run into scenarios like below:

So we could play around with these edge cases all day, but there’s not much of a point.  If you’re really interested in getting a complete picture of what this actually is, I have a number of articles I’ll recommend at the bottom of the post. Otherwise, I’m just going to give you a quick interpretation that is, at least for our purposes, fairly accurate.

Assume that this is a global variable. When we call a method, this gets set to that method’s current scope. Per example, the below code :

Whenever you use this internally, you’re making a call to the object being stored in this global variable, and all of your data and method calls and so on happen relative to the object in that variable.  Simple enough, right?

Call and Apply

The important thing to remember is that JavaScript sets this at runtime, while the code is still executing. If we could change the definition of this before we called a method, we could do some cool stuff. And it turns out we can.

In fact, this is pretty much how JavaScript makes new objects in the first place.

What methods like  call allow us to do is to invoke a method and pass in an object that we want to use as the new   this for the duration of that method call.  And what that allows us to do is Object Oriented Programming on a very fundamental level.

Context is everything

For example:

JavaScript checks to see that a method exists before it allows you to call it, but it almost never checks to see that the method is being called in a context that makes any sense at all.  It’s not an oversight, it’s a feature.  But it’s a feature with a wild potential for abuse.

Another interesting feature of JavaScript is that it sometimes uses this internally.

We just got JavaScript to push an element onto the number 5, then pop it back off.  And the absolutely amazing, fantastic thing about all of this is that it worked perfectly.  No errors at all.

And yes, it’s a little bit tricky that we made a new number instead of sticking with a primitive, but the point still stands.

 A mild case of legitimacy

So, inheritance.  Here’s a fairly good method of doing it, as stolen from John Resig.

Wait, wait, don’t leave yet!  We can simplify all of this!

Good, you’re back.  So it’s not going to be as production ready, and we won’t get any of the nice typeof behaviors or even proper method overriding, but what if I told you we could get inheritance working in one line of code, without worrying about prototype or anything complicated like that?

In fact, let’s go a step farther and make multiple inheritance:

Easy, right?

All we have to do is take advantage of some of the things we already know about  this  and how objects get created in the first place.  We use our parent classes as constructors, but instead of making new objects, we just run those constructors with our new object as the current context., "meow");

The result is that we’ve basically just chained two constructors together.  And again, half of object creation takes place in the constructor anyway, so we’re not really breaking any of the existing JavaScript tenants.

Again, there are some weaknesses with this method, many of which you can probably come up with on your own.

And there are many good questions you could ask right now that I’m not going to answer:

  • “What happens if I inherit from two parents that have methods or properties that share the same names?”
  • “What if I do want to have method overriding and be able to call base and super without breaking stuff?  How would I do that?”
  • “Isn’t it inefficient to be recreating all these methods every time I make an object?”

But still, if you were working on a tight schedule for a class or side-project, and didn’t really understand how the Prototype works, this would be a perfectly reasonable, if somewhat limited solution you could use in your actual code.

Yay, JavaScript!

Some follow-up links

To be expanded as necessary.

Possible Lightening Talks

One of the things we’re allowed to do in my FOSS classes is to give lightning talks, quick presentations on a single topic that need to be below 5 minutes.  The goal is to be as quick and concise as possible.

I’m still not really sure how I want to approach them. Presenting in a group of people you don’t really know is always a tricky proposition; you want to make sure that what you’re talking about is actually going to be interesting to them, and you also want to make sure that you know enough about the topic that, compared to their own thoughts, what you say doesn’t just sound juvenile or stupid.

That being said, I like the concept, and I want to do at least a few, and possibly more.  If nothing else, lightning talks give extra credit, and I already know that I want to stack extra credit this semester if for no other reason than because right now I’m craving some predictability and  and bonus points sound like a good way to get at that security blanket.

So, ordered by what I’d really like to do to just what I’m thinking about -

Javascript: What ‘this’ means and how you can abuse it : An explanation of exactly what the ‘this’ keyword means in Javascript, and some interesting tricks you can perform with that knowledge.

How Open Source games cheat Death-by-Community : An attempt to explain why, if designing and building a game with broad and diverse input makes a bland and fractured experience, some Open Source games are actually really good.

Programming practices aren’t good or bad : An appeal to developers and designers to stop phrasing best practice as a moral absolute.

If I do end up putting any of them together I’ll either record them or put writeups on the blog. In any case, feel free to either share suggestions or tell me that they’re bad ideas below.