This breaks shapes out into having separate colors. This requires breaking shapes out into an enum describing the shape and the shape layout, then we can add the mesh and material based on the shape enum variant. |
4 weeks ago | |
|---|---|---|
| .cargo | 4 months ago | |
| assets | 1 month ago | |
| examples | 1 month ago | |
| src | 4 weeks ago | |
| web | 4 months ago | |
| .envrc | 6 months ago | |
| .gitignore | 4 months ago | |
| Cargo.lock | 1 month ago | |
| Cargo.toml | 1 month ago | |
| README.md | 5 months ago | |
| build.rs | 5 months ago | |
| flake.lock | 4 months ago | |
| flake.nix | 4 months ago | |
| justfile | 2 months ago | |
| rust-toolchain.toml | 5 months ago | |
README.md
Games by Elijah V.
This is a mono-repo I am working on containing many mini-games I am working on.
Games
Building a game
You can build games in this project with cargo provided by Rust:
$ cargo run --bin game-name-here
That builds and runs a lightly optimized (but still debug) build of the game.
For a fully optimized build add the --release flag:
$ cargo run --release --bin game-name-here
Games in this project
All games can be found in the src/bin/ folder.
There is a README in that folder with more info, and there should be a README in each subsequent game's folder with a rough design doc of that specific game.
What about examples?
I also have some examples which are meant to test out specific code or mechanics.
The distinction is basically if it has a menu it's a game, if it just runs it's an example.
Why a mono-repo?
For all of the reasons that mono-repos are good!
- Code can be re-used across multiple games easily.
- Code from one game can be easily referenced, copied, or forked.
- I can stare at my accomplishments in one place.
Mono-repos get a bad rap because they feel bloated, or can cause conflict when lots of people step on each other's toes. I am a solo developer, so none of those are really problems for me.