Add MVP boss fighter

[zicklag]

MVP Boss fighter should be essentially like any other fighter we currently have with the following changes:

• He should be bigger
• He should move slower
• He should have more health
• He should do a jumping-in-place smash attack instead of a punch

[edgarssilva]

How should I go about defining different attack types? Should each fighter have its attack type or maybe just a wholly different attack logic in the case of bosses. If so, how should this be set in the yaml assets?

[64kramsystem]

How should I go about defining different attack types? Should each fighter have its attack type or maybe just a wholly different attack logic in the case of bosses.
If so, how should this be set in the yaml assets?

Interesting question, in particular because scripting is in development, which I think it will affect the overall design of the behavior.

Considering that:

• attacks are currently not configured in YAML, and it's a nontrivial work, I'd split that type of work, and do it separately
• this is the MVP
• I reckon that doing the attack logic customizable separetely and after, is not going to have considerable overhead instead of the reverse
• writing the customization on 0.0.4 will give more time to think about scripting

I'd just define separate logic (systems) for the boss, and in the next milestone, make the attack behaviors customizable (YAML and stuff).

@odecay @zicklag what do you think?

[zicklag]

Yeah, for now since it's MVP and attacks will probably be defined in scripts if we can get that working, I'd say just make the boss essentially the same as the other fighters at this point as far as the YAML definition goes. Any extra logic for attacks should just be defined in plain Rust and we can try to migrate later once we have a better idea of what scripts will be able to do.

[odecay]

@edgarssilva For the boss attack you can define it similarly to how the player_flop attack works, with the movement and attack in the same system, but have it triggered by the AI targeting through parsing EventReader<ArrivedEvent> instead of inputs, like in enemy_attack.

[odecay]

Re: discussion in discord it seems this may be blocked on sprite assets for the big boss being finished, is that accurate? Do we want to push this off to v0.0.4 @erlend-sh @edgarssilva?

[edgarssilva]

Since @erlend-sh said in discord that looks fine, as he mentioned, it will spread out the visual updates.

[odecay]

Ok moving to v0.0.4

[64kramsystem]

@edgarssilva are you still working on this? if you have some code sketched, I'll check it out, and try to complete other boss-related tasks in parallel, in a way that it's compatible with your code.

[edgarssilva]

Yeah just waiting for the sprites, the jump is a bit junky. But didn't worried much sense it would be refractored later.
Right now I've been working on my fork, should I make a PR, maybe create a branch in the project for it. Not sure what's best wdyt?

[zicklag]

A PR from your fork probably make sense. For the most part we haven't been opening branches in the project which IMO feels best so far.

That should still allow @64kramsystem to push to your branch if you guys want to work like that on it because of the "allow edits from maintainers" feature in GitHub on pull requests.

Not to answer for @64kramsystem on what he wants to do of course! :)

[64kramsystem]

A PR from your fork probably make sense. For the most part we haven't been opening branches in the project which IMO feels best so far.

That should still allow @64kramsystem to push to your branch if you guys want to work like that on it because of the "allow edits from maintainers" feature in GitHub on pull requests.

Not to answer for @64kramsystem on what he wants to do of course! :)

I'll work in a parallel branch, as I'll work on different tasks (otherwise, I'd step onto @edgarssilva's work). Having a PR is actually convenient, so that if he pushes a new version, I'll be notified, and can rebase.

[zicklag]

With #222 I think this could be done, but there's one more thing we might need to fix:

You're able to stand on the boss. 🙃

Also his sound effect for attacking isn't playing. That should be an easy fix, though.

[edgarssilva]

With #222 I think this could be done, but there's one more thing we might need to fix:

You're able to stand on the boss. 🙃

Also his sound effect for attacking isn't playing. That should be an easy fix, though.

Also I think the attack hitbox is not right

[zicklag]

We might be able to tweak the attack hitbox easier once #221 gets in, so we should probably rebase + merge that and then do the remaining tweaks for the boss.

[odecay]

We probably need to load character Hurtboxes from YAML as well, they all use the same sized one currently.
We should also probably determine the z of sprites from the bottom pixels rather than the center I would imagine?

[zicklag]

We should also probably determine the z of sprites from the bottom pixels rather than the center I would imagine?

Yeah, that should fix the fact that we can walk on the boss.

More than just determining the Z from the bottom, though, maybe we need to determine the player position from the bottom, too. Because right now the boss attacks with his middle, and that's also how he targets players, so he is essentially trying to cover the player instead of walk up to them.

Maybe we need to spawn the sprite bundle as a child of the figher with an offset? I'm not sure if Bevy sprites have a built-in offset option.

[odecay]

Agree, I was going to say we can also offset hitboxes/hurtboxes which is already in place for attacks, but the targeting point is relevant.
Sprites have an anchor we could use, but we could also offset transform. Unsure which is better.
https://docs.rs/bevy/latest/bevy/sprite/enum.Anchor.html

[zicklag]

I feel like Anchor would work perfect.

[edgarssilva]

Just added the Anchor but now I got some empty space from the sprites so we probably would need to obtain real size values from the assets.

[zicklag]

Oh, good point, maybe we do need to do manual offsets.

[edgarssilva]

I'm thinking of offsetting the z in the y_sort by half of the sprite height, and probably introducing some Size component or just adding it in the fighter meta.

Edit: Just noticed that all colliders sizes are from a constant :/

[odecay]

I'm thinking of offsetting the z in the y_sort by half of the sprite height, and probably introducing some Size component or just adding it in the fighter meta.

Edit: Just noticed that all colliders sizes are from a constant :/

Yep, characters colliders should be moved to loading/defined in YAML but havent yet, thats the Hurtbox I mentioned above.

[edgarssilva]

Btw found a bug with the hitbox offset where the Y is also reflected based on the facing.

I fixed it in this, also should I add the hurtbox in here or leave it for another PR?

[odecay]

Btw found a bug with the hitbox offset where the Y is also reflected based on the facing.

What was causing it?

I fixed it in this, also should I add the hurtbox in here or leave it for another PR?

Up to you, but it should include hurbox offsets for all fighters not just the boss.

[edgarssilva]

What was causing it?

The entire vector was multiplied by -1 instead of just the x.

[edgarssilva]

Up to you, but it should include hurbox offsets for all fighters not just the boss.

I'm thinking of adding a ColliderMeta that can also be reused for the attacks and other cases.

Right now I will just assume it's a cube but maybe we can add support for different shapes.

[odecay]

What was causing it?

The entire vector was multiplied by -1 instead of just the x.

oops lol

[odecay]

I'm thinking of adding a ColliderMeta that can also be reused for the attacks and other cases.

Right now I will just assume it's a cube but maybe we can add support for different shapes.

Unsure if it would be useful. Its extremely common in most 2d/2.5d fighting games/beatemups to use boxes only, although I do think eventaully we will want to be able to define multiple different boxes for a single attack.

[odecay]

I'm thinking of adding a ColliderMeta that can also be reused for the attacks and other cases.

Right now I will just assume it's a cube but maybe we can add support for different shapes.

Unsure if it would be useful. Its extremely common in most 2d/2.5d fighting games/beatemups to use boxes only, although I do think eventaully we will want to be able to define multiple different boxes for a single attack.

for stuff like this
[removed by @zicklag ( the artwork a character was suggestive )]

[edgarssilva]

for stuff like this

Haha that looks cool like that.

[edgarssilva]

Just submitted #229 to fix the sorting problem and allow to customize the colliders.

[zicklag]

I edited out the image above because one of the character's artwork was not dressed properly. I'm really strict about that kind of of stuff, so it's important for my participation to keep communication channels clear of anything in that direction.

[odecay]

hows this

[zicklag]

That's good, thanks. 👍

[odecay]

I noticed that the boss often walks offscreen, any ideas why? I cant remember if we moved fighter positions to be determined at the bottom of sprite or not.

[zicklag]

@edgarssilva did you change fighter positions to be based at the bottom of the sprite?

I know we did something to fix the y-sorting and walking on top of the fighter, but I don't remember if we ended up changing the sprite anchor or not.

[edgarssilva]

@edgarssilva did you change fighter positions to be based at the bottom of the sprite?

I know we did something to fix the y-sorting and walking on top of the fighter, but I don't remember if we ended up changing the sprite anchor or not.

We ended up just taking the sprite height in account while doing the y-sort. Basically sorting on the y based on their feet position.

[odecay]

Ah, I feel like we should be positioning the fighter relative to the bottom of the sprite as well right? That means we are currently positioning based on the center of the sprite which is default bevy, so the boss who is huge can get a big chunk of his body offscreen when moving around. Unsure, but I guess this could cause problems with with how collision boxes are placed currently.

Other option might be like setting up some kind of offset based on character sprite size for targeting? Seems less ideal 🤷

Any other ideas?

edit: I guess this is almost verging back into the 2d/2.5d/3d discussion again, I guess what is the best solution for now without making a decision on that?

[zicklag]

Yeah, I'm feeling like setting the sprite anchor so that they are rendered above position is the cleanest solution for now.

Logically they position themselves with their feet, so I think it makes sense and is easy to do.

[odecay]

Just checked and it looks like using the bottom center anchor means we will have to offset all the collision boxes as well.

edit: well technically it just works but the hitboxes are all just where they were before, which makes it really janky looking if you actually look at them/maybe will result in problems later. 😢

[odecay]

It also causes weirdness with the item pickups it seems.

[zicklag]

It seems like it could be simple to translate the colliders up by half the fighter height, right?

[odecay]

I think we would have to move hurtboxes to a child entity so they can have their own transform. Could already do that with attack hitboxes since they are already a child entity.

[edgarssilva]

I think we would have to move hurtboxes to a child entity so they can have their own transform. Could already do that with attack hitboxes since they are already a child entity.

Yeah, that is why I chose not to move the anchor since it would influence all the collisions.

[odecay]

Threw a PR up #241 would appreciate eyes

[odecay]

I think this is complete for now, #242 also came up during boss implementation but its not strictly related to the boss so leaving it for the future.