For game music we've already got a completed OST that can be reused as-is for this game:
https://spicylobster.itch.io/fish-world-pack

We'll probably follow up with a beatemup-tailored remix of this album way later.

For SFX, anything creative-commons is on the table for the purpose of temporary use. A quick search for 'punch' resulted in these two which I quite like:
https://opengameart.org/content/punch-slap-n-kick
https://opengameart.org/content/37-hitspunches

Also:
https://www.kenney.nl/assets/interface-sounds
https://www.kenney.nl/assets/ui-audio

If a camera panning key combination (e.g. Ctrl+Up) includes a key from player move (e.g. Up), both actions will be performed.

Description

Lots of higher level coders won’t be interested in modding unless we support a higher level scripting language, like Lua.

Scripts don’t even need to be able to run in production (although we will eventually figure that out); their primary function is iterative prototyping. A rust implementation might still be required for anything running in production.

Alternatives & Prior Art

• fishfolk/jumpy#394
• https://github.com/makspll/bevy_mod_scripting

hey all! The creator of bevy_mod_scripting here. Very happy to see interest in my baby 😂 The current state of the crate is fairly good, tealr support is already there with on the fly compiling to lua and hot-reloading + documentation generation. The biggest piece of functionality missing is currently the bevy API (i.e. get_component Vec2/Vec3 etc etc), and I am currently working on it full-time, I think bevy 0.8 (mid july) is a fairly realistic deadline for that feature and I'd recommend waiting for then to start using the package unless you do not need this and are rather looking for simple scripts which do not directly interact with the bevy World. Let me know if you have any questions, happy to help!

While still being a very limited language, Mun would also be super exciting to start playing with:

• mun-lang/mun#416

Tasks

• #140
• #253

Players should have a component such as PlayerIndex(usize) on them that just sets which player they are.

This can be used where the player order is important, for example, in the HUD display, which happens to change the ordering when a fish get's punched sometimes, just due to the unstable iteration order over player entities.

Tasks

• #108
• #97
• #269
• Implement boss headbash
• Update AI to use multiple attacks

for one frame or so, the enemy is shown standing before dying.

As a follow up to #23 we want to allow specifying engine configuration in the query string. Configurable options should include:

• Asset URL: Allows people playing alternative games with the same web build
• Log level

Schedule graph seems to have broken recently.
Not quite sure what caused it, seems like its not finding a requirement https://github.com/jakobhellermann/bevy_mod_debugdump/blob/c055c00cc7417859aa38c630d9b39077bb339437/src/schedule_graph.rs#L430 for printing here. Other clue is the StateTransitionStageLabel which comes from Loopless.
I don't really understand what missing downcast means in this context or what could be causing it. Is there a missing downcast impl on something in loopless?

Missing downcast: StateTransitionStageLabel(TypeId { t: 12401367547488415915 }, "littlefighter2::GameState")
thread 'main' panicked at 'assertion failed: found', /home/xxxx/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_mod_debugdump-0.4.0/src/schedule_graph.rs:430:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/f2d93935ffba3ab9d7ccb5300771a2d29b4c8bf3/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/f2d93935ffba3ab9d7ccb5300771a2d29b4c8bf3/library/core/src/panicking.rs:142:14
   2: core::panicking::panic
             at /rustc/f2d93935ffba3ab9d7ccb5300771a2d29b4c8bf3/library/core/src/panicking.rs:48:5
   3: bevy_mod_debugdump::schedule_graph::add_dependency_labels
   4: bevy_mod_debugdump::schedule_graph::system_stage_subgraph
   5: bevy_mod_debugdump::schedule_graph::build_schedule_graph
   6: bevy_mod_debugdump::schedule_graph::schedule_graph_dot_styled_inner
   7: bevy_mod_debugdump::print_schedule
   8: littlefighter2::main
             at ./src/main.rs:317:5
   9: core::ops::function::FnOnce::call_once
             at /rustc/f2d93935ffba3ab9d7ccb5300771a2d29b4c8bf3/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Do we want to add the Egui world inspector plugin that could be displayed, for instance, when pressing F12. It can be quite handy.

https://github.com/jakobhellermann/bevy-inspector-egui

Probably only enabled when built with a debug feature flag.

We need a way for players to edit their controls.

This could be structured in a table, essentially similar to the controller binding list in the README, where we allow setting the controls for the keyboard player one, keyboard player two, and for gamepads.

Menu controls should not be configurable and should remain mapped as they are.

Description

We should have music and sound effect volume options in the settings menu.

Alternatives & Prior Art

#100 setup the tab system needed to have multiple settings pages. The only thing we will need in addition to that will be slider widgets.

Building the slider will be bulk of the work for this task, but there are some slider textures in the wood and paper assets from the FishFight repo that we can use for the graphic design. We can also probably copy the egui slider for the most part and just swap out the rendering pieces.

In beat 'em ups, there are two common ways of displaying enemies' energy:

1. display a small panel structured like the player one (photo + bar) below the player energy panel
2. display a bar immediately above the enemy's head

There are pros and cons for both, which differ when multiple enemies are hit:

• for strategy 1, the enemy panel will change quickly (but visibly) between enemies; only the energy of the last enemy persists for a while (try Final Fight to see what I mean)
• for strategy 2, the enemy bars will be crowded and overlapping

There's no best strategy (unless some innovation is applied 😉. I don't think one as inherently better than the other (I'm personally used to Final Fight's style, which is 1.).

When starting the game, there should be a player join menu that allows both players to join using a gamepad or keyboard, very similar to how it is done in Jumpy.

This allows us to start the game with either one or two players.

When zooming in too far, you start zooming out again but the level is upside down.

I assume this can be fixed by limiting the camera translation on the z axis, I'll try to make a PR for this myself.

Seems like the labels are not getting picked up. Could be related to some incompatibility of loopless with non string labels? I feel like last time I noticed this it was something like that but not sure.

2022-07-11T19:20:33.902241Z  WARN bevy_ecs::schedule::graph_utils: littlefighter2::ui::handle_menu_input wants to be after unknown label: ProcessInput
2022-07-11T19:20:33.902365Z  WARN bevy_ecs::schedule::graph_utils: littlefighter2::ui::handle_menu_input wants to be before unknown label: BeginFrame

Any ideas @zicklag?

We have more enemy variants which need to be added to the game.

• Slinger Variants
• Bandit Variants
• Brute YAML definition and its Variants

EDIT: #203 was made to solve (more or less completely) this problem. Currently, the bug mentioned below is still present (still requires a workaround).

Currently, we have commands flushing issues (1-frame-lag related bugs), and likely race conditions.

Structuring commands flushes is something that IMO needs to be tackled ASAP, because the more time passes, the more (and more subtle) bugs will arise.

Currently the game has one recognized bug, which requires a workaround. I suspect that there are also race conditions.

Note that this is orthogonal to state design.

Description

It'd be good to have menu sound effects. I think two are necessary for now:

1. When you move the cursor or hover over a button.
2. When you click a button.

Alternatives & Prior Art

@64kramsystem just added sound and the menu music ( thank you! ) and it made me feel like the buttons were muted when they should have made some small noise, but I think it's also possible that the noises could get annoying if we're not careful, and it's also still a possibility that keeping them silent would be better.

For the next release our current priorities are

• - System ordering #9
• #13
• #12
• #11

• #81
• #89

Support for mapping of inputs to keyboard/controller buttons via a menu/saved + loaded from a settings asset.

• Setup the data ( i.e. structs/enums ) necessary for the input map. The idea is to map raw control events such as keyboard and gamepad to something like a GameInput event in terms of the actual actions that can be taken in game. #52
• Create a thin storage abstraction that works for web and desktop #79
• #87

http://andrewrussell.net/2016/06/how-2-5d-sorting-works-in-river-city-ransom-underground/

https://www.youtube.com/playlist?list=PLgPMWQb41awm62M5YE3zzAKyw5Odka6JR

https://github.com/conatuscreative

Sometimes when systems are scheduled in a certain way animation state is set back to idle after application of knockback within the same frame causing the enemies damaged animation not to play. Damage and Knockback are still applied as expected.

This will hopefully be fixed by a pass of more explicit system ordering.

Attacks can have a few frames of windup before spawning an active hitbox #53 . This allows for players and enemies to be hit out of an attacks windup animation.

This issue consists of two parts.

Ingame HUD/UI consisting of:
Floating health bars + player/character portraits, likely made using bevy's native UI features.

Reference:

Menus Using bevy_egui
A Main Menu with which to start the game.
A pause menu with which to exit the game.
Eventually this could include submenus to set options, controller bindings.

Character and level select screens will likely be needed as well.

• Main Menu #38
• Pause Menu #41
• Ingame HUD/UI #50

Prerequisite for actual multiplayer,
Systems which work on our current single entity with player component should be changed to work with multiple players.
Camera follow player system will have to change. Could be based centered on average point between all players to start.
Input will have to support multiple players, each should have their own input map.

• Camera refactor to support multiple players; closed by #62
• Input refactor to support multiple players. Work started in #52
• Update AI targeting to better account for multiple players. Done as of c36ceca

The first iteration of a scene system requires a way to define and load levels from a file.

This will require some sort of prefab for spawning in different types of enemy.

Items defined in asset system and systems which allow them to be interacted with.

• #83
• #84
• #85
• #86

Game panic, this occurred while despawning an enemy due to damage/player attack, maybe by using jumping and shooting attack simultaneously (I haven't been able to reproduce it since).

(edit: just reproduced on enemy despawn via projectile attack)

Probably would be solved by explicitly ordering systems/despawning only at a certain stage or at end of frame.

thread 'main' panicked at 'Could not add a component (of type `littlefighter2::movement::Knockback`) to entity 6v0 because it doesn't exist in this World.
If this command was added to a newly spawned entity, ensure that you have not despawned that entity within the same stage.
This may have occurred due to system order ambiguity, or if the spawning system has multiple command buffers'

Collision should be changed so that attacks have hitboxes and fighters have hurtboxes. This will allow us to decide what to do when attacks collide with one another.

Area in red is the active hitbox of the attack, Area in green is the hurtbox of the player during the attack. If the attacks hitbox connects with a players hurtbox the enemy will take damage, if the attack overlaps with an enemies active hitbox, attacks could clash.

Melee weapons are items which while held change the fighters available attacks.

My proposed design for this would be to move available attacks to a component with a hashmap/vec of attacks which is attached to each player.
Items with attacks should have their attacks added to AvailableAttacks component of the fighter they are picked up by while held, with the ability to take priority over the fighters innate attacks (dependent on design of weapon).

For non weapon items, we could decide to either block the fighter from using a subset of their attacks while holding them, through the same method or default to "the only attack you can do while holding a non weapon item is to throw the item, freeing up your hands to continue attacking."

This also calls into question whether all items should be required to have an attack, and/or if we should change the damage field in item definitions to be throw damage instead (since damage stat in fighters has now moved to being attack specific)
This also raises the question of how best to represent the animations of weapon attacks, since they will implicate both the fighters spritesheet and weapon spritesheet.

This looks like useful learning code, but it's hard to feel confident recommending it without a clear license, one way or another.

I propose that we set up an ingame level editor state that consists of an egui menu which shows available fighter/character definitions loaded from the definitions as well as item pickups which should be defined similarly.
Selecting a fighter or item from the menu should then allow you to click to place it in the scene.
Then these placements should be saved to a new level definition file.

• Menu which loads available Fighters and Items
• Mouse driven spawning/placement of Fighters and Items
• Scene/Level export

I'm opening some issues for possible next tasks. Just let me know what you think about them.

It'd probably be good to setup the web build.

It should be easy and I've got a nice HTML file with a simple loading screen ( while WASM is downloading ), and I have a simple system that will make sure the game plays in full screen and auto-plays sound to work around weird chrome browser problems.

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

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

Enemies need to move + attack/interact with the player.
Might consist of pathfinding and an action queue for each enemy.

further reading required
https://github.com/zkat/big-brain - an AI plugin for bevy. I have not yet assessed it for our use case nor used it in any other projects but it seems like reasonable prior art to draw from.

When the players lose, the program doesn't return to the main menu (currently, it crashes).

While it's probably intended right now not to spend effort on this, I think it'd be nice to just return to the main menu on game over. This may (not 100% sure) have also some architectural consequences, if it requires some cleanup to be designed/implemented (which I think is g00d).

We've gotten some new stuff in now, it seems like we could update the video.

It is possible to get stuck toward the bottom of the map such that it is only possible to move in X direction.
I vaguely remember it relating to the way the character is moved slightly downwards by the belly flop attack

Description

Camera needs to be expanded, to implement stop points (ie. all enemies defeated, or boss, etc.).

This is actually low priority for normal encounters, however, for the boss, it's essential.

Alternatives & Prior Art

No response

Pull in iyes_loopless and do an initial pass on explicit system ordering.

Currently, there is separate logic to handle the player translation, for example, on user input vs. attacks.

Such logic should be merged; otherwise, additional translation processing (currently, limits) would need to be applied for each point where translations are manipulated.

A standard pattern for this is all movements should send an event, which is then processed, and applied (according to the rules).

When this is implemented, remove the dir.x < 0. condition from the player_controller system.

I see this as depending on #99, so it'll be clear which systems handle translation, and how they need to be modified (it's known already which they are, but it's confusing to operate right now, since we'd need to introduce some temporal dependency).

When throwing items with T, sometimes one will show up in front of the player toward the ground.
Seems to only happen when throwing multiple in succession but could also just be easier to notice that way.

There is a reference implementation of this in Jumpy:

• fishfolk/jumpy#381

Though in Punchy it gets more advanced because our characters have more varied movement sets that need to be animated properly. A hat attachment is harder to do right if a character can perform a head-butt, tilting their head at an angle.

Even harder if a character has a tattoo variation:

Yet we’re obviously looking at the same core model for both of these examples respectively. What techniques are available to us if we wanna treat these aesthetic variants as attachments that don’t require us to fully hand-paint each new character variant?

We’d like to initialize Punchy through https://github.com/fishfight/FishLauncher

We use a convention for release assets and they should follow this to work seamlessly with the launcher. Explained here: https://github.com/fishfight/FishFight/blob/main/PACKAGING.md#binary-releases

@orhun can answer any further questions.

Description

Problem

When performing a cargo run with env var LC_CTYPE set to an empty string, the window that spawns is blank.
No music plays.
Some Bevy systems still execute during this failure state.

Workaround

LC_CTYPE seems to be an environment variable that accompanies tmux terminal sessions.
Simply running unset LC_CTYPE is enough to get around this limitation

To Reproduce

run: LC_CTYPE="" cargo run

Expected Behavior

(Best guess): The logic that handles for LC_CTYPE when it is unset needs to account for a scenario where it is set, but set to an empty string.

Additional Context

System used

Linux, X11, gnome desktop, kernel 5.15.53-1-MANJARO

# System installed on ~2022-02 with latest x86 Manjaro
ID=manjaro
ID_LIKE=arch
BUILD_ID=rolling
PRETTY_NAME="Manjaro Linux"

rustup show (some information redacted)

Default host: x86_64-unknown-linux-gnu

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu (default)
nightly-x86_64-unknown-linux-gnu
1.61-x86_64-unknown-linux-gnu

installed targets for active toolchain
--------------------------------------

wasm32-unknown-unknown
x86_64-unknown-linux-gnu

active toolchain
----------------

stable-x86_64-unknown-linux-gnu
rustc 1.62.1 (e092d0b6b 2022-07-16)

Log Messages

(Nothing too interesting)

$ cargo run
    Finished dev [optimized + debuginfo] target(s) in 0.14s
     Running `target/debug/punchy`
2022-07-21T05:36:21.782424Z  INFO winit::platform_impl::platform::x11::window: Guessed window scale factor: 1
2022-07-21T05:36:21.806092Z  INFO bevy_render::renderer: AdapterInfo { name: "AMD RADV VEGA10", vendor: 4098, device: 26751, device_type: DiscreteGpu, backend: Vulkan }
2022-07-21T05:36:21.881985Z  INFO gilrs_core::platform::platform::gamepad: Gamepad /dev/input/event7 (ASRock LED Controller) connected.
2022-07-21T05:36:21.884767Z  WARN bevy_asset::asset_server: encountered an error while loading an asset: Parser error: The given language subtag is invalid
2022-07-21T05:36:21.885567Z  INFO bevy_input::gamepad: Gamepad(0) Connected

The line
2022-07-21T05:36:21.884767Z WARN bevy_asset::asset_server: encountered an error while loading an asset: Parser error: The given language subtag is invalid
is not present when using the workaround.

Description

Compiling the project is (relatively) very time consuming. Even making small changes causes slow compiles on my (8 threads) laptop - 35+ seconds. I'm even using the mold linker, which is as fast as it gets.

I have no idea what causes such slowdown. Compiling could be profiled, but maybe somebody has an idea (based on experience) of why it takes so long.

Alternatives & Prior Art

I've tried the dynamic Bevy feature, but it doesn't bring any improvement.