The Magic Cottage is a game based on the book of the same name by James Herbert. The first point to make here is that you should not submit a game for publication that is drawn on the work of another author. In the case of previously published books, films, plays or whatever this is particularly important. In most cases, not only permission but also payment (sometimes very substantial) is required before you can use another plot or design.

Stuart's game runs on the Amstrad 6128 only and uses a silicon disk (if you have one). The program asks whether such a disk is fitted when you RUN it and if you answer "NO", you receive a prompt asking you to edit a line of the program to enable it to run correctly. This is a serious mistake - In order to play a game the user should have to do nothing except RUN the program. You should avoid any disk or tape swapping, loading of different files, or unclear loading instructions.

In addition, Stuart's decision to use the 6128 is unwise. As far as the Amstrad market is concerned, the 6128 is in a minority. The best format for an Amstrad adventure is cassette format, 464 and 6128 compatibility, with any evaluation copies supplied on disk. This is a sad fact, since a disk-only game opens up a lot of very attractive possibilities, but I'm afraid that until we've all bought disk drives, we'll have to live with it.

The instructions for Stuart's game are contained in his accompanying letter. Another blunder, I'm afraid! The disk supplied should have a label bearing a clear loading instruction, the name of the game, a copyright notice (e.g. "Copyright Stuart Lockey 1987"), and your name and address. Most important! Don't forget also that, if you have used a utility, you should credit the company concerned as in "Copyright Bert Balroger. Produced using GAC from Incentive Software". In addition, you should also include a disk or cassette label carrying in as few words as possible a clear summary of the game's objective.

Again, this is extremely important. You'd be amazed at the number of games received that carry no explanation or introduction to set the scene of the game! Ideally, you should also program such an introduction into the beginning of the adventure, with an option to skip it if not required.

Your letter accompanying the game should be on one sheet of paper only unless you feel that there is vital information which simply cannot be compressed into that space. It should be typed or printed out - if you have to handwrite it, make sure your writing is legible. The letter should contain basic information about the programmer and the adventure. together with your reasons for thinking that the game is suitable for public release, i.e. what's so good about it? Be confident - don't say "I think the game is good because..." but strike out boldly and say "The game is good because...".

Ideally, the first sentence of your letter should read: 'Further to our recent telephone conversation, I enclose...'. And that obviously means that you have to make the effort to (a) find out who will be receiving and playing your game and (b) phone them to make sure they wish to receive an unsolicited program. This is only courteous, and also has the desirable effect of fixing your name in the publisher's mind. Don't, however, be a pest on the phone and allow at least six weeks for a response to your contribution. Then follow up your application with a letter. Most importantly, you should keep a back-up copy of the program you send and not expect to have the disk or tape returned to you.

And now for the game itself... Stuart's game does not appear to have been written using either GAC or The Quill, which is a brave step and has the advantage of giving the game a very individual flavour. It's also risky, since most companies will prefer a game that can be released on more than one format. Both utilities give you the possibility of doing this with a little extra work.

Stuart's game has some excellent screens, but it does unfortunately include a number of spelling mistakes and programming glitches. In addition, the vocabulary is limited and in some cases the gameplay is poorly thought out. For example, one location starts with two glasses in it, each of which has a different description when examined but the same description when you enter the room "You can see glass, glass." is a bit confusing under the circumstances and typical of the sort of rough edge in a program that could put off a software house. Note that not only is the name of the object non-unique, but also that the object list ends in a comma (in case there's another one to follow). Little points like this need to be tidied up before sending the game off.

As a general rule, the person who programs a game is the very worst person to play-test it. This may sound illogical, but the fact is that when working on a game you soon train yourself (unconsciously) to ignore many of its minor faults - and sometimes the major ones as well - and this is hardly going to endear your adventure to the player.

Good points about Stuart's game however are the graphics which are excellent and original pictures, if included in a game, must justify their presence. Don't use a graphics facility in your utility just because it's there - make it enhance the program and put as much effort as you can into it. If you're not skilled enough then better to go for very simple pictures or even none at all.

The Magic Cottage isn't a bad attempt by any means, but as you can see it has brought up a number of points that players submitting products to software houses would do well to bear in mind.