+Living Room Arcade Posted July 24 Author Share Posted July 24 THE ANDREW DAVIES 'SNAKE' EXAMPLE Spoiler The Example Spoiler About four years ago, a programmer here at AA was making a very nice 4k snake game. He wrote that he was accustomed to programming on computers and that programming this game on computers wouldn't have been a problem for him, but trying to make the game for Atari 2600, he was running out of memory. Link Mr. Andrew Davies offered him a helpful suggestion to save RAM. He suggested to just note the starting point of the snake and a series of 2 bit (0-4 up/down/left/right) turns after that all the way to the end. The programmer thanks Mr. Davies and says he'll try using his advice. As a result, the programmer could make a new snake that is more than twice as long with 200+ segments! Applying the Idea to This Game Spoiler I think Mr. Andrew's idea might apply here. Take away the 3D effects, our road looks like a ladder with two parallel lines and "rungs" connecting them, the rungs being the pairs of WRM's. It kind of looks like a segmented snake. We here also have been using a lot of RAM to store the information about the segments of our snake er um I mean the rungs of our ladder er um I mean the pairs of WRM's on our road. Like the snake, which has segments of equal length, the rungs of our ladder are equally far apart. Taking a cue from Mr. Davies, we should not, therefore, need to store the y-values for every rung on the ladder. Just the first rung, and observing the pattern, we can calculate the y-values of the other rungs, thus saving a lot of RAM. How Much RAM Will We Save? Spoiler About 13 bytes. Meaning, we'll get nearly 1/3 of our RAM back. X-Coordinates of WRM's: I think we need to store those in RAM. No savings there. Y-Coordinates of WRM's: These are like the rungs on a ladder or the segments of a snake in Mr. Davies' example. I think we can apply his idea and save RAM here. Currently, we are using 2 bytes in high precision 8.8 fixed decimal format for each pair of WRM's. We'll need to store the first pair in RAM. That's like the head of the snake, so to speak. But the other 2 bytes times 6 pairs equals 12 bytes of RAM that we can save using Mr. Davies' suggestion. Plus, currently, there is one pair of WRM's off the bottom of the screen used for collision detection. One byte is used to store its y-coordinate. So, we can save one more byte of RAM there. Totally, we can save 12 + 1 = 13 bytes of RAM if this idea works for us. How to Implement this Idea? Spoiler NEWER VERSIONS ON TOP VERSION B Spoiler The Mad Bomber's Accumulator will express a value from 0% to 100%, called MBP or Mad Bomber's Percentage for short. The road is like a ladder with 8 rungs. The 7 pairs of WRM's move inside the 7 spaces created by the 8 rungs. The MBP will move all 7 pairs of WRM's simultaneously. All 7 pairs of WRM's move from their rungs above to their rungs below. When the MBP is 0%, then all 7 pairs of WRM's will be at their rungs above. When the MBP is at 100%, then all 7 pairs of WRM's will be at their rungs below. Due to 3D effect, rungs at the top of the screen are closer together and rungs at the bottom of the screen are farther apart, but all 7 pairs of WRM's will move in unison such that they all start at their rungs above at the same time and they all will arrive at their rungs below at the same time. Consequently, the pairs of WRM's at the top will be moving slower and the pairs of WRM's at the bottom will be moving faster. This is also part of the 3D effect. Thus, the motions of all 7 pairs of WRM's are locked to the MBP as it goes from 0% to 100%. The rate at which the MBP goes from 0% to 100% is dictated by SPEED OF CAR. Therefore, the y-coordinate of each pair of WRM's can be found by a simple formula y=a+MBP*(b-a) , where a is the y-coordinate of the rung above and b is the y-coordinate of the rung below. (NOTE: In Batari Basic, the positive y-direction is down.) Since the y-coordinate of each pair of WRM's can now be found by use of a simple formula, it is now no longer necessary to store those y-coordinates in RAM. Everything stated above for the 7 pairs of WRM's also applies to the 8th pair of WRM's not visible off the bottom of the screen and used for collision detection purposes. (Actually, the road has 9 rungs and 8 spaces, but the 9th rung and 8th space are not visible off the bottom of the screen.) VERSION A Spoiler If there were no 3D effects, it would be rather simple. Then the road would look like a ladder and the pairs of WRM's would be the rungs on the ladder. Knowing the y-coordinate of the first rung, one could easily calculate the y-coordinates of any rung desired. What makes this task tricky is that our game has 3D effects. In particular, 3D Effect #3: the WRM's are spaced closer together near the top and farther apart near the bottom. That will make things a little tricky. But, the basic idea would be that given the y-coordinate (in high precision fixed point 8.8 format) of the first "rung," to find formulas to directly compute the other 6 rungs on the ladder. That will be tricky, but I think we can do that. The result would then be 6 formulas that you can plug the value of the first y-coordinate into and get back the y-coordinates of the other 6 rungs of the ladder. What Can We Do with All the RAM that We Would Save? Spoiler Well, I have just finished my shopping! The game will be much improved. Let me tell you? Bring Back Top Speed: 2 bytes - It's a part of the arcade version and I'd like it to be a part of our home version Display Changes: 2 bytes - Alternate between odometer and gear in lower left corner. - Alternate between game timer and top speed in lower right corner. Improved WRM Drawing Routine: 5 bytes (See New Version D here) - Better than our current drawing routine - Will more perfectly draw 3D Effect #1: WRM's become larger as they come "closer." - Will not waste sprites on WRM's that go off the sides of the screen when the paddle is turned to the extreme right or left. TOTAL: 9 bytes And we would still have about 4 bytes left And all while retaining all 14 WRM's! So, this would be amazing! It would be amazing to me to be able to do all of these things within the same RAM as before. I will try to do it. We'll see how it goes. 1 Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted July 27 Author Share Posted July 27 GAME MODE LAYOUT Spoiler My current thinking about the layout of the screen in Game Mode. NEWEST VERSIONS ON TOP VERSION B Spoiler NOTE: Phosphor effect was used to take this screenshot. LOWER LEFT: Smart Display alternates between odometer/SCORE (0-999) and GEAR (1-4) LOWER RIGHT: Smart Display alternates between GAME TIME (0-100) and TOP SPEED (0-350) REMARKS: LOWER LEFT: The default display mode is to show the odometer/SCORE counting up from 0. If at any time during the game the GEAR changes, then this display will temporarily show the new GEAR for about 3 seconds. Then it will return to displaying the odometer/SCORE counting up, as usual. LOWER RIGHT: The default display mode is to show the GAME TIME counting down from 100 down to 0. However, if at any time during the game the current SPEED OF CAR exceeds the TOP SPEED stored in RAM, then this display will change modes and show the new TOP SPEED for about 3 seconds. Then it will return to showing the GAME TIME counting down, as usual. VERSION A Spoiler Version 1 Version 2 UPPER LEFT: GEAR (1-4) UPPER RIGHT: GAME TIME (each block = 10 seconds) LOWER LEFT: odometer (AKA SCORE) LOWER RIGHT: TOP SPEED (0-350) REMARKS: UPPER RIGHT: This is a kind of a timer. It shows how much GAME TIME remains by using blocks. Each block represents 10 seconds of game time. Every 10 seconds, one block is removed. There are 100 seconds in a game. After all 10 blocks have been removed, the game is over. UPPER LEFT: These blocks show which gear the car is in. The car has 4 gears. There will be one, two, three or four blocks displayed to indicate which of the four gears the car is in at that moment. 1 Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted July 27 Author Share Posted July 27 GAME OVER, ATTRACT MODE and BONUS Spoiler GAVE OVER Spoiler The GAME OVER screen Tiny letters intended to look more like the arcade game. NOTE: Phosphor effect was used to capture this screenshot. When the game is over, the game will immediately go into the ATTRACT MODE, which will feature the GAME OVER screen, above. ATTRACT MODE Spoiler The ATTRACT MODE will consist of the following: Show the GAME OVER screen for a few seconds Show Vignette #1 for a few seconds. That is, a few seconds of actual racing. Collision turned off. Show the GAME OVER screen for a few more seconds. Show Vignette #2 for a few seconds. That is, a few more seconds of actual racing. Collision turned off. Repeat the above sequence endlessly during ATTRACT MODE. BONUS Spoiler When the GAME TIME reaches 0 and the player's score is 350 or higher, the player is awarded extended play called BONUS. When this happens, the game will do the following: Game play does not stop when a player earns the BONUS time. The GAME TIME will be reset to 100 seconds. An audible sound will be played. Perhaps a bell tone sounding three times. Maybe some flashing. Perhaps the score will flash three times also. 1 Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted July 28 Author Share Posted July 28 PLANNING IS COMPLETE Spoiler The following objectives have all been accomplished. Learn about the arcade version of the game to better understand the features we wish to implement in our home version. ✅ Describe in English, step-by-step, how the program will work, including the main program loop and the major subroutines for special purposes. ✅ Name all of the variables to be used in the program and determine the amount of RAM. ✅ Create small, simple demo programs to test concepts as needed. ✅ Describe in English the most important next steps that will be necessary to complete this project. ✅ The next stage, writing the code, will generally follow the steps outlined in ROADMAP - STEPS FORWARD. 2 Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted July 31 Author Share Posted July 31 WINDFALL RAM Spoiler In RT's section on the playfield, he talks about pfres and he shows this table. He says that if you're not using the playfield for anything, you can get up to 36 bytes of RAM back by changing the value of pfres as shown in the following table. That's more RAM than we used to plan out the entire game! What to do with it? INSTANT REPLAY Spoiler With 36 extra bytes of RAM, I think it should be possible to create an Instant Replay feature that gives the player the option to watch a live, CPU-controlled re-enactment of his or her last game. RE-ENACTMENT VS. REPLAY Spoiler Technically, this will be a re-enactment, not a replay. A replay would result from recording everything that happened in the game and then playing back that recording. Well, we only have 36 bytes, and that's not enough to do a replay, but I do think that's enough to do a re-enactment. We'll record benchmark odometers every 10 seconds and up to 19 player collisions. We'll record the odometer reading that the player achieved his or her top speed. The computer will then re-enact your performance by driving down the exact same road and matching all 9 benchmarks, all player collisions (up to 19 of them) and reaching top speed at the recorded odometer, resulting in a re-enactment that will be, I think, pretty close to (although not exactly the same as) the player's actual performance. We're going to call it a replay, but you understand it's really a re-enactment, not a replay. AUTOPILOT Spoiler Write some code that would let the computer drive the car in place of a human player. AUTOPILOT If this bit is 0, the program reads the paddle knob and button from the paddle. p=paddle If this bit is 1, the program goes to a subroutine to provide substitute paddle inputs. p will be calculated by the program. See below. STEERING Compare the position of the car with the position of the next pair of WRM's. Does the car need to go straight, turn right or turn left? What is the horizontal distance from the car to the next pair of WRM's? The greater the distance, the farther the paddle knob should be turned. PADDLE BUTTON Let p be the variable which indicates whether the paddle button is pressed or released. If SPEED OF CAR is less than TARGET SPEED, set p to 1. (Press down on the accelerator.) If SPEED OF CAR is equal to or greater than TARGET SPEED, clear p to 0. (Let off the accelerator.) TARGET SPEED The final odometer reading of the human player's last game is known. And the time was 100 seconds. Divide distance by time to get TARGET SPEED. However, we modify the formula. For each collision between here and the end, subtract time, maybe 5 seconds for each collision. Because at each collision, the car is stopped and returned to first gear and must accelerate to normal speed again and this causes a loss of time. The modified formula could be TARGET SPEED = DISTANCE / (TIME REMAINING - 5*COLLISIONS REMAINING) DRIVING WITH AUTOPILOT Spoiler The Autopilot would drive the car in place of the human player. There would be no difference between the gameplay when the autopilot is controlling compared to when a human player is controlling. The acceleration of the car, the engine sounds, the odometer, game timer, and everything else will all be identical to when a human player is driving. RECORDED INFORMATION Spoiler Here is where we will spend our 36 bytes of RAM. NOT RECORDED (BY INSTANT REPLAY MEMORY): The initial odometer reading. Replays always start at the beginning of the race, so the initial odometer is always zero and doesn't need to be recorded. The player's final odometer reading (AKA SCORE) is recorded automatically by the regular game memory and thus also doesn't need to be recorded by the Instant Replay routine. The player's TOP SPEED, because that value is store by the regular game memory. Details about the turns of the road. The road will be procedurally generated with inspiration taken from Carol Shaw's river sections in River Raid. (See PROCEDURALLY GENERATED ROAD, below.) RECORDED (BY INSTANT REPLAY MEMORY): 9 odometer readings. That is, one odometer reading for every ten seconds of GAME TIME, not including the start of the game (0 secs.) and not including the end of the game (100 secs.). That is, odometer readings will be recorded at 10, 20, 30, 40, 50, 60, 70, 80 and 90 seconds; 9 odometer recordings in all. One byte for each recording; 9 bytes in all. The odometer readings of up to 19 collisions can also be recorded. Also one byte for each recording; 19 bytes in all. DATA STORING METHOD Spoiler Since in NDA, the final odometer value can be greater than 350; and bytes hold values from 0-255; therefore, the following method of recording odometer readings seems practical. TWO SPECIAL BCD COUNTERS Two special 3-digit BCD counters will be set up especially for the Instant Reply; one for the odometer benchmarks and the other for collisions. Each BCD counter can thus store values from 0-999 just like the arcade version. Additionally, 2 bits will be added to the regular game odometer to record quarter turns of the odometer. Another 2 bits will be added to the Instant Replay odometer also to record quarter turns of the odometer. One nybble 0-16 to store each BCD digit 0-9; three nybbles for each of the two 3-digit BCD counter. 6 nybbles = 3 bytes. Plus the additional 4 bits to record quarter turns of the odometer. Totally, 3 bytes and 4 bits to create the two special BCD counters. RECORDING ODOMETER BENCHMARKS Odometer readings called benchmarks will be stored using one byte each, storing a value from 0-255. This value will represent the value added to the previous odometer value in the 3-digit BCD odometer counter. Thus, I think 0-255 for each 10 seconds of game time will be sufficient even at the maximum possible speed. Example. Suppose the first five odometer values are 0, 5, 15, 30, and 50. Then the Instant Replay routine will store the values 5, 10, 15 and 20. In this way, 9 odometer benchmarks will be store during a 100 second game. They will be recorded at 10, 20, 30, 40, 50, 60, 70, 80 and 90 seconds during the game. RECORDING COLLISIONS Collisions will be recorded according to the TIME when the occurred, not the odometer reading. One byte will be used to record each collision. 6 bits 0-64 to record the whole number value of the time in seconds, and 2 bits to record the quarter of a second in which the collision occurred. The elapsed time from the start of the race or the most recent collision is recorded in seconds + quarter of a second. Values 0-62 will indicate that a collision occurred. A value of 63 (%11111111) is a special value which indicates that no collision occurred during those 62 seconds. Thus, 19 bytes are set aside for recording collisions. Up to 19 collisions can be recorded. TOP SPEED One byte is set aside to record the time in seconds when the player achieved his or her top speed. Seven bits indicate the time in seconds 0-127. The 8th bit indicates which half of a second. SEED And one nybble to store the seed 0-15 for the not-so-random number generator so it can exactly reproduce the roads during Instant Replay. INCREASING ACCURACY Spoiler Here's a tweak to increase the accuracy of the replay. THE PROBLEM Spoiler Right now, the difference between odometer readings is stored as a whole number, truncated. (The fractional part, if any, is disregarded.) This can lead to significant errors, especially at slower speeds. For example, if the first two actual odometer readings are 0.0 and 5.9, our program would record "5." That's an error of .9/5.9=15%. This number is used by the Instant Replay routine to calculate a target speed (speed=distance/time). If the distance is off by 15%, I guess the target speed would also be off by 15%. I guess the program would still work, but it might have trouble reaching benchmarks on time due to the 15% error in target speed. TWO UNUSED BITS Spoiler We don't have all the numbers for this design yet, and we won't until we do the video capture from video of the arcade version of the game. We know the max speed of the car is 350 when in Expert Mode. What we don't know is at speed 350, how many odometer turns will that be in 10 seconds? Another thing we don't know is how many pairs of white road markers equals one turn of the odometer. Again, we will find these things out when we do video captures, I'm sure. Let's guess some numbers. I guess that the theoretical maximum odometer reading for 100 seconds at max speed is 500. That would be an average of 50 odometer turns per 10 seconds. Well, as we all know, the way that binary numbers work, if the max odometer increase in 10 seconds is 50, then we only need 6 bits. 2^6=64 will cover it. But we have allocated one whole byte (see BITS AND BYTES, above) for each odometer recording. That means that for each odometer reading, 2 bits are not needed. How can we use these 2 unused bits to make our measurements more accurate? INCREASING ACCURACY Spoiler In binary, 2 bits hold values from 0-3. It's not a lot, but it can improve the accuracy of our measurements. We can think of these values 0-3 as being fractional amounts of one whole odometer turn. 0 means 0% of an odometer turn. 1 means 25% of an odometer turn. 2 means 50%. 3 means 75%. With these two added bits, we can have numbers truncated to the nearest 25% instead of the nearest whole number. Example. Suppose the true odometer readings are 0.0 and 5.9. Using the two extra bits, our Instant Replay program would record 5.75. The error is now reduced to .9-.75=0.15 which as a percent is 0.15/5.9=2.5%. Recall that without using the two extra bits, we said the error would be 15%. So by using the two extra bits, we improved the accuracy of this measurement by 15%-2.5%=12.5%. I think the Auto Pilot in our Instant Replay program will be hitting benchmarks on time much more often if we use these extra two bits in our calculations of Target Speed. PROCEDURALLY GENERATED ROAD Spoiler We take Carol Shaw's procedurally generated river sections in River Raid as inspiration. MY CURRENT THOUGHTS Spoiler In the old days of computing, there were random numbers generators. Trouble was, they weren't really random. To humans, they seemed random, but, actually, they weren't. If you started with the same number called the seed, then you would end up with the same sequence of numbers in the output. To get a difference sequence of numbers to come out, you had to start with a different seed. For our discussion, we'll call these predictable random number generators not-so-random number generators. Well, most of the time, having predictable random number generators would be undesirable, but for the instant replay feature of our Night Driver Arcade home version, these not-so-random number generators will be exactly what we need to implement the replay without having to store data about the road. Suppose that by searching the Internet, we could find one of those not-so-random number generators. Suppose that we could confirm that, yes, if you start with the same number called the seed, then, yes, the not-so-random number generator will output the same sequence of numbers every time. Then all we would have to do is to write our Night Driver Arcade program in such a way so as to use that sequence of numbers that come out of the not-so-random number generator to direct the movements of the Mad Bomber (we use the Kaboom! analogy to describe the twisting and turning of the road in Night Driver). One way would be to let each number in the sequence represent a specific movement of the Mad Bomber, kind of like the quarterback of a football team calling plays for the offensive unit. In Night Driver Arcade, "1" might be a "play" where the Mad Bomber moves to the left edge of the screen. "2" might be a "play" where the Mad Bomber goes to the right edge of the screen. And so on. Each number that comes out of the not-so-random number generator calls a specific "play," and the Mad Bomber knows every play by heart. Thus, in order to show an instant replay of the player's last game, as far as the road is concerned, the only piece of data that we would need to know would be the value of the seed that was used to begin the not-so-random sequence. If we know the seed (suppose it was "3") then we're good to go to create the instant replay. The road will be recreated precisely as it was when the player raced on it. Every twist and turn of the road will be reproduced exactly as it happened during the game. BITS AND BYTES Spoiler We have 36 bytes of windfall RAM. To implement Instant Replay, we will use the RAM as follows: 3 bytes and 4 bits for the two 3-digit BCD counters 9 bytes to record 9 odometer benchmarks 19 bytes to record up to 19 player collisions 1 byte to record the time in seconds when the player reached his or her top speed 1 nybble to record the seed for the not-so-random number generator used to create the replay of the roads. In all, 3+9+19+1 bytes and 1 nybble and 4 bits, or 32 bytes and 2 nybbles = 33 bytes. Thus, we will use 33 bytes of the windfall RAM to implement the Instant Replay feature for this game, leaving 3 bytes remaining. THE REPLAY MENU Spoiler After the human player has finished his or her race, REPLAY Y/N appears on the screen. The player selects Y or N with the paddle and presses the paddle button to make his or her selection. If the player selected N, the program goes into ATTRACT MODE and the replay data stored in RAM is lost. If the player selects Y, the REPLAY will begin immediately. THE REPLAY Spoiler Every drawing cycle (every 3.5 frames), the program will do the following: recalculate the TARGET SPEED and thus determine if the PADDLE BUTTON should be pressed or not. recalculate the PADDLE POSITION recalculate the Mad Bomber's game state using "plays" that are "called" by the not-so-random number generator. The value of the paddle and the paddle button will be fed into the program's main loop to create the car driving graphics and sounds the same as if the human player were controlling the paddle. The program will seek to let the car accelerate or decelerate as needed to reach the TARGET SPEED all the time. Gear shifting will be fully automatic in autopilot. Autopilot can steer the car perfectly, keeping the car in the center of the road at the highest speeds on the tightest turns on the most difficult tracks and never make a mistake. However, just to be safe, collision detection will be turned off during replay. That is, during the replay, if the autopilot were to make a mistake and let the car drive into a WRM, nothing would happen. The program will continually check the odometer. If it matches the next COLLISION, then the COLLISION bit is set to 1, the screen is flashed, the crash sound is played, SPEED OF CAR is cleared to 0 and GEAR is set to 1. NOTE: The car does not need to actually hit anything. It could be in the center of the road but the program will set the COLLISION bit to 1 when the odometer reading matches. The program will seek to attain TOP SPEED at the precise odometer reading when the human player attained it. The program will seek to reach benchmark odometer readings precisely at the same moments of GAME TIME as when the human player reached them. The program will continue in this way until it approaches the final odometer value (AKA SCORE). The program will seek to arrive at this odometer reading precisely as the GAME TIME reaches zero. In this way, the computer will have created a replay of the human player's last game, featuring a perfect recreation of the road using the not-so-random number generator and the starting seed value. reaching benchmark odometer readings at the same times during the game as the human player did. enacting all of the human player's collisions at the same odometer readings as when they occurred in the game. reaching the human player's same TOP SPEED at the same odometer reading as the human player did. reaching the human player's final odometer reading/SCORE when GAME TIME expires. AFTER THE REPLAY Spoiler I think the screen will again show REPLAY Y/N as it did in the beginning, inviting the player to see the replay again. The replay could be shown as many times as the player would like. When the player answers N, then the program will go into the ATTRACT MODE and all of the 36 bytes worth of saved replay data will be lost. GAME FORMAT CHANGES Spoiler COLLISIONS The unknown quantity for replays would be the number of collisions. Theoretically, a player could have a new collision every three or four seconds. If the number of collisions is normal, I think 36 bytes would be enough. But if the number of collisions would be excessively high, then I think 36 bytes would not be enough. How to handle this problem? ADJUSTMENTS To address this issue, the following changes are proposed. No 200-second replays. Only 100-second replays. If the person gets the BONUS, then The player plays the first 100 seconds Then the player views the replay (100 seconds) Then the player plays the BONUS 100 seconds (if score was 350 or higher) Then the player views the replay of the BONUS time (100 seconds) Then the game enters the ATTRACT MODE showing the combined score of regular time + bonus time (200 seconds) In this way, the player could still earn bonus time as in the arcade, but it would be played as two separate 100-second games with a combined score at the end, with 100-second replays after each game. WHAT IF THERE ARE MORE THAN 19 COLLISIONS? Spoiler If a player has more than 19 collisions during his or her game, then the Instant Replay will stop after the 19th collision. The reason being that, internally, there was only sufficient RAM to store data for up to 19 collisions. MY THOUGHTS Spoiler I think that 19 collisions is a pretty good number, though. A game is only 100 seconds long. To have 19 collisions in 100 seconds, a player would have to average a new collision ever 5.2 or 5.3 seconds. When you consider that it takes a few seconds for the car to accelerate to dangerous speeds from a full stop after each collision, it really doesn't seem likely that a player trying his or her best would get into that many collisions. But, if they do, that's fine. The replay will show everything up to the 19th collision. 1 Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted August 1 Author Share Posted August 1 SCORING ADJUSTMENT Spoiler Why should a player care what his or her TOP SPEED was during a game? I propose a scoring change. SCORING CHANGE Let the player's final score at the end of the game be ODOMETER + TOP SPEED. Example. On the Novice Track, a player's final odometer was 200 and his or her top speed was 150. Then, the player's final score would be 350. Thus, TOP SPEED becomes a part of the player's final score. If the player earned the BONUS time, then the formula would be final score = ODOMETER (first 100 seconds) + ODOMETER (second 100 seconds) + TOP SPEED (the best of the two games). Also, having a single, combined score at the end of each game facilitates the ranking of players' scores for the purpose of participation in high score clubs. 1 Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted August 3 Author Share Posted August 3 THREE GEAR SHIFTING OPTIONS Spoiler If space in the ROM permits, I would like the game to offer the player three gear shifting options as follows. Fully automatic shifting - Just hold down the paddle button and the computer will automatically shift gears for you all game long. Paddle button shifting - The player must shift up to the next gear by using the "release and squeeze" technique at the right times during the game. The player has no way to shift down but the player can let off the accelerator and the computer will automatically downshift when the car decelerates. Joystick shifting - Plug a joystick into player 2's controller port and secure it to a flat surface in front of you with Velcro and use it like a four-speed gear shifter to shift gears just like in the arcade version. 1 Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted August 4 Author Share Posted August 4 NEW SCREEN LAYOUT Spoiler IN ORDER FROM LEFT TO RIGHT GEAR (1-4) ODOMETER: 3 DIGITS COUNTING UP FROM 0 TO 999 GAME TIME: 2 DIGITS COUNTING DOWN FROM 99 TO 0 SPEED BAR (VARIES BY GEARS) Introducing the SPEED BAR - It is a progress bar that moves to the right as SPEED OF CAR increases and moves to the left as SPEED OF CAR decreases. - It shows "where you are" in terms of the speed range of the gear that the car currently is in. If the car is in first gear, the SPEED BAR will go from 0-30. If the car is in second gear, the SPEED BAR will go from 30-60. If the car in in third gear, the SPEED BAR will go from 60-90. And if the car is in fourth gear, the SPEED BAR will go from 90 to MAX SPEED which is 200 for NOVICE, 300 for PRO and 350 for EXPERT. - When the car is accelerating, if the SPEED BAR goes all the way to the right, then it is time to shift up to the next higher gear. - When the car is decelerating, if the SPEED BAR goes all the way to the left, then it is time to downshift to the next lower gear. 0003_6digitscore_demo_v2.bas.bin 1 Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted August 5 Author Share Posted August 5 SIMULATED COIN-OP SELF-TEST Spoiler Phosphor effect was used to capture this screenshot. Turn off phosphor when running the program. We enhance the coin-op flavor of this Atari 2600 home version of Night Driver with a short, simulated, arcade self-test at "start up." The Real Arcade Self-Test Spoiler If you're curious, the real arcade self-test screen looks like this. This image can be found in section 5.3 on page 14 of the Night Driver Operation, Maintenance and Service Manual. After the animation finishes, press F2 (if you're using Stella)/reset to see the animation again. 0003_startup_v3.bas.bin 1 Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted August 6 Author Share Posted August 6 A LOT LESS TINY Spoiler The Tiny font characters in the 6-digit score display are now 2 pixels higher and 2 pixels wider. More Spoiler This is the number 8 in the original Tiny font. It is 3 pixels wide and 5 pixels high. HIGHER Actually, at first, I was only going to make the font 1 extra pixel higher. But if you do that, then either the top of the 8 will be bigger or the bottom will be and neither looks right. Does it? This leads to the realization that the digit must be 2 pixels higher, like this. This 8 is 3 pixels wide and 7 pixels high and it looks "right." Doesn't it? WIDER Similarly, at first, I was only going to make the digits one pixel wider. Again, here is the number 8 in the original Tiny font. It is 3 pixels wide and 5 pixels high. If you use the original Tiny font digits to make a 3 digit number, the digits are 5 pixels apart, like this. <--- 5 pixels ---><--- 5 pixels ---> Now, suppose you make the digits 1 pixel wider. Then, when you make a 3 digit number, either the spacing on the one side will be short 1 pixel <--- 4 pixels ---><--- 5 pixels ---> or on the other side <--- 5 pixels ---><--- 4 pixels ---> and either way, the spacing won't look quite right. Will it? So, then you realize that you must make the digits 2 pixels wider so that the spacing will be equal on both sides, like this <--- 4 pixels ---><--- 4 pixels ---> And now the spacing looks right. HIGHER AND WIDER Put it all together and you have 5 pixels wide and 7 pixels high Each individual digit looks right, and as part of a 3 digit number, they are evenly spaced. <--- 4 pixels ---><--- 4 pixels ---> MY THOUGHTS I like this modified Tiny font for the 6-digit score display of our game. It's bigger and much easier to read It still retains the style of the original Tiny font, which IMO looks good as a font for an arcade game Now it matches the height of the PF score bars on either side much better, making the layout look much nicer IMO Later, I plan to use the hex characters to add some alphabet letters to the display. And I have come to understand that certain alphabet letters require more pixels to be drawn. A "W," for example. So, increasing the heighth and width of the digits 0-9 will help us later when we want to add a few alphabet letters to the display. Finally, this display is very important in our game. It's the player's score and the time remaining. It ought to be large enough to be easily seen. I think it is now. 0003_6digitscore_demo_v6.bas.bin 1 Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted August 8 Author Share Posted August 8 ARCADE CABINET VIEW Spoiler Use the paddle controller. It's not a game that you can play, but you can turn the steering wheel with the paddle and press down the accelerator pedal with the paddle button. This cabinet view could have possible uses in Night Driver Arcade as a graphic for a title screen or perhaps a built in minigame. Regardless, this cabinet view is being developed here as a stand-alone Night Driver Arcade minigame. 0003_cabinet_v5.bas.bin Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted August 24 Author Share Posted August 24 PROJECT STATUS Spoiler Sorry for the delays. When I get around to it, the tentative plan is to finish the mini game version first and then come back here and resume working on this, the full version. I see the mini game version as being a valuable step for me, personally. Here's why. Spoiler It would be nice to finish something. Spoiler I have yet to actually finish anything homebrew-wise. It would feel good to actually finish something. IMO the mini game version is excellent preparation for writing the larger program. Spoiler Programming-wise, the mini game version has (or will have) many of the same elements as the main version of the program. They both have (or will have): Two main loops, an attract mode loop and a game mode loop. Common resources such as sprite bit maps being located in subroutines at the bottom of the program and accessed by gosub and return commands to both main loops. And making the mini game version can give me valuable practice with things such as: using an 8.8 fixed decimal counter. using DIM statements to give the a-z bytes of RAM human readable names. addressing single bits and perhaps single nybbles to use RAM more efficiently. using the 6-digit display including the 6 hex characters. using the Atari color palette, especially in the attract mode (if I decide to do that; not sure yet). using sounds, some kind of basic sounds that will be needed to finish the mini game. setting up a debouncing bit for the game reset switch. troubleshooting bugs. And more. So, by finishing the mini game version first, not only will I gain a sense of achievement but also be better prepared to write the larger, full version of the program. 1 Quote Link to comment Share on other sites More sharing options...
LatchKeyKid Posted August 24 Share Posted August 24 Quote It would be nice to finish something. I have yet to actually finish anything homebrew-wise. It would feel good to actually finish something. IMO the mini game version is excellent preparation for writing the larger program. I definitely feel you there and, as you know, took a couple months off myself. Sometimes writing a smaller program within some strictly defined limits can be a refreshing break to learn some new techniques without worrying about incorporating them into a bigger and more complex existing program without risking breaking what's already working and discouraging yourself. Alternatively, sticking with the larger program but simply focusing on a discrete chunk with a specific goal might also keep you motivated (like incorporating a single aspect/feature over the course of a week/month). 2 Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted August 25 Author Share Posted August 25 @LatchKeyKid Exactly. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted August 25 Share Posted August 25 I get the feeling retail era developers experimented until they found an outstanding graphical feature and ran with it. My life has gotten a lot easier by thinking about what my skills and the 2600 can do above my own desired game design. 2 Quote Link to comment Share on other sites More sharing options...
LatchKeyKid Posted August 25 Share Posted August 25 10 hours ago, Gemintronic said: I get the feeling retail era developers experimented until they found an outstanding graphical feature and ran with it. My life has gotten a lot easier by thinking about what my skills and the 2600 can do above my own desired game design. Yeah, I can even begin to comprehend the imagination and patience necessary to conceptualize and code a game while just looking at a sheet of printer paper and blinking lights... I don't know if I'm not considering or realizing a key limitation (I probably am!) but I'm shocked that Atari's first priority wasn't developing a suite of tools and hardware for the almost simultaneously released Apple II (fully expanded) to develop and compile games locally instead of remote time share computing. 1 Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted August 26 Author Share Posted August 26 INSTANT REPLAY - MORE DETAILS Spoiler If anyone is interested, I worked out more details about how the 36 bytes of windfall RAM will be used to make the instant replay. To see the new information, go to this post WINDFALL RAM and open the sections on RE-ENACTMENT VS. REPLAY, RECORDED INFORMATION, BITS AND BYTES and WHAT IF THERE ARE MORE THAN 19 COLLISIONS? and you will see it. Quote Link to comment Share on other sites More sharing options...
LatchKeyKid Posted August 26 Share Posted August 26 Instant replay sounds like a great feature and definitely not something I would expect on the 2600! 1 Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted August 27 Author Share Posted August 27 @LatchKeyKid Thank you. I have my fingers crossed. I hope it will work. INSTANT REPLAY - INCREASING ACCURACY Spoiler If anyone is interested, I wrote a new bit called INCREASING ACCURACY. You can find it in this post WINDFALL RAM under RECORDED INFORMATION. It talks about using two unused bits to make odometer recordings more accurate. Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted August 29 Author Share Posted August 29 INSTANT REPLAY TWEAKS; WINDFALL ROM; PRNG'S Spoiler Instant Replay Tweaks Spoiler Fixed Mistake Spoiler A 3-digit BCD counter uses 3 nybbles (0-15), not 3 bytes (0-255). Instant Replay will have two 3-digit BCD counters, one for mileage and one for collisions. Together, they will use 6 nybbles = 3 bytes, not 6 bytes. I made the correction in BITS AND BYTES of WINDFALL RAM. So we have 3 bytes more now. That's very good. Mileage Counter Tweaks Spoiler To review recent changes, mileage will still be recorded using bytes. 9 mileage benchmark recordings = 9 bytes. We realize that only 6 bits 0-63 will be needed to record mileage. That leaves 2 bits unused. We already had decided that these two unused bits will now represent 1/4 turns of the odometer. That is, instead of merely recording "5", we can now record, more accurately, either 5.0, 5.25, 5.5 or 5.75. Accordingly, the following additional new changes are made: 2 bits will be added to the 3-digit BCD odometer in the Instant Replay program to record quarter turns of the odometer. And another 2 bits will likewise be added to the 3-digit BCD odometer in the main game program (the one that displays the odometer on the screen). Thus, recording odometer readings will become very easy using this process: 1) set the 2 bits of the main game odometer to indicate the number of quarter turns of the odometer 2) The 2 bits of the Instant Replay odometer were already set before 3) subtract the game odometer (including 2 extra bits) from the Instant Replay odometer (including 2 extra bits). That is the distance travelled since the last bench mark reading 10 seconds ago. It is a number from 0-63. Store it in RAM using one byte. 6 bits to store the whole number value 0-63 and two bits to indicate the number of quarter turns of the odometer also. 4) Finally, write the value of the game odometer to the Instant Replay odometer (including the 2 extra bits). The two odometers are now ready to make the next odometer recording 10 seconds later. Top Speed Recording Tweak Spoiler Recall that the regular game program already records TOP SPEED. Instant Replay only needs to record when it happened. The change is that now, Instant Replay will now record when the Top Speed occurred in terms of Game Time in seconds, not distance on the odometer. Game Time in seconds is a number from 0-100. It can be stored in a single byte using only 7 bits 0-127. The 8th, unused bit will now be used to indicate in which half of a second it occurred. "0" indicates the bottom half 0-.5 and "1" indicates the top half .5-.9999. For example, if the Top Speed occurred at precisely 50.9 seconds into the game, "50" will be recorded by the first 7 bits, and "1" will be recorded by the 8th bit to indicate the fractional amount is more than .5 and less than 1.0. Collision Recording Tweaks Spoiler Collisions will now be recorded in terms of time in seconds. The game has 100 seconds. We will record time using whole bytes. We will use 6 bits of the byte 0-63 to record the whole number amount of time in seconds, leaving 2 bits of the byte unused. The 2 unused bits of the byte 0-3 will record quarters of a second. Actually, we will only record collisions from 0-62 seconds. If "63" is recorded, that will have a special meaning. It will mean that for 62 seconds, there were no collisions. 62 seconds will be added to the 3-digit BCD counter but no collision will be registered in the game. Thus, each collision recording will still be one byte. 19 collision recordings will still equal 19 bytes. Recording seconds will be better. If multiple collisions happen in rapid succession one right after another, the odometer method will not be accurate enough because the car barely moved between collisions. However, the way the game is designed, each collision will use up at least 2 seconds. That is, there will always be at least 2 seconds between collisions. Recording collisions by time in seconds will produce a more accurate replay. Bits 'n' Bytes Update Spoiler Updated Bits 'n' Bytes for Instant Replay, taking into account all of the above tweaks. Reposted from WINDFALL RAM. We have 36 bytes of windfall RAM. To implement Instant Replay, we will use the RAM as follows: 3 bytes and 4 bits for the two 3-digit BCD counters 9 bytes to record 9 odometer benchmarks 19 bytes to record up to 19 player collisions 1 byte to record the time in seconds when the player reached his or her top speed 1 nybble to record the seed for the not-so-random number generator used to create the replay of the roads. In all, 3+9+19+1 bytes and 1 nybble and 4 bits, or 32 bytes and 2 nybbles = 33 bytes. Thus, we will use 33 bytes of the windfall RAM to implement the Instant Replay feature for this game, leaving 3 bytes remaining. Windfall ROM Spoiler Special thanks to @Atarius Maximus for sharing this. We will save 354 bytes of ROM by commenting out pf_scrolling and pf_drawing. PRNG's Spoiler I did a little reading about psuedo-random number generators. For example, here at Wikipedia. Recall that we plan on using a PRNG to create a randomly generated road. I think bB's built in function, rand, will work perfectly. Just need to build a demo and test it. You can set the seed (starting value). I assume that since it's the built in function, it is already optimized for speed and will use fewer processor cycles than if we were to use a formula. Rand returns a byte 0-255. Perhaps the bytes could be read two at a time. Two bytes equals four nybbles. Perhaps the first nybble 0-15 could indicate the "play" and the other three nybbles could provide additional information. For example, if the "play" were to go to a given coordinate, then the other three nybbles could tell the speed (one nybble 0-15) and the x-coordinate of the target location (one byte 0-255). Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted August 31 Author Share Posted August 31 CINEMATIC VIEW Spoiler Cinematic View is an optional view for Instant Replay planned for NDA 16k. It will consist of external camera shots. It will look like you're watching a movie of your last race. The Cinematic Views Spoiler Cinematic View #1: Car Coming Directly Towards the Camera Duration: 7 pairs of WRM's. Description of the Camera Shot Spoiler The road is reversed. The camera is looking backwards down the road. In the darkness, all you can see of the road are the stationary WRM's. It's night. The car is at the distant horizon, coming straight toward you. In the darkness, all you can see of the car are the two headlights coming closer and closer and getting larger and larger. The car drives right up to the camera in the foreground, reaching max size. Collision with the camera seems imminent (but does not occur). The scene ends with the screen flashing white for an instant as the car's headlights flood out the entire screen with white light. Cinematic View #2: Car Going Directly Away From the Camera Duration: 7 pairs of WRM's. Description of the Camera Shot Spoiler It's night. The road extends out toward the horizon. The camera is looking straight down the road. In the darkness, all you can see of the road are the stationary WRM's. The car is going forward down the road. In the darkness, all you can see of the car are the two, red tail lights getting smaller and smaller as the car gets farther and farther away. When the car reaches the distant horizon, the scene ends. Cinematic View #3: Side View Duration: 7 pairs of WRM's. Description of the Camera Shot Spoiler The road is horizontal across the screen. This shot could be filmed either from right-to-left or from left-to-right. Let's use left-to-right as an example. The camera is beside the car, matching the speed of the car, moving with it. It's night. You can see the vague outline of the car, but not a lot of details. You can clearly see the two wheels on your side of the car bouncing up and down. The car body, however, glides above smoothly. White road markers whiz by at intervals, indicating the speed of the car. When 7 pairs of WRM's have whizzed by, this scene ends. Cinematic View #4: Complicated Shot Duration: 14 pairs of WRM's. 7 pairs of WRM's when the car is coming and 7 pairs of WRM's when the car is going. Description of the Camera Shot Spoiler This shot works best if the section of the road is mostly long and straight. This shot could either be done from right-to-left or from left-to-right. Let's use right-to-left as an example. The camera is off the road, beside the road. The road goes across the screen horizontally. The car begins at the horizon on one side, cuts across the TV screen horizontally, and ends at the horizon on the other side. The camera is at all times during this shot aimed at the car. We can break this complicated shot into two separate shots. SHOT A: FROM RIGHT HORIZON TO 12 O'CLOCK It's night. The car starts at the horizon on the right side. The camera is turned to the right at about 2:30 on the clock. All you can see of the car are it's two headlights coming toward you. The car is coming closer, moving from right to left. At first, the car seems to be coming right at you, but the camera is not on the road. The camera is beside the road. As the car comes closer from right to left, the camera pivots to stay focused on the car and the car passes by a few feet in front of the camera. When the car is directly in front of the camera, the camera is now facing 12 o'clock, directly head. The car whizzes by the camera in a blur. SHOT B: FROM 12 O'CLOCK TO THE LEFT HORIZON It's still night. Now the car is moving away from the camera, toward the horizon on the left side of the road. Now, all you can see of the car are it's two red tail lights as it's driving away. The car continues moving from right to left toward the distant horizon on the left, the two red tail lights getting smaller as the car gets further away. And the camera continues pivoting to the left, staying always focused on the car. This scene ends when the car has reached the horizon on the left. When this scene ends, the camera will be turned to the left at about 9:30 on the clock. How to Do This Shot Spoiler ABOUT DOING THIS SHOT Spoiler Panning the camera is going to be the big trick in order to do this shot. To compute the (x,y) coordinates of the objects on the screen as the camera pans from one side to the other, I think we're going to need to use something called a "Rotation Matrix." I found a page in Wikipedia about it. We'll need to include some basic trig tables at the end of our bB program. Sin, cos, inverse sin, inverse cos. Just for a few angles. We can use linear interpolation to find trig values of more angles in between as needed. We'll need to break up the matrix equations into separate equations and do them one by one without using matrix math. The reason I think we can do this shot is because there are so few objects on the screen at once. Just a few pairs of white road markers (WRM's) and either the car's headlights or tail lights. I'm sure it will be tricky, but how many computations can there be with so few objects? References: Panning (Cameras) - Wikipedia Rotation Matrix - Wikipedia Linear Interpolation - Wikipedia THE 10-STEP PROCEDURE FOR DOING THIS SHOT Spoiler 1. THE GIVEN INFORMATION Spoiler THE FIRST 7 WRM'S We may have to do a few computations, but, effectively, at the start of the scene, we know: the (x,y) coordinates of the car and of each headlight and tail light if desired the (x,y) coordinates of all 14 white road markers (WRM's) the path of this section of road in the x-y plane the length of this section of road THE SECOND 7 WRM'S This information will be computed in real time during the first half of the scene. It will be available when the car arrives at the 12 o'clock position. 2. THINKING STEP: DRAW THE ROAD ON A PIECE OF PAPER LAYING FLAT ON THE TABLE Spoiler Lay a piece of paper down flat on the table. Draw an x-y coordinate system on it. Draw the road on the line y=1 from about x=70 to x=-70. The point (0,1) will be the midpoint of the road. The camera for this shot will be at the origin (0,0). Label the (x,y) coordinates of every pair of WRM's and the car. 3. LIMIT THE NUMBER OF OBJECTS TO BE COMPUTED Spoiler Each computation in bB uses valuable processor cycles. To save processor cycles, we only want to do computations on objects that are within the view of the camera. We can do this simply by applying the following rule. Only draw the car and the next two pairs of WRM's in front of the car. It will make sense, visually. It's night time in the game and it will appear that the car's headlights only can reach far enough to illuminate the next two pairs of WRM's. 4. FIND THE ANGLE THETA NEEDED TO AIM THE CAMERA AT THE CAR Spoiler The camera is at (0,0) on the graph. We know the (x,y) coordinates of the car also. To find the angle, theta, needed to aim the camera at the car, use the formula theta=arctan(y/x). NOTE: We will need to add the tables for inverse tangent to do this in bB. 5. ROTATE THE GRAPH BY THETA DEGREES AND AIM THE CAMERA AT THE CAR Spoiler In the previous step, we found the angle, theta, needed to aim the camera at the car on the road. Now use the ROTATION MATRIX to rotate the map on the table by theta degrees. Doing so should result in the camera pointing directly at the car on the road. NOTE: bB doesn't do matrix math, so we will break up the matrix equation into separate equations and compute them one by one. 6. CHANGE OF COORDINATE SYSTEM Spoiler Once the camera is aimed at the car, we will change the coordinate system of the graph on the table. On the paper laying flat on the table, draw a line straight from the camera to the car. That line is now the new z-axis. On the paper laying flat on the table, draw a line perpendicular to the z-axis and passing through (0,0). This is the new x-axis. The new y-axis can't be drawn on the paper. It is comes straight up out of the paper and points toward the ceiling, and it goes straight down out of the paper toward the floor under the table. 7. NEW COORDINATES FOR OBJECTS ON THE MAP Spoiler Now that the map on the table has a new coordinate system, we can give all of the objects on the graph new coordinates using this new coordinate system. Since the car and the WRM's all lay flat on the graph paper on the table, in the new coordinate system, all of them will have y-coordinates of 0. The new x-coordinates for each object can be found graphically by placing your eye at the origin, where the camera is, and looking toward the car and then measuring sideways to the left and right. The new z-coordinates for each object can be found graphically by measuring the distance from the new x-axis to the objects. The new x, y and z coordinates were computed by the ROTATION MATRIX in a previous step. Recommendation: Before going on to the next step, take a moment to look at the map and verify that the new coordinates you calculated for the objects in the picture seem to be correct. 8. DIVIDE X AND Y COORDINATES BY Z TO APPLY DISTANCE PERSPECTIVE Spoiler In real life, the farther away things are, the smaller and slower they appear to be. To add this perspective of distance to our video game graphics, simply divide the x- and y- coordinates of every object by its z-coordinate. 9. TILT THE SCREEN Spoiler If you place your eye on the level of the table and look across the graph paper from the camera to the car, you will see what will be drawn on the screen. Everything will be in one horizontal line, flat across the middle of the screen. Perhaps the scene would look a little more interesting if we tilted it a little? Use the SHEARING MATRIX to tilt the scene so that the foreground is lower than the horizon. NOTE: bB doesn't do matrix math, so we will break up the matrix equation into separate equations and do the computations for each object one by one. Then, when you draw the sprites, there will be a slight "tilt" of the screen upward toward the horizon. It will be as if the camera were a little up in the air and looking downward slightly. It will let you see more of the road. 10. DRAW AND REPEAT Spoiler Now, the computations are all finished and it is time to draw the objects on the screen. As we all know, in bB, there is no frame buffer. Apply the above steps to every coordinate of every object that must be drawn and keep calling drawscreen until all objects have been drawn. When all objects have been drawn, that is the end of the drawing cycle. Now, go back to step one and go through the entire 10-step process again for the next drawing cycle. Remember, for this shot, keep the camera aimed at the car. Every drawing cycle will have a new and different coordinate system because the angles change every time the car moves down the road with respect to the camera. DEFINITIONS frame: one occurrence of calling drawscreen in bB. drawing cycle: When using flicker, it's the number of frames needed to draw all of the objects on the screen one time. Example. In the game, it's night and the car is coming towards the camera. We can only see the car's two headlights coming towards the camera and the two pairs of WRM's in front of the car. We will draw the two headlights of the car and two pairs of WRM's in front of the car. Totally, we will draw six objects. We have two sprites, P0 and P1, with which to draw these six objects. We can't draw all six objects in one frame. We will use flicker and draw the objects two at a time over multiple frames. Drawing six objects with two sprites using flicker will take three frames. Thus, three frames will be the drawing cycle to draw the six objects. 3D TURNING EFFECT FOR THE CAR Spoiler We will create a realistic 3D turning effect for the car simply by modulating the distance between the headlights or tail lights. DETAILS When the car is facing the camera, the angle between the car and the camera is 0 degrees and the headlights should be the full width of the car apart. When the car is facing 90 degrees either to the right or to the left of the camera, the two headlights should appear to be merged into a single headlight. When the angle between the car and the camera is less than 90 degrees, then the distance between the two headlights should be set according to the following formula: distance between headlights = the full width of the car * cos(angle between car and camera). Thus, the headlights will be furthest apart when the car appears to be coming straight at you. When the car is turning away from you, the headlights will come closer together. The concept for tail lights is basically the same except the car is going away from the camera. HOW TO FIND THE ANGLE THAT THE CAR IS FACING Spoiler NOTE: In Instant Replay mode, the car will drive in straight lines from one pair of WRM's to the next. Thus, in Instant Replay mode, the car only "turns" as it passes through pairs of WRM's. Given: the (x,y) coordinates of the midpoint of the road at the previous pair of WRM's that the car passed. Given the (x,y) coordinates of the where the car is now (which should also be at the midpoint of the road). Then use the inverse tangent to find the angle that the car is facing right now. 3D Sound Effects Spoiler Loudness Whenever the car is coming toward you, the engine sounds will get louder. Whenever the car is moving away from you, the engine sounds will get softer. Doppler Sound Effect Whenever the car is coming toward you, the pitch of the engine sounds will be raised slightly. Whenever the car is moving away from you, the pitch of the engine sounds will be lowered slightly. Sample Cinematic Sequences Spoiler CINEMATIC VIEWS ONLY Spoiler CV#1: The car coming directly toward you CV#2: The car going directly away from you CV#3: Side View, Left to Right CV#1: The car coming directly toward you CV#2: The car going directly away from you CV#4: Complicated Shot, Right to Left CV#3: Side View, Right to Left CV#4: Complicated Shot, Left to Right CV#3: Side View, Left to Right CV#2: The car going directly away from you CV#2: The car going directly away from you MIX OF CINEMATIC VIEWS AND GAME VIEW Spoiler CV#3: Side View, Left to Right GAME VIEW: View from inside cockpit of car CV#2: The car going directly away from you GAME VIEW: View from inside cockpit of car CV#3: Side View, Left to Right CV#4: Complicated Shot, Right to Left CV#3: Side View, Right to Left CV#4: Complicated Shot, Right to Left GAME VIEW: View from inside cockpit of car CV#2: The car going directly away from you Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted August 31 Author Share Posted August 31 PLANNING FOR NIGHT DRIVER ARCADE 4K, 8K AND 16K VERSIONS (UPDATED) Spoiler We will plan for three separate releases of Night Driver Arcade in 4k, 8k and 16k ROM sizes. First will be the release of the Night Driver Arcade mini game. Then the 4k, 8k and 16k versions in that order. Updated Plan for NDA 4k, 8k and 16k Versions (UPDATED) Spoiler Night Driver Arcade 4k No extra features. The arcade classic for your Atari 2600. The main game program Scripted roads for Novice, Pro and Expert Attract mode (B&W, arcade-style) Note: We will comment out pf_scrolling and pf_drawing to gain back 354 bytes of ROM Night Driver Arcade 8k Everything that the 4k version has, plus: Instant Replay (Game View) - Watch a replay of your last performance. (It looks just like when you're playing the game, except the computer is controlling your car.) Ghost Car - A single race against a ghost car re-creating your last performance. Night Driver Arcade 16k Everything that the 4k and 8k versions have, plus: Ghost Rally Racing - Race to win in a series of rally races against ghost car opponents. Cinematic View: An alternate view for Instant Replay. Uses external camera shots during the replay. It looks like you're watching a movie of your last race. Unused Now (Could Be Added Later) Spoiler Pace Car - single races Catch the Pace Car - series of races Psuedo-randomly generated roads Alternate, scripted roads for Novice, Pro and Expert Fake self-test start-up screen Arcade Cabinet View: It looks like you're standing in the arcade. QUESTION: Can we use RevEng's Multikernel Framework to pull all of the parts of NDA (including the mini-game version) together into one ROM? References Spoiler Special thanks to @RevEng for sharing these: bB Multikernel Framework Organizing a Large, Multibank Game Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted September 5 Author Share Posted September 5 RACING AGAINST YOUR GHOST CAR Spoiler I'm pleased and excited to announce this new mode of game play for Night Driver Arcade. FORWARD Spoiler When I first became aware of the WINDFALL RAM back on July 30, I suddenly had a quite-unexpected "problem" to solve: "What to do with an additional 36 bytes of RAM?" (I repeat, that is more RAM than we used to design the entire game up to that point.) I began brainstorming. One idea that resulted from that brainstorming was Instant Replay, which I have since written about. Another idea, though, that I have not yet written about, was Racing Against Your Ghost Car. The reason I did not write anything about it up until now is because I hadn't worked it out yet and/or I didn't think it was possible. It turns out that Racing Against Your Ghost Car is very similar to Instant Replay (the same data that is stored for Instant Replay will be used to create your ghost car), and having already worked out most of the details of Instant Replay, it really wasn't difficult to see how to do Racing Against Your Ghost Car. WHAT IS RACING AGAINST YOUR GHOST CAR (RAYGC or GHOST CAR for short)? Spoiler You race against a computer-controlled car that is replaying your last performance. There are no collisions between your car and the "ghost car." If the two cars touch, your car merely passes through the ghost car, thus the name. WHAT WILL GHOST CAR LOOK LIKE IN NIGHT DRIVER ARCADE? Spoiler In NDA, after you finish a game, you will be given the option to view the replay. Furthermore, if you had approximately 14 or fewer collisions, then you will also be given the option to race against your ghost car. In GHOST CAR, you drive your car as usual; however, at the same time, AutoPilot will be driving the ghost car. Thus, two cars will now be driving down the same road at the same time! AutoPilot will be driving the ghost car, mimicking your last performance, including ten odometer benchmarks and your TOP SPEED and up to 14 collisions. There are no collisions between your car and the ghost car. Your car passes through the ghost car when they touch. To pass the ghost car on the road, simply pass through it. Conversely, the ghost car can pass through your car to pass you on the road. Your car and the ghost car can still collide with the left and right sides of the road, as usual in Night Driver. This is a race between you and the ghost car. Either you win the race or the ghost car wins the race. The race lasts for 99 seconds. The timer counts down the time left. When the timer reaches 0, whichever car is in first place will be the winner. Sometimes during the race, you will see the ghost car in front of you. When you do, you will only see it's red tail lights. During the race, the 6-digit display will show you how far ahead or behind you are from the ghost car. For example, +2 means that your car is 2 odometer turns ahead of the ghost car. -2 means that the ghost car is 2 odometer turns ahead of you! At the end of the race, your odometer reading (-99 to +99) is your score; meaning, how far ahead or behind the ghost car you finished. MODIFIED 6-DIGIT DISPLAY Spoiler The 6-digit display at the bottom of the screen will be modified for GHOST CAR races. The first three digits will no longer display the odometer. Instead, they will show how far ahead or behind the player is from their ghost car. The first digit will either be a "+" or a "-". The next two digits will be 0-9. Thus, the first three digits can go from -99 to +99. If your car is more than 99 odometer turns in front of the ghost car, the display will show "+++". If the ghost car is more than 99 odometer turns ahead of you, then the display will show "---". The last three digits of the 6-digit display will be as usual; a space followed by two digits 0-9 to show the time remaining in the game, in seconds, counting down. SOME DETAILS OF IMPLEMENTATION Spoiler Given: We have the 36 bytes of Windfall Ram; and Instant Replay (Game View is sufficient) has already been added and is working fine. Task: Now add Racing Against Your Ghost Car (RAYGC or GHOST CAR for short). Recall that Instant Replay has stored into RAM odometer readings from the human player's last game and also the times of collisions. Also, the time when the player's TOP SPEED was reached. Recall also that Instant Replay has a subroutine called AutoPilot that can drive the car like a human player. Thus, with the recorded data, AutoPilot can drive the car and recreate the human player's last game. To implement GHOST CAR, we just need to add a few new things. To drive the ghost car, AutoPilot will need: a 5-digit BCD odometer (###.##) 0-999 and two decimal places a 5-digit BCD register for SPEED OF GHOST CAR (###.##) 0-999 and two decimal places two bits for the ghost car's gear 0-3 Flicker Management Spoiler When the ghost car is not on the screen, the program will draw 7 pairs of WRM's as usual; (7x2=14 objects) but, when the two red tail lights of the ghost car are visible on the screen, then the program will only draw 6 pairs of WRM's. (2 tail lights + 2x6 WRM's =2+12=14 objects) Thus, the total number of objects to be drawn on the screen and the amount of flicker would be the same. UPDATED HEX CHARACTERS Spoiler The 6 hex characters for the 6-digit display currently are: space, :, T, S, + and -. At the end of a normal game, 1: 999 your odometer from first 100 seconds 2: 999 your odometer for the second 100 seconds if you had bonus time TS 999 your TOP SPEED is also added to your score 9999 your total score, left-justified. It's the sum of the three numbers, above. GHOST CAR +99 indicates that your car is 99 odometer turns ahead of the ghost car -99 indicates that the ghost car is 99 odometer turns ahead of you Special thanks to @SeaGtGruff for sharing how to define hex A-F in the score_graphics.asm file. BITS AND BYTES Spoiler Before GHOST CAR, we had 3 bytes out of 36 bytes of Windfall RAM left. Additional RAM needed to implement GHOST CAR: 5-digit BCD odometer for ghost car: 5 nybbles 5-digit BCD register for SPEED OF GHOST CAR: 5 nybbles GEAR OF GHOST CAR (0-3): 2 bits Totally, 10 nybbles and 2 bits = 5 bytes and 2 bits Recall that Instant Replay reserves 19 bytes for collisions. We can take the 2 bits from the leftover Windfall RAM of 3 bytes. We can take the other 5 bytes from the 19 bytes of collision storage in Instant Replay. Thus, the player can race against his or her ghost car if he or she had 14 or fewer collisions. UPDATED WINDFALL RAM After implementing GHOST CAR, we will have 2 bytes and 6 bits of the 36 bytes Windfall RAM left over. Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted September 8 Author Share Posted September 8 RALLY RACING Spoiler INTRO Spoiler I was looking for a few good ideas for a few different game modes for NDA and I think RALLY RACING is definitely one good possibility. WHY HAVE DIFFERENT GAME MODES? Spoiler Atari has a great tradition of it. If you think back, I'm sure you'll remember this example. Indy 500 Game Modes Spoiler Race Car - the standard game, the one we think of as being Indy 500. But there was also... Crash 'n' Score - The first player to drive into the randomly positioned white square gets one point. The first player to get to 50 points wins. Crash 'n' Score Time Trials - The player with the most points at the end of 60 seconds is the winner. Tag - like the game we played as kids, but using race cars. The first player to get to 99 points is the winner. Ice Race - The first player to complete 25 laps is the winner. Ice Race Time Trials - The player with the most laps after 60 seconds is the winner. Indy 500 game manual at Atari Compendium I think you get the idea. Atari had many games with multiple modes of game play. Which other Atari games with multiple game modes do you remember? WHAT IS RALLY RACING MODE IN NDA? Spoiler You start in last position in a rally race. You have 99 seconds. You will pass the other cars one at a time. You must finish in 1st, 2nd or 3rd place to advance to the next race. WHAT WILL RALLY RACING IN NDA LOOK LIKE? Spoiler The road will be wider so there will be room to pass the other cars. The first 3 digits of the 6-digit score tells you your position in the race. Note: I'd like to have it say "1st" instead of just "1" and "2nd" instead of just "2" etc. but we'll see what we can do there. Before play starts, the player selects Novice, Pro or Expert tracks. Top speed in Novice is 200; in Pro it's 300 and in Expert it's 350. That's your top speed. The other cars will be going less than your top speed. You drive your car mostly as usual in NDA. You still will crash if your car hits the sides of the road. If your car touches another car, the two cars will bump off each other. You only will see the tail lights of the other cars in front of you. To pass another car, you must go around it without touching either the car or the sides of the road. When you successfully pass a car, the 6-digit display will subtract one from your position in the race. When the timer runs out after 99 seconds, the race is over. You will be awarded 25 pts for 3rd place, 50 points for 2nd and 100 points for 1st. NOTE: Add your TOP SPEED to your score also? At the end of each race, your updated score is displayed. You must finish 1st, 2nd or 3rd to advance to the next race. The next race will begin with your car positioned one place further back. For example, if in the last race you started in 10th position, then in the next race, you will start in 11th position. Thus, each race becomes harder and harder to finish in 1st, 2nd or 3rd. When you finish outside the top 3 (1st, 2nd or 3rd), your game is over and your score is final. A single race lasts for 99 seconds. If a player made it through 10 races, their game would take 99*10=990 seconds; 990/60 = 16.5 minutes, which is shorter than a game of Pitfall, for comparison. SOME DETAILS ABOUT IMPLEMENTATION Spoiler To manage flicker, I'm thinking that only 6 pairs of WRM's will be displayed (12 WRM's totally) throughout the entire game. Thus, when another rally car approaches you, you will see only the two tail lights, and the total number of objects to be drawn will be 14 (12 WRM's + 2 tail lights). A SAMPLE CALCULATION Spoiler You start in 10th place. Suppose you are in Novice mode and your top speed is 200. The other rally cars were released every 3 seconds ahead of you. All of the 9 rally cars ahead of you are travelling at the same speed. Let's call it x. At the moment your car was released, the #1 car had been going for 27 seconds. That is, the #1 car had a 27 second head start on you. You have 99 seconds to catch the #1 car. In 99 seconds, your car will travel 200*99 units. In that 99 seconds, the #1 car will travel 99x units. However, it had a 27 second head start, during which it also travelled another 27x units. That is, totally, the #1 car will travel 99x+27x=126x units during the race. Set the two expressions equal. 200*99=126x. Solve for x. x=157.14. That is, if you start the race in 10th place and all of the other nine rally cars were released 3 seconds apart and are travelling at 157.14 and if you travel at your max speed of 200, then you will catch the #1 car 99 seconds later when time runs out. CAREER MODE, SORT OF Spoiler To me, NDA RALLY RACING GAME MODE (or RALLY RACE for short) is kind of like the Atari 2600 version of "career mode" in racing games on more advanced game consoles because if you finish in 1st, 2nd or 3rd place, you advance to the next race. Because RALLY RACE can last longer than a typical Atari 2600 game, the player may wish to save his or her progress and continue the game later. For this reason, it makes me wonder if we should be considering AtariVox/Save Game support? We're currently not using the second controller port. PROBLEMS/ISSUES Spoiler NO INSTANT REPLAY: Pretty sure it's just not possible. There would be so many interactions between the player's car and the other rally cars that would need to be recorded. We don't have any RAM free to record all of that extra information. Quote Link to comment Share on other sites More sharing options...
+Living Room Arcade Posted September 8 Author Share Posted September 8 GHOST RALLY RACING Spoiler I think I have the perfect solution for our game: GHOST RALLY RACING (or GHOST RALLY for short). WHY A GHOST RALLY? Spoiler GHOST RALLY will: still provide a fun, new game mode for Night Driver Arcade and it will... make Instant Replay possible, but it will... be easier to program/require fewer modifications/require less ROM space WHY DOES GHOST RALLY MAKE INSTANT REPLAY POSSIBLE? Spoiler Because ghost cars do not interact with the player's car in any way. The ghost cars and the player's car simply pass through each other. Thus, the movement of the ghost cars in GHOST RALLY will be 100% "deterministic." That means you don't need to record any data about the speeds or positions of the ghost cars during the race to create the replay. MORE Spoiler For example, if you just simply knew that, at the start of the race, there were 9 ghost cars and that they were released 3 seconds apart and that each of them was travelling at a constant speed of 100, then that's all of the information that you would need to know about the positions and speeds of the ghost cars to create the replay. WHAT WILL GHOST RALLY IN NDA LOOK LIKE? Spoiler The first 3 digits of the 6-digit score tells you your position in the race. Note: I'd like to have it say "1st" instead of just "1" and "2nd" instead of just "2" etc. but we'll see what we can do there. Before play starts, the player selects Novice, Pro or Expert tracks. Top speed in Novice is 200; in Pro it's 300 and in Expert it's 350. That's your top speed. The other cars will be going less than your top speed. You drive your car as usual in NDA. You crash if your car hits the sides of the road as usual in NDA. There are no collisions between your car and the ghost cars. Your car passes through the ghost cars when they touch. You only will see the tail lights of the ghost cars in front of you. To pass a ghost car on the road, simply pass through it. When you successfully pass a ghost car, the 6-digit display will subtract one from your position in the race. Conversely, if a ghost car passes you, the 6-digit display will add one to your position in the race. When the timer runs out after 99 seconds, the race is over. At the end of each race, your updated score will be displayed as follows: You will be awarded 25 pts for 3rd place, 50 points for 2nd and 100 points for 1st. NOTE: Add your TOP SPEED to your score also? After you have seen your updated score, you will then be offered the chance to watch the replay of your last race. You can watch the replay as many times as you like. You must finish 1st, 2nd or 3rd to advance to the next race. After you are finished watching the replay, if you finished 1st, 2nd or 3rd, you will asked to continue. If you say no, the game will be over and the game goes into Attract mode. If you say yes, the screen will set up for the next race. The next race will begin with your car positioned one place further back. For example, if in the last race you started in 10th position, then in the next race, you will start in 11th position. Thus, each race becomes harder and harder to finish in 1st, 2nd or 3rd. When you finish outside the top 3 (1st, 2nd or 3rd), your game is over and your score is final. A single race lasts for 99 seconds. SAMPLE CALCULATION: If a player made it through 10 races, their game would take 99*10=990 seconds; 990/60 = 16.5 minutes, which is shorter than a game of Pitfall, for comparison. If the player watched the replays of all of those races, then the total game time would be 33 minutes or more. SOME DETAILS ABOUT IMPLEMENTATION Spoiler I haven't worked it all out yet, but here are my current thoughts about implementation. LADDER ANALOGY: The ghost cars all move at the same speed and remain equally far apart from each other. The ghost cars on the road can be compared to the rungs of a ladder. To know the location of one rung on the ladder is to know the locations of all of the rungs on the ladder. Thus, we will use a 5-digit BCD register (###.##) to accurately store in RAM the location of the last ghost car. Then, by simple calculations, we can also know the precise locations of all of the other ghost cars, no matter how many there are. FLICKER: To manage flicker, I'm thinking that only 6 pairs of WRM's will be displayed (12 WRM's totally) throughout the entire game. Thus, when a ghost car approaches you, you will see only the two tail lights, and the total number of objects to be drawn will be 14 (12 WRM's + 2 tail lights). FAIRNESS: Some parameters must be set correctly; otherwise, it may actually be impossible for the player to finish in the top 3 and advance. The parameters that must be set correctly are: 1) the number of ghost cars, 2) the starting position of the player, 3) the number of seconds between the releases of the ghost cars and 4) the constant speed of all of the ghost cars on the "ladder." Here is a sample calculation to give you an idea what I'm talking about. A SAMPLE CALCULATION Spoiler You start in 10th place. Suppose you are in Novice mode and your top speed is 200. The ghost cars were released every 3 seconds ahead of you. All of the 9 ghost cars ahead of you are travelling at the same speed. Let's call it x. At the moment your car was released, the #1 ghost car had been going for 27 seconds. That is, the #1 ghost car had a 27 second head start on you. You have 99 seconds to catch the #1 ghost car. In 99 seconds, your car will travel 200*99 units. In that 99 seconds, the #1 ghost car will travel 99x units. However, it had a 27 second head start, during which time it also travelled another 27x units. That is, totally, the #1 ghost car will travel 99x+27x=126x units during the race. Set the two expressions equal. 200*99=126x. Solve for x. x=157.14. That is, if you start the race in 10th place and all of the nine ghost cars were released ahead of you 3 seconds apart and are travelling at 157.14 and if you travel at your max speed of 200, then you will catch the #1 ghost car when time runs out 99 seconds later . BITS 'N' BYTES Spoiler I haven't worked it all out yet, but here are my current thoughts about memory management. RACE NUMBER: 1 nybble (0-15) In the first race, there are 9 ghost cars and you start in 10th place. In the second race, there are 10 ghost cars and you start in 11th place, etc. 5-DIGIT BCD COUNTER (###.##) (0-999) + 2 decimal places. The position to within one hundredth an odometer turn of the last ghost car in the "ladder." 5 nybbles = 2 bytes + 1 nybble EXTEND THE GAME ODOMETER TO HUNDREDTHS OF AN ODOMETER TURN (.##) 2 nybbles = 1 byte TOTAL: 2 bytes + 2 nybbles + 1 byte = 3 bytes + 2 nybbles = 4 bytes We could take the 4 bytes from the player's collision record. Instead of recording 19 collisions, it could record 15. That is, if the player had 15 or fewer collisions during the last GHOST RALLY race, then he or she could watch the full replay of it. NOT STORED IN RAM: Spoiler PLAYER'S POSITION IN THE RACE: This number is already stored in BCD in the 6-digit display. THE NUMBER OF GHOST CARS IN THE RACE: That can be calculated from the RACE NUMBER in RAM. It equals 8+RACE NUMBER. (In the 1st race, there are 9 ghost cars. In the 2nd race, there are 10 ghost cars, etc.) THE NUMBER OF SECONDS BETWEEN THE RELEASE OF THE GHOST CARS - This information can be written into the game program. THE CONSTANT SPEED OF THE GHOST CARS - This information can be written into the game program. It will probably be 100 for Novice, 200 for Pro and 250 for Expert. THE DISTANCE BETWEEN GHOST CARS ON THE "LADDER" - This number is a constant and can be written into the game program. Also, it can be calculated as SPEED OF GHOST CARS * TIME IN SECONDS BETWEEN RELEASE OF GHOST CARS. For Novice, that would be 100*3=300. For Pro, it would be 200*3=600. For Expert, it would be 250*3=750. CAREER MODE, SORT OF Spoiler To me, GHOST RALLY is kind of like the Atari 2600 version of "career mode" in racing games on more advanced game consoles because if you finish in 1st, 2nd or 3rd place, you advance to the next race. ATARIVOX Spoiler Because a game of GHOST RALLY can involve many individual races and can last for over half an hour if the player watches all of the replays, we might consider adding AtariVox/Save Game support to allow the player to save his or her game partway through and continue playing later. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.