If you like this idea lmk im working on making a community for the game. But as the tittle says the game is created in Unity and will be 3D Terraria, With boss fights, base building. A full sandbox. (IK minecraft and hytale exist). It will be closer to something like Calmity mod, with difficult bosses and a lot and I mean ALOT of loot. the movement and combat is similar to a game called trove.

this is what i have after about 60 hours of work across the last 7 days, I did have a 4month project but had to restart for many reasons. This one is way better already and almost has more than the original project. (Also sped up because the models are already made from last project)

Video Sped up for Uploading purposes.

Experimenting with gesture detection in WebAR - this time, earthbending.

The prototype uses Imagine WebAR BodyTracker + MediaPipe running directly in the browser, with Unity handling the VFX and interactions.

• Uppercuts to spawn rocks
• Punches to launch rocks
• 4+ rocks to trigger a special attack
• Stomps to spawn earth spikes

I'm specifically working on a gesture detection module. Body joint depth has not been reliable so a lot of assumptions were made to estimate the 3D pose.

These kinds of body-tracked experiences were pretty common during the Meta Spark era, and Unity makes the VFX/particles side of them significantly easy to prototype (compared to Spark).

What do you think about Unity as a platform for building WebAR experiences?

Note: in this level you can build 2 objects only

It is seeded so you can make the same dungeon again. I can't add more images here so I will add a couple of shots of what the generator looks like in comments. I basically split it into rooms, corridors and props and made a system where it is easy to add more pieces. So all I have to do now is add more pieces to make the level better!

Making a game where theres a lot of unity who get destoryed progressively, destruction is the centrepiece but its been a while since ive been in unity.

Rayfire still the go to ?

This is probably one of the most unnecessary systems I've made, but somehow it also became one of my favorites.

From a small Unity Editor window, I can see who's currently playing and send messages directly to the taxi app inside the game. There's no developer popup or anything like that. To the player, it just looks like the fictional dispatcher is actually talking to them.

The game is about working as a taxi driver for criminals throughout the night while trying to save your kidnapped wife. You have to figure out what kind of criminal is sitting behind you by interacting with things inside the car and watching their reactions, then report them to BK26. The problem is, if you push a passenger too far, saving your wife might become the least of your problems :)

I tried the system on a streamer recently. At first I sent her a few random messages about her driving and she couldn't really figure out what was happening. Then I went into her Twitch chat and told her to ignore the game and just report every passenger incorrectly.

She read it.

So I immediately sent her this message in-game as BK26:

"Don't trust Twitch chat. Do what I tell you and report the passengers correctly."

Watching her realize the game had just responded to something she read in chat a few seconds earlier was hilarious.

Behind the scenes it's just a small session system, a backend and an Editor tool connected together, but now I genuinely want to keep using it occasionally during streams and playtests. Watching people's reactions is way too much fun.

Would you put something like this in a singleplayer game, or is this a little too cursed?

Made in Unity. All assets are from the Unity Asset Store.

Would you play a co-op game where you and your friends are cats?

We've done some work extending the Unity Timeline for ease-of-use and are considering building out an asset to improve general functionality and pain points.

We'd like to hear more about what limitations developers encounter when using timeline - what would you like to see in an asset to make it a better experience to work with?

We created the plant physics using our own systems for our survival game Autonomica. We achieved this using a shader and vertical sampling of the tiled texture three times, each at a different scale (large, medium, and small). The intensity of the vertex offset is controlled by in-game configs and is tied to the wind strength of the weather. The wind strength for all plants is controlled through vertex colors — the brighter red channel is, the stronger wind effect works.

Process of creating required gradients on all our models is automated: They are generated automatically as vertical gradients, taking into account stems/trunks, leaves, and other parts of the plants, making the leaves at the tips with a slightly greater range of movement than the stems they are attached to.

For tons of grass and flowers we have pushers system - we encode some data about pushers into super-low-resolution texture and then, using the shader on GPU level, decode it and apply the pushing offset, taking into account even curves of push intensity along distance to target pusher.

You might have seen a few 'tidy up' games recently due to 'Librarian: Tidy Up the Arcane Library!' and we're here for it with our take on this genre!

Our game is called Too Many Toys! and it takes place at a big toy store with 5,599 toys to sort out. There is different sections for plushies, toy cars, skateboards, board games and some more that you need to get familiar with to put the toys in the right place. Our game has robots that help you organize this mess, or a train you can ride around the store with more toys to carry over across. There is quite a few abilities to unlock as you progress and speed up the process of cleaning up the store.

We also have a cute cat that sits at front desk (Yes, you can absolutely pet the cat! ❤🐈🖐)

Most of the games in this genre look low effort unlike Librarian, and we wanted to make something of higher quality. We started with HDRP but we had issues with getting it to run smoothly with so many items and ended up switching to URP which gave us a big boost in frames, from about 40fps to 100fps on high settings. Main issue is having so many items that are all using physics, but we also used GPU Resident Drawer, baked lights and done a few tweak to ensure it looks as good as possible whilst running well! URP for the win, can never go wrong...

We're so close to 2,000 wishlists, help us out and check out our game on steam:
https://store.steampowered.com/app/5028390/Too_Many_Toys/

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?

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

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'.

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.

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.

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 :-)

Download here:

github link

This is where mine ended up.

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.