timberwolf
| Crates.io | timberwolf |
| lib.rs | timberwolf |
| version | 0.5.0 |
| source | src |
| created_at | 2019-01-27 10:36:24.003686 |
| updated_at | 2021-01-09 17:43:11.869954 |
| description | a high-performance 3D-focused game engine |
| homepage | |
| repository | https://github.com/DangerInteractive/TimberWolf |
| max_upload_size | |
| id | 110894 |
| size | 55,836 |
Alex Barber (RaidoWolf)
documentation
README
TimberWolf
a high-performance, cross-platform, modern, pure-rust game engine
Objectives
- seamlessly cross-platform
- triply safe (type-safe, memory-safe, thread-safe)
- maximizes performance
- extensibility and flexibility over ease-of-use
- declarative over imperative
- react-ish push-pull reactive APIs
How to Use
This is a Rust library, available through crates.io. To install as in your project you simply need to add it to your Cargo.toml as a dependency:
[dependencies]
timberwolf = "0.5.0"
Running the Demo
As of now, there is only a single demo app, which shows the game loop timing and logging subsystems.
cd triangle
cargo run
Why should you use this instead of Amethyst or Piston?
For now, you shouldn't. Amethyst and Piston both have large communities, more complete
implementations, more mature codebases, and more developer resources dedicated to
them. If you want to make a video game right now, those things will be more useful to
you. If you want to experiment with new game development patterns and learn a bit
about drown in game engine code with me, you're welcome here!
What sets this engine apart from its competitors?
For the most part, this engine will naturally have many similarities with many of the other engines out there. My original goal in making this engine was as an ambitious learning tool for myself, but I ultimately would like it to make it to production use.
The end-game for this library has yet to be solidified, but as of right now, I'd like to differentiate from other engines by putting a stronger focus on using more declarative/functional programming patterns, whereas gamedev has traditionally been extremely dependent on very Imperative Object Oriented patterns. I also want to follow some of the same decisions that React (the JavaScript library) by designing some API to use a push-pull reactive API to propagate data between some entities, and across the boundaries between state and I/O.
This is all theoretical and imaginary until I get the time to put those plans into practice and find out how they ultimately work out. For the forseeable future, that's what this engine will be: highly experimental.