Are there any tanks in River Raid?

[Room 34]

If the levels were generated randomly, they wouldn't be the same every time you play!

Actually, there IS a random number generator at work in the levels for both this and Pitfall (look at the disassemblies).

 

The thing is, computers can't REALLY generate truly random numbers. They have a pseudo-random number generator, and they require a seed to start the list of numbers. If the seed is always the same (as it is in these games), then the list will always be the same.

 

The contents of the levels of the game are not random, but the sequence of the scenes is... sort of. (Anyone who actually knows how to program 2600 games can feel free to clarify or correct what I'm saying, but I do know the basic concept behind a computer's "random" number generator.)

 

That being said, Thomas is still full of it, because there's no way a 2600 cart could store discrete information for 1024 different levels. 1024 different levels of PONG, maybe...

[Chris++]

I'm pretty sure that if you played five games of River Raid, then wave 1 would always be exactly the same, wave 2 would always be exactly the same, etc. Further, no random activity or placement is going on in Pitfall -- or the maps wouldn't work! (Maybe the generator's being used for something non-customary?)

 

Either way, you've gotten my point: There would still need to be 1024 different levels concocted, which would've taken Carol well past the first industry shakeout to complete...

 

CF

[Room 34]

I'm pretty sure that if you played five games of River Raid, then wave 1 would always be exactly the same, wave 2 would always be exactly the same, etc. Further, no random activity or placement is going on in Pitfall -- or the maps wouldn't work! (Maybe the generator's being used for something non-customary?)

Like I said, nothing is ACTUALLY random. Most computer processors have a random number generator which is really just a built-in algorithm that generates a pseudo-random list of numbers, but it is ALWAYS the EXACT SAME LIST of numbers. You give the generator a "seed" which tells it where in the list to start, thus giving you a pseudo-random list. But if you always give it the same seed, you always get the same list. Read Thomas's disassembly of Pitfall... it talks about the random number generator as the basis of the sequence of screens.

 

Either way, you've gotten my point: There would still need to be 1024 different levels concocted, which would've taken Carol well past the first industry shakeout to complete...

To say nothing of fitting all of them onto a 4 KB cart!

[Paul Slocum]

I think the word random is confusing. Both Pitfall and River Raid use a formula to generate the next part of the level. So Carol and David did not sit down and design what the levels would look like, and there is no big set of data that determines the level layouts. They just fiddled with pseudo-random formulas until they found one that generated levels they liked. The formulas produce the same sequence each time, but their output is somewhat unpredicatable and so we call it random. Simply changing the formula will change the entire level layout for either game.

 

If the level number was stored in 2 bytes for River Raid (which would be silly since few people could complete more than 256 levels) then it could be that the tanks don't show up until level 1024. And this wouldn't take a ton of ROM space (or time to design) since the levels are generated with a formula and not stored in the ROM.

 

-Paul

[Chris++]

IIIIII get it. Thanks for clearing that up, Paul. I've only programmed 8-bits, so to me, random literally means random (different every time). I gotcha now.

 

I still think Thomas is pulling your Fuij-legs, though.

 

CF

[Room 34]

I don't want to get too far off on this, since you obviously have more programming experience than I do, but I am still fairly certain that random number generators do not really generate true random numbers.

 

It is possible that more recent ones use an algorithm that can be seeded automatically based on the system clock or something like that, but it is still just an algorithm that will yield the same results with the same input parameters. Computers have no means of "tossing a coin" as it were. They have to follow a set of instructions, and until we have quantum computers, the way they behave in response to that set of instructions is purely deterministic.

[Thomas Jentzsch]

Paul has described that correct, River Raid's random number generator uses 2 bytes.

 

BTW: I'm working on a patched version that will show you the tanks. Will take a few day, maybe on Sunday.

[Chris++]

Actually, Scott, you're right. By "random," I mean "a number that's different every time." This is obviously more applicable to 8-bits than the Stella chip. But it literally interjects an unpredictable value (unless used in the way that River Raid and Pitfall! use it).

 

But no non-living thing can decide which number to throw at you. Nothing can be pulled from thin air. Computers don't have the ability to invent values. So, by the strictest definition of "random," you're obviously right. The CPU pulls a number from the system clock, performs a particular equation with it, and gives you your "random" number.

 

CF

[Pitfall Harry]

That being said, Thomas is still full of it, because there's no way a 2600 cart could store discrete information for 1024 different levels. 1024 different levels of PONG, maybe...    

 

Thomas is NOT full of it. At least, not for the reason you've stated.

 

It's true that there is no way a 2600 cart could store discreet information for 1024 different leveles... simultaneously. But Thomas never suggested that was the case.

 

A pseudorandom generator is an extremely simple computer algorithm based on an underlying equation (or set of equations) which is used to generate a very large (sometimes infinite) sequence of numbers. The distribution of the numbers generated in the sequence is so difficult to predict that it appears to be a random sequence, especially to those who, in the heat of rapid-fire gameplay, have neither the time nor the expertise to analyze it to the point where its pattern begins to emerge.

 

As you're flying your way up the Shaw River, you may notice that all of your enemies come at you from the sides, moving horizontally within fixed-width bands of background scenery. There are maybe 6 or 7 of these bands onscreen at any given time, with the lower one rolling off the screen as you are scrolling into the next band. Let's say there are as many as 8 simultaneous onscreen bands for the sake of argument. Now, what enemies and what background elements go into these 8 bands?

 

There are maybe as many as 32 different scenery types per band, consisting of varying river thicknesses and combinations with and without land dividers. But even these are generated based on symmetry and river continuity rules. The game probably uses ony 16 scenery types and a set of rules which limit what a given band may contain based on the band that came before it. Each of the different types could be distinguished by a single number... a number taken from the peudorandom sequence of numbers from the random number generator. Thus, an entire screen's worth of scenery can be computed on the fly from as little as 8 bytes worth of data mainenance. (The same 8 bytes could have accommodated as many as 256 different scenery types, had that many scenery generation routines been coded into the ROM).

 

Now, what about the enemies and misc screen elements? Notice that there is one enemy/misc graphic per scenery band. It can be a boat, helicopter, airplane,[hidden tank?], house & tree, bridge, fuel or Nothing.

8 more numbers popped off the pseudorandom generator can populate all 8 scenery bands of a game screen with enemies/misc graphics. Since there are only 8 different types, only 3 bits of each generated number is used to select them. 3 more bits of each number are used to set their initial location to one of 8 different horizontal positions within the scenery band. 1 bit could be used to specify which direction it will move in (if it's an enemy), and the final bit could be used to specify whether it has been destroyed.

 

Therefore, I can easily see how only 16 bytes of data, taken from 16 outputs from a pseudorandom number generator, could easily permit generation of a highly varied screenful of River Raid. And how 64 numbers from the sequence could be used to generate 32 horizontal bands, or one game level. However, once one band has scrolled off the screen, the program never needs to track that info, so only 16 bytes of data ever need to be maintained at any given time.

 

The different combinations of scenery bands and enemies/misc graphic elements per River Raid level goes something like:

 

(scenery band types) x (no. of graphics)^(bands per level)

= (16 x 8 )^32

= 2^224

 

...Thus, the only real limitation on the number of different River Raid levels which can be generated by 16 or so 8-bit numbers taken from a pseudorandom sequence generator is the periodicity of the generator itself. Thomas' claim that River Raid uses a simple one which repeats after 57,000 or so is easy enough to believe.

 

Ben

[Chris++]

Well, la-de-da!

 

 

[Paul Slocum]

You're really serious Thomas!? I searched through the dissasembly for the word "tank" and didn't find anything so I thought it was a joke.

 

BTW: That dissesembly is great! I need to read through some of those that you've done. It's probably one of the best ways to improve my 2600 programming skills.

 

-Paul

[NE146]

so what was the technique, they used to gradually make River Raid more difficult?

[Pitfall Harry]

so what was the technique, they used to gradually make River Raid more difficult?

 

An obvious technique would be to use the Level Number to linearly bias the pseudorandom selection of sceneries and enemies which are known to be more difficult. As the level goes up, the frequency of Fuel and "Nothing" decreases, and narrow river channels and fast-moving airplanes increases.

 

Ben

[Room 34]

 

OK, while I may be underestimating the potential for X-TREEM manipulation of the powers of a pseudorandom number generator within the confines of a 4K ROM, my point about the nature of "random" numbers generated by a computer stands.

 

It is quite fascinating to get an insight into how these seemingly carefully-designed and static level layouts are in fact the results of some very tightly-arranged mathematical formulae.

 

I have a couple of questions at this point:

 

1. Could you make a hack of Pitfall or River Raid where you change the seed value on the random number generator and create an entirely different "map" for the game?

 

2. How does the layout of the 20 levels of H.E.R.O. compare to what was done in Pitfall and River Raid?

 

And now, presenting a new approach to proving Thomas is full of it, without dealing with the whole messy issue of levels and random number generators:

 

Look closely at Thomas's disassembly (available here). Near the end of the code is where all of the shapes of the various on-screen objects are laid out. There is no tank amongst any of these shapes.

[Big Player]

Just want to say, cool thread. I had heard about how River Raid generates landscapes, but never really thought about how it works. You guys have explained so well to a guy who last programmed in Pascal in 1987 (and the program didn't compile either!)

[Thomas Jentzsch]

1. Could you make a hack of Pitfall or River Raid where you change the seed value on the random number generator and create an entirely different "map" for the game?

That's very easy for River Raid, just change the values in SEED_LO and/or SEED_HI at the beginning of the code and compile. That's all!

 

Pitfall is another story, because the random number generator can't produce more than 255 different levels (0 is not allowed). But you can change the way, how the game reacts to the values and also the initial value of the generator. I did this some months ago and created my own Pitfall! with a different map.

 

2. How does the layout of the 20 levels of H.E.R.O. compare to what was done in Pitfall and River Raid?

Don't know, but I'd guess they are implemented and not generated.

 

Look closely at Thomas's disassembly (available here). Near the end of the code is where all of the shapes of the various on-screen objects are laid out. There is no tank amongst any of these shapes.

Notice, that in River Raid the graphic data is stored interleaved. That means, in one block are the even lines and in another the odd ones. That makes it hard (even for me ) to recognize the graphics.

 

So, wait and (hopefully) see.

[Room 34]

That's very easy for River Raid, just change the values in SEED_LO and/or SEED_HI at the beginning of the code and compile. That's all!

Intriguing! Have you done any work on this? I lived and breathed River Raid when it first came out, but I haven't played it much since I was about 12 because I got tired of the same levels all the time. I'd be very interested in trying a new version with different levels!

 

Notice, that in River Raid the graphic data is stored interleaved. That means, in one block are the even lines and in another the odd ones. That makes it hard (even for me ) to recognize the graphics.  

 

So, wait and (hopefully) see.

If your disassembly weren't so neat and well-commented, I might believe this. But unless you deliberately omitted some of the code from it (which I can't believe you'd do), there's clearly no tank in there.

 

Granted, I have no means of compiling this code to test it, so I am going to have to take your word and my own observations and just come up with my picture of reality from there.

 

I still don't believe there are any tanks!

[Thomas Jentzsch]

Intriguing! Have you done any work on this? I lived and breathed River Raid when it first came out' date=' but I haven't played it much since I was about 12 because I got tired of the same levels all the time. I'd be very interested in trying a new version with different levels![/quote']

No work necessary any more, just compile! Or would it be easier for you to use an hex editor. Then I'll check the addresses for you.

 

If your disassembly weren't so neat and well-commented,...

Thanks!

 

...I might believe this. But unless you deliberately omitted some of the code from it (which I can't believe you'd do), there's clearly no tank in there.

 

I still don't believe there are any tanks!

Ok, in a few days, I'll hope to finish the promised fixes (very tough, beause the ROMs is using nearly every single byte) and send it to AA. Perhaps you believe me then.

[Room 34]

No work necessary any more, just compile! Or would it be easier for you to use an hex editor. Then I'll check the addresses for you.

Yeah, the problem is I do not have a way to compile it. If you could let me know what to change in the .bin file directly, that would be great!

[Thomas Jentzsch]

Yeah, the problem is I do not have a way to compile it. If you could let me know what to change in the .bin file directly, that would be great!

Ok, just change the values at $0dc9 (=$14), $0dca (=$a8 ) and also $0dce and $0dcf (for 2nd player).

[Room 34]

Yeah, the problem is I do not have a way to compile it. If you could let me know what to change in the .bin file directly, that would be great!

Ok, just change the values at $0dc9 (=$14), $0dca (=$a8 ) and also $0dce and $0dcf (for 2nd player).

COOL! It works!

 

Sorry... I am new to this kind of thing. Now I want to start doing all sorts of crazy stuff... but I'm sure I'll get in over my head very soon.

[Chris++]

You also win the coolest avatar award for making yourself into a game cartridge!

[Room 34]

You also win the coolest avatar award for making yourself into a game cartridge!

Thanks. I decided to be bold and show my face!

[NE146]

Oh by the way did I mention I have a new hack where I created an entirely new map layout for River Raid? Yes it's true!

 

Get it right here: RIVER RAID 1.5 I'm calling it "Official River Raid 1.5 as programmed by NE146!"

 

ok ok I'm just goofing around but of course what Thomas said worked like a charm. Do that mod and voila.. instantly changed map. I just did two truly 'random' values . But I wonder if there would be combinations that might put out nicer results.

[Room 34]

I changed the values of all 4 bytes to FF and that way, you get an object on every block! Definitely more of a challenge.

 

Thomas, when you identified the addresses of the bytes to change in a hex editor, how did you go about determining that? I guess what I am really asking is, do you have a table listing the game variable values and their addresses? That would be a great tool for novice would-be game hackers like myself to use for tinkering with other values in the game!