However, I decided – largely as a matter of taste – that I’d rather figure out the sheet’s “parent” window programmatically in the didEndSelector when the first sheet is dismissed. That way I don’t need to store the parent window anywhere in my controller.

To do so, you can walk the window list and ask each window for its attachedSheet, comparing against the sheet window that is being dismissed. I’ve wrapped this in a category on NSWindow, shown below.

/*
    NSWindow+BSSheetParent.h
 */
#import <Cocoa/Cocoa.h>

@interface NSWindow (BSSheetParent)
- (NSWindow*) sheetParent: (NSWindow*) sheetWindow;
@end

/*
    NSWindow+BSSheetParent.m
 */
#import "NSWindow+SheetParent.h"

@implementation NSWindow (BSSheetParent)
- (NSWindow*) sheetParent
{
    NSWindow * sheetParent = nil;

    if(self.isSheet)
    {
        NSArray * allWindows = [NSApp windows];
        for(NSWindow * aWindow in allWindows)
        {
            if(aWindow == self)
                continue;

            if(aWindow.attachedSheet == self)
            {
                sheetParent = aWindow;
                break;
            }
        }
    }

    return sheetParent;
}
@end

Lines of note:

• Line 20 - If the argument window isn’t a sheet, then don’t bother searching. Its sheet parent will be nil
• Line 21 – get all of the windows from the app controller
• Line 22 – iterate through all the windows
• Line 25 – if we find the argument window, just skip it. It can’t be the sheet parent of itself
• Line 28 – If the current window’s attached sheet is the argument window, then we’ve found the sheet’s parent so we’re done

Here’s how you might use it:

/*
    MyController.m
 */
@implementation MyController
- (void) runMySheetAsModalForWindow: (NSWindow*) parentWindow
{
    [NSApp beginSheet: self.window
       modalForWindow: aWindow
        modalDelegate: self
       didEndSelector: @selector(sheetDidEnd:returnCode:contextInfo:)
          contextInfo: nil];
}

- (void)sheetDidEnd: (NSWindow*)sheet
         returnCode: (NSInteger)returnCode
        contextInfo: (void *)contextInfo
{
    BOOL needsToShowAlert = YES;  // figure out whether to warn the user

    if(needsToShowAlert)
    {
        NSWindow * sheetParent = [sheet sheetParent];
        NSAssert(sheetParent != nil, @"Sheet apparently isn't hosted by another window");

        [sheet orderOut: self];

        // chain sheet alert...
        NSBeginAlertSheet(@"Alert Title",
                          nil,            // default
                          @"Cancel",
                          nil,
                          sheetParent,
                          self,
                          @selector(warningAlertDidEnd:returnCode:contextInfo:),
                          NULL,
                          NULL,
                          @"Warning - do you really want to delete all your data?");
    }
}

/*...*/
@end

Here’s what this does:

• Line 5 – This is the entry point for running my sheet. It would be called from another window controller with the intent of having attaching the sheet to its window. If I were going to cache the sheet’s host window, this method is where I’d store it in an instance variable.
• Line 7 – Run the sheet. self.window is in an instance variable set up when the controller is initialized by the Nib (not shown)
• Line 14 – This is what is called when the sheet is dismissed. Code to dismiss the sheet is not shown for brevity (use [NSApp endSheet: returnCode])
• Line 18 – You’d normally want to do something here to figure out whether to show another sheet (like a warning), like check the return code or check some values in your sheet controls.
• Line 22 – Figure out the sheet’s host window, and assert if it isn’t found (it should be!). This uses the category shown above to do the heavy lifting.
• Line 25 – Get rid of the current sheet
• Line 28 – Now show another sheet from the same originating window.

Pretty straightforward, but also pretty useful in this circumstance.

Enjoy!

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.