Many years ago, in 1998, I released my own version of Arkanoid/Breakout for the Commodore Amiga. Written in AMOS, it was a reasonably good version of the game and came relatively near what I had in mind. Sadly, it only really worked smoothly on an Amiga with at least a 68020 processor and it contains some bugs I never quite got rid of.
There was also the small hitch that it way in fact, way, way too hard to actually finish. But even so, it was the first game I ever released to someone other than my friends and family, so for me it is still a bit of a big deal. Besides, if it was too hard, the included level editor meant you could always make your own levels instead!
Eventually, Breakout was listed in the German Amiga Plus Magazine public domain section as being a nice little game - which I found rather neat!
Now, back then there were about ten gazillion versions of Akanoid about, so what gave me the idea to make yet another one? Why not make something different than the rest of the world had made, or finish my as yet still never-released or even mentioned 2-player space shoot-each-other-dead game that my friends rather liked?
These and other questions (such as why I stopped working on the game when it had still had a rather obvious bug or why I didn't ever finish all the levels I wanted to) will be answered in this two part series. Along with some technical details about my first ever semi-serious attempt at game making!
Above: Screenshot from level 8 of Breakout.
Unlike my other 'big' Amiga project at the time (A.S.O.S, the AMOS GUI system I made), Breakout was much more 'trial and error' and much less 'design stuff first and then make it'*. Partly because I was learning AMOS as I went along and partly because Breakout was made to cure a 'creative itch'.
See, years earlier - around 1989-1990 - I had made a rather silly, very basic** and not-at-all finished version of Breakout on the C=64.
This gave me the idea, partly powered by the niftyness which was AMOS (for making simple games in your free time, it mostly is) that I could make a much nicer version than I made back then. So, in 1995 or 1996 I started out making Breakout in my free time.
I had a working version of the engine that the game still uses to move the balls, react to walls and bricks in under a day. Mostly bug-free after two days. True, it didn't save or restore backgrounds back then and it did have an odd bug were the ball could get stuck inside a brick. But at that stage of development, it was fine.
Naturally, because this project was something I just started to work on without any design guidelines or planning and because the solution eluded me for quite a while, this bug is still present in the last ever released version. Nowadays I understand very well what the problem is, so if I ever write another Arkanoid clone, rest assured it will be fixed.
For the technically minded ones reading this: the reason for the bug is that Breakout doesn't use proper vectors for the ball but rather a simple delta X and Y system. The game also has very simple collision checking. This meant that there were situations where a ball moving into a brick would be undetected, or result in a new ball direction which was wrong. Couple this with a level containing one or more invincible bricks and the ball can get stuck forever, inside one of the invincible bricks.
Over the next few years, I added so much program code that AMOS started to struggle working with it (I ended up at something like 130Kb of AMOS source). I couldn't add more if I wanted to, because if I did add much more code AMOS would, quite literally, blow up! Spectacularly so. Or it would decide to overwrite parts of my code - despite setting the buffer space high enough for the code to fit.
Now, most of the extra code added was severe feature-creep or caused by a lack of designing anything before I started. That said, some of those extra features where rather nice and I still think that being able to save the game any time while playing was a nice touch. The rather silly end-of-level screen with animating paddle not so much, I never was quite happy with that part.
Next time, in part two, I'll write about more Breakout related stuff. Such as the Aminet release, why Breakout doesn't run well on an Amiga 500, just what AMOS did to my poor program and why I quit making new versions even though I wasn't really done.
So, continue to part two!
*) It may be somewhat slow and use a layout which had nothing to do with Amiga's Intuition, but it was built in a far more serious fashion. It even has rather complete reference documentation and I still have a document hiding out somewhere which pointed out what I wanted to add to it and in what revision it would be added.
**) In more ways than one, the game was actually written in Commodore Basic and used two or three small assembly routines to speed it up to something playable.
There was also the small hitch that it way in fact, way, way too hard to actually finish. But even so, it was the first game I ever released to someone other than my friends and family, so for me it is still a bit of a big deal. Besides, if it was too hard, the included level editor meant you could always make your own levels instead!
Eventually, Breakout was listed in the German Amiga Plus Magazine public domain section as being a nice little game - which I found rather neat!
Now, back then there were about ten gazillion versions of Akanoid about, so what gave me the idea to make yet another one? Why not make something different than the rest of the world had made, or finish my as yet still never-released or even mentioned 2-player space shoot-each-other-dead game that my friends rather liked?
These and other questions (such as why I stopped working on the game when it had still had a rather obvious bug or why I didn't ever finish all the levels I wanted to) will be answered in this two part series. Along with some technical details about my first ever semi-serious attempt at game making!
Above: Screenshot from level 8 of Breakout.
Unlike my other 'big' Amiga project at the time (A.S.O.S, the AMOS GUI system I made), Breakout was much more 'trial and error' and much less 'design stuff first and then make it'*. Partly because I was learning AMOS as I went along and partly because Breakout was made to cure a 'creative itch'.
See, years earlier - around 1989-1990 - I had made a rather silly, very basic** and not-at-all finished version of Breakout on the C=64.
This gave me the idea, partly powered by the niftyness which was AMOS (for making simple games in your free time, it mostly is) that I could make a much nicer version than I made back then. So, in 1995 or 1996 I started out making Breakout in my free time.
I had a working version of the engine that the game still uses to move the balls, react to walls and bricks in under a day. Mostly bug-free after two days. True, it didn't save or restore backgrounds back then and it did have an odd bug were the ball could get stuck inside a brick. But at that stage of development, it was fine.
Naturally, because this project was something I just started to work on without any design guidelines or planning and because the solution eluded me for quite a while, this bug is still present in the last ever released version. Nowadays I understand very well what the problem is, so if I ever write another Arkanoid clone, rest assured it will be fixed.
For the technically minded ones reading this: the reason for the bug is that Breakout doesn't use proper vectors for the ball but rather a simple delta X and Y system. The game also has very simple collision checking. This meant that there were situations where a ball moving into a brick would be undetected, or result in a new ball direction which was wrong. Couple this with a level containing one or more invincible bricks and the ball can get stuck forever, inside one of the invincible bricks.
Over the next few years, I added so much program code that AMOS started to struggle working with it (I ended up at something like 130Kb of AMOS source). I couldn't add more if I wanted to, because if I did add much more code AMOS would, quite literally, blow up! Spectacularly so. Or it would decide to overwrite parts of my code - despite setting the buffer space high enough for the code to fit.
Now, most of the extra code added was severe feature-creep or caused by a lack of designing anything before I started. That said, some of those extra features where rather nice and I still think that being able to save the game any time while playing was a nice touch. The rather silly end-of-level screen with animating paddle not so much, I never was quite happy with that part.
Next time, in part two, I'll write about more Breakout related stuff. Such as the Aminet release, why Breakout doesn't run well on an Amiga 500, just what AMOS did to my poor program and why I quit making new versions even though I wasn't really done.
So, continue to part two!
*) It may be somewhat slow and use a layout which had nothing to do with Amiga's Intuition, but it was built in a far more serious fashion. It even has rather complete reference documentation and I still have a document hiding out somewhere which pointed out what I wanted to add to it and in what revision it would be added.
**) In more ways than one, the game was actually written in Commodore Basic and used two or three small assembly routines to speed it up to something playable.