Last time I posted the giant 5400 piece stress test, this time I wanted to focus on how it actually feels to vacuum stuff up, since that’s like 80% of the game.

Things I’ve been tweaking:

• each piece shakes for a split second before it gets pulled, so it feels like it’s being ripped off the pile
• pieces fly in one after another instead of all at once
• every emits a sound, so a long stream sounds like a little scale
• each one sends a bump down the hose, and the tank on his back puffs up a bit when it lands
• the next few pieces in line get a thin outline so you can see what’s coming

I also turned the suction down a bit for this clip, at max upgrades it just turns into a firehose and you lose all the nice details (probably something I should polish).

The Last Kilowatt: build green power and take down Evil Corp. Overload a cable and it burns out.

A burn front runs from the failure point to both ends of the cable.

The cable swaps to prism segments that glow, char and crumble away.

Low-poly smoke puffs swell as they rise, with a little emission so they don't look like rocks.

HDR flames for bloom, plus a few point lights that travel with the fire.

What you think?

Spent the last few weeks on and off building a physics-based flight mount system for the flight sections in my game.
Heavily inspired by Game of Thrones' dragon movement so I'm using a Drogon model and Unity's free particles to block out the movement and fire breathing for the prototype.
The IK system, rig and controller are completely reusable for other winged creatures since it has adjustable weights, limbs and wingspans.
There is still a lot of refinement left to do on the spine, stability, impulses and camera framing but I'm quite happy with the general aerodynamics and sense of weight so far. :)

Mix of Life is strange and road 96 and pretty much achieve a decent light in unity 6. Need help on something what make fun in adventure game and other cool thing which make a adventure game immersive to player

Hey peeps,

Just wanted to showcase what I've been working on. I started the initial development back in 2017 but abandoned because I had other projects to take care of. I've revived it this year and reached a functional state.

I'd be happy if you could take your time and follow my socials, there's more videos.

Cheers! :D

Made this custom raymarched black hole shader for my game. It simulates gravitational lensing and has a fully adjustable accretion disk. Took this screenshot in game to use as the base for my games steam capsule art!

Hey everyone!

After more than eight months of development, and with your support along the way, my behaviour tree plugin, DODBT, has reached version 1.0.0.

I built it mainly for larger projects where game logic lives in separate C# systems, whether you use ECS or your own architecture.

There are two versions:

• DODBT-Dots: for Unity DOTS, with Burst and Jobs support.
• DODBT-Light: for other ECS frameworks or C# projects that keep game logic outside MonoBehaviours. It’s much lighter and has fewer restrictions than the DOTS version.

Both include a visual graph editor and runtime debugging, as shown in the video. DODBT-Light also supports dependency injection (DI).

Thanks to everyone who tried earlier versions and shared feedback. Your suggestions helped shape this release.

It’s FREE on GitHub: https://github.com/vadimburym/DODBT

If you give it a try, I’d love to hear how it works in your project!

A lot of people have asked how the procedural road generation in DRIFT RIDE 2 works, so here’s a quick breakdown of the current setup.

The route is built from 200-meter segments.

Each segment contains objects that can either deform together with the road or remain unchanged. I currently use several different base segment types, with variations in terrain shape and road layout. For example, one can be mostly flat, while another has a cliff on one side, and they can also use different numbers of traffic lanes.

Right now these base types are still fairly independent from each other, so they can’t always be mixed freely within the same run.

Additional environment objects are then placed on top. Each one can also be configured to deform with the road if needed, which is useful for larger objects, fences, guardrails, and anything else that needs to follow the terrain or road shape.

Some of the non-deforming objects go through a randomizer. It decides which ones are active on the next segment and how many of them appear, which adds variation without requiring every possible version to be built manually.

The actual road shape is controlled separately through a set of parameters. I can define ranges for horizontal turns, elevation changes, road irregularities, and how long each of those changes should last. These values are generated continuously as the route extends, which gives me a result that is random, but still predictable and controllable rather than completely chaotic.

Banking is handled separately in code and is added depending on the strength of the turn.

Each segment is also marked up for traffic. I only need to define the lane width, number of lanes, and their direction, and the traffic system can use that data on the generated route.

There is also a check that prevents the route from intersecting itself. Before the next segment is accepted, a box collider checks whether its direction would cause it to overlap with an already generated section. If an intersection is detected, that spline is rejected and a different one is generated instead.

The route keeps generating endlessly ahead of the player, while sections far enough behind are removed.

Some large background elements, such as distant mountains, aren’t generated as part of the road at all. I use an old trick from classic racing games, where distant scenery was often kept static. In my case, those background elements are attached to the skybox and kept at a fixed distance from the player, which creates the illusion that they are much farther away than they really are.

That’s roughly how it works right now.

One of the main things I’d like to improve next is the transition between different base types. Ideally, I want those transitions to be generated automatically at runtime, so segments with very different shapes could still connect smoothly. Eventually, even the base geometry itself could become procedural instead of relying on predefined meshes.

I’d also like to spend much more time on the environments. A lot of the current environment work was done fairly quickly because I’m building the whole project alone. In the future, I want to create more dedicated assets based on real references for different types of roads and locations, instead of trying to reuse a relatively small set of assets everywhere.

The attached video is from the latest version of the game.

I want to let the players in my game spam-click to fire a pistol faster. However, in order to do this, I have to figure out how to interrupt an animation with itself. Problem is, I can't figure out how to do that without turning off Exit Time, but if I turn of Exit Time, the firing animation plays on repeat (despite being a trigger). What do I do?

I was experimenting with ui toolkit for three days now, i made a little speedometer widget for my hobby game project, I'm a fan of persona 5 and i wanted to emulate a little bit of it's visual style, if you guys could give me some good critics on design i would really appreciate it, i'm not good at creating ui

Hello!

I am currently conducting research on the specific job tasks that are involved in developing VR training scenarios for law enforcement in Unity

I would like to know about the day-to-day responsibilities of people who design and develop these scenarios.

If anyone has experience with building these sorts scenarios, I would love to hear about the general job responsibilities, specific responsibilities, and KSAO’s involved with this sort of position.

Also if you are willing to let me ask you more specific questions about your day-to-day responsibilities, please let me know!

Thanks!

a tiny Unity editor tool. Fly around your Scene View,
and your Main Camera follows in real time, so what you see is exactlywhat the game sees.
Save any spot as a snapshot, and jump back to it later with a single click.
download from here

I used DOTween for the text animations to give it that 80s feel.

i was in the proccess of creating my juice tutorial , and needed some simple shader , suddenly created this effect!
its urp subsurface scattering , and tbh i really love it.
will throw the shader for free on assetstore , also my video is going to be ready and uploaded to yt channel very soon , stay tuned.

Given the latest events regarding games such as unity builds being decompiled, quickly remade by AI and posted to the steam store with almost a dozen duplicates or more, Ive started considering ways to introduce misleading content to trick any decompilation pipeline.

Has anyone given this any thought and would care to share on how to approach the subject? As through a quick research on the topic, Comments aren't retained and function names are questionable if there retained in full when decompiled. So ive considered things like "SafeModeStartup" intializers or even const string's with instructions to retain specific information to mislead something thats trying to remake the project in anyway. So if a recompiled project tries to start, it prefers the safemodestart and immediately fails.

Perhaps even, going so far back to copying valve with the infamous coconut.vtf from tf2, Where if it was deleted, The game just broke. (Not that it did really but yk) And just copying a similar strategy to that where maybe a specific asset or series of items need to be completed in a specific sequence to ensure proper start up and output misleading error messages to cause issues.

I don't know, im rambling now, Thoughts anyone? How would you try to approach this where it could weed out the cheap-flippers from using my own project against me to launch their own product with my own-code. This obviously won't stop one-trickers from having AI repeatedly just try to copy the product, But atleast then they had to spend a ton of tokens and time to produce it, Rather than using my product to push something fast.

I have N number of GameObjects running scripts, where they all interact with each other

Each of the N GameObjects are running their own Update methods and performing an interaction with another one of the N GameObjects

In the same frame, GameObject i and j could be interacting with GameObject k. A method called "interact"

i.interact(k);

j.interact(k);

Both methods access GameObject k at the beginning of the "interact" method

An issue is that sometimes, somewhere along the way into the method, i.interact(k); causes k to become null, and then suddenly j.interact(k); can't access GameObject k, even though it could at the beginning of the "interact" method

Do I need a Manager script that orchestrates the interactions between all of the N GameObjects?

Instead of each GameObject having it's own script where it calls interact in it's Update method, do I need to have a Manager run a for loop over all N GameObjects and call interact on each GameObject i?

It seems like a case of overengineering, and almost like running away from the benefits the Update method provides

Or am I missing some knowledge about the execution order of multiple Updates, and you could refer me to some video / documentation / resource where I can learn what I'm missing?

Is a Manager actually the only ideal solution here? Some other solution?

Thank you

A while ago, we started working on our own level design tool.

The idea was to keep everything non-destructive, so we could freely experiment with environments and change things without having to start over.

We also have sculpting and a layered material system, so there's quite a bit more to it than what we're showing here.

Lately, we've been focusing on metaballs, and we're pretty happy with how they're coming along!

Curious what you guys think!

Still pretty early in development, but the core gameplay is starting to come together. Been having a lot of fun experimenting with large enemy swarms and procedural generation.

What do you think of the atmosphere so far?

Hey everyone!

I'm working on a first-person game in Unity 6 and I'm trying to figure out the best way to handle entering and exiting a car.

Currently, the player can interact with the driver's door to enter the car and switch to a first-person view from the driver's seat. Interacting with the door again lets the player exit and return to walking around.

However, my current implementation has some bugs and feels like the wrong approach. The main issue is that the car needs to be stationary for the player to end up at the correct position. If the car moves while the player enters, the player's transform can end up at an outdated position.

What's the recommended way to implement this?

using TMPro;
using UnityEngine;
public class CarEntryController : MonoBehaviour
{
    [Header("Player")]
    [SerializeField] private Transform player;
    [SerializeField] private Camera playerCamera;
    [SerializeField] private CharacterController characterController;
    [SerializeField] private MonoBehaviour movementScript;


    [Header("Car")]
    [SerializeField] private Transform driverSeatPoint;
    [SerializeField] private Transform exitPoint;



    [Header("Car Systems")]
    [SerializeField] private CarPhysicsController carPhysicsController;
    [SerializeField] private CarHeadlightController carHeadlightController;



    [Header("Interaction")]
    [SerializeField] private PlayerInputHandler inputHandler;
    [SerializeField] private Collider driverDoorCollider;
    [SerializeField] private Collider interiorExitCollider;
    [SerializeField] private float interactionRange = 10f;
    [SerializeField] private LayerMask interactionLayers = ~0;


    [Header("Interaction UI")]
    [SerializeField] private GameObject interactionPrompt;
    [SerializeField] private TMP_Text interactionPromptText;


    public bool IsPlayerInside { get; private set; }



    private void Update()
    {
        if (playerCamera == null || inputHandler == null)
        {
            Debug.LogWarning(
                "CarEntryController: Player Camera or Input Handler is missing!",
                this
            );
            return;
        }


        UpdateInteractionPrompt();


        if (inputHandler.InteractPressed)
        {
            Debug.Log("E pressed - checking car interaction.", this);
            inputHandler.ConsumeInteract();


            if (IsPlayerInside)
            {
                Debug.Log("Player is inside the car. Checking exit door.", this);


                if (IsLookingAt(interiorExitCollider))
                    ExitCar();
                else
                    Debug.Log("Raycast is not hitting the interior exit collider.");
            }
            else
            {
                Debug.Log("Player is outside. Checking driver door.", this);


                if (IsLookingAt(driverDoorCollider))
                    EnterCar();
                else
                    Debug.Log("Raycast is not hitting the driver door collider.");
            }
        }
    }


    private void UpdateInteractionPrompt()
    {
        Collider target = IsPlayerInside
            ? interiorExitCollider
            : driverDoorCollider;


        bool canInteract = IsLookingAt(target);


        if (interactionPrompt != null)
            interactionPrompt.SetActive(canInteract);


        if (canInteract && interactionPromptText != null)
        {
            interactionPromptText.text = IsPlayerInside
                ? "[E] Exit Vehicle"
                : "[E] Enter Vehicle";
        }
    }



    private bool IsLookingAt(Collider target)
    {
        if (target == null)
            return false;


        Ray ray = new Ray(
            playerCamera.transform.position,
            playerCamera.transform.forward
        );


        if (Physics.Raycast(
            ray,
            out RaycastHit hit,
            interactionRange,
            interactionLayers,
            QueryTriggerInteraction.Collide))
        {
            return hit.collider == target ||
                   hit.collider.transform.IsChildOf(target.transform);
        }


        return false;
    }



    private void EnterCar()
    {
        if (player == null || driverSeatPoint == null)
            return;


        SetMovementEnabled(false);
        TeleportPlayer(driverSeatPoint);


        IsPlayerInside = true;


        //if (carPhysicsController != null)
        //carPhysicsController.SetDrivingEnabled(true);


        if (carHeadlightController != null)
            carHeadlightController.SetHeadlights(true);
    }




    private void ExitCar()
    {
        if (player == null || exitPoint == null)
            return;


        TeleportPlayer(exitPoint);
        IsPlayerInside = false;


        SetMovementEnabled(true);


        //if (carPhysicsController != null)
        //carPhysicsController.SetDrivingEnabled(false);


        if (carHeadlightController != null)
            carHeadlightController.SetHeadlights(false);
    }



    private void TeleportPlayer(Transform destination)
    {
        if (characterController != null)
            characterController.enabled = false;


        player.SetPositionAndRotation(
            destination.position,
            destination.rotation
        );


        if (characterController != null)
            characterController.enabled = true;
    }


    private void SetMovementEnabled(bool enabledState)
    {
        if (movementScript != null)
            movementScript.enabled = enabledState;
    }
}

We all start with humble beginnings and a game where you run around an open field for no reason. It’s not about where you come from, it’s where you end up!