Archive

Posts Tagged ‘iPhone’

There’s an app for that

June 6th, 2009 beardo No comments

So let’s say you want a fun little game to learn to read music? There’s an app for that.

That’s right, uSightRead is live on the App store. It was submitted late Tuesday, and approved for sale on the following Saturday. That makes about four days from submission to approval. Not too shabby, although it is a simple game which probably aided in the quick review.

You can buy it here (opens iTunes). I’m so excited I may have just wet myself.

The cost of making an iPhone App

June 5th, 2009 beardo No comments

While I’m playing the waiting game for my first application to be approved for the App Store, I thought I’d talk about what it costs to make an iPhone application. There’s a question on Stack Overflow that talks about it here. There’s cost dimensions to consider here, monetary cost and time cost. First the monetary costs.

Since I didn’t have a Mac, I had to purchase one. The iPhone SDK requires an Intel based Mac with OS X 10.5 installed (at the time of writing this). I looked around Craigslist and other such sites, but with the way Mac’s retain their value, I decided to just buy new. Fortuntely I got an educational discount thanks to my wife. The other major monetary cost is the $99 to join the iPhone Developer Program. Added with a few other things, the total cost is:

  • $1350 (Unibody MacBook, with tax)
  • $99 (iPhone Developer Program
  • $10 (usightread.com domain registration)

For a grand total of $1459. In my opinion, this is an extremely low number for starting a business. If you were starting from scratch in any other business, I don’t see how you could do it for any cheaper. I do get a break because I’m already paying for shared hosting, but that is only $10/month.

Secondly the time cost. This is highly variable depending on the skill of the individual making the application. I started with at least some background in Objective-C, and about 15 years of development experience which I think is a little above average for a starting iPhone developer. I would estimate the total time for creating uSightRead was about 50 hours. That includes the time to learn the Cocos2d-iPhone framework, create the artwork, and learn the nuances of iPhone development. I’d say that I spent at least 15 hours of that creating the artwork (Dammit Jim, I’m a developer not an artist). It doesn’t include the time to work through the my first iPhone sample app from Apple. If you figure about $40/hour for developer time, the monetary value of my time was $2,000.

My initial goal of this project was to break even on the monetary cost. With uSightRead slated to hit the App Store at $1.99 it seems reasonable. After Apple’s cut, my take would be $1.40 except that I still have to pay taxes on that. If I take 0.40 out for taxes, I’ll get approximately $1.00 per app. This makes the math easy and I’ll have to sell 1459 copies in order to cover my cost. Even if you take my time into accunt it’s only 3459 to break even. Only time will tell if this is a profit making venture.

One real time saver (and headache saver)  of using the App Store is that it totally eliminates the need to find a distribution channel or deal with payment processing. In other business, you’d have to setup a merchant account, and either handle the payment processing or pay someone to do that. Companies charge anywhere between 1% and 5% for payment processing services (usually on top of a $0.25-$0.75 per transaction fee). Of course Apple takes 30% so you may feel like your getting ripped off, but consider how long it would take you to get a piece of software into say, Best Buy. What percentage do you think they’d take if you could even get it in the store? I think 30% pretty fair for getting your app available to millions of potential customers.

uSightRead submitted to the App Store

June 3rd, 2009 beardo No comments

Well, after about a month of hard after-hours work, version 1.0 of uSightRead has been submitted to the iTunes App Store. Hooray!

Now it’s just a waiting game for it to be approved. I’m really happy with the way it came out, and suprised at how easy it was to develop for the iPhone. There were some features that I cut out, but it just gives me a reason to keep going and to have additional releases. I already have plans for two more releases, but for now I’m going to take a little breather.

One other thing that I was having an issue with is setting up the bank information in App Store so that I could get paid. The issue is that they require a bank that has a SWIFT code. The SWIFT system is a proprietary international banking system that allows for money to be wire transfered across country borders. Most small banks (like the one I use) aren’t on the SWIFT system. I ended up opening an account specifically for the app store at Wells Fargo. Just a heads up for other budding iPhone developers out there.

Let there be multi-touch and animation

May 18th, 2009 beardo No comments

Saturday was very productive for me. I re-did the input layer to support multi-touch. Now you can play more than one note at a time on the virtual piano portion of the game. I’m not sure it’s 100% right, and there seems to be occasions where the key gets “stuck” in the down position. I’ll have to debug that before release. I also added labels to the keys for those that don’t know the notes on a piano. I actually implemented the labels with an AtlasSpriteManager and AtlasSprites. The way it works is that you compound multiple sprites in a single texture (one png file for me), and set the sprites to be different regions of the shared texture. This allows it to load the texture once, draw all the sprites, and then move on to the next texture.

The static labels aren’t where AtlasSprites really shine, the best use of them is for animations. I added a pulsing gate that “kills” the notes that make it past the player. I started with a png file containing all the animation frames:
killer

Here’s the code to make the it pulsate:

Texture2D *killerTexture =
  [[TextureMgr sharedTextureMgr] addImage:@"killer.png"];
killerManager =
  [[AtlasSpriteManager alloc] initWithTexture:killerTexture capacity:9];
AtlasSprite *ks =
  [killerManager createSpriteWithRect:CGRectMake(0, 0, 32, 134)];
[ks setPosition:ccp(wallLocation, STAFFSPACING * 2)];
AtlasAnimation *animation =
  [AtlasAnimation animationWithName:@"pulse" delay:0.1f];
for(int i = 0; i < 9;i++)
{
  [animation addFrameWithRect: CGRectMake(i*32.0, 0.0, 32, 134)];
}
for (int i = 8; i > 0; i--)
{
  [animation addFrameWithRect: CGRectMake(i*32.0, 0.0, 32, 134)];
}

[killerManager addChild:ks];
[self addChild:killerManager z:5];
id action =
  [RepeatForever actionWithAction:
    [Animate actionWithAnimation: animation]];

[ks runAction:action];

Basically, you load the texture, create a atlas sprite manager with the texture, create a sprite in that manager, and then build an animation based on the different portions of the texture. One thing to note is that creating a sprite with the AtlasSpriteManager’s createSpriteWithRect message does not add it to the manager. You still need to do that yourself. Also note that you don’t add the AtlasSprite to the layer/scene, you only add the AtlasSpriteManager which handles drawing all of the child sprites. The animation is pretty straight forward, just add the individual frames, set the delay, and you’re off. In this example I add the frames going forward, and then going backwards.

I did start out with only five frames, but it was choppy on the actual device, so I expanded it to nine frames and it’s smooth as butter.

Getting touched

May 13th, 2009 beardo 2 comments

I had an opportunity last night to work on the input component of uSightRead. The main part of the game is a single scene, with layers for the individual parts. There is a main game display layer and an input layer. The input layer consists of keys from a piano that respond to touches. Initially I had thought that each sprite would be able to handle its own touches and then simply pass a message up. This is not how it works. With cocos2d-iphone only a layer can receive touches. I discovered this in a answer to this question on Stack Overflow, which the answer goes into how to do bounds checking.

If you note the highest rated answer shows how to compute where the point touched within your layer, and then determine if the touch was inside a label. This is doing a basic rectangle point intersection. The example code uses a compound if statement, but I simply built a rectangle based on my sprite, and used the CGRectContainsPoint function found. You can read about the built-in geometry functions here. Here’s what my code looks like:

CGRect spriteRect =
  CGRectMake(self.position.x - spriteWidth / 2,
                   self.position.y - spriteHeight / 2,
                   spriteWidth,
                   spriteHeight);

if(CGRectContainsPoint(spriteRect, cLoc)
{
  NSLog(@"Sprite was touched");
  return kEventHandled;
}
else
{
  return kEventIgnored;
}

The one thing to note is the subtraction of half the width and height to compute the postion. This is because the position is actually the center of the Sprite.

Unfortunately, I’m not making a “crap app”

May 12th, 2009 beardo No comments

According to this story at TUAW so called “crap apps” tend to sell really well. Apparently people are more than willing to spend $0.99 for an app that makes fart sounds or can impress their friends for five minutes. My friend and I do have one idea for one of these less regarded apps, but we’ll probably just do it in my spare time and focus on making uSightRead a full featured app. 

I guess this means that I’m not going to “strike it rich” making iPhone apps, but who cares, at least I’m having fun developing it and hopefully someone out there will find it useful.

Tags: , ,

Actual progress

May 11th, 2009 beardo No comments

I got a decent amount of time to work on the iPhone version of uSightRead this weekend. I’ve made a deal with the family that I can work on it uninterrupted (unless the baby wakes up) after 9:00. So this Friday and Saturday I stayed up till about midnight working. I was rewarded with a fully functional game display with notes smoothly scrolling by.

Everything worked great on the simulator, so I decided to see how it ran on my iPhone. It was then I realized that yes, I am developing for a mobile device and some things need to be optimized. I was initially storing each all of the notes in an array, and having the sprites already in the scene. This worked okay with about 100 notes, but after that it started having intermitent pauses and my target was about 2000 notes queued up.  I changed the logic to only add the notes to the scene when it came close to being displayed. This works much better. I’m still looping through all notes and updating their location each frame, and so there some more optimizations that can be done.

Aside from this optimization, I’m ready to move on to the input area.

Progress, and then starting over

May 8th, 2009 beardo No comments

I had been progressing just fine with the app, it had the notes being draw correctly, a staff with choice of clef symbol, everything anyone could want in a music theory app. Then I got the inkling that I was “doing it wrong”. I based the application on the UIKit model for the iPhone. I knew that OpenGL ES existed, and that it was probably better for making games, but I figures I’d get enough performance the way I was doing it. As I got into coding the game mechanics, I realized that I was making a basic game engine, and really, I’d rather have use one that already exists.

After some research I decided on Cocos2D-iPhone. So, last night I mostly scrapped the existing app and started over. A few hours later I had gotten a basic menu, and some test sprites drawing on the screen. The good news is that the rest of the game should be much easier with someone else’s framework and it should be fairly high performance as it uses OpenGL ES. The bad news is, well, I should have thought of it sooner and I’d be much farther along. Ah well, live and learn.

First Post!

May 6th, 2009 beardo 2 comments

This is the obligatory first post for the blog. This blog is to chronicle the development of an iPhone app that I am making to help people learn some music theory.

Where are we now? Well, I’ve purchased the requisite Mac, installed the SDK, followed the sample app tutorial and started work on the app. I have most of the images needed, and am working on getting the game mechanics coded up.

About me: I’m just your typical software developer. I’ve been doing it for years professionally, and many more years as a hobby. Once upon a time I wrote a Jabber client for Mac OS X called JabberFoX. Not updated anymore, but I still know most of the Objective-C that I learned back then.

Tags: ,