preAlpha Sandbox Map is Under Construction

First of all, I’d like to thank everyone who has supported me in the development of this project. Your support fills me with hope and drive to complete this game to the best of my abilities. I am happy to announce that we’ve began working on the preAlpha sandbox map that Patreon supporters will have access to before the game is complete. A lot of work is going into this map because I want to thank supporters by giving them an expansive and rich world to explore while we wait for the final version of the game.

This map will also be available in the final version of the game as a map that players can play around on, completely separate from the story. We’re doing a lot of experimenting and are learning a lot in regards to constructing a large-scale open world. We’re still developing this world with an image of the North in mind, so it will be reminiscent of the environment found in the final game, though it will not be representative of any area in the game. As a matter of fact, some areas of this map are based on the landscape of a local park from the real world.

As you can see from the screenshots in this post, we’re still working on sculpting the terrain, which is a rather involved task. These particular screenshots are of the preAlpha when it had it’s first sculpting pass complete. Sculpting this terrain is done in a few different steps; a base sculpting pass that you can see above is where terrain is blocked in, then a detail pass is done that adds noise to the environment, simulating erosion and creating more dynamic landscapes. The first pass has taken approximately 15 hours of work, and we’re projecting the detail pass to take around the same amount of time.

Though we still have a lot of backend work to do, such as AI writing, finishing up our menus, player character work, redesigning our inventory and sandbox building interfaces and logic, as well as character animations on top of small tweaks here and there to our weather system, a preAlpha release finally seems within grasp.



We’re also planning on changing Patreon pay tiers around as we approach launch of the preAlpha map. Don’t worry though if you fall into new a pay tier that doesn’t correspond with your original pay tier’s rewards. When we make the change, you will receive an email that notifies you of such and you will be logged as being a legacy supporter in our records. This means that you’ll still maintain the previous rewards that you were promised, in addition to any new rewards if applicable.

Thank you so much for your support! You’re all amazing.

Nvidia Ansel Support!

(Let's go ahead and preface this post with a little notice: Those are nowhere near representative of the quality of tree-like organic structures that will appear in the game. I acknowledge they look like garbage. I actually just had a fun time writing a script to randomly generate some trees since everyone has been having a giggle at the "Minecraft trees" shown in earlier development. After generating the core of the tree, I slapped some random materials that kind of look like they belong there. This is not at all representative of what will be in the final game. In fact, it took me around 5 minutes to make these where I've spent hours working on the dirt that you see covering the landscape.)

I recently came across a particular tool that Nvidia has released. By the time of this post, only 28 games, not including V:SotN, have implemented this tool. It's called Ansel, and it's pretty neat.

Players are able to press a hotkey combination (by default, ALT+F2) and activate the Ansel overlay. While in the Ansel overlay, players can use their mouse (while holding LMB) to look around and WASD keyboard controls to fly a freecam around the game world. Z and X will change the height of the camera, and you and hold SHIFT to accelerate any translational movements.

So what is the point of the freecam? Can't that be used for cheating? Yes, but that isn't what it is for. (And there is a limit as to how far away you can fly from your character.) Using Ansel, you are able to take screenshots of the game from interesting perspectives. While taking screenshots, you're also able to adjust different filters such as contrast, brightness, sketch filters, etc. All of these effects aren't applied in post processing but are actually applied to the game itself, making for better looking image adjustments.

You're also able to change the resolution of the screenshots and the type of screenshot you're taking. For example, we're able to do cool stuff like what you see below. This tool will be employed so development team members can get a better feel of the area that is shown to them so they can provide better feedback, and this will also be used to document different areas in the game. Click and drag the image to look around the 360-degree panorama. The square icon will enter fullscreen. You can also view this using an HMD.

The Dynamic Weather System Mk. II

As a part of our code rewrites for optimization and feature adding purposes, we've recently begun working on remaking our Dynamic Weather System plugin for the Ultra Dynamic Sky blueprint. I am happy to announce that we now have a much more complex simulation using much simpler code.

Below is a list of features for our new plugin. (Optimized features are in yellow, new features are in green.)

Features:

Start-up Checks and Reference Assignments:

This is a backend feature that ensures everything is available for DWS to work correctly. Properly, the Dynamic Weather System should be called by the level blueprint and spawned somewhere in the world. Once it is spawned, the system will check for an Ultra Dynamic Sky actor. If one is not found, then the operation of the plugin is ceased and an error message is provided to the end user, stating that a UDS actor is required for the DWS to work correctly. We do not automatically add UDS to the scene since there are many customization options that the world builders are able to take advantage of; we want to avoid an out-of-the-box feel to the plugin. If more than one UDS is present for some reason, we will use the first one placed.

The start-up procedure also checks for a directional wind actor. If one is not present in the scene, then the system will add one. If more than one directional wind source is present for some reason, we will use the first one placed.

The last thing the start up procedure checks for is an exponential fog height actor. Due to its importance in realistic rendering of the UDS, we also halt the system here if one isn't found since the UDS must be set up with the exponential fog height actor.

Once all required actors are located in the scene, references to those actors are established so that they can be later manipulated by the code.

Timer Ordering:

This is another backend feature that ensures the start up of our system goes smoothly. Basically, a timer in the system is not able to start until validation events in the startup checks are passed. This introduces more order to the system and prevents things from breaking.

Cloud Density Shifts:

Cloud density changes aren't new to the system, but they have been reworked in order to work with our wind simulation. Specifically, how they are generated has been changed to work in adapting to the speed changes of our wind.

Temperature:

Temperature is also not new, but how it is calculated is. Temperature is no longer a variable that randomly fluctuates within a given range based solely on cloud coverage and active weather events. Temperature now also takes into consideration the time of day; if it is daytime, then the temperature will be more inclined to increase; if it is nighttime, then the temperature will begin to drop.

Humidity:

For sakes of simplicity, humidity changes are mostly random with some influence from the current temperature. If the temperature is high, then humidity is more likely to increase slightly more than it normally would. If the temperature is cold, then it is more likely to decrease slightly more than it normally would.

Wind:

Perhaps one of the biggest things in this update is our directional wind simulation. The direction of the wind is able to change randomly throughout the day. The wind must update within certain parameters, however.

We originally contemplated allowing the wind to update as it wanted, free of most constraints, or programming in a jet stream so that the wind would always be blowing primarily in one direction with some variation. We settled on programming in a jet stream, so now the wind is able to blow in any direction within a North-to-East heading. (Thank you everyone who voted on this topic in our Discord and on Twitter.)

In addition to wind direction changes, the wind speed will also randomly update within a certain range.

Furthermore, in addition to the wind itself changing direction and speed, the clouds in the UDS also change direction and speed in relation to the wind.

Weather Events:

Though weather events aren't anything new, we have added some new features to the weather events themselves. Weather events no longer work as something entirely dependant on the cloud density; humidity also comes into effect when calculating the possibility of a weather event occurring. 

We also have a new weather event that is able to occur because of our inclusion of the humidity variable; fog. A general humidity based fog is always present in the scene. A fog event, such as the one pictured below, only occurs when a certain set of conditions is met. Important factors in determining the ability for a fog event to appear are the scene's humidity, as well as its temperature.

Solar Activity Simulation:

We now have random solar activity simulation. We simulate solar activities because we added auroras to the game that can be seen during the night. Every time that we run an update of the aurora, there is a chance that a solar flare occurs, which makes the typically unnoticeable aurora much brighter and more vibrant.

Binaural Wind Volumes

Recently, we've added an impressive chunk of code to make Vilous: Soldier of the North seem more realistic. We've created a new blueprint actor class that can be modified on an instanced basis to suit the design needs of the level builders. This actor we created is called a "Binaural Wind Volume."

What does the word "binaural" mean?

Binaural is a term that refers to using two ears. In a recording environment, binaural recording is a method using two different audio channels to record something, and then playing the recording back to the listener by means of those independent channels; one channel is assigned to the listener's left ear, and the other the right. This creates a stereo sound environment.

We started off making this system by generating Brownian noise, modifying the sound samples we created to get a more desirable wind sound, and then assigning the samples to left and right audio channels. If you were to listen to the left audio sample file, you'd only hear a wind sound in your left ear and nothing from your right ear.

What does the system do?

The system is meant to better simulate headwind for the player by adding an adaptive audio component to their game. When the player is looking into the direction of the wind, they will hear a sound that sounds like wind rushing into their ears. If the player turns around so that they aren't facing the wind, they'll still hear the sound of wind rushing past their head, but not into their ears; this makes the wind sound quieter.

It would sound a little strange if the falloff of sound was linear and applied to both ears, so this is where the binaural capabilities of the coding come into action. We aren't simulating and checking the direction the player is facing when we determine how loud to make the wind sound as much as we are checking what direction the player's ears are facing. This allows us to independently change the left and right audio tracks based on where the player is looking. That means if a player facing into the wind turn to their right, they'll hear stronger wind sounds in their left ear as opposed to their right ear.

Hearing models:

Since sergals, the race you play as in the game, have a drastically different anatomical setup for perceiving audio, we questioned how we should program our binaural audio receiver checks. A sergal's ears are located at the back of their head, on either side and are slightly cambered out by an angle similar to human ears. Obviously, a human's ears are much more different, being located on the sides of our heads and pointed forwards. Imagine taking the cartilage of your ears and flipping them upside down so your ears are pointed backward; that is similar to how sergal ears should work.

The question comes into play, "how do we let the player hear the wind like this? Do we use a hearing model that is based on how us humans hear sounds for comfort or do we risk disorienting the player by using a sergal based hearing model?"

We recently ran some polls on our Discord server and from Twitter to ask supporters what they'd like to hear in the game. The results were surprising; Discord was split a perfect 50/50 on what hearing model they'd like, and Twitter overwhelmingly preferred that we use the sergal hearing model.

As a professional design choice of the team, we decided that we'd like to hear the wind comfortably with human hearing models. The polls showed that there was enough interest in playing with the alternate hearing model that we added that as a setting for the game; you'll be able to choose what hearing model you'd want to use, but the human hearing model will be enabled by default.

We currently have both hearing models in the game and the player will be able to select how they want to hear the wind from a settings menu.

Features:

Behind the scenes:
Lots of features are at work that are intended to make use of this asset as smooth as possible. Without getting into technical details, these features are set up to reduce the likely-hood of errors and reduce the amount of debugging that may need to occur by presenting problems as soon as possible.

Debug features:
For our level builders, we programmed in a bunch of settings that can be enabled or disabled. When playing the game in the editor, we are able to draw the volume bounds, wind directional arrow, the sprite that represents the actor, and ray traces for other debugging purposes.

Instance based editor tools:
A large number of settings are able to be changed in the editor, per actor. This gives more control to the level builders, as they're able to adjust individual actors as they see fit.

Variable wind intensity:
In addition to being able to set the wind speed on a per-actor basis, wind variation is also able to be set. This is a value that defines limits for the intensity of the wind to randomly jump around between while the sound is playing. When the loudness is adjusted, the pitch of the wind will also be adjusted. Faster wind is louder and more high-pitched, as slower wind is quieter and has more of a bassy rumble to it.


Volumetrically operated:
By having multiple actors in the scene, world builders are able to create complex wind bodies. Individual actors can be placed to make it seem like the wind is blowing through an open window, that it is blowing into the mouth a cave, or that it's taking a specific path through other complex scene geometries. When a player stands inside of the bounds of one of these actors, they'll hear the wind.

Global wind setting:
The Binaural Wind Volume actors don't just work with volumes; we programmed in a setting that, when enabled, will simulate wind everywhere in the world. This setting disables the volume detection so no unneeded processing occurs in the background if the player should happen to overlap the original bounds of the volume.


Directional sensitive binaural audio:
As stated above, we simulated wind intensities per-ear. Looking into the wind will cause a louder sound to be heard whereas looking in the direction the wind is traveling will cause it to be quieter. Looking to the left will cause a louder sound to be heard in the player's right ear, and turning right will cause the same effect in the left ear.


Blocking bodies:
The system is also able to trace for any bodies that may block the wind from getting to the player. This also isn't a linear system as it works on a per-ear basis. A player is able to stand behind something like the wall of a building and still hear the wind just fine, but as they move closer to the wall, they'll begin to enter an envelope where wind isn't rushing past them. The farther they move into this envelope, the quieter the wind will become.

Since this is simulated on a per-ear basis, the player can stand on the left side of the building and only hear wind rushing past their left ear and little blowing past their right ear due to their proximity to the building's wall. Turning their head to the left, exposing their right ear to the wind will allow them to hear the wind in that ear, and since their left ear is now facing out of the wind, they'll hear less wind from that ear.

Dynamic Weather System integration:
The actor is able to act independently or is able to be manipulated by our Dynamic Weather System. The Dynamic Weather System will update the Binaural Wind Volume's heading and wind intensity in relation to direction and speed that the clouds are moving.

Velocity based wind:

As the player moves, the volume of the wind in each ear will update based on the player's velocity in relation to the wind. If the player is facing the wind and begin moving into it, then the wind will get louder. The opposite is true if they're moving with the wind; the wind will get quieter.

If the player enters a still pocket of air, then they will be able to hear a low rumble of the wind as they move forward (or backward "as a sergal") to simulate them walking through the air instead of the air pushing past them. This effect is scaleable based on the current wind intensity, so players running in the direction that the wind is traveling, if the wind is slow, will be able to hear the rumble of "walking wind" more than if there were in a very windy environment. If the wind is strong and the player is running with it, then the overall effect will seem to stop and they may not hear any wind if their speeds match.

Huge Improvements

It has been quite some time since my last update on this project. A lot has been going on all around, but let's talk about what V:SotN has been doing. We've made some amazing improvements to the game.

Let's start off with a little side story. When I first started this project, I had no idea what I was doing with Unreal Engine. I initially intended to create the famous "PreAlpha Build" and release that to selected supporters to test mechanics, and in working with the PreAlpha Build, I'd learn the engine and be prepared for the final build of the game. Once the PreAlpha was selectively released for testing, then I'd begin copying the code over to the new project, optimize it, and give it a bunch of happy little comments, optimize models and other assets, and everything would be wonderful. The downside of this though, is that I really didn't know too much about what I was doing in the beginning, as I stated. The code was messy, optimization was put on the sideline, and file hierarchies were absolute disasters. It was hard for me to work in the project. So, I skipped ahead past the PreAlpha release and began working on the final build of the project, making the code and assets much more desirable.

Everyone who was signed up for access to the PreAlpha build, don't worry; you will still get that! The PreAlpha map is going to be packaged with the final game, is all. You'll still be able to play around with fluffy Sergals before I start working on the actual story of the game.

With all of that out of the way, let's start talking about what we've got going on in this new version of the project.

Let's begin with:

The Character

- We brought back the three stances. Thanks to a very large and complex piece of code, players are now able to, in addition to standing and crouching, lay down on the ground. The big and scary part of the code comes in for smoothly transitioning the camera, allowing the player to change from any stance to any other stance correctly, dealing with players who want to go ham on the crouch and prone keys so they will end up in the correct stance, as well as a setting that players will be able to enable from the options menu that will allow them to change between toggle-button-stance changes and hold-button-stance changes. Crouching and laying down are both configurable to support this feature together, individually, or not at all.

- Players are also able to toggle (or hold-to-activate) slow walking for each of the stances. This will activate some stealth features in the final release of the game and will also allow you to take in the sights and sounds of the world, or match NPC walking speeds (which seems to be a technology that has been impossible to develop until now.)

- Although not implemented in this current build yet, we added a "disable head-bob" toggle for all of you people out there who like to glide around like robots.

- We also added code so the player will be able to adjust their mouselook sensitivity.

- Full key rebinding will be supported.


The Ultra Dynamic Sky

- Updated sun settings to be more realistic; added bloom and lens flare, as well as set proper inclination and orbit paths that correspond to where the player will be in the world, meaning that the sun rises and sets in the southern hemisphere of the sky.

- We have three different cloud layers now; the highest layer which is a wispy cloud layer that is a static image. This wisp layer can be changed to make the clouds more notable or fainter. We also have an upper and lower level of procedurally generated clouds that are able to change in density and speed.

- Clouds are also now able to change direction! No more cloud traveling in a perfect Northwestern direction; we can make our wind simulation more realistic.

- We also now have lighting palettes that we can manipulate in order to change the mood of the game. In a simple outdoors scene, we can make the weather seem warmer, or cooler based on the choice of color palette. We also have a palette to suggest extreme heat for desert areas.

- A bug was resolved that involved the subsurface scattering of our foliage models. If the game session began in the late afternoon, the flora would have a noticeable orange glow throughout the rest of the session. This was especially troublesome at night time. The UDS will now occasionally update its skylight actor by recapturing the sky scene, which is what was causing the problem with our glowing flora. Now, you can't navigate the darkness by the faint glow of orange everything.

- Pending contact from the GRG, the official people making the Vilous universe, based on their response, we may look into simulating solar activity that will make Aurora events a possibility. Below is a small demo of what such an event would look like.

The Landscape

This is perhaps one of my favorite things in this update.

- Dynamically tessellated terrain with 4 high-quality materials. Terrain closest to the player will have more polygons that it uses for displacing the terrain, as the further terrain will have their regular flat textures.

- The landscape is using an instanced version of the landscape material and not the actual material itself. What does that mean? That means we can add more immersive detail to the landscape by updating it during runtime. When it rains, the ground will get darker and glossier as a result from all of the water. Different materials will dry at different rates. Snow will be able to actually pile up on the ground, not only as a texture, but with physical body at no additional cost to the tessellated terrain, then it will even melt and make the ground wet before drying. We don't have a proof of concept yet, we're just planning for the future as this is something we're able to do with an instanced material; update it at runtime.

Note that Vilous isn't going to look as dead and dry as this demo terrain; this is just what I had in the engine to test with, and that is what I made with it. Vilous will be much lusher.


Props

- We've added 27 small ground props to add more detail to the terrain. (Be careful not to step on some of the smaller sticks. Well, you don't need to be, only because that feature isn't implemented yet. ;) ) One of the branches and three different rocks can be seen in the above tessellation demo .gif.

- We've taken care to outfit these props with LODs to ease rendering load. From LOD0 to LOD3, you can expect the props to be optimized by a factor of around 8. Below is a visualization of how the LODs work. The more screen space that a prop takes up, the more detail it will be rendered in.

And finally...
Dynamic Grass

We had fancy, subsurface lit, swaying grass in the old project. In this project:

- The grass is fully dynamic and able to be pushed out of the way by the player. No more clipping through planar textures when sneaking around in tall grass.

- Careful how you walk through the grass though; you'll leave a trail behind you of grass you've matted down. This can be useful for tracking animals, enemies, and even yourself if you get lost. Grass will eventually spring back to its original position.

- Unfortunately, due to a bug in one of our materials, we are unable to show this next feature. We do however have dynamic fire propagation! Fire can burn foliage, be influenced by wind strength and direction, and foliage type. Burning foliage glows a brilliant orange, and shrinks along its z-axis until it is in the ground, a which point, it'll disappear. What is left behind is a scorch mark on the underlying terrain material.



Thank you to all of our patrons supporting us on Patreon! Your support means so much to me. I hope you're all looking forward to future progress as much as I am! If everything goes according to plan, we'll have one more update before we finish up our Sergal model. The second update, the Sergal model update, should happen around the end of next month.

We also invite you to come check out our Discord server! I post game development stuff there frequently. Come play some games with us, hear about what is being worked on before Patreon finds out, and merp around with us!

Support this project on Patreon!

I am a full time college student who is studying information technology and I'm focusing my degree on programming. I've always had a passion for gaming, so one day, I decided to take that passion a step further and challenged myself by making my own game. Things are a little rough right now, working part time and going to school full time while trying to keep my dreams alive, so any support you'd be able to lend would be greatly appreciated.

My campaign runs on a "donate as I work" schema, where if I don't complete enough work that I'd be happy enough with to share, I won't release a content update and won't collect any donations. I always want to show supporters that their donation is valuable to me and I am not willing to take anything if I don't have something to show for it.

If you'd like to support my work, click here to visit my Patreon page; it'd be greatly appreciated. If you can't assist financially, a pat on the back will do! Any kind of support, even if it's just emotional, is appreciated beyond comprehension.

Come join us on Discord!

Come join our Discord server and talk about gaming and game development! We have a pretty laid-back community of supporters who would like to see our project succeed. Come have a chat with us, and maybe stay a while and play some games with us!

Click here to join our server!