Mischiefblog
I WATN 2 MAEK GAEM!

Niche MMOs

Posted by Chris Jones
On January 11th, 2005 at 09:49

Permalink | Trackback | Links In |

Comments Off
Posted in Games

Meridian 59 is a perfect example of an old school niche MMO: it has a small, well-established community, long history, and a stable subscriber base. Niche MMOs don’t seem to cannibalize players from mainstream games (at least, not in such numbers as to be noticed), although they may be cannibalized by the new, shiny game.

Niche MMOs usually have innovative or challenging features and mechanics that don’t have currency in the mainstream games, such as item loss upon death, strong PvP mechanics, a single strong mechanic (such as crafting, combat, or socialization), text-only interface, strong developer interaction, etc. Many niche MMOs have failed, and many mainstream MMOs have been forced into the niche category over time–this is the natural evolution of these games, although companies addicted to high MMO populations and profit will cancel the “failing” game before considering a new, low cost business model. In general, niche games have under 50,000 subscribers.

Niche games have to be recognized in the market by players.

There is room for the niche MMO in today’s marketplace. Their biggest problems have tended to be too few players to keep operating profitably, lack of player population growth (player loss is inevitable), and lack of marketing clout. Some organizations, like the Themis Group, have organized advertising campaigns for these lesser known games and to bring new players into the game. Although this sometimes succeeded, many niche games were doomed to obscurity and eventual failure: the cost of attracting new, potential players can be higher than the income ever realized by that player (c.f., Rubies of Eventide). Many players are tired of the same mechanics, the same XP grind, and what is essentially the same game with a different skin (EQ and WoW come to mind) and are perfect candidates for the niche game, but first they have to be reached.

Consider working with gaming websites to review the game, contacting bloggers and luminaries to visit the game and provide their feedback, and inviting people from message boards to try the game. Well placed advertising can begin to build mind-share, but that won’t bring in income; a stellar endorsement by an influential guild leader or well-known board personality can bring as many people to visit the website and learn about the game as entire advertising campaign.

The game website needs to be accessible and provide a positive, informative view of the game. Plenty of screenshots, information about gameplay, mechanics, and tidbits to encourage all four types of player need to be presented well and with tantilizing detail. Game lore is good to include, as are real-time statistics of your game players.

Once the player is ready to try the game, the MMO operator needs to start making a good, lasting impression:

  • the game client needs to download quickly and install easily, without errors,
  • the game’s appearance needs to be professional and the UI perform responsively and as expected by the player,
  • the game itself must be compelling and absorbing, with the player drawn naturally into the world and, for these new players, with another option, goal, or something to learn waiting for them,
  • the game’s mechanics and play must always behave as the player expects: rubberbanding, locked combat encounters, unexpected PKing, and insta-death mobs will turn off new and potential players,
  • and the game community must be friendly, open, responsive, and supportive.

A niche game needs to break even, or better, make a profit.

Bandwidth and data center costs alone can consume money that would be well spent on expanding and supporting the game. Consider that a traditional client download can be 300 MB or larger, with textures, sounds, animations, and binaries: a few dozen people trying the game daily can cost 6 GB or more in download traffic alone. Using Bittorrent is a reasonable solution, assuming you don’t make Blizzard’s mistake and shut down the patch client as soon as the download is complete. A similar distribution method is to load areas “on demand” from other game clients–bandwidth limiting and integrity checking would be required in those cases.

Game play bandwidth is also to be considered. Clients should be coded to require the minimum amount of bandwidth (no XML messages), and should run well on a 28.8k modem or slower. The server should send a minimal number of packets, and each packet should be well-sized (under 1500 bytes, and ideally around 700 bytes) to pass through gateways without fragmentation. Additionally, game world update packets should attempt to provide as many updates as possible in one packet. Finally, clients should meter the number of packets they send to the server (no more than four per second, and ideally less than one packet per second), and the server should ration clients. Although many ISPs and routers have this turned off, multicasting would be an ideal way of updating world state without having to send individual updates to each client.

Getting too many characters or mobs in one area can lead to exponential increases in the number of update packets to send to player, or of apparent lag. Again, when the server can fold many updates into few packets, bandwidth costs can be reduced. Additionally, computing line of sight and clipping distance on the server can reduce the number of chartacters or mobs that need to be sent to the client. A niche MMO will be unlikely to be able to afford sending the entire zone’s mob and movement data (like EQ) to the client every second. Consider instancing encounter areas to reduce the traffic sent from a single zone.

Packets themselves should be minimal in size and structure. Traffic should be segregated, with critical packets using TCP, and the majority of the world state update packets using UDP–out of order UDP packets can be safely discarded and the world updated to match the latest status. (Yes, this can lead to apparent rubber-banding of mobs and other characters, the appearance of others running in place, etc.)

The game should be written so that 10 concurrent, active players consume under 300 kbps of bandwidth, and aim to have each client consume no more than 3 kbps while idle, travelling, or performing normal activities.

Customer service is another major, ongoing expense. Players pay for a service and expect to receive responsive help when something goes wrong. Consider developing mechanisms to have players help themselves (ignore lists, assistance channels, banning and booting from private areas, etc.). When possible, turn the company staff into CSRs: a custom client that notifies staff members of waiting issues in the queue is a good way to get everyone involved. Of course, ensure that you have strong policies in place, and that all CSRs know what can and can’t be done.

Alternatively, consider having little or no customer service representation. If players are given powerful tools for handling their own disputes, and only game errors are handled by CSRs or developers, costs could be dramatically cut. I’d love to see how CSR costs are impacted in a game that implements whuffie. Remember that if you cut CSRs, you should also cut subscription prices to reflect the lower cost to do business.

Comments are closed.