Nowotnik Puzzle

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 --