Bomberman's deplacement style

[cChaD]

Hi everyone,

I'm looking for reproduce deplacement like in Super Bomberman 2 on SNES

It's mean, that if the player is moving with 2 key pressed simultaneously, the player begins with the movements planned for the first key pressed until returned to colision with a block and then hands over to the second key

Example with

TOP + RIGHT



So I do not know how to reorganize my code to manage that ...

Here are the current that manages only one button at a time.

(click to show/hide)

void Application::Update(sf::Time time)
{
    mPlayer->Update(time);

    if(!mMap->CollisionWith(*mPlayer))
        mPlayer->move(mPlayer->GetMovement());

}

Player::~Player()
{
    for(unsigned int i = 0; i < mAnims.size(); i++)
        delete mAnims[i];
}

void Player::SetSpeed(float speed)
{
    mSpeed = speed;
}

const int Player::GetDirection()
{
    return mDirection;
}

const sf::FloatRect Player::GetBoundingBox()
{
    return mBoundingBox;
}

const sf::Vector2f Player::GetMovement()
{
    return mMovement;
}

void Player::Update(sf::Time time)
{
    mMovement = sf::Vector2f(0.0f, 0.0f);

    if(sf::Keyboard::isKeyPressed(sf::Keyboard::Up))
    {
        mCurrentAnim    = mAnims[0];
        mMovement.y    -= mSpeed;
        mNotPressed     = false;
        mDirection      = UP;
    }

    else if(sf::Keyboard::isKeyPressed(sf::Keyboard::Down))
    {
        mCurrentAnim    = mAnims[1];
        mMovement.y    += mSpeed;
        mNotPressed     = false;
        mDirection      = DOWN;
    }

    else if(sf::Keyboard::isKeyPressed(sf::Keyboard::Left))
    {
        mCurrentAnim    = mAnims[2];
        mMovement.x    -= mSpeed;
        mNotPressed     = false;
        mDirection      = LEFT;
    }

    else if(sf::Keyboard::isKeyPressed(sf::Keyboard::Right))
    {
        mCurrentAnim    = mAnims[3];
        mMovement.x    += mSpeed;
        mNotPressed     = false;
        mDirection      = RIGHT;
    }

    mMovement *= time.asSeconds();

    this->StartAnimation(mCurrentAnim);

    mBoundingBox = sf::FloatRect(this->getPosition().x, this->getPosition().y + (getGlobalBounds().height - 40), 40, 40);

    if(mNotPressed)
        this->StopAnimation();

    mNotPressed = true;

    Entity::Update(time);
}

bool Map::CollisionWith(Player &player)
{
    sf::FloatRect box = player.GetBoundingBox();
    sf::Vector2f  movement = player.GetMovement();
    int topLeftX, topLeftY, topRightX, topRightY, bottomLeftX, bottomLeftY, bottomRightX, bottomRightY;
    const int direction = player.GetDirection();

    topLeftX        = (box.left + movement.x) / TILE_SIZE;
    topLeftY        = (box.top + movement.y) / TILE_SIZE;
    topRightX       = (box.left + movement.x + TILE_SIZE - 1) / TILE_SIZE;
    topRightY       = (box.top + movement.y) / TILE_SIZE;
    bottomLeftX     = (box.left + movement.x) / TILE_SIZE;
    bottomLeftY     = (box.top + movement.y + TILE_SIZE - 1) / TILE_SIZE;
    bottomRightX    = (box.left + movement.x + TILE_SIZE - 1) / TILE_SIZE;
    bottomRightY    = (box.top + movement.y + TILE_SIZE - 1) / TILE_SIZE;

    switch(direction)
    {
        // Haut
        case 0:
            if(mCases[topLeftY][topLeftX]->GetType() < 2 || mCases[topRightY][topRightX]->GetType() < 2)
            {
                player.setPosition(player.getPosition().x, mCases[topLeftY][topLeftX]->GetPosition().y + (box.height - (player.getGlobalBounds().height - 40)));
                return true;
            }

            break;

        // Bas
        case 1:
            if(mCases[bottomLeftY][bottomLeftX]->GetType() < 2 || mCases[bottomRightY][bottomRightX]->GetType() < 2)
            {
                player.setPosition(player.getPosition().x, mCases[bottomLeftY][bottomLeftX]->GetPosition().y - player.getGlobalBounds().height);
                return true;
            }

            break;

        // Left
        case 2:
            if(mCases[topLeftY][topLeftX]->GetType() < 2 || mCases[bottomLeftY][bottomLeftX]->GetType() < 2)
            {
                player.setPosition(mCases[topLeftY][topLeftX]->GetPosition().x + box.width, player.getPosition().y);
                return true;
            }

            break;

        // Right
        case 3:

            if(mCases[topRightY][topRightX]->GetType() < 2 || mCases[bottomRightY][bottomRightX]->GetType() < 2)
            {
                player.setPosition(mCases[topRightY][topRightX]->GetPosition().x - box.width, player.getPosition().y);
                return true;
            }

            break;
    }

    return false;
}

Thanks.

[Hapax]

I don't think this game moves in the direction of the first key pressed then the next, I think it looks like it moves depending on which direction is available. It's likely that it would prioritise the movement that it isn't travelling in to allow easily controlled "junctions".

[cChaD]

Yes, it's right but i don't know how implement this, because if i press 2 key and moving, just only one direction is checked and i can't check more than one.

I think that my current code is not adapted for use it... 

[Hapax]

Check for all directions and then allow it to make a decision on which one it should use.
e.g.
Is up pressed? yes
Is right pressed? yes
Is down pressed? no
Is left pressed? no
Can move up? yes
Can move right? no
Can move down? yes
Can move left? no

Matching these shows that it should move up.

That should get you started... 

[shadowmouse]

I was actually about to post the same thing. Another way of doing it is having two signed char (or other numeric type) variables, one to store vertical and one horizontal. This can sometimes be useful for either acceleration, or to stop the character trying to move both up and down at the same time.

[cChaD]

actually my only problem come from the colision, If right and down are pressed mMovement.x et mMovement.y are positive...

and it's like this(not really but its just for show you how the collision "see" it).

[TheNess]

I will first give a solution then explain why its not good
you should separate the movement and the animations, meaning do something like this (in pseudo code):

// do movement:
if (key_up_pressed && can_move_up):
    move_up();
else if (key_down_pressed && can_move_down):
    move_down();
if (key_left_pressed && can_move_left):
    move_left();
else if (key_right_pressed && can_move_right):
    move_right();

// do animation
if (key_up_pressed):
    animate_run_up();
else if (key_down_pressed):
    animate_run_down();
else if (key_left_pressed):
    animate_run_left();
else if (key_right_pressed):
    animate_run_right();

 

with this basic logic you have several advantages:
1. the player is not "sticky" to walls, i.e. if you press up and left and he can't move up, he will still move left and won't get stuck
2. player will still animate walking while colliding with walls, which is how bombarman works if I remember correctly. anyway its just my own opinion but I prefer games where your character keeps on the walking animation while stucking at walls rather then games that the character just stop and stand because it collided  with a wall.

now here's why I don't think its an ideal solution:
I believe in always integrating physics into your game rather then implement them yourself. you can never know what kind of physics you gonna need tomorrow. maybe sliding surfaces? bouncy bombs? explosion pushing you back? pushable objects? surfaces with higher friction?.. etc. etc. since implementing your own physics limit your possibilities (every feature suddenly becomes costy), I always recommend to use physics engine (such as box2d) rather then to implement the collision & physics yourself. even for "simple" games (no game is simple! )

with that said, if you are still kind of new to this and/or this is just an experimental / hobby / study project, forget about what I said and don't worry about implementing a naive collision detection yourself. its a good practice and anyway messing with physics lib while you are still learning to handle the graphics/game-play can be a bit messy.

[Silderan]

I think TheNess gives you the correct answer.
Maybe you coded like this:

if( up_pressed() )
{
    if( can_move_up() )
        move_up();
}
else
if( down_pressed() )
{
....
}
else
...
 

So, player won't chose the avaiable direction.

By the way, I prefer modify TheNess code in that way:

// do movement:
if (key_up_pressed && can_move_up):
{
    move_up();
    animate_run_up();
}
else if (key_down_pressed && can_move_down):
{
    move_down();
    animate_run_down();
}
if (key_left_pressed && can_move_left):
{
    move_left();
    animate_run_left();
}
else if (key_right_pressed && can_move_right):
{
    move_right();
    animate_run_right();
}
else
{
    // do animation
    if (key_up_pressed):
        animate_run_up();
    else if (key_down_pressed):
        animate_run_down();
    else if (key_left_pressed):
        animate_run_left();
    else if (key_right_pressed):
        animate_run_right();
}
 

If I'm not wrong, this way the player won't do the "moonwalk" facing up and moving left (for example)

[Arcade]

I've worked on a Bomberman clone before and the movement can be pretty tricky.

 I don't know if you have run into this problem yet, but in the App Test screenshot you provided, what happens when the player presses left? The bottom of the player will clip the top of the wall and, without any extra logic in there, the player will not move anywhere. This can be a bad player experience because it can be really hard to line up the player with the hole so that you can move left. A more ideal solution would be if the player presses left and is barely hitting the edge of a wall like in your screenshot, you first make them move up until they line up with the hole, and then start actually moving left. This is what the real Bomberman game does.

However this introduces even more edge cases to think about. What if the player presses Left and Up at the same time? Do you make them go straight up or turn into the hole? I've found that I like prioritizing the change in direction (in this case Left) first such that the player can "zig-zag" though the level without the player getting frustrated with the controls. Again, this means you slide the player up a bit first such that it exactly lines up with the hole, then turn left instead of continuing on in the Up direction.

What happens in the player presses Left and Down? You need to recognize this case because you probably want to handle it different than the other cases I mentioned. You probably do not want to slide the player up first in this example. You probably want to go Down first.

And of course you need to also consider if you're clipping the bottom of a wall instead of the top. Also consider all 4 directions. Like I said, bomberman movement can be trickier than it first seems 

[cChaD]

I understand all what you means but for check the collision i need check if the player pos + movement are inside a case and replace him if needed.

So if the player press left and top, the player is always replaced because Movement.x and Movement.y are increased  ! 

[Hapax]

Test to see if the movement is valid before performing collision detections on the new movement.

[cChaD]

Test to see if the movement is valid before performing collision detections on the new movement.

Sorry, I don't understand.

[TheNess]

I understand all what you means but for check the collision i need check if the player pos + movement are inside a case and replace him if needed.

So if the player press left and top, the player is always replaced because Movement.x and Movement.y are increased  ! 

You talk as if you have no control over the code  . lol just change your logic flow. like Hapax said, first do collision test on the predicted position and only then move the player. you know the current position and the speed, so predicting next step is just position + speed.
and if for some reason its a problem, you can always store the previous position, move, and if collision detected restore to previous pos (on x and y axis separately).

to Arcade - the problems you mentioned are just more reasons to use physics lib (with player having a circular shape and 'sliding' on walls)
but if I'm not mistaken in bomberman the movement is aligned, i.e. the player will only stop walking on multiplies of X pixels. for example, if the player walking is aligned to 8 pixels and while walking up the player released the up key at position of 32x13, the player will keep on walking up for 3 more pixels so he will end up standing on 32x16. this requires a little rounding due to framerate independence making the final position inaccurate, but after implementing this you won't have problem with aligning the player on the holes.
I think in bomberman if you collide with a wall it also moves him a bit on the other axis to fit to the opening right?

[cChaD]

The movement is not always the same it's because i replace the player.

[TheNess]

The movement is not always the same it's because i replace the player.

I don't mean to disrespect, but can you please stop making up problems??? 
so what if the movement changes? you still know it! even if you do some crazy random movement every frame, something like this:

player.x += rand();

you can still turn it into this:

float movex = rand();
player.x += movex;

and predict the next step before the actual movement.
there is no reason, and I repeat, NO REASON why you can't predict the next step of the player you move.
and if I didn't understand what you meant I apologize and please explain better