Transitions, much like bent spoons in martial arts sci-fi movies, are a figment of your imagination.
Or at least they ought to be.
Sometimes people program their games like this:
- Fade in menu screen (2 seconds)
- Wait for input selection
- Fade out menu screen (2 seconds)
- Fade in options screen (2 seconds)
- Wait for input selection
This is going to take at least six seconds before I can make a selection from the options screen.
The first time I play your game, I won’t care about that. I’ll probably be too busy ooh-ing and aah-ing at the incredible beauty and originality of your transition effects.
But what about the second time I play it? The tenth? If it is good enough to keep my interest, how about the ten thousandth?
After a while I will stop noticing your pretty transitions. I’ll have the route through your menus off by heart, and be able to navigate them in my sleep. Anything that slows me getting into the gameplay will just be an annoyance.
A historical aside: four years after shipping MotoGP, I still have the sequence “A, A, A, Down, A, A, A” (skip THQ logo, skip Climax logo, skip MotoGP logo, select Multiplayer, select Live, select QuickMatch) burned into my synapses. I did that so many times while testing the network code that it became an instinctive reflex. It’s a shame there are no fighting games that use “Left, Up, Left, Left, B, Up, Left, Left, B, Y, Down, Up, B” as a combo: that was the unlock-everything cheat code in debug builds of the game, and it is ridiculous how fast I still am at entering it!
Transitions are great for adding polish and flair, but you shouldn’t let them slow down the expert users who just want to get through your menus as quickly as possible. Here’s how I like things to work:
- Start fading in menu screen (will take 2 seconds if not interrupted)
- Start checking for input selections
- As soon as the user makes a selection:
- Menu screen fades back out
- Start fading in options screen
- Start checking for option selections
Note how the second screen is transitioning on at the same time as the previous screen is transitioning off. More importantly, note how there is never even a moment when the system is unresponsive to user input. No matter how fast I enter my selections, the game will always be ready for me. It may look a little odd if I am quick, because screens will turn around and transition back off even before they have a chance to finish transitioning on, but that’s ok. If I want to see a screen properly I can wait for the transition to finish, but I don’t have to bother waiting if I already know what the screen is going to be.
Put another way: from a logical point of view, new screens should become immediately active. Whatever fancy transition animations the drawing code is doing should have no effect on the update logic and input handling.
It should come as no surprise that our Game State Management sample works exactly this way. That is why it checks for ScreenState.TransitionOn as well as ScreenState.Active when deciding which screen should get the input focus.
While I’m here, a plea: if you have an intro logo, movie, or animation, please give me a button to dismiss it! There is nothing that makes me quite as angry as people who think their logo is so important, they leave it on my screen for 10 seconds with no way to skip past it 🙂
In a temporary moment of megalomania, I had the following dream:
- All XNA developers read my blog and take this post to heart
- Five or ten years from now, all the best games are being made using XNA
- Now all games have responsive, non-blocking, and reflex-friendly menu systems