The Laws of Online Communities

I went ahead and updated an ancient page called The Laws of Online Communities. It includes some of my observations of online communities over my many years on all sides of the game development fence (player, fansite creator, community relations manager, and designer). I added a few more laws to the mix, and I’ve mirrored them below.

Law #10: Developer posts are valuable as long as what they post has value. It’s great to allow for transparency and open communication between fans and your development team, but it is only valuable as long as what the team posts is useful. The Signal/Noise ratio doesn’t only apply to members of the community, it applies to the company as well.

Law #11: Never announce something before you’re 100% sure it’s going to happen. If it’s something very minor, it’s often okay to mention that you are thinking about doing it, but always be clear that it isn’t a sure thing. If it’s something major, don’t even go that far, or people will expect it to come to fruition even if you indicate that it may not.

Law #12: Never lie to your community. Honesty is the gateway to trust. It is better not to answer if you aren’t sure, and it is better to tell the hard truth even if players aren’t going to like it. They will respect you and your company more for your honesty.

Law #13: Never try to mask a negative as a positive. A nerf is a nerf, a buff is a buff. Players are smart. You can’t fool them into thinking something is a good thing if it isn’t. If something that players perceive overall as negative has positives, feel free to highlight them, but don’t pretend that everything is pie and cake if it isn’t.

Law #14: “A person is smart. People are dumb, panicky dangerous animals and you know it” – Kay, Men in Black. Build relationships with individuals, and realize that an individual can be reasoned with. People are smart. Treat members of your community as individuals, not just as a faceless crowd.

Law #15: Encourage and reward constructive contributions from community members. Whether positive or negative, acknowledge and thank players who provide constructive feedback, organization, and sanity to your community.

To see the rest, check out the page:

MMO Development Lesson #45

Remember that an MMO is multiplayer. There are multiple lessons in that one phrase, but I’ll just split this one into two (the next lesson will cover the other half). One of the most important considerations when you’re making a decision about a quest, event, population, or feature is to consider the multiplayer implications of that decision. All too often I see content that isn’t multiplayer friendly; it’s developed with a single player in mind, and as soon as more than a few players are around, problems occur.

For example, content bottlenecks are pretty common with named bosses, particularly with the first major wave of players in any MMO. You get a quest to defeat High Lord Brekhalu and you ultimately find him where the quest said he’d be. Unfortunately, someone’s already fighting him or he’s just been killed. Find a way to fix it. Can you share credit to all players who helped defeat him? Can you trigger a near-instant respawn of the boss if someone who needs him is present? Can you make it so players summon him in some way (e.g. lighting a pyre or hitting a gong)?

Every decision should be made with multiplayer in mind. From the ground up (literally). The environments need to accommodate enough players, the mob population needs to be dense enough and have some form of respawn throttling (low mob population respawn acceleration), events and objectives need to account for multiple people, quests objective numbers need to be tuned against objective availability, intricate scripted sequences might best be left to instances, features should be multiplayer inclusive, etc.

The fact that MMOs are multiplayer is the genre’s greatest strength and greatest development challenge. Leverage it.

MMO Development Lesson #44

Don’t be afraid to ask for help. One of the most common problems I see with new designers is that they’re afraid to ask for help. They think they might look stupid or incapable of doing their jobs if they ask someone for assistance. Instead, they bang their heads against a problem until they either solve it, give up, or finally seek help. It’s a waste of time, and asking questions doesn’t make you look stupid. Even as a senior designer who is extremely good with tools, I’ll happily ask even an associate designer how to do something if I forgot how to do it. It’s not a big deal!

MMO Development Lesson #43

Know when to stop. There is always a point of diminishing returns with everything. This goes for overtime, content creation, and virtually anything you do when working on a game. With regard to self-imposed overtime, you need to learn where your point of diminishing returns is. Do you know that you can work 10 hours a day indefinitely? Great! Don’t make yourself work 12 hours a day, slowly degrading your overall work quality and output over time (and remember that family is important!).

This is one of the hardest lessons to learn as a developer. Do you have a really interesting idea that you think might be possible if you just work on it for a few more hours? Is it worth it? Often, a piece of content is very nearly as good in far less time than you might be personally willing to put into it. It can be tempting to keep working on it because you might eventually get there, but you need to know when to stop and move on to the next thing.

MMO Development Lesson #40

All the passion and talent in the world on your development team can take you far, but business and management are just as vital. Making a game takes a village. You need designers, engineers, artists, testers, and many other creative and skilled developers in the trenches. But, you also need solid production, management, and a viable business plan or your game isn’t going to get very far. Focus on making a great game first, but remember that this is a business and don’t let a game fail for the wrong reasons.

Want to read more lessons? Check out all of my MMO Development Lessons!

MMO Development Lesson #39

Be mindful of where you set your quality bar. If you set your quality bar too high, it’s going to make production difficult and inefficient. This goes for all aspects of game development, not just design.

To give an example, let’s use art. Let’s say you can create a very good looking crate in one work day. To the untrained eye, it’s an amazing crate. To the eye of an artist, it’s fine, but it could use some tweaks to get it just right. Those tweaks take two or three more days to complete before everyone is happy and the crate is itself a work of art.

Guess what you just did: You wasted two days. The vast majority of players are not going to see that crate and examine its intricacies, they’re just going to see it as part of a scene. The time would have been better spent on an important landmark prop rather than the crate.

This is true of design as well. Don’t spend 8 hours writing flowery dialogue and quest text when you’re just sending a player on a mission to kill a named boss. That time could be better spent improving the boss encounter, adding an optional objective, or creating another quest entirely. The player is going to remember the experience, not the perfectly-crafted dialogue.

Find your baseline quality bar and make that realistic, then create moments of extreme quality (Lesson #37) that the players will remember.

Remember the MMO Lesson series? It’s back now that I have some time on my hands. Check out the other MMO Lessons!

The Value of Open Beta

I was linked to an article with the following tagline: “Doubts raised on the value of public betas.” It’s essentially a commentary on open betas not being useful to the development process. It’s interesting, because I thought we’d figured this whole thing out back in about 2004. I’m not a panel, but I can say fairly definitively that open betas are very useful, in roughly these statistically-irrelevant percentages: Continue Reading »

3 Things Official/Unofficial Forums Do

An innocent post declaring official forums a necessary evil led to some controversy. Garthilk, a guy who actually runs very good fansites like WHA, basically called me out and asked me to list 3 things that official forums do that fansite forums can’t. I’ll do him one better by talking briefly about 3 things official forums can do that unofficial forums can’t, and 3 things unofficial forums can do that official forums can’t. I honestly believe both are necessary, and neither is actually evil. Continue Reading »

Update Agility

One of the rarely mentioned, but incredibly important, aspects of MMO game development is updating the game. When someone does certain aspects of updating very well, it highlights the importance of it. What I’m talking about at the moment is update agility — responding to real, game altering issues in a timely manner. Continue Reading »

MMO Development Lesson #27

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 »