Publishing Games: An Overview, Part One

by Shannon Appelcline

March 6, 2003 – Today we released two new games to the Skotos community. Meridian 59 and Underlight don't just represent a 50% increase in the games available to the Skotos community. They also represent the start of a new strategy.

At Skotos we've long wanted to offer not just a game-playing community, but also a game-designing community. Castle Marrach was always our proof of concept and our testbed for our online game toolkit. We're still very committed to this path, as can be evidenced by the fact that we've currently got seven(!) games in production using our toolkit, one of them (Lovecraft Country) being coordinated in house, and the other six being coordinated by external development teams all over the world.

However, along the way we've realized something. In the process of putting together a community for our own online games, we've also created infrastructure that could be very useful for other game developers on the net. And, that's the heart of our new Associate Game programs.

Meridian 59 and Underlight are, you see, games that are available commercially on the net. M59 is produced by Near Death Studios and Underlight is produced by Lyra Studios. But, both companies were interested in the fact that we can offer them marketing, business development, and branding above and beyond what they can provide themselves — that we can expose their games to more players than their own sites can. And so they've been willing to offer their games (non-exclusively) to the Skotos community.

I'm pretty excited in seeing the Skotos games expand in this manner, and thus I'm going to be actively looking for more partners in the months to come. As of today we have six games at the Skotos community. My goal for the end of 2003 has long been eight, but now I'm starting to think bigger. Maybe 10, maybe 12, maybe more.

Got a game? Talk to me about it.

The whole topic of Associate Games has gotten me thinking about what's really required to put out an online game. It's a lot more than just a well-designed game.

I've touched on the topic here and there throughout this column's history, but I've never really provided an overview of everything that's needed. So, that's what I'm going to be doing this week and next. This week's going to be part one of the overview, where I'll be talking about pre-release topics: QA, Documentation, and a variety of Engineering nuisances.

And, if you've gotten this far and wondered where's the strategic game design which has been the topic of this column from #101-109, it'll be back in two weeks. The release of the games today just provided too good of an opportunity for synchronicity to be passed up.

QA

So, you've got a brand, spanking new game, and you're ready to roll it out the door...

Hold on, Pardner.

The very, very first post-development step is one that's often missed: QA (or Quality Assurance). This is the stage where you sit down and make sure that your game works and is of professional quality. There's lots of things you can QA. Some of the ones you should pay the most attention to are:

Good Game Design: Is your game interesting? Are actions and responses clearly correlated? Are players able to figure out what's going on? Generally, this is the topic that I've spent almost this entire column talking about, but in the QA stage the idea is to let players loose in your game, and see if the game design decisions that you made actually match reality.

Expected Player Actions: Closely related in the QA process is observing whether players actually do what you expected them to — or not. If you've spent a month of programming time engineering your gadget-production skill, and you find that all of your players are instead engaging in gadget-rolling races, you probably need to go back and spend some time fleshing out those durned gadget races.

Ease of Use: Can your players intuitively interact with your interface? Are there any commands/UI uses which they constantly try, but fail? Is some of your interface totally useless because it's not actually interesting to the players? Sadly, computer users have gotten pretty used to really bad interfaces, so expect to have to prod your QAers to ask them "what confused them" and "what they wished the interface would let them do".

Good Ingelish: If you're using text, be it for an all-prose game or just for the occasional signage in a graphical game, does it obey the rules of English (or whatever your language of choice is)? There's nothing that says unprofessional like a typo in your game's entry hall.

Closing Up Cheats: Are there ways to exploit the system — which is to say cheats that players will use to either give them an advantage over the system or over other players? This is another topic where you're going to need to push your QAers to test. You need to assign a couple of people to explicitly try and break the system in any way you can... because there will be some users who do exactly that after your game is out.

I wasn't joking when I said that QA is often overlooked; as far as I can tell, this is the first time that I've written about it in two and a half years. Whoops.

Documentation

Probably equally neglected to QA is the whole topic of documentation. You'll start realizing the necessity during the QA process, as you start to see what confuses players. The whole idea of documentation can be pretty big, so I've outlined some of the most important aspects:

Quick Starts: We're square in the middle of an attention-deficit oriented society. Most people aren't going to bother reading reams of documentation before they get into your game, and thus if your game has any complexity, they're likely to be at a bit of a loss. My best solution to this is to offer a "quick start" — no more than two pages of text explaining the 5 or 10 things that are most important to a player entering your game. (See my Marrach Quickstart or GE: Hegemony Quickstart.)

Indexed Help: Because your players will be entering your game cold, you need to provide some nicely index documentation that they can use to figure out a specific topic within a game. This is typically done in prose games with a "help" command and in other games with a popup help GUI.

Contextual Help: If you're clever and did a good job on QA, you'll be able to figure out beforehand what sorts of things are most likely to confuse players in your game, and thus can stick in help that automatically pops up when players reach that stage. This is a very nice technique, but you should make sure that players can turn it off if it annoys them.

In-Depth Help: All of what I've written thus far is what's necessary to carry a player through those first couple of sessions where he's trying to figure out if he enjoys your game or not. If he does, he'll then probably want to read in more depth how everything works. This is the place for your in-depth documentation, which is to say a complete player's manual. If you scroll through the Player's Manual for Castle Marrach you'll see my idea of a fairly solid manual: 48 pages, including background, parser/UI information, and in-depth info on game systems. The Player's Manual for Galactic Emperor: Hegemony shows a more web-oriented manual that also reveals more of the nuts and bolts, as is required for a strategy game.

Engineering & Administrative Help: Finally, don't forget that the people running your game will need documentation. From the engineering side that clearly means "document your code", but it can also involve outlining procedures that must be undertaken to keep your game running. I often remind the folks I work with of hit-by-a-bus documentation. If you stepped off a curb and were hit by a bus, is there anything that you alone know, and is vital to running a game? If so, write it down.

Engineering: User Information

With that pesky QA & Documentation out of the way, you're ready to get that game out the door, right? Actually, there are probably a few programming tasks that have been neglected as well. The first big engineering question that you might not have considered is, how are you dealing with users?

To be more precise, you've probably got some type of individual account associated with your game, which is to say you give your players a character. But, is it associated with anything bigger, outside of the game?

Perhaps not, and it should be.

There's actually a number of meta-user functions which you're going to need to perform for individual players:

• You'll often want to hook up multiple characters to the same account.
• You probably want some type of contact info in case you need to get a hold of a player outside of the game.
• You probably want to record some pseudo-unique identifier, be it an IP address or a credit card, so that you kind-of know if people are playing multiple characters.
• You might want to hook an overall user account up with other applications at your web site, such as forums or personalized portals.
• And you'll need some place to save the inevitable billing information...

Related to all this, you need to figure out an authentication scheme, via which your users can use to log into their accounts. Likewise you probably want to develop some usage reporting schemes, so that you know when your players are playing your games (possibly, as with Skotos, so that you can report royalties, or maybe just so that you can develop stats on peaks and dips in your game's usage.)

Engineering: Billing

But, let's get back to that billing bullet point. If you're thinking about truly developing your game professionally, you're going to need to have billing in there somewhere, otherwise you just have a hobby which you might be able to spare the occasional evening hour for.

Billing is, perhaps, the most horrific engineering challenge involved in releasing an online game that you might not be aware that you're going to have to do. One of our engineers here at Skotos spent many months programming billing in before we released the Skotos community pay-for-play, and came out of the process semi-insane; he'd only been quasi-insane beforehand.

To start with you're going to have to figure out how you internally keep records of payments. Do you do it day-by-day, month-by-month, or year-by-year? Do you record the amount that people paid, for possible royalty use? How do you record different payment amounts and different payment time periods for the same user? How do you incorporate free, trial, and staff accounts? Are refunds a possibility?

If you're accepting credit cards, you need to find someone who'll supply you with a "merchant account", to fill out the appropriate paperwork, and to pray you get approved. And, for our industry, you'll need to specifically find someone who can automate charges over the Internet — and then you'll have to build an interface to work with their API. If you want to go with other methods like Paypal, you'll have to work with their teams to figure out how their specific APIs work and how they can be built into your increasingly chaotic billing structure. If you're going to accept checks, you need to build intuitive interfaces for your administrators to use to record those checks.

And afterward you need to start thinking about fraud. What do you do when you get credit card chargebacks? What fraud detectors can you put in place to catch things beforehand?

Whew.

Billing can be a pain, so make sure you outline your whole system beforehand if you're going to try and undertake it yourself.

The whole issue of having your game be pay-for-play raises issues which I discussed somewhat in Trials, Triumphs & Trivialities #45, And Now a Word from our Sponsor... .

Engineering: Security

So now you've got individual user information and possibly credit card information zipping this way and that across the net, which leads to the last engineering topic I'm going to cover this week: security. In running your online game, you should think about four distinct types of security:

Transaction Security: Is information secure when it is being sent the net? If you're using HTML, you've fortunately got an easy answer in SSL, which is supported by the https protocol. You'll need to jump through some hoops with VeriSign to get a certificate, but once you do, you can share secure and trusted transaction information. Where you should really watch your transaction security, however, is in any client you're running that isn't protected by https. The short answer is this: never send secret information over the net in an unencrypted (plaintext) form. Encrypt it or use a cryptographic hash... or something. It's really easy to use a "sniffer" to see everything that's going across a network, so don't put your customers' information at risk.

Server Security: You're probably storing some of that secret information on a server. If you're doing so, make sure it's well protected. First, this means that you should encrypt it or use some other method to ensure that some hacker can't pull plain text off your server computer. Second, this means that you should control how a player can recover his secret information. Generally, you never want a player to be able to recover his complete credit card information. (If he's forgotten, he should look in his wallet.) If you're going to let a player recover a password, you should usually require him to show some identity token saying he's really who he claims to be. Top methods for this include:

• Challenge/Response: For example, "What's your mother's maiden name?" This essentially is a second password, though one that the player's more likely to remember.
• Validated Email Address: If someone had earlier validated an email address, you can usually feel pretty safe sending passwords to that email address (though this violates my earlier statement that you shouldn't send them plaintext, because email is usually not encrypted; the obvious answer to this is to send a one-time password which the player can use to then change their password via a more secure channel).
• Information Verification: Finally, you can release one bit of secret information if your customer has access to some other secret information. For example, if someone can prove that they have access to the credit card they're using, it's usually OK to hand over a password. (And note, this is just another concrete variant of the whole challenge/response idea.)

Client Security: A lot less obvious to some engineers is the fact that you have to think about security with regard to your client too. Or, more specifically, you should understand that your client isn't secure. You can't trust anything coming from a player's computer, because it could be faked. Thus, though you can accept commands and requests, all computation, all interaction, and especially all randomization and results should be processed on your server. The first time I ever played Diablo online I got whacked by someone with a +gazillion sword — because the original Diablo trusted clients to report honestly on what items characters had. It was also the last time I ever played Diablo online.

Physical Security: Though outside the purview of engineering, make sure you think about physical security too — how your actual servers are protected. If someone can walk off with your server (or in a famous case on the news a couple of years ago, walk off with a laptop computer full of credit card numbers), the rest of your security ain't worth much...

Conclusion

And that wraps up the first part of this overview, on all that other darned stuff that you need to do to publish a game. Next week I'm going to cover the other half of this topic, with the issues that you need to consider while edging into post release: marketing, branding, business development, administration, community creation, continued game development, and... er... whatever I've forgotten.

Some of these upcoming topics I've covered more completely in the past than those topics that I wrote today... but I'm sure I'll find new things to talk about, and I definitely plan to help connect all the dots.

And before I close off totally, I suppose it's worthwhile to go back to my initial discussion of Associate Game and talk a bit more about what we do for games who come aboard as associates. We inevitably do bits of QA to suggest improvements for Associate Games, because we can't help ourselves. For our closest partners we also help write documentation. However, it's really in engineering that we can offer the greatest value to Associates still in the pre-release stage... because we've already dealt with user information, billing, and security... and thus offer engineers at Associate Games the opportunity to remain quasi-sane. And as for post-release value... that's next week.

I'll see you in 7.

Recent Discussions on Trials, Triumphs & Trivialities: