Alby, the albino bat

Copyright © 2017 by Víctor Parada


This is a little game for the 2018 NOMAM's BASIC 10-liners Contest. This program fits in the PUR-80 category, and it was written using TurboBASIC XL for the 8-bits ATARI XL/XE.


Do your sonar trick and fly through the cave avoiding to hit the stalactites and stalagmites.


Alby start Alby is inside a cavern and needs to exit for food. Scan the surface of each cave with the sonar.
Alby flies Use the joystick button to flap the wings. Press to move them down and release to move them up. The only way to stay flying is by flapping continuously. Flaps rapidly to ascend, slowly to descend.
Alby avoids obstacles Fly to the other side of the cave avoiding the stalactites and stalagmites.
Alby height The starting height in a cave is the same that the one you left the previous one.
Albi score and lives The left number at the bottom of the playfield is the number of the cave, the rigth one is the number of tries left. You'll earn a bonus try at the end of each cave, with a maximum of 5 tries.
Alby gameover The game is over when no more tries are left.

Development of the game

Gravity effects are common in phone and tablet games, so I wanted to recreate one of them in my Atari. Some time ago, I saw one of my sons playing a game with an horizontaly scrolling playfield and he only has to tap the screen to change his vertical direction movement and to avoid obstacles. In another game, the player only has to tap the screen to go up, while the gravity takes you down the rest of the time. This was the concept I wanted to try.

I had two alternatives: to scroll the playfield horizontally in a smooth way and to move the player through a playfield horizontally. To move a playfield horizontally requires a huge buffer with the screen elements on it, or to use all the players and missiles to build the obstacles and move them through an empty screen. As I was trying to write a very short program for the PUR-80 category, it seemed easier to move a single player through a static playfield.

Atari games look more attractive when played in a black background, so I immediately thought about caves and that leads to stalactites, stalagmites and, of course, bats.

The first step was to create a playfield. My first try was to create a simple low res set of random heights of stalactites and stalagmites, with some of them using most part of the screen height creating a kind of barrier or obstacle. I did that using graphics mode 5 (80x48 pixels) and the result was not as fast as I expected, and it was also ugly.

Then, I tried to build an attractive playfield, so I changed to hi res graphics to draw sharp stalactites with a litle of 3D effect, using graphics mode 15 (160x192) and 2 colors to simultate a lighter and darker side of the obstacles. The result was nice, but it also used more code.

ALBY prototype 1

Low resolution cave

ALBY prototype 2

High resolution cave with shades

The next step was to include the bat. It would be implemented using only one player, so I create the bitmaps for the character in the two positions required to animate it: wings up and wings down. After that, I added the horizontal movement to check if the speed would be nice to play.

ALBY prototype 3

Design of the bat

ALBY prototype 4

Moving the bat at a constant speed

The next step was to add the routine to animate the bat: while the bat is moving to the right, it is also descending, but pressing the joystick button made the bat to flap its wings and to go up a bit. Not so real but I liked it. Well, make it real. Let the bat go in free fall. Wow! That was too fast! I just increased the vertical delta value for every horizontal step and got something like a parabolic movement. When the button is pressed, the free fall is stopped and the vertical heigh is increased a bit. By pressing and releasing thge button quickly, the bat could be moved up, by doing that slowly it could be retained almost stable, and it would fall if the button is not pressed again.

ALBY prototype 5

Bat is planning, going down slowly

ALBY prototype 6

The bat in free fall!

It was time to check when the bat hits a wall, and it could be easily done by checking hardware registers to detect P/M collisions. OK, we have a game, but a way to make it increase the difficulty was required.

ALBY prototype 7

Enabling collision detection

The original idea was to make the space between stalactites and stalagmites smaller on every new cave, but it got borring and needed another degree of difficulty. Adding more obstacles in the cave could be the solution... or a mix of both.

The game started with 1 obstacle in the first cave, then 2 in the second one and 3 in the third. Then 1 obstacle again but with less space to go through it. Still borring! Well, change to 2, 3 and 4 obstacles. Ouch! With 4 it was impossible to go to the end of the cave when one path is on the bottom of the screen and the next one is on the top, as the distance between them should be reduced.

As I was using a data table to store the stalactite numbers where an obstacle must be put, I changed the number of caves from 3 to 4 before repeating them, and made the stalactites appear in other sequence: 2, 2 closer ones, 3 and 3 closer ones.

ALBY prototype 8

Reorganizing the obstacles of the caves

I was checking the file size during the development and I was very, very, very near to the max 800 bytes allowed for the PUR-80 category, and there was no room for the final thing I had to add: the sound (SFX). This required me to reduce the number of statements, removing some unnecessary things. Fortunatelly, I discovered that the table with the position of the main obstacles could be replaced by a formula to save some bytes. I had to change the way stalactites and stalagmites were painted to let the code fit the 80 columns requirement. Since then, stalactites and stalagmites have their own solid color.

ALBY prototype 9

I had to simplify the design to make room and add sound

ALBY prototype 10

Solid colors for stalactites and stalagmites

I programmed this game using a text editor in my PC, and used Altirra to test every new version in the abbreviated form, which I created using my own utility for that purpose. When the game was ready, I tried it using a real Atari and found a "little" problem: it was too difficult to press the button in the joystick so many times and quickly. One possible solution was to change the joystick button by the START key in the Atari, but it was impossible because there was no more room to add a couple of bytes and accomodate the source again.

I called this game as "Bat's Cave" until it was almost ready, but as the bat couldn't be black in a playfield of the same color, I made it gray as it could be seen in some screenshots. I tried to invert that: black bat over a brown playfield, but it was an ugly combination. I finaly set the bat as white, and that made me to change the name of the game: "The albino bat's cave". The final name was to make it more friendly.

This game was written in May of 2017, and I waited the rest of the year for the announcement of the 2018 edition of the contest. It came by the end of January with a big surprise: NEW RULES. From this edition of the contest, only stock version of BASIC must be used in the PUR-80 category. That means that Atari BASIC is the only dialect that can be used in the smallest of the categories. As I won't change the program, it could be sent as an entry for the PUR-120 category, running at a disadvantage compared to other programs written in TurboBASIC XL. Anyway, I added to the disk a modified version of the game that uses the START key instead of the joystick button, and it still fits the PUR-120 category.

Return to my 10-liners page.

© 2017-2018 by Víctor Parada - 2017-05-22 (updated: 2018-02-08)