emmett9001

Parse.ly Blog: To the Next Parse.ly Intern: Learning is Not A Race

Wed, 15 May 2013 10:30:25 -0400

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.

Rainbow Smoke Experiments

Tue, 14 May 2013 15:40:00 -0400

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.

To the Next Parse.ly Intern: Learning is Not A Race

Tue, 14 May 2013 10:48:00 -0400

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

ninjashadowwarrior: 35 points

Thu, 09 May 2013 08:05:56 -0400

ninjashadowwarrior:

35 points

Heads Up was on the front page of Adult Swim dot com

Sun, 31 Mar 2013 11:11:46 -0400

Heads Up was on the front page of Adult Swim dot com

Schema.to Publicity

Fri, 08 Mar 2013 10:39:00 -0500

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

How Git Saved My Workshop

Mon, 25 Feb 2013 11:47:00 -0500

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.

Yesterday, I gave the first of two iOS game development...

Fri, 22 Feb 2013 09:18:00 -0500

Yesterday, I gave the first of two iOS game development workshops at Pace University. I spoke and answered questions about cocos2d and box2d for two hours, and I captured it all on video. This video uses https://github.com/emmett9001/iPhoneGameDemo for code examples. Enjoy!

This week Nina, Diego and I participated in a nine-day game jam...

Mon, 18 Feb 2013 20:43:09 -0500

This week Nina, Diego and I participated in a nine-day game jam hosted by Sony. They gave us access to the Playstation Mobile SDK, which provides a 2D game engine abstraction in C# and targets the PS Vita. We made a game in which you control a robot gardener searching for the perfect interspecies plant hybrid. Nina and I pair-programmed pretty much all of this, and Diego’s art is legend. We had a lot of fun, especially watching our friends from the NYU Game Center take home a semifinal spot!

Thanks to Sony and Indiecade for this awesome opportunity!

Some recent graphics tests from my game engine project. These...

Thu, 14 Feb 2013 10:32:46 -0500

Some recent graphics tests from my game engine project. These tests illustrate the sprite drawing and transforming capabilities of my rudimentary OpenGL-based system. Excluding the creation of the graphics context and OpenGL itself, all of the code executing to achieve these effects is my own (especially the transformation matrix math!). The last two examples are currently serving as stress tests for the renderer, which runs them at about 18 fps. The next step is some basic physics!

I especially love the pattern I was able to create in this last example, because this beautiful result came about totally by accident. The code that accomplishes this motion is fairly simple.

indiecade: The teams are hard at work for the PlayStation...

Mon, 11 Feb 2013 12:50:36 -0500

indiecade:

The teams are hard at work for the PlayStation Mobile hosted GamJam. See what they come up with at IndieCade East, Feb 15-17, at the Museum of the Moving Image in Queens, New York.

You, me and @hentaiphd

donutgoku: colorlimit: SPAWN MY BABBIES ~LEARNING ABOUT...

Sun, 10 Feb 2013 17:29:33 -0500

donutgoku:

colorlimit:

SPAWN MY BABBIES

~LEARNING ABOUT SPRITES~

watch ‘em makin’ children~*

Heads Up postmortem pt. 6

Mon, 31 Dec 2012 12:28:53 -0500

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.

deckman: my friend emmett and i are working on a music...

Fri, 21 Dec 2012 17:13:12 -0500

deckman:

my friend emmett and i are working on a music visualizer using c and opengl. our goal is to make it cool enough for chiptune visuals (and to make it stop using up half our system resources)

what should we name it?

3d audio visualizer

Started the gfx side of this like a week ago lol

seriously though, names?

Heads Up postmortem pt. 5

Fri, 07 Dec 2012 09:12:26 -0500

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

Heads Up postmortem pt. 4

Tue, 04 Dec 2012 11:08:59 -0500

Touch Tracking

Since Heads Up’s core gameplay centers on the quick manipulation of physics objects with touches, designing some system that allowed it efficiently and cleanly was one of my biggest concerns during development.

We knew from the beginning that we wanted to allow players to grab hot dogs with their fingers, and this basic interaction was something that I actually learned on my first night working through some example box2d code. The general idea is simple: when a touch event happens inside the boundaries of a grabbable object, create what box2d calls a mouse joint, which is a type of physics joint specifically made for mouse (or finger) manipulation. Use this joint to connect the finger and the object, moving the object to the touch position for the duration of the touch, and destroying the joint when the touch ends. Not so bad.

The big requirement that made this more of a problem was multitouch. When we had the guarantee that only one hot dog would ever be grabbed at a time, it was easy to use the simple algorithm above to move it along with the only touch. When there could be more than one grabbed hot dog at a time, though, there was suddenly the issue of determining which touch should have which hot dog attached to it.

My first try here was to use the above algorithm to try and handle more than one touch, with predictably unsatisfying results. One touch still worked fine, but touching anywhere else on the screen (grabbing a hot dog or not) caused the hot dog that the first touch was holding to float halfway between the two touches, constantly having its target position alternated between the two touch positions. The program logic was telling the hot dog to be in both positions at once, instead of choosing just one touch to hold it.

Aside: I guess I probably had no idea why that was happening at the time, and I most likely said something like “that’s a showstopper bug”. This seems a lot simpler in hindsight.

So this was a problem. It seemed like a big problem. I was scared of it. And intrigued.

My naive approach was, essentially, an attempt to roll my own system of identifying touches uniquely. “Why would he do that?” you might wonder, “Doesn’t he know about touch hashes?” Unfortunately the answer at the time was no. But more on that in a moment.

My best attempt to uniquely identify touch events was based on movement tracking - intuitively: “if this touch is close to where touch A was a second ago, this touch must be touch A”. meh.

The touch’s last known position was saved and compared to its current position, and I treated them as part of the same “macro” touch event if the current and past positions were close enough together. I was actually really happy with this implementation at the time, thinking I was pretty smart for figuring out what (for some reason) I hadn’t been able to find on any box2d forum.

Predictably, though, there were a ton of problems. Worst, since the comparison between positions involved testing an absolute value for proximity to zero, the bottom left corner of the screen became a bug haven (in cocos, bottom-left is the origin). The dog-grabbing logic sort of broke down near this area. Aside from that, the design imposed a maximum speed for hot dog dragging, since touches that moved too far per frame would leave their hot dogs behind. As a result, the core interaction felt kind of sluggish. Sometimes hot dogs wouldn’t respond to touches. Sometimes they’d get stuck in midair. Bringing two dragged hot dogs close enough together made them do strange things. Not good.

We lived with this system for a while, through the early testing phases. Testers reported all of the bugs mentioned above (which I already knew about). Then one day, for some reason, I decided to google something like “ios touch event identifier” and discovered that iOS gives each complete touch event its own unique id for its entire duration - that is, across touchesBegan, touchesMoved, and touchesCancelled - the hash.

Suddenly the whole problem became practically trivial. Not having to worry about providing touch ID myself, keeping hot dog grabs separate was as simple as comparing new touch hashes against stored ones. The above intuition becomes “if this touch has the same ID as touch A, then it is touch A”. Much better. (Notice the difference in wordings: “must be” versus “is”)

Look at this code:

// in CCTouchesMoved

for(NSValue *v in dogTouches){
    // stored as NSValues

    DogTouch *dt = (DogTouch *)[v pointerValue];
    // get the touch hash for this stored touch

    NSNumber *hash = [[dt getHash] retain];
    // compare the currently processed UITouch with this DogTouch by hash 
    if(hash.intValue == [touch1 hash]){
        [dt moveTouch:[[NSValue valueWithPointer:&locations[0]]retain] topFloor:FLOOR4_HT];
    } else if(count >= 2 && touch2 && hash.intValue == [touch2 hash]){
        [dt moveTouch:[[NSValue valueWithPointer:&locations[1]]retain] topFloor:FLOOR4_HT];
    }
    // have to pass in the height of the top floor here, since moveTouch needs 
    // to know about it and it varies across platforms (iPad, iPhone) 
}

dogTouches is an NSArray of NSValues containing pointers to DogTouch objects, which in turn contain a stored hash for the touch to which they belong, as well as methods for positioning the hot dogs according to the touch position. count on that array easily tells how many hot dogs are grabbed at the moment.

This code deals with a touch event ending (ie a finger being pulled off the screen):

// the cocoa touch events that just ended 
for(UITouch *touch in touches){
    // our stored touch objects 
    for(NSValue *v in dogTouches){
        DogTouch *dt = (DogTouch *)[v pointerValue];
        NSNumber *hash = [[dt getHash] retain];
        // if the touch that just ended has the same hash, 
        if([touch hash] == hash.intValue){
            // drop the hot dog associated with that touch 
            [dt removeTouch:FLOOR4_HT];
            [dt flagForDeletion];
        }
    }
}

With this implementation, dog grabbing is faster, more responsive, and less buggy (and dare I say more fun?) than it ever was during testing. Much better.

~emmett

Heads Up postmortem pt. 3

Tue, 27 Nov 2012 09:36:52 -0500

Cheat Codes

Near the end of the Heads Up development cycle, we were looking for some easter eggs to covertly sprinkle around the app - I guess to put our “signature” on it, in a way. I like the idea of knowing something about the app that nobody else does, and having that knowledge be demonstrable in such an obvious way as a secret cheat code, so if a friend is playing on their phone, I can say “hey check THIS out” and suddenly drop into Spicy Chorizo Hell Mode*. Yes, this is a self-centered view of my role as the developer. Sorry. It’s fun.

Also, cheat codes are a dying breed, and including some makes Heads Up feel all the more “retro” (as much as that description stinks)

So the codes are secret, and obviously I’m not revealing them here. But I had fun implementing the cheat code recognizer.

The codes are entered by performing a specific series of directional swipes at the level select screen. All of the menu screens in Heads Up actually have their own main loops in the form of tick functions, which I sometimes use for running or switching animations, or in the case of the level screen, moving between the levels and processing cheats.

The cheat recognizer is pretty simple: every time a directional swipe is performed, it places a string representing the swipe direction into its buffer, and once the number of entered swipes is equal to the length of the cheat it’s responsible for, compares the buffer to its “correct” cheat code direction sequence. One of those might look like

NSArray *cheatSwipeSequence = @[@"l", @"u", @"r", @"d", @"r", @"u", @"l", @"d"];

After that check, the entered swipes buffer is freed, to allow the next attempt to be made.

The one other bit is that if a certain amount of time goes by without any input, the swipes buffer is cleared - that’s necessary to allow multiple attempts and multiple cheat code entries.

Obviously, the strings used to represent the swipe directions could just as easily be chars or ints, since they really just represent one of four states. I wanted the sequences to be easy to read, though (so I can remember them!)

I don’t know how old-school button sequence cheats are implemented, but I imagine it’s something really similar to this - keeping sequences of entered inputs, validating, and then releasing for retry.

The one other thing about this implementation is that I was feeling lazy about learning how Cocoa’s built-in gesture recognizer classes work, so I just wrote my own (certainly an interesting manifestation of laziness). Naively, I first tried simply comparing the start and end position of the swipe, checking each of the directions (eg last.x > first.x means the swipe was to the right) within a four-part if...else. This didn’t work too well, though, since using else excluded some checks, and using only if produced two outputs (eg “u” and “r” for an up-right swipe). That’s fine, but it didn’t totally fit what I wanted - I just required the main direction of the swipe, disregarding the smaller component of its vector.

if(firstTouch.x < lastTouch.x && swipeLenX > swipeLenY){
    // right swipe

}
if(firstTouch.y > lastTouch.y && swipeLenX < swipeLenY){
    // up swipe

}
if(firstTouch.y < lastTouch.y && swipeLenX < swipeLenY){
    // down swipe

}
if(firstTouch.x > lastTouch.x && swipeLenX > swipeLenY){
    // left swipe

So, in the final version of that bit, I check the larger component of the swipe vector, which I imagine is very similar to what Cocoa’s recognizers do for directional swipes.

~emmett

*Spicy Chorizo Hell Mode may or may not actually exist

At NYTM

Wed, 14 Nov 2012 14:00:15 -0500

At NYTM

Heads Up postmortem pt. 2

Wed, 14 Nov 2012 09:06:20 -0500

Storing Level Data

In classic Emmett form, the first time Diego mentioned the idea of multiple levels/areas in Heads Up, my reaction was something between “how do you do that” and “that’s impossible”. Claiming that problems are unsolvable is apparently a favorite pasttime of mine, and at the time (around April), I could barely conceptualize the work necessary to set up different levels. Of course, having done it, the problems now seem totally trivial, but that’s called learning I guess.

I was still a bit uncomfortable with Objective-C at that time, and a big question I had was “how would we avoid massive code duplication across levels?”. My gut reaction to the idea was that all of the game logic code would at best be put into utility functions, at worst be copy-pasted for each level*.

Luckily, I at least knew enough about good coding practices at the time to know that both of the above were horrible ideas. Both were based on the idea that each level would be contained in its own cocos2d screen, totally independent from the others. This probably seemed like the most reasonable idea at the time.

I ended up slowly easing into a fully formed level implementation step by step. First, we wanted to randomly choose a background image for the round: Philly or New York (the only two backgrounds that were finished at the time). This seemed much less intimidating than “building levels” to me, so this time my reaction was less fearful and more pragmatic. Easy, just switch on a random number between 1 and 2 at game load time to choose between two background images. We did something similar to choose audio tracks for each round.

The real meat of the levels implementation came when I wanted to create a linking between the background and the music - so that every time the NYC background was shown, we’d hear the same music. This was solved simply enough by storing a struct with the string name of the background and the string name of the audio file, one struct for each level. Then, the random choice at load time was between two structs instead of two strings. Much better than turning the whole game loop into shared code (or copypasta).

Over time, ths struct grew to include lots of data about a specific level, until it grew into what you see below (truncated for brevity)

+(NSValue *)chicago:(NSNumber *)full{
    BOOL loadFull = [full boolValue];

    // some properties are used only in-game, others are used on multiple screens

    // this saves load time on non-game screens 
    levelProps *lp = new levelProps();
    lp->enabled = true;
    lp->slug = @"chicago";  // canonical identifier

    lp->name = @"Chicago";  // user-facing name

    lp->unlockNextThreshold = 8000;  // used for determining trophy level

    lp->thumbnail = @"Chicago_Thumb.png";  // level select screen image

    lp->func = @"switchScreenChicago";  // callback function to load level 
    if(loadFull){
        [[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"sprites_chicago.plist"];
        lp->bg = @"Chicago_BG.png";  // gamplay background

        lp->bgm = @"04 - Chaos Dog In The Windy City.mp3";  // gamplay music

        lp->introAudio = @"03 - Chaos Dog In The Windy City (Intro).mp3";
        lp->gravity = -27.0f;  // force of gravity per level

        lp->spritesheet = @"sprites_chicago";
        lp->sfxVol = .8;
        lp->personSpeedMul = 1;  // multiplier for people's walk speed

        lp->restitutionMul = .8;  // multiplier for head bounciness

        lp->frictionMul = 1.1;  // multiplier for head friction

        lp->maxDogs = 6;  // initial value for max dogs allowed onscreen

        lp->hasShiba = true;  // is the dog in this level

        spcDogData *dd = new spcDogData();  // each level has a special sandwich

        dd->riseSprite = @"ChiDog_Rise.png";
        dd->fallSprite = @"ChiDog_Fall.png";
        dd->mainSprite = @"ChiDog.png";
        dd->grabSprite = @"ChiDog_Grab.png";
        // ...

        lp->spcDog = dd;
    }
    return [NSValue valueWithPointer:lp]];
}

Looking back on this progression from naive implementation to sensible one, I notice that the main difference between them is an attention to the actual form of the problem. Turning the game loop into shared code between different level views might work in some other cases, but for Heads Up it seems like overkill. A lot of code would still be duplicated. Storing level data as structs, on the other hand, abstracts the idea of a level out only as far as one level differs from another. All of the levels are more or less the same. Hot dogs are always falling from the sky, sitting on the ground, and then dying after some amount of time. All of the physics are the same. People move in the same patterns. We don’t need vastly different functions to deal with these.

The level structures encapsulate the exact ways that the levels differ from each other, and nothing more. At load time, a struct is chosen from the array of all level structs based on the slug field.

// populate an array with all of the level structs

NSMutableArray *levelStructs = [LevelSelectLayer buildLevels:[NSNumber numberWithInt:1]];
for(int i = 0; i < [levelStructs count]; i++){
    level = (levelProps *)[[levelStructs objectAtIndex:i] pointerValue];
    // if the slug is the one the levels screen passed in

    if(level->slug == levelSlug){
        // use it

        break;
    }
}

Looks like it might make more sense to pass in the whole struct here rather than loading all of them and discarding all but one.

The slug field of the level struct is also useful for storing persistent data like high scores and unlocked levels. Cocoa allows apps to store a plist file full of arbitrary keys and values persistently on the device, called NSUserDefaults. I think that’s normally used to store the defaults for user-editable settings. I do use it for that a bunch, like storing the sfx on/off preference, but I also use it for the progression data mentioned above. The slug helps here since I can store a key like

[standardUserDefaults setInteger:_score forKey:[NSString stringWithFormat:@"highScore%@", level->slug]];

persisting the high score for the current level. I do something similar for unlocked/not unlocked and the highest trophy earned per level. I can read the stored data with

highScore = [standardUserDefaults integerForKey:[NSString stringWithFormat:@"highScore%@", level->slug]];

And just like that, we have persistent storage of per-level data.

Another clever and possibly questionable overloading of the slug functionality is the way that the code chooses characters per level.

+(NSMutableArray *)philly{
    NSMutableArray *levelArray = [[[NSMutableArray alloc] init] retain];

    [levelArray addObject:[NSValue valueWithPointer:[self businessman]]];
    [levelArray addObject:[NSValue valueWithPointer:[self youngPro]]];
    [levelArray addObject:[NSValue valueWithPointer:[self jogger]]];

    return levelArray;
}

Each level has a function associated with it, simply named the same as the level’s slug. Objective-C lets you call functions by string name pretty easily, which makes this work awesomely. This function calls a few others, each of which load a specified set of data encapsulating the differences between characters. Similar to the level structs, these character structs only hold the data indicating the important ways that the characters differ from each other - running speed, head bounciness, etc.

Each of the characters also has a “weight”, which is used for probability weighting! Some characters show up more often than others (eg the cop and the hipster guy are rare). I might show that code in another post, but this one has enough code already.

So there’s a whirlwind tour of the level-storing logic in Heads Up. There’s a lot of it, and aside from the game logic itself, this implementation probably took the most effort out of any in the app.

~emmett

*Disclaimer: I realized how bad an idea this was long before I would have tried it. Don’t worry.

Diego and I demoing Heads Up Hot Dogs at the New York Tech...

Wed, 14 Nov 2012 08:50:09 -0500

Diego and I demoing Heads Up Hot Dogs at the New York Tech Meetup.