Jamie's Blog

My employer gives us a week off for the holidays, so I’d been trying to decide what to do with all of the time. Although I originally didn’t want to work on any programming projects, I wound up working on a few. One of them was inspired by a play of the iOS game Train Yard. I was paying particular attention to the loading screen when I noticed it had been created using Cocos2d. I’d seen articles about the engine before, so I decided to take another look at the Website. I was curious about what other game engines were in popular use. Besides Unity, I didn’t notice any that were more popular than Cocos2d. I decided to investigate further and found a tutorial on the site.

Before I knew it, I was working through the tutorial. The API was simple, straight-forward, and intuitive, and I was soon done. Still, I wanted to use it for my own project. Unfortunately, the holidays were winding down, and Spring term classes will start soon, so time is very limited.

As a prepubescent child, I played a shareware game where balloons would rise on the screen. You’d use your mouse to draw a bowstring, flying an arrow horizontally through the balloon field, timing the ascent of a balloon. It’s this game that immediately came to mind when I tried to think of simple games. The satisfaction of that balloon popping noise made me long to play. (A satisfaction only outpaced by the sound of popping bubble-wrap.)

So, I decided to work on a game like that other game, and started on making balloons float up. I went to http://openclipart.org and found a great balloon-popping sound at http://soundbible.com. I started out by using CCActions, a CCSequence composed of CCMoveUp and CCCallFuncND to perform cleanup. The balloons would randomly spawn at a certain interval below the screen, and rise to a height above the screen, out of the viewport, and be removed from the layer.

Somewhere along the line, I decided that an bow and arrow would be unnecessary, and that touching a balloon would be enough to pop it. At the same time, I’d target the game at children. I implemented procedures to detect a balloon touch, show a particle effect upon touch, play the popping noise, and remove the balloon from the layer immediately.

Play-testing confirmed this mechanic was a little boring in of itself. I figured that popping balloons should release things stored inside, so you should be able to earn points for popping balloons and touching a “treasure item” dropped from the balloon, things like: diamonds, coins, and treasure boxes. I also added clouds in the background, a timer, and score display, the concept of rounds, and a game over state.

I got this working, but it didn’t seem especially targeted towards children. Lisa, my wife, tried it and confirmed as much. We talked about marking each balloon with a letter, and using the balloons to spell words or elsewise learn about words.

After thinking for a bit, I decided that balloons marked with a letter would release a word starting with that letter. When you touched the word dropped by a balloon, that word would be spoken aloud. I downloaded Audacity, and had Lisa recite a list of words. I spliced them and loaded them into my project Resources folder. Once I got the code working, so that the word sound would play when the word was touched, the audio seemed to low, like it had not been normalized. Even after reducing the volume of the background music and popping sound, the words weren’t loud enough. We’ll have to redo the word sounds at some point.

At this point, I’m mostly done, but may add some more graphics and clean up the code. This project has been a great introduction to Cocos2D and Objective-C programming, in general.

Check out game footage below and the complete source code, including assets, on Github: http://github.com/jamiely/ios-balloon-burst

Here’s a great wrapper that really simplifies working with KeyChain in iOS http://log.scifihifi.com/post/55837387/simple-iphone-keychain-code. The code is on GitHub as well http://github.com/ldandersen/scifihifi-iphone/tree/master/security/.

Apple’s official documentation is here, and there is also a sample project, but it’s not a good example for getting up and running quickly. The version of the project (last updated 10/2009) doesn’t even run on the simulator.

Thinking about the problem domain, Trevor, Sebastian, and I decided to abstract away the complexity. The problem (as I understood it then) can be explained thusly:

Students need a way to follow a list of scheduled tasks throughout the day, to assist them in performing daily activities. These tasks can be broken into more detailed tasks with steps or choices. A choice, such as what to have for lunch, is non-linear. A choice helps a student develop his sense of independence. Each choice and task may have accompanying text and audio.

Day to day within a week, the schedule of tasks may be different. Weeks can also differ from each other.

Given these simple business requirements, we decided that a step, a task, and a choice were all the same in that they had a name, audio content, text content, and that they had a parent-child relationship with each other. We decided that all of these would be “tasks” and that there would be a “task type” field to differentiate between these. The “task” paradigm yields the following definitions:

• A task is a task with linear/sequential sub-tasks
• A step is a task with no sub-tasks
• A choice is a task with non-linear, non-sequential sub-tasks

We also decided, after further discussion to make certain other things tasks. We thought that days and weeks were similar enough to a task in the parent-child relationship. We decided that

• A day is a task with linear/sequential sub-tasks whose name is a weekday
• A week is a task with day sub-tasks (days as defined above)

This allowed us to have a single Task model, and a Task Parent model, which greatly simplified the API. Instead of making REST calls to create a step, create a week, or create a choice, there would be just one create call, with a task type defining the behavior of the task. This would also make copying tasks and task trees easier, since we would only have to work with one model when doing a deep copy of a task tree.

Although this made the API really quick to build, when I started writing the builder code, interacting with the API, I found the API to be a bit low level. For example, I would have to make two calls to bind a new task to a user. First, I would have to create the task via the API, and then create the user-task relationship via the API. As I was writing nested callbacks with the jQuery ajax functions, I questioned our decision to make the API so simple. Still, I think the API is a thing of beauty, and I am still proud of what we did that weekend.

As the MECA staff were describing the application, I didn’t have a clear sense of how beneficial our work would be. To illustrate how our application would help people, they showed us a video of a student going to a gym. In the first clip, the student has trouble following directions and signage about the use of gym equipment. In the second clip, the student is following auditory prompts and exercising at the gym with little trouble.  Another student was able to prepare a meal with the help of visual prompts from a PDA. It was illuminating to see the difference that prompts could in someone’s daily life and spurred us to work even harder.

We decided to split the application into 3 components:

• A REST API written using Rails
• A HTML/Ajax builder web application
• An iPhone user application

We had a team of about eight people, and we knew we had to separate tasks somehow. There were some individuals with iPhone experience (mostly novice stuff like simple view demos), and some with Ruby experience, and then there were two designers with CSS and some jQuery experience.

We figured Trevor, who has extensive Rails experience should lead the API effort, and that Brian, who has done the most, albeit little, iPhone development using MonoTouch should lead the student application effort, while the designers should focus on designing and implementing some of the builder code. (The interface for the user application had already been worked out by group consensus.)

I decided I could best help with the API, so I worked with Trevor on that. Something that I think amazed all of us was that once we had assigned ourselves to teams and broken the project up, we functioned seamlessly, all of us entering the zone in our respective areas. It’s the kind of synergy and flow you get when the majority of your team knows their shit. It was an incredible experience to be a part of that.

We had a good framework and sample response API for the student interface and builder to start building plumbing by the time we left on Friday. Meanwhile, the iPhone app team had gotten some samples working using Monotouch. The builder interface was looking really sharp. We were off to a good start when we decided to break for the night around midnight.

In the next post, I will describe some of the insights behind the API.

Dani led us into a different conference room from the main room that most of the other conference attendees stayed in the entire weekend. We met MECA members Gloria, Kaori, and Avi who teach autistic individuals how to function independently. They discussed some of their current work and successes, including the Preparing Adolescents for Adult Life (PAAL) program.

There a number of programs that are used to make an individual’s life easier. One, used by an individual with speech impairment, is a Powerpoint presentation featuring images of common items. Clicking on an image plays a sound file that represents the image. In this way, the individual can communicate with others.

Another program is a sort of flash-card program. This program helps guide a student through daily tasks by breaking the tasks into granular steps. The program also provides a choice option that prompts the user to choose among a set number of options. Although the user program is fairly effective, the authoring application for these files is cumbersome to use. Two drawbacks of this program exist:

1. There is no monitoring component built in. Monitoring of students is done on paper.
2. There is no schedule component to the application, which would provide the students a task list of activities for the day

MECA wanted a program that not only was easy to use for students, but also a program easy to use for instructors to author lessons. Additionally, a program that incorporated a task-list and monitoring component would be especially helpful.

While the staff explained some of the requirements, we were joined by other team members: Brian, Erik, Sebastian, and then Joe. There was another person who came to help during the night but he didn’t come on subsequent days. Much of that first Friday evening was spent just gathering requirements and attempting to fully understand the problem.

When we finally thought we had enough to start, it was around eight or nine at night. In the interest of time, we decided we would not work on a monitoring component. We decided to break the remaining problem into three components:

• A REST API written using Rails
• A HTML/Ajax builder web application
• An iPhone user application

The next post will discuss the reason for this split.