In this installment of Z-Tips, we'll look at how to provide a good help system that players of all kinds will make use of.

It's no good to have a game without help. Even if you make the very simplest game, one that has only two buttons saying "Press here to play" and "Press here to quit," people will have questions about your game. Why should we care about the help systems in our games? First because a good help system allows players to better enjoy your game, and second because it lessens the number of times we (and others) get bugged about the game.

We are going to examine a few facets of help systems: where to put them, what to put in them, and how to use the DM language to our advantage in making a good one.

There are a number of ways to introduce a help file to players. Our placement has to achieve a few things. Obviously, it should be easily available whenever someone has a question. But it can also be a good idea to stick it somewhere people will be forced to look at it and click it away themselves in order to progress to the game.

Many players prefer to jump right into a game without reading help (I'm one of them), but this can be to their detriment and everyone else's. It can be disruptive to have new players bugging other players or even paging you with things they could have learned if they'd bothered to read the help file. So it's for even the most independent player's good if you have a popup at the beginning of the game showing some basics. Let the players click it away... but maybe they'll absorb something before they do.

You can output some beginning help right to the main text window, a low-tech approach. Or you can make a page for the browser window, or make a browser popup. I think a browser popup is best because it's more likely to be noticed and has to be actively clicked away to make disappear, and because the player can minimize it and bring it up later. I use one of these in my game Sheep II, and I'll show you how.

In mob/Login(), we will call the Intro() proc. In the mob/proc/Intro() proc, we'll create a page that has our introductory info on it, then show it to the user in a browse window.

mob/proc/Intro()
var/page
page += "<html><head><title>Introduction</title></head><body bgcolor=black \
text=yellow>" //our formatting
page += "<big><big>Welcome to Blagglemites!</big></big><br><br>"
page += "The object of the game is to take over the world with your blagglemites by playing cards that give \
you special blagglemite powers.<br><br>"
page += "<big>Controls</big><br><br>"
page += "Join button - join a game<br>"
page += "Start button - start game<br>"
page += "Click card - click on a card in your hand to select it<br>"
page += "Click map/blagglemite - click on an area on the map or a blagglemite to see info on it<br>"
page += "Doubleclick map/blagglemite - doubleclick on an area on the map or a blagglemite to apply your \
selected card to it<br><br>"
page += "Enjoy Blagglemites!"
page += "</body></html>" //not necessary in a browse window, but good habit
src << browse(page,"window=info;size=500x380")

The last line is what displays our created page to the user. In the first argument we tell browse() what to display (the page we created, held in the "page" var). In the second argument, in quotes, we can set a number of aspects of the window the page will display in. By naming a window in the first place, we tell browse() to create a popup rather than using the standard browser pane. The only other thing we are going to specify is the size; on other possible settings, such as whether the window can be closed or scrolled, the default will work fine for us.

This will make a lovely little popup that will give the game basics to arriving players. Suppose we have more information about how to play the game; perhaps we have detailed info on what each of the cards in Blagglemites does. We could add this into our popup. The popup can be as big as we like. But I think it's best to put it somewhere else. The smaller your popup, the more likely it is to be read at all. When you have a popup that's so long as to be scrollable, you can put all the vital information at the very top, but your jump-in type players aren't necessarily going to realize that all they need to know is at the top there. In the brief essential glance, all they'll see is that the file looks too big to be read in the 5 seconds they're willing to dedicate before jumping into the game.

So we will put more detailed help somewhere else. To let people know there is more help, we can add a line to the end of our page saying "For detailed game instructions, use the help verb." Now, with any luck, every player will take a few seconds to scan what's there before joining the game. With any luck, you won't hear them ask "What do I do?" and hopefully, when they're already into the game and a question does come up, they'll remember there's a help verb.

What will our help verb do? Our help verb will show players a well-organized file that will not only contain the answers to their questions, but will arrange the data in a fashion that makes those answers easy to find.

It's not always evident what beyond basic play instructions should go into your help file. The very best thing you can do is make a preliminary file with those instructions, put it in the game, then do plenty of testing. Keep track of what else your testers want to know as they play the game. Anything that your testers find confusing may be a candidate for something to be changed in the game itself, but it's good to document as much in our detailed help file as we can.

A help file for a game with any complexity should have sections. Some of these sections should be:

* Goal(s) of the game and conditions for winning * Game controls and/or what the verbs do * The rules of the game * Personal options such as sounds, music and host tools

The first element, the goal or goals of the game and conditions for winning, is very important. I have played a number of games where the instructions are very clear on what I can do during my turn, but don't tell me anything about the game's purpose. State right up front what players are trying to accomplish in your game, and which conditions must be fulfilled for a win to occur.

"Blagglemites is a game in which you attempt to take over the world. The player who fills in every map area with his or her color, conquering each area by strategic use of his or her blagglemite cards, is the winner."

The controls for your game are important as well. In some games, the controls may be self-evident -- perhaps all you have are clearly labeled buttons with good names -- but it's still vital to document them. This is an area where the input of your testers is required; as programmers, things can seem obvious because we have always known how to play the game... but they may or may not be obvious to someone with an outside perspective. It might not even occur to you that how you move around the map with the NumPad is part of the controls for your game. Also explain what each of your verbs does, even the painfully self-evident ones.

It's up for grabs whether a section on game controls should go before or after one on rules. Players who are more interested in figuring things out for themselves will appreciate the controls section first, so they'll know what to click on their explorations. Other players may appreciate having the rules come first, so that there's more context for the explanations of what the controls do.

It's not always easy to explain the rules of a game in a format that's clear to new players. Not all good programmers are good teachers, to begin with. Once again, your testers may be your best allies. Pay attention to what they ask about how to play the game, and be sure to include those items. Something no one has ever asked may not need to be included, and might be better off left out, to avoid overloading players with information.

One way to structure your rules is to look at the order of play in your game. Follow the order in which game events and choices occur, looking at the players options anytime a choice is needed, and the results of those options.

"Blagglemites is a turn based game. At the beginning of a player's turn, he or she will receive a new card, which will go into that player's hand. The player may now choose either to pass, or to play a card. If the player clicks 'pass,' he or she receives 1 momentum point, but cannot play a card, and play moves to the next person. If the player chooses to play a card, by selecting the card then double-clicking on the map or a blagglemite, the action stated on the card will occur, and then play will move to the next player.

"A player takes over an area on the map by extinguishing any opposing blagglemites in that area and having at least one of his own blagglemites there. Areas under contest will appear in grey; areas held by one player will appear in that player's color. When all areas on the map appear in your color, you have won."

Note how in the above sample, I restate aspects from our other help sections: the controls and the winning conditions. This level of redundancy isn't a bad thing. It helps out those players who would prefer to read just one section.

A section on personal options that don't affect gameplay is also important! Even if you don't have any other options, you should say so. If there is no way to turn off the music in your game, firstly you should be shot, and secondly you should add that in your help file so players don't tear out their hair looking for a way. (Likewise, if your game has no sounds, mention that so players don't go crazy trying to turn them on.) These non-gameplay-related options can be included in your section on game controls if you feel that section would not become too cluttered, or they can be included in a separate area for clarity. But your documentation should contain at least a sentence about your personal options' existence of lack thereof.

Those are the basics every help file should include. What about some other things we might want to stick in there... say, a FAQ section, a strategy hints section, or game credits?

I think a FAQ is a great idea if it's truly composed of your players' frequently asked questions, and not just things you thought might end up being frequently asked. As I've mentioned, I'm not the type to sit down and read through a whole help file. I love having a page I can pull up that has answers for only the things I can't figure out on my own.

Many games will include some basic game strategy in their help files. It can be tempting to include this; when you've come up with a game on your own, it's exciting when you get out there playing it, and notice patterns and means to win in it. The fact that you discovered them yourself and were the first to do so makes it hard not to share tips. But I prefer not to see any strategy at all contained in help files. Let your players figure the strategy out for themselves, help each other, make their own strategy fan sites.

It's better to have credits than not have credits. Most of your players may not care who worked on the game, but they're harmless if properly situated.

So how do we lay out our documentation? I will suggest once again a popup window, which your players might like to minimize and keep handy.

mob/verb/help()
Help()
mob/proc/Help()
var/page //as in the code for the intro, we add what we'd like to say on to this page variable, then...
src << browse(page,"window=help;size=500x380")

You can do some fancy things in this window, like making clickable links to each help section, adding graphics, but I'm here today more for design than for code, so our help file will be low-tech. We want people to know what's in it, so some kind of listing of contents is good.

What about our FAQ or credits? Both or either of these could do well at the beginning if it wasn't too long; otherwise, best to stick it at the end, or even in some other file, perhaps brought up by a "faq" or "credits" verb.

Finally, remember to chose wisely when you pick background and text colors for these popups. Ask your testers if they look good.

Z's Peeves

Do not put music in your game that cannot be turned off. Depending on what you choose, music can be extremely irritating, and I don't trust you to choose wisely. I can't count the number of times I've stopped playing what could have been a fun game, because I couldn't stand the constant music but didn't want to turn off all sound. Here's a simple verb to allow your players to turn the music off:

mob/verb/music-off()
usr << sound(null)

If you don't put these two lines in your game, I will come to your house and kill you.