Author Topic: jump3  (Read 4030 times)

0 Members and 1 Guest are viewing this topic.

aimaina

  • Administrator
  • Cutester
  • *****
  • Posts: 889
  • Cutes: 105
    • View Profile
  • Pronouns: she/her
Re: jump3
« Reply #135 on: February 02, 2018, 11:07:57 PM »
more unity questions..... im thinking of giveing a talk at my local "grames dev club" about movement & collision handling in 2d games (without using built-in physics) but everyone uses unity so i wanna understand the nuancés of unity

the docs seem to say (e.g. here) that when you move a collider, the move doesnt actually happen until the next physics update (FixedUpdate?). so basically if i ran this psuedocode in a FixedUpdate with a 16x16 box collider at (0,0), it would detect the collider:
Code: [Select]
MoveColliderTo(32,32);
if OverlapAreaAll((0,0),(16,16)) {
   Print("detected collider");
}
(also would OverlapAreaAll((0,0),(16,16)) check a 16x16 area or a 17x17 area?)

anyways im wondering how you would do moving platforms with that kind of behaviour..... my barely functional moving platform code definitely relies a lot on the assumption that when you move a platform, its collision box will actually move in the same step, and not one step later..... it seems like it would be really hard to avoid stuff getting stuck

did you have to do anything weird to get the golems and stuff in atgh to work?

vgperson

  • Cuter
  • ***
  • Posts: 172
  • Cutes: 67
  • guess i'll have to... make them fall.
    • View Profile
    • vgperson.com
Re: jump3
« Reply #136 on: February 03, 2018, 03:55:07 AM »
I think there are a few edge cases in ATGH that result from that issue (like in the box push method, I check for "Box or girl fell into path of pushing" after moving the box), but it wasn't a fundamental problem for me. Presumably it would be worse when using Update() instead of FixedUpdate(), since you could have several frames of out-of-date collider positions. I guess that's the sort of thing you could avoid by using pure Rects or something instead of Collider2Ds, but, yeah.

Pretty sure since 0 to 16 is 17 pixels, it's a 17x17 area. Though I think Collider2D bounds may be shifted a pixel right and down or something? Since my code does this: (Note that "rect" is created from collider2D.bounds.min and collider2D.bounds.size)

Code: [Select]
collidersFound = Physics2D.OverlapAreaAll(new Vector2(rect.xMin + 1, rect.yMin + 1), new Vector2(rect.xMax - 1, rect.yMax - 1), layers);
You're misremembering - Golems don't actually move you when you stand on them. I explicitly avoided platforms that moved on their own in ATGH because it would get awkward with the grid-based nature of it. What it does have is carrying Brooke (or bombs) on boxes. In all the cases where boxes move (being pushed, flying through the air, being carried and thus aligning with Asha), the box's old position is saved before it moves. After moving, it checks if Brooke (or a bomb) is above it*, and if so, calls brooke/bomb.getCarriedByBox(xDiff, yDiff). This simply attempts to move them that much one axis at a time, stopping at walls.

* To be specific, bombs are checked for in the push case only (they won't ride on thrown or carried boxes - even getting a bomb on top of a carried box is an edge case I didn't consider until just now I guess), and girls are only checked for in the non-push cases (Brooke can ride on carried and thrown boxes, but boxes are "pushed out from under her"). Just because the different cases are meant to work differently by design.

The way I keep you from pushing Brooke up into ceilings with carried boxes is sort of a cheat that won't work for every game. I basically directly set the position of carried boxes to be above Asha at all times, and then just kept clipping situations from happening at all. If Asha is carrying a box, she simply can't jump unless there's room above the box. And if that carried box is carrying Brooke, Asha can't jump unless Brooke has room to jump. And she can't walk right/left if the carried box has room.

(Yeah, I know you can carry a box and jump up into a falling Golem and it somehow works out okay, but I don't think I coded anything specific to make it work that way... It's a mystery.)

So, to address it more legitimately... If you make getCarriedByBox() return what direction(s) Brooke encountered a wall in, you should be able to use that info to be like "oh, this carrier object is pushing the other object into a wall, let's move it back." Or actually, maybe more useful would be to return a Vector2 telling the carrier how much it needs to "step back," based on the xDiff/yDiff passed to it and the distance the object was actually able to move.
« Last Edit: February 03, 2018, 04:03:31 AM by vgperson »

aimaina

  • Administrator
  • Cutester
  • *****
  • Posts: 889
  • Cutes: 105
    • View Profile
  • Pronouns: she/her
Re: jump3
« Reply #137 on: February 03, 2018, 04:21:37 AM »
oh i know golems dont move you, i was wondering how you handle basic situations like this involving moving solids:
- asha and golem are standing beside each other, with a 2 pixel gap between their colliders
- asha moves 2 pixels right
- golem moves 1 pixel left
- next frame unity updates the collider positions, and they are inside each other now

in gm there wouldnt be a problem because the "golem moves" step would fail, but if im understanding things correctly, it wouldnt fail in unity....

aimaina

  • Administrator
  • Cutester
  • *****
  • Posts: 889
  • Cutes: 105
    • View Profile
  • Pronouns: she/her
Re: jump3
« Reply #138 on: February 03, 2018, 04:35:51 AM »
i guess its more than just golems and other enemys, this kind of thing would arise if (e.g.) in 2 player mode asha is carrying a crate and moving right, and brooke is moving left and jumps into the crate

do you have some code that pushes you out of solid objects if you get stuck in them? that would fix the problem i think, but i normally use a collision system that just tries to avoid getting stuck and does nothing if you get stuck

vgperson

  • Cuter
  • ***
  • Posts: 172
  • Cutes: 67
  • guess i'll have to... make them fall.
    • View Profile
    • vgperson.com
Re: jump3
« Reply #139 on: February 03, 2018, 04:59:59 AM »
Well, the thing is, I never really noticed or was aware of any kind of "update delay," and am not entirely sure when that situation occurs, and suspect it may not at all the way I'm doing things. I said that one case was a result of it, but come to think of it, I think it's just caused by "thing getting in box's path" falling via its FixedUpdate() before the girl's FixedUpdate() runs (in which the box's push() function is called). Meaning the only issue is the standard "which FixedUpdate() runs first" - the colliders will always be properly aligned with the objects when their positions change.

Ultimately, it may be as simple as "if you're only using FixedUpdate to move stuff, you're fine, the colliders will be right." So as usual, Unity's docs just make things more confusing? It could even just mean "if you're using physics to move your objects (that is, setting their velocity instead of directly changing positions), they won't move until physics happen," which is like... obvious.

aimaina

  • Administrator
  • Cutester
  • *****
  • Posts: 889
  • Cutes: 105
    • View Profile
  • Pronouns: she/her
Re: jump3
« Reply #140 on: February 03, 2018, 05:15:22 AM »
ok thats good to know :honeydew: if i go through with giving a talk about this stuff ill probably have to actually test out my codez in unity first....

i noticed that the Collider2D.IsTouching docs have the warning about colliders still being registered as "touching" if you move one out of the way, but the Collider2D.OverlapCollider docs (and the docs for all the Physics2D overlap methods) dont mention that issue..... i thought it was just the docs not accounting for every edge case of every function, but maybe checking if colliders "overlap" is actually different from checking if they are "touching" for some reason....

SquareWheel

  • Administrator
  • Cutest
  • *****
  • Posts: 462
  • Cutes: 67
    • View Profile
Re: jump3
« Reply #141 on: February 03, 2018, 06:33:47 AM »
Good luck if you give the talk.

aimaina

  • Administrator
  • Cutester
  • *****
  • Posts: 889
  • Cutes: 105
    • View Profile
  • Pronouns: she/her
Re: jump3
« Reply #142 on: February 03, 2018, 07:19:09 AM »
thanx :honeydew:

i have another question for vg..... do you use "static colliders" or "kinematic rigidbody colliders" for your moveable hitboxes? the docs (https://docs.unity3d.com/Manual/CollidersOverview.html) say that repositioning static colliders is very inefficient & can cause glitches, so kinematic rigidbody colliders sound like they would be better, but i dont think you ever mentioned using rigidbody stuff in your games....

vgperson

  • Cuter
  • ***
  • Posts: 172
  • Cutes: 67
  • guess i'll have to... make them fall.
    • View Profile
    • vgperson.com
Re: jump3
« Reply #143 on: February 03, 2018, 07:48:46 AM »
Yeah, no Rigidbody. I feel like I had that at first, but it just resulted in "automatic" physics that I didn't want. But it does sound like even if you're just using it for colliders, it regenerates the collision map every time you move a "static" collider, and that can add up... So maybe we should both look into that.

aimaina

  • Administrator
  • Cutester
  • *****
  • Posts: 889
  • Cutes: 105
    • View Profile
  • Pronouns: she/her
Re: jump3
« Reply #144 on: February 03, 2018, 08:36:23 AM »
this platformer controller someone made (https://github.com/prime31/CharacterController2D) has a kinematic rigidbody on the character which does not seem to actually be used in the code anywhere, so maybe it really is faster to just have a useless rigidbody on your objects with moving colliders.....

i tried to generate hundreds of player objects to test the speed difference between no rigidbody/kinematic rigidbody but it just made unity crash

hubol

  • Cutester
  • *****
  • Posts: 842
  • Cutes: 133
    • View Profile
    • hubolhubolhubol
  • Pronouns: he/him
Re: jump3
« Reply #145 on: February 03, 2018, 12:42:17 PM »
unity good me bad

aimaina

  • Administrator
  • Cutester
  • *****
  • Posts: 889
  • Cutes: 105
    • View Profile
  • Pronouns: she/her
Re: jump3
« Reply #146 on: February 06, 2018, 11:39:21 PM »
love-game.net/fluffbattle

this runs slow in chrome but fast in firefox for me? can anyone else test it?

juner

  • Cutey
  • **
  • Posts: 93
  • Cutes: 49
    • View Profile
Re: jump3
« Reply #147 on: February 07, 2018, 12:12:54 AM »
same here, fast in firefox and slow in chrome...

juner

  • Cutey
  • **
  • Posts: 93
  • Cutes: 49
    • View Profile
Re: jump3
« Reply #148 on: February 07, 2018, 12:16:15 AM »
had a weird thing when trying to rebind controls the other day in the previous version, trying to rebind "move left" to the left arrow but that kept undoing one step of assignment instead. i guess cause the left arrow was assigned to reset or something?

but it looks like you've changed the button assignment stuff for multiplayer anyway so this might not even be an issue any more  :orange:

aimaina

  • Administrator
  • Cutester
  • *****
  • Posts: 889
  • Cutes: 105
    • View Profile
  • Pronouns: she/her
Re: jump3
« Reply #149 on: February 07, 2018, 03:51:24 AM »
oh apparently i fucked up and option/button config files from different games on my site can overwrite each other..... turns out im supposed to generate a unique "Game Identifier" for each game to prevent this.... normally this is done automatically on project creation but for electrocat/fluff battle (and maybe other games?) i started with some base code instead of creating a new project, so they have the same id..... lol