SFML community forums

Help => Graphics => Topic started by: cChaD on January 26, 2015, 12:36:28 am

Title: Bomberman's deplacement style
Post by: cChaD on January 26, 2015, 12:36:28 am
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

(http://img11.hostingpics.net/pics/959318red5eef90gtpo0cuu239a6ecn1cr514221108258034animation3250vite.gif)

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)


Thanks.
Title: Re: Bomberman's deplacement style
Post by: Hapax on January 26, 2015, 01:34:11 am
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".
Title: Re: Bomberman's deplacement style
Post by: cChaD on January 26, 2015, 10:42:40 pm
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...  :-\
Title: Re: Bomberman's deplacement style
Post by: Hapax on January 26, 2015, 10:55:41 pm
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...  ;)
Title: Re: Bomberman's deplacement style
Post by: shadowmouse on January 26, 2015, 11:00:04 pm
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.
Title: Re: Bomberman's deplacement style
Post by: cChaD on January 27, 2015, 12:14:30 am
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).

(http://puu.sh/f4BD7/dc546b56d9.png)

Title: Re: Bomberman's deplacement style
Post by: TheNess on January 27, 2015, 11:04:57 am
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! :P)

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. :)
Title: Re: Bomberman's deplacement style
Post by: Silderan on January 27, 2015, 02:32:57 pm
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" 8) facing up and moving left (for example)
Title: Re: Bomberman's deplacement style
Post by: Arcade on January 27, 2015, 05:25:21 pm
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  ;)
Title: Re: Bomberman's deplacement style
Post by: cChaD on January 27, 2015, 11:03:05 pm
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  !  :'(
Title: Re: Bomberman's deplacement style
Post by: Hapax on January 27, 2015, 11:17:30 pm
Test to see if the movement is valid before performing collision detections on the new movement.
Title: Re: Bomberman's deplacement style
Post by: cChaD on January 27, 2015, 11:24:08 pm
Quote
Test to see if the movement is valid before performing collision detections on the new movement.

Sorry, I don't understand.
Title: Re: Bomberman's deplacement style
Post by: TheNess on January 28, 2015, 09:45:51 am
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  :-X. 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?
Title: Re: Bomberman's deplacement style
Post by: cChaD on January 28, 2015, 01:03:58 pm
The movement is not always the same it's because i replace the player.
Title: Re: Bomberman's deplacement style
Post by: TheNess on January 28, 2015, 05:07:15 pm
Quote
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???  :P
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 :)
Title: Re: Bomberman's deplacement style
Post by: Arcade on January 28, 2015, 06:06:48 pm
Quote
if I'm not mistaken in bomberman the movement is aligned, i.e. the player will only stop walking on multiplies of X pixels.

This is likely true. I've only ever played one bomberman game before (Mega Bomberman), but in that game x is several times smaller than the size of the blocks. Meaning the player won't necessarily be perfectly lined up with the blocks (or openings) when releasing the movement button.

Quote
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?

Yeah, if I'm understanding you correctly, that's what I was getting at in my previous post. If a player is trying to move into an opening, but is slightly not lined up with the opening, it will first move the player in the other axis until lined up. As you mentioned, giving the player a "bounding circle" and allowing the circle to slide around the corners of a wall is one solution to that problem.

Anyways, I've realized these aren't really the problems cChaD is experiencing. He is more focused on getting basic collision responses working, so I won't derail this thread any longer :)
Title: Re: Bomberman's deplacement style
Post by: Hapax on January 29, 2015, 01:08:45 am
I think it's possible that we just don't understand what you mean when you say that you replace the player.
Title: Re: Bomberman's deplacement style
Post by: cChaD on January 29, 2015, 12:54:34 pm
I think it's possible that we just don't understand what you mean when you say that you replace the player.

Alright, actually if the player press a RIGHT key, the collisions calcul where the Top Right Corner will be, with the player position more the "actual" movement, also the next movement can be lower and the bomberman will be not stuck on the wall, so i replace him.
Title: Re: Bomberman's deplacement style
Post by: Arcade on January 29, 2015, 06:24:53 pm
I think the language barrier here might be too large for us to really help you. This is my interpretation of your last post:

"If the player presses the Right key, the collision calculation uses the top right corner of where the player will be, which is more than they can actually move because the wall is in the way. Also, the player might press Down at the same time causing the bomberman to now be stuck on the wall...."

That's all I could understand, and I'm not even sure if it's accurate. What do you mean when you say you "replace him"? What you typed doesn't give us enough information to figure out why your bomberman is getting stuck on the wall.

Basically it sounds like you want to handle the case where the user presses Right and Down at the same time. All you need to do is handle those cases separately. Ask yourself "can the player move Right without colliding? if so move Right. Can the player move Down without colliding? if so, move Down."

Have you tried to understand Silderan's post from earlier? Maybe you could start by trying to explain why it doesn't answer your question.
Title: Re: Bomberman's deplacement style
Post by: cChaD on January 30, 2015, 11:01:26 pm
Sorry, i have read back and arcade's post get up the solution, thank you everybody.

++