Creating a game menu

Daniel Sperl on May 2, 2010

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!