This Week In Veloren 60

This week we check in with @Sharp about some improvements to the map. Many contributors have been putting good work into combat, and there is progress to show! @Timo does a design analysis article on Zelda: BoTW.

- AngelOnFira, TWiV Editor

Contributor Work

Thanks to this week's contributors, @xMAC94x, @Acrimon, @Songtronix, and @Capucho!

@Adam, @Slipped, @Pfau, and @Timo have been working a lot on combat. This work has lead @Slipped to compile "8,000 times", while @Timo was never able to compile in time before someone else pushed a new commit to the branch. Here are some items that they covered:

- Abilities like dash and triple strike
- More work on the new inventory by @Pfau
- Inventory supports stacking
- Armor as items
- Many bug fixes
- Fireball explosions
- Animations for hammer attacks, axe attacks, sword spins, arrow firing, and spell casting

@Comfy has worked on exporting most of the models used in the game. Many were saved instead of exported, so this will cut down on file size. @Capucho is working on implementing free look.

Analyzing the Map of Zelda: BoTW by @Timo

As part of game design, @Timo has written an article on the map in Zelda: BoTW. This analysis is a good way to get inspiration and ideas for things we could make use of in Veloren. Here is a short excerpt of this article:

Maybe you've heard of the 40 second rule of open world games. It says that there has to be something that catches the players attention every 40s on average. Luke Stephens did an excellent video on this, where he tries to find out how well the 40s rule applied in a variety of open world games. This article is meant to expand on the idea to find out how open world games manage coming up with so many interesting ideas.

Map improvements by @Sharp

This is only a small update for maps, but worth mentioning. We switched from shadow maps to horizon mapping. This means we can store just two angles per chunk to get proper lighting across the sun's whole arc (ideally I'd like to keep this to 1 byte each), plus two bytes of "occluder height" to give us an approximation we can use for soft shadows.

This theoretically uses considerably more space per chunk than the implementation of binary, sharp shadow maps for height fields as described in the other paper. However, sharp shadows usually require much finer granularity (possibly column level rather than chunk level) to look decent, which we probably don't want. Since our characters can also be in the air, I also wanted to make sure we could come up with some plausible estimate for the height where a chunk stops being in shadow, which requires the extra height data anyway.