Upcoming: Sparrow 0.8

It’s been a while since the first official Sparrow version came out, and many of you are eagerly waiting for the next version. Heck, the features page says that audio support will be added in the next few weeks — since months!

Guys, we are really sorry for the delay. We were busy at many different sites at once, and it showed. Some of you might have seen the update of PenguFlip, which included an online highscore system and a cross-promotion feature. Furthermore, we are working on the next Sparrow-powered game: “Twins”. And that’s just the tip of the iceberg …

But, finally, we are putting the finishing touches on the next release. The sound engine is finished and supports many different sound formats, without you having to care. The promised movie class works similar to what I showed in the last blog post, but with a few nice additions. There are new transition types that look really cool. And lots of bug fixes and improvements were applied behind the scenes. The feedback you provided us with in the forum and via mail is invaluable for us — thanks a lot for your support!

Expect Sparrow 0.8 within the next days. As soon as all our tests are finished and everything works as flawless as we want it to, we will upload it and inform you right at this place :-)

3 Comments

A simple Movie Class

Update: Since version 0.8, Sparrow contains a movie clip class, so you don’t need to create one yourself, as it is shown in this tutorial. However, reading this post is worthwhile nevertheless, because you can use this technique for your custom classes, too.

One thing that many Flash developers will miss in Sparrow is the MovieClip class. In Flash, you normally use the Flash authoring tool to create animations (like the walk cycle of your main character), and then display and manipulate these movie clips in the game.

In Sparrow, you have to use textures to create animations. If you want, you can still create your movie clips in Flash, or in any other animation tool you like. To display these animations in Sparrow, you need to export each frame of your movie as an image. I recommend that you add all your frames to a texture atlas — or several texture atlases, if necessary.

The next Sparrow release will most probably contain a class called “SimpleMovie”, which makes it easy to display those animations. But as such a class is really easy to create in Sparrow, I think it might be interesting to see how you could create it yourself. That’s what this post is all about.

Overview of “SimpleMovie”

The idea is simple. The class will be a subclass of “SPSprite” and will contain one “SPImage” object. It will also contain all “SPTexture” instances that are part of the animation. When the animation is running, the “SPImage” will change its texture at a specified interval.

Let’s first see how we will use the class:

SPTextureAtlas *atlas = [SPTextureAtlas
    atlasWithContentsOfFile:@"atlas.xml"];        

mMovie = [[SimpleMovie alloc] initWithFps:5];
[mMovie addFrame:[atlas textureByName:@"frame_0"]];
[mMovie addFrame:[atlas textureByName:@"frame_1"]];
[mMovie addFrame:[atlas textureByName:@"frame_2"]];

[self addChild:mMovie];
[myJuggler addObject:mMovie];

[mMovie release];

I think that should be quite self explanatory. The atlas contains the frames for the animation, and all relevant frames are added to the movie object. As you can see, we also add the movie object to a juggler — just like you do with tweens. As soon as the movie clip is added to the juggler, it will execute the animation.

The implementation

Now to the implementation. Here is the header of our class:

@interface SimpleMovie : SPSprite <SPAnimatable>
{
    SPImage *mFrameDisplay;
    NSMutableArray *mFrames;
    float mFrameDuration;
    double mElapsedTime;
}

- (id)initWithFps:(float)fps;
- (void)addFrame:(SPTexture *)texture;

@property (nonatomic, readonly) int numFrames;
@property (nonatomic, readonly) double duration;

@end

As you can see, SimpleMovie implements the “SPAnimatable” protocol. This is required when we want to add it to a juggler. “mFrameDisplay” is the image that will always display each texture that is active at a given moment. I think all other members and methods should speak for themselves.

Thus, we can continue to the implementation file:

// private interface
@interface SimpleMovie ()
- (void)setActiveFrame:(SPTexture *)texture;
@end

// class implementation
@implementation SimpleMovie

- (id)initWithFps:(float)fps
{
    if (self = [super init])
    {
        mFrameDuration = 1.0f / fps;
        mFrames = [[NSMutableArray alloc] init];
    }
    return self;
}

- (void)addFrame:(SPTexture *)texture
{
    [mFrames addObject:texture];

    if (!mFrameDisplay)
    {
        mFrameDisplay = [[SPImage alloc] initWithTexture:texture];
        [self addChild:mFrameDisplay];
        [mFrameDisplay release];
        [self setActiveFrame:texture];
    }
}

- (void)setActiveFrame:(SPTexture *)texture
{
    mFrameDisplay.texture = texture;
    mFrameDisplay.width = texture.width;
    mFrameDisplay.height = texture.height;
    mFrameDisplay.x = -texture.width/2.0f;
    mFrameDisplay.y = -texture.height/2.0f;
}

- (void)advanceTime:(double)seconds
{
    mElapsedTime += seconds;
    int frameID = (int)(mElapsedTime / mFrameDuration) %
                  self.numFrames;

    SPTexture *texture = [mFrames objectAtIndex:frameID];
    if (texture != mFrameDisplay.texture)
        [self setActiveFrame:texture];
}

- (BOOL)isComplete
{
    return NO;
}

- (int)numFrames
{
    return mFrames.count;
}

- (double)duration
{
    return self.numFrames * mFrameDuration;
}

- (void)dealloc
{
    [mFrames release];
    [super dealloc];
}

@end

The part right at the beginning is a private interface. If you haven’t seen this before: that’s the Objective C way of marking methods as private. A user of the class will not see the methods that are declared here.

The “addFrame”-method just adds the texture to our frame array, and it creates the frame display image if that hasn’t been done before.

The interesting part happens in “advanceTime”. This method is part of the “SPAnimatable”-protocol, and will be called by the juggler in every frame. Here, we find out which frame needs to be displayed at the current moment. The correct frame (texture) is then displayed by the “mFrameDisplay” object. (In this implementation, I center the image horizontally and vertically, but if all your frame textures have the same size, you can omit that step.)

The “isComplete” method is the other method that is required by the “SPAnimatable”-protocol. As soon as this method returns “YES”, the juggler will throw that object out, and “advanceTime” will not be called any longer. Since we want our movie to loop forever, we just return “NO” here.

Conclusion

That’s all there is to it! As you can see, thanks to the “SPAnimatable”-protocol and Sparrow’s “Juggler”, creating the “SimpleMovie” class is really … simple!

If you understand the steps that are done in this class, you can extend it as you like. You could e.g. add a “pause” method or define if and how the animation should loop.

But more than that: you should now be able to use the “SPAnimatable” protocol in different parts of your game. It’s a very simple yet powerful protocol, and can help you every time something needs to be moved or animated in your game.

4 Comments

Creating a game menu

Since the release of Sparrow, we have received quite a lot of positive feedback — thanks a lot for that, guys! There are already a number of people working on games that are powered by Sparrow.

If you are a little bit like me, you will put most of your thoughts and efforts in the game itself — the levels, graphics and gameplay. You know that at some time in the future you will have to create a game menu, a highscore system etc., but you put that thought back for now. And I think that’s the right thing to do: you have to concentrate on one step after the other, and the game is the most important step.

But one day, your game will be ready (it sure will!), and you will need a menu system. So I thought you would be interested in the approach we took for that matter with PenguFlip.

You might have noticed that the game menu in PenguFlip does have that typical iPhone interface look. Well, there’s a reason for that: the menu is not written in Sparrow, but in Cocoa. Yes, Cocoa, just like the boring notes and stock apps. ;-)

A bare-bone menu system


The reason that we wrote it that way is simple: “Always use the right tool for the right job”. Think about the stuff that is displayed in a game menu:

  • navigating to different screens
  • a settings screen with switches and sliders
  • scrolling lists with highscores and/or statistics
  • a connection to facebook
  • text fields (keyboard!) and alert boxes

Granted, you could do a lot of that in Sparrow. But it would be time consuming. Cocoa, on the other hand, was designed for exactly those tasks, and it does those tasks well. You’ve got the interface builder to set up the screens in no time, and all interface elements (switches, sliders, tableviews) are available and ready to use. Furthermore, the users know how to use those interface elements. They won’t need to learn anything new to navigate in your menu.

I know, some of you might think: ‘But Cocoa is boring. I want to have a flashy interface, where everything is moving and turning. You can’t do that in Cocoa!’ Your point is perfectly valid, of course. We all want to have those menus. But, trust me, that will take a lot of time — and in my opinion, this time is better spent in making your game better. Games are played because of their gameplay. Not because of their menu.

And though it might hurt to have a simpler menu: it can look great in Cocoa, too. With beautiful graphics, even a static menu will look awesome!

Furthermore, when you begin working on the menu, the rest of the game will be nearly completed. You want to get it out soon! I can say from first hand experience: developing the game menu is boring, and — even with Cocoa — it takes a lot more time and effort than you might estimate. You will be happy for any hour you can spare.

Conclusion

Every game needs some kind of menu. This makes me wonder why there are no finished “menu-engines” available, just like there are graphics engines (like Sparrow).

For PenguFlip, we created a simple menu engine for internal use. It is skinnable (via standard nib files) and can thus be easily adapted for our next games. It’s not über-flexible yet, but it will do for our games. That way, we can add a menu to a new game in not much more than an hour (ignoring graphics & sounds, of course).

The question is: would some of our users/readers be interested in such a menu engine? And would it need to be just as free as Sparrow, or would you be ready to pay something for the saved development time?

I’m looking forward to any comments and thoughts on this topic =)

Whatever the outcome: you can be sure that our top priority will continue to be Sparrow!

3 Comments