Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
4 PR# 0:TEXT: HOME
|
2018-08-02 01:41:15 +00:00
|
|
|
5 HTAB 15: INVERSE: PRINT "DOOR DETECTOR": NORMAL
|
|
|
|
|
6 PRINT: PRINT: PRINT "DO YOU WANT INSTRUCTIONS? Y/N"
|
|
|
|
|
7 GET P$: IF P$="Y" THEN 610
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
8 IF P$<>"N" GOTO 7
|
|
|
|
|
|
2018-08-02 01:41:15 +00:00
|
|
|
10 E=200: R=1: F=0: Q=0
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
20 A=RND(-PEEK(79)*999-PEEK(78)): A=20: B=20
|
|
|
|
|
|
|
|
|
|
30 FOR I=1 TO 2: V=H: H=INT (RND(1)*(40-R*2))+R: NEXT
|
|
|
|
|
40 REM Line 50: If prior room's exit was next to Death Zone, you'd now be IN Death Zone — step out of it!
|
|
|
|
|
50 A=(A<R)-(A>39-R)+A: B=(B<R)-(B>39-R)+B
|
|
|
|
|
60 GR: HOME: VTAB 21: PRINT "ENERGY:";E;: HTAB 34: PRINT "ROOM #";R
|
2018-08-02 01:41:15 +00:00
|
|
|
65 E=E-1
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
70 COLOR=15: PLOT A,B: Q=13: GOSUB 180
|
|
|
|
|
|
|
|
|
|
80 Q=0: FOR I=0 TO 128: I=PEEK(49152): NEXT: POKE 49168,0: I=I - 203: I=I-(I>21) * 32
|
2018-08-02 01:41:15 +00:00
|
|
|
90 HOME
|
|
|
|
|
100 VTAB 21: PRINT "ENERGY:";E: VTAB 21: HTAB 34: PRINT "ROOM #";R
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
110 IF SGN(I)=I OR I=3 THEN COLOR=0: PLOT A,B: COLOR=15: A=(I=1)+A-NOT I: B=INT(I/3)+B: PLOT A,B: E=E-1
|
|
|
|
|
150 IF B<R OR A<R OR A>39-R OR B>39-R THEN GOSUB 300
|
|
|
|
|
|
|
|
|
|
180 IF (A-V) * (B-H) > 0 THEN VTAB 23: I=A>V: HTAB I+10: PRINT "YOU ARE IN THE " MID$("COLDHOT",I*4 + 1,4) " ZONE"
|
|
|
|
|
190 ON A<>V OR B<>H GOTO 220:IF Q=13 THEN POP
|
|
|
|
|
200 HOME: FLASH: PRINT "YOU FOUND THE EXIT!!!": NORMAL
|
|
|
|
|
210 Q=15:FOR I=1 TO 20: COLOR=Q: PLOT A,B: Q=15-Q: FOR C=1 TO 300: NEXT C,I: R=R+1: ON R/2 GOTO 30,30,520
|
|
|
|
|
220 IF Q=13 THEN RETURN
|
|
|
|
|
230 IF E>=0 GOTO 80
|
2018-08-02 01:41:15 +00:00
|
|
|
240 HOME: INVERSE: VTAB 21: PRINT "YOU RAN OUT OF ENERGY": NORMAL
|
|
|
|
|
250 F=7: GOSUB 310
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
|
2018-08-02 01:41:15 +00:00
|
|
|
260 FOR PAUSE=1 TO 5000: NEXT PAUSE
|
|
|
|
|
270 HOME: VTAB 21: PRINT "THE DOOR WAS IN THE RED AREA"
|
|
|
|
|
280 COLOR=1: PLOT V,H
|
|
|
|
|
290 GOTO 570
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
|
2018-08-02 01:41:15 +00:00
|
|
|
300 HOME: INVERSE: VTAB 21: PRINT "YOU HAVE ENTERED THE DEATH ZONE": NORMAL
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
|
2018-08-02 01:41:15 +00:00
|
|
|
310 FOR I=1 TO 250
|
|
|
|
|
320 COLOR=G
|
|
|
|
|
330 PLOT A,B
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
340 G=G+1: IF G>15 THEN G=0
|
2018-08-02 01:41:15 +00:00
|
|
|
350 NEXT I
|
|
|
|
|
360 FOR C=1 TO 4
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
370 W=A: X=A: Y=B: Z=B
|
|
|
|
|
380 COLOR=0: PLOT A,B
|
|
|
|
|
390 FOR D=1 TO 10: COLOR=G
|
|
|
|
|
400 W=(W<39)+W: X=X-(X>0): Y=(Y<39)+Y: Z=Z-(Z>0)
|
2018-08-02 01:41:15 +00:00
|
|
|
450 PLOT W,B: PLOT X,B: PLOT A,Y: PLOT A,Z
|
|
|
|
|
455 FOR PAUSE=1 TO 250: NEXT PAUSE
|
|
|
|
|
460 COLOR=0: PLOT W,B: PLOT X,B: PLOT A,Y: PLOT A,Z
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
470 FOR PAUSE=1 TO 250: NEXT PAUSE
|
|
|
|
|
480 G=(G+1) * (G<15): NEXT D
|
2018-08-02 01:41:15 +00:00
|
|
|
490 NEXT C: IF F=7 THEN RETURN
|
|
|
|
|
500 GR: GOTO 260
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
|
2018-08-02 01:41:15 +00:00
|
|
|
520 TEXT: HOME
|
|
|
|
|
530 PRINT "WELL DONE!"
|
|
|
|
|
540 PRINT: PRINT "YOU HAVE ESCAPED FROM ALL FIVE ROOMS"
|
|
|
|
|
550 PRINT "SUCCESSFULLY, WITH ";E;" UNITS OF"
|
|
|
|
|
560 PRINT "ENERGY LEFT.": PRINT
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
|
2018-08-02 01:41:15 +00:00
|
|
|
570 PRINT "WANT TO PLAY AGAIN? Y/N"
|
|
|
|
|
580 GET A$: IF A$="Y" THEN 10
|
|
|
|
|
590 IF A$="N" THEN PRINT: PRINT "SO LONG!": END
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
600 PRINT CHR$(7);: GOTO 580
|
|
|
|
|
|
2018-08-02 01:41:15 +00:00
|
|
|
610 HOME
|
|
|
|
|
620 PRINT "The object of this game is to escape"
|
|
|
|
|
630 PRINT "from a series of five rooms before you"
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
640 PRINT "run out of energy. Each room contains"
|
|
|
|
|
650 PRINT "an invisible door you must locate to"
|
|
|
|
|
660 PRINT "advance to the next room."
|
2018-08-02 01:41:15 +00:00
|
|
|
680 PRINT: PRINT "Use the I, J, K and M keys to move"
|
|
|
|
|
690 PRINT "around the rooms."
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
700 PRINT: PRINT "Each room is made up of different zones:"
|
|
|
|
|
710 PRINT "All the area ABOVE and to the LEFT of"
|
|
|
|
|
720 PRINT "the door is called the COLD ZONE."
|
|
|
|
|
730 PRINT: PRINT "All the area BELOW and to the RIGHT of"
|
|
|
|
|
740 PRINT "the door is called the HOT ZONE."
|
|
|
|
|
750 PRINT: PRINT "When you enter one of these zones, a"
|
|
|
|
|
760 PRINT "message on the screen will tell you so."
|
|
|
|
|
770 PRINT "Use this information to help you locate each door."
|
|
|
|
|
780 VTAB 24: PRINT "PRESS ANY KEY TO CONTINUE ";
|
|
|
|
|
790 GET P$
|
|
|
|
|
800 HOME: PRINT "You must also beware of the invisible"
|
|
|
|
|
810 PRINT "DEATH ZONE, which surrounds the border"
|
|
|
|
|
820 PRINT "of each room. In each room, this zone isa little bit wider than in the previous room."
|
2018-08-02 01:41:15 +00:00
|
|
|
840 PRINT: PRINT "If you ever enter this zone, the game"
|
|
|
|
|
850 PRINT "will end immediately!"
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
860 PRINT: PRINT "You have 200 units of energy."
|
|
|
|
|
870 PRINT "Every time you move one space, one unit"
|
|
|
|
|
880 PRINT "is used up."
|
|
|
|
|
890 PRINT: PRINT "If you make it through all five rooms,"
|
|
|
|
|
900 PRINT "you win. But if you run out of energy orenter the DEATH ZONE, the game is over."
|
2018-08-02 01:41:15 +00:00
|
|
|
920 PRINT: PRINT "Good luck!"
|
Several sample fixes/improvements by Alan Ratliff
**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
2024-02-19 19:03:15 +00:00
|
|
|
930 VTAB 23: PRINT "PRESS ANY KEY TO START THE GAME ";
|
|
|
|
|
940 GET P$: GOTO 10
|