Closes #16.

Changes

To do this, I added a new section to the Config, which can take an array of input bindings for each command in the game.

Since the convenient way to write this down in configuration is not strikingly efficient for runtime querying, I created a new resource type DirectionalControls that simplifies runtime access.

Refactored the snake_movement_input system to use this new resource, and cleaned up a bit of its code too, by breaking up the nesting in iteration. While it technically runs faster when the player presses multiple keys in one frame, it was unlikely to be a problem, so this was mainly a readability change. This way it is also a bit easier to add different event-reading loops later.

Usage

Players can change their control configuration like this (likewise for down, left, right):

[controls]
up = [ { device = "keyboard", code = 72 } ]

Sadly, Bevy does not provide conversions from named keys to string and vice-versa, so I had to use their scan codes instead. Good part is that it's keyboard-layout dependent, bad part is that it is rather obscure to set up (I found them by putting a print on key presses and taking note of the codes for each key).

Extensibility

When time comes for #17, the following changes will be needed:

1. Add a new variant to the config::Binding enum with appropriate data;
2. Consume those variants when constructing DirectionalControls (the compiler will yell the location at you);
3. Add a new method to the impl DirectionalControls to read the gamepad event;
4. Call that method in the input system within the processing loop for gamepads.

I imagine this is something you might want to do yourself, but if you need some inspiration you can use this PR as a reference! Do not feel like you need to merge this. 😅

Basically, I removed the grid_width, grid_height and corner_walls fields from Config, and instead created an enum called Map, which can be one of two variants:

• Box layout, which has the aforementioned properties and uses the existing level generation code;
• Custom layout, which allows whoever is writing config.toml to draw a map with ASCII.

To be able to do that, I had to refactor the coordinate conversion function to use a new unified resource for the grid dimensions, since it can be obtained from possibly many locations now.

Here's how config.toml feels like now, using a custom map (before you ask, yes, it is. 😄):

theme = "solarized_light"
tick_length = 0.15
food_ticks = 8

[map]
type = "custom"
data = """
#################
#               #
#  >      >  <  #
#  #      #  #  #
#  #      #  #  #
#               #
#  > <   >      #
#  # #   #      #
#  # #   # ##v  #
#               #
#################
"""

Or using the generation algorithm:

theme = "solarized_light"
tick_length = 0.15
food_ticks = 8

[map]
type = "box"
width = 17
height = 13
corner_walls = true

Currently, the .wav files in the dev_assets folder cause errors when used, even with the wav feature of Bevy enabled. See this thread on the Bevy Discord server for more info. The files seem to play fine, so I'm not sure if this is some issue with the encoding of the files that jsfxr outputs, or if there's a potential bug in Bevy. Either way, it'd be way cleaner use the original .wav files directly instead of having to convert them .mp3 using a shell script like is being done currently and store both in this repository.

Hi :)

I'm not sure if you were able to reproduce this on your end, but when I kill the process the compiler throws:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/main.rs:329:61
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
zsh: segmentation fault (core dumped)  ./hebi

This PR should fix that.

You might have that feeling too:

Currently, if any piece of code wants to spawn a snake, segment, or wall, the system needs to query for those resources and pass them along up to and including the call site. There are like 8 parameters each so it is very verbose, and if you ever need to add something else to the spawn logic (e.g. suppose you later want to add sprites), updating the call sites will be a chore.

This can be substantially improved by either:

• Implementing your own Command, fetching the dependencies from the world inside the write function. This would make the call site look sorta like this:

  commands.add(SnakeSpawnCommand);
  

  Or even in this specific case, move the spawn-location-picking logic to the actual respawn system, and have the command take parameters:

  commands.add(SnakeSpawnCommand { x: 4, y: 6, direction: Direction::Up });
  

• Using an Event, and a late-running system that listens to it to do the actual spawning. Register an Event type, and make a system that runs as late as possible in the frame that reads the events and the required dependencies, spawning the entities. The call site would then look like:

  snake_spawn_event_writer.send(SnakeSpawnEvent { x: 4, y: 6, direction: Direction::Up });
  

Moving each map generator (box, corridors, etc.) into a separate executable and then calling them from the main application instead of having them hard-coded in would increase customization potential for players, who could then create their own map generators for the game.

Instead of using the reasonably-verbose Serde default attributes, consider using the Default trait.

Pros

• Works across the ecosystem, since Default is from the Rust core library;
• Slightly less verbose, you don't have to define a function for every single field;
• Allows you to generate a completely default value without relying on Serde, which I've done in main.
  • This means that the "missing config file" handling is a bit cleaner, since it can skip summoning Serde if the file doesn't exist.

Cons

• Technically it's a wee bit more allocation-happy since all defaults are generated at once and then replaced one by one by the values from the config file. But a few string allocations during startup is not the end of the world.
  • I haven't done this, but it could be fixed by making the configs non-owning, and using &str instead of String, that would mean holding onto the whole source string for the lifetime of the program though. Less allocations, but more memory usage (though since the config file isn't huge it's not a big deal either)

With the merging of #15 and c52b37a, Hebi supports four input schemes: the original arrow keys, WASD, HJKL, and the number pad. It would be nice if the user could create custom input schemes in the configuration file.

For example, if I'm moving right, then hold the left arrow key, then press up, nothing happens. Since the current input code has a strict priority in the form of the if chain, if I hold a key, any key of a lower priority is ignored.

Consider using key events instead of polling, so that the direction is always in sync with what the player last pressed.

Currently, the MapType trait cannot be serialized directly, since serde doesn't support serialization of traits (i.e. Box<dyn MapType>). As a work around, I'm using the Map enum with a variant for each individual map type. This works, but it's extremely verbose and requires a lot of duplicated code for each new map type.

Apparently, the typetag crate will fix this problem—it adds the ability to serialize and deserialize trait objects to serde.

From the user's perspective, the way currently map values are passed in behaves differently than the rest of the config file: you have to put in every single map setting. There should be fallback values for each Map variant in a similar way to #[serde(default)] on Config.

Materials no longer seem necessary for sprites in Bevy 0.6, see the SpriteBundle and Sprite section in the migration guide. This should be done after migrating #25. For now, all material variables have been underscored to prevent unused variable warnings in b1184c7.

Nice project.

If you are still looking for ideas you could implement you could allow the user to provide different audio variations for the same event. For example by allowing trailing numbers like so: eat_0.wav, eat_1.wav, eat_2.wav, etc. Quite a lot of games do that, so the sounds don't get to repetitive.

These are the steps I followed:

• Clone the repo
• Install rust nightly
• rustup show returns this:

~/hebi main
▲ rustup show
Default host: x86_64-apple-darwin
rustup home:  /Users/cog/.rustup

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

stable-x86_64-apple-darwin (default)
nightly-x86_64-apple-darwin

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

nightly-x86_64-apple-darwin (directory override for '/Users/cog/hebi')
rustc 1.57.0-nightly (c3c0f80d6 2021-09-14)

• run cargo build --release --verbose
• Cook an egg with my laptop fans
• Watch as hebi hangs on 299/300. I tried waiting up to 7 minutes and it didn't get unstuck. This is the output, if anyone can understand it:

Other notes: The build size is about 500MB. A lot better than 1.26GB, but far bigger than linux or windows builds.

Kind of like how themes work currently. Name in config, load from a separate file.

Bonus points, would be cool if it used something like curl to be able to load remote files too, which would facilitate sharing.

In that case, it maybe would also make sense to be able to specify a seed for the random map generators? So people can share a specific map, not just the parameters.