This game of mine was a clear cut copy of Ocean's 1987 CPC smash hit "Gryzor". I used to play Gryzor a lot. In the end I was even so good at the game that I was able to win it without loosing a single life!

Gryzor was really an amazing game, incredible graphics, great gameplay, just the right amount of difficulty so that it was hard, but still playable, some cool extra weapons, three different types of levels (horizontal fighting, vertical fighting and 3d tunnel levels) and a cool soundtrack.

It was just lacking one thing: scrolling! Unfortunately the game was divided into individual screens. Sometimes going from one screen to another meant instant death, because you ran right into the arms of an enemy soldier or cannon on the new screen!

With this Gryzor clone of mine I wanted to remedy this single drawback about the original game. The primal idea was to create a junge fighting game where the player had to shoot enemy soldiers. But I realized that the graphics I had created looked so much like the original Ocean game that I couldn't fool anybody about the origin of this idea. I was obviously searching my inspiration a little too hard in the original game...

Anyway, the scrolling I've created was just a simple software scrolling with double buffering, so that it didn't flicker too much. I also made a conceptual error with inserting the new graphics at the right end of the screen, so that every time the screen was moved by one byte to the left the last column on the right came out to be an exact copy of the last but one column. This was due to the fact that I had the computer insert the new column on the right hand side of the screen and move the screen afterwards. I should have done it the other way round...

But this wasn't the real problem I had with this game. I ran into similar problems like in "The enchanted forest" when it came to finding out where the character was allowed to walk on the screen and where he couldn't walk or stand. Since I wasn't able to think of an easy way to test that in the memory I tried to devise a method so that I could find out on the screen whether the character can walk on the next byte or if the road is blocked or ends there.

Since the graphics was very colorful there wasn't a distinct two-pixel combination (a Mode 0 byte) that I could use to define as ground. I tried to mark the walkable parts on the screen with a brown colored byte. That meant that I would have to change the palm trees in the graphics so that they didn't contain bytes with two brown pixles anymore, but I was willing to accept that change.

The first tests with this brown walkways on the screen were promising. The program was able to determine where the character was able to walk and where he couldn't walk. But marking all the walkable parts on the screen with brown bytes looked really stupid. Also finding out where the next brown byte was on the screen took a lot of time. So when I used that walkway identification routine with the software scrolling it was so slow that the guy on the screen was continuously wobbling left and right.

Since the game was already very slow and at that time I didn't have the means or knowledge to create a faster scrolling I soon started to divert my attention to other programs and demos. Thus this Gryzor clone grew to become another unfinished project in my CPC career...

Of course I had already created a map editor with which I was able to draw the landscape that was being scrolled on the screen in the test version of the game. With this editor I was able to select one of several background elements and insert it in one of the three height levels that were used in the game. Since this background elements were very large the combination possibilities of these elements were rather limited.

At that time I obviously had a lot of leisure time. The editor was a regular BASIC-Assembler mix, i. e. the background elements were painted on the screen with an Assembler program, the keyboard input and the loading and saving of data was done in BASIC.

Every time I started the editor a very slow BASIC algorithm added some colored points to the "Landschaft Editor" text on the top of the screen. It took a minute or two to change the points in the whole text, but obviously I had enough time to wait for that algorithm to get finished when I wanted to change the map for the demo. I'm a lot less patient nowadays and was very happy that Caprice had an option to run the CPC Emulation with more than 100% speed.




★ ANNÉE: 1990


Game (NON Commercial/Freeware/Shareware):
» Gryzor  CloneDATE: 2013-08-30
DL: 123 fois
SIZE: 62Ko
NOTE: 40 Cyls

Je participe au site:
» Newfile(s) upload/Envoye de fichier(s)


L'alinéa 8 de l'article L122-5 du Code de la propriété intellectuelle explique que « Lorsque l'œuvre a été divulguée, l'auteur ne peut interdire la reproduction d'une œuvre et sa représentation effectuées à des fins de conservation ou destinées à préserver les conditions de sa consultation à des fins de recherche ou détudes privées par des particuliers, dans les locaux de l'établissement et sur des terminaux dédiés par des bibliothèques accessibles au public, par des musées ou par des services d'archives, sous réserve que ceux-ci ne recherchent aucun avantage économique ou commercial ». Pas de problème donc pour nous!

CPCrulez[Content Management System] v8.7-desktop/cache
Page créée en 130 millisecondes et consultée 1442 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.