16 ways to make your WP7 game better #wp7dev

One of the great things about Windows Phone 7 is all the games available.

Over the last few weeks, I've definitley spent more time than I probably should playing just a few of them.

Not being one to miss an opportunity to find ways to improve the apps (and games) I'm working on and may build in the future, I've been looking for lessons I can learn from other people's games. Some of these lessons are based on identifying things which some games do well, some on things some games do badly and some on my own ideas and observations.

In the hope that these lessons can also help you improve the apps you create, here's the list of points I've drawn up. This is in no way an absolute or complete list but that shouldn't invalidate it's value. (While specifically relating to games, many of these points could be applied to any application.)

In no particular order:

1. Lots of short levels are preferable to a few big ones.
   

   This is especially true if the game doesn't support tombstoning (or any form of saving and resuming later). It also better suits a mobile environment where users will typically play for shorter periods of time compared to other platforms.

2. Get tombstoning right, so I don't lose my place in a game.
   

   Unfortunately there are lots of games that don't support saving games part way through. Because of the nature of the phone I can't guarantee not being interrupted and so if I can't save my game at any point (whether the interruption was my choice or not) can be very frustrating.

3. Keep multiple copies of saved state so that even if there's a problem you can revert back to the slightly older copy as its preferable to go back a bit in a game than to lose everything.
   

   Unfortunately, (presumably at least in part) due to the large amount of data a game needs to save to resume later, quite a few games I've played have crashed when trying to resume a previously saved game. The framework will automatically close the game if it takes too long to perform certain tasks (including resuming a game). In all of these cases the only solution was to start the game again, thereby losing all progress. If practical I'd like to see a game take periodic snapshots of game state (some games do do this. e.g. at certain points in a level anyway) and then if when attempting to resume it's not possible to successfully restore a game based on a specific copy of the saved state

4. Don't screw up the back button!!!
   

   The rule of the back button (for >95% of apps) is that (with the exception of a possible dialog to confirm closing) repeatedly pressing the hardware back button will close the application. Unfortunatley there are a few games which break this rule. This can be very frustrating!

5. Evenly balance all achievements
   

   Don't just achievements that will mostly be achieved in the first few minutes of play and then a couple for having played for a VERY long time or (for example) 1000 Games or earing a million points. Achievements should be achieved as the user progresses through a game, not all at the start.

6. Show progress towards achievements
   

   If you have achievements based on the number of times something is done or the total time spent playing a game then indicate the progress being made towards those numbers/lengths of time

7. Don't use technical, meaningless terms in unnecessary prompts.
   

   Seriously, just don't. To a non-technical user you will just confuse and potentially frustrate. "Why do you keep asking me this question I don't understand. Cancel."

8. Be smart about touch targets
   

   If a game has lots of touchable items close together and I try and click on something I can't but its right next to something I can, assume I meant to click on the thing I can click on. An example of this would be a game which has certain spaces where you can place "pieces" and the user touches the already populated space next to an empty space. Yes this can mean that the touchable area for items will change based on it's neighbours (which may be complicated to program) but the alternative is to frustrate users. Your choice.

9. Don't save all details on a single config file
   

   Because if the stored game state fails to save and all details lost I don't want that to lose my entire history. e.g. Total points across all games or number of games played. Use multiple files and/or IsolatedStorageSettings as appropriate.

10. If your about screen contains URLs and email addresses make them clickable/actionable.
    

    Do you seriously expect me to type in your url or email address when you're to lazy to wire up a touch event to launch a task? And if I have to contact you because of a problem I'll be even more frustrated because of this. Just saying.

11. Let me exit the app at any point, not just at the end of a level/go.
    

    Specifically in response to navigating via internal menus or the hardware back button. (Yes I know it's possible to exit via the start or search buttons.) This is a variation on the above point about breaking the back button but I can't see any reason why I shouldn't be able to exit at any point in the game, even if I'm happy to lose my progress/state within the game.

12. If I'm listening to the radio when I start your game don't ask me about "custom music"
    

    This is a specific variation of the above point about unnecessary prompts. Why is the music "custom"? What does "custom music" even mean. The point hear is to word your dialogs carefully to match user terminology. I suspect they meant to refer to "currently playing music".

13. If you prompt me to confirm closing the game don't add another screen after that where I have to select quit again.
    

    I seriously don't understand why anyone would even think this was acceptable. As a user I find this frustrating and confusing. What happened? Did the game actually close? Why do I have to press "Quit" 4 times to close this game?

14. Its better to show loading progress in lots of small steps than a few big ones
    

    Responsiveness is even more important on mobile devices. Having a loading status information message or progress bar length update more frequently can give extra reassurance to the user that they are progressing towards being able to play thier game sooner. In some instances, a more frequently updated progress bar can also give the perception that the total load time was less than an infrequently updated one.

15. Having an on screen back button can be useful for navigating between pages.
    

    Don't rely on the hardware back button if your game only plays in a landscape orientation. Most landscape games have an onscreen way of navigating back so by not having one you add an moment of confusion to the user as they try and work out what they're supposed to do to navigate.

16. If you have a lot of instructions / help (which is probably good) don't just have it all in one place (as a single long list).
    

    Provide relevant info, in pieces, as the user advances through the game. It's much easier to take in this way and a user is more likely to remember it when they need it. This all serves to help the user learn the game as they need to and become less frustrated by having to try and work out what they need to do. The challenge should be in playing the game, not how to play the game.