Jump to content
IGNORED

Pathing?


gar0u

Recommended Posts

When I look at a game like Tron Deadly Discs, I can see how it would be implemented:

   1. Draw the background using 'cards'

   2. Anything that moves on the background is a 'sprite' (of which there can only be 8):

       i. Player

       ii. Player's disc

       iii. Enemy 1

       iv. Enemy 1 disc

       v. Enemy 2

       vi. Enemy 2 disc

       vii. Enemy 3

       vii. Enemy 3 disc

   3. Doors can be implemented by location checks of the Player

 

Don't know if that's how it works, but I imagine I could re-implement the game this way.

 

When I look at a game like Advanced Dungeons & Dragons or any maze game like Lock 'n' Chase, I have no idea how Player pathing would be implemented to control where the Player can move their sprite.  The only thing I can think of is a 2d array that is constantly checked against controller input.  That would be straightforward for a game where the entire maze is visible, but not a scroller like AD&D.  Unless the entire screen is an abstract of a single card, and a finite number of them are implemented like a static maze, which would explain the repeating room shapes in AD&D.

 

Anyone have any suggestions on how this might me done?  Maybe I need to get into reverse engineering?  I know someone reverse engineered Utopia, but I'm only aware of modern RE tools like Ghidra.  I doubt it knows anything about the Intellivision architecture, but I bet a lot of this is documented by the creator of 'jzintv'!

 

 

 

Edited by gar0u
Link to comment
Share on other sites

It's a lot simpler than what you are thinking.  I will give you an example of how this is implemented in my own game, Christmas Carol, which was based on effort to port Pac-Man originally.

 

The maze on the screen is a visual representation of the world, but there is an internal data structure that actually provides all the information for the maze. It defines a set of "tiles" or blocks, where each indicate the path ways in and out of them, and whether there is an item (a candy or snowflake) in it.

 

The entire maze is then divided into these "tiles."

 

It then becomes a matter of computing the position of the player within this "virtual map" using the sprite coordinates.

 

Sometimes, you can encode this information directly on the background tiles, say, by making the assumption that "card #5 is always a wall," or "card #1 indicates an open path"; but once again, you take the player's sprite position on the screen and compute his position in the actual world (whether virtual map or background card), then read the necessary information and act on it.

 

In the case of D&D: Cloudy Mountain, I believe it works the same way:  there is an internal data structure that tells you how the world is laid out, including the pathways, walls, etc.  Then, the game just keeps track of the position of the player within this virtual world map, as it displays only a portion of it at a time.

 

You can think about it this way:  do you remember those games like Defender or even World of Warcraft, in which you have a screen showing you a piece of the world and a mini map showing you the rest of the world?  Well, the game actually tracks the player in the wider map, and just shows you the portion where the player is at each moment.

 

That's the theory, which should be enough to get you started.  If you are looking for practical implementations, well, it really depends on the game, because the set of data points you need to track may or may not fit in GRAM or the BACKTAB, or other "natural" places, and so you may need to build data tables to define your virtual world map.

 

In my game, I use a combination of both:  there are a few bits left unused in the BACKTAB cards, so I encode the state of retrievable or consumable items there (since I can alter the bits).  As the player moves, I compute his position on the BACKTAB, retrieve the card and see if there is an item there.  If there is, I update the  background card and act on the event by giving the player points and engaging some game state if necessary.

 

For the maze itself, I store an array of each virtual "tile" specifying which exits it supports:  whether you can move out of it via north, south, east or west. Then I perform the calculation mentioned above:  as the player moves or changes direction, I figure out his current "virtual tile," get the exits available, and decide whether he is allowed to move there or not.  Then finally, act on it by moving the player, or blocking him.

 

 Hope this helps.

 

    dZ.

Edited by DZ-Jay
  • Like 1
Link to comment
Share on other sites

I know from having disassembled AD&D these things:

 

All sprites travel from one entire background card to the next, though their movement is smooth as if they're moving freely within the rooms.  Notice how blobs often continue to travel in the same direction for a second before turning to chase you down when you're in a large room together.

 

Rooms are drawn with the GROM background characters that fill one half of the card across a diagonal, as well as character 95, which fills a whole card with the foreground color.  Those diagonal graphics are merely decorative and exist to show movement "within" tunnels and rooms.  The only valid cards that sprites can travel to are the ones that are completely filled.

 

Rooms not yet revealed to the player are still drawn, using the "walls" foreground color.  There is a bit that can be set to hide sprites behind the foreground, although they may exist on the screen.  That is why the game engine permits you to hear the sounds of bats, snakes, and dragons when they're nearby.

 

As for Lock & Chase, I disassembled the ROM to prevent collision handling between the player and the cops, but I didn't look into how they move within the maze.  I imagine it's probably done the same way as in Ladybug.  Whenever your direction of movement changes, calculate how far you can go in that direction.  If you reach that threshold, stop the player until direction changes again.  But whereas Ladybug has turnstiles, Lock & Chase has those doors opening and shutting.  I haven't looked into it further.

  • Like 2
Link to comment
Share on other sites

22 hours ago, DZ-Jay said:

In the case of D&D: Cloudy Mountain, I believe it works the same way:  there is an internal data structure that tells you how the world is laid out, including the pathways, walls, etc.  Then, the game just keeps track of the position of the player within this virtual world map, as it displays only a portion of it at a time.

You might want to look at this thread which I also posted here somewhere, but a quick search didn't immediately pull it up.  I uncovered the method for procedurally generating the "virtual world map" for each mountain.

Link to comment
Share on other sites

52 minutes ago, Zendocon said:

You might want to look at this thread which I also posted here somewhere, but a quick search didn't immediately pull it up.  I uncovered the method for procedurally generating the "virtual world map" for each mountain.

Thanks, but I was just generalizing the options, not providing specific implementation details.  I think my point still stands:  the path is part of the virtual world map which can be either encoded in the background graphics (as you suggest for AD&D, and as I described in my examples for Christmas Carol items), or stored elsewhere in a table.

 

In either case, the player's sprite position is then translated into the position on the map (whether on a table or in the background) and compared against the available path of the location, upon which the game reacts.

 

I do not know how Lock 'N' Chase work, but considering that it is a clone of Pac-Man, it probably works in a similar fashion to it.  In Pac-Man, the path is stored in a table of virtual tiles, defining the exits available on that tile.  The sprites are allowed to continue forward motion on a tile until the next transition, at which point the position of the sprite is translated into a virtual tile coordinate, and a response is made to the current movement.

 

The Pac-Man model is very common, especially among maze games with a two-dimensional corridor.  Encoding bits of the virtual map on the background representation itself (e.g., BACKTAB) is very useful, but is not always practical.

 

    -dZ.

Link to comment
Share on other sites

26 minutes ago, DZ-Jay said:

I do not know how Lock 'N' Chase work, but considering that it is a clone of Pac-Man, it probably works in a similar fashion to it.  In Pac-Man, the path is stored in a table of virtual tiles, defining the exits available on that tile.  The sprites are allowed to continue forward motion on a tile until the next transition, at which point the position of the sprite is translated into a virtual tile coordinate, and a response is made to the current movement.

 

The Pac-Man model is very common, especially among maze games with a two-dimensional corridor.  Encoding bits of the virtual map on the background representation itself (e.g., BACKTAB) is very useful, but is not always practical.

That of course would make more sense, given that walls exist as whole cards and not as single-pixel barriers between adjacent cards.

Link to comment
Share on other sites

I have never really looked into it or read about it but I have always assumed there was just collision detection on the screen that stopped or allowed the movement. It didn't make sense to me that it was so damn hard to get the plumber to climb the ladders in the original Intv Donkey Kong when I could see he was obviously touching the ladder. 

 

It seems like a complex issue to track the location on the screen and the location in a table but it does make sense (sort of). But then, I'm old and I drink a lot so lots of this programming stuff is getting harder and harder for me to grasp.

Link to comment
Share on other sites

6 hours ago, Zendocon said:

That of course would make more sense, given that walls exist as whole cards and not as single-pixel barriers between adjacent cards.

In Pac-Man, background tiles are 8x8 pixels, while sprites are 16x16.  In Christmas Carol, the virtual tiles are 4x4 pixels, while the sprites and background cards are 8x8 pixels.  I did not have the resolution to make the mazes the same size as the background tiles.

 

My point is that the visual representation of the world does not have to correspond exactly to the actual game world.  It not really necessary to map everything to an 8x8 card or to depend on the pixels on that card for collisions.  :)

 

   dZ.

Edited by DZ-Jay
  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...