Refactor fighters spawning

[64kramsystem]

Extract spawning types and logic from main into player.rs and enemy.rs, and extended the respective bundles to make all the components explicit.

Right now, main.rs still has a mix of different things (e.g. player belly flop attack), so other things should be moved out.

There are still some

[64kramsystem]

Should the belly flop system go into attack.rs (hypothetically, and in a separate PR)? I think so, although the semantics of attack are a bit fuzzy (probably, other systems will be added in the future, so I think that the belly flop system should go there).

[odecay]

Should the belly flop system go into attack.rs (hypothetically, and in a separate PR)? I think so, although the semantics of attack are a bit fuzzy (probably, other systems will be added in the future, so I think that the belly flop system should go there).

I like this, I was starting to do something like this myself while I was considering #63. I think the attack portion and movement portion of the flop can be different systems, triggering by input should happen in attack. I'll try to make a pr soon and ask what you think.

[64kramsystem]

I like this, I was starting to do something like this myself while I was considering #63. I think the attack portion and movement portion of the flop can be different systems, triggering by input should happen in attack. I'll try to make a pr soon and ask what you think.

Splitting them is a good idea - actually, I think it will be necessary, if we unify the player translations as described in my recent issue.

The final shape of the split depends on if/how we decide to merge the translations. If yes, I think we should also start to think in stages.

My rough idea of splitting is:

• stage N: input is read, and it's translated to an intention-to-move message, with the current location and the motion vector
• stage N+1: move is examined, optionally processed, and optinally applied
  • for example, if the player belly flops from the edge of the screen towards outside, the processing should remove the x component of the motion vector, but leave the y one
• stage N+2: attack collisions are tested

That's my proposal 😄

[odecay]

Yea I thinkkkk that makes sense. We will have to account for collisions from attacks in our motion vector application as well. I keep meaning to reply to this but forgetting where it was. Would you transfer above proposal to its own issue @64kramsystem?

edit: I found the "reference comment in issue" feature which keeps like to your original comment. Issue here #99.