The designer formerly known as Lum the Mad has a wonderful volcanic eruption of a post up called How To Make A Game With ‘PvP Done Right.’ He makes a lot of great points, and I pretty much agree with all of what he says in there. It’s a great insight for many people, I’m sure, showing how any little decision you make will have repercussions, and designing a PvP system is like walking on a thin line that you might violently crash off into some endless void of suck. Come to think of it, designing anything for a game is pretty much like that. Anyway, check out his post. The main lines from each of his points are after the fold. Continue Reading »

You may know that I love humor. I’m not particularly funny myself, despite attempting to be almost constantly, but I really do appreciate comedy. That is also the case when it comes to playing any game, be it massively multiplayer or otherwise. However, I think some games tend to go overboard. There is a line in comedy that should only be crossed by a certain type of game, and even then it should be moderated. Continue Reading »

Many people, when they try their first MMO, are innocents. Those who aren’t terribly experienced with online play in any persistent sense, who haven’t forged relationships with others using their virtual selves. People who don’t realize that avatars in a massively multiplayer game are our virtual representatives, and that people actually remember who our avatar is. Continue Reading »

I’m one of the many people who complains frequently about tedium and inconvenience being unfun. I have limited playtime now that I’m married, with many of my sessions capping out at an hour or less. Any time there is a time sink introduced into a game that I see little value in, I get extremely frustrated. The more often that happens, the sooner I am likely to quit playing a game entirely. It’s a wonder, then, that I don’t have a problem with travel time. Continue Reading »

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.

I already mentioned a talk given by Gordon Walton at AGDC, but there’s another good one that I’ve read the write-ups for. This one was also by a BioWare Austin guy and was called The Zen of Online Game Design. It’s a good talk that discusses what Damion Schubert calls the Three Rs: Recruitment (of potential players), Retention (of existing players), and Reduction (of costs). There are great write-ups on Raph’s website, Slashdot, and Next Generation. Keep an eye on the Zen of Design blog for more in-depth articles on each of those Three Rs. As I catch other good write-ups from AGDC, I’ll link them here (and don’t hesitate to direct my attention to other goods ones yourself).