How were the Power Zones done in E.T. and can it be done with batari Basic?

[+Random Terrain]

How were the Power Zones done in E.T. and can something similar be done with batari Basic?

 

One of my favorite things to play are Civilization-style games where a new world is created and you explore, looking for resources and treasure. Since I can't make a world on the Atari 2600 with a ton of sprites that show the resources, I can do the next best thing and use a system similar to the Power Zones in E.T. When the player moves over an area of the world that has a resource, a symbol would show it. Unlike the Power Zones in E.T., these zones would have to be fairly small with areas of no resources or treasures between them. If you've played E.T., you know that some Power Zones can be large and multiple Power Zones can be right up against each other. Not good for what I need to do.

 

Not only would some of the zones have resources, some would also have treasure or a spot that looks suspicious where you would dig for treasure. Zones that contain treasure or the type of resources that can be used up would need to be empty after the player depletes that zone.

 

So, to summarize, the zones and zone contents would be created using controlled randomness, then when a certain resource in a zone is used up or treasure is removed, the zone will be empty after that.

[jrok]

How were the Power Zones done in E.T. and can something similar be done with batari Basic?

 

I'm not sure how they were implemented in E.T., but what you describe is essentially a grid of binary nodes - like a checkerboard with some squares turned "on" (treasure, trap or resource is there) and many more turned "off" (nothing of interest is there). I think the general way I'd approach it would be to start out by determining the grid size (how many possible map positions there are vertically and horizontally) and the number of possible outcomes whenever the player occupies a square on the grid. For the sake of argument, let's say that our grid is 8x8, and that there is only one possible outcomes when the player digs up the ground at his present square. With 8 bytes of RAM you could create a bitmap of your search grid:

 

dim map_row1 = a
dim map_row2 = b
dim map_row3 = c
dim map_row4 = d
dim map_row5 = a
dim map_row6 = b
dim map_row7 = c
dim map_row8 = d

map_row1 = %00000000
map_row2 = %00000000
map_row3 = %00000000
map_row4 = %00000000
map_row5 = %00000000
map_row6 = %00000000
map_row7 = %00000000
map_row8 = %00000000

 

Then you can randomly turn on bits in each row at the beginning of play to determine whether a treasure is there or not. During gameplay, track the player's grid position. When a player is located in the same position as a "1" square and digs, give him the treasure (i.e. play a sound, show a picture, add points, etc) and then turn the bit off so that the next time he digs there, he'll get bupkis.

 

If you wanted to further randomize the kind of prize he gets, just do a rand command during the digging routine, and display the appropriate result:

 

dim dig_result = e

constant treasure = 0
constant trap = 1
constant oil = 2
constant skeleton = 3

DiggingRoutine
dig_result = rand & 3
if dig_result = treasure then goto FoundTreasure
if dig_result = trap then goto TriggeredTrap
if dig_result = oil then goto StruckOil
if dig_result = skeleton then goto HolyCrapASkeleton

 

Off the top of my head that's just one way to do it, and just the bare bones of it. The randomness in this example can be finessed and weighted in a number of ways (limit the number of bits flipped at the beginning of play, expand or reduce the odds of each dig result, etc). I'm going to do something similar to this with the navigation map in Star Crusade, but I'm thinking of using a large ROM bit array instead of a RAM array, then randomizing a pointer in order to randomize the elements in the map.

Edited December 3, 2012 by jrok

[Nukey Shay]

The "power zones" in E.T. aren't random. Just the pointer to a 128-byte data table is. IIRC, larger zones exist when the program is instructed to ignore specific zones on certian screens (such as the landing zone on non-forest screens)...but it's really just 1 of 16 different setups based on the initial value of the pointer. There's less than 16 different types of power zone too, so each byte holds 2 zones.

 

Debro's disassembly is here. See "PowerZoneMap".

 

To have them change, you could either map everything to RAM as mentioned (costly), or use a smaller allotment of RAM to "nullify"** only specific types of zones.

 

**If you were designing the engine similar to E.T's, 1 byte per screen is enough to "kill off" up to 8 specific types of zones as they are used (with up to another 8 types allowing infinite use).

[jrok]

To have them change, you could either map everything to RAM as mentioned (costly), or use a smaller allotment of RAM to "nullify"** only specific types of zones.

 

**If you were designing the engine similar to E.T's, 1 byte per screen is enough to "kill off" up to 8 specific types of zones as they are used (with up to another 8 types allowing infinite use).

 

Yeah, I agree that masking out zones might be the way to go. My example was just meant to be generally illustrative of the concept. For my project (32x20 grid), I'm thinking of employing a combination of an "E.T." array pointer with 4 bytes reserved to disable certain elements. That's why I think pinning down the grid size should be mission number one for RT, here. When you have a sense of the size of your search grid, the best options become clearer.

Edited December 3, 2012 by jrok