Specific question regarding a fighting game camera

Okay, I will try to lay out what my exact question is as clearly as I can:

I am making a fighting game.
I have made the camera so that it centers on the two players, and so that each player cannot leave the screen (In the Boundary View 0 Event, I put "x = xprevious").
This works as intended.
I have one problem, though.
Every time a player performs an action of any kind, the shape and size of their hitbox changes.
When a player is standing near the left or right edge of the screen, and they perform an action that results in their hitbox(es) becoming BIGGER than they were previously, they get stuck and cannot move.
This is because their hitbox(es) is/are now intersecting the edge of the view/screen.

What I need to know is:

How can I make it so that, in the Create event, if the player object's hitbox(es) is/are intersecting the edge of the view/screen, they are moved TOWARDS THE CENTER OF THE SCREEN until they are no longer intersecting the edge, so that they can move and don't get stuck because they are intersecting with the edge of the view/screen?
So, if the player is on the right edge of the screen, they need to move to the left until they are no longer colliding with the edge, and vice versa.

How would I go about doing this? Please explain very clearly, as I am not an expert.

Thank you for your help. I hope I explained what I'm trying to do clearly enough.
 

woods

Member
here is what looks to be a vague point in the right direction...
Intersect Boundary: The Event is triggered when the Instance touches the inside edge of the Room.


Views
Camera views are normally defined in the room editor and used to show only a small area of a large room at any one time. This event category has two seperate sub-categories (Outside View and Intersect Boundary), with eight different events in each corresponding to the eight available view ports. These two categories function exactly the same as the respective room events, only taking the boundary of the camera view as the thing for the instance to check against rather than the room.


another thing to check out...
camera_get_view_width
 
Well, for me, hit/hurt boxes are completely separate entities than the actual player. The camera shouldn't even know, let alone care about, if they spawn or where they are.
That said, if you are talking about the actual player's bounding box getting outside the room and getting stuck, I think the simplest way to do this without breaking your whole architecture would simply be to clamp the player's position in the room, by not letting him go all the way to the edge. You could clamp the player's x position, for example, from x=32 to x=room_width - 32, or something like that, which would prevent going out of bounds 100% (actual value will depend of your sprite size, but you get the idea)
 

Nidoking

Member
in the Create event
Do the actions you're performing cause instances to be created? If not, then the Create event is not the correct place for the checks you're describing. You need it to happen every step, after changing the hitbox but before using the character's position to do any kind of calculations.
 
Well, for me, hit/hurt boxes are completely separate entities than the actual player. The camera shouldn't even know, let alone care about, if they spawn or where they are.
That said, if you are talking about the actual player's bounding box getting outside the room and getting stuck, I think the simplest way to do this without breaking your whole architecture would simply be to clamp the player's position in the room, by not letting him go all the way to the edge. You could clamp the player's x position, for example, from x=32 to x=room_width - 32, or something like that, which would prevent going out of bounds 100% (actual value will depend of your sprite size, but you get the idea)
This is the one that ended up working for me. I ended up putting this in the create event and again in the step event of each player object (in my game, the player instance_changes to a different object for every action or state they can potentially be in. I find that this helps me for organization purposes, so the code doesn't get unreadably long):

x = clamp(x, view_xview[0] + (sprite_width / 2) , (view_xview[0] + view_wview[0]) - (sprite_width / 2) );

So, that code does it. I makes it so that the player sprite can never be off-screen.

I may or may not change it to detect for hurtboxes rather than the player sprite. Do you think that I should?

Thank you so, so much for your help. I am immensely grateful. I would not have thought to tackle the problem that way.
 
I may or may not change it to detect for hurtboxes rather than the player sprite. Do you think that I should?
Well, make sure it does not bug, but hitboxes crossing boundaries is not really important to prevent. If someone's there kicking the wall, he's going to look like a n00b anyway šŸ˜‚
But also to take in consideration is a move that warp to the other side of the screen (Scorpion in MK, I think?). Allowing the player to block it from the other side (a little outside the view), could be a good thing, actually (if you plan on having moves like that).
Important thing is really that the player itself is in bound.
 
Top