Bomberman

5 Feb 2016

It has been a while since I made any updates to the blog. Life has been busy, and often I come home from class with a bunch of homework that needs to be completed. Granted, I could have used the weekends for updates. Oh well. Let’s talk about what happened in Week 3.

Week 3 was especially hectic, and stressful. It was the week we had to work on our first project, and I went a little overboard with what I wanted to make for my game. While others chose to make simple visual novels and time-based challenges, I chose to recreate Bomberman. I didn’t think it was difficult at the time, in fact I thought it was pretty straightforward…. that was until the day I started working on the project.

So what did I learn? Well firstly I found out (the hard way) why games have “game loops”, or frames per second. There are several reasons for this. For instance, imagine what would happen if you held down two keys at a time on a word document – the computer would only register and print out one letter at a time, so in the instance of Bomberman, it would be impossible to move a character diagonally on a map as it means holding down A and W to move North-West. Likewise, it would be impossible for two players to play Bomberman if only one character could move at a time. Also when a key is held down, only one letter will be registered within the first 2 seconds, before the computer registers that the key has been held down, which causes player movements to stutter. How a game loop counteracts this is that it creates a set interval timer that refreshes a set number of milliseconds, depending on how many frames per second you would like the game to run for. For instance, 60fps would be 1000ms/60 which would set the interval at 17ms, so every 17 milliseconds the computer would check if a key has been pressed down, and if a key has been released. If keydown is true, then the character would move, else if the keyup for that key is true, the character would would stop moving and keydown will become false. This way, the computer is able to register for multiple keys being pressed simultaneously.

Another challenge was making sure the characters were able to detect collisions based on their surroundings. To do this, I constructed an array of arrays in the Javascript file that defined the basic map setup. It looked like this:

Screen Shot 2016-02-14 at 10.38.01 PM.png

Here, ‘R’ stands for Rock (which is impassable and indestructible), ‘E’ stands for Empty space (which characters can pass through), and ‘A’ stands for a cell that randomly generates either a Wooden block (that can be destroyed) or an Empty space. Hence when the game starts, ‘A’ would change into either ‘W’ or ‘E’, which would in turn be reflected in the CSS.

I then created a player constructor function that identified the CSS positional values of the top, right, bottom and left borders of the character based on their starting position on the map.  For instance, player 1’s default starting position is on the upper-left empty cell on map (or (1, 1) in the array). Given that all cells are equal sizes (40 square pixels), and there’s a Rock above and to the left of the empty space that player 1 starts in, player 1’s starting border values would be Top-border: +40px from top, and Left-border: +40px from left. Given the character size is 30 square pixels, Bottom-border would be +70px from top, and Right-border: +70px from left. If player 1 moves right, its left and right border values would increase and the game loop would continuously check before every single pixel movement whether the character’s right-border is divisible by 40 (i.e. reaches +80px). If it does, the game loop needs to check whether or not the character cell to the immediate right is an Empty space. If it is a Rock or Wooden block, obviously the character wouldn’t be able to transition into that cell, but if it is an Empty space, the character would be allowed to transition. When this happens, p1 would be present in 2 arrays in the Javascript map, an ‘original cell’ and a ‘new cell’. When p1’s borders are fully within one of the cells, the other cell would become an Empty space, ‘new cell’ would render false, and the cell that p1 is in would become an ‘original cell’, hence completing the player transition.

I encountered a lot more challenges during the development of the game, for instance, the creation of bomb objects was tricky because their explosions also needed to detect for collisions, and having them detonate off of each other was particularly noteworthy. But the above were some of the more immediate challenges that come to mind when I was developing my game.

What are some aspects that come to your mind when you think about developing a game like Bomberman?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s