Phaser Development: Maze Game

This week we made the basis of a procedurally generated maze game with the task to customize it with 2 new features. This week I thought i would work on the UI and sound since I didn’t touch on them last week.

First thing I did was to make a few variables to outline when I needed text to display, the 3 things that I planned to implement was a score counter, some text that notifies you that you have speed boost active and a message at the end of the level to say that it’s complete. With that in place I worked on them in that order, so first up was the score.

Nothing fancy, but gets the job done well

Of course that won’t update by itself so I needed to add that functionality to the gems (worth 250 points) and power-ups (worth 50 points) so that it will display the score variable.

Gem collected. 250 points gained.

The speed power-up was just the points code edited to be relevant to the situation, however I needed it to dissapear after a certain amount of time once its effect wore off, so I used the update function as a timer to disable the text after so many runs of update. This took some altering to get the time right but 300 seemed to be the sweet spot.

This makes sure the text is gone after the effect is over. Also a sneek peek into some music code!
Just in case the player didn’t know, they are going extra fast!

The final bit of UI was the maze complete text, code wasn’t anything new, just another alteration of the score text except it only displays once all the gems are collected .

4 Gems? Check. Home reached? Check. Text dispalyed? Check.

Next on the agenda was to implement some music. This was easier than I thought it would be but of course before we start coding, we need to put it in preload! With that quickly done it was time to make an object with all the music and sounds I plan to use.

I also made sure that the background music was playing too.

After this it was simply a case of repeating the line whenever I needed something to play so there isn’t anything else major to document, and sadly images cannot play music so showing it off is a bit difficult.

Overall I had a lot of fun implementing these customisations into the game and it also turned out to be a lot easier than I thought, this does incentivise me to try some more ambitious things in the future as they may not be as difficult as I thought.


Phaser Development: Tank Wars

This week I have been working on adding some extra features to a tank game that I was tasked to make. I feel like i’ve been talking about Phaser on this blog but not really showing much of my own, so this week aims to fix that.

The first feature I added was a new type of tank I called the Hyper Tank which would act as a very powerful tank, so first I recoloured the tank assets so that I could visually tell the tanks apart and made the canon wider to give it a more powerful look, I think the atlas came out well.

The Hyper Tank sprite atlas

Next was making a class for this tank. It was a fairly straightforward implementation due to the existance of other classes I could extend and simply change a few variables. Looking back I did make the tank far too powerful but it gave me a bit of a laugh so I decided to keep it.

The class for my Hyper Tank. Short code, deadly power.

After that it was simply a couple extra checks in the scene to check for the spawn point and it was in the game ready to decimate, and oh boy did it do some damage…

I don’t think I can outrun this. Game Over.

My second addition was another level, so first thing on the list was to make it in Tiled. Nothing too interesting here, just randomised the ground tiles and set up a different configuration of wall tiles and then dot around some eney spawn points.

Nothing revolutionary, but gets the job done.

Next I decided to make a base scene class to make the actual scene classes a lot more compact, this was a proceess of figuring what functions and lines would be shared between the scenes. The update function did start to mess up a bit after this so I returned it into the actual scene which fixed the issues

A preview of the BaseScene class

With this done, I could make a very consice second scene which looked like this:

With all this in place, all that was left was to make it appear in game. So I wrote an if statment to check if all the tanks were dead, sadly I had issues with this part of the code, but the second scene still loads in fine, so i’ll have to check that out after this post.

Overall this project was pretty fun and it proved to me how useful classes can be for adding new things like levels and eneimes to a game. Some parts were tricky like adding the small parts across multiple files for multiple scenes to work but the overall amount of code is lower than I thought it would have been.


History of tilemaps and sprite sheets in 2D games

Phaser tilemaps and sprite sheets are very versatile and customisable, with tile heights and width being able to be changed to whatever the developer needs and can have impressive amounts of tiles/frames and resolution, however they have not always been like this so I thought it would be intersting to take a look at some older hardware and see how graphics were at the beginning.

Phaser uses a .json file to hold lots of information about tile sizes and layouts which allows for high customisablility in its tilemaps.

The third generation of video game consoles was the first time sprite sheets and tilemaps were used prominently in the home market, the main consoles of this era were the Nintendo Entertainment System (NES) and SEGA Master System, which both had very similar graphical capabilities. Both has sprite limits of just 8×8 or 8×16 pixels and could render 64 of these, which may seem a lot but due to the sprite size many characters or objects would often used around 4 to 8 sprites to increase their size and add more detail, however they were still very colour limited with that being controlled separatley in the PPU in the NES where developers had to specify which palettes to use.

Super Mario Bros.’s Mario used 4 or 8 sprites combined together to create the illusion that he was one singular object. Src:

Tilemaps were only used for backgrounds, being an 8×8 or 16×16 atlas of small single colour areas that the graphics unit would used to render a simple background colour. Tilemaps would get a big upgrade in the next generation of consoles with the Super Nintendo Entertainment System (SNES) and Sega Mega Drive with the use of multiple parallax backgrounds and scaling. Sprite sheets also got an upgrade with up to 64×64 sprites on the SNES and 16 colours per sprite which greatly enhanced the graphics quality of games.

SimCity for the SNES utilised the enhanced tilemaps on the menu screen to create a scrolling cityscape with much more detail then its predecesor console.

Home computers often relied more on tilemaps rather than sprites such as the Commodore 64 using custom character sets that acted very similar to tilemaps, of course it came with lots of limitations like only 2 colours per character (4 colours in half-res mode) but many games were made like this such as the Ultima games and more recently, Planet X2. Even when the more modern style home computeres came around in the 90’s with EGA and VGA graphics, tilemaps were still very prominent just with greater capabilities such has higher resolutions and more colours, plus sprite were more commonly adopoted as PC’s became more powerful.

David Murray’s Planet X2 uses edited character sets on the Commodore 64 to create graphics completley in a tilemap. Src:

I think its very interesting to look back at all the limitation of video games in the 80’s and 90’s and I’d love to take on the challenge of making a game with these limits, whether that be on actual hardware or just limiting myself on a more modern engine as I feel it would get me to think in ways that I wouldn’t usually and would incetivise me to optimise more.