QBasic Gorillas

Today I’m looking at the classic old artillery game Gorillas, it was an example program for the Qbasic interpreter that was packaged with MS-DOS 5.0 and later. Because it was so widespread, being on practically every machine of its time, it was widely played and loved by many. I first encountered it on our high school computers in computer studies classes, we often got to play some games after we finished our work. We played many games, but Gorillas  (and Nibbles) were favourites.

Dancing Gorillas!

Being written in Qbasic graphics and sound support is fairly basic. Unless you’re using an old machine with CGA only, the graphics are in high resolution EGA (640x350x16) and whilst not spectacular have some charm. Sound is PC speaker, again largely due to the limits of Qbasic. Most sounds are fairly basic, although the intro tune is kinda cool.

City Skyline

The game field consists of a city skyline with two Gorillas atop a building at opposite ends of the screen. Each Gorilla takes turns hurling an explosive banana at the other, with the player aiming the shots by entering the angle and velocity. The round only ends when one of the Gorillas is hit by a banana, with the survivor being the winner. There was no computer AI, so you had to play it in a hot-seat style or on your own. It’s simple and fun to play, although there isn’t much variety.

Target hit!

Normally this is where a post like this would end, with some kind of summary of what I thought. Today however I decided to have a quick go at making a simple modification to the game, adding an AI to the game so you can play solo. The tricky part with making an AI player in this case isn’t making something that will play well, but making something a human has a chance of beating. I could quite easily make it simply calculate the ideal velocity and angle, but that wouldn’t be much fun.

A winner is you.

So what have I done instead? It’s a fairly simple algorithm, I set the initial aim to some sensible defaults and after each shot adjust the velocity depending on whether the shot landed short or long. This actually proved to be quite good at making hits, but not before making a few shots giving a human player a chance. Occasionally they will make a hit on the first shot, but that only happens when the buildings are set up just right. One circumstance that the computer does poorly is when a tall building is blocking the path of the bananas. I deal with this to a degree by making the angle higher when the banana doesn’t go very far. It will still take many shots for the AI to succeed.

I’ve made the modified version available here. It requires the original Qbasic to run and DOS in one form or another (Dosbox recommended). The game is pretty much unchanged apart from adding the AI, which you activate by naming a player Computer. You can have the computer play itself by naming both players Computer. Another improved version of the game exists, and has improvements such as a league table and improved graphics and sound. It’s called Gorillas Deluxe and can be found here.

Amstrad NC100 Laptop

Amstrad NC100

Today I’m looking at one of the micro computers in my small collection, the Amstrad NC100 laptop. It was released back in 1992 arguably after Z80 machines were no longer relevant. However because it was small and inexpensive it sold quite well because PC laptops of the time were quite expensive.

The machine is faster than other Z80 portables of similar vintage running at 6Mhz! It has 64K of battery backed up RAM which can’t really store all that many programs or data. Fortunately the built in software is quite good for basic tasks such as word processing and managing a diary and address book. The built in RAM can be expanded with PCMCIA SRAM cards and I am fortunate enough to have the maximum upgrade in the form of a 1Mb card, now if only I could get a 2325 battery to replace the dead one in it.

Expansion Card

You can transfer files to and from the machine using XModem transfer over serial. The machine was frequently used by journalists in the field to write documents and be able to submit their reports via modem. It’s also useful for transferring programs to the machine or to PC for backup. There is a serial terminal built into the ROM so it could be used to access BBS services or act as a terminal for a larger machine.

The machine has BBC Basic on it, which was one of the better interpreters of the micro computer era. There are a number of statements that don’t work however, but it’s all fairly well documented which is fortunately available online. A number of people have developed different games and applications for it. The interpreter is of course not as fast as machine code, so if you know Z80 assembler that’s a better way to code for the machine.

It uses standard AA batteries and has quite a generous running time on a fresh set. The display is a simple 80×4 character text LCD with graphics capability, so the screen doesn’t use up tones of juice. It can be a bit hard to read depending on the light, but there is a contrast control to help make it more readable. The keyboard is a bit mushy, but quite usable and certainly better than some of the really cheap keyboards around.

I found the Amstrad NC100 a fascinating machine to use. It’s built in ROM makes creating documents and basic organiser functions quite easy, and the program-ability of BBC Basic makes it quite versatile. It is however quite limited in many aspects such as the display and amount of memory, but for the time it was one of the best portables around. I got mine of Ebay some time ago, and I frequently use it as an easy to store and use serial terminal for my bigger Sun machines. I would like to own a NC200 for the larger screen and floppy, but those appear less frequently at a price I’m willing to pay.

Some pages that would be interesting to owners of the Amstrad NC100/NC200

Tim’s Amstrad User Site

Tear-down on EEVBlog for repair

Finally as it is that time of year, I’d like to wish everyone a happy holiday season, which-ever holiday it is that you celebrate.

Trap for gwbasic

On a personal note, I recently became a dad again for the second time! So I’m quite tired and may not be very good at writing something intelligent, and todays entry will be short. The game I’m talking about today is called trap, and was written by Bruce Brandt in 1993 from what little information I could find on the internet. It was written in gwbasic and is now freeware. The game has no story, and is pretty basic. You move around a grid of rotating doors and your task is to trap the monsters that are travelling around in as little time as possible. Monsters will randomly teleport if you run into them directly or if you push a door into them. It’s surprising fun in short bursts in the same way that minesweeper is. Once you figured out the best ways to trap the monsters you can get you time down quite quickly. I was able to finish the game in about a minute at best but usually take about 90-120 seconds. You’ll find that it gets more difficult based on where the monsters start. If you find a monster at the edge of the map, it’s often a lot easier to force the monster to teleport than to try to trap him where he is. Some times the starting position of the doors can be a hinderance, but you can usually get around this. Running the game is pretty easy if you’re used to running programs in gwbasic, but there is also a pre-compiled DOS version around as well. It’s quite a difficult game to locate on the internet these days, but if you search for the author’s name and the word trap you should be able to locate it within an old BBS archive still around on the internet. I originally got it from a shareware disc from a magazine that my older brother bought so searching along those lines may also help.

The instructions for the game.

High scores

Game play screen

Gwbasic – my first programming language

Gwbasic holds a lot of fond memories for me. I was about ten when dad gave me a book about programming in basic, and our computer, a 386SX with dos 4 on it, had gwbasic on it. The book I got was actually not even for the right platform. It was called 30 hour basic and was written for the BBC micro, I was fortunate in that it didn’t use any of the advanced features of the beeb, and that gwbasic supported everything in the book. I breezed through the book, typing the programs in, then trying my own variations on how they worked. Most of the programs were simple and there were basically no games in it. My imagination however was sparked, I instantly wanted to be a programmer and to write computer games, but learning to do this in gwbasic and with very little in the way of assistance from books or anything else was a bit of a journey.

For starters, there were no block if statements, or easy to use editors. Gwbasic used the same system of writing programs that the old microcomputers of the 80’s used. This meant typing in a line number and the code that you wanted, without being able to easily reference previous code. User definable functions and procedures were limited to what you could type on a single line, so I very rarely used them. I often used gosub and goto to accomplish the tasks I needed. This often led to a well know problem with basic programs. Spaghetti code! None of these things deterred me from writing and experimenting. I had found that there were shortcut keys using the alt key in combination with a letter to produce a keyword. I basically tried a combination of different things until I had worked out the syntax of the command. I very quickly learned enough to produce simple ascii games, that were usually often attempted clones of other games.

Numdrop gamplay

One of the first I made was called numdrop. It was meant to be a sort of clone of tetris, but being a kid I wasn’t yet good enough to make something as complex as tetris. So I came up with the idea that there would be single blocks falling like in tetris, but instead of having different shapes, I would have different weighted blocks. Larger blocks would crush smaller ones and earn you  points. My older brother helped me, by finding a timer function that allowed accurate timing for the speed of the game. As the levels progressed you had more blocks before the end of the level, and the game speed would increase.

Jump gameplay

Up until this point the most I could do with the graphics was draw lines and circles using the basic drawing commands available. Then my dad bought us the gwbasic reference manual, now I had the power! Reading the manual lead to the ability to use bitmap graphics, which as you probably know are important for games. I rigged up a simple sprite creator that basically had you entering the colour of each pixel by number, and created my first proper graphical game, Jump. It was a simple single screen platform game where you had to avoid a green monster, and a missile that would come out from it. The gameplay wasn’t great, but as a proof of concept that it could be done it worked a treat. This really was the starting point for me, now I could write proper games.

I even started to write a windows clone of sorts, called farout. This was quite an ambitious project, and I did manage to make the basics of it. It worked by having a set of routines and variables that were basically a template for each program I wanted to make. The programs would use the chain command to switch from program to program, so no multitasking was possible. A program could save it’s state before chaining back to the main program, allowing some simple windows like functionality in that you could suspend a program for use later. I even created a boot disk that automatically started it. The loading and switching of programs proved to be a little slow on floppy disk, the medium I was using the most at the time. So I whilst the base system was completed, I never really wrote many applications for it.

Gwbasic had limitations to the size of the data and code combined. It was about 60300 bytes if I remember correctly. This was only because of how the interpreter was written, the memory model it used could not take advantage of more than 64Kbytes of ram. programs were stored in memory in the form of tokens in a binary format that saved a lot of memory. 64K may not sound like much but you could do a heck of a lot with it! When it came to graphics however, and storing a lot of sprites for a more complex game, the memory was not really enough. I was beginning to want to build larger and more complex games, and upon starting them found I didn’t have enough room. This is where I stopped developing for gwbasic as a kid, and moved onto qbasic which had come out with the newer versions of DOS, and was on the computers at school.

I still have all the old programs that I wrote as a kid, and I occasionally go back to them from time to time. Recently finding one of my old games had suffered data loss (fortunately nothing else was lost)  I began to re-write it as an ascii art game. After having moved to more professional and higher level languages, programming for gwbasic was a bit of a strain on the memory. I never did this as a kid, but I’ve found keeping a running documentation of the program as you develop it helps immensely. Especially as you can’t label subroutines with sensible names. The challenge and power of the language to keep my interest has not faded, and as I write this I’m entertaining ideas of what I could squeeze into it. Stay tuned, I may fix up and release some of my code here. If you have any experiences with gwbasic, please comment bellow, I’d love to hear how others experienced the language.

Jump gameplay

Digger Clone

Numdrop gamplay