The story of GORILLA.BAS, the MS-DOS artillery game that taught BASIC

Before coding bootcamps, browser sandboxes and cheerful online tutorials with badges, there was a blue screen, a blinking cursor and a pair of gorillas throwing explosive bananas over a pixel skyline. GORILLA.BAS was not a big commercial game, not a boxed release, and not something most people went looking for on purpose. It arrived quietly with QBasic in the MS-DOS 5 era and became one of the strangest programming lessons ever shipped with a mainstream operating system. On paper, it was simple. Two gorillas stood on top of buildings. Each player entered an angle and a velocity. A banana flew through the air, obeying gravity, wind and the rude geometry of the city. If it hit the other gorilla, the round was over. If it hit a building, it blew a chunk out of the skyline. If it missed completely, the other player had a turn and probably made a comment about your maths. That was the whole game. It was also the point.

A small game with a clever job

GORILLA.BAS was included as a sample program for QBasic, Microsoft’s beginner-friendly BASIC environment that came with MS-DOS 5. QBasic replaced some of the older BASIC workflows with a cleaner editor, structured programming features and a less frightening way to run and modify code. The sample programs were meant to demonstrate what the language could do. GORILLA.BAS did that by pretending not to be a lesson.

It showed graphics, sound, input handling, loops, conditional logic, arrays, random numbers and subroutines. It also showed basic projectile motion, although no child ever said they were studying projectile motion. They were trying to hit a gorilla with fruit. Education always works better when it is wearing a silly hat.

The game’s strength was that it gave every line of code a visible consequence. A skyline appeared because the program generated buildings. The gorillas moved because sprite data was placed on screen. The banana curved because maths was being calculated step by step. The explosion removed part of a building because the program redrew the world after impact. This was not theory in a textbook. This was cause and effect with fur.

The joy of editable software

Modern software often arrives as a polished surface. Tap here, swipe there, accept the update, do not ask what is inside. GORILLA.BAS belonged to a different world. The game was source code. Opening it did not reveal an asset folder and a legal notice the size of Luxembourg. It revealed BASIC code that a curious user could read, ruin and repair.

That mattered. A player could start by playing the game and then accidentally become a programmer. Maybe they changed the gravity value. Maybe they adjusted the explosion size. Maybe they made the buildings taller, the bananas faster or the sun easier to hit. Maybe they introduced a bug so bad the gorillas stopped appearing and the whole city looked like a spreadsheet having a nervous breakdown. This was not a failure of the lesson. It was the lesson.

Programming is not learned only by following instructions. It is learned by building a mental model of what the machine is doing. GORILLA.BAS invited that process because it was small enough to explore and entertaining enough to reward the effort. You could scroll through the code, recognise the names of things, and connect them to what happened on screen. The distance between idea and result was short. That is a powerful teaching tool.

Skyline maths and banana physics

At the centre of GORILLA.BAS is a neat little physics problem. The player enters an angle and a velocity, and the program calculates the banana’s path. Gravity pulls it down. Wind affects its horizontal movement. Buildings interrupt its journey. The screen becomes a coordinate grid, only with more property damage.

This made the game more than a guessing contest. Players learned by trial and adjustment. Too low, and the banana slapped into the side of a tower. Too high, and it sailed away like it had an appointment in another postcode. Too weak, and it fell sadly between buildings. Too strong, and it left the battlefield with the confidence of a banana that had read too much science fiction.

The city skyline made every round slightly different. Randomly generated buildings changed the tactical problem. A shot that worked in one round might be useless in the next. This was a simple way to show procedural generation before most users knew the term. The city was not hand-drawn. It was made by rules. That idea is everywhere in games today, from terrain systems to roguelikes to endless runners, but GORILLA.BAS made it understandable in a few screens of BASIC.

A programming lesson disguised as playground violence

The premise was ridiculous in exactly the right way. Two enormous gorillas are standing on rooftops, resolving a dispute with explosive bananas. There is no backstory. No campaign mode. No moral dilemma. No downloadable hat pack. Just turn-based artillery and a skyline unlucky enough to be in the middle.

That simplicity gave the code room to be understood. There were no complex assets, no 3D pipeline, no networking layer and no physics engine hidden behind a library call. The logic lived in the program. For a beginner, this was important. You could trace the game from input to calculation to output. You could see where the banana was created, where it moved, where it collided and where the explosion happened.

Many educational programs announce themselves too loudly. They arrive wearing a badge that says learning activity and immediately drain the fun from the room. GORILLA.BAS did the opposite. It gave users a game first. The programming lesson was waiting underneath, like a trapdoor with syntax highlighting.

Why it worked on school and home PCs

GORILLA.BAS spread because MS-DOS spread. In the early 1990s, IBM-compatible PCs were common in homes, offices and schools. Many users discovered QBasic not as a professional development environment, but as something already sitting on the machine. That was crucial. There was no purchase decision, no installation ritual and no need to convince a parent that a programming language was a sensible use of money.

The game also worked well in shared spaces. Two players could take turns at one keyboard. It was competitive, quick to understand and just technical enough to feel clever. In computer labs, it had the ideal shape of trouble: educational enough to defend, entertaining enough to distract everyone. A teacher could say it demonstrated programming. A student could say the same thing while absolutely not studying.

It also ran on modest hardware. The visuals were basic, but clear. The sound effects were simple, but memorable. The skyline and gorillas did not need realism. In fact, realism would have ruined it. A photorealistic gorilla throwing a photorealistic explosive banana is not an educational game. It is a health and safety investigation.

The open-code experience

One of the most important things about GORILLA.BAS was not the game design but the delivery method. Because it was a BASIC file, users were encouraged to open it in the same environment used to run it. The edit button was practically part of the gameplay loop.

That meant users could learn in layers. First, they played. Then they changed obvious values. Then they looked for the code that controlled a specific behaviour. Then they began to understand structure. A beginner might not know what a subroutine was, but they could see named sections of the program doing different jobs. One part handled the intro. Another drew the city. Another moved the projectile. The vocabulary of programming became attached to visible effects.

This is still one of the best ways to teach code. Start with something complete. Let the learner change it. Let them break it in ways that are recoverable. Give them feedback that is immediate and slightly funny. GORILLA.BAS did all of that with a file small enough to feel approachable.

A cousin to today’s coding toys

Today, beginners often meet programming through Scratch, MakeCode, browser-based Python editors or game engines with visual scripting. These tools are more advanced, more accessible and much friendlier than a DOS prompt. They also follow the same basic principle that made GORILLA.BAS work: make the result visible.

The difference is that GORILLA.BAS lived inside the operating system culture of its time. It did not feel like a separate educational platform. It felt like a secret room in the computer. You opened QBasic, loaded a file and suddenly the machine was doing something playful. The same environment that showed the game also showed the source. There was a directness to that experience that still feels valuable.

For many users, it also changed the emotional relationship with computers. A PC was no longer just a device for running programs. It was a device on which programs could be inspected and altered. That shift is small but important. It is the difference between using software and understanding that software is made.

Developers remember GORILLA.BAS not because it was the deepest game of its era, but because it was legible. It made code feel reachable. It connected maths to motion, input to action, and mistakes to discovery. Also, it featured weaponised bananas, which remains an underused educational technology.

Not a masterpiece, but a smart artefact

It would be easy to overstate GORILLA.BAS as some grand masterpiece of game design. It was not that. The gameplay was limited, the graphics were tiny, and the pace depended on the machine running it. After a while, the basic strategy became familiar. Enter angle, enter velocity, watch the banana arc, adjust, repeat. The fun came from the interaction and the experimentation, not from depth.

But as a programming example, it was unusually effective. It gave beginners a complete program that was playful, structured and understandable. It used the computer’s graphics and sound just enough to feel alive. It demonstrated that code could create a world, however small, and that the world could respond to rules.

That is still a serious lesson. Every modern game, simulation, app and interface is built from the same fundamental idea: define the rules, accept input, update the state, show the result. GORILLA.BAS just expressed it with skyscrapers, gravity and bananas that behaved as if they had unfinished business.

The legacy of a banana-shaped tutorial

GORILLA.BAS survives because it sits at the intersection of gaming, education and early PC culture. It was a game people played, a program people modified and a memory people can still explain in one sentence. Two gorillas throw bananas at each other. You type the angle and speed. The skyline explodes. Done.

That clarity is why it remains useful to talk about today. It reminds us that good educational software does not need to be overproduced. It needs to be inviting. It needs to give learners control. It needs to make the invisible visible. And, when possible, it should allow a small amount of harmless chaos.

In a world where programming is often presented through frameworks, accounts, dependencies and setup instructions longer than the beginner’s attention span, GORILLA.BAS feels almost radical in its simplicity. Open the file. Run the game. Change the code. Run it again. Laugh when it breaks. Fix it. Make the banana bigger.

That is not nostalgia speaking. That is solid teaching design, wearing a gorilla suit.

GORILLA.BAS may have been a small sample program tucked inside a DOS-era programming environment, but it understood something many modern tutorials still struggle with. People learn faster when the lesson does something. They learn even faster when the lesson explodes. And if the explosion happens to be caused by a banana, well, the syllabus can probably allow it.