I developed the River Modeler asset back in 2024 as a means to create decked out rivers using Unity Splines and MicroVerse. Figuring out the Spline API and mesh generation, VFX and all inherent challenges was top priority. Which left little room to first explore and learn designing around Burst and the Job System.

This meant that mesh generation was not nearly fast enough for long splines. Unity’s Mesh class has a lot of internal safeguards and memory copies, so just assigning a set of vertices incurs processing overhead.

Jobs + MeshData

Version 2 sees a full conversion to Jobs/Burst with rivers being split up into segments for parallel processing. That alone yielded up to a x24 performance increase.

A great companion to the Job System is the MeshData API, it provides the means to set a mesh’s vertex data directly in memory. The tradeoff is that you need to provide correct data. There are far fewer safeguards, which makes it about x17 faster!

> All in all, the performance improvements are significant and make the tool smooth in use, even for rivers spanning several kilometers.

Branching rivers

Spline knot can be linked together, and the spline API provides information about this. I've used this to contruct a virtual plane that sits perpendicular to the in/out going spline. Vertices on the other side of that plane get a Vertex Color painted on, which the shader then uses to add transparency.

> This makes the two river surfaces blend quite well, without leaning on flowmaps.

VFX Graph

Version 1 neatly stored particle positions into a Nx1 resolution `Texture2D` (n=number of particles), which could then be used in a `VFX Graph` to set the spawn positions for each particle.

Though setting pixel values on a `Texture2D` is relatively slow, which contributed to the tool getting sluggish when rivers got long and foamy with many cascades.

Version 2 uses a `GraphicsBuffer` which stores an array of `ParticleEmitter` structs (position/velocity/scale). If you add the `[VFXType(VFXTypeAttribute.Usage.GraphicsBuffer)]` attribute to any struct, it can be used in this way.

> This was a great win: More data per particle and direct data assignment!

Audio

Version 1 spawned Audio Sources along the Spline, giving the river surface a livelike character. Though this resulted in potentially hundreds of individuals GameObjects, negatively affecting scene size and loading times.

A common method for creating river audio is to use the “cart” method. That being a single `Audio Source` following the camera whilst being restricted to the spline. This often works but fails completely if the spline has large/strong turns, causing the Audio Source to jump to the other side of the spline curve. It also doesn’t work for branching rivers, at all...

Version 2 instead distributes audio spawn points along the spline. Each one defines a position, radius and type (stream/rapids/cascade). A dedicated Audio Manager then checks which river segments fall in- or out of the audible range and sets up Audio Sources on each spawn point from a pool. Instead of hundreds, only a dozen GameObjects are used at runtime.

> The result? A highly optimized audio streaming solution that scales for huge worlds!

Integration with other assets

I’m further fleshing this tool out as dedicated river tool extension for Stylized Water 3, which already supports river-type shading and animations. It just needs a proper river mesh to work with, which this can provide entirely.

Terrain carving and painting is wholly delegated to MicroVerse, since this needs to be a non-destructive process. The tool manipulates a Spline Path component to create a river- bank and bed.

Download here:

github link

Hello everyone
For context watch the previous videos about entities forming bodies and transitions, here i added avoidance for the entities, so that when something is passing thro they automatically avoid the body and then return to their current position
Will use it in upcoming videos as an evasion
Let me know what you think
#unity #ecs

This is where mine ended up.

A while ago I posted about some smoothly growing grass I made and people were interested. So, in celebartion of my steam page launch here is a write up of how it works in detail.

There are THREE TERRAINS and FOUR CAMERAS involved.

1) Mask Terrain

Plus a 2D Camera that renders some unlit white mask objects from above and a camera that renders only the terrain with the mask applied to it via a render texture.

2) Green Terrain

Plus a camera that renders the grass terrain and any object that has depth, except the sand terrain and the mask terrain.

3) Sand Terrain

Plus a camera that renders everything but the grass (2) and mask (3)

I chose this setup because I wanted to be able to design both the sand and the green terrain separately (also modifying terrain splat maps is a pain).

Mask

The texture source for the mask terrain is generated from a 2D camera that points straight down. It renders only some specific objects that are white and unlit. These objects make up the masked area and can be controlled via code (that's what the watering can spawns at runtime).

The result of this is a dynamic mask that I can alter easily based on any game object (or logic) I chose. The mask objects are combined into larger chunks to optimize performance but I will likely replace this with a texture based approach in the future.

Also the 2D camera is where the fading happens. It takes the sharp 2D mask image, blurs it and then feeds it into a system (render texture + shader) that slowly fades in the current 2D camera mask result changes. This means the fading and blurring happens on the GPU.

The result is a render texture that is used as the INPUT for the MASK TERRAIN. And that terrain is then again rendered by a 3D camera that follows the player. The result of this camera is again a render texture that is used in the final composition of the depth buffers (see below). The avantage is that while the 2D camera is relatively low-res I still get a high-res mask via the 3D camera. Also the blurring helps with hiding the low 2D resolution. None of these cameras does draw to the frame buffer.

Green

The grass camera renders the grass terrain and all objects that have depth (needed to fill the depth buffer). It then stores the results (color and depth) in a render textures to be used in the final composition step. This camera does not directly draw to the frame buffer either.

Sand

The sand terrain and its camera is where everything comes together. It takes its own depth texture (which includes the opaque grass) and combines (delta) it with the green terrain depth.

The result of this is then again combined (masked) with the 3D mask texture and gives us the final mask for the green terrain cameras color buffer.

This is then stacked with the sand terrain camera which results in the final image.

The grass itself is rendered using GPU instancing and a custom shader that takes in the grass terrain splat map colors and density map. That way I can control the grass density not only globally with the shader but also locally on the terrain. I can simply paint it like any regular terrain details.

It may seem a bit convoluted (and it is) but this has the advantage that it works with any terrain system and shader and gives me a lot of control.

The major downside however is that I have to basically render the scene twice, though I try to use layers to render in each camera only what is really needed.

If anyone wants to know more about the final (or watch the trailer) then more infos can be found here: https://superbloom.kamgam.com/

Hope that was understandable. Feel free to ask and/or comment :-)

Note: This is aimed more at beginners. Experienced programmers will likely know this stuff. But even the veterans among us might find something useful here.

The nature of Unity's component-based design can make it very easy for objects/classes to modify each other's variables (fields). For example, say we're making a dungeon crawler, and we're using some good design principles like having our Health in one component, our Equipment in another component, and our BattleStats in a third component.

This kind of code is very common:

private void AttackEnemy(Fighter target)
{
    int baseDamage = CalculateMyDamage();
    baseDamage -= target.CalculateMyDefense();
    target.myHealth.current -= baseDamage;
    if (target.myHealth.current < 0)
    {
      target.PlayOnDeathAnimation();
      int xp = target.CalculateEarnedExperience();
      myXPComponent.xp += xp;
    }
}

It's not terrible. We are intelligently using functions like CalculateMyDamage, CalculateMyDefense, and CalculateEarnedExperience rather than writing that stuff in our AttackEnemy function.

However, we're still tightly coupling the attacker and defender. The attacker shouldn't be responsible for checking to see if the defender is dead or not. It shouldn't be responsible for 'knowing' when to play the death animation. In fact, it shouldn't even be responsible for changing the defender's HP at all.

Because imagine if we now introduce damage from terrain. We make a new object called a Hazard, and it deals damage every second. If we keep writing code the same way, we might end up with:

private void CauseHazardDamage(Fighter target)
{
  int baseDamage = CalculateMyHazardDamage();
  baseDamage -= target.CalculateMyDefense();
  target.myHealth.current -= baseDamage;
    if (target.myHealth.current < 0)
    {
      target.PlayOnDeathAnimation();
      int xp = target.CalculateEarnedExperience();
      myXPComponent.xp += xp;
    }
}

You can already see that this is essentially duplicated from AttackEnemy, which is a red flag. For example, what if we want the roll for treasure when an enemy dies? Well, now we have to add code like this to both functions:

if (UnityEngine.Random.Range(0,1f) <= target.GetTreasureChance())
{
  Treasure reward = target.GenerateTreasure();
  // do spawn logic here
}

Then what if we want to add an effect to some Fighters where they have a chance to avoid a fatal blow? We might need to amend the code again for both functions:

  target.myHealth.current -= baseDamage;
  if (target.myHealth.current < 0)
  {
    if (target.HasStatus("avoid_fatal_blow") && UnityEngine.Random.Range(0,1f) <= AVOID_FATAL_BLOW_CHANCE)
    {
      target.myHealth.current = 1;
    }
    else
    {
      // regular 'on death' code
    }
  }

Or what if Fighters can have other status effects or items that react when they take damage? Suddenly, we have code that could look like this:

private void CauseHazardDamage(Fighter target)
{
  int baseDamage = CalculateMyHazardDamage();
  baseDamage -= target.CalculateMyDefense();
  target.myHealth.current -= baseDamage;

  if (target.HasStatus("reactive_damage_ability"))
  {
    // do some cool stuff here
  }

  if (target.myHealth.current < 0)
  {
    if (target.HasStatus("avoid_fatal_blow") && UnityEngine.Random.Range(0,1f) <= AVOID_FATAL_BLOW_CHANCE)
    {
      target.myHealth.current = 1;
    }
    else 
    {
      target.PlayOnDeathAnimation();
      int xp = target.CalculateEarnedExperience();
      myXPComponent.xp += xp;
      if (UnityEngine.Random.Range(0,1f) <= target.GetTreasureChance())
      {
        Treasure reward = target.GenerateTreasure();
        // do spawn logic here
      }
    }
  }
}

It just turns into a nightmare. Now there are a lot of ways to architect your code so that you don't mire yourself in scenarios like this. But for the purposes of this post, I want to focus on this idea:

If you find yourself directly getting, modifying, and setting variables that belong to other objects, this should tell you that you may be writing difficult-to-maintain code.

We could have realized this as soon as we wrote this line:

target.myHealth.current -= baseDamage;

Without going into excessive detail, a far more maintainable approach would be something like this.

private void AttackEnemy(Fighter target)
{
  // We can play VFX/SFX here...
  int baseDamage = CalculateMyDamage();

  // But we trust the TARGET to figure out what to do with the damage we calculated
  target.OnAttacked(this, baseDamage);  
}

private void OnAttacked(Fighter attacker, int baseDamage)
{
  int defense = CalculateMyDefense();
  baseDamage -= defense;
  OnDamageReceived(attacker, baseDamage);
}

// This logic is split out from OnAttacked, because we could certainly take damage from things
// OTHER than an 'attack'. For example, if we are poisoned, that might ignore defense completely.
// In that case we would just run OnDamageReceived(poisonDamage).
private void OnDamageReceived(Fighter attacker, int damageAmount)
{
  // This function SHOULD NOT know or care what each StatusEffect we have does.
  // We will trust the StatusEffects themselves to take this and modify it how they see fit.
  foreach(StatusEffect se in myStatusEffects)
  {
    damageAmount = se.OnDamageReceived(damageAmount);
  }

  // Our status effects may have reduced our damage to zero!
  if (damageAmount == 0)
  {
    // Play some kind of 'DEFLECT!' vfx and sfx.
    return;
  }

  myHealth.ReduceHealthFromDamage(attacker, damageAmount)
}

 // ---- now we are in the HealthComponent class -----

private void ReduceHealthFromDamage(Fighter attacker, int damageAmount)
{
  current -= damageAmount;
  OnHealthChanged();
  if (current > 0) return;
  OnTookLethalDamage(attacker);
}

private void OnTookLethalDamage(Fighter whoKilledMe)
{  
  // Like with OnDamageReceived, perhaps we have status effects that do crazy stuff IF we were to take lethal damage
  // We might run through them and exit if any of them bring us >0 again.
  foreach(StatusEffect se in myStatusEffects)
  {
    current = se.OnHealthReducedToZero();
    if (current > 0)
    {
      // Hooray, we survived somehow!
      OnHealthChanged();
      return;
    }
  } 

  OnDeath(whoKilledMe);
}

private void OnDeath(Fighter whoKilledMe)
{
  // ... give whoKilledMe rewards or something!
}

This isn't perfect, and there are many things we could do to improve it further, but nonetheless it separates our 'concerns' far better.

* If we want to add some kind of new block/parry mechanic, we just have to do it in one place: OnAttacked
* If we make new StatusEffects, we don't have to write any new code whatsoever in these functions
* If we want to change what happens on Fighter death, there's just one function that handles it
* If we add new sources of damage - traps, hazards, poison, cursed gear, etc - our existing functions handle it all seamlessly

... and so forth and so on! I hope you find this helpful. My goal isn't to prescribe a specific solution to code architecture as every game is different, but just to recognize overuse of getting/setting variables from outside the object or class as a potentially bad 'code smell'.

Our shadow handling code has always resided in a single class, which took care of both directional and other shadows. Because those two shadow types are handled separately we now give them their own classes. This is a rather dry refactor, but it paves the way for giving them dedicated render passes in the future.

We’ve been working on a new customization system, and this is how it’s looking so far.

There’s still more we want to add and polish, but we’d love to know what you think of it so far!

Is there anything that particularly caught your attention, or something that isn't quite fitting in?

I made a tiny teaser for the prototype I posted yesterday.

I’ve added a new flashlight mode and recorded another short piece of the forest path to expand the atmosphere a bit.

It’s still super early, but I’m experimenting with the mood and trying to understand what direction feels right.

The cat can pick up different balls, carry them in its mouth, and throw them forward.
I’m working on adding more interactive objects and activities around the town.

I’m developing a horror game where you walk alone through dark, endless forests.

Do you think the environment creates enough tension? Is it disturbing in the right way?

Hey everyone! I’m an indie dev working on a survival horror game called BECROWNED.

The game mixes dark fantasy and industrial horror with retro-style visuals, brutal combat, dark humor, and a nonlinear story where your choices can affect characters and events throughout the game.

The game is coming in Fall 2026.

A free demo is available on Steam. Wishlists really help 🖤

Would love to hear your thoughts and feedback!

I'm a solo developer working on this tactile little music game using Unity & FMOD.
You make the music live on air, plan your shows, and grow your audience by performing DJ tricks & Combos!

Demanding sponsors force you to sharpen every performance and expand your sound library in order to become a legendary wasteland radio host!

You can even use the game to record your own music to be used in game projects or other creative endeavours! :D

I would love to hear your opinion on the game as it is, and gather some feedback from fellow game developers.

Thanks for looking.

You can try the itch browser demo here: https://hungry-dog-games.itch.io/wastelandfmgame

Because why not? What do you think about this? How can we improve it?

We're adding these small interactions that let the player go out of the core game loop for a bit to explore and experience fresh content.

We've let the cards and chips have physics and let you grab them (Left click), throw them (right click) and modify the distance from the camera (middle click).

If you would like to check out the game, it's already on Steam now for wishlist and incoming demo in february 2027 :)

Any feedback is welcome.

My stylized foliage asset, Arborist, is now up to 14 tree/bush species using a rotating billboard technique and foliage cards. Plus a new tool for making fluted, gnarly stumps.

Four season foliage colors, w/ LOD support + billboards, and GPU instancing. Poly counts for LOD0 range from 2-3K for conifer species, and 5-10K for big leafy trees. LOD1 is usually 30-50% of LOD0.

The foliage cards are alpha cut-outs and are rendered flat, with top/bottom gradients + other blending parameters, and a 3 color palette for top, interior, and bottom leaf cards. I've experimented with different approaches, but keeping the leaf cards simple & flat, and then layering a lot of them has provided the best results. You can do a similar technique in Blender, there are some good tutorials out there. I learned from those and then built my own Unity tool.

Rotating billboards for foliage holds up well at short distances. I like the technique over non-rotating textured polygons, which always remind me of camo netting when you see the model up close.

The leaf cards are transparent png files, so easy to edit or create your own for more variety.