Map/Maze

[archerbird]

So this is in a very messy state right now. A map is simply a 2D Array of Tiles. The idea here was to mimic the Excel.Range.Value array, where you can access tiles from the map like Map(row,column). I have a module called MapManager acting as a global static class that the controller and models can all call on. I'm thinking this should maybe just become a class though.

For now, I've encoded the maze as a series of characters in a .pmap file that can be easily read and converted into a 2D array of Tiles. One icky issue with my encoding is that it is technically not quite to-scale with the original pacman game. I have put a spacer tile between each pellet on the map, which effectively means that my tiles are equal to ~1.6 original pacman tiles. The problem I have with this is that the map string representation can't really be used for every view implementation. Ideally, we would have a correctly scaled map encoding, and the excel view, if we want to keep the way it looks now, would have to have some sort of scaling logic.

[retailcoder]

I haven't gone through the code yet, but reading the PacMan docs, I would model the map as a 2D array of MapTile objects, where a MapTile class exposes an enum that indicates what directions the tile can be exited from, and another indicating what directions the tile can be entered from. Could be just me but I'd go with a get-only public interface and a factory method for this, similar to Battleship's GridCoord class and get-only IGridCoord interface.

So the first thing I would do would be to define that direction enum, which probably belongs under a shared folder because other parts of the code will need it.

Something like this:

Public Enum MoveDirection
    None = 0
    Leftward = 1
    Upward = 2
    Rightward = 4
    Downward = 8
End Enum

That way it can be used as a single-value for PacMan and the ghosts, and the values can be combined such that a tile with EnteredFrom = 3 can be entered from the left and the top, while ExitedFrom =15 means a tile can be exited from either direction.

Having these two pieces of metadata for every tile should be enough to build the entire maze and work out the entire game logic, whether there's a visual representation of the map or not (the beauty of MVC! Everything is independently testable!)

This only addresses navigation though: perhaps tiles ought to (later? linking #5) hold actual mutable state as well (e.g. HasPellet or HasPowerPellet Booleans that flip off when PacMan traverses the tile, or maybe there's another better way to do this, depending on what a Fruit or PowerPellet clasd might need to do).

Now of course the hard fun part is deserializing a string representation of that map into a 2D array of properly-defined map tiles, but in my books once that's done then this game has a navigatable maze map - no need to be concerned about how it's going to be rendered in a worksheet, at this point what matters the most is that the game state is easily queryable through its objects, so additional helper properties might be useful at the actual map level, meaning a 2D array of tiles might be too simplistic of a model for the map - could be a good idea to have a MazeMap class that encapsulates a 2D array of tiles, and then exposes an indexed getter (default member?) to get the tile at a particular specific coordinate, and methods to evaluate whether the level is completed (might be better to countdown pellets than iterate all tiles everytime though).

Anyway just dropping a few thoughts, hope it helps!

[archerbird]

This is probably going to be the preamble to my next CR post regarding map structures and game piece interactions.

We are on the same page for most of your ideas. In fact, this is generally what I had imagined when I first started on the map design. Here is what I have built so far:

The Maze

The maze (or map) is structured as a dumb, queryable set of building blocks called Tiles. The Maze exists as a 2D array of Tiles. Tiles are "dumb" in that they don't know about the characters that are on them. They are "queryable" in that they hold certain state information that a character can ask about, namely an IsTraversible boolean flag that will make known if they may be entered. The Tiles also have a coordinate pair of Integers that contain the (row, column) position they occupy in the Maze array.

Along with the Maze object, I have a set of commonly used maze operation methods contained in a MapManager. The MapManager can do things like:

• return the Tile object at a given (y,x) coordinate
• given a "CurrentTile" and a "Heading", it can tell you what the "Next" tile would be on your path
• along with the "Next" tile, you could also ask it for the Tile n TileLengths away from your current tile (this will become very useful for Ghosts)

Encapsulated in all this logic are handlers to account for things like "map wrap" (get the next tile on the other side of the maze for the tunnel portion), and suppressing NextTile requests at the edge of the map (for targeting tiles that might lay outside the maze (this also comes into play with Ghost Pathing).

Navigating the Maze

Directional Enum

I have an enum similar to what you suggested:

Public Enum Direction
    dNone = 0
    dUp = -1
    dDown = 1
    dLeft = -2
    dRight = 2
End Enum

I built it this way because there will be a need to issue "ReverseCourse" directives, and it is easy to calculate the reverse direction simply by multiplying the enum with (-1).

Character navigation

As I alluded to, Pacman characters, like Ghosts and Pacman himself, will know how to move around in the maze. These characters have a reference to three tiles at all times, a CurrentTile, a NextTile, and a TargetTile. They also have a Directional enum property that we'll call a Heading.

The CurrentTile represents the current location of the character.

The NextTile represents the tile that the character will travel to on its current Heading. This is always one TileDistance away from the CurrentTile.

The TargetTile represents the tile that a character would like to go to.

Pacman and Ghosts use these properties slightly differently. But here is an example of how Pacman moves:
Note: pacman actually has two headings, the regular Heading and a CommandedHeading that holds the direction the user is trying to move pacman.

Private Sub IGamePiece_Move()
    
    If this.TargetTile.IsTraversable Then
        '//Go to target tile
        this.Heading = this.CommandedHeading
        Set this.CurrentTile = this.TargetTile
        
    ElseIf this.NextTile.IsTraversable Then
        Set this.CurrentTile = this.NextTile
    Else
        '//can't move
        Me.IsDead = True
    End If
    
    '//Aquire a the next desired tile and the next tile along the current path
    Set Me.TargetTile = MapManager.GetNextTile(this.CurrentTile, this.CommandedHeading)
    Set Me.NextTile = MapManager.GetNextTile(this.CurrentTile, this.Heading)
End Sub

So, in pacman's case, the TargetTile is the tile adjacent to the CurrentTile in the direction of the CommandedHeading. The NextTile is the tile adjacent in the direction of the current Heading. As pacman moves, he will check if the TargetTile is accessible. If it is, he'll change his Heading and go there. If it is not, he will check if the NextTile is accessible. If it is, he'll go there. Otherwise, he stops moving.

Map Serialization

I've already had a lot of "fun" with this. The MapManager has a method that will allow it to load a map from a file. Its fairly unsophisticated, but we just read in some tokens (w = wall, m = open path, p = pellet, P = super pellet, s = slow zone, etc) and have a TileFactory create the right tile for us.

Non-Moving game pieces

I'll go more into detail on issue #5 and #4 for pellets, but I'll briefly mention some of my half-baked thoughts here. My original idea was to use a boolean flag in the Tile object to indicate if there is a pellet to eat. But, I'm thinking I'd like to go down a different path. I was thinking maybe we could encapsulate some sort of Interact() logic in each of the non-pacman game pieces. Maybe it works like this:
We give Tiles an Interact Event and a DoInteractions() method that raises the event. Non-pacman game pieces would have a WithEvents CurrentTile reference and subscribe to the interact event. Here we put all the interaction logic for each type of gamepiece, should they encounter pacman. Pacman will call the CurrentTile.DoInteractions() method when he enters a tile to cause any other gamepiece occupying the same tile to carry out its interaction with pacman.

Thoughts?

[retailcoder]

I think the game needs to evaluate a tile's accessibility from various actors in a cycle, and a flag enum makes that check a bitwise comparison against the direction the actor would like to enter the tile from: it's stupid fast, makes the check essentially insignificant! Reversing the direction could be an "inverter" dictionary (keyed collection?) that maps enum values with their respective opposite-direction value, making the directional flip a O(1) hash lookup that isn't more work than achieving the same with arithmetics (although, it does need initialization).

I'm not sure about the non-moving elements, my "this might be over-abstracted / over-engineered" lights are flashing here; state isn't inherently evil, I think a v1 should not need to worry about those - keeping the end result and fixed specifications in mind, the risk of over-abstracting is that you end up coding a game engine that could make a Zelda game work with a few more tweaks ;-)

In your CR post you mention something about being unsure what needs to be injected as a dependency, and what can afford stronger coupling. The answer to that, is testability; if a unit test can inject surrogate dependencies that behave predictably (and don't actually hit the file system or a database, or a worksheet), then the output of the method under test can be predictably asserted, and its side-effects (on model state) can be asserted too. OTOH if a class news up its own dependencies, then a unit test can no longer be testing just the behavior under test: inevitably the dependencies that the test has no idea about will play their part, and when that involves state changes or other side-effects, then testing things can become impossible. For example in Battleship I had the player factory logic coupled with the controller; that made it impossible to write any test whatsoever for the controller, because tests had no way of instructing the controller what kind of players to create. In other words, the idea behind abstractions and architectural patterns (MVP/MVC/MVVM), is to decouple the components to enable that testability (whether there actually are any tests or not).

[archerbird]

you end up coding a game engine that could make a Zelda game work with a few more tweaks

🤔...