2 December 2008

Numeric Keypads

I'm starting work on another app, but I need a means of entering currency values (Let the user enter $2.00, for example). 

There's three numeric keypads available on the iPhone. Let's have a look and see how well they suit out needs.

First up is the standard iPhone keypad. Looks nice, large keys, but as far as I'm aware, this isn't available to me as a developer. It's also got the letters under the numbers, which is not too much of a problem, but is extra noise, has extra symbols we don't need (*, #, +) and has no means of entering a decimal.









Second up, we have the second page of the standard text editing keypad. I've discounted this almost immediately as the numbers are too small and there's too many extra characters we don't need.

Next.



Finally something that looks promising. Except it doesn't when we look closer. Sure it has nice big buttons and it's available for use, but we still have no decimal. There's also no clear way to signal when you're done entering the value.

So, I thought it would be a fun exercise to build my own.







First Week's Sales

For anyone who's interested; Resistance sold 37 copies this week across 9 countries and received a five star review on the US store.

26 November 2008

I'm Stoked

Just checked my first days sales - I've sold four copies! Made my day :)
With the current exchange rate, that's a profit of about AU$8.40 (US$1.40 [AU$2.154] * 3 +  €0.97 [AU$1.95]).

Thanks to those customers and hope you like the app. 

Localisation (Localization)

Hooray! My app is up on iTunes for sale. Looks good, but I see three problems.

The first seems to stem from my decision to select Australian English as the main language. When I view the app in the US store, it contains no description at all. Fixed by cutting/pasting the description to all English speaking locales, and then removing a lot of 'u's from colour.

Problem two: below the description are two links; David Phillips Website and Resistance is Futile Support. I didn't know I had a website. Oh, I don't. The link leads to localhost. oops. Fixed (I think) be removing the default http:// from this field.

Problem three: The requirements section lists iPhone 2.1 Software Update as required, but this will run on 2.0. I assume 2.1 is listed as this is the target I used to build the binary I submitted. Not going to worry about this one.

25 November 2008

Approved

Just got an email from Apple. The app has been approved and is now ready for sale.

From what I've read elsewhere, it takes about 24 hours for an app to make its way from here into the actual iTunes Store.

22 November 2008

Waiting

Managed to get everything off to Apple this morning; the app is now in their hands with a status of 'In Review'. Now I wait...

Being an Australian resident, I also need to supply proof of being registered for GST (Goods and Services Tax). 

There are five similar apps on the AppStore currently, 2 free, 2 for AU$1.19 and 1 for AU$3.99. I am pricing mine at the tier 2 price of AU$2.49 (US$1.99). 

21 November 2008

Preparing For the App Store


The app is complete.

Now it's time to get it off to Apple for review. All I need to do is write a few paragraphs about it and then upload it to them, right?

No.

First I have to do a Distribution build, which involves signing the app with a different certificate, setting up a third build profile and then getting it all to work.  This took me all evening and more; some bits took a lot of fiddling to get working, and then the build would succeed, but inspection of the log showed it wasn't being signed with the new certificate. In the end, however, it got it all working.

Now all I need to do is upload it.

Um... no.

Now I need to supply a 512 x 512 icon (what! that's not an icon, that's a poster), and a url for a support website for the app.  I don't have Photoshop, but I do have a trial version of Acorn. I try a few ideas, but they all look embarrassingly bad. I give up and head to bed.

As for the website... I'm not game to spend much money as I don't think there's a huge market for this type of app. I think I'll be please to sell a dozen copies, not because it's bad (it's not), but because it doesn't have the same sexiness as a game or some of the other types of apps.
I think I'll see if I can get away with setting up another blog and using that for support.

Again, my friend Matt has stepped in and offered to try his hand at designing a poster. His idea was something like a Borg ship shaped like a resistor. That's his initial idea at the top of this post. I like it.

So, all I need now before I can submit this app is a poster sized icon, and a support site. And a price.

20 November 2008

Resistance is Useless

 I've been working may way through the UIKit components learning how they work and how to use them. Got a bit carried away with the UIPickerView and ended up building an entire app.

There's two tricks I've developed. The first is a simple means of getting the picker dials to wrap (by default the work like a list - once you reace the end you then have to scroll all the way back up to the beginning again). A number of the native apps, such as the alarm (but interestingly, not the timer) feature wrapping dials, and I thought it seemed like a good idea. The second trick was highlighting the selected row of each dial to make it more prominent and the overall look less like a kids toy.

Second one first. I have a class ResistorBand which all four band types inherit. The band objects are called upon by the controller (which acts as a delegate for the UIPickerView) to supply the views for their corresponding dial. I've subclassed UIView and overwritten  - (void)drawRect:(CGRect)rect which actually paints each square. If the view is not the selected view for that row, it has a white rectangle with a 0.6 alpha drawn over it. This has the effect of slightly muting the non-selected colours.

Getting the dials to wrap up being simple in the end, thanks to a suggestion from a friend of mine [thanks Matt]. 
To start, we need to tell the picker there's three times the number of rows than there really are:

- (NSInteger)pickerView:(UIPickerView *)pickerView
numberOfRowsInComponent:(NSInteger)component {
    return [[self bandForIndex:component] viewCount]* 3;
}

Next, when the picker asks for a particular view, we need to map the row it's asking for, with the actual views, ie just row mod viewCount:

return [views objectAtIndex:position % [self viewCount]];

Finally, when the user selects a row, as well as our normal logic, we need to make sure the picker row selected is always in the range [band viewCount] and [band viewCount]*2-1 (inclusive). This means that whenever the picker draws the selectd view, there will always be others above and below it (we'll never reach the end of the list):

- (void)pickerView:(UIPickerView *)pickerView
      didSelectRow:(NSInteger)row
       inComponent:(NSInteger)component {

    ResistorBand *band= [self bandForIndex:component];
    [band selectPosition:row % [band viewCount]];

    NSInteger updatedRow= row;

    if (row< [band viewCount]) {
        updatedRow= row+ [band viewCount];
    } else if (row>= 2* [band viewCount]) {
        updatedRow= row- [band viewCount];
    }

    [pickerView selectRow:updatedRow
               inComponnt:component
                 animated:NO];

    [self updateDisplay];
}

Hope this makes sense.

I'm Back

Time to resurrect this blog again, me thinks.

Since I last posted, we've moved 4,000km to the other side of Australia, the NDA has been lifted and I'm now looking for work.

I've put my game on hold to try and get a better grasp of Objective-C, UIKit and the way iPhone development works. I've written another app that's complete and ready to go to apple, it's just waiting for me to create a support webpage and an icon.

3 August 2008

Discovering things everyone else already knows

Over the weekend I've changed all coordinates to floating point numbers (from integers) and changed the method used to call renderScene. 

Previously I created a timer which fired every 1/60 second and called this method. Now I have a small loop which basically calls renderScene, processes any messages and repeats. This means the screen is redrawn as often as we can, giving the smoothest movement (and the shortest battery life?) possible. 

Because we no longer know the frequency of the renderScene calls, we need to change the way we specify movement. Previously, each object had its movement given as a change in pixels per frame; eg x will increase by 4 pixels each frame. Now movement is given as pixels per second, with the movement for this frame calculates as deltaTime (time between last frame and this one, in seconds) times this value.

I've had a number of requests to get some bullets on the screen. People want to see the ship fire something when you tap the screen, but there's a few things I would like to sort out first. Number one is a better grasp of Objective C objects and memory management - I have at least one memory leak, but not the experience yet to track it down. I'm going to give this a break for a bit and write some simple practice code to hone my skills a bit.

28 July 2008

Framerate and rendering time

I've noticed when testing the new code, that the display would pause every now and then for a noticeable delay. After a bit of experimentation, it looked like the pause was related to crossing texture boundaries.

I have the framerate set at 60Hz, but was not sure how that hardware was actually taking to render a frame; a task that must complete in less that 1/60 second (0.0167s). Added a text overlay that shows time to render the current frame, and the maximum time in the last 3 seconds. From the screenshot here we can see a render time of less than 1ms (very good), but a max of over half a second (very bad).

I'm now quite certain the pause is related to loading textures and maybe I need to reduce their size. At least now I have a means of objectively measuring the benefits of any changes.

The other change I've made is to the code that locates the ship vertically on the screen. Previously the ship was always centred, except when approaching the limits when the background would remain stationary and the ship would move. I found the sudden transition of movement disconcerting and have now made the vertical position of the ship on the screen proportional to its position in the world. This seems much better and still allows the ship to reach both the top and bottom of the screen.

[UPDATE 28 July - Further testing has narrowed the cause of the delay down to the two lines of code that draw the background textures. I've reduced their size by a quarter to 512x512 which has eliminated the delay. Max render time is now about 5ms.]

25 July 2008

It's late again, I'm still tired, but now it works


Sorted all the bugs I could see, and now we have a fully wrapped (scrolls forever) world made from six 1024 x 1024 tiles. The ship now moves toward the top and bottom of the screen when you reach the limits, instead of being stuck in the centre.

Please note this is only temporary artwork. The background is another space image I liked and have borrowed for a bit. I'll create my own artwork in a few weeks.

24 July 2008

It's late, I'm tired and it doesn't work


Spent the evening tidying up my code (in the refactoring sense) and implementing a tiled, wrapping background.

Everything in the game is stored with World coordinates, relative to an arbitrary point in the world (that just so happens to be the bottom left of the first background tile). The ship is always centred horizontally, and normally centred vertically except when near the top or bottom of the world.

From the ship position, I can calculate bounds for the view (the area of the world to be drawn on the screen), and from this screen coordinates for the objects we need to draw, and an xy offset for the tiles. I can also calculate which tile to draw, and if needed draw a second.

I've stopped for the night (which goes against the grain, but I'm already over tired), with bits not working. I'm having resource issues with some image files I've renamed not being updated on the iPod (looks like a case sensitivity bug) and errors in my maths that cause a few amusing visual errors before the game crashes.

From the picture of the simulator, you can see not everything is rosy. What you can't see is that the ship is flying backwards, the tiles are in the incorrect order, and once a join reaches half screen, the right most tile stops dead while the left one keeps moving until it covers it. Fun for the whole family.

More tomorrow.

21 July 2008

First screenshot

Friday night I got some time to get started. I was able to get a background and a spaceship sprite (which I borrowed from the Internet) on the screen. This is only placeholder artwork to let me concentrate on the game mechanics.

Hooked up the accelerometer and, after getting the axes (apparently the plural of axis) correct I was able to move the ship by tilting the iPod. Screenshot above. The background is only small (1000 x 600 pixels) and doesn't wrap, so flying area is limited.

I've implemented variable speed by multiplying the accelerometer output by a constant (slightly different value for Y than X, so you speed up faster when travelling horizontally), and capping it at 4 pixels/frame. I've also had to implement a 'dead' area around 0ยบ (flat) to stop the ship flicking left and right from the slight movement you get when holding the iPod in your hand.

Must say, it scrolls very smoothly. I've got the framerate fixed at 60/second

The code at the moment is a bit rough, and the background moves relative to the ship - fine for a demo, but a rubbish way of managing multiple objects. This method will be gone shortly and all objects will have a position relative to some fixed point.

Next task is to create a means of tiling backgrounds and enabling it to wrap horizontally.

Setting everything up

Received notification from Apple that they were ready for my money on 12 July, but was unable to pay due to Apple's website being completely overwhelmed. Ended up paying on the 14th.

Not sure what I can say here (NDA and all), except that setup was straightforward and worked first time. Very nice to see one of the sample apps running on my iPod instead of in the simulator.

I suspect, but I don't know, that everyone else waiting to join the dev programme, but not part of the chosen 4000, has received this notification as well.

Welcome

Note: A large amount of iPhone development is still under NDA, so I'll be concentrating on the game itself, not the technology or code. 

My aim is to create an old style side-scrolling shooter for my iPod touch. I have a number of pencil drawings and ideas from years ago, but I'm not sure how this will transfer to the unique interface of the iPhone though.

I'll be working on this evenings, possibly only a few hours a week.

Here's the plan:
1. Create a cool game I like
2. ...
3. Profit!