Denjoy and Slez were intended for german disk magazines. So I would have gotten a little money for them.
Pot - I don't know. I showed it to some german publishers (Demonware and Software 2000), but they were not really interested.
Rejection by disk magazines and publishers. They said the games were too complicated. Looking back, I must admit they had a point.
I didn't have anyone particular in mind.
I showed Pot to Demonware because I had already sold another game to them (The Power), I showed it to Software 2000 because they had already published some puzzlers.
I offered Denjoy and Slez to the disk magazine Amiga Fun because I had sold them a game before (Aim XI). I'm pretty sure I offered these games also to other disk magazines. Unfortunately, I don't remember their names.
As I already said, I couldn't rouse anybody's interest.
Pot - as far as it got - was written in about five months from October 1990 to February 1991.
Slez was written in about five months from March 1991 to July 1991.
Denjoy was written in about five months from August 1991 to December 1991.
The game code of Denjoy, Slez, and Pot is of course 100% asm. I don't remember the exact name of the assembler I used, but the words HiSoft, DevPac, genam, genim come to mind.
The level editing tools for Denjoy and Slez were built with C and used the Amiga GUI (screens, menus, ...). Aztec C? Lattice C? Don't remember.
General purpose graphics converters used throughout were also built with C. Some even with Modula 2. Don't ask me about that particular compiler either.
A good deal of text editing was done with CygnusEd.
There are several kinds of graphics and animations in Denjoy, Slez, and Pot.
First, there are bitmap graphics and vector graphics. Then, there are hardware sprites and graphical objects drawn with the blitter. Finally, there are vector animations, bitmap animations with all phases drawn by hand, and bitmap animations with intermediate phases pre-calculated from base phases drawn by hand. All the bitmap graphics (fonts, tiles, single animation phases, hardware sprites, display elements, ...) were created with DeluxePaint. All vector data (object shapes, animation phases) was typed by hand into the asm source code as lenghty sequences of numbers.
The development cycle for the animations went as follows.
In Denjoy, the mouse cursor is a hardware sprite. Everything else is bitmapped and drawn with the blitter.
In Slez, the - um - life-forms you control are hardware sprites. The rotating maze you move them through is made up of vector graphics tiles. Some tiles are animated. The display elements around the rotating maze are bitmaps. This game contains code for rotating bitmaps about quite arbitrary angles (not in real-time). The resulting bitmaps look good (recognisable :-) and have no holes. I was pretty fond of this feature. It is used to pre-calculate rotations of the life-forms you control, which are too colorful to be done in vector graphics. Unfortunately, it's difficult to observe this feature while playing the game. You can see it only when two (or more) of the life-forms you control are so close together that they are visible in the rotating maze at the same time. Then the life-form you are currently controlling looks straight up while the others are rotated according to their viewing directions. And wait, you can also observe it during the smooth transition you get when switching control from one life-form to another, especially when they are looking in different directions. In retrospect, a technically cool effect which was not properly shown off. Big design flaw.
In Pot, the information displayed at the bottom of the screen and the border around the 3D view are bitmaps. The aiming cursors in the center of the 3D view are hardware sprites. The sporadically occuring planets in the 3D view are also bitmaps.
Everything else in the 3D view - the information about your position and viewing direction, the playfield on the ground, and the puzzle pieces (rather abstract, geometric objects) - are vector graphics. The puzzle pieces in the 3D view are dynamically lighted by parallel rays.
Denjoy wasn't inspired by any game in particular. Here, the goal was to create a dynamic puzzle where the player had to act under time constraints. For example, in Shanghai (Mah-Jongg to the uninitiated) you can stare at the playfield for hours on end. It's static, no time constraints. In Tetris on the other hand, you *must* do something *now". It's dynamic, the player is forced to act. Shanghai works because of its classical time-tested rules. Tetris works because it's instant fun - easy to pick up, hard to master, as the saying goes. If you browse puzzle games on the Amiga (commercial and PD), you will find a lot of static puzzles with their own strange set of rules. The problem with these is that the player is not forced to pick them up. On the other hand, the good ones (according to my taste), the instant-fun-ones are dynamic, like Tetris. Then, I like puzzle games and had a lot of strange ideas. But I noticed that most of them were static. Of course you can always slab a ticking clock onto any static puzzle to add time constraints. But I think that's not exactly original. So I tried something more dynamic. The result is Denjoy. Here, the player is forced to drop one of those turning rings onto the playfield every now and then. Sooner or later, things get messy.
Slez is remotely inspired by Thrust on the C64. There are other fun gravity games on the C64 and the Amiga (and probably also on other systems :-), but Thrust is *my* gravity game. My modification of the concept was to rotate the background instead of your ship.
Pot was generally inspired by my love and admiration for puzzles and 3D vector graphics. Two 3D puzzlers which I found extremely awe-inspiring are The Sentinel (which I experienced on the C64) and Towers of Babel. However, in both of them the viewing direction was somehow restricted, if I remember this right. Not so in Pot.
Both Denjoy and Slez are 100% as I wanted them to be. Looking back, they would have needed some serious playtesting by other people. For example, Slez would probably be really fun to play if the collision detection were not so unforgiving. Or the corridors in the maze were wider, but that's another story.
With Pot, it's hard to say because I didn't have a clear picture of the product as a whole in my mind. So I can't really measure its completeness in %.
On the plus side, we have:
+ the 3D vector graphics work fine
+ the puzzle mechanics work, the existing levels can be played
On the minus side, there are:
- no sound
- background in the 3D view needs improvement
- display elements around the 3D view need improvement
- there should be more levels
What can be said is that Pot stopped as a work in progress and sadly didn't become all that I wanted it to be.
For all three games, there are only Amiga versions.
On a C64, back in the 80s. When every game you loaded into the machine was a new world. Better yet, you could make your own worlds.
But the thrill of total control over the machine is not there anymore. And just the thought of another process running in the background, taking CPU time away from my game code, makes my hair stand up. :-)
By Tetris, I mean the version from Mirrorsoft, with mind-expanding, trance-inducing music from David Whittaker, and that strange, animated background. Ok, quite some people are not so enthusiastic about that incarnation of the game. But this is *my* definition of Tetris.
By Virus, I mean the 3D shooter from David Braben.I like the bright and colorful vector graphics in third person perspective, and especially the lavish particle effects. And opposed to widespread misjudgement, I can assure you: you *can* play this game.
Of course, I also played a lot of other games ... :-)