Today’s update is going to be pretty short and sweet because there’s not a whole lot to say: level editing has been added to make testing easier. A small demo:
I really waffled on what to do today because the notion of getting the ball visibly slowly moving through the maze is fairly compelling; once that’s implemented, the only things really missing to make a more playable prototype are a user controlled player to push the balls and some simple AI to have the computer select moves and we’re most of the way there.
However, before I got into that I decided that it was probably best to include at least simplistic level editing abilities to make that aspect go faster. Just with what has already been implemented I’ve felt the pinch of having to keep regenerating levels until I got something with a layout that allowed me to set up the situation that I needed to test (this is why there is a key for regenerating the maze). So I just sat down and toughed it out and we should be good to go now.
I implemented a simple debug mode in the maze code which, when turned on, tracks the current mouse location and overlays a red Marker instance on that cell to indicate to you what you will be manipulating. When in this mode, various keyboard keys will perform an operation on the current cell; adding, deleting or toggling.
In order to keep the number of keyboard shortcuts down, entities that are visually represented in more than one manner (Ball, Brick and Arrow) are inserted in a single generic form, with a key that toggles them to their alternate state. The Teleport entity exists in only one state, so it’s just inserted directly.
Additionally, since the Ball, Brick and Arrow entities use ActorPool to hold instances (and in the case of Brick there are two, one for the gray bricks and one for the bonus bricks) inserting an entity requires pulling an entity of the required type out of the associated pool for addition in the level, while toggling of a brick requires swapping an entity between pools. Due to the current engine limitation on creating entities at runtime if they preload images, this means that there is a set limit on the number of such entities there can be in the level.
The Teleport entity is handled specially. There is only a single created entity of this type, which is included multiple times into the maze at each maze location it is needed. This entity contains a list of all of the locations where it has been added. This allows the single entity to jump the ball between other occurrences of itself easily. So inserting or deleting an entity of this type mostly revolves around adding or removing a destination from the list. The entity itself is smart enough to not operate when it has only a single destination available (to prepare for not selecting a destination that is blocked by a ball, for example).
The animated GIF above is just a simple demonstration and doesn’t show all of the possibilities. If you’d like to play around, you can view the live version of the code (updated nightly during Devember to the latest version prior to posting the associated blog post) at: http://gamedev.nurdz.com/amazeballs/. The page contains popup help for the controls available. This is not complete (clicking on an arrow rotates it and clicking on a ball drops it), but it gets the job done.
Tomorrow we shall embark upon making a single ball slowly track through the maze, so that we can see what’s happening better.