elnudev / hebi Goto Github PK

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.

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.

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.

Currently, the corridors map type only inserts passageways in columns when they fill up the entire grid height. However, this is not the only scenario that will divide the map into multiple isolated rooms. More commonly, with an offset top or bottom corridor, two walls just a single x-coordinate appart that sum (but aren't individually) to more than the window height will touch, blocking the path. The following config.toml file will cause this issue:

[map]
type = "corridors"
width = 51
height = 19
corridor_width = 3
corridor_height = 14
top_corridor_offset = 1
bottom_corridor_offset = 0
wall_variance = 0.6

This shouldn't be too hard to fix, but it might be a bit fiddly. It isn't high priority.

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.

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.

Migration guide

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.

Well, "should" is a strong word, but it is unneeded.

1. &Res<T> is pointless in systems, just use Res<T> (same goes for ResMut);
2. Outside systems, you shouldn't be dealing with the Res* types, just use &T or &mut T. Automatic deref takes care of the rest;
3. Haven't looked too deep, but the same goes for any other SystemParam (thing that can be a parameter to a system) wrapper-types.

Obvious exceptions are things like World, which are not wrappers but are a thing by themselves.

700 line main.rs ?_? wtf

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.

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.

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.

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.

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 });