These applications were both developed with Codewarrior using PowerPlant as the framework, and as a result these are PowerPC apps. Mac OS X 10.7 (“Lion”) does not support PowerPC applications, and as a result these no longer work. Furthermore, there isn’t an easy way to simply just recompile these projects and make them run on Lion. Furthermore, even if they could be rebuilt fairly easily, they could really use a thorough rework to modernize their user interfaces.

So, as of now these products are officially unsupported. There’s a chance that one or both may be resurrected in the future as time permits, but I’m in no position to make an announcement to that effect at this time.

To those who purchased these products in the past, I thank you for your support.

In my initial development I was simply drawing into a UIView via its CGContext. Now I’m thinking about changing to drawing into CALayers. This gives me a few advantages. First, it lets me separate drawing a little bit more. I already have most of the drawing broken into separate methods in my view, but now I can set a layer for the score, and a layer for the objects (or even a layer per object). These aren’t too much of an advantage, but I think the biggest gain is that I can put a background image in a layer and then draw the rest of the items on top of it. I won’t need to redraw the background on the view for every frame of animation.

The second advantage is for some animations – I can just set them up and let them run. Take, for instance, an event like an explosion. I could create a few layers for some particles in the explosion, set them up on a path (maybe with some rotation), and then just let it run. I don’t have to add state tracking to animate these by hand with every frame.

I’ve only just started researching this, but I think this will work out nicely.

Part of my game play involves the user touching objects on the screen which can be fairly small.  In my light testing on my iPhone (along with some brief play testing done by my wife) it proved hard to hit within those objects.  I added some code to draw an ‘X’ where the last touch occurred in order to track this.  Generally it seemed that the both of us were hitting down and to the right of the target area.  As we are both right-handed, I would guess that this it because our aim is guided largely by the position of our fingertip while the touch area is back from that at the finger pad.

The inaccuracy is not a surprise, I suppose.  Most standard user interface elements have a reasonably large target area and are at least static positionally, so this generally isn’t a problem in typical applications. In the height of game play, however, you don’t want to require touches to be too accurate, or you at least want the touches to match the position that the user expect the touch to occur. Otherwise, the player will become frustrated and will hate your game!

So, my solution? One of my considerations in my game design was to put my objects in a grid, rather than placing them in arbitrary locations on the screen.  As I implement this, I will start with registering a click on an object when the user clicks on the grid cell that contains it.  As it looks so far, the ‘X’ I’m drawing for the last touch location appears to show touches in the intended grid cell.  That’s a good thing.  My one concern is that using the grid cell as a proxy for touching an object makes it too easy to touch small objects.  If that’s case, I’ll make touches require less accuracy by allowing a few pixels of slop outside the boundaries of the game object.

Has anybody else experience this in their game design? How did you solve it?

Second – I spent a bit of time writing down the concept that had been in my head and brainstorming other possibilities that may or may not make it into the game. What is written down still constitutes a fairly loose concept with no exact details. This is not a specification that could be handed off to an engineer to code. This is purely my ideas written down so I don’t forget them at the point that I start coding the product. In this particular instance, this amounts to 2 pages of stuff written down in my Moleskine (quad-ruled of course!). Once the game is released, I plan on releasing a scan of these notes on this blog to show you where I started and what I ended up with.

Just last week, I started coding the game. To begin, I decided to take an evolutionary approach to the implementation rather than drilling down into the details up front. I think this is the best approach given that I’ll be learning more about the iPhone platform  as I’m coding . I think this also encourages me to continuously refine the game on the fly.

So what have I been implementing so far?

Game loop: A major portion of any game is the game loop.  Essentially, this is the pulse of your game where you move objects, do collision detection, and then redraw the contents.  There are various ways to approach this, but I am currently using a NSTimer set to fire 10 times a second.  A NSTimer is not guaranteed to fire at exactly the interval I specify, but it’s close enough for now that the rest of my code is assuming the interval is constant.  If I get to a point where the frame rate becomes variable due to excessive load, then I’ll investigate other methods to make it more steady or I’ll take the actual framerate into account when calculating how to move the objects in the game.

Graphics: For now, I’m implementing the graphics using Core Graphics and just using simple drawing functions to draw into a CGContext. I have never written OpenGL code, so that would be a roadblock to me in my quest to develop the game play.

For starting with a 2D game, I think using really simple graphics to start out with is a good idea.  I want to get the gameplay going and then enhance the look over time.  With a 3D game, I’m not sure that this this approach will work quite as well (and it may not apply to all 2D games), but depending on your game you might be able to get away with drawing spheres and boxes and then enhancing the 3D models over time.

Input: I’m just using  -touchesEnded:withEvent: in my view to handle input.  I don’t think I’ll need to get more complicated than that.

So what are the next steps?  In the immediate future, I will continue refining the game play. That’s the most important thing. If the game isn’t fun and well-balanced, then it’s just not going to succeed.

After I’m happy with the game play, I will loop back to refining the graphics which are far too abstract for a final product at the moment. I generally appreciate form over function, but from the perspective of the users of a game they will want attractive graphics instead of colored blobs. I will eventually see whether I can spice them up a bit just using Core Graphics. If I can – great!  Otherwise, I may investigate whether pre-drawn sprite bitmaps are the way to go. Or, I may still have to learn how to use OpenGL in order to get the look and effects I’m looking for in order to give this a good visual polish.

At some point, I’ll have to address sound effects for the game as well. I’m not quite sure where that fits in, but I figure that I’ll start working on that while I refine the game play. I have much to learn about this area.

Hopefully some of you will find this useful. I plan on posting some more notes on my progress as my work progresses.

I bought it in 1995 for around $650 as I recall and used it heavily to print excerpts from manuals (e.g. The Powerplant Book), specs, and other documents. I even bought a stapler to staple larger documents of 50-100 pages.

When I updated my network to Ethernet, I picked up an unused Ethernet-to-Localtalk adapter from my day job at the time so that I could keep printing. The adapter never worked nicely with my 10/100 Base-T network, so I had to keep it on my old 10 Base-T hub.

Since then – and probably in large part to the availability of information on the internet – I haven’t printed as many large documents. Even so, documents have become more graphics intensive – a problem for the old beast. I did upgrade the RAM at one point (from 2MB to 6MB) just so the printer wouldn’t choke on bigger documents.

In any case, I bought a Lexmark E360dn Monochrome Laser Printer, which is much faster, prints double-sided and cost much less than my old LaserWriter did originally.

As one last call to duty, I wanted to have the LaserWriter print out its test page. The “print test page at power up” feature had been turned off, and there is no way to turn it back on in Mac OS X. I, unfortunately, do not have a system with Mac OS 9 on it anymore so there was no way to turn it back on. After much digging, I found an Apple Developer Note which included details of how to print the sample page. So I embedded the following in a “.ps” file and printed it from my Mac.

%!PS
/SamplePages /ProcSet findresource /StartPage get cvx exec

Click here to see a scan of the last test page I printed (278KB, opens in new window). Almost 10K pages printed!

Now I’ll take it off to Free Geek and perhaps somebody will buy it, or it will just – *sniff* – get recycled.

Farewell, LaserWriter!

For those of you who are about to enroll yourselves, below is a summary of our experience.  For comparison, you can also read some other enrollment stories here and here.  For us, the whole process took almost 5 weeks, though your mileage may vary.

1. We started our enrollment on April 26, 2009 as a company under the standard program.   We received an email confirmation from Apple stating that they were processing our application.
2. On May 11th, we received an email requesting information to confirm our company’s identity.  As requested, we faxed (yes…faxed) our business documents.
3. On May 18th, we received an email stating that Apple was waiting for information and that we should send it, or contact Apple if we had already sent it.  Since we had already sent the information, I sent an email to Apple to figure out was going on.
4. We received a response from Apple on May 23rd, confirming that our company information had been received and that our enrollment was being processed.
5. I received a phone message from Apple late on May 28th requesting that we contact them.  I called them on May 29th.  They just wanted to confirm our mailing address and contact phone number.  As a result, I was told I’d get an email pointing me to the license agreement I would need to agree to.
6. I read the license agreement on May 30th, agreed to it, and was then able to purchase membership in the iPhone Developer Program ($99).  After purchase, I received an email with my activation code within a few hours, after which I activated my account.

Now, we need to finish up our application and get set up to sell it in the App Store.

I have no predisposed plan for blogging in terms of frequency of posts.  However, I do intend to provide some business and software development insights from a Mac and iPhone developer whenever I have topics to discuss.

So, welcome!  And stay tuned!