This Week In Veloren 132

This week, we have several writeups from devs. We hear about the status of modular weapons, some physics improvements, and camera clipping.

- AngelOnFira, TWiV Editor

Contributor Work

Thanks to this week's contributors, @xMAC94x, @juliancoffee, @Sam, @Snowram, @pacmanmati, @Treeco, @lboklin, @Xeriab, @XVar, @ubruntu, @imbris, @Capucho, @zesterer, @UMR1352, @yusdacra, @KnightressPaladin, and @ygor.souoza!

The Rust Gamedev Newsletter is out! You can read this week's meeting minutes here.

@Christof is thinking about introducing Levenberg-Marquardt to the profession re-assignment in econsim and seeing the difference in correctness. This clearly calls out for a writeup, but he is still working on it. There will be a long form post once it's further along.

Work by @ubruntu

I tweaked the formula that sets how much experience is required to level up in a skill tree. The result is that lower-level characters will gain levels a little faster, while some higher levels take a bit more, but the maximum amount of experience required to level up is still capped at the same value (1000). I felt this was necessary because some recent gameplay videos showed new characters grinding for quite a while before earning their first skill point.

Modular weapon status by @Sam

Modular weapons are in progress. Not all of this has been done in the past week, I've just been lazy about throwing any updates about modular weapons into the blog at all until now.

• All crafting mechanics work as desired
• Modular weapons will now automatically resolve their quality and handedness from their components (they previously only resolved their stats)
• All modular components have been added as items (they still need models)
• Names are programmatically generated from the shape of components used and the material used to make the components
• Wood models and sprites were added for 6 new types of wood that will be used in making bows, staffs, and sceptres
• Fixed loading of persisted items to properly handle items that had more than one layer of components (and now it supports an arbitrary layer of component nesting)
• Changed specification of models for weapons both in the inventory and equipped in the hand to work for modular weapons
• Added ability for modular weapons to be randomly generated given a toolkind, material, and handedness to allow them to be dropped as loot, given to enemies, and offered as stock in a merchant

Things that still need to be done before merging:

• Migration to remove many of the old weapons and migrate them to modular variants
• Insert all the models for modular weapons after the rest have been made
• Figure out where wood will go to prevent easy progression skips
• Make recipes more interesting
• Various UI/UX improvements to the process of crafting modular weapons
• Balance and stress testing to ensure nothing unexpected is broken

Dev tweaking by @juliancoffee

This week, I've been working on debugging UX.

• E-gui hotkey toggle, press F7 to enable/disable e-gui debug window (you'll still need press F3 to enable debug mode)
• Three new debug lines: Gliding ratio, Gliding Angle of Attack, and Look Direction
• Update of asset_tweak module

Now if you compile the game with --features asset_tweak you can use tweak! macro from the common::assets module. Here is quite a trivial example, I hope you'll find how to use it in your code.

use common::assets::tweak;
let x: i32 = tweak!("x", 5);

This will create an assets/tweak/x.ron file with (5) as its content, but whenever you'll call it again, it will hot-reload so you can tweak values during play testing. This works with structs too! They need to implement Serialize and Deserialize if you want to use default value.

use serde::{Deserialize, Serialize};
use common::assets::tweak;

#[derive(Clone, Deserialize, Serialize)]
struct Data {
    x: i32,
    y: i32,
}

let default = Data { x: 5, y: 7 };
let data: Data = tweak!("dimensions", default);

Note that struct should have double parentheses (like (5) in previous example and one pair of parentheses for the struct itself). Check examples and tests in this module to learn more. And for small combat fixes; beams now follow the orientation of caster (not look direction like it was before) and agents now can correctly use it too.

Physics improvements by @sudoreboot

This week, I identified and resolved a mistake in the aerodynamics simulation that improves glide ratios significantly. More specifically, the mistake was that the lift coefficient included the glider's reference area as a factor. This messed with the resulting induced drag, which is a function of the (square of the) lift coefficient and the glider's aspect ratio. In other words, the amount of drag from angling against the wind was much too high, and now it should be much lower and more accurate.

I also made the orientation of the glider tend towards the camera direction while wielding it on the ground. Mostly because it makes the state feel more visually dynamic and interesting, but also because it makes the transition a little more seamless.

Between @juliancoffee, @treeco and myself, we managed to come up with a way to make the different playable species glide equally well while letting them keep their distinguishing physical attributes, such as size and mass (both of which were also adjusted to be more sensible). As a side-effect, hitboxes now also very closely match the characters' models.

Camera clipping by @klipkonn

I've been working on improving camera clipping. I started by reduced camera clipping by ray casting just outside each camera corner instead of ray casting only to/from the center. Now the camera will automatically zoom in if the player model becomes hidden and the target zoom is under 20.

Zooming in makes much more sense in tight environments such as in town as otherwise it's hard for the player to navigate. The change itself was rather easy it was by flipping ray casting direction. With further distances, we ray cast from camera towards player until we get out of solid blocks and place camera there. Now in near distances, we ray cast from player to camera until we hit solid object and then place camera in front of it.

For zoom distances greater than 20, previous behavior was kept to allow trees eg to pass in front of camera and cause less jumps if zoomed further out. Next, I'll work on "mode" switching between near and far "mode" as well as on far mode in the future as I got some great ideas from discussions.