Bomberman Rules

[Hollis Abdelkarim]

Informativearticle. Very easy-to-digest article that really puts the ECS into good use. Thanks for sharing this!

A note: I know you provided the source code, but it would be nice if you could put up a small example of methods and logic of a system as well. Just briefly, as you have with components above.

Bomberman is a product of an 8bit/16bit era and ran on systems that had very little ram and weren't programmed in higher level languages. As such there were no "powerup components". Powerups were just tiles placed in the map. Making them components and or having them as active game objects would have taken too much ram and too much processing. As tiles they are effectively static. The player tries to take a step in the direction of the powerup. The code looks at the tile, sees it's a powerup tile, replaces the tile with a ground tile and sets a flag in the player they he now has that powerup (or one more bomb).

As another example bombs don't expand. They blow up at their defined size instantly. (Google SNES Bomberman video to see).

The article is a great introduction into ECS but it's also arguably an introduction into over engineering. Sorry, that sounds like a judgement and arguably anyway your game works is fine. It's just the limits of old systems forced or suggested different solutions. Those solutions have their own advantages and disadvantages.

For example, using the tile based (non GameObject) solution you can easily make a level that is filled with bombs because the bombs themselves are tiles. They can only be placed on tile boundaries. When you place one the ground tile is replaced with bomb tile. That means having 1 or 1000 bombs takes the same amount of processing. They only become gameobjects when they are moving and usually only a few are moving at any one time. Possibly max 2 per player. In other words the bomb is tile, if the player kicks a bomb tile (and has the kick powerup) the tile is replaced with a ground tile, a gameobject is spawned, the bomb moves down the hall until it hits the end or the player stops it, the closest ground tile is changed to back to a bomb tile and the gameobject is destroyed.

The bombs can appear to "tick" using tile animation. Rather than a gameobject per bomb all you need is an array of bomb tile locations and a time they were placed. A single function walks the array, any bomb who's time is up explodes the tile. So much less overhead. In fact because bombs are added to the array/queue as they are placed the code only has to check the oldest bomb. So in general only one bomb needs to be checked each frame to see if it's time to explode (or 2 or 3 for those rare occasions where 2 or more players put bombs down on exactly the same frame)

Even explosions are tiles. The moment a bomb explodes the code goes and replaces ground tiles down the aisles with explosion tiles. That means all the aisles on the entire board can be explosion tiles and again there is no processing. (tile animation effectively free on those old systems and can be replicated to be free on modern GPUs. Similarly it makes collisions easy. Each player just checks the max 2 tiles they are straddling. If they are explosion tiles they player dies.

In gameobject terms, the original bomberman likely only had 1 gameobject per player and 1 gameobject per moving bomb. Everything else was tiles with a few arrays to remember which tiles to change later (like changing explosion tiles back into ground tiles when the explosion is done)

Having bombs as tiles also has other advantages. Collisions are simple. The player checks if the tile he's on is an explosion tile, if so he dies, then he checks in the direction he's moving. If that's explosion he dies, if it's a powerup he changes it to a ground tile, if it's ground he moves, if it's anything thing else he can't go that way. So, bombs become barriers without any extra code.

I wouldn't even be surprised if kicked bombs sliding down hallways weren't placing tiles in the hallway as they slide down it. Either tiles with a bomb image offset or some tiles that looked like ground but were actually "bomb is sliding here" tiles. That way if another player tried to enter an aisle at the exact time a bomb is sliding by his tile checking code will prevent him from walking into the tile and so you wouldn't need any special "is there a gameobject version of a bomb here" collision code. Similarly the tile/tiles under each player might also be special "play is standing here" tiles so similarly a bomb sliding down a hallway will know to how to stop just by checking the tile in front of them instead of having to check gameobject positions.

Well, I wasn't making any attempt to "stay true" to the original bomberman code (if anything, the opposite). I just chose Bomberman because it has an interesting set of gameplay mechanics that most people are familiar with.

I'm sure you're right that performance would be better - but that kind of speed is completely unnecessary, and you'd end up with bug-prone code that is difficult to modify or extend (for a small game like Bomberman, it may not be a big deal). Never a good trade-off. And you'd have to do yucky things like the following:

Modern hardware allows us the luxury of superior coding practices. There's no way you'd be able to efficiently create a typical modern game with the type of code that the original Bomberman would have been limited to.

How is that less overhead? Did you actually look at the article's code? That's pretty much exactly how it works. There's an array of Bomb components that the BombSystem iterates over and decreases their timer. It's extremely simple. (And yes, you do need to check all bombs).

I dreamt about a board game a couple of nights ago, but of course couldn't remember the details when I woke up. All I could conjure up was an image of a sort of maze, and it somewhy reminded me of Bomberman. And then I thought, why not try to turn Bomberman into a board game. I have some free time (vacation) and could use a project like this. Could be fun -- a bit chaotic like Robo Rally, but less random and quicker.

I sketched up some rules and drew a board, and did some test games with 4 players (all controlled by me), tweaking the rules a bit after each play. Seems ok so far, but I can't really test on myself, so I'll try to get some people to playtest during the next few days.

I was wondering though -- Bomberman as a board game somewhy seems a rather obvious idea to try -- do any of you know about any similar attempts, or actual published board games that could be considered similar to Bomberman? I did a google search, and that came up with a couple of descriptions of similar attempts, one even included the rules text.

Players start with 1 bomb, and with firepower of 1. Power-ups (+1 to bombs, firepower or movement) can be picked up from destroyed walls. The goal is to bomb the other players to death and be the last man-of-bombs standing. Choose a starting player, although it doesn't matter much in the beginning.

There are some more details, but this is the gist of it. If the wall in the center of the board is destroyed, it will go into end-game mode, where players automatically receive additional power-ups at the start of each round. This seems to guarantee that there won't be a very long cat-and-mouse game, as one player should eventually be able to surround the other with bombs.

Just did my first play test with another player. 2 player was not so good, but when we each controlled 2 characters it was already quite fun and chaotic. Will try to get some real 4 player tests going in a couple of days.

Instead of everyone making a single 5+ step movement, players have 5+ 1-step moves, and they take turns resolving them. And there's no "narrow escape" phase. I tried it by myself, but I can't really trust what it seemed like since you have to react much more in this mode, and how do I react to myself? Slows the game down quite a bit as well, but on the other hand it is more like the real Bomberman -- now it's much more imporant how close you are to something instead of who has the next move. E.g. no matter if the other player goes first, I can get that power-up because I'm closer to it.

I have written a complete draft of the rules doc, and if anyone is interested, I'll also make a board that you can print out on an A4 paper. You would also need to use components from other games (I used Agricola's, but I assume some others would work as well).

One additional idea I got was a hex board that would allow up to 6 players. I just tested this by myself and that seems even more promising and chaotic! Also more dangerous from the start, which is good, I think. And also yields initial power-ups faster*. The only concern is that it's more complex than the rectangular board, and even the rectangular board showed that at some point the game kind of slowed down due to excessive thinking time (but was still only about 30 mins). A sand clock was suggested.

Here's an in-progress hex board -- print on A3 if you can (and want to help play test). It can fit on an A4 too, but is a bit small (at least with Agricola components). It doesn't have the places for power-ups that the square one had, but those can be kept outside of the board. Maybe I'll introduce player sheets for those anyway.

Rules are exactly the same as the square board. The black hexes are impassable, gray hexes are destroyable walls -- light is uncertain reward and dark is certain reward. Yellow is also certain reward, and triggers the end-game automatic power-up get.

3a8082e126