No Fragments Archive 10: Diskmags/nf_archive_10.iso/MAGS/ST_USER/1990/USEROC90.MSA/TEXT_STOS.DOC

Text File | 1990-08-19 | 7.8 KB | 160 lines

                             HAVING A BALL


         Phil lawson takes a break from programming to give you the
           bare bones of a game. It's up to you to finish it off


    One of the hardest parts of writing a game is getting the ideas in the
first place and if you can't get past this point you might as well give up
before you start. STOS is best suited to arcade and strategy games, but it's no
use trying to write an 'if it moves, zap it' game if you haven't planned all
the different screens, levels and features. Strategy games can be cobbled
together as you go, as most extra features can be written as self-contained
subroutines, but some overall plan is needed at least.

    Over the past couple of months we've discovered how to bounce sprites
around the screen, and in particular, off various obstacles. You may have been
wondering where all these tricks and methods were leading, in which case your
question is answered this month.

    What I've done is to write the main controlling loop of a strategy game,
but it's up to you to finish it off. This should put your programming skills to
the test, so you can monitor your own progress.

    Anyone familiar with the old 8-bit game Gate Crasher will recognise
STOS.BAS in the LISTINGS folder. The object is to drop a ball from the top of
the screen, which then travels along the platforms, drops through holes and
finally ends up in one of the eight slots at the bottom. Dotted around the
screen are deflectors which will change the ball's direction.

    To position the ball use the left and right arrow keys and drop it with the
spacebar. The game will automatically end when each slot contains a ball.

    The original version of the game had many features, some of which are:

SHUFFLE
SCROLLING
LIMITED BALLS (20)
BLANKED OUT PLATFORMS (only the deflectors showing)
BLANKED-OUT DEFLECTORS ON HIGHER LEVELS (only the platforms showing)
HAVING TO PUT THE BALLS INTO THE SLOTS IN A DEFINED ORDER

    What you should try and do is add some or all of these to the original game
- I have provided the bare bones of the game, but it is up to you to add the
frills. You could also devise a few of your own, and maybe the best one sent in
will appear on a future cover disk.

    The whole program hinges on the bouncing techniques covered in the past
couple of issues, so if you haven't got them order some back copies now! Just
to recap, the hot-spot of the ball is placed smack bang in the centre, which
means the dimensions of the ball have to be an odd number of pixels, otherwise
there would be no centre position.

    Using the POINT command, we can test the colour of the background screen
immediately under the hot spot, which tells us of the ball has hit anything. If
it has, we now define four points around the hot spot, (as shown in Table II),
and use these to check what type of object has been hit. Since we know the
direction in which the ball was originally moving, and we now know what type of
object it has met, we can easily work out its new direction.

           p2- *   * -p3

                 * - hot spot

           p1- *   * -p4

    If the coordinates of the hot spot are X and Y, the coordinates for each of
the four points are:

p1 = X-1,Y+1
p2 = X-1,Y-1
p3 = X+1,Y-1
p4 = X+1,Y+1

    Now for a brief rundown of the main control loop. The initialisation
routine at line 500, sets up a few variables and two animation strings to give
the ball the appearance that it is actually rolling. The array slot(8) stores
the status of each slot at the bottom of the screen. If, for instance, slot(3)
equals 1, a ball is already present in the third slot, but a value of zero
would mean it was empty.

    Before dropping a ball, the player first has the choice of where to
position it along the top of the screen. This is handled by the routine
starting at line 8000.

    When the ball drops one of two things will happen. It will either fall onto
a deflector or a platform. These possibilities are checked for in the Drop Ball
routine at 7000, which also calculates the new direction. If the ball lands on
a platform it will retain its original direction until either it reaches
another hole to fall through or it hits a side wall, in which case its
direction is simply reversed. This is controlled by the Hit Wall routine at
line 1800.

    The routine at 1100 is used whenever a ball is about to drop into a slot.
It checks whether a ball is already in that slot and if there is, that slot now
becomes empty which means you'll have to fill it again. The final part of this
routine tests for a ball in each slot and sets the variable 'done'
accordingly.



                     FEATURES TO BE ADDED
                    **********************

BALLS - The original game only allowed 20 balls to be used, which meant you had
to think very carefully before dropping one.

SHUFFLE - Causes between 50% and 75% of the deflectors to be changed. For
example, if a deflector was / it would possibly be altered to \. This feature
reduces the number of balls left by one.

BLANKED-OUT PLATFORMS - Only the deflectors and bottom slots are shown. The
positions of the platforms and the holes in them have to be worked out by
watching where the ball goes. Should be used only for higher levels.

BLANKED-OUT DEFLECTORS - Everything is shown apart from the deflectors, so the
angles, (/ or \) will have to be worked out by watching which way the ball
moves. Should be used on levels higher than those with blanked-out platforms.

DEFINED ORDER - The balls must be placed into the slots in a predefined order.
To indicate the order, display the values 1 to 8 in each slot, where 1 must be
the first filled slot and 8 must be the last. Should be used on medium levels.

SCROLLING - This is by far the most impressive featue of the original game, but
is also the most difficult to implement. By using the up and down arrow keys
the playing area would scroll, allowing you to position the deflectors and
platforms so the ball could get to the more difficult slots. Unless you've seen
the original game, this scrolling can be rather difficult to explain, but I'll
try my best. Take a look at Picture 1:

PICTURE1.PC1:<<SCREENSHOT>>

    This shows the original screen, (1) along with the resulting screen layout
after each upward scroll. Notice the + marks, which show the lines where
deflectors may have to be altered when scrolling upwards. This is done by
checking the area directly above and below each deflector positon. If the above
one is empty and the below one is part of a platorm, a deflector is required in
that position so put one there if one isn't already present.

    If a deflector is not required, blank out that part of the screen either by
using the BAR command to draw an empty block, or use a small sprite and PUT it
on the screen. Note that both of these will require another colour other than
zero to be defined as black, otherwise your block/sprite will be treated as
transparent.

    The rules for scrolling down are exactly the same, except it's the top two
lines and the bottom one which will need the deflectors altering. To actually
scroll the screen, don't forget to copy the top/bottom part before you
overwrite it. This can easily be done with the SCREEN$ command, which can be
placed back again afterwards.

    I have now given enough information for you to start working on your
masterpiece, but you don't have to stick to the features outlined here. Try to
devise some of your own, and the more devious the better for the higher levels.
Also feel free to alter any of the graphics, and try including some of the many
techniques we've discovered in the past.

    That just about wraps it up for this month, and since my ST is back in
working order I'll get the Sprite Path Definer program finished for next time.