I switched tracks from what I was originally expecting to do today and started a little bit of a restructure of the data structures that we’re using behind the scenes. The upcoming changes require interfacing with those data structures, and so ultimately I decided that I should make the required changes now while functionality is still simplistic so that it’s easier going forward.
This ultimately means that after a couple of hours of work, I’ve ended up with something that is (hopefully) visually identical in every regard to how it used to work, only now it’s happening in a different way. Huzzah?
What it boils down to is that the way things were originally written (for simplicity) involved a single array representing the maze, with each element representing an entity of some type. This means that rendering is as simple as iterating over the entire array, drawing the cells as we come across them.
This is all fast and great but runs into trouble in the situation where we want to decouple an element from the grid. Say for example we want a ball that has reached the goal at the bottom to fly up to the top corner of the screen, where it will award points. We can’t do that if the ball is held within the grid, and removing it from the grid stops it from rendering completely.
One way around this problem would be to have a list of entities that are not contained within the grid, and then iterate and render them. However that seems somewhat redundant because it would require yet another list, when we already have an ActorPool that knows about all of the live entities. It seems like a better idea to just render everything from the live entity lists; then as long as an entity is alive, it’s visible.
In ts-game-engine every Actor already contains a position and mapPosition property, where the first is the position on the screen and the second is a position within some arbitrary 2D grid (I wrote it that way exactly for situations such as this). So all we really need to do is make sure that every cell we put into the grid knows not only it’s screen location, but also it’s maze location, and everything will work the way we want it to.
This is fairly easy because there is a method in Maze called setCellAt which takes a cell and a position and updates the grid. This means that a modification to this method is all that is needed to stamp the appropriate location on pretty much everything with no extra work on our part. So that’s what I’ve done, along with a small tweak to the ball movement code so that it also updates the screen position as the ball is moving. That will be important later when (or if) we make the ball movement smoother by rendering it between positions.
The end result is something that works the same visually but is vastly easier to work with behind the scenes, which is always a net plus in my books. This will also pave the way for the maze grid to not have to store the outer walls, which makes it’s size smaller and the associated code clearer (the maze grid will be just the actual contents and nothing more).
That will be the goal for tomorrow, along with the start of the changes I originally intended for today, time permitting.