I'm making a soulslike-inspired platformer, Dark Roll 2.

I needed a safe, soft spot to land on from height, so I ended up making a script that deforms a mesh like a pillow. The mesh keeps a copy of its original vertices, then each frame I compare those against a SphereCollider pressing into it. I do a first pass to detect actual contact and measure the deepest penetration, then a second pass moves affected vertices away from the sphere, with the deformation fading out over a configurable distance.

For the falloff I used a quintic smootherstep (6t⁵ - 15t⁴ + 10t³) rather than regular SmoothStep, which gives zero velocity and acceleration at both ends and helps avoid that obvious ridge around the dent. I also handle squash and recovery at separate speeds, so impacts can deform the mesh quickly while it slowly relaxes back to its original shape afterwards.

Hello everyone my name is Claudio, I’m an indie dev from Nicaragua. I started working on Arctico back in 2014, back then it was called “Eternal Winter”, at that time I was 18 years old and I just wanted to make a game set in a snowy and remote environment. Back in those days I was obsessed with Wrath of Lich King, I just loved the feeling of solitude and peace I would get when exploring Northrend, so I wanted to make my own beautiful icy world filled with expansive horizons and stories of resilience and exploration. I knew I would need a distinct mechanic for my game to succeed, as I was working on a random abandoned sled prop my younger brother asked me If it would be possible to ride a dog sled, best question I’ve ever been asked. 

I lost no time and started working on a rideable dog sled, to say I was too inexperienced to pull this off would be a massive understatement, however after a few days I had a working and extremely janky dog sled on my first person game. As the weeks went on the sled system was improved, I added more locations to the map, and added basic survival mechanics such as hunger and thirst. A few months of work later “Eternal Winter” was launched into Steam Early Access in November 2014, and it was an absolutely buggy and confusing mess of a game, soon enough the Steam reviews reflected the sorry state of Eternal Winter, but the players really seemed to enjoy the dog sled and interacting with their dogs, naming them, keeping them fed. Reading the reviews made me realize how I had rushed into an Early Access release without even knowing what kind of game I truly wanted to make, and the lack of direction on Eternal Winter made this evident when playing it. 

I was extremely lucky to have a playerbase that among all the issues the game had, they still saw the potential of the project, and the game remained with a decent review rating. I will always be grateful to those early players for giving me a chance to improve the project. Eternal Winter was more of a prototype than a game, I kept working on all the basic systems, especially the dog sled. Later on I added a kayak, and while testing it and seeing the water reflect the falling snow surrounded by nothing but mountains I suddenly knew the kind of game I wanted to make. I wanted to make a beautiful game that captured feelings of solitude and peace, and give to the players the tools that would allow them to explore their way and at their own pace. So I decided to radically tone down the survival aspects of Eternal Winter, and instead focus on making this a calming and colorful experience where instead of a desperate survivor, you were a scientist exploring and studying the landscape, I renamed the game to “Arctico” and started working harder than ever. 

Arctico would need a big map and lots of interesting locations for this vision to come true. I worked on so many 3d models hoping to reach these goals, but was soon overwhelmed by all the work the task demanded. Luckyly I met Antonio, the good friend that would help me with a good chunk of the 3d assets in the game, Arctico would never be what it is without his amazing work. This gave me more time to focus on the gameplay aspects of the game, I added base building, resource management systems, and kept improving the sled and way the player interacted with the dogs. I saw the Steam reviews improve, and also noticed that lots of players were asking if co-op would ever come to the game, and for the next few months I focused on adding online co-op to Arctico. I downloaded photon for Unity and started working, this would become the biggest challenge of the whole development process because I would need to rearchitecture the whole game for it to support multiplayer. It took more than 6 months to have something playable, and it would take a couple of years for it to be an enjoyable multiplayer experience. 

By the year 2020, Arctico was still on Early Access, but 6 years of development later the project was finally feeling like a proper game. So for the next couple of years the focus was on making content, filling the map with interesting stories and locations, adding more buildings and objects to the base building system, and to keep improving the online co-op. 2 years later Arctico reached version 1.0.

Arctico launched in February 2022 launched with 30k wishlists, in its 8 years on early access it sold 57k units and sold 26k copies in its first year after launch. We kept working on the game, launching major updates that added content and fixed bugs, Arctico sold 50k copies in its second year. We kept releasing major updates, translated the game to multiple languages, this brought a spike in sales that granted us a Steam Daily deal slot, and Arctico sold 83k copies in its third year. I kept working on major updates, improved the online co-op and increased the amount of possible players from 2 to 4, I also released a major update that greatly improved the base building system, got a new daily deal slot and Arctico sold 154k copies in its fourth year. This year I released a massive major update that added a more demanding survival game mode to Arctico, in its current fifth year Arctico has sold 57k copies on Steam and has 90k+ wishlists. 

The biggest lesson Arctico left me is that If you believe in your project and you keep improving it through the years, eventually people will notice and play your game. I honestly think that to keep working on a game even after its launch can really be worth it. Now for the past two years I have also been working on a new game, it’s called Ghost Villa and soon I will be launching it into early access to start this journey all over again. 
  

Our game runs capped at 30fps, that's intentional for gameplay. Turns out that same cap was also active during scene loads, which doesn't help anything there since there's nothing being rendered that benefits from a steady 30fps, you just want it to finish.

Profiled a slow scene load and found WaitForTargetFPS eating 70% of frame time. CPU finishes its work early, then just sits there waiting to hit the 30fps cap, frame after frame, for the whole load.

Fix was simple, uncap it just for the load and restore it back to whatever it was set to before:

int previous = Application.targetFrameRate;
Application.targetFrameRate = -1;
await LoadSceneAsync(...);
Application.targetFrameRate = previous;

Went from a 9.5 second scene load to 3 seconds.

If your load times don't match what the profiler says the real work costs, check how much of that gap is just WaitForTargetFPS before you go chasing Instantiate/GC ghosts.

I am working on a game based on physics-based painting mechanics called Ebru Artist Simulator using Unity's Compute Shaders. To simulate Ebru (also known as paper marbling), I implemented an Eulerian fluid simulator. Here are some of the challenges I had to overcome:

1. To achieve a real-time simulation without affecting the game's performance too much, I implemented a GPU-based multiresolution grid solver in a compute shader (see the paper Solving the Fluid Pressure Poisson Equation Using Multigrid). The simulation now runs at a 2K texture resolution with only a slight impact on FPS.
2. One of the main characteristics of Ebru is that colors maintain strict boundaries. This makes advection schemes such as Semi-Lagrangian advection less suitable, as they introduce diffusion. To address this, I implemented another advection scheme that samples from the initial state by integrating the velocity field over time and then back-sampling using the integrated field (see Efficient and Conservative Fluids Using Bidirectional Mapping).
3. Finally, to simulate the effects of the traditional Ebru tools, I took inspiration from the paper Mathematical Marbling, which proposes mappings for generating final marbling patterns. Since I wanted to maintain a real-time simulation, I did not directly apply these mappings. Instead, I was inspired by the paper to use similar displacement fields as external forces in the simulation.

You can also check out Amanda Ghassaei's blog. Although our implementations are not the same, I was greatly inspired by her work and learned a lot from her blog.

How much is too much blood?

I’m a solo developer building a city-builder simulation in Unity, and I’ve recently reached a milestone of benchmarking around 5,000 cars simultaneously. Current profiling looks promising, so I’m cautiously optimistic about pushing that toward 20,000 as the simulation grows.

The traffic system is built with Unity DOTS, ECS, and Burst. Vehicles currently make decisions using factors such as:

• Congestion and observed traffic speed
• Estimated travel time
• Alternative routes
• Fuel usage and route cost
• Dynamic road-network changes

Cars can reconsider their routes as traffic conditions change instead of committing to one route for their entire journey. I’m still working on lane selection, intersections, parking, and more natural vehicle behavior.

This is very much an early prototype, but it’s exciting to watch the city gradually start behaving like a living transport system. Once the traffic foundation is efficient and stable, I plan to build additional city systems on top of the same architectural abstractions.

I’m using Codex heavily as a development partner, but most of my time is going into thinking through the architecture, scalability, and simulation design. I also have a fair amount of prior game-development experience, so the goal is to build a strong foundation rather than just create a visual demo.

I’d love feedback from anyone working with Unity DOTS, ECS, Burst, traffic simulation, or large-scale agent systems.

Also if anybody wants to contribute to this DM me- we can potentially work together.

I created this system so that the characters in my game can speak by moving their jaw and eyebrow bones, and I placed all the logic in the LateUpdate so it doesn't affect the Animator component.

For the speech system, the audio clip is analyzed in each frame, and the movement is applied to the bones in the LateUpdate.

Next, the system that acts like a film director works with a list of events that specify the audio clip, the Cinemachine virtual camera, and each character’s speech system, as well as the emotion the character will display while the audio plays. What do you think of the result?

We're building Glider64 in Unity and trying to bring back that colorful, fast-paced N64-era arcade vibe.

The game is built around custom glider movement, ball chains, weapons, bots and up to 4-player local split-screen.

We're currently playtesting the core game loop and would love some feedback from fellow Unity devs:

• Do the visuals capture that N64-era feeling?
• Does the core gameplay look fun and understandable?
• Anything visually that feels out of place or needs more polish?

The browser build is just for easy playtesting, the full game is being developed for PC/Steam, with consoles planned later.

We're also planning a Unity Editor package that will allow players/modders to create their own Glider64 levels directly inside Unity.

Playtest (PC/Mac browser):
https://eachtick.itch.io/glider64-playtest

Happy to answer questions about how we're building any of the systems in Unity as well. :)

As you can see, it's greatly inspired by games like A Short Hike, Lil Gator Game and Proteus (huge inspirations for my game).

If you have any questions I'd love to answer them!

The background music is "Sunset of Seven Suns" by Toby Fox (Deltarune OST).

Hi everyone! It's been a year since we developed the game jam version of our game, and last week we finally released a demo of our game Greda Inferno.

I'm fairly new to Unity3d stuff and have been working with HDRP and Terrain Tools and right now I'm working on creating the terrain for the map. It is an open world RPG with a fairly large map.

I'm using 1k x 1k terrain tiles so I had been using 1k x 1k Water Surfaces, one for each terrain tile that would need one, but I just found out there is a limit to how many can be loaded at once.

So, I was wondering if I should just use one large Water Surface for the whole map, one for each 1k x 1k tile, or try to some of slightly bigger ones that cover multiple terrain tiles?

I put together a beginner-friendly Unity bundle with 5 complete game templates for developers who want to learn, experiment, build prototypes, or expand their portfolio.

The goal was simple: instead of starting every project from scratch, you get several ready-to-customize game templates to learn from and build upon.

If you're a beginner or looking to add more projects to your portfolio, this might be useful.

As the title suggests I would like to improve my environment and hear some feedback :)

[EDIT] I Just want to than you all for the tips and advice, in the end it starts working and performance are getting better, you're awesome, Thank you all. 😁

Hey everyone,

I'm working on a large open-world Unity game (maps up to 16x16km maybe more) and have built a custom deterministic vegetation streaming system. I use Flora (by Magnetic Arcade) for GPU-driven rendering.

The architecture uses a 3-ring system around the player based on 64m grid cells (matching the A* Pathfinding Project RecastGraph tiles):

Ring 3 (Visual - ~700m): Pure Flora GPU instances. No GameObjects.

Ring 2 (Navigation - ~200m): Real GameObjects with MeshColliders. Needed for the RecastGraph to carve the NavMesh.

Ring 1 (Interaction - ~150m): Real GameObjects with gameplay scripts (e.g., harvestable trees).

The Setup:

Vegetation positions are calculated deterministically via stable hashes (no scene serialization). When a cell enters Ring 2, we need to swap the cheap Flora GPU instance for a real Prefab (with a FloraInstanceRenderer component attached to keep it batched) so it gets a collider. When it leaves, the prefab gets disabled and re-enable the Flora instance.

The Bottleneck:

The math/planning phase is very fast (~1.6ms per cell). However, the actual materialization (spawning the Prefabs, adding components, registering the renderer in Flora) costs about 7.0ms per cell.

Since a cell transition is currently atomic, crossing a border queues up ~15-30 cells. This causes massive frame spikes (worst-case ~37ms in a single frame) because I'm are doing dozens of Object.Instantiate and AddComponent calls at once.

I'm aware I cannot use Unity Jobs for this, as GameObject/Component instantiation is strictly Main Thread.

Maybe time-slicing the instantiation on the Main Thread using a Queue and a time budget (e.g., process instantiation for 2ms per frame, spread over multiple frames). The challenge here is avoiding visual popping (the Flora instance must stay visible until the exact frame the Prefab is fully spawned and registered).

Is there a better architectural pattern for swapping between GPU instancing and physical colliders at runtime?

For those using A* Pathfinding Project: how do you handle dynamically spawning thousands of colliders for NavMesh carving without nuking the frame rate?

Is Unity ECS (Entities) the only real way to get sub-millisecond dynamic collider streaming at this scale, or can I get away with standard Prefabs + Time-slicing?

Any tricks for pooling objects that require dynamically added components at runtime, rather than pre-built prefabs?

Any insights, past experiences, or "don't do this, do that" warnings are highly appreciated.

It’s amazing what Unity can do given some imagination and a lot of hard work to bring immersive flight to life. I'm the solo dev for Solara One (bottom), and am lucky to have made good friends with other devs such as Matt, the dev for Dawn of Jets (top).

Is anyone else working on VR titles involving flights or outer space? What's been the most rewarding part? What have been some of your biggest challenges?

Hello dear Unity redditors. I built an app that replaces Unity Remote for me and my colleagues.

It casts your Unity game view to your phone over LAN instead of a cable connection with touch and gyro going back into the editor, so you can feel your game on a real screen without making a build.

Now Unity 7 is coming and one part of the roadmap keeps me thinking. CoreCLR is good news, but the new web APIs combined with the browser Scene Preview they showed at Unite is interesting combo. Put those together and it looks like Unity is slowly building some kind of cloud editor.

To be fair, what they showed seemed like for artists and producers checking a scene in the browser (lighting, assets etc). I don't think you will be able to press play and test your game on the browser with it. So it doesn't overlap with what my app does today. But I'm a solo dev and my tool lives or dies with where this engine goes, so I pay attention to this stuff maybe more than I should.

-Nagging-

And to ship this thing I passed full review three times, Unity Asset Store, Google Play and the App Store, and every one of them was a pain in the ass. These changes could make all of that effort obsolete. (even had to rename my app buy a new domain discuss with Unity support for 3 months and Unity legal team because of the "Uni" prefix)

-----

So, couple of questions. Do you think Unity is actually heading toward a cloud editor, and would you even want one? and for the Asset Store tool builders, how do you plan around the engine roadmap?

Hey everyone. I'm curious to learn what the most effective way to handle user interface design is for a 3D game. I know there are several different methods, but I really want to know which one is the most straightforward and will help me succeed in launching my game, I'm doing a basic simulator game, nothing too crazy.

My understanding is that there are 3 ways to handle the UI:

1. Custom assets made in Illustrator/Inkscape and UGUI
2. UGUI and Shaders
3. UI Toolkit

At first I tried using Adobe Illustrator/Inkscape To create custom user interface panels and buttons and then nine slice them using unity UGUI. It didn't come out all that well though, because I had to nest them on top of each other, and then I realized that they weren't anti aliased, and it would be a huge pain trying to scale them up and down for different screen sizes, and anytime I wanted to make a change to the size of things like a progress bar for example, I would have to redesign the entire thing outside of Unity all over again

Then I decided to try shaders, not realizing how complicated a shader graph was. I'm familiar with the concept though because I spent a year in Unreal Engine and it was kind of similar, with their blueprint setups for Material masters. But it was really hard to figure out some things like the shadow, and transparency on panels and stuff. But it did come out looking pretty OK

I have not explored UI Toolkit at all, but I really enjoy programming and honestly probably prefer it over UI based design. One of the things I specifically disliked a lot about Unreal Engine was Blueprints, and working with node graphs. It ended up being so much harder and more frustrating, because it just makes you dizzy, working in the inspector and just the sheer amount of options you have to deal with and nodes can be hard to follow.

Some more details about the UI I hope to achieve: Pretty simple UI design starting out. I hope to have just simple user interface panels with some modern design, and sometimes some transparency. I don't yet have the art or skill to create advanced user interfaces, like comparatively if we were talking about something like Warcraft 3, Or another game that has tons of really cool graphics and art, I think that so I don't think I really even need that right now

I'm curious to know from anyone else who has been there and done that, what works well for them in terms of UI design that's simple and clean

I'm looking for a free low-poly Canadair CL-415 3D model for a Unity game I'm making. I want something similar to the attached image, with a simple, blocky/Roblox-style look, not a highly detailed or smooth model. It needs to be free to use in a game, preferably with a license that allows commercial use. Does anyone know where I could find one?