| ★ AMSTRAD CPC ★ GAMESLIST ★ STARDODGER (AMSTRAD COMPUTER USER) (c) AMSTRAD COMPUTER USER ★ |
Amstrad Computer User |
STARDODGER is a very simple game that remains challenging despite the lack of fiddley bits. It was produced as a test exercise to determine the suitability of three languages - Basic, BCPL and Assembly language - for writing a simple game. The gameplay is about as simple as is humanly possible. The player guides a zig-zag line towards a goal on the other side of the screen, avoiding static objects placed in its path. The higher the level, the more objects are placed on the screen, until the player collides with an object or the white edge of the screen, ending the game. The game is made even simpler for both .programmer and player by the use of the Shift key as the only means of control. If the Shift key is pressed, the line climbs; if it is released, the line falls. Basic was used to write the original program as it has the advantage of instant access. This allows a deal of experimentation and correction while testing without lengthy recompilation sessions. Despite its speedy reputation, Locomotive Basic is a little slow for this sort of thing, so the game was later rewritten in a compiled language for speed. Subprograms The Basic program was written as a series of simple subprograms tacked together with that most marvellous keyword, GOTO. This keyword gives rise to cheers from some and hisses from others - generally computer scientists who have been bitten by a rabid GOTO at an early age. The most complex part of the game is the check on whether the pixel in front of the player's free is white; if it is, the game ends. A test is also nade to determine whether the right-hand edge of the screen has been reached; this results in the next screen being drawn. It was found that the game was very slow when written in this manner since two independent tests - TESTR and XPOS - were required every game loop. This was solved by drawing a vertical line in a different ink to the rest of the game graphics at the right-hand edge of the screen. Now all that was required was one ink test per loop, using TESTR, to see if the player had hit the line or had hit something nasty. There were plans to include sound - these were shelved when it was discovered that sound programming is not one of my strongest points. This programming technique is know among the cognoscenti as The Cop Out. As the variable names used are not descriptive, a table of their function may help (see Figure I). These variables hold integer values only, so it could be an interesting (and simple?) exercise to use a Basic compiler on the program.
ONCE the Basic version of Stardodger worked to my satisfaction - which took longer than expected - the program was rewritten using Amor's BCPL compiler. BCPL was the forerunner of the oh-so-trendy C language beloved by computer scientists and other deviants. Unlike C, BCPL is quite readable, yet it still enforces a carefully structured programming style. This is due to its syntax and the lack of error checking. Care must be taken or the compiler will merrily churn out guff without a single beep of displeasure. The BCPL Stardodger took far less time to write than the Basic version, mainly because all the program logic had already been worked out.
Dynamic elegance A particularly neat feature of BCPL is the case structure - SWITCHON..INTO..CASE, used here in the collision detection routine - which is similar to, but more elegant than, Basic's ON..GOTO. Nearly all the variables used in this program are static variables; this means they are always available to any part of the program. Dynamic variables - such as t used in the pause procedure - disappear after being finished with. Unlike Basic, ail BCPL variables and constants, known as manifests, have to be defined before use. Also unlike Basic, which has string, integer and real variables, BCPL has only one type of variable - the "word", or 16 bits. This makes it ideal for implementation on a home micro. It does have some odd conventions though. For instance, the asterisk is thought of as a control character. It cannot be represented as simply * but has to be written as ** before it is accepted. Gripes aside, BCPL is a lovely language to use. You can use any Ascii text editor for producing the source code. Indenting the text is not necessary, but helps to show the levels of the program. After saving the text - call it STARDOJ.B - it may be an idea to dry run it through the compiler without GETting any of the libraries. As long as only Undefined identifier errors are produced the text should be OK. But beware of spelling mistakes in procedure names, as these cannot be checked for until the final compilation stage. You must first invoke the compiler from disc, using RUN"DISC and then |BCPL. Follow the compiler dialogue in the panel, but note that minor differences may occur in the numeric values produced.
BCPL produced a game that would be fast enough for anyone, but was about 10k long. This seemed quite excessive, so a non-singing, non-dancing compact game in Z80 code was developed in Assembly language. Assembly language programming is quite a different kettle of fish from Basic or BCPL, with absolutely no safety net provided for the unwary. Simple housekeeping tasks such as printing a string have to be written by the author and these can frequently prove to be the most difficult bits. Again, the Basic Stardodger served as the template for this model, with slight differences. The screen numbers in this version are printed in hexadecimal simply because a hex routine is shorter to write than a decimal one. Reasonable care has been taken that each routine does not corrupt registers unnecessarily. This wastes space in the form of PUSHes and POPs, but the approach is preferable to a possible system crash. The random routine and the screen drawing The listing was produced using the Maxam rom, so the long label names may cause problems for ADAM , Devpac, Zapp and Code Machine users, but are there to increase readability. Check your manuals to see how label names should be entered into your particular assembler. Your reward for all of this effort? A paltry 937 bytes of code. This can be saved by hopping into SAVE"STARDOJ",B,&5080,&3A9,&5000Some people may find this Assembler version a bit fast. Remedy this by changing part of the START subroutine from LD A,3:CALL HAUDON to LD A,value:CALL HAUDON where value can take any value from zero to 255 - 3 (default), 4,5 or 6 {very slow) are the best ones to use. HAUDON, incidentally, is Glaswegian for "hold on".Conclusions Producing the Assembly version was certainly challenging, but the effort involved doesn't really justify the result. Although coming last in the race, Basic provided the slow, good-natured workhorse from • which the tetchy thoroughbreds were descended. My current record on both the BCPL and the Assembly versions is Screen 11. I've made it through Screen 19 on the Basic one. Can you get further? Go forth, and dodge them stars! ACU
| ||||||||||||||||||||||||||||||||||||
|  |
|
Page créée en 147 millisecondes et consultée 1048 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. |
