NOWOTNIK PUZZLE
by David Nowotnik
from ZX Computing Jun/Jul.1985

A PUZZLE FOR THE QL
- by David Nowotnik


[The accompanying file NOWOTNIK.BAS is in MS-DOS format,]
[ie. CR+LF at the end of lines; whereas Nowotnik_bas is ]
[in QL format, ie. LF at the end of lines.         JimG.]


The first few months of existence for the QL have not been
happy ones. The computer and its producer have deservedly
received a lot of criticism from the computer press. But now
that many of the 'rough edges' have been smoothed, the QL is
beginning to fulfil all those pre- launch promises made for
it. The QL will be a big seller, and, no doubt, many
Spectrum owners will be making the transition to the QL. To
help with that transition, this article will be offering
advice to Spectrum and ZX81 owners to adapt to SuperBASIC.
And, for QL owners, there is a 'serious' game to play on
your 'serious' home computer.

In the same way that the BASIC of the Spectrum was derived
from that of the ZX81, so does QL's programming language owe
much to its predecessor. I'm sure we'll see yet better
versions of BASIC in the future, but SuperBASIC deserves its
name by present day standards. Spectrum owners may care to
glance at the program listing in this article; many
structures may look familiar, but SuperBASIC also has much
more to offer. Particularly notable are PROCedures, and
here's why -

Procedures are similar to subroutines, but there are enough
differences to make them much more powerful. Procedures work
on their own set of variables (although you can pass
variables to and form PROCedures in the normal way). Using
the LOCAL command, you can identify those variables which
are used within the PROCedure. Even if they are identical in
name to variables within the main routine or other
procedures, use of the LOCAL command keeps them quite
independent. This leads to an interesting and powerful
possibility. You can readily build up a library of
PROCedures. You need only know the input and output
variables, and, of course, the purpose of the PROCedure, and
your PROCedure can be slotted into any program in which it
might be required. And the QL's powerful line renumber
facility can replace the PROCedure to any position required
in a program.

You call a procedure simply by using its name. Hence, in my
program, when you see 'init' or 'set_up' in a program line,
these are effectively new commands calling the procedures of
that name. Even when the program is not running you can call
a procedure by typing in its name - as you would a direct
command.

The use of PROCedures, and some of SuperBASIC's other
constructions, encourage what is commonly called structured
programming. A simple way of looking at this is that GOTOs
and GOSUBs are excluded (although the QL still has these if
you really must use them); the aim is to make programs more
'readable', making them easier to understand and debug.

The strategy of program writing in SuperBASIC is quite
different to Spectrum BASIC. You aim to build up a series of
PROCedures, each being a distinctly independent new command,
which you can test and de-bug, before moving onto the next
PROCedure. The program is then brought together by calling
these new commands in the correct sequence. See if you can
spot that design in my program. Even if you can't see that,
one thing for sure - in the true spirit of the QL,you won't
see any GOTOs or GOSUBs!

The main ways by which you can avoid using GOTOs are in the
modified format of IF ... THEN, and the new command of
SELECT. You'll see both in my program. You can use IF ...
THEN in the same way as on the Spectrum, but you have a more
powerful option of IF ... THEN ... ELSE ... END IF. To use
this form of the IF command, start with the line:

IF condition THEN

Put nothing after the THEN; you can place several statements
on any number of lines after this line, and all will be
carried out if the condition is met. If you want to have
some instructions if the condition is not met, then the ELSE
command follows next. Again, you can have several program
lines following ELSE, all of which would be carried out if
the original condition was not met. Finally, to inform the
computer that you have come to the end of the IF structure,
use the command END IF (for an example, see lines 800 to
830).

Examples of SELect appear in lines 5550-5650 and 8000-8120.
SELect enables the value of a variable to be tested, and
various actions to be performed as a result of that test. In
line 5560, the first statement '= 1' effectively means 'if
the variable move_one is equal to one then ... '. As with
the IF command, you could have several lines of options if
you wish before testing another value of the variable. You
even have an ELSE equivalent with SELect. You can say ON
REMAINDER, and have several program lines on what to do if
the variable does not have any of the previous values
tested. SELect is a more powerful variant of the IF command.

Other features you may spot in the listing are the two types
of loop structure. FOR ... NEXT is one you'll know from
Spectrum BASIC, but REPEAT may be new to you. An example
appears in lines 50 to 110. The end of the REPeat loop
appears in line 110. The loop is given a name (in this case
'demo_option', and the loop is ended with 'END demo_option'.
You can go around this type of loop forever if you don't
have some exit possibility. With a REPeat loop, to exit the
loop a condition normally has to be met (see line 70 for the
construction). The EXIT command effects a GOTO, to the line
immediately following the END REPeat.

While I blandly said Spectrum owners will recognise FOR and
NEXT on the QL, there are modifications which can make the
QL version more powerful. These are EXIT and END commands,
similar to those for the REPeat loop.

All the preceding explanations of QL commands should make my
program listing reasonably clear to Spectrum users, but
there remains one more item to explain before I describe the
program itself. In use, the program will demonstrate the
powerful WINDOW, SCROLL and PAN commands of the QL. By using
WINDOW, you can identify to the computer a specific area of
the screen, which you can control in many ways quite
independent of the rest of the screen. For instance, you can
print to that window, SCROLL or PAN the window, or change
the colour of that window. Lines 1070 to 1110 re-define the
shape and colour of two of the windows which are 'provided'
by the computer when it is switched on and lines 1120 to
1240 define 13 new windows which are used in the game. The
window is identified by the # number; this is the channel
which 'communicates' to that window. The initials 'scr_'
indicate that the device you are aiming that channel at is
the screen, and the numbers which follow those initials
define the width and height (in pixels) of the window, and
the position on the screen of the top left-hand corner of
that window.

SCROLL is a command which appeared on the ZX81 , but
disappeared on the Spectrum. The much more powerful version
on the QL allows a window to be SCROLLED up or down, and by
a specified number of pixels (for examples, see lines 7140
and 7640). SCROLL can be modified further to SCROLL only a
specified number of rows of pixels within a window. The
command PAN allows the specified window to be SCROLLed
either left or right.

You will notice quite a few REM statements in my listing.
This is quite deliberate, for the following reason. One
disadvantage of PROCedures compared with GOSUBs is that the
former can be used anywhere in the program. So can a GOSUB,
of course, but not without a line number to identify its
place in a program. So, to make the QL program easier to
read, I have identified the start of each PROCedure with a
double row of stars, with the name of the PROCedure about to
be defined held within the stars. You should do something
similar if you want your QL programs to be readable.

And now, at last, the program itself. For me it has a short
history, and you may be interested in the story behind the
game. It originated three years ago when, whilst teaching
myself Z80 machine code, moving blocks of characters around
the screen developed into a game idea. What resulted was a
mixture of the Rubic Cube, and a sliding puzzle. It was the
similarity to the former which inspired a friend to nickname
the program after myself, and that name stuck when the ZX81
version was marketed by a software house. I went on to
produce commercial versions, bearing the same name, for the
Spectrum and Oric Atmos. This is my first version for the QL.

When you RUN the program, you will get a choice of options,
for a demonstration, or to play the game. The demonstration
will show you the starting (and finishing position) of the
puzzle, and the way in which it is shuffled, for you to
return to its original orientation.

The puzzle appears as a large square on the screen, which is
divided into four smaller, coloured squares of red, yellow,
blue and green. If you watch the shuffling movement
carefully, you should notice that there are 8 possible ways
in which the puzzle can be moved. Imagine that you can
divide the puzzle into two equal halves, both horizontally
and vertically. This gives you 4 possible 'halves'. The
movement of these halves involves sliding a half in the
direction of its longest side. As each half could be moved
in one of two directions, there are a total of 8 ways in
which parts of the puzzle can be moved. In sliding half of
the puzzle, the piece which 'falls off' the edge of the
puzzle re-appears on the opposite side.

The same eight movements are used to solve the puzzle. On
the screen, you will see numbers and arrows. The numeric
keys 1 to 8 are used by you in solving the puzzle. The
arrows show you which number will move which half, and in
which direction. The object is to re-form the original four
large squares and place them in the same arrangement they
were in prior to shuffling. At the top right of the screen
you will see a miniature version of the final arrangement of
squares, to remind you of your aim in solving the puzzle. A
checking routine is built into the program, and you will be
informed when you have successfully solved the puzzle, and
how many moves it took you. Unlike the commercial versions
of this program, this version has only one level of
difficulty, so once you develop a strategy for solving the
puzzle, your aim must be to minimise the number of moves
necessary to solve it.

This version also differs from commercial versions in that
it is written entirely in BASIC. This is achieved by using
the QL's enhanced BASIC facilities, particularly SCROLL and
PAN in pre-defined windows. I hope that the program is
sufficiently well documented to allow it to be understood
without a detailed description of how it works. After all,
'readability' must be one of the aims of all programmers
switching to QL's SuperBASIC.


-- end of file --