Standards for Online & Multiplayer Games
A Casual Connect Seattle Session Round-Up

Jonathan Greechan
Casual Connect Magazine, Fall 2007

Note: This article was written prior to the RealNetworks acquisition of Game Trust. A full transcript of this session and a podcast recording can be found on the CGA website.

There’s no question that the casual game market is moving to produce more online and multiplayer content. Considering our industry’s notorious conversion rates, one need only look at Pogo or the plethora of micro-transaction-based games in Asia to see that the other side of the pasture may, in fact, be greener. Many leaders of our industry have been predicting that “this will be the year of multiplayer” for years, but these prophecies have yet to come to pass. What is holding us back?

One factor restraining growth may be a lack of best practices that could help reduce stakeholder disagreements. To begin establishing these best practices, I helped organize a session at this year’s Casual Connect Seattle with industry leaders from top game studios and portals—including Margaret Wallace (Rebel Monkey), Bryan Bouman (HipSoft), Eric Zimmerman (Gamelab), Dave Williams (MTVN/Shockwave), Jim Greer (Kongregate), Scott Austin (Microsoft), and Ted Woolsey (RealArcade), along with the moderator, Adeo Ressi (from my company, Game Trust). This article serves as a round-up of what I thought were the key points brought forward during that session.   

 

Why All the Fuss About Online and Multiplayer Games?
With such a variety of participants representing companies of different sizes and strategies, it comes as no surprise that there were quite a few disagreements. However, everyone seemed to agree that the market is moving towards online and multiplayer content. “We tried to take Bridge down (from our service), and we had suicide threats—from 80-year-old people, homebound in Canada,” explained Microsoft’s Austin. “Bridge has become such an important part of their life, it’s unbelievable.” RealArcade, which is known mostly for its prowess in the download market, has begun testing a multiplayer service of its own in China. According to RealArcade’s Woolsey, “we are very encouraged by what we’ve seen there . . . we’ve seen steady growth in our concurrent usage.”

At the same time, the developers seemingly can’t move fast enough to fill the demand. Almost half of Gamelab’s titles currently in production are multiplayer, as opposed to none just one year ago. According to Eric from Gamelab, “already in the digerati circles, ‘Web 2.0’ is kind of a passé buzz word that everyone knows about, and if you’re not on the bandwagon, you’re being left in the dust. The game industry is definitely playing catch-up in that regard.” In addition, Rebel Monkey’s Wallace pleaded, “the casual game industry as a whole—we’re not moving fast enough in this direction. I mean, what is holding us back?”


If You Build It, They Will Come

One may argue that it’s a lack of tools provided by the portals that is “holding us back”—but that hasn’t stopped developers from uploading and hosting 10 multiplayer games on Kongregate without any multiplayer API. Nor has it prevented companies like HipSoft from building online and multiplayer features into games like Flip Words 2. “I love hosting it, and I would actually be scared of someone else hosting because I’d want to go over their architecture,” HipSoft’s Bouman explained. “Even if they’re a big company, I still want to make sure it’s done right.”

It’s only a matter of time before the portals do provide these robust services to the developers—they obviously want to maintain control over the user experience and not rely on several different backends. Kongregate, Microsoft, and Shockwave already offer simple APIs because, as Austin pointed out, “every game needs to have a friends list, authentication, and billing or ad-serving. . . . I think it’s absolutely necessary for the portals to provide those technologies and services to the developers so each developer doesn’t have to repeat it.”

However, the current APIs are of the single-player variety, to create “Pogo”-like communities around the games—an important distinction that Williams from Shockwave made. “We look at that as one potential model where we want to create some connective tissue between all the games that are on our sites,” he said.

So why haven’t the portals provided multiplayer APIs—if this is, in fact, where the market is headed? According to Woolsey from RealArcade, “we just can’t work fast enough.” What’s more, it can be hard for portals to navigate this new and complex landscape. As Shockwave’s Williams explained, this “is a lot more complicated for us because it often means letting go of the community, and potentially building somebody else’s community—a developer’s community—or even someone else who potentially could become a competitor to us. So that’s a really tough thing for us to get our heads around—that’s a real big challenge in the market right now.”

 

Different Models for Different Folks
Zimmerman pointed out that “online games present very different kinds of relationships with portals than single-player games do”—and with different relationships come different responsibilities. Throughout the discussion, three distinct deal relationships for online and multiplayer games were discussed: a Partnership Model, a Distribution Model, and an Affiliate Model.

 

Partnership Model
This model is very similar to a typical publisher/developer relationship. In most cases the developer will receive funding in exchange for exclusivity or even IP, and it will develop the game using the portal’s backend. The portal then handles the hosting and billing, and a large amount of data is shared between both parties.

This is more complicated than a typical download publishing deal—but the consistent user experience that is created is very attractive for portals, and the upfront cash and technical support can be a boon to developers too. However, with these deals the developer is usually tied to one portal, which is not always a good thing. As Wallace pointed out, “A lot of developers are developing their own backends independently because if they work with a certain API that is provided by a portal then they feel like, ‘I’m not stuck, but I’m going to be working with this portal, and what happens if my IP gets buried in this portal?’”

Distribution Model
When the developer creates an online or multiplayer game for syndication on multiple sites, this is the Distribution Model. In most cases, the portal would be expected to host these games and provide easy tools for developers to integrate with generic services like registration, high scores, and chat.  However, it’s definitely not always so cut and dried—the responsibilities become very tricky depending on the type of game. For example, a “massively single-player” or multiplayer card game could theoretically plug into portal services rather easily, whereas a multiplayer game with light persistence—in which the lobby system or backend is integral to the game—can be a different beast altogether. For this reason there can be no definitive division of responsibilities for games using the Distribution Model—they simply need to be handled on a case-by-case basis.

The billing responsibility in such arrangements can also be tricky, depending on the game. For the most part, the portal will likely require integration with its billing system because, as RealArcade’s Woolsey put it, “users get really confused if you have multiple points of e-commerce taking place. So we’re trying to think more from a consumer’s standpoint, and make it more holistic.” However, some portals may be willing to compromise. As Shockwave’s Williams explained, “we recognize that it simply isn’t technically feasible in many cases, and it certainly doesn’t fit with the business models of a lot of developers out there who we like to do business with.”

Affiliate Model
The Affiliate Model probably offers both the largest risk and largest reward for developers. Runescape and Club Penguin are prime examples of the possibilities. As Zimmerman explained, “The most successful community-based games have a single community—a single URL where people go.”

With the Affiliate Model, the developer generally hosts the game on its backend through a white-label solution. A portal may ask for segregated lobbies and varying amounts of branding, but the developer runs the community, billing, and is the general interface to the consumer. This model is most used for MMOs, and even lighter multiplayer games with elements of persistence. While there are exceptions, the developer is generally not expected to integrate any community services, because, as Kongregate’s Greer explained, “at that point the backend of it is so integral that the developer should probably host it.”

It should also be noted that not all portals are receptive to these arrangements—which is understandable considering the risk of customer-loss inherent to affiliate deals. In this forum, Shockwave and Kongregate were open to these opportunities, while Microsoft and RealArcade were non-committal. Developers should also acknowledge that affiliate deals come with significantly different contract terms, because, as Shockwave’s Williams pointed out, “those are really marketing relationships at that point. You’re really using my portal and my audience as a marketing vehicle.”

Deal or No Deal
So how does a developer choose which model to pursue? Wallace offered some advice by saying, “I really think it ties into your business goals . . . and where you see yourself as a developer, in terms of the value chain.” And while every game might not fall neatly into one of these three models, choosing a model puts you in a much better position to get a deal done. As Williams explained, “It’s important to be clear right out of the gate, because the moment you try to blend things, you run into a lot of problems trying to figure out what the deal is.”

 

Where, Oh Where, Has My Data Gone?
The discussion wrapped up with the always interesting topic of data-sharing. Both sides have valid points in this argument: On the one hand, the developer needs data in order to make better games; and on the other hand, the portals are providing the audience, and the data derived from that audience can be their competitive advantage. But in the online and multiplayer realm, it may be more valuable to see how a developer’s one game is used, as opposed to aggregate data. This data does not provide any competitive advantage for the portal, while it can significantly help the developer improve its game and design new content—which ultimately benefits all parties involved. All four portals were in agreement here—so we can definitively say that in-game usage data for online and multiplayer games should be shared, with varying levels of disclosure depending on the relationship model used.

 

Cue the Orchestra . . .
My biggest takeaway from this discussion is that, in this nascent sector of our industry, there still isn’t a straight line between point A and point B. I think Zimmerman put it best when he said, “If you look at other media—books, film, television, music—there are ‘corporate boy-band’ stadium concerts, but there are also still small record labels and digital distribution of music—and it’s that kind of ecosystem that keeps a popular cultural medium healthy. So I’m glad that there’s a variety of ways that we can work with portals.”

At the same time, this forum allowed both developers and portals, both big and small, to discuss their viewpoints and even come to agreement on some best practices for what remains a somewhat uncharted territory.

 

* * *

Jonathan Greechan is the Director of Games & Marketing at Game Trust, an online casual game infrastructure company based in New York City recently purchased by RealNetworks, Inc. His email address is jgreechan@real.com.