ddd00000ff00fe0080888000a3f
^2««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»

^2       {7P O L I S H   U P  Y O U R   P R E S E N T A T I O N .{

^2««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»

^4 What makes a program stand out from the rest?

^1 Why  does  program `A' get accepted for Licenseware or released as a
^1commercial  while  program `B' is classed as Public Domain, when both
^1do basically the same thing?

^7 We have learnt a lot over the last 18 months whilst writing for Déjà
^7Vu  Licenseware  and also more recently whilst working with Europress
^7on  a project that we will hopefully be able to tell you about in the
^7July Issue of TA.

^1 First  of  all you do need a good idea.  A brand new type of game or
^1program will obviously stand more of a chance than an Amos rewrite of
^1Space Invaders.

^7 If  you  do  decide  on  a  topic  that  has been done before, which
^7admitedly,   if  you  are  writing educational programs, is often the
^7case  especially with English and Maths, then you must come up with a
^7novel approach.

^1 A  blank  screen which merely has a sum printed on it in the default
^1Topaz font will not impress anyone, although if it is the first thing
^1you've  ever  made  the Amiga do for you, then you have a right to be
^1proud.

^7 Now,  if  your  maths program was set inside a fun to play game, had
^7cheerful graphics and a reward sequence for getting the sums correct,
^7then it would stand a chance.

^1 Whatever  the  subject  of  your  program,  the  main  aim has to be
^1long-lasting  appeal  for  the  user.   No  one wants to pay out hard
^1earned  cash  for a five minute wonder, so think out what you can put
^1into your program before you plough into the coding.

^7 Although we think that Amos is the best thing to hit computers since
^7the silicon chip, and we always make sure that Amos gets full credit,
^7there  are a few things that it does which will give the game away if
^7you  want  to  show someone your program before telling them what was
^7used  to  create  it.  There are still Software Houses out there that
^7will not accept Amos as a language for their products, although these
^7are  getting fewer.  Most publishers of educational software are Amos
^7friendly!

^1 The  first  things to get rid of are the horrible orange screen with
^1its  cursor ghost in the corner that pops up at the start of a lot of
^1programs.  All you have to do to get rid of this is:-

^2 Screen Open 0: 320,200,16,Lowres: Curs Off: Flash Off: Cls 0

^7 This will give you a `clean' start to your work.  It's good practice
^7to  do  this  as  it  can  save problems on RAMOSing your disk.  Amos
^7defaults  to  Screen 0, but if you force the screen display yourself,
^7then you are in full control of your program from the start.

^1 We  use  a screen depth of 200 as there will not be any problems for
^1American  users if the program is taken to the USA (or Japan for that
^1matter!)  Don't  say  that  your  program  will  never go there so it
^1doesn't  matter,  Sandra  has  a very active American distributor for
^1Amos PD and Licenseware, so it might well travel there.  (Hi Dave!)

^2 Curs Off:  Flash Off:  Cls 0 ^7done in that strict order will sort out
^7the other problems.

^1 Screen  wipes  and  other  special  effects  will make the move from
^1screen to screen more professional.  If you have been collecting TA's
^1Screen Wipes, you will now have 25 to choose from!

^7 Instructions  must be clear and easy to read.  Put these as a README
^7doc  which is displayed on loading (with PPmore or similar) or if you
^7have  disk/memory space as part of your program.  Commercial releases
^7have printed manuals, others won't.

^1 Be sure that the program WILL run in the amount of memory you say it
^1will.   1/2  meg  programs  should  RUN  on  a  1/2 meg machine, some
^1programs  will  load,  play  for a while then crash out of memory, so
^1test  thoroughly,  if  in doubt, say that 1 meg is needed or at least
^1highly recommended.

^7  Remember that the Amiga's memory `leaks' and a bit is lost here and
^7there  during  the  running  of  a  program which cannot be got back,
^7therefore you should thoroughly test your program for a likely memory
^7bang out on a machine with a smaller memory capacity than the one the
^7program was written on especially if you have over the now standard 1
^7meg.   Most  Amos  programs,  games,  educational etc will need 1 meg
^7unless  you  have  the  knowledge  on ALL the possible ways of saving
^7memory.   Perhaps that could be the subject of another article.  Read
^7the programming tips in TA, this is where we put such gems!

^1 One  thing  that really makes a game come to life is the addition of
^1sound  effects  and  music.  Amos does not allow the editing of a Sam
^1bank,  so  this  is easier left till last when you can make a list of
^1samples  you  will  need  and put the banks together in one go.  Easy
^1Amos, however has a superb Sam Bank editor which is very flexible and
^1user friendly.

^7 As  our  main  interest is in educational software, our knowledge on
^7what  makes  a  good game is rather limited, though having said that,
^7our book is about writing a game!

^2                    Check list For Games writers

^41.   Are the graphics suitable.  Cutie style for kids, futuristic for
^4spacey  Shoot'em  ups, as realistic as possible for an adventure etc.
^4The  graphics are the first thing to hit the user's eye, so they have
^4to  be good.  However flash your coding, pinmen graphics will not do!
^4Great  graphics  can  however  hide  the  odd inconsistancy in coding
^4quality!

^52.   Does the game consist of conquering one level before going on to
^5the  next?   If  so, if your player dies on Level 10, will he have to
^5start  from  Level  1 again?  This is extremely frustrating and it is
^5better  to have a password or similar system to restart the game from
^5a higher level.

^43.   Is it possible to finish the game inside the time allowed or the
^4the number of lives allowed?  The only way that this can be tested is
^4to  play the game from start to finish, you can cheat be putting in a
^4temporary trainer, or by getting friends & family to do it for you as
^4long as any bugs are noted down, with info saying where and when they
^4occurred  and  what the player did to create the error.  A bug report
^4saying  `It  crashed  on  Level  2'  will  not help you to debug your
^4program,  whereas  `It  crashed  when  I shot the green monster as it
^4passed  over the spaceship going right to left' could give you a hint
^4of what went wrong.

^54.   Is all your action smooth?  Does the joystick/mouse control work
^5properly?    Is   your   collision  detection  accurate?   Will  your
^5bullet/missile hit the target at the right angle, for example.

^45.  Is the score routine fair, have you left enough room in the score
^4display  for  someone who will score a mega number of points, if not,
^4are you giving too many points per hit etc.

^56.   In  a  maze game, you must be allowed access to all parts of the
^5maze, believe me, after writing `Marvin the Martian' it is quite easy
^5to make parts of the maze inaccessable to the player.
  
^2                   Educational Program Check List.


^11.  Lots of the above points are relevant!

^62. Test it on children of the relevant age.

^13.   Don't  feel  embarrassed at using reference books to check up on
^1facts!   Just  because  you  are writing a program to teach spelling,
^1don't  assume that your spelling is perfect, this type of program has
^1you doubting your own abilities!
  
^64.   The  main thing that you MUST keep in mind here is the fact that
^6you  are  trying  to  teach something or reinforce a child's existing
^6knowledge,  therefore  YOU MUST BE ACCURATE!!!!  A child will believe
^6that  computers  are  always right, not the truth that a computer can
^6only  do what it is told!  If it says 2 + 2 = 5, then they might well
^6go on believing it!  English programs are very Data hungry.  You must
^6make  sure  to  the  best  of your ability that there are no spelling
^6mistakes,  then  ask someone else to check the data with a dictionary
^6if  necessary, all mistakes should be rectified before the program is
^6finally  released.

^1  Definitions  or  clues should be clear and if there are two or more
^1possible  correct answers to an anagram for example, then this should
^1be  covered.   eg if the letters TSAR are given then possible answers
^1would  be  STAR  RATS  and  TARS.   It is cruel to say that a correct
^1answer  is  wrong  unless you gave a clue for the one answer you want
^1the  user  to  find,  eg It twinkles in the sky at night - STAR would
^1then be right, but RATS would be wrong.

^6 Yes  we've  been  guilty of errors, spelling, grammar etc in some of
^6our  programs,  but  we have always tried to put them right once they
^6have been discovered.

^1 Data  accuracy would be very important also in geography, history or
^1anything  else  that  deals  with  facts.  Remember to put in capital
^1letters for proper nouns ie place names etc.  Even if the user inputs
^1a  word  in  lower  case letters, it is easy enough to make the first
^1letter  a capital when return is pressed to enter the word.  This way
^1reinforces  the fact that certain words need capitals even if you are
^1not asking them directly to use them for data input.

^65.   Fonts  used  should  be clear and the younger the target age for
^6your  program  is,  the bigger (within reason) and bolder the letters
^6and  numbers  should  be.   Browse around the children's section of a
^6bookshop  to  see  how the displays in the books change as the age of
^6the child increases.

^16.  Keep control of the program simple!  It's no good asking a 5 year
^1old to press two keys on the keyboard and at the same time press fire
^1on  a  joystick!   Alternative  choices  of  control are a good idea.
^1Sometimes  the  same  program  can  be  keyboard,  joystick  or mouse
^1controlled.
 
^67.   In  multi-program packages, try to give a feeling of continuity,
^6eg Big Top Fun has a central theme of a circus, Europress' Fun School
^6uses  the  same font and colour schemes for text displays, there is a
^6central character in a lot of packages, eg Play It Safe.  etc, etc.


^2                     Utility Program Checklist.

^41.  Will this program perform its task faster or more accurately that
^4if it was programmed manually?

^52.  If it is meant to be included as part of another program, does it
^5take up the least amount of memory possible?

^43.  If it is a stand alone utility, does it look good?

^54.  Is it easy to use?

^45.  Can it be used by a beginner?

^56.   If  there are certain dangers involved in its use (ie doing this
^5will erase your previous hard work!) Have you told the user to make a
^5Backup,  also  have  you included a disk health warning system before
^5the task is carried out?

^47.   If  you  get  comments  such as `Why didn't anyone else think of
^4that?' then you know you've got a good idea!

^58.   Listen  to  the  things  that other Amos programmers moan about.
^5Paul  Townsend did this and came up with Music Engine which will play
^5unconverted music files from Sonix etc inside Amos programs.

^2General Comments.

^6 If  you  have  put every effort into seeing that your program is the
^6very best you can do, listened to other peoples comments and included
^6the  ones  that  improve  your program, tested it for hours and hours
^6until you never want to see it again, then you deserve to succeed, or
^6at  least  get  yourself noticed.  It is easy to spot if a programmer
^6really  CARES about his or her work as the program will look and feel
^6good.

^1 Never say `It'll do!' IT WON'T!  This attitude shows when there are
^1lots of little errors in a program, eg the odd graphic glitch or jerk
^1or text appearing slightly out of place. 

^6 If your program is returned from wherever you've sent it with a list
^6of  comments or `improvements' consider them carefully before sending
^6the  same  program  elsewhere,  if  someone  has taken the trouble to
^6comment,  they  are  probably  willing  to take your program with the
^6changes.

^1 Be  flexible!  If you want to succeed, you must be willing to change
^1your  views  if  necessary in order to get a software house to accept
^1you and your work.

^6 Don't  expect too much too soon.  Here we are not just talking about
^6money!   Just  because  you  think that your program is fantastic, it
^6does  not  mean  that  everyone else will!  Standards are continually
^6rising  and  so  as time goes by programs will have to get better and
^6better  to  stand  a  chance out there.  That's where we hope that TA
^6will  be  able  to help.  We believe in passing on things we learn in
^6order  to raise the general standard of Amos programming, and we want
^6everybody else to do the same!

^2««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»»««*»
\