Alright, this is the second article in my series of articles about writing Fantastic Contraption.
This one is about menu development. And how much work it is. And how much work it continues to be.
Fantastic Contraption took me about four months to write. And fully half of that was spent on the menus. I think I spent more time on my mouse-pointer code than most flash authors spend on their games.
I have written a fair number of games before. But none of them have ever been fit for human consumption. And I think in general what makes a game fit or unfit for release to the public is the menu system and the interface. I guess this is trivially true, since you can have a game with no menu but not a menu with no game.
The problem for me is that the importance I put in the menu is way out of whack with the importance the user puts in it. I don’t care at all about it and wish the issue would just go away. The user sees it as an integral part. They first use it to judge the quality and theme of your game. And then they require it to smoothly and painlessly allow them to go where they want to go and do what they want to do.
At the heart of the matter is that every user starts out as a novice and has to learn to use your game. While, as the author, you are a power-user from day one. You think people should just use the command-line interface like you do.
But they don’t. So you have to spend an incredible amount of time exposing your features to the user in an intuitive, appleaing way.
Let me give you an example of how much work this is. Lets take the Main Menu as an example. The Main Menu lets you you select what level you want to play. What is required to make the Main Menu? (you can check out the menu here)
Well first off you need graphics. God help you if you aren’t artistic or don’t have a brilliantly artisitc fiancée. If your graphics are suck noone is even going to try your briliant game.
The Main Menu has a list of levels. Which is (currently) retrieved from the server when the game loads. So if a user jumps to the main menu they will breifly (or not so breifly depending on the server-load) see an empty field with no level-buttons. To hide this we need a fancy animation that covers the loading time. In Fantastic Contraption this is a screen of bubbles. But then there are all sorts of timing issues you have to coordinate. When menus get hidden, shown and when the bubbles are comming, going, or holding solid.
Now you need buttons. The life-blood of the menu. This requires more graphics. But it also requires a system. Fantastic Contraption has something like 100 buttons. You aren’t going to manage this many buttons without your own event types and a solid system to manage the events they throw. Plus you need to handle both the buttons and the mouse changing when the user mouses-over the buttons. Adobe makes this akward with their mostly-but-but-quite-working tools for including vector graphics in command-line projects.
On the main menu most of the buttons trigger either a new menu to appear or a level to load. But these new menus will open new menus of their own, and will have buttons that go back to the previous menu. So now you need a menu management system with a stack that new menus get added to and removed from as users go back and forth.
Currently there are two pages of levels. So you have to add paging buttons that route a request back to the server. Which has to be written to page the data properly.
And there are menus that don’t take you away from the page but pop-up over the existing menu. Like the log-in menu. Most menus don’t have to talk to eachother but the log-in menu has to tell the main menu when a user logs in. So that the main menu can put their name in the corner. So your menu system has to have a way to relay information between menus but not break if the user is logging in somewhere that isn’t the main menu (like the save game menu).
And just a ton of other look and feel problems. Like getting the font right and the text to fit in the space provided and the hitmaps for the buttons to cover the right amount of space and other buttons that appear when a level is finished and the mute button and fitting the “buy this game, please!” button in but making everything look natural when it’s gone and trying to make everything responsive and why won’t the mouse pointer change when it’s over the buy button!?
And that’s the simplest menu in the game.
When you start out authoring a game you’re thinking “this is going to be the coolest game ever!” not “this is going to have an intuitive, trouble-free menu system!”. But find the will people. Because menus are a must.
I’d also like to quickly thank Dan Ukryn for giving me some advice in my foray into menu writing.
