Make it easy to come back. If someone has quit your game (See: Lesson #26), make it so easy to come back they can’t believe they quit in the first place. I’ll apologize right now for not making this lesson short and sweet like I usually do, but this one’s worth elaborating on. I’ll start with what you shouldn’t do, then I’ll give a few ideas for what you could do to make coming back easier than ever. Continue Reading »
Make cancellation easy. Seriously, don’t make it difficult in the least. The worst thing you can possibly do is make someone call to cancel their subscription. It may yield you an extra month of their subscription money since people are generally lazy, but it will leave such a horrible taste in their mouth that they will NEVER come back. Ever. Feel free to ask for brief (key word #1), voluntary (key word #2) feedback, maybe a series of check boxes that they can select for why they quit. But, make it a simple, easy to understand, quick, painless process. If you do, the player will be infinitely more likely to come back if and when they get the itch.
A game is only as strong as its weakest feature. Games are more often judged by their weaknesses than their strengths, just like anything else. Any incomplete feature or complete but crappy feature will leave a bad taste in players’ mouths. Reviewers will dwell on anything that isn’t up to par in your game far more than they will dwell on all the positives. Do not be afraid to get rid of features, even if you’ve already implemented them. This goes for more than just features: If a quest sucks, fix it or get rid of it. If a zone sucks, fix it or get rid of it. If anything sucks, fix it or get rid of it. It may make you shed a tear for all that lost work, but it’s better than leaving it in.
Know when to stop. Beta is not a time for you to pack in new features that you weren’t sure you could get into the game, it’s a time for you to polish all of your core features and ensure that everything that will be in the game at launch is up to snuff. If you find yourself with the desire to add that neat little feature you always wanted, ask yourself two questions: 1) Is everything currently in the game polished and ready to go for paying players? 2) Do we have time to implement this feature and get it polished to a fine sheen? If the answer to either of those questions is “no,” under no circumstances should you try to implement it. Know when to stop, and quit while you’re ahead.
Inconvenience does not make a game harder, it makes it less convenient. Tedium does not equal difficulty. Making something unnecessarily complex, tedious, or in some way inconvenient doesn’t make the game more challenging or more fun. Is having an extremely limited amount of inventory space fun or challenging? No, it’s tedious. It’s not fun gameplay for most people, even if there are some freaks out there who want to painstakingly manage their inventory and consider the absence of that unfun. Don’t design for those people unless you are making a niche game. Make a game challenging via gameplay, not tedious barriers to fun.
Just because you have a good idea doesn’t mean it’s a good idea to implement it. Sometimes a good idea isn’t completely cohesive with the core focus of the game. Sometimes a good idea is very difficult and time-consuming to implement, and that time would be better spent on other things. Sometimes a good idea is cohesive and may not necessarily take forever to implement on its own, but preexisting systems would not mesh very well with it. Whatever the case may be, just because someone has a good idea does not mean it should be or even can be implemented. Remember, when someone who can make calls does not include your good idea in a game, it doesn’t mean it’s a bad idea or that they simply don’t like it; there are usually other reasons that it doesn’t get implemented.
A good idea stands on its own. It doesn’t matter where a good idea comes from, it’s still a good idea. Let go of your ego and learn to identify a good idea no matter where it comes from, even it’s from a non-designer, player, or even your mortal enemy. I’ve had a few good ideas in my life (I like to think, anyway), but the total number of good ideas I’ve heard from other people dwarfs the number of good ideas I’ve ever had myself. Learn to get over yourself and recognize good ideas when you see them.
It’s better to start with a great shell than a jumbled mass of crap. Okay, that wasn’t articulated well, but the point is this: If you are outlining a system or some content or whatever it is, don’t mash a bunch of random ideas together and hope they will work out. Instead, create a notes document in which you jot down all of your random ideas for whatever you are creating, then write a structured and cohesive document as the document. You will thank yourself later, because trying to revise a jumbled mess is even harder than writing something completely new (I tend to just wipe things clean and start over if I don’t have the notes doc).
Make decisions. Sometimes it’s better just to make a decision on something you’ve been thinking about for a long period of time and go with it. You’ll discover pretty quickly if that decision was the wrong one, and you can, in fact, change your mind on decisions you made before. It is not a crime to delete what you wrote down for System X and start it over–in the end, your game is better for it, because you know WHY the original System X isn’t as good as the new one. Note: Don’t go live with said decision until you know it is the right one.
Quality Assurance is not a four letter word. Test is, but that is beside the point. The point is, QA is vital to the success of your MMO. These games are simply too big for you to catch everything on the first pass. Never underestimate the power and passion of QA testers–and don’t treat them like crap just because they aren’t “on the dev team.” I prefer to consider anyone who makes a game better part of the dev team. Utilize and respect your QA team, and do the very same for those dedicated Testers who are part of your community.