Adventure randomization question

[mslass]

Hi:

 

I've been looking at the annotated assembly for Adventure from here http://www.bjars.com...e/adventure.asm (thanks again to those who pointed me to this.) I'm specifically looking at the object random-placement routine, RandomizeLevel3. According to the Room Bounds Data table, the yellow key, object $BF, can start in any room from $01-$1D, inclusive. But that includes room $12, which is the interior of the yellow castle itself. Is there code somewhere that I'm not seeing that prevents that, or is it possible to create an un-winnable game by placing the yellow key inside the yellow castle?

 

Likewise for two-way swaps (white key inside black castle, and black key inside white castle.)

 

If there is some logic to prevent this, where is it?

I suspect that there isn't, because I can remember games on my old woody where I couldn't win, but I don't think it happened that often, and the chances of just yellow-in-yellow is 1:29, not to mention the swap possibilities.

 

Thanks in advance for your insights. It's so much fun learning about this game that I loved.

 

-Mike

[accousticguitar]

You are correct; unwinable games are possible in Adventure.

[SeaGtGruff]

Yes, it's possible for the yellow/white/black key to be placed in the yellow/white/black castle by the randomization, thereby making the game impossible to win. Of course, the game might still be possible to win if the white/black key is locked up in the white/black castle, depending on where everything else is-- mainly the chalice and the yellow key.

[+Gemintronic]

In my own Adventure-esque engine I also never try to divine only solvable mazes. Instead, I guarantee the player can backtrack a screen. Rooms have a small chance of changing into their "secret" versions with a different set of entrances/exits.

 

Still, my solution is less efficient and simple than Warren Robinettes idea. It seems he left it to players to use the bridge properly and if THAT doesn't work have Knubberrub eventually switch items around.

[Nukey Shay]

I'd started to map out all 256 possible scenarios (256 because the routine just uses the framecounter as the initial value "seed"). I did the first 64 values...and 4 of those were unwinnable games (another 4 were repeats of earlier seed values). So W.R.'s statement of a "1 in 17 chance of being unwinnable" is about correct.

 

If the framecounter holds the value $0D when executing the routine, for example, the yellow key is placed in it's own castle. If the framecounter held an $0F though, both the yellow and white keys are in the black castle (along with most of the other stuff) and the black key ends up in the yellow castle. IIRC you'll only find the bat and magnet on the outside for that seed.

[+Random Terrain]

Related quote:

 

randomterrain.com/game-design.html#controlled_randomness_and_freedom

I used the random object placement in level 3 for variety. I didn't want it to be like a puzzle, where once you've solved it, it's not very interesting to do it again, and I wanted to avoid that. The bat was also added as a confusion factor, to move objects around a bit, so that the game wasn't too predictable. (I did make a mistake in my random object placement code, and there is a 1 in 18 chance that the yellow key will start out in the yellow castle, making the game unwinnable. This only happens in level 3.)

 

As you may gather from the above, I think that randomness in a game is very strong medicine, and must be very carefully controlled.

 

~Warren Robinett from a Good Deal Games interview

[mslass]

All those answers, and while I was asleep, too! Thank you all.

-Mike