Search Unity

Tile based movement and walls between tiles

Discussion in 'Scripting' started by eses, Feb 13, 2019.

  1. eses

    eses

    Joined:
    Feb 26, 2013
    Posts:
    1,255
    Hi,

    I decided to add walls to tile based movement. These probably would be more occasional as they wouldn't form typical solid tiles but thin walls and doors between tiles. See image below. If a tile needs a wall and it's a wall with a door, in addition to neighbors (NESW directions) I have an array of doors in each Tile data cell:

    Tiledata[] neighbors = new Tiledata[4];
    Door[] doors = new Door[4];

    Then I have a bunch of ifs to decide if there's a wall or block in move direction. Finally I check if it has a open door. Only if the direction is not blocked, I allow transition from tile to tile.

    My questions

    Anyone have idea how old school dungeon crawlers and some other types of games handled these?

    I bet these didn't use OOP style. Like here I've got a Tile cell, which knows it's neighbor cell tiles and each cell has a list of walls in NESW directions around it.

    I haven't found any articles on this topic, but I remember some games that used this kind of tile movement. I was considering also some sort of tile-wall-tile type structure bit like in Pac-Man, but I haven't quite got it right in my head yet.

    So I got it working but it feels clumsy and ugly. I feel there must be cleaner way to do this.

     
  2. Kurt-Dekker

    Kurt-Dekker

    Joined:
    Mar 16, 2013
    Posts:
    4,067
    Normally the point of a grid is that you know a tile is enterable based on what is in it. You also know the neighbors of a given tile are always +1 or -1 away in each of the four (or eight) directions.

    You can continue to do this simple neighboring and traversability, but if you wrap it up in a class, then you can ALSO have other providers of either linkage or blockage, such as these walls between two otherwise-traversable tiles.

    But the key is if you wrap it up in some kind of "navigability manager" class, then your underlying maneuver code doesn't have to change: it just asks "can I go from here to here?" and then the nav class can decide based on the state of the map, any doors opening/closing, chasms opening, etc.

    In other news, PacMac was a pure grid, but not quite in the way you visually see it as: the cells are actually smaller than the size of the hallways that you navigate.

    Here's an AWESOME article on how the PacMan AI worked, and it gives you an insight into how they did such a great game with such limited hardware.

    http://gameinternals.com/post/2072558330/understanding-pac-man-ghost-behavior

    The whole article is a great read for any game developer.
     
    eses likes this.
  3. eses

    eses

    Joined:
    Feb 26, 2013
    Posts:
    1,255
    @Kurt-Dekker

    Thanks, I already did mention that I'm aware of Pac-Man tile system, where it is basically tile-wall-tile kind of setup...and I've read that article twice a while ago, however IIRC it was mostly about ghost movement logic, not about map structure. I've yet to read Pac-Man dossier.

    I do already have a grid of Tile cells that each know their neighbors, and which edges can be crossed, but the implementation is quite clumsy. And I do have sort of manager for map, that entity in map can query for free positions, possible transition from tile to neighbor tile, but it's not pretty. I'm eventually going to modify it to fit A star (if I have time), but not sure how long this will take. It just bothers me how the doors / non-crossable edges are now sort of special cases, and not map data like walkable/non-walkable tiles. I bet this has been solved in much better way already.