| ★ APPLICATIONS ★ AIDE A LA CREATION DE JEUX ★ SPRITES ALIVE - COMPILER VERSION ★ |
SPRITES ALIVE: COMPILER VERSION | SPRITES ALIVE + COMPILER (Amstrad Action) |
Duncan Evans checks out the latest packages from Glenco. The trouble with producing fast action arcade games or graphic intensive educational packages, is that unless you want your masterpiece to move as fast as progress on the Channel Tunnel, you have to resort to a fairly low level language, or a high level one with a fast compiler. Low level languages such as machine code or assembly are fast and powerful, but also notoriously difficult for beginners to get to grips with.
The maximum number of sprites that can be defined is 64, which is the same number of drawings which can be defined. Drawings are the backbone of the entire sprite making process as not only do they form the shapes for the assigned sprites, but they serve in animation sequences. A sprite can have up to 16 animation sequences, with each sequence containing eight drawings for each potential direction it coulcl move in. Tliis is facilitated by the clumsy command :SEQUENCE, sn (sequence number) 11, lh, 21,2h, 31,3h, 41,4h, 51, 5h, 61, 6h, 71, 7h, 81, 8h. Thankfully this only needs to be done once for a sprite. But when you have quite a few sprites, then there's a lot of defining to be done. The actual drawing package for the sprites is fairly crude, it doesn't support a joystick either, but usable, and at least you can redefine the colours used from the CPC's palette. Two cursors down either side of the grid covering the sprite size (maximum definition of 32 x 32 as mentioned earlier) are used to point to a pixel to be coloured. This is easy enough for small sprites but very awkward for large ones. Another down point is that there is no repeat function when colouring pixels, so each and every pixel has to be co-ordinated, then coloured in. Still, it works, however clumsily, and data can be saved for incorporation into the main Basic and Compiler programs. The commands offered by Sprites Alive are quite comprehensive, covering general screen colours, text printing to the screen (four times faster than normal), collision detection, sprite speed, missiles, nodes and sound effects. The Compiler version also offers labels, as line numbers are optional. Sprite collision detection is at the heart of Sprites Alive but besides offering powerful functions, it also has a number of idiosyncrasies that throw up problems. The sprites normally bounce off each other when contact is made, but because of the way the system works, it is possible for them to become locked together (if they are of a design whereby coloured elements could fit into black areas). This problem can be solved - the manual gives fair warning and advice on the subject, but in a commercial package this is unacceptable. Then, because of the way the sprite detection system works, there is the problem of deliberately overlaying one sprite over the top of another. The case used to illustrate this in the manual is that of a platforms and ladders game with a man climbing up a ladder, where both are sprites. The solution offered is to use colours for the sprites that do not show up on the collision detectors. An awkward compromise to make. While Sprites Alive looks a little amateur in these regards, it scores heavily in the provision of nodes. These are points on the screen that sprites can be set to move through, so producing Pac-Man or games with patrolling sprites is made much easier. The system used to plot the nodes is not as sophisticated as it could have been, such as that used by the Shoot 'Em Up Construction Kit (not available on the CPC anyway), but then this is a sprites package, not a dedicated games creator, so you can't really complain as it does the job asked of it. A very nice feature comes in the form of missiles, which once defined as sprites can be ordered to fire automatically, and in the direction that the host sprite is facing. It's a handy little extra if you are contemplating some form of violent exercise. Speed is very important in a sprite package, and I'm afraid to say that despite cutting the odd corner, the smooth pixel by pixel animation in Basic-is too slow to be usable. You have to make the sprites move at least two pixels per step to achieve reasonable speed, and then the animation can be flickery as well. Whether you like it or not you have to have the Compiler version if you want smooth and steady animation, or cruder and less impressive animation, but the speed necessary for a fast action shooting game. However, just before you rush out thinking XENON II here we come, there is another drawback to Sprites Alive. You can't scroll the screen because it confuses the co-ordinate system. The manual is generally very informative, if not particularly lucid in places, while the demonstration programs that come with each package show something of what the system is capable. At this point though I have to lambast Glenco for the absurdly lengthy procedure that needs to be undertaken to make the demos in the Compiler version work. This is not the way to provide a demo program. I suppose that it has been done this way because of a lack of space on the disc for source code and a compiled version. There are some powerful features in Sprites Alive, and in some ways it qualifies as a simple games creator. With possibly more development work and enhancements Glen Cook could have a product that Palace Software would be happy to licence. As it is, Sprites Alive does offer educational or utility designers a comprehensive package to enliven their own products. The claim made on the back of the packaging, namely, "At last, the truly professional games designing system which will allow you to write quality arcade style games with ease," is stretching the truth rather too far as you still have to be able to program (in Basic) to produce the games. You can create impressive products with Sprites Alive, within the limitations outlined, but it won't be a painless and easy task. POINTS FOR
POINTS AGAINST
ACU #9007 |
|  |
|
