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

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.

Difficulty Tuning

We knew from early in the Heads Up project that the flow of gameplay would center on hot dogs falling more and more frequently. We were looking for ways to gradually ramp up the difficulty per game in a semitransparent way. We wanted players to not really notice the difficulty ramp, so that without realizing it they’d end up in some arcade zen. Originally, we had the idea that having more people on screen would make the game harder, so we also slowly ramped up the number of people on screen as well as the speed of falling hot dogs. Pretty quickly, though, we realized that having more people on screen actually made things way easier, so we allowed the people spawn speed to remain constant.

We also tried shortening the amount of time a hot dog could live on the ground before decaying as a method of increasing difficulty, but our attempts at this made the game way too hard - after a short time, hot dogs wouldn’t sit on the ground at all, making things very difficult. That idea was eventually scrapped in favor of simplicity.

At first, the gradual decrement of the hot dog spawn rate was based on time: at certain time intervals, the rate would be decremented by some discrete value (eg at 30s, delay -= .5). The main problem with this method was that a player who was slower at mastering the mechanic would be faced with a huge challenge before they were ready for it and the game would feel way too hard.

Instead of time benchmarks, spawn-time decrementing in the production version is based on point benchmarks, so the effective difficulty of the game is dependent on how well the player has done so far. For example: delay -= .5 at 10000 points, 20000 points, etc. This way, slower players still feel appropriately challenged. This strategy alone doesn’t stop players from feeling that the game gets too hard too fast, but it does put players on the same footing, so at least most players should feel that the difficulty increases at the same rate.

Interesting note: when the timing of these difficulty increases is literally identical across player skill levels (ie increase at 30s, 1m, 90s, etc….), some players complain that the game gets difficult too fast. However, when the timing is adjusted based on player skill (ie different for everyone), players feel like it’s consistent. Interesting how that works.

For a while, the delay between hot dog spawns was the only parameter being adjusted to increase difficulty. Somewhere along the way, we decided that having 18 hot dogs on the screen at once might be unmanageable. We introduced a maximum number of dogs onscreen, in an attempt to mitigate that issue. This ended up becoming another parameter used to affect the difficulty - increasing at certain point benchmarks. For example: at 50,000 points, increase the maximum from 7 to 8. This, combined with the spawn delay decrements, proved to be enough to create a frantic feeling in the players.

This also leads to an emergent wave pattern in the hot dog spawns. Enforcing a maximum means that even if the spawn delay time is past, a new dog won’t spawn unless there are less than the max onscreen. If not, it will wait to spawn until some dogs are removed. This means that if the max is hit and all of the onscreen dogs leave on a single head, more will come down all at once. This creates the feeling that things are frantic but still manageable.

I’m reminded of a funny story from testing: I noticed one day that one of the testers had posted a Game Center high score higher than I’d ever gotten - somewhere in the 150k area. Thinking I was the best Heads Up! Hot Dogs player in the world, I immediately started a game trying to beat his score. After passing about 50000 points I noticed that I had neglected to account for someone being this good at the game. The dog spawn rate didn’t increase past that point, and gameplay quickly became boring for a player who was practiced enough to manage the five hot dogs.

Side note: I missed the guy’s high score by about 100 points. T__T

This was a great catch, though, since it led me to ensure that skilled players wouldn’t ever reach a plateau of difficulty. I made sure that after a certain point, the game would increase in difficulty much faster than it had before, almost guaranteeing that high-level players would still have something to do up there at the top.

What does all of this mean? I think we did a good job of creating a curve that feels fairly transparent to the player. Maybe that’s a goal for arcade games with mechanics as simple as ours.

HotDogManager

There was a point in Heads Up development when I started realizing that I had to account for the iOS actions surrounding its execution - home button taps, double taps, sleep button presses, music and sfx changes, and things like that. Yes, this moment only came after months of never thinking about these things (it’s my first app, ok?) Before then I’d been mostly avoiding the questions that couldn’t be solved by not allowing the app to run in the background, until I noticed the double-tap home button question.

Some of the boilerplate that Cocos had put into the project paused and restarted the gameplay automatically on applicationWillResignActive and applicationDidBecomeActive, the functions that the app delegate calls when the home button is double-tapped to bring up the little list of apps on the bottom of the screen. This was great for me, since I didn’t need to worry about how to do that pausing myself…

until I implemented an in-game pause screen. Immediately I ran into the issue where every time the user dismissed the app list, the action on screen would restart, including when the pause screen was up. This meant that the pause menu would stay there with action running behind it - obviously not a good situation.

My immediate reaction to this is to tell the app delegate about when the pause screen is up, so it knows when to start the action and when not to - but the app delegate and the gameplay screen are in different and apparently unrelated files. I don’t really remember what I tried, but I quickly realized that this was a pretty good use case for a singleton (a class that is guaranteed to only be instantiated a maximum of one time).

So now there’s a HotDogManager singleton that maintains a state flag called isPaused that indicates whether or not the gameplay pause screen is displayed. Since there’s only one instance of the manager, the app delegate can just check it and see whether it should restart action.

// in applicationDidBecomeActive 

if(![[HotDogManager sharedManager] isPaused]){
    [[CCDirector sharedDirector] resume];
}

It works quite nicely. That was the original use case, and since then I added a few more flags to the singleton to help keep track of more global state - things like sfx on/off, app running time, functions for reporting analytics events, and some more.

Another awesome side effect of this is that now that the app always knows if it’s paused or not, I can let it run in the background and display the pause screen if the user leaves and comes back in the middle of a round. This actually works by always resuming the game loop upon the app entering the foreground, and then checking within the game loop whether to display a pause screen. Something like

// in the game loop... 

if([[HotDogManager sharedManager] isPaused] && !pauseLock){
    // display the ingame pause screen and freeze the action 

    [self pauseButton:[NSNumber numberWithBool:true]];
    // make sure we only send the pause command once 

    pauseLock = true;
}

When the app enters the background, isPaused gets set true. Then as soon as the app comes back up, one cycle of the main loop runs and then this code gets hit, freezing the action before the second loop.

Beyond being pretty cool, I feel like this functionality might improve engagement or retention or some other marketing word since the user isn’t always forced to restart their games when they get phone calls or whatever.

This was my first time using a singleton, and if the idea had occurred to me sooner, I probably could have done an even better job of storing all of the global state in this manager, similar to how cocos does it with the CCDirector. But I suppose that’s the next project.

I’ve thought of so, so many ways I could refactor this code and make it way nicer. Effort probably better spent on making the next project awesome, though.

~emmett