How to emulate larger "hit box" for bigger sprites?

[cuby]

This is something I've been trying to figure out with no luck, but I know folk here will have thought of a solution for this already!

I have a part of my project where the player is suddenly quite big -- the best analogy I can come up with is a top-down 2D shoot-em-up, but the player's spaceship is quite big.

No problem with the big sprite, the sprite sheet gets divided up properly, but as you know the game only recognizes the one 48x48 square as the "hit box".

The problem here is, I need the spaceship to have a larger actual "hit box" so that if the sprite collides with something, the game will recognize the collision at the edges, and not just at the core little 48x48 box.

In previously working with large sprites, I just used blank dummy events around the core event to mimic the space the sprite would take up, and that works fine, but not for an actor actually being controlled by the player.

Hope that's a clear enough description of the problem, and hoping someone has some thoughts! It's an interesting problem.

Thanks

 

[ShadowDragon]

best workaround (if you use event hitbox) region, is to set a switch ON
so the event or region is been blocked by player to walk on.

I dont know if there is a cleaner way to do this though.
if you use pixel movement, than you need to make something as an addon
to dynamically change the collision to be bigger, but I dont know otherwise.

 

[Andar]

No, the biggest problem here is that there is no hitbox at all.

by default collision is tested by grid coordinates, NOT by pixel box. You collide if your position coordinates get into the same coordinates as another event.

as such, you cannot increase the size of something that does not exist.
you either have to implement pixel collision with a plugin (and that is not easy, many have failed - most limit themselves to pixel movement with grid collision).
or you have to check for multiple grid coordinates to collide

 

[Bex]

Just some quick thoughts and Brain storming, i hope you dont mind:

I would suggest using the Event Screen X and Event Screen Y Coordinates, they are better for fluent and responsive hit detection.

Screen X and Y is normaly the Center Point of the Eventbox. To get a good 1 Tile collision a Radius or Range of 20 or less would fit.

It is also possible to create a hit rectangle for the Event and if needed also for the Bullet.
But i dont have a example for that and i dont know how to explain a glimpse of it in English.
i hope this suggestion still points into a possible direction. The earlier Linked Thread is realy helpful,
it is with map cooridnates, perfect to learn the basics, but screen coordinates are the real deal for hit detection with moving targets.

Here is a Pixel example without hitbox:

Var1 = Event Screen X - Bullet Screen X
if Var 1 is less than 0 do Var1 *-1

Var2 = Event Screen Y - Bullet Screen Y
if Var 2 is less than 0 do Var2 *-1

Var1 + Var2
If Var 1 is equal or less than 20 do Textbox you are Hit the Bullet Center Pixel is less than 20 Pixels away of the Event Center Pixel which means both Events are on the Same Maptile.

A Bullet with Center Pixel and a Event with Hit Box could look like this:

Var1 = Event Screen X - Bullet Screen X

Var2 = Event Screen Y - Bullet Screen Y

If Var1 is equal or less than 68
if yes: if Var1 is equal or more than -68
if yes do: If Var2 is equal to or less than 20
if yes do: If Var2 is equal to or more than 116 (A little less than the height of your Sprite -20)
if all 4 nested conditions are true, than the bullet hit the hit rectangle of this event.

i hope this basic example helps to get started.

 

[cuby]

Thanks all.

I have considered using checks for X and Y coordinates, but the math on this gets complicated since the shape of the player actor is not a clean rectangle. Not impossible but it becomes unwieldy.

@Andar I do understand the lack of a hitbox, and I am not using any pixel movement (thank goodness). But I am wondering if there is any way to approximate the permanent presence of event boxes that surround the player and move in concert as the player moves.

If you were to think of a giant spider, with extending legs, that's kind of what I'm going for. Those legs should block movement if the player runs into a wall.

Tricky, right? I haven't found a plugin that can manage this, and I'm wondering if I'm genuinely butting up against the limits of RPGM. Sure would love to figure it out though, even if it comes down to calculations of X Y coords.

 

[Bex]

I Edited my Post and added a Hitrectangle example.

Edit: The Hit rectangle should be a bit smaler than the sprite itself.
The rectangle does not need to be a square, a rectangle will work.

 

[cuby]

Just some quick thoughts and Brain storming, i hope you dont mind:

I would suggest using the Event Screen X and Event Screen Y Coordinates, they are better for fluent and responsive hit detection.

Screen X and Y is normaly the Center Point of the Eventbox. To get a good 1 Tile collision a Radius or Range of 20 or less would fit.

It is also possible to create a hit rectangle for the Event and if needed also for the Bullet.
But i dont have a example for that and i dont know how to explain a glimpse of it in English.
i hope this suggestion still points into a possible direction. The earlier Linked Thread is realy helpful,
it is with map cooridnates, perfect to learn the basics, but screen coordinates are the real deal for hit detection with moving targets.

Here is a Pixel example without hitbox:

Var1 = Event Screen X - Bullet Screen X
if Var 1 is less than 0 do Var1 *-1

Var2 = Event Screen Y - Bullet Screen Y
if Var 2 is less than 0 do Var2 *-1

Var1 + Var2
If Var 1 is equal or less than 20 do Textbox you are Hit the Bullet Center Pixel is less than 20 Pixels away of the Event Center Pixel which means both Events are on the Same Maptile.

A Bullet with Center Pixel and a Event with Hit Box could look like this:

Var1 = Event Screen X - Bullet Screen X

Var2 = Event Screen Y - Bullet Screen Y

If Var1 is equal or less than 68
if yes: if Var1 is equal or more than -68
if yes do: If Var2 is equal to or less than 20
if yes do: If Var2 is equal to or more than 116 (A little less than the height of your Sprite -20)
if all 4 nested conditions are true, than the bullet hit the hit rectangle of this event.

i hope this basic example helps to get started.

This does provide a blueprint of how to work it out, in a brute force style. If all else fails I will use this kind of a solution, though the issue I think is that it would constrain my ability to create an interesting shaped sprite, and even so this would create memory overhead for sure.

As with any problem though, always hoping someone out there has devised a miraculously simple solution to the exact problem that bedevils me

 

[ATT_Turan]

Have you looked at this?

Neon Black's Large Sprite Fix

Neon Black's Large Sprite Fix 2015.08.11 by Neon Black Introduction This is Neon Black's Large Sprite Fix ported from Ace. The MV script was written by Neon Black - I just made a fix to it while he was unavailable. How to use Please read plugin instructions. Script MUST be saved...

forums.rpgmakerweb.com

 

[Bex]

I can ease your worries about the performance, here is a Hit detection used in Event command Script.
It checks if Event1 is on the same Maptile as one of the Event Ids from 2 to 100. You could even change it to 2 to 999.
If yes, the self SwitchA of that Event will get Activated.
But with Screencoordinates to have a fluent and good detection.
This is without Hit rectangle, but iam sure that could be added. Caethyril and others helped alot with this, also the Script Call List.

var hitDist = 0
for ( a = 2; a < 100; a++) {
if (!!$gameMap.event(a)) {   // check that event exists
hitDist = $gameMap.event(a).screenX() - $gameMap.event(1).screenX().abs +
          $gameMap.event(a).screenY() - $gameMap.event(1).screenY().abs;
if (hitDist <= 20) {  // in range?
        $gameSelfSwitches.setValue([$gameMap.mapId(), a, 'A'], true);
 }}}

Edit: I would also suggest for Hit detection, first check a Rectangle or Range, if Event is in that Rectangle only than process even more specific hit detection and math. That could safe performance, depending on how complex the shape of your sprite will be in the end. Iam a casual user myself, so iam sorry if i wrote something wrong, iam also not high skilled with english.

 

[caethyril]

All collisions boil down to coordinate checks, typically simple geometric shapes like circles (distance) or rectangles. Like Andar said, RM simplifies this to tile coordinates: if you move into an occupied tile, that's a collision. For more complicated shapes, you'd just have multiple components. E.g. for a 3x3 tile size player, do 3 collision checks: 1 per front-facing tile.

I think doing this with events would require you to manually handle player movement, e.g. with an Autorun event or a scripted player move route? Or a Parallel event that manually triggers things on a timer, seems a bit hacky but it might work.

For a plugin approach, I'd consider specifying a number of events as "attached" to the player, with their relative tile coordinates. Then for all movement checks involving the player, e.g. passability, check each attached event as well as the player.

As usual, the most complicated part of this is design: identifying all relevant features to extend. Some things to consider for a plugin request:

Spoiler: big list

1. Attaching events:
   • Could have the same map events, e.g. 1, 2, 3, 4, 5, attached permanently.
   • Alternatively could allow adding/removing attached events mid-playthrough
     • If so, how would you want to do that? E.g. event notetag? Script call?
2. Movement:
   • Move attached events with player, and
   • Block player movement if any attached event can't move in that direction, right?
3. Events:
   • Which triggers should process for attached events?
     • Triggers: Action Button (including over a counter), Player Touch, Event Touch.
     • Should the triggered event's priority make a difference?
   • How are player-targetted effects handled? E.g. play animation on player only? Tint player and all attached events?
4. Vehicle triggers:
   • Can the player enter a vehicle through an attached event?
   • What happens to attached events while in a vehicle?

There may be other stuff. I imagine there's a plugin for it somewhere, but I don't know of one off-hand. As you can probably see, it's generally more challenging to do this for the player than for map events.

 

[cuby]

Thanks all. I'm going to basically go down the line and try a few different approaches -- please keep thread open, I'll check back to mark as closed once I figure out a solution or give up