How Adventure handles dragon, bat movement/behavior?

[jjsonique]

Hello all,

 

I was wondering if someone could describe, not in assembly terms but just in general logic flow, how Adventure handles the movement of the dragons and the bat throughout the entire "map"?

 

For instance, does it constantly keep track of each dragon's whereabouts, tracking their movement from room to room even when unseen by the player, or does it only keep track of their offscreen location when they're guarding an object, and otherwise has them randomly "enter" the player's current room periodically? I tried to glean this from the comments made on the disassembled adventure code ( http://www.io.com/~nickb/atari/doc/adventur.txt ), but couldn't quite get it.

 

The game seemingly does keep track of the bat's whereabouts constantly -- if you are eaten by a dragon, and then the bat picks up that dragon while you're still in the dragon's stomach, you get a nice tour of the bat's path as it flies from room to room. But I'm wondering if the bat's path is random, and if the procedure's the same for the dragons, etc.

 

Thanks for any info,

JJ

[tiggerthehun]

This is an interesting question - I'll bet Nukey will have some good imput on this one! I'd like to help you out, but my Atari 2600 tech knowledge stops at the on/off switch.

[Nukey Shay]

The game keeps track of everything...seen or unseen. The dragons, bat, and magnet-attracted objects are moving until a game win occurs (in which most of the subroutines are skipped over). They are even moving around when the game-select screen is up...the room links just make it impossible for them to get to you

Here is what happens:

 

-When you are on the game-select screen, a reset will restart all of the objects for that game #. Game #1 and Game #2's variables are preset to begin at specific values. If game #3 is chosen, game #2's table is used and then an additional routine exectues to mix up the room numbers of all objects except the dot and number token. Anyway, when copying the variables from the #2 table, the dragons are automatically given a direction of down-right, and the bat is given a direction of up-right. In game #1's table, all direction is killed (which is why the yellow dragon stays put until you enter it's room in that game mode). Anyway, the bat's "held" and "fed-up" variables are also reset...so it's not carrying anything and looking for an object to pick up. So right when you can see your square player, the enemies are doing their thing:

 

The dragons, bat, and magnet all have their own subroutines that the program jumps to (but they are all pretty similar)...

For the dragons, the game first checks up on their "state" variable. If it is not zero (i.e. roaming the screens), the program skips ahead to deal with movement.

Checking the matrix:

Each dragon has a group of objects that it either "likes" or "dislikes". The program checks each one to see if it is on the same screen...and then updates the dragon's direction accordingly (running away from the "most disliked" object or towards the "most liked" object). The player sprite itself is in the tables as the "most-liked" object...so a dragon will move towards you unless a disliked object is present. BTW the sword is set as a disliked object in each dragon's matrix...but a small compare will kill this value if the difficulty switch is set to "B" (so they ignore the sword).

Checking collisions:

Now that the direction has been updated, the program checks to see if the displayed objects have hit the dragon sprite. If the ball did, a table is used to reset a new value (>2) for the state variable, and the sound variable is reset to the "biting" noise. If the other displayed object is the sword, the dragon's state is set to 1 (dead) and the sound variable is reset to the "dying" noise.

Moving the dragon:

The program looks to see if the dragon's state is equal to 1...If so, the subroutine ends (no movement needed). If the state is >2 (biting), the state variable is incremented for next time. If the state is equal to zero, this would mean that the state has rolled over during the "biting" period...and the player's variables are reset (i.e. the player got eaten).

If the state was equal to 2, the new direction is applied to the sprite...either moving toward the liked object or away from the disliked one. As stated, the player character is a "liked" object...so the dragons aren't really "trying" to bite you...they just want to guard you (but once they get to you, the collision detection routine sticks them in the "biting" mode).

 

The bat moves similarly as the dragons...just using a direction variable to update it's X and Y. And also similar to the dragons, the bat has a table of objects that it likes. The first thing that is done is the bat's state is incremented. If it rolls over, the bat becomes "fed up" with it's current object and seeks another one. Once the collision detection routine reads a collision with the desired object, the held object is dropped and the new one picked up...and the fed up timer is cleared. If the new object had been carried by the player, the player's "held object" variable is cleared (so the bat can steal objects from you).

 

The magnet routine kind of works in reverse. Instead of moving itself, the magnet uses a table of "liked" objects to check if any of them are on the same screen. If so, the most-liked object's X and Y are changed to be closer to the magnet's position.

[tiggerthehun]

Nukey, I could set my watch by you!

[Nukey Shay]

* steals tigger's watch

 

That'll learn ya to keep it away from me

[jjsonique]

Very interesting and informative, Nukey Shay! Thank you!

 

Just a handful of additional questions:

 

When it's tracking the dragon/bat's position, I assume it's tracking 3 variables for each: room #, X and Y - is that correct? And if so, does it handle registering movement (unseen by the player) to a new room by checking if the dragon/bat's X or Y or is above or below a certain value, and changing the room number variable if appropriate?

 

And lastly: since a dragon starts out moving down-right, am I correct in assuming that it continues moving in that direction until it enters a room that contains either or liked or disliked object?

 

( I like the fact the dragons are actually trying to guard the player & it's only when the get up close that they realize how tasty the player is. )

[Nukey Shay]

Both correct

[jjsonique]

Excellent -- the mysteries of Adventure have been unravelled before me. Thanks again!

[Nukey Shay]

No prob.

There are a few limitations with movement...

If an object moves below the minimum Y boundry (the bottom of the screen) and the current screen is the castle entry AND the portal is closed...it will not exit the castle. For some reason, this does not operate correctly if the player's held object does so. Tho normally, it's impossible for the player to even be in a locked castle - so that oversight is not such a big deal (hacking the game, you can have the init routine place you on any screen you choose). During normal game play, once an object enters or exits a castle entry it's corresponding gate is reset to be open - even if the gate was in the process of closing.

The gates themselves cannot allow an object to enter the castle unless it is open AND the collision routine detects a hit between the gate and the object (which means that it would need to happen while this screen is being displayed). To see an example of this, carry the magnet below you and force it into the wall just below the yellow castle. Bring the key to the entryway and drop it...moving downward right away. Wait a few moments, then go back up to the yellow castle. Although the key was floating upward to meet the magnet (crossing the gate)...the gate will still remain unchanged.

Since the collision detection for the dragons only works if they are not currently in motion, it's impossible to kill a dragon while it is currently biting you (mouth open GFX).

The player sprite must be located at X+3, Y-10 of the dragon for the player to be eaten - this causes the glitch where the player cannot be eaten when moving downward into a wall (because Y won't have the correct coordinate).

The secret EE room can only be accessed by the player moving to the right of the panel screen AND the dot is no longer in it's starting screen. However, objects may also enter the EE room if the player sprite is currently on the panel screen AND the object crosses the right border.

Since the bat can only fly in the direction of the "wanted" object, it's possible to "train" the bat to fly in any direction desired simply by matching it's X or Y position with the most-wanted object on the screen. Then you can just move the dropped object offscreen and the bat will have to keep flying that direction so long as it's flight path doesn't put it on a screen with any object in it's matrix

The yellow dragon always fears the yellow key (since the yellow key is placed in it's "feared" range in it's matrix). I don't suppose it will ever be known for sure if it was intentionally coded this way from the start, or just an accident that was accepted as a "feature" (i.e. the key might have been placed in the matrix too high by mistake).

Because the dragon bases it's direction changes off the relative position of the liked or feared object, it's possible to "lock" the yellow dragon in place if the yellow key happens to be placed correctly above it's "bill"

The yellow key is allowed to begin on any screen in game #3. This opens up the bug in which the yellow key might be given a starting screen inside the yellow castle - making the game unwinnable. This could have been easily avoided by adjusting the yellow key's boundry values...so it's unknown if this was just an oversight

The panels are made of the missile sprite (which is why they will change colors to be the same as an object on-screen). This too has a glitch when dealing with the right panels. The color will be the same as the second sprite on the screen...so if only 1 exists (besides the dot), it will be invisible due to the dot's grey color.

There is a slight bug in the positioning routine which allows objects to move too far to the right when being carried by the bat. If this happens, the object will "wrap around" to the left side of the screen. If you then pick up the object, the relative X location will be thrown off a great deal (the carried object will move with you half a screen away).

The sideways links of the black castle link directly to the inside of the black castle in all games. This too could also create an unwinnable scenario if the bat happens to be carrying the black key and flies off the entry screen (the bat and key will get stuck inside the castle, unable to exit due to the locked portal).

Although you cannot see them (due to the room links), the white key, the red dragon, the bat, and the dot all exist even in game #1. If you hack the room links, you will find the bat just inside the white castle (not flying anywhere - due to no motion given in game #1's init table). The red dragon will be guarding the white key 2 screens below.

[jjsonique]

Fun stuff! I have experienced the "object wrap around" bug and have wound up carrying a key that is half a screen horizontally away from me

and seen some of those other things as well but never knew the (buggy) reasons for them.

 

More stuff to play around with. I'm still amazed at how much Warren Robinett managed to push into this game (were/are there any other 2600 games that keep continuous track of offscreen entity behavior to the extent that Adventure does?). I'm going to have to try locking that poor yellow dragon with the yellow key sometime soon, as well as some bat-training.