Lots of Updates...

So, we haven't really finished one thing yet in the past few months. Being a lone developer, I am experiencing something I am calling "Game Dev A.D.D." Just because we haven't finished a single thing in the past few months doesn't mean that we haven't been working on a lot of small things. This is another one of those posts that says "I'm working on things and the project isn't dead."

We have some really impressive things in the works such as refined Binaural Wind Volumes, an Advanced Inventory System, additional Dynamic Weather System features, Weather Particles, Weather FX, Survival Handbook frameworks, graphical scalability, and menu frameworks. Hopefully, we'll start cranking out actual updates soon.

Below are two screenshots comparing the same scene, one regular scene, and one with a rain particle system and weather FX that have been applied to the meshes in the scene to make them seem wet.

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!

October Overview

Completed Models and Resource Optimization

So, in the time between other times, I've completed another few small props for the game; basic scene dressings that can be placed around the world.




As a feature of Substance Painter 2's export tools, there is an interesting feature that is included that will save on user VRAM and likely on other GPU resources. In the world of game development, there are various texture maps that are used in creating complex materials. Some of these maps, such as metallic maps, height maps, and ambient occlusion maps are maps that are generated in grayscale. This means that a pixel found on that map, of say a roughness map, with a value of white will be interperated as having a value of 1, or full roughness. Black, or 0, would make the surface smooth.

What Substance Painter 2 does with this, to turn three different 4MB files into one 4MB file, is it converts these maps into RGB tones. For example, red would be 1, and black would be 0. By doing this, we can overlay each of the maps on top of one another (and make a really ugly picture) to save on memory. This image can be taken apart and interperated by UE4 during runtime to create the maps that are desired.

Let's say that in our RGB map, red is roughness, green is ambient occlusion, and blue is our metallic map. When being taken apart and iterperated by UE4, if a specific pixel is purple, that means that that area of the texture map has values of roughness = 1, ambient occlusion = 0, and metallic = 1, because the colors red and blue are present, but not green. Gray would imply that all values are equal to 0.5.

On a side note, we've also fixed the shaders in Substance Painter 2 so that they are more representative of the shaders in Unreal Engine 4.

Sergal Model

Looking into the history with the Patreon that is running for the development of this game, and I was wondering why I didn’t have a whole bunch of support that was on par with the good comments that I’ve been getting from people I’d talk to. A lot of people agree the game is a good idea and that that like what I’m doing so far, but I thought something was missing…

I recently came to the conclusion that people would probably be more willing to financially support a game about sergals, and myself, if they actually saw sergals in the game! So, I started making a final (and hopefully it is the final) sergal model to put in my game.

This is a .gif that was used to highlight improvements to the arms of the model, but can also be used to show the overall progress as of 10/10/2016.

What you’re looking at here is a “blank and smooth” male model. He is still missing a lot and needs a bunch of refinement work done on him, but he is some pretty good progress that I’ve got done over the past week, which includes forming the entire base model and various improvements as suggested by the Project Freelance Games community. (Thank you everyone who provided your feedback on the model!)

The way I see it, although he almost looks done, he is only around 1/5 of the way complete.

Texturing and unwrapping is exactly what it sounds like.

After texturing, I’d like to add fur to our model before working on anything else. That is a whole set of complex problems in of itself. Hopefully, it won’t take too long to rig up.

For skeletal rigging, I want to have the base skeletal structure to use for animations, but I also want more intricate facial rigging for expressions, blinking, and talking or shouting. I also want spring joints, also known as jiggle bones, to simulate dynamic movement of different parts of the character, such as ears and tail. In the engine, I am also going to set up inverse kinematics, so that the character’s feet will dynamically update to what they’re standing on.

After that, it’s on to animations. I plan to use a lot of blended animations to get as dynamic a character as possible. This means that the character can decide, from a list of approved animations, what they’d like to do. For example, if we have a character who is walking, we’ll have then run a walking animation. There isn’t really much else we can do with that half of the body; if we’re walking, we’re walking. The top half of the body though, that can have different animations such as regular walking, carrying a weapon in two hands, carrying a weapon in one hand, of the character can even decide if they want to scratch their head or their arm. These animations can be mixed together to make completely new animations at run time and can make a character look more life like.

Looking forward to having a completed model!

Unreal Engine Update / NeoFur Update

We have moved from Unreal Engine version 4.11.2 to 4.13.1

Notable improvements from the previous engine version that would be able to be implemented into Vilous: Soldier of the North include planar reflections, grass and foliage scalability, twist corrective animation nodes, as well as some updates to the stock AI pathfinding, among other impressive things. Unreal Engine 4.13 release notes can be found here. We also updated our NeoFur version from (1.0) 4.11 to (2.0) 4.13 for support within the new engine.

NeoFur 2.0 (4.13) boasts many new features over the older 1.0 (4.11) version. We still have all of the same features such as our dynamic fur simulation, self shading and advanced PBR material support, but in 2.0, artists have access to much more powerful features. Version 2.0 of NeoFur is much more strand-driven, as appose to only using shells for rendering like in version 1.0. This means that density maps can be used, height maps can be used to dictate strand length, undercoats of fur and overcoats of fur can be rendered, each with their own PBR settings, and many other impressive features that will be noted in the next update on this blog when we are finishing our sergal base character.

A screenshot taken from a user of NeoFur who posted this on Twitter. An amazing example of the realistic capabilities of NeoFur.

Team Update / Story Update

We've added a new member to our team! You may know Siskmarek from interactions with her on Twitter, the #Justice4Sisk campaign, or from the sergal game she was making a while back; Dissertation. Unfortunately, due to severe complications on her end regarding the directions things have been turning out for her, she is unable to work on her own game.

However, she has offered to help me in creating V:SotN! Due to her situation, she is unable to access a computer and is flying with some clipped wings, but she is still passionate about the project. Drawing concept art up and helping in writing the story, we're making great progress in creating this game!

Once things are fleshed out a little more in the story aspect of the game, I'll discuss the direction the game is headed apposed to where it was headed. All of these changes are made with user experience in mind, so they're for the better!

Patreon Update

A special thanks goes out to everyone who is supporting this project on Patreon. We broke our $40 goal, so that means that we're going to start hosting live streams for game development on beam.pro. We're plan to try and host a live stream every Thursday. Due to the complexity of my current schedule, this may not be able to happen every week, but I'm going to try! Above are screenshots from the last live stream, done on 10/13/2016.

August / September Updates

If you would like to visit the Patreon page, you can click here to see the video associated with this update.

Since the last post on this blog, we've made some improvements to the sandbox system. Specifically, we re-added and fixed placement collision testing. If on a valid surface, the game will test to see if the item you're trying to place is overlapping anything in the world, and it does it with a much higher degree of accuracy compared to the old system. Below, a player can be seen placing a box underneath a table with both valid and invalid placement feedback. This shows how fine the system can be tuned for placing objects next to other objects.




This new collision detection system properly updates based on the placement mesh that is selected, where the placement mesh is in the world, and how the player orients it.

We've also acquired a copy of Substance Painter 2 at a discounted price to use for texturing items in V:SotN.





Above, there is a quick model that was created to play around with the new software and learn the new tools. It's a small spool of thread, only 2.5in (6.35cm) tall. It comes in four different states to add a bit of diversity to the scene. The base thread texture is also white for a reason; I can easily create instances of the thread material in UE4 and change the color to whatever I’d like it to be.

Substance Painter 2 has a slightly different tool set that I’m trying to adapt to, so the first few models I paint might be bad. I’m working on learning some of the more advanced features like how to set up my model for use with some smart filters and materials in regards to things like automatically generated edge wear and ground dirt.

I’m already dabbling in some features like masks and filters.




Finally, I've also ordered some more hard drives for backups and storage of my game. I now have a total of 3TB internal storage in my computer. You can see my main, all purpose C: drive, and my external 3TB drive that I use for Steam games. You can also notice that I only have one of the new hard drives set up and divided into three partitions based on the media type. (This is because I forgot to order SATA data cables, so I had to rip my house apart looking for the spare one I had laying around. Once I get my new cables in the mail, I'll have the second new drive set up for backups as well.)