Posts Tagged ‘finishing’

This is community focused blog entry and not generally related to Textfyre.

Since the community has begun to look at ways to broaden the reach of IF, much of the focus has been on web-based interpreters like Parchment and Quixe as well as in-game modifications to enable easier play for people new to IF. In the past there have been efforts to develop feelies to go along with games. These are important steps, but I believe there is a lot more that could be done to widen the potential audience of game players.

With that in mind, I believe we have an iceberg problem.

Below the surface there are a number of things that are named post-production, finishing, and packaging. These are fairly huge tasks and without them, a particular game is unlikely to reach more than the normal people in the IF community.

Once you’ve completed your game, tested it thoroughly, possibly even added some nice in-game hints and help, there is still more work to be done. Some of these things might or should include:

It’s my belief that hints need to be embedded in the game, but also available in the user interface in a seamlessly user-friendly fashion. They also need to be context sensitive which means going through your game thoroughly and writing down as many questions as possible. In order to test to see if your hints are working properly, you probably need to sit a novice IF player in front of your game and see how they do. Getting feedback is very important, so this is a step with several iterations.

Every game should implement several different kinds of help either as an add-on document or embedded in the game or user interface. There should be a general introduction to IF, to the particular game and its idiosyncracies. There should be help for the user interface and there should be context sensitive parser help. If people are typing wildly inappropriate commands, the user interface should step in and help out. There should probably also be context or status help, where at various points in the game, a note is displayed summarizing what the player has accomplished, where in the game they’ve traveled, and a map showing such travel.

Cataloguing Information
Every game should have an IFID number, a title, list of author(s), a list of non-authorial credits, a short game summary, a long game summary, a marketing tag line, cover art, a standard set of icons, list of search keywords, genre(s), and probably a list of other games that are similar.

Every game should come with an in-game or add-on document map that shows either the detailed room layout or a more artistic rendering of the game setting.

Every game should offer an online place for a user to turn for questions that are not answered within the game or the user interface. The forums should probably be moderated to keep it clean.

Every game should be packaged so that it can be installed on a Mac, PC, or Linux box with a single step process that places the game in a known location. Most computer users understand where their programs are supposed to go, which is on the Start menu or in an Applications folder and/or menu bar. There should be no mention of interpreter or game file or anything about where things are located or installed and how things work. Most users don’t care and aren’t interested. For mobile devices, each game should be packaged individually. The hobbyist community will always feel comfortable with something like Zoom or iFrotz, but I don’t believe a wider audience will until, well, there is a wider audience. Each game should come with a transcript for each possible ending (unless if there are infinite endings of course). If possible, there should be an e-mail address the user can use to report bugs or to contact the author(s).

Loading Times
Obviously with larger games there is an issue with loading times, especially using Parchment or Quixe. I don’t think there’s any problem with the loading time specifically, but something should be presented to the user besides a count of bytes being loaded. There should be a cartoon or progress bar and this is probably a good place to offer some introductory text to distract the user while the game is being loaded. Watching a byte count is likely to be a death sentence with a lot of users.

Each game should be announced on, registered as a game at IFDB, and reported to Baf’s Guide. We should probably come up with a system to report new games to various blogs, ezines, and other appropriate channels.

I’m not sure if this is required or an optional task, but I think a specific website/web page for each game might be a good idea. IFDB offers this on some level. possibly a bit too libraryish. I think something more game focused and author designed would be nice. The way Adam Cadre and Emily Short have presented their games is very nice.