__ ___ _ _ __ _ _ __ __ ____ _ _ _ _ __ __ ____

Tweaking and Perfecting
 

After you have everything you intend to put in your game in, and have run out of ideas about extra chrome, the final stage before playtesting (or during playtesting) is to increase your game's timing. This is akin to the editing aspect of movie production. If you have anything that involves timing: story event scenes, textboxes that advance on their own, cutscenes, coordinated music, etc., now is the time to make the timing prefect. Now is also the time to go back and alter the occasional graphic (a walkabout perhaps) which doesn't look up to the standards of the rest of the graphics. You may be tempted to just release it and forget about perfection, but this is a mistake, for you'll never have another opportunity to perfect it, after it is released, you shouldn't think about working on it ever again, but until then, you have a little more time to make the game worthy of yourself.
 

__ ___ _ _ __ _ _ __ __ ____ _ _ _ _ __ __ ____

Playtesting
 

Two main types of playtesting: finding bugs and finding gameplay imbalances. Hopefully you've been playing your game as you make it, and so the majority of bugs will never reach your playtesters. It used to be that most commercial games (for game consoles) were playtested for 3-6 months before release (because you can't release bug patches for the NES). And even then, some bugs slipped through (like the use Relm in the Phoenix Cave bug of Final Fantasy 6, and the final floor Lufia 2 bug).

Playtesting imbalances are sometimes ignored in the playtesting phase, and sometimes with good reason. Ten or twenty playtesters is not an accruate representation of players in general, and just because one of them feels a certain boss is too hard is not enough of a reason to rush and lower that boss's HP. But if all the playtesters (independently of eachother) have trouble in the same area, that might be reason enough (assuming they are good players).

The terminology of 'beta testing' and 'alpha testing' are sometimes used for computer game testing, and there is usually no standard definition of what these mean, except that beta testing is right before release and alpha testing is farther away from release. This usually applies more to non-game software, however, and I believe it originated in that context, so I don't use such terminology. There need not be set phases of testing, and if there are, the game creators should decide on what those phases are (and are called).

Where do you find playtesters? The most foolish mistake is to only use people who know you -- friends and family. This will give you an overly optimistic vision of your game (unless your friends and family don't like you, in which case their opinions on it are also useless, or they are very objective about it, in which case they are the best playtesters you can ask for). It's preferable never to have met your playtesters, that they are indifferent toward you and give your game a chance but are not familiar with it previous to playtesting, but this isn't always possible. Game designers and to a lesser extent game reviewers (whether Ohrrpgce or otherwise) are usually good playtesters, if you can get them to playtest for you.

This should be common sense, but take what the playtesters say seriously, especially if they are also game designers. It feels (speaking from experience) like wasted effort to playtest a game and then have the author of the game release it anyway, without fixing any of the bugs and imbalances you found and took the time to point out. If you don't care about the quality of your game, don't expect playtesters to care more than you do.

Playtesting should begin as soon as the game is partially playable. Using this diagram again:

Playtesting should begin when any part of the outermost circle is complete, as you can see from the three occurances of the word 'playtest'. As soon as a map or a boss or a plotscript scene is put in the game, playtest it yourself. As soon as a good chunk of them are in (what 'good chunk' means depends on the game), ask others to begin playtesting. Too early is a lot better than too late.

__ ___ _ _ __ _ _ __ __ ____ _ _ _ _ __ __ ____

Copyright Laws
 

There is a lot of confusion on this, from what I've seen. International copyright law is automatic. All you need to copyright your game is your name and the date. The (c) symbol is optional, the name of what you are copyrighting is optional (but advisable for purposes of clarity), and there is no need to register with anyone.
 

__ ___ _ _ __ _ _ __ __ ____ _ _ _ _ __ __ ____

User Documentation
 

Your documentation may be as simple as a read-me file, or as drawn-out as the Lunar 1&2 propaganda of Working Designs (music CDs, making-of CDs, cloth maps, amulets, standees, quasi-leather bound instruction manuals with bookmark ribbons (including design art, walkthrough, and interviews with the developers), and the like). I prefer walking closer to the second path than the first, when possible. Extras add to the game experience, especially when unexpected. When Startropics was released for the NES, it came with a letter from one of the characters in the game inviting the player into the game. It also had a message to save that letter. Then, more than halfway through the game, the game itself informed you that there was a secret message on that letter, and told you to immerse it in water. Upon doing so, you reveal the password neccessary to work the submarine, the game's main transportation. This ingenius way of using documentation delighted many a child. Nintendo kept this up with Earthbound (Mother 2 in Japan), which included smelling stickers and a huge walkthrough guide which had the feeling of a tour guide. This wasn't as great as the letter was, because these things weren't integrated with the gameplay two directionally, but they still brought you into the world of the game more than just a weak instruction manual would have done. An instruction manual in some form is essential, of course (even if your game includes vast user-friendly in-game tutorials on every button push, you still need something to let people know how to contact you and how to install the game if for some reason they can't get the game to work). But how boring to include just that.
 

__ ___ _ _ __ _ _ __ __ ____ _ _ _ _ __ __ ____

Pre-Release
 

Publicity requires a different repertoire of skills than game design, and you're not likely able to afford an advertising specialist. But games have to be known about to be played, and have to be played to be liked, and what potential players hear about your game influences their decision to download it or not.

A lot of people overly downplay over upplay their game's value in advertising. This is a mistake. A potential player doesn't care or need to know your claims of the game's worth to them (whether its 'this game will change the way you look at gaming' or 'this game isn't worth downloading, and you'll hate it') they just need to know about the game: what's in it, the general idea, etc.. In other words: don't tell others what they are going to think of your game, just tell them what it is.

A website for your game is usually a good idea, especially if your game is freeware and you need somewhere for people to download it from. It needn't only be that, it can have quotes about the quality of the game, links to reviews, a summary of the game, screenshots, a message board, a fan art section, previews of upcoming sequels, and whatever else you think fits in. The website, especially for independent games, is the game's face, even more than its title screen is its face, and ideally should be finished or near-finished before the game's release.
 

__ ___ _ _ __ _ _ __ __ ____ _ _ _ _ __ __ ____

Reviews and Criticism
 

After your game is released, you are going to get a chance to see how it is evaluated by its players, what points they talk about, which they don't, and in general whether the game is talked about or ignored. Operation: OHR is currently the lead Ohrrpgce reviewing site (with Ohrrpgce Monthly itself following), and a lot of the time people don't agree with the reviews. That is expected; it would be amazing if someone did agree with his game's reviews. A reviewer doesn't look at the game with the same ears that you do, just as you hear your own voice differently than others do (and it is unfamiliar if you hear it on tape). Don't expect reviews to be what you expect (if that doesn't make sense literally, take it semantically).

One thing you should not do is to ignore when others point out faults in your game. That doesn't mean you should go and change everything that the reviewer says is wrong in your reviewed demo, it just means that you shouldn't dismiss offhand the possiblity that the reviewer knows what they are talking about. Often they do, and often if they criticise some aspect of the game's quality, it merits looking into.
 

Previous Page || Contents || Next Page