I should really queue these posts, shouldn’t I?
Lately I’ve been feeling like my life is sorta out of control, like I can’t shape or affect any of the stuff going on around me. This might have influenced my decision to highlight Ladylike, a game by Nina Freeman, Emmett Butler,…
Ladylike on Indie Advent Calendar
I wrote this a while ago when I was trying to understand how arguments and scopes work in python. Here it is in case anyone wants my explainer.
Disclaimer: I use the terms “value” and “reference” here a bunch. These terms are used only to illustrate the point. I don’t mean to imply that python’s calling model has any concept of a “reference” or a “value”. In particular, look at the last two paragraphs.
When an object of a mutable type is passed to a function, what is actually passed is sort of a “fake pointer”. That means that, while it can be used to access parameters of the object it points to, the address to which it points cannot be modified.
This is “pass by value” in the C++ sense, where the value is a reference (maybe an integer representation of some location in memory). An important point is that the value is of an *immutable* type. That means that we cannot play with it like a pointer: we can’t, as in C, pass a pointer into a function, change the address it points to, and have that change visible outside the function. We can, however, use the reference to play with members of the object it points to.
More clearly: when a name is assigned to at function scope, the outer-scoped value of that name is discarded (mutable or immutable, it doesn’t matter). When a name is used to reference a mutable parameter without reassigning to it, the named object is modified.
If a name is assigned to in a function, the corresponding parameter appears to be passed by value (ie the outer object of the same name is not modifiable).
If a name is not assigned to in a function, the corresponding parameter appears to be passed by reference (ie the outer object of the same name is modifiable).
If you’re married to the value/reference paradigm, this can be thought of as “pass by value where sometimes the value is a reference”.
By that I mean that a name can be used to *reference* the same mutable object that exists outside of the current scope, but the identity of the object referenced by the outer name cannot be changed - any attempt to do this will actually result in the function-scope name being reassigned to a new object, but will have no effect on the outer-scope name.
This model is also called “pass by object” since the terms “value” and “reference” cease to be meaningful when used in this context.
Ladylike is a game about parental control and manipulation by Emmett Butler, Nina Freeman, and Deckman Coss.
Why Try It: A short, dialogue-focused piece that expresses childhood experiences of powerlessness and neglect.
Time: Two minutes, though worth replaying to see alternate dialogue.
How to Play: Use the arrow keys to select options/move around and the enter key to make dialogue decisions.
More Info: Ladylike was made for the was created in 48 hours for the 27th Ludum Dare competition in which participants were asked to create a game that fit the theme of “10 seconds.”
Nina Freeman and Emmett Butler have developed a number of other short games, many of which they have collaborated on. You can find them here and here. My House, My Rules and Fist of the North Carp are the most similar to Ladylike in that they also deal with parent-child relationships
This is a very nice write-up thank you!
Nina and I made another game about her childhood this weekend for Ludum Dare 27. Warning: this one is pretty sad, you guys.
Nina and I made the second of n games about her childhood this weekend for the What Would Molydeux game Jam (last time around, Diego and I made this ). Our game this time is called My House My Rules, and it’s a stealth game about hiding snacks from your (Nina’s) mom. Play it please!
A few weeks ago, we made our first game about Nina’s childhood
Nina and I made this game about getting slapped in the face with fishes for the Fishing Game Jam. Check out the dev log here and play it on Nina’s site.
My attempt at animating a dad for our #fishingjam game
Background I made for a game about gettin slapped with some fishes for #fishingjam with Nina
Parse.ly Blog: To the Next Parse.ly Intern: Learning is Not A Race -
Emmett Butler is a web and video game developer and an NYU senior studying computer science and music technology. In this post, he reflects on his time as an intern at Parse.ly
Today, I leave Parse.ly after 20 months of work that took me from writing web scrapers to diving deep into semantic…
I wrote this post for the next wave of Parse.ly interns.
This is an exploration I did last night into pseudorandom noise generation. I was working on a project that involved the use of Perlin noise to make a target move erratically, and I couldn’t resist the temptation of making vapor trails (a pretty common use case for noise).
Nina and I found a Perlin noise implementation and adapted it into a simple class. Later in the evening, listening to the new Anamanaguchi album, I was inspired to make something cool looking, which led to this smoky rainbowy excellence.
The code that draws the smoke lines is based on code that simply draws a horizontal line. From the horizontal line, noise is applied to the vertical position of each pixel in an amount proportional to the distance of the pixel from the right side of the window. This is why the right side of the image appears less erratic than the far left side. The noise function is also passed the frame count as a parameter, to make the smoke lines progress from one side of the screen to the other and off then side. Without this addition, the lines would compress onto themselves over time, never leaving the screen.
The colors are generated by three sine waves, each representing one of red, green, and blue. The phases of these sine waves are disturbed by Perlin noise, and these disturbances are what cause the changing color palette.
This animation is created by writing pixel color values into a texture, then applying the texture to a sprite. The sprite is also scaled up by a factor of six in this image, since calculating the noise function at each pixel on a retina display makes the app run at <1 FPS.
Check out the code for this demo here.
Emmett Butler is a web and video game developer and an NYU senior studying computer science and music technology. In this post, he reflects on his time as an intern at Parse.ly
Today, I leave Parse.ly after 20 months of work that took me from writing web scrapers to diving deep into semantic web standards to designing mobile SDKs. Here is some advice and emotional primer for the incoming Parse.ly intern. I can only speak from my own experience, and while I try to generalize, all of my advice is heavily colored by what I went through when I started.
When I started at Parse.ly, I was working 20 hours a week alongside another part-time work study job. I was entering my 3rd year of an NYU double music technology/cs degree, and my technical skills were rudimentary. I had no “real world” experience to speak of, and the extent of my outside experience was a few hackathons, schoolwork, and a handful of personal projects. I actually remember thinking during my first few weeks at Parse.ly that I had no idea what I was doing - I didn’t delude myself.
In the course of my time here, I’ve gone from mechanically writing 4-6 web crawler scripts per day to developing semantic web tools and mobile SDKs for Parsely’s customers, as well as contributing to the main analytics product, Dash. I gained experience in most of Parse.ly’s codebases circa mid-2012, primarily as a result of my own exploration. I personally feel that I’ve come a long way.
Parse.ly was both my first “real” job and my first time collaborating with other professional developers. Knowing that I was extremely inexperienced, it was easy to assume that everyone else on the team had all of the answers. In my mind, there was no question I could ask the other developers that would challenge them - the rest of the team was light years beyond me as far as I was concerned. This was my mindset for probably the first 2 or 3 months I spent at Parse.ly, and it didn’t really change until I had done something I saw as substantial enough to warrant being taken seriously by anyone else. Of course, this is a poisonous mindset and it can (and did) lead to all kinds of negative emotions and behaviors. Primarily, it stopped me from contributing meaningfully to discussions, since I was convinced that I had nothing to offer.
What I came to realize about this mindset is that it is (obviously?) not founded in fact. I’m sure this realization is something everyone has to go through at some point or another, but the most important thing for me to personally understand was that there is no worldwide programmer race. I am prone to operate under the assumption that there is a race going on between all programmers in the world to see who can be the “best” the fastest, and I’m losing. The fact is that nobody actually thinks this way about anyone other than themselves - everyone is worried about their own skills, but they don’t spend time comparing other people.
The point is that everyone has their own expertise and skillset, and it’s very unlikely (no matter how much you want to believe it) that the sum of your own knowledge is fully duplicated across the rest of the Parse.ly team. You know something someone else doesn’t, and this simple fact invalidates the “race” idea. Skill sets are vectors, not scalars - you can’t just “rank” people based on the entirety of what they know or don’t know.
The upshot for me was to stop comparing myself to other developers, especially the Parse.ly team. There is nothing to be gained from worrying about “how good you are”.
As for contributing to discussions, I think about it like this: you are very familiar with yourself. You probably have a constant internal monologue in which you acknowledge your own thoughts about the discussions and team activity happening around you. You’re comfortable with this. If you’re anything like me, you tend to forget that other people (especially people who don’t know you very well) are not familiar with your internal monologue. To me, it seemed that the worst consequence of not contributing to discussions was having to go along with whatever decisions were made. It turns out, though, that since the rest of the team doesn’t hear your thoughts, the worst consequence is, in the long term, gaining a reputation on the team as unengaged. This applies, as far as I can tell, to any tech team, not just Parse.ly. If you don’t actively contribute in group settings, people may see you as unengaged, or they might give you the benefit of the doubt and assume that you’re still paying attention. If you do contribute, though, you remove all doubt as to whether you care about being a productive team member. Ultimately, contributing to conversations is bound to make you look better, not worse.
My first project at Parse.ly was the data exporting feature (what became Dash’s “save page as” buttons). My first day was consumed by haphazardly setting up virtualenv, python, pip, mongodb, postgres, and dash on my laptop, and the assignment came on my second day (in my experience, this is a typical timeline for Parse.ly interns). The environment setup consisted mostly of Andrew guiding me through the setup processes (which were at the time alien to me) over a google hangout. When Andrew told me my assignment, it was presented as a verbal list of customer-facing requirements and a few technical pointers (for example, “try using tablib for converting to CSV”).
I had no idea where to start. The project was an exercise in smart google searching and lots of trial and error. It felt weird at the time to be given a project that I would have to learn a lot to complete, and the distributed nature of the development team made it even more intimidating to ask for help when I needed it. A distributed team is a great environment for seasoned engineers to collaborate asynchronously, but it leaves something to be desired for a novice developer in the process of learning. In a non-distributed environment, I could lean over and ask another engineer to look something over or give a pointer - this becomes less natural when you’re collaborating over IRC.
As a result of the team’s geographic separation and my above-mentioned mental blocks, I learned how to figure things out for myself. I started spending more time searching online and participating in StackOverflow than I did wondering when some team member could find time to help me learn. Honestly, I think the distributed environment contributed positively to my learning, as it forced me to break out of the comfort of more experienced devs and learn to fend for myself, so to speak. If I wasn’t already an autodidact, I certainly became one around this time.
There is a lot that you can do as an incoming intern at Parse.ly to make the experience most worthwhile for yourself. Most importantly, learn how to teach yourself. Don’t let insecurity about your skills stop you from sharing your thoughts. React to intimidating projects with curiosity, not fear. Do not be afraid of this man, he is scarier than he looks. I mean, not as scary as he looks. He may be the most opinionated member of the Parse.ly team, but he will teach you to challenge your assumptions and defend your positions. Take every opportunity to learn bits of the codebase you’ve never seen before, in languages you’re unfamiliar with.
In short, do not let any real or perceived lack of expertise stop you from being the developer you can be. Contribute often, teach yourself whenever you can, and allow yourself to be supported by the amazing team you’re entering.
I’m more than happy to provide personal or techincal advice if you’re the target audience for this post. You can email me at emmett dot butler three 2 one at g mail dot com. (Change all number-words to digits and all “dot” to .)
Thanks to Andrew Montalenti, whose encouragement to self-reflection helped these thoughts crystallize
Heads Up was on the front page of Adult Swim dot com
I just googled myself and found this…
1. When did you first create your github repo?
We open-sourced Mr. Schemato live at the TimesOpen event on October 17!
2. Have you been surprised by any of the feedback or contributions from other github users?
The feedback from users has been really helpful. People have run Mr. Schemato on their sites and have essentially served as testers, helping us see how well it’s working now and where we can improve. We could never do all that testing ourselves.
3. Describe your ideal forker/contributor.
We’d love to work with semantic web experts and people who are standards evangelists.
4. Finish this sentence: Open source is ____.
Open source is the only way to do software.
The full story
This weekend, I gave a series of two talks on iOS game development at Pace University’s computer science school. The talks, which introduced developers to cocos2d and box2d, couldn’t have gone as well as they did if I hadn’t learned how to use Git as a teaching tool. I can’t say I was surprised at how well Git fit this role, or at the degree to which it became a stumbling block for those who had never seen it before.
I’ve been using Git for about as long as I’ve been programming seriously. At first, the add-commit-push paradigm was hard for me to grasp, and I learned important lessons through trial and error: stash your changes before you pull, always use the —rebase flag when pulling, et cetera. I learned some rules the hard way: don’t use push -f unless you really know what you’re doing (even when Git’s helpful error output tells you to). To learn this lesson in particular cost me several hours of team code. I know from experience how unforgiving Git can seem to a newcomer.
My workshops were based on a toy project I made in late 2011 to teach myself the basics of iOS game dev, including sprite animation, collision detection, and time-based actions. To prepare this old project for the workshops, I actually rewrote most of the code in a new repository. One might ask why I didn’t just use the old code; the main reason was to provide a full change history to the workshop attendees. For a workshop that was primarily based on live coding, showing the attendees a complete changeset representing our demo app in different stages of development made a huge difference in their ability to learn the material.
As I rewrote the project, I git-tagged each important commit with a number and some semantic content referencing its commit message. For example, when I added walls to the physics scene, I tagged the commit with
git tag 2_walls
This enabled anyone who cloned the repository to checkout commits by semantic content, rather than looking them up by hash. That ability engendered more participation on the part of almost everyone involved, since participants who fell behind could instantly catch up to the rest of the group with a simple git checkout.
The workshops were attended by a varied bunch: some professional developers, many beginner programmers who were interested in iOS, and a few nonprogrammers who came for the design knowledge. Ultimately, the wide variance in participants’ experience levels proved challenging, especially given my presentation’s heavy use of Git. I had to spend some time at the outset attempting to get everyone up to speed on the basics, including the difference between saving and committing, and the importance of stashing and unstashing changes. The workshops, especially the second (a day-long Saturday session) comprised building my demo app with the group: I talked through and wrote the project on a projector as if from scratch, and participants followed along and asked questions. For the beginning of the workshop, when the group was having an easy time following along, I hardly even used the tagged commits.
At some point, though, the going got tougher. Around the time that I started leading the group through spritesheet creation and importing, I could tell that many were getting lost. After I had blasted through the material with characteristic disregard for those slower on the uptake, I noticed more than half of the group looking very confused. Almost nobody had followed my logic, and those who had had made significant changes to accommodate their incomplete understanding of the code. The whole room had code that was inconsistent with what I’d written on the projector, and few people knew how to fix it.
Enter Git tags. As a result of my pre-workshop tag setup, I could ask everyone to stash their changes and checkout the tagged commit that roughly corresponded to our position in the live coding session. This ensured that everyone in the room was playing with the same code, a huge benefit for a workshop leader. Careful planning and repository construction using native Git features saved my workshop.
Used in this way, Git works amazingly well as a teaching aid. To those who would set up their own workshop using a similar Git-based scheme I offer the following advice. Focusing your project on a visible change history obviously works best if your audience is already familiar with Git, at least on a superficial level. If they aren’t, you will spend time (probably more than you’d like) explaining the difference between committing and saving, or between stashing and stash-popping. If you’re alright with splitting your time between Git and your subject matter like this (as I was), it might work well. Also, if you’re live coding with a group and following the structure of a preexisting codebase, the closer you stay to the structure of that code, the less confusing your workshop will become.
Thanks to Andrew Montalenti for seeding the idea of Git as a teaching aid. You can find the repository referenced in this post on my github and a video of one of the presentations on my blog.