v0.2
Milestone ID: 590031
This update is split into several distinct phases. Additions to a phase should be discussed and ratified before that phase has begun. Additions that are not ratified in time should wait for a future update.
Phase 1: Refactoring
This phased focuses on heavy-duty refactoring of the codebase. It involved significant and rapid changes to the codebase, many of them likely to break existing systems and will make merging pre-phase code difficult or impossible.
Global changes
-
Use vek
across the codebase -
Use job system where possible (excluding voxygen
, where some code must necessarily be executed from the main thread) -
Use the postbox networking system everywhere -
Remove all instances of .unwrap()
and.except()
(unless approved by core developers) -
Audit dependencies, remove those that are unnecessary (I'm looking at you, syrup
) -
Switch to parking_lot
for sync primitives such asMutex
,RwLock
,Once
,CondVar
, etc. (this will help us remove many instances of.unwrap()
for lock poisoning)
API
-
Discuss and implement an 'intent' input system for front -> client
controls -
Discuss and implement an client
-> frontend 'event' system (callbacks? event loop? mpsc?) -
Move to crate-specific Error types (i.e: server::Error
) for all API crates -
Consider and implement unified API for all library crates, consider use cases including frontends, third-party apps, mods, plugins, etc. -
Client
,Server
, and other API structures should use a builder pattern
region
-
Merge physics rewrite - [-] Move to an ECS
-
Move to VolSample
to enable mesh + collision optimisations -
Implement a chunk format persistence system to improve the performance of over-the-network chunks (there is also a potential for significant client-side memory optimisation)
voxygen
-
Make voxygen
modular as part of effort to move towardsgfx-hal
in the future - [-] Implement a high-level render pipeline abstraction to permit use of both OpenGL and
gfx-hal
as rendering backends. - [-] Implement mesh optimisations made possible by move to
VolSample
-
Split frame constants and model constants to avoid unnecessary transferring of data between GPU and CPU -
Only update chunk model constants when the chunk is created -
Pass additional world information to the shaders -
Prevent framebuffer stretching when using non-standard aspect ratios
net
-
Discuss and implement new networking protocol (how do we deal with entity metadata? Chunks? Player names and login? Online players?) -
Implement postbox system on top of load-balancing network system
headless
-
Find Syrup alternative for headless
- [-] Clean up CLI interface
Phase 2: Features
This phase is primarily focused on implementing new features.
voxygen
- [-] Movement Acceleration tilt (should this be implemented in
client
?) -
Skeletal animation system (Overgrowth is an excellent source on how to program movement) -
Keyframed animation (stride wheel?) -
Interpolation?
-
-
Add shadows -
Add AO (Ambient Occlusion) -
Add Audio Engine/Api -
Add simple day/night cycle -
Add view distance fog to hide world generation
client
-
Character faces current velocity instead of aligning with camera -
Character rotates towards velocity
server-cli
- [-]
server-cli
should use a config file system (.toml? standardised across crates?)
Phase 3: Feature freeze
During this phase, no heavy changes to the codebase are made. Development focuses on smartening, documenting, and debugging the codebase, only adding small features as a matter of urgency.
Global changes
-
Add tests across the code -
Add benchmarks across the code -
Properly comment all code - [-] Apply format and linting to codebase (rustfmt + clippy?)
-
Standardise order and labeling of imports -
Create master overview diagram describing entire codebase -
Remove logic, casting and mutability warnings across the codebase
API
-
Add docs for API (i.e: non-binary) crates ( world
,region
,client
,server
andcommon
) -
Document API crates on the wiki, including examples of usage -
Add #[allow(dead_code)]
to structures/methods that form part of the public API
Organisational changes
This update also brings about significant changes to the way development is structures, largely revolving around the establishment of working groups to better focus development and bring new developers into the fold.
-
Define purpose for working groups, allocate PoCs for each -
Begin producing weekly/monthly working group targets -
Weekly working group blog writeups on changes -
Weekly working group meetings (Discord calls)