The first day of Devember is drawing to a close, and progress has been made. What we have so far is three different Entity subclasses, a Scene subclass capable of displaying them, and a rather uninteresting looking grid. It’s only the first day and already I’ve started in on the refactoring, so we know we’re going to have a good time on this one.
Things started out a little slowly while I got Sublime set up the way I want it. I’ve mentioned in a previous update, but a new version was released recently with support for Phantoms and the TypeScript plugin has been modified to support them. Along with that came a few other changes which slightly modify how things work (based on the last time I did any extensive TypeScript coding). As a result I had to spend a bit of time tweaking things to the way I want them to work.
With that out of the way, it was time to actually get some coding done. I set up the new Scene instance that will house the main game scene, and then started in on populating it with contents. The first thing to come was a Brick entity.
In my design, this is an entity which can exist in one of three states:
- Empty: In this state, the brick is rendered as a simple background tile, and it will not collide with anything
- Solid: In this state, the brick is rendered as a solid, unbreakable brick and will stop the ball from dropping through the maze. These are used to surround the playing area, and represent the outer bounds
- Gray: These are the bricks that will be a part of the actual game play area. They start out solid, but once all moves have been taken, they are removed from the play area, and gravity will draw the balls to a final resting position for final scoring.
I don’t know if I’ll stick with it, but for the moment all three of these bricks are implemented using a single entity subclass, since the only thing that differentiates them at the moment is what sprite they use to render themselves.
Once that was done, the next entity to come was the Maze entity. This is basically a wrapper around an array of instances of Brick entities. Going forward all logic in the game will be applied based on the contents of the maze grid, but for right now we just end up with something like this:
Here I did a bit of refactoring. Initially I just had an actual array of entity instances, but once I was sure everything was working I went back and modified things so that it contains instead only two unique entities; one for a brick that is solid, and one for a brick that is empty, and then those two instances are reused (actually at the moment empty cells are null and the rendering code knows to use the empty brick for that).
I have also set up a common base class for Brick and all future game related entities named MazeCell, just to keep everything nice and clear regarding roles. At the moment all this really provides is a class name more distinct than Entity to base things on, and a more simplified default constructor.
Hopefully this gets some of the more common boilerplate code out of the way and tomorrow will advance a little faster adding in the other possible grid contents, and I can start with actually generating a play area
The day’s code has been pushed to the public repository for perusal, although it’s not terribly interesting at the moment. Like last year I will be tagging the last commit of each day in order to make comparisons a little nicer for the sake of progress.
Something else that I thought of after the fact last year was a publicly available deployment of the current progress, so that anyone interested wouldn’t have to clone the repository in order to see the code in action. I’ve pushed the code to my game development site, and the URL for it is http://gamedev.nurdz.com/amazeballs/ although at the moment all it does is render the grid as seen above so it’s not terribly interesting.