Bottle throwable item
zicklag opened this issue · comments
WIP Spec ( Needs Review )
The bottle item should:
- Be spawned on the map, laying on the floor in places determined by the level info.
- Be able to be grabbed by a fish
- Be able to be thrown after being grabbed
- Should break after thrown
This would also change the player moves:
- Player can no longer throw an unlimited amount of bottles
- Player has a move that is pick up and throw using the same button
@erlend-sh @odecay I wrote a work-in-progress spec for the bottle item. I had to make some guesses as to how we wanted to handle it. Does that look right to you?
Also, when you throw the item, does it shoot straight forward, or thown in an arch? I feel like the bottle should throw in an arch.
Sounds right 👍
Throws should be slightly arched, yep.
Point 4 (Should break after thrown) may not be trivial.
With the current design, within one frame/stage, systems are not aware of each other. In short, the shoot system can't know that the throw system executed, so if a user taps both shoot and throw keys in a single frame, a bottle will be thrown and shot.
If it's not possible to trigger two action keys at the same time, then both systems will not run in the same frame, but this leaves an very bug-prone logic.
This problem will be solved once there is a single entry point for testing the keypresses and deciding which action to take, rather than having systems individually testing the keypress.
Player has a move that is pick up and throw using the same button
Since shoot works on bottle as well, I've made the PR use also the shoot button to pick up items. This can be trivially changed, though.
With the current design, within one frame/stage, systems are not aware of each other. In short, the shoot system can't know that the throw system executed, so if a user taps both shoot and throw keys in a single frame, a bottle will be thrown and shot.
I think ultimately we should not allow bottles to be "shot", that sort of projectile attack will be reserved for bows or guns or other such projectile weapons. All weapons should additionally be able to be thrown, melee weapons included. (this will solve above issue but also may introduce a new case of "what happens when we want to throw a gun".
Player has a move that is pick up and throw using the same button
Since shoot works on bottle as well, I've made the PR use also the shoot button to pick up items. This can be trivially changed, though.
This has some implications for the inputs we use, I feel like it makes sense for melee weapons to default to picking them up either with a dedicated pickup button or with the attack button, but I think it could cause issues when "mashing" that button if it also causes a throw to happen as soon as the item is picked up, which may only be desired behavior for dedicated throwing weapons (even then unsure if this is beneficial). I advocate for pickup and attack to be on the same button, and throw to be on a 2nd button.
I will be working on an #148 soon, which could also make the "mashing pickup" if its also throw case less problematic.
Point 4 (Should break after thrown) may not be trivial.
It depends what is meant by "break" but already projectiles despawn after hitting something, so at a base level this already works. An animation could be added as improvement but that can be left till future.
As an aside, not ALL weapons should break upon being thrown. A bottle most certainly should but imagine something such as a bat or a sword, I would prefer these to fall to the ground on collision with the ability to pick them up again. I will be working on specing some of this out in #149 and sub issues.
I advocate for pickup and attack to be on the same button, and throw to be on a 2nd button.
I’d prefer attack and pickup to be two separate buttons, so items can’t be accidentally picked up mid-attack. This would also match our Jumpy convention.
Your input buffer would indeed mitigate unintentional throwing, but it’s also worth mentioning that unintentional throws are really fun.
I’d prefer attack and pickup to be two separate buttons, so items can’t be accidentally picked up mid-attack. This would also match our Jumpy convention.
I don't think there should be an issue with picking up items mid attack. The player will be locked into State::Attacking while they are already attacking and can be made to only be able to pick up items from State::Idle or State::Running. I could see what you mean if there were an attack like the current flop which moves the player forward directly onto an item at which point they continued mashing attack, causing them to pick up the item, but again this could be fun 😉 .
I think my preferred solution may be to have pickup action be a combination of the attack and down directional input together which would prevent accidental inputs like that and also conceptually mapping pretty well to a "bend down and interact" action that is picking something up. Of course a similar reasoning could be applied in the opposite direction, making throw triggered by the Pickup button combined with forward directional input.
My main goal for these suggestions is to avoid accidental inputs throwing your weapon away, I feel like that should be an intentional choice on the players part, whereas if you accidentally pick up a weapon when you intended to attack, you have the option of throwing/dropping it immediately with much less consequence. Considering throwing something immediately accidentally may not give you the chance to use it (think of the milk bottles in Little Fighter 2 for example, a breakable consumable healing item, which also doubles as a projectile).
There are probably a few strategies for reaching a good conclusion and we can always test and make changes if things don't feel right at first.
making throw triggered by the Pickup button combined with forward directional input.
☝️ that’s my preference. Can we try that first? Pretty sure that’s how LF2 works too, but I could be wrong.
That would follow the Jumpy (and Duck Game) convention. Keep in mind that we’re making a mini-arcade of multiple interrelated games that players will play in rapid succession. We wanna make the leaps between controller schemes as small as possible. There will of course be deviations, but a standard separation between ‘pickup/toss’ and ‘shoot/interact’ feels correct to me.
My main goal for these suggestions is to avoid [1] accidental inputs throwing your weapon away, I feel like that should be an intentional choice on the players part, whereas if you [2] accidentally pick up a weapon when you intended to attack, you have the option of throwing/dropping it immediately with much less consequence.
There’s another big difference between these two types of accidents though:
(1) This is a very unlikely accident when there’s a dedicated pickup button that you’ll only be using for the specific action of picking up an item.
(2) This is a highly likely accident, and it’s also a more jarring one because the player might accidentally pick up a weapon and start using it without even knowing what button-press made that happen.
p.s. I’m only thinking about the gamepad ABXY scheme here. A keyboard can support any number of schemes anyhow, so you can experiment to your heart’s content there 💟
I've set the pickup input to be the throw button, as per original specification.
Since this discussion got larger than initially planned, we could make a separate issue, so that this PR can go out. Changing the input is straightforward anyway, so applying the change in a separate PR has virtually zero overhead compared to doing it in this one.