2 releases
0.0.1 | Dec 18, 2018 |
---|---|
0.0.0 | Nov 19, 2018 |
#22 in #entity-component
6KB
62 lines
nitric
General-purpose data processing library.
Status notes: highly experimental, unfinished, work in progress, not recommended for use
This library is meant as a successor for Specs, a parallel ECS library. However, nitric
aims to be more general
and composable than Specs. In fact, Specs can be implemented as a frontend for nitric
once this library is complete.
Motivation
Specs has many problems, both big and small. The library grew big without much planning and as it is now this will continue and make it very hard to maintain.
Philosophy
nitric
will be a collection of crates all about processing data. All of its crates follow this philosophy:
- Only solve a single problem, in a reasonably composable way
- Expose a general, composable and robust API (also refer to the API design document)
- APIs should either be designed to not produce any error cases or return a
Result
with only the possible error conditions - Do not assume how the API is being used (-> composability)
- Expose internals in an
*-internals
crate for stability by default, with the option to opt into more unstable facilities
- APIs should either be designed to not produce any error cases or return a
- Impose minimal friction to use
nitric
Using nitric
as ECS
How will this allow you to use nitric
instead of Specs? Here's the tentative design for ECS:
nitric-entity
: Provides entity allocators, storages, and with that mappings between entities and components
This would already be enough to have an ECS. Systems can simply be functions that accept references to the storages and eventually the allocator. In fact, that is the recommended way for libraries to expose their API; libraries should not assume how the code is executed. For example:
(pseudo code for now)
pub fn process_local_transforms(
local: &Storage<LocalTransform>,
global: &mut Storage<GlobalTransform>,
parents: Storage<Parent>)
{
// compute global transforms
}
If those component storages come from a dynamically typed, string mapped HashMap
, fine. If they are stored in a
struct
- works, too. How systems are ran also doesn't matter.
Now, there surely are other things Specs users would miss, so the next crate will be...
nitric-world
As you might have guessed, this provides a map that can store arbitrary component storages. In contrast to Specs, I also plan to include support for multiple values of the same type by allowing an additional key (e.g. a string).
nitric-graph
This will be a re-worked version of shred
's Dispatcher
, allowing to parallelize data processing (execution of
systems). A "system" will simply be a FnMut(T) -> R
, which means it's up to the user how the data is fetched
(nitric
will provide solutions for this, but it doesn't force you to use any of them).
Vision
The vision for nitric
is to provide a set of crates that evolve as the standard way to solve data processing
problems. There were already very interesting use cases for Specs, including using it for a compiler and performing
larger simulations, both outside of Specs' original scope (ECS for game development). This is what I intend to make
nitric
suitable for. So to list a few examples of what nitric
could be used for in the future:
- game development
- game physics
- simulations
- compilers
- data validation
- Graphical User Interfaces
Structure
The main crate, nitric
will simply serve as a top-level crate for re-exporting all nitric-*
crates.
However, since everything is optional, nitric
is controlled with Cargo features, only exporting the crates for which
you enable the flag.
Current crates:
nitric-lock
- Locks with deadlock prevention & lock ordering
Contribution
nitric
can only exist with lively contributions and every help is very much appreciated!
Please note that in its current state however, the project might not be very friendly for contributions. If you're still interested in helping out, please contact me (@torkleyy) so we can make sure there's no duplicated effort.
License
All nitric
projects are, except stated otherwise, dual-licensed under Apache-2.0 / MIT. You're free to choose on of
both licenses.
Every contribution made to this project is assumed to be licensed according to these terms.
Dependencies
~0–355KB