Education Software Must Be Entertaining
IAN MURRAY, continuing his series, looks at how amusing software
aids education
SO now you can program! If you've been following The Micro User
recently you will have learnt about the dreadful tricks and button
pushing that youngsters get up to. And you will have learnt how
to structure your keyboard entries to direct your user to do what
you want him to do.
Suddenly you are left with a clever piece of software which
is well structured, educationally valid — and dead boring. Oh
dear!
You are not alone. As the wrapping gets glossier on the computer
cassettes in the shops, it seems that a lot of the contents get
shoddier.
The commercial artists do a great job with zapping rayguns,
bug-eyed beasts and roaring rocketry on the covers. But once the
outer plastic has been ripped away the story is a little different.
Complicated instructions and poor graphics make the consumer
feel very hard done by. This isn't always true, but good and entertaining
software stands out.
Sadly very little educational software is at all entertaining.
Lots of teachers, and many parents, think that they cannot be
learning from the computer if a "game" is involved or
if the student is enjoying the experience.
For some reason true learning has to be painful, a pill that
is always slightly too large to swallow.
Nonsense! Learning is fun and good educational software must
entertain.
The BBC Micro has three main areas in helping the programmer
to entertain the user:
• Colour
• Graphics
• Sound
The human brain was originally the brain of a hunting animal
that had to react to changes in shape, colour and movement of
its prey. And we still respond best to such changes.
Anything that you, the programmer, want the user to notice must
stand out as different and exciting.
Most of your software will need a menu and instructions. I suggest
that these are best written in Mode 7, which gives you a lot of
memory space and access to the eight flashing and non-flashing
colours. But you do not have the opportunity to define your own
characters.
Do not print a menu or instructions straight onto the screen.
That's all right for business software, but not for what we are
trying to do.
Build up the menu and instructions over a short period by printing
the menu line by line or even letter by letter. This way the user's
eye follows the build up and he is more likely to take notice
of what you are putting on the screen.
Listing I is a procedure which takes a string of characters,
which could be a whole line, and prints them bit by bit.
1000 DEF PROCMove_letters(A$, Time_delay)
1010 LOCAL X
1020 FOR X = 1 TO LEN(A$)
1030 PRINT CHR$(128+RND(6)) MID$(A$,X,l);
1040 PROCWait(Time_delay)
1050 NEXT
1060 PRINT
1070 ENDPROC
Listing I
To run it you will have to write a short time delay procedure
such as shown in Listing II.
6100 DEF PROCWait(Seconds)
6110 LOCAL Finish_time
6120 Finish_time = TIME + 100*Seconds
6130 REPEAT
6140 UNTIL TIME > Finish_time
6150 ENDPROC
Listing II
Then at any time in your program you can summon up the procedure
by using Listing III.
10 A$ = "Try to work out"
20 B$ = "the number I am"
30 C$ = "thinking of !!!"
40 PROCMove_letters(A$,.1) :PROCMove_letters(B$,.1) :PROCMove_letters(C$,.l)
Listing III
You will notice that line 1030 throws in some random Mode 7
colours for added effect.
This is needed or the user may suspect that there is something
wrong with the BBC Micro if it is printing out letters a little
slowly. It does however put an extra space between each letter
occupied by the hidden colour code.
It is also useful to design a standard double height Mode 7
character procedure. Double height characters stand out and are
very useful for sudden important messages and reprimands, as well
as the more usual titles.
However they can only be used in Mode 7 and can be expensive
on memory, as all text has to be printed twice to get the double
height. A suitable procedure to get round this is shown in Listing
IV.
7000 DEF PROCu(x%,y%,w$)
7010 LOCAL z%
7020 FOR z%=0TO1: PRINT TAB(x%,y%+z%) CHR$141;w$
7030 NEXT
7040 ENDPROC
Listing IV
Words can of course have colour codes and a flashing code built
into them.
With younger users it is often very useful to. take in data
in double height characters. It's easy on the eye and more immediate.
You will have to take each character in individually and then
print it double height.
You will have gathered that any software which produces moving
images and allows the user to play and react to moving images
is going to be much more entertaining than boring old writing.
However, it is perfectly possible with even fairly simple spelling
and Hangman type programs to introduce good graphics. At the risk
of being ghoulish, a winking hanged man will entertain much more
than the creation of a stick hangman.
To produce such winking, all you have to do is define your own
two characters - possibly four - and print the open eye on top
of the closed eye.
All introductions need some warm up graphics. A monster might
escort each letter of the title onto the screen along with the
letter move procedure.
It will put your user into a friendly frame of mind when dealing
with your software. It might even cover up some fairly trivial
learning point which you wanted to reinforce.
If your software involves some interactive graphics between
machine and user have a routine where the machine plays itself.
There is always a time in learning when one wishes to sit back
and watch, and one can learn by watching as well as by playing.
Make your machine seem human. Youngsters relate to the computer
as if it were alive. They get pleasure from beating it - so let
the youngsters win from time to time.
Always get the name of your user and store it for future use.
Perhaps you might like to add a name guessing routine to your
introduction.
This is fun, doesn't take up much memory, and always leaves
the user baffled - if the guess is right. See Listing V.
Sound is almost as important as moving images. It is good practice
to program two sound channels with a friendly and an evil sound.
For every successful data input -even for an individual letter
- play out the friendly sound.
Many children have difficulty reading, or attempt things a little
beyond themselves so as to stretch their learning, and a soft
reassuring sound boosts confidence.
You can always go overboard with whole tunes for success, but
it does involve some quite complex music programming.
The evil sound needs to be no more than a good "splattt"
- enough to wake up the user and encourage a better response.
Sounds add the human touch.
Though all this adds to the user friendliness of your software,
at the final count the software itself must be useful and fun.
No amount of friendly cover-ups will hide bad software. But
I hope that some of the tips here will mean some of you abandoning
pages of screen instructions in Mode 0 and that at least your
software will seem nice, even if it isn't educationally perfect.
7100 DEF PROCName_guess
7110 PRINT"Are you a boy or a girl?";
7120 REPEAT: A$=GET$
7130 UNTIL INSTR("bBgG",A$) <>0
7140 IF INSTR("bB",A$) <>0 THEN PRINT" a
boy": RESTORE 8000 ELSE PRINT " a girl": RESTORE
8500
7150 READ n%: REM number of random names
7160 FOR X = 1 TO RND(n%): READ Name$:NEXT
7170 PRINT'"Is your name "Name$" ? ";
7180 PROCAnswer
7190 IF YES PRINT"I thought so!": GOTO 7230
7200 PRINT"Sorry, my fault, I'm sleepy!"
7210 INPUT"What is your name then ? " Name$
7220 PRINT
7230 PRINT"Nice to meet you "Name$
7240 ENDPROC
7400 DEF PROCAnswer
7410 LOCAL Ans$
7420 REPEAT
7430 Ans$ = GET$
7440 UNTIL INSTR("YyNn",Ans$) <>0
7450 IF INSTR("Yy",Ans$)=0 THEN NO=TRUE: YES=FALSE:
PRINT" No" ELSE YES=TRUE: NO=FALSE: PRINT" Yes"
7460 ENDPROC
8000 DATA10
8010 DATA MIKE
8020 DATA PETER
8030 DATA ALAN
8040 DATA DAVID
8050 DATA LEROY
8060 DATA JUNIOR
8070 DATA JOHN
8080 DATA JAMES
8090 DATA IAN
8100 DATA GRAHAM
8500 DATA 10
8510 DATA SUSAN
8520 DATA MARY
8530 DATA LORRAINE
8540 DATA DEBORAH
8550 DATA JOAN
8560 DATA ERICA
8570 DATA NORMA
8580 DATA BETTY
8590 DATA BETTY
8600 DATA LIZ
Listing V
