Bomberman 64 Playthrough

[Magdalen Dano]

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).

The last few posts here have taken us on a rare and exciting trip into Vast Fame town, but, well, nothing lasts forever. Except, of course, for Sintax's game library. So we're back here again, once more taking a dive, Scrooge McDuck like, into that seemingly bottomless pit of brightly-coloured cartridges. Sorry to do this to you in pride month hangover month but my sporadic posting habits on here have long since drifted free of any anchoring in real-world festivities. (Remember when I actually timed releases for Christmas hahahaha yeah)

Today's selection comes from the later era of Sintax's Game Boy Color development, around 2004-2005, firmly in their "decline" period, so don't expect peak quality or anything. There isn't really a theme beyond that, but I did realise after putting this post together that 3 of them have titles referring to some kind of "super man" (超人) in Chinese, so you could pretend that was intentional.

Big thanks to Lady Bluestreak for buying this one! This is one of the more distinctive of Sintax's later efforts, being an honest-to-god Bomberman clone and not just a bad generic platformer or rehash of something from previous years. The main title alludes to "Crazy Arcade", a longstanding online game, and the ingame sprite does seem to resemble its characters, but they also hedged their bets a bit with the label depicting a regular-style Bomberman and a subtitle translating to "Super Bomberman".

(It's also one of their later GBC releases that shipped in GBA-sized carts, mostly seen in the Taiwanese market, meaning it's only physically compatible with GBA & GBA SP despite actually being a GBC game)

The classic Bomberman gameplay is present here, but it comes off a little more exploration-focused since you have these big open scrolling levels and you need to find 3 keys in each to unlock the exit, which you also need to find. It's quite apparent also that, despite the change in gameplay and perspective, this game is at least somewhat based on the same codebase as Sintax's contemporary late platform games, featuring the same odd palette shift when you pause the game, the same GBC Lemmings music and even some leftover graphics from those games in the ROM.

Feng Kuang A Gei III - Chao Ji Zha Dan Ren (Unl) (Chn) [C] [GBX].zip

Feng Kuang A Gei III - Chao Ji Zha Dan Ren (Unl) (Chn) [C] [Raw].zip

Feng Kuang A Gei III - Chao Ji Zha Dan Ren (Unl) (Chn) [C] [Cracked].zip

I THINK this one is based on the MMORPG Lineage, which is called 天堂 in Chinese, but I don't know enough about Lineage to substantiate that. Game-wise it's a straight reskin of Sintax' old Star Wars game, which is... alright!

The Incredibles, unfortunately, have been cursed to appear in an iteration of Sintax's Bad Late Platformer Engine, which most commonly hosts Pokemon games like The Original Pokemon Platinum, but has also counted Sonik the Coolhog among its victims. You can pick from 3 characters which all play the same and all have a seemingly non-functional MP gauge, and then you have to search for the exit in a handful of mazelike platformer levels, before fighting a final boss which may or may not be from the movie (which I haven't seen). Naturally GBC Lemmings music plays throughout all of this.

Finally, this is a particularly weird one. It seems pretty obvious that they set out to make a Metroid game here, with an intro and character sprite depicting Samus, and a plot resembling Metroid Fusion's. But at some point they decided to switch gears, for some reason, turning it into "Ultraman" simply by replacing the title screen and nothing else. And if you were hoping they might've at least rehashed their Metroidvania-like Castlevania game for this attempt... well, no, it's just the Metal Slug clone Yue Nan Zhan Yi 3 with the sprites replaced and the level order changed around.

3a8082e126