Daniel Pasco:

Make no mistake: a lot of people – including people on my own team – have been seeing legitimate issues, and their productivity is being impacted. But what bothered me was the scarcity of tweets mentioning bug reports. Many people weren’t actually doing anything about it besides voicing their distress

If you’re not familiar with radars, please read Dan’s post. It is the best explanation of what they are and why they’re important that I’ve seen.

At the end of the article, Dan listed a series of radars from Open Radar that he (and many other developers including myself) hopes that you will take a look at and dupe. After reading through those radars I spent some time looking through Open Radar, and I found a few gems. Some of these are from Dan’s list and deserve more exposure and some are more thought provoking (or humorous) than mission critical, but all are worth reading, considering, and duping if you’re affected by them:

• Create NS/CGRect class which knows its own coordinate space
• Problems in red text require your attention not useful if colourblind.
• Mike Jurewitz is answering questions on Twitter instead of enjoying his vacation
• Update documentation with known bugs / workarounds
• Make 3rd party issues in radar searchable by outside developers
• iOS Simulator Frequently hangs; can’t register with the bootstrap server

After reading my article on pushing web views, one of my co-workers pointed out a mistake.

Here’s what I said:

The only reason Mobile Safari gets away with putting back and forward buttons in the bottom left is that there is never a back button in the top left of the app, as real estate is scarce up there. Note that, on the iPad, these controls are in their rightful place, thanks to the larger screen.
- Please Stop Pushing Web Views

Michael (@turbotomato) disagrees, and points out that the HIG outlines specific use for Toolbars, as well as positioning:

A toolbar contains controls that perform actions related to objects in the screen or view.
…
On iPhone, a toolbar always appears at the bottom edge of a screen or view, but on iPad it can instead appear at the top edge.
- Apple iOS UI Element Usage Guidelines

Taking this into account, it’s definitely arguable that this is the reason Mobile Safari keeps the web view navigation controls in the bottom toolbar on iPhone, vs the top on iPad. One could also argue that placing these controls in the top left on an iPhone would break consistency, because of this choice by Apple. I’ll concede that point as well.

However, as Michael will agree, this doesn’t change the larger issue. Having two “Back buttons” on a screen is both confusing and sloppy.

Twitteriffic for iPhone seems to have the best solution. Modal presentation, Done button top-right, web view controls in a toolbar at the bottom, no navigation back button (unless the hyperlink was tapped inside of a modal view, but that opens a whole separate modal-on-modal can of worms, so I’ll give them full marks). Consistency achieved + HIG hounds called off.

Originally posted on the while(YES) blog on May 5th, 2011

A user is looking at a table view of web-related content. This might be a list of Tweets, or an RSS feed, or what have you. This table view’s view controller is in a navigation controller’s stack, and a navigation bar is being used to manage navigation through the stack hierarchy. Typical navigation controller usage. Nothing out of the ordinary.

The user taps a hyperlink in the table view, and a web view is pushed onto the navigation stack to display the desired web page. In theory, that’s exactly what we’d expect to happen. The user is drilling down through a hierarchy, getting more specific with each step, with a back button consistently appearing in the top left of the screen, ready and willing to take them back a step. These are all things the navigation controller was made for.

The problem is that “back a step” bit. In this example, the back button would take us back to the previous screen, the table view. But this case adds an unforeseen twist: web views have their own navigation structure. They have their own notion of “back”.
If the user taps our hyperlink, the web view is pushed onto the navigation stack, and the page loads.

If they then tap a link on that page, a new page loads within that web view. Now, if they want to get back to the table view, they tap the back button. However, if they want to go back to the previous WEBPAGE, they need a method to do that. A common (and mostly correct) solution to this is to add a toolbar at the bottom and provide back and forward controls for the web view.

For some visuals, see these screenshots of Reeder, TweetBot, and Facebook. Problem solved?

Well actually, no. This is the solution adopted by many app makers, but it turns out the user (me) has been programmed by Apple to use the trusty back button, in the top left of the screen, to go back. This is doubly enforced: both by the navigation controller’s behavior, and by virtually every web browser in the world, save Mobile Safari (iPhone/iPod). Muscle memory is a very powerful thing. Top left == back.

The only reason Mobile Safari gets away with putting back and forward buttons in the bottom left is that there is never a back button in the top left of the app, as real estate is scarce up there. Note that, on the iPad, these controls are in their rightful place, thanks to the larger screen.

I can not tell you how many times I have dug 3 or 4 pages deep on a blog I found through my favorite RSS reader, Reeder, only to have all that navigation history thrown away when I impulsively tap the wrong back button, only to return to the article index.

So what’s the solution? Simple. Present web views as modal views. Keep your back and forth controls in the bottom left to stay in sync with Mobile Safari (unless you’re on an iPad, then I’d argue that you should put them in the top left). Provide a Done button in the top right to allow the user to dismiss the modal and return to the previous view. Potential user confusion and rage averted.

Don’t underestimate the power of muscle memory when designing your user interface. Look at your choices through the lens of the user’s expectations. Don’t confuse navigation metaphors, especially the subtle ones. And please, for my sanity, stop pushing web views.

UPDATE

The fine folks at The Iconfactory have it right, by the way. Twitteriffic rocks the modal web view controller the way it should be. That’s honestly almost enough for me to switch back from TweetBot. Now if someone would just fix Reeder…

Originally posted on the while(YES) blog on May 4th, 2011

Bear on a Wire Trailer from bearzo on Vimeo.

The Game

Our first IPhone game, previously code named Poor Bear is officially available in the app store today under the name Bear on a Wire. For those of you who followed the progression of the game on our site (1, 2, 3, 4) know that this game didn’t start with designs, requirements, deadlines, or the promise of gold bars. Instead it was built on the premise that we could make something fun that we molded just how we wanted it. That mold shifted and turned over time. Even at the starting gate, we didn’t even know what type of game we were making. The game really grew organically and took on a life of its own. I’m personally blown away with the outcome, especially considering this was Chad’s (the developer) first game and he went into it not knowing Objective C. The design is a work of art as well. However, for those of you know Trevor (the designer), know that you could expect nothing less. Words can’t do justice to what 1 designer and 1 developer have done with this game. It is simply amazing and even though it is our own game, none of us can stop playing. That was the point though. We built something we loved. We hope you will too!

Support Us

We appreciate any support you can give us. For those with an IPhone grab the game now, rate it, and review it!
APP STORE: http://itunes.com/app/bearonawire

For those wanting to get the word out. Here are some links to blog, twitter, AIM, tell someone on a subway, etc. We will have flyers too that you can print and post on bathroom walls, telephone polls, and anywhere in eyes view.
SHARE THE BEAR!

APP STORE: http://itunes.com/app/bearonawire
SITE: http://bearonawire.com
TWITTER: http://twitter.com/bearonawire
VIMEO: http://www.vimeo.com/6367707
YOUTUBE: http://www.youtube.com/dreamsocket

Press Release

Dreamsocket & TVM Studio are excited to announce they have just released Bear On A Wire.

URL: http://bearonawire.com/

Apple app store link: http://itunes.com/app/bearonawire

About the game:
Our green hero, Bearzo, has had it! No more performing for “THE MAN” day in and day out. What! Do you think he is some kind of dancing bear? NO… he is a high wire bear, and it’s time for him to make his great escape from the Big Top. He loves his fans and his work, but he just wants to be free and feel his scarf blow in the wind as he shreds wire with the most insane moves ever attempted … on a Moped… on top of high voltage power lines. Get ready to feel the power of the 49cc, two stroke, and single cylinder stallion!

As you tear off on the wire, try to balance Bearzo and keep him from fallingdown into the 1.21 gigawatts that alternate through the wires below him (Ah, the smell of burnt bear hair). While balancing on the wire, acquire crazy mad points by using the different stunt key combinations to generate some MOPED MAYHEM (ECO..ECo..eco) Bearzo’s stunts include no hands, half twist, full twist, bear buck, back roll, front roll, jump roll, grinder, spin roll, spin buck, spin buck grinder, coat tail, coat tail kick, and the next to impossible coat tail kick spin grinder. Combine these stunts with full flips, double flips… triple flips…? Now you are just being crazy! Collect coins and rack up even more points. I know…you never saw collectable coins coming. Don’t get caught hibernating b/c it’s about to get all GRIZZLY up in here!

Get pumped for BEAR ON A WIRE.

The problem

I am using the Chipmunk physics engine on PoorBear and very basic collision shapes for all objects to try and keep it as fast as possible. You can make very complex objects with Chipmunk, combining many circles and polygons, but I feel that a single convex poly will provide accurate enough collision for this particular game. So, PoorBear’s body and scooter are represented with seven verts which are depicted by the orange dots below:

Up until we decided to add tricks to the game these vertices were all that was needed to provide collision detection for PoorBear’s body and scooter. The only variation in the animation was the movement of his scarf which didn’t need any collision detection so the verts remained static. Since we want to be able to do some pretty crazy tricks, these verts are no longer sufficient because the trick animations aren’t close to the shape of these verts. For example, this is a frame from one of the tricks:

As you can see, not only is it a totally different shape but the image is a different size and the wheels and shocks of the scooter are also included. This particular animation has ten frames and each frame is different enough to warrant unique collision verts. We have around 15 different trick animations with as many as 40 frames each which is why it became unrealistic to plot the verts by hand.

I browsed the internet for advice on how to solve this problem, but being new to game development I wasn’t even sure what to search for. Someone mentioned to be that I could use a single color image to generate terrain when I was working on the level editor for PoorBear so I started thinking how I could implement something like that and apply it to this problem. The solution turned out to be simpler than I had imagined and has saved me a ton of time.

The solution

My solution was to open each frame in Photoshop, create a new blank layer, and draw a 1px black (could be any color) dot where I wanted each vert to be. Then simply hide the original layer and save the layer with the dots to a file. Then I wrote a little script with my scripting language of choice, Python, to grab each pixel and convert them to coordinates that I can use with the physics engine. I have since extended the script so that I can generate the verts for multiple frames and animations at once because all the animations for PoorBear are complied into 1024×1024 images to cut down on the number of textures being swapped. However, I will just go over the basic steps of generating verts for a single image.

Below is sample of the previous image with several points drawn to form a loose polygon for collision detection. The points are overlaid on the image so that it is obvious what they represent and the points are large for the sake of clarity. The red dots have to be 1px on the real thing.

Once the verts are pulled out of the image and converted to something the physics engine can understand, they will represent something like the following in the game:

The script

There is a great image handling module for Python called Python Imaging Library (PIL) which is required for this code to work.

First we need to open the image saved from photoshop and pull out the pixels that were drawn. This can be done with the following code:

def grab_points():
image = Image.open("/path/to/image/animation0000.png")
pixels = image.load()
width = image.size[0] # the size property is a tuple (width, height)
height = image.size[1]
points = []

for x in xrange(width):
for y in xrange(height):
if pixels[x, y][0] == 255: # could just as easily detect any color
# pixels[x, y] returns the tuple (R, G, B)
points.append([x,y])

This code opens the image and loads the pixel data into memory and steps through each pixel, adding the ones with a red channel value of 255 to the points list. We could have also used a list comprehension which most likely runs more efficiently but is considerably less readable. This is what it would look like:

def grab_points():
image = Image.open("/path/to/image/animation0000.png")
pixels = image.load()

points = [[x,y] for x in xrange(image.size[0) for y in xrange(image.size[1]) if pixels[x, y][0] == 0]

Now that we have the location of all the pixels we drew in Photoshop, we need to convert them to something the physics engine can understand. Getting the pixel data was very simple thanks to PIL and at this step these points could be used for any physics engine with the right translations. These next steps will be more and more specific to my situation (Chimpmunk physics and the iPhone) but can be adjusted to most any project.

Chipmunk expects the verts to be in clockwise order and to form a convex poly. Currently, the verts are ordered by their x value. Given the image below, we need the verts in the order ABCDE but they are in the order ABECD right now.

I developed a simple algorithm which arranges the verts in the correct order, it has four basic steps:

• 1. Iterate over all verts excluding the first and last
• 2. Remove the verts with a y value less that half the height of the image, saving them in a temporary list
• 3. Reverse the order of the temporary list
• 4. Append the temporary list onto the original list

This is the code that does that:

def sort_points(points):
length = len(points) - 1
temp = []

i = 1
while i < length:
y = points[i][1]
if y > HEIGHT / 2:
temp.append(points.pop(i))
length -= 1 # we are editing the list in place. since
# we popped a value, decrement the length
else: i += 1

temp.reverse()

[points.append(point) for point in temp]

At this point, we have pulled the pixel data out of the original image and sorted the points in an order that the physics engine will understand. Now we just need to translate the points to the coordinate system used by the physics engine. The pixels were stored linearly in the pixels list where the first pixel in the list represented the top left pixel of the image and the last represented the bottom right pixel. This can logically be thought of as a coordinate system with the origin in the top left and the positive y-axis growing downwards. Chipmunk uses the traditional coordinate system with the origin located in the center. We just need to loop back over every point and transform them to coordinates Chipmunk understands. This code will do that:

def transform_points(points):
for point in points:
x = point[0]
y = point[1]
point[0] = x - OFFSET_X if x > OFFSET_X else (OFFSET_X - x) * -1
point[1] = (y - OFFSET_Y) * -1 if y > OFFSET_Y else OFFSET_Y - y

Now we have the list in an order and format that Chipmunk can use. Being that PoorBear is running on the iPhone, I just format this data to resemble a multidimensional C array and copy/paste it over into the code for the game. There are better ways to get the data over but copy/pasting is good enough for now.

The full script is below, I just chained each function together for simplicity.

from PIL import Image

OFFSET_X = 75 # image width / 2
OFFSET_Y = 75 # image height / 2

def grab_points():
image = Image.open("/path/to/image/animation0000.png")
pixels = image.load()

points = [[x,y] for x in xrange(image.size[0]) for y in xrange(image.size[1]) if pixels[x, y][0] == 0]

sort_points(points)

def sort_points(points):
length = len(points) - 1
temp = []

i = 1
while i < length:
y = points[i][1]
if y > OFFSET_Y:
temp.append(points.pop(i))
length -= 1
else: i += 1

temp.reverse()

[points.append(point) for point in temp]

transform_points(points)

def transform_points(points):
for point in points:
x = point[0]
y = point[1]
point[0] = x - OFFSET_X if x > OFFSET_X else (OFFSET_X - x) * -1
point[1] = (y - OFFSET_Y) * -1 if y > OFFSET_Y else OFFSET_Y - y

# format the list if needed
file = open ('output.txt', 'w')
file.write (points)
file.close()

grab_points()

Help make Poor Happy!

As you can tell, Poor Bear’s life is starting to hype up, but we have him running in different directions. He is a little confused and we’d like your input. How? Well we’ve played with different goals for Poor from beat the buzzer to collect and score. What do you think would make Poor fun? Either of those? A combination? Or something else? We have tons of ideas, but would like to know what you think in terms of the fundamental game play. Please share your thoughts in the comments or with us directly!

“The idea behind project poor bear is to mesh a couple of my favorite ideas with the awesome game engine Dreamsocket came up with. First, I love the idea of making a monumental escape from work. I think anyone can relate to that. Here we have a bear who is good at what he does, loves to do his thing, but is stuck inside the unrelenting system (the big top) that sucks the fun out of his work. Sound like your life? The next idea I’ve incorporated is one I’ve been sitting on for a while. As a kid, I used to skate board. Trust me, I sucked… real bad. Even though I didn’t have any thrashing skillz, I could imagine the possibilities. I would always look up at the power lines and imagine ridding a skate board, or bike, or rocket boots on the power lines. Man, that would be so cool. I don’t think there could be a better escape route for our high wire bear. Of course we can’t just let our poor bear ride off into the sunset all golden parachute style. We have included a few challenges that should make for an interesting ride.

For the overall look, I wanted to make something that was just really fun to to interact with. I was initially going to make something all stylistic and out there, but it has been a while since I just made something tat felt cartoony. It’s almost a bad word these days. “CARTOONY.” Yeah, I feel bad even typing it. Well, I’m glad I did, because I think it really has a nice goofy look.”

Splash screen development

The development of the splash screen from a hand-drawn image to the (almost) completed image.

In-game assets

Potential objects you can expect to see in the game, from deadly barbed wire to not-so deadly squirrels.

Level one intro video

A sample intro/theme video we are using to defined the game. It shows Poor Bear making his death defying escape from the circus.

The presentation is slated for Thursday April 23 at 10:15.
You can find all the details here.

It should be quite interesting presenting at NAB, since the crowd is so different than a lot of the places I speak. It also marks my first attendance to the event, so I’d love to hear feedback from others that have attended in years past.

Plot

Trevor is working out the dynamics of POOR BEAR’s story line and it will evolve as we progress. Nothing is nailed in stone, but we have our basics. Our main character is a circus bear who rides bikes on tight ropes. Pretty hype already, huh? Who doesn’t love bears on bikes??? The game starts with our fearless character blasting out of a circus tent and landing on some power lines. He has some where he has to go, and he has to get there fast, so it is up to you to help him get there. A side scrolling bearrific race against time!

Current State

You can see from the video above, our development started by just getting basic mechanics working in the game along with a few art elements and menu screens. Some how the luck of the Irish hit, and we already have our fearless hero iPhone ready and controllable via the accelormeter and screen interaction. Tilting the phone to either side controls balance, touching the front of the phone speeds him up, and touching the back slows him down. Although some of the game elements are limited now, they along with the terrain are getting generated from a custom level editor we built in AIR. This gives us the ability to really map out and throw things in pretty rapidly. Expect good things

Future

Moving forward, there are many hours of work left at this point. We still need to settle on layouts for all the menus and screens, get art for them, add sound effects, add background music, and create levels for the game. Perhaps one of the most important tasks left is to implement a scoring system. We have not ironed out the details yet but are considering making the levels time-limited and scoring based on quickness of MR BEAR. If we go this route, things like power-ups via time bonuses and speed boosts come to mind. Finally but not least, our bear FLIPS, yes he FLIPS while jumping his bike! Obviously, we might have to take that into account too!

All that said, welcome to PROJECT POOR BEAR. Expect us to post our process and progress here, so you can follow along and add your 2 cents into the game. Help us shape it into something great. We want POOR BEAR to pull you into the bears shoes and have you craving to play!

Therefore, when looking for folks to work on projects or to join the team, I look for people that are:

• a) smarter than I am
• b) completely devoted
• c) care

It’s a decision that I don’t take lightly since I’m essentially asking someone to join a “family of friends”. That’s how I view work. It is part of your life, the people around you are part of your life, and you should surround yourself with those that bring out the best in you and themselves.

Chad Fuller

Last June, Mr. Chad Fuller sent me a note mentioning that he was moving to Atlanta. I knew Chad well, knew how smart he was, but also knew that he didn’t have any work experience. Point blank, experience is huge for us. Due to the positioning of Dreamsocket, we typically receive jobs I would refer to as high experience work. Thus, we can’t have people work on the projects who don’t know the technologies better than they know their own name. It is our position and what we’ve built the business on it. So Chad was in a way a gamble. Obviously there is risk with any gamble. You either win or lose. However, I took a pretty calculated gamble and came out ahead…. way ahead. If I were in Vegas, I would probably be the owner of the Wynn right now .

How did I win? Instead of throwing projects at Chad he would tear his hair out with, I decided to invest in him and the company. Chad’s first project was dreamsocket.com. If you haven’t looked at the site yet I highly advise that you do. Not out of self promotion, but to see what he accomplished. Before the project, Chad had never touched HTML or built a website. After the project he could boast a site that included a store front, live docs, bug tracker, and more all under one dynamic system. Needless to say, I’m more than impressed. Being able to own and shape it himself, Chad really was able to take value in his creation and learn a lot (at least I think he did ).

Investments

Since the site was an internal project, it was an investment. We invested in defining our image more concretely, creating a way to extend our business, and developing ole Chad. Personally, I know what its like to run in his shoes. Developers that care want to learn as much as they possibly can, to work on great things, and just enjoy what they do. It felt really good to give him a project that he could call his own, mold it, and learn from. That is really what being a business owner can do for you, it can help you help others.

As much as the business will let me, that is what I intend to do. Invest in the folks around me. If your folks have passion, let them run with it as much as you are able to afford. Your workers will grow in strength, which will in turn mean that you get an experience level you couldn’t get any other way. On that note, Chad got the IPhone bug and I’m letting him get all over it. It means diversification and it means he continues dealing with things he is really excited about. Wait and see what he’s got running .

Look for big things on Chad’s blog and our site