Help in bomberman like game with bump.lua (slide in blocks edges)

[bahamut]

I'm playing this on a laptop, but I presume the behavior is the same for all.

When I am right above a lane and press down, nothing happens most of the time, unless my pixels are lined up perfectly. The same happens when I try to enter a lane sideways. As shown in the top picture.



What I would expect, is the bottom picture. As long as the player is close enough to a lane, pressing down should cause the player to slide into the lane automatically. This means that you can still walk into wall blocks, but you don't have to perfectly line up the player any more. The game should do that for you.

But this way isnt coded yet, i'm trying do first the vertical movement. Try do this:

working fine with expected movement.png (68.77 KiB) Viewed 6753 times

Will work. But try do this and you will find the bug:

sometimes trembling problem.png (72.86 KiB) Viewed 6753 times

From Left or Right to Top or Down, I dont put the event, I will code when the vertical movement works fine, because is only a copy of the code.

[bahamut]

Yes, Imacaluta's second image is how Bomberman games have worked since the days of old. However, one thing to note is that Bomberman games (almost) never have lanes that are wider than one tile, so you can essentially make "soft-locking tiles": player slides from tile to tile, but can stop between tiles at any time. Thus in practice player is always standing on either one or two tiles. In addition to this, player is usually either walking vertically or horizontally on a given lane; not simultaneously as diagonals don't exist in classic Bomberman game modes.

The problem with the corners then comes from when player is standing between two tiles, which basically happens every time when you try to turn because lining up perfectly can be a bit difficult. To avoid this, you can do:

1) Check if player is trying to turn from a horizontal lane to a vertical lane or vice versa (could just check player inputs for these)
2) Find the two tiles the player is standing on (if player is standing perfectly only on one tile and there are no solid blocks on the path, then jump to step 5)
3) Find the closest eligible lane based on the tile(s) the player is standing on. If a solid block is blocking that lane, then stop here an do nothing in regards to turning.
4) Check if the threshold for turning the corner has been reached (perhaps check if 50% or more of player's collision box is already on the desired lane); this could be done with simple rectangle queries using bump
5) Move the player towards the lane if all the required conditions are met; if the player is standing on the lane then move along that lane

There are other ways to approach this, of course, as these are just some thoughts from the top of my head.

1) I check this with the comand input of the player, or he will not try enter in the corridors.
2) if the player still perfectly in one tile, he actually can enter (go to Top and try move to Right, you can do it, even removing the code to slip the character)
3) Alread done, in other way, the player enter inside the block and "teleport" to another place. I code the destination X and Y of the movement, with the check command of BUMP.lua.
4) Alread do it for the step 3
5) Alread done, he moves to Up until step 2), where he can enter in the corridor. (and i put a X +1 (or -1) to priorize the intention of enter instead of run ahead, with makes sense when you press two comands)

I have no problem with the logic of how to do it, but with the detail of the code. Try read the lines that I have mentioned (controls.lua, 69 to 98 if my mind dont fail).

Try like my last image, just press Right in that position of the block (a little above of the middle of the block); he will slip to Up until can enter in the middle of the blocks, like the movement expected in the Imaculata's second image.

I think is just a stupid detail that i'm missing do make the character stop to trembling when try enter in a horizontal corridor from the Top, like occour sometimes in my second image of my previous).

Working in the Y axis, I will add in the X axis too, but now, will not work in X axis...

[airstruck]

I thought this was an interesting challenge, so I put together a small demo. Some parts are a little hairy but it works pretty nicely. I hope this is helpful; also curious to see if this can be improved on or if anyone comes up with a better solution.

Because this kind of "physics" is pretty unique and needs some special care, I suspect Bump is not only unnecessary, it may actually get in the way. I'm not that familiar with Bump, though, so who knows.

The code is a little unintuitive in some places, but I tried to comment it thoroughly.

[MrFariator]

Your demo is pretty accurate; makes the character even turn at every fork if diagonal direction is held throughout the whole map (some more naive implementations just have the character keep walking on the same lane until inputs change).

I suppose as far as bump goes, its main benefit for a game like this is providing easy collision responses for things like collecting pick ups, taking damage from explosions, and others.

[bahamut]

Running your demo shows right the behavior that I want, like the expected movement that Imaculata talks. I will see the code here. Today, I started from zero, trying in other way (making step by step instead of put lots of conditions in one IF statement...)
I will check your code and see if I can adapt, althought you don't use bump, because he tell me the conditions of walkable tiles or not (like if I have the 'passbomb' or 'passwalls' pickups) easily. Thanks so much, I really appreciate your help!
Like MrFariator talks, thanks to BUMP, I can easily check my collisions or check itens in rectangles, get a table with them, see the names and atributes, coordinates, etc. For a starter, is very useful!

[airstruck]

Your demo is pretty accurate; makes the character even turn at every fork if diagonal direction is held throughout the whole map (some more naive implementations just have the character keep walking on the same lane until inputs change).

Thanks, the thing with diagonals was the main motivation for this demo; I felt like we both glossed over this in our replies and wanted to see what the solution might look like.

I suppose as far as bump goes, its main benefit for a game like this is providing easy collision responses for things like collecting pick ups, taking damage from explosions, and others.

This is something I wasn't sure how the original games handled. Does the player get hit by an explosion if only a small part of his hitbox is on that cell, or does the majority of it need to be on that cell? What about pickups? In any case this should amount to about 4 lines of code either way; Bump seems like overkill for that.

@bahamut, good luck, I hope it helps! Nothing wrong with a fresh start

By the way, "epsilon" may have been too low in that example; you should be able to avoid that epsilon-snapping thing altogether with a (carefully selected) fixed-timestep, but I thought that was a little off in the weeds for a simple demo.

[MrFariator]

Usually in most Bomberman games at least some 40~50% of the player's sprite needs to overlap with the explosion before it registers a hit (sample screenshot from Power Bomberman), so I assume it's a fair to say that it's the center-most pixels that are compared against. Can't remember from the top of my head, but the NES Bomberman might have had a less lenient hurtbox for the player. In any case, this seems to vary slightly between games (particularly the 3D and 2D titles), so experimentation is key to find what is fair for the player(s).

For Collectable pick-ups, their hitbox tends to be as large or smaller than the tile it occupies. Even then, player always needs to physically be standing on the tile in order to collect the item on it.

[bahamut]

Finally, I made the code =]
The airstruck's demo gave me the light that I needed, and now, works in vertical and horizontal lanes, with priority to change the direction. That "wasMovingVertically" was decisive (I don't created a var for this, the player can move diagonally), is the condition to my code stop with the trembling. Now my char walks smoothly like in the bomberman snes games. In future, I will post the engine complete with 4 players local (and with multiplayer via programs like Hamachi, if my messy code permits...).
And, I have coded for bombs damage the character considering 50% of the character sprite in the explosion tile as valid target (main objective of don't put tile-aligned movement). But I need really test if is 50% or 33%. If you play against COM, they walk very close to the explosions, waiting the bomb detonation. It is important, because my next step is "enemies and AI".
Thanks for all!

[airstruck]

Nice, glad you got it working! Will be interesting to see how the AI looks when it's done.

[Imaculata]

waiting the bomb detonation. It is important, because my next step is "enemies and AI".

First of all, great to hear you're making so much progress. In regards to enemies and AI, what I think Bomberman does, is it allows the enemies to detect zones that an explosion is about to hit. One way to do this, is to simply create explosion zones upon placing a bomb, which only kill a player once they actually explode. This may sound counter intuitive, but it allows your ai to detect which tiles to avoid before a bomb explodes.

There was an excellent Bomberman clone on the Amiga, called Blitzbombers. In Blitzbombers, the ai would actually yell out "NOOO!" when they knew they were trapped between bombs. And that AI in that game would also wait just out of reach of an explosion when a bomb was about to go off. The AI knew how far the explosion could reach.