"A program should follow the 'Law of Least Astonishment'. What is this law? It is simply that a program should always respond to the user in the way that astonishes him least."This page is just an area where I can spout off with my own opinions regarding AIF or whatever I'm fired up about. You can scroll down to read my ravings on different topics, or choose from the selection below to jump right to a topic.
The Tao of Programming by Geoffrey James
Which language to use?
There is always some discussion at AGX about which programming language to use. The main discussion always seems to come down to two points:
POINT: Using an "easier" language like ADRIFT will turn out more games.
COUNTERPOINT: Yes, there are more games, but most of them are crappy!
POINT: Using a "harder" language like TADS or Inform will turn out better games because you really need to know what you're doing to write a game in these languages.
COUNTERPOINT: Yes, you get better games, but the number of games turned out is really low.
Okay, here's my $.02 worth: Poppycock to all of it! (That's right, I said Poppycock, and don't think I didn't mean it!) Here's the thing that makes or breaks a game: The game itself. I know that sounds like a radical concept, but it doesn't make any difference what language the game is written in, as long as it is well written. And by "well written", I mean the scenes and descriptions, not the cool programming tricks done by the author. When people play one of my games, "Dexter Dixon", do I think they think about the blood, sweat and tears I put into getting Bruno to circle the warehouse and let you "hear" his footsteps as he approached? No. They are more interested in how I describe the sex scenes with Claudia Vanderbilt as you and her get-it-on all over her mansion.
So, what's my point? (Believe me, I do have one!) Write your game in whatever programming language you feel most comfortable. I do recommend that you stick to one of the "big three": ADRIFT, TADS or Inform. That's only because those are the most popular languages and your audience is most likely to already have those interpreters handy. Remember: You aren't writing these games for yourself. If you were, you never would have released them to the general public. If you want more, and IMHO better, information on this topic, I suggest you check out these links:
- Choosing a Text Adventure Language
- "Easy" IF Languages
- "Hello Sailor!"
And, for an example of a small game written in many of the IF development languages (or "authoring systems") to use as a comparison, check out Cloak of Darkness.
Back to top...
Have you tested your game?
You've just spent months sweating over a computer keyboard, putting your heart and soul into a wonderful piece of interactive fiction that is just going to revolutionize the community. They'll be talking about this game for years. People will remember where they were and what they were doing when this game was released. With visions of accolades in your head, you zip up the game and send it off to one of the websites that distributes these games and ... WHAM! Oh, people are talking about the game all right. You've never heard such language used to describe a game before. You're actually starting to get death threats. What went wrong?
May I ask one simple question? Did you test the game? I mean, really test it? The first thing that is going to happen if you release a buggy game is that the not-so-forgiving members of your community are going to blast you with so many negative comments you're going to wish you had never bought a computer, let alone decided to use it for something. If you are going to be a programmer, you should be familiar with a couple of terms:
Alpha-testing - This is the initial testing that you perform on the game, to check to make sure it is working the way you think it should. Most of this is done as you are writing the game, so most of the time it really isn't a "stage" of the programming process. But believe me, there have been some games released where it is painfully obvious that the person writing it didn't do any sort of testing at all. Before you release a game, I recommend that you find and eliminate all of the bugs. In your mind, the game should be bug-free.
Beta-testing - This process involves letting a small group of people test your game. Let's face it, no matter how much alpha-testing you do, you'll never find all of the bugs. You'll never think of everything. So, let someone else give it a try. They'll find things you never even thought of and your game will be much better for it. After you correct these problems, then go through alpha- and beta-testing once again. You'll finally reach a stage where you and your testers all feel the game is bug-free.
Now you are ready to release the game. You may still receive some negative comments, but you'll find that they'll be more constructive. (Remember: You can never please everybody.) This leads me to...
Back to top...
How to criticize...
You've just downloaded a new game. You fire up your computer in anticipation of a few hours spent exploring the world created by this author. But wait a minute, what's this? When you climb the ladder outside the castle to the damsel's bedroom, you find you can't enter the window. It's closed and you can't open it. You spend an hour pounding on your keyboard before you finally realize you have to "TAP ON WINDOW" first to get the damsel to come open it. You can't wait to send off a message to the author. Let's see, how should it go: Dear moron: How could you be so f$(*ing stupid as to...
Needless to say, that is NOT the way to go about it. There is a right way and a wrong way to inform an author about perceived problems with a game. Remember, the idea is to encourage new authors so that more games get produced. Here are some tips from me:
Be polite- Is there really a need to be insulting? Sure, you might feel like the author is a moron for not thinking of whatever brilliant idea you had, but it doesn't help anyone to say so. In fact, you come off looking much worse than the author. More than likely, the author will just ignore whatever you have to say, and so will everyone else.
Be constructive- I worked at a job once where the boss would say to me: "Don't come to me with a problem unless you also have a solution." The same principle applies here. It is very easy to point out problems with anything. Solutions are a little harder to come by. If you can't think of one, then don't blame the author for not thinking of one! Going by the example above, the real problem is not in the solution the author presented, it was in the author not providing enough synonyms for the solution. You could suggest that the author also allow for such things as "KNOCK ON WINDOW" and "HIT WINDOW".
Be encouraging- Let the author know about the things he or she did right in the game as well as the things you perceive were done wrong. Not only will the author be more receptive to what you have to say, he or she will also be more likely to include the things you liked in any future games.
Bugs may not be bugs- You may have noticed that I use the phrase "percieved bug" a lot in this rant. This is because some bugs are actually just implementation choices made by the author. I once had a beta-tester request that I not force players to "SEARCH" items, and allow hidden items to be found by using "EXAMINE". I think it boiled down to a semantic interpretation of the word "EXAMINE". I interpreted it to mean "LOOK AT" and this person interpreted it to be a more thorough, well, examination. As it turns out, my interpretation is also the way the command is implemented in TADS. I decided to leave it the way it was. I'm sure that any players who felt the same way as my beta-tester felt that this was a bug, but it ultimately was a choice made by me in the way the game was implemented.
Back to top...
How to avoid "Guess the Verb"...
The second biggest problem facing game players is the ubiquitous "Guess the Verb" problem. (The biggest problem is the lack of new games, IMHO.) Fortunately for most prospective authors, this problem is handled pretty effectively by the authoring systems out there such as Inform, TADS and ADRIFT, which already have many synonyms pre-defined for the normal verbs used in A/IF. If you're a new player who isn't familiar with the "standard" set of verbs used in most game systems, there isn't much I can do to help. There are plenty of "Beginner's Guides" out there, which should help you through the learning process. The good news is that the standard verb set is pretty well defined across all platforms, so you don't have to learn new verbs depending upon which game system you use.
When it comes specifically to AIF, there are a new set of verbs that are added to handle the sexual aspect of these games. Many authors use pre-defined libraries such as those by Sir Gareth or NewKid. Other authors implement their own system. In either case, the verbs are defined and operate differently. Here are some tips that I offer from my experience as both a player and an author. Although most of these are written with the sexual aspect of AIF in mind, the same tips apply to almost any new verb you implement in your game.
List the commands you use - Either in a separate README file, or as an option in your game, list the commands you support and indicate how they are implemented. Whether you use "T*TFU** SHARON" or "FU** SHARON'S T*TS", it should be listed. Also, indicate how you refer to an NPC and his/her body parts. What I mean is that if it is "FU** SHARON T*TS" and not "FU** SHARON'S T*TS", then tell the player about this.
Be consistent - If you implement "FU** SHARON'S T*TS", then that is how it should be implemented for every female NPC in your game. You shouldn't have "FU** SHARON'S T*TS" and then later force the player to use "FU** BETTY T*TS". Going along with this, you should also have a response for every NPC for each new command you implement. I notice this the most in ADRIFT games, but I've seen it in just about every language. Here is an example of what I mean: The player is allowed to "FU** SHARON'S T*TS", then later the player is interacting with Betty. He attempts to "FU** BETTY'S T*TS", but the reply is something like "There is no need to use that type of language." Obviously, the author has decided that this particular action cannot be completed with Betty (maybe she is too small-busted). However, you should put in some sort of message to the player letting him/her know that what they've tried is legal, it just isn't possible with this NPC.
Think of synonyms - Try to think of and implement synonyms to the verb you are going to implement. For example, instead of choosing to implement "T*TFU** SHARON" or "FU** SHARON'S T*TS", why not implement both? Why not allow the player to "FU** SHARON'S T*TS" and to "FU** SHARON'S BREASTS"? Granted, don't get too carried away with it, or you'll spend all of your time trying to come up with synonyms just so someone can "FORNICATE SHARON'S MAMMARY GLANDS".
Back to top...