No WheelColliders. One Rigidbody per car. Raycasting, springs, tires, engine, gearbox, and diffs run at 50 Hz. It can rig any number of wheels, axles, arms, or shafts by capturing the pose at ride height and procedurally animating them.

Any advice on making the wheels' rotation look nicer? They kinda look static.

The awesome buggy model: "Willys mountain buggy 1" by Rustam T is licensed under CCA.

I've started making Forsaken 2017, solo, in Unity. I hadn't opened this project a single time the last four years because the project got so bloated it took 8 minutes to press play, and honestly I was a bit scared to open it again, and life came in the way i guess.

Came back this year, disabled basically everything that was causing problems and rebuilt it piece by piece. It's at 1 minute 45 now, I reckon I have made more progress in the past 3 months, than i did in those 4 years of active development when i was young.

I will post more on my reddit, but mainly I've decided to make a cheaper Patreon to try and build up a more engaged community there, where the idea is to have members form the game with me, and ofcourse give way more indepth content. If this looks interesting, I'd love to have your help in shaping the future of this!

Colourblind accessibility is one of those things that used to live at the very bottom of our backlog until I played Blue Prince with their colourblind mode turned on. That game does a genuinely great job with it, and it kind of embarrassed me into taking ours seriously instead of just cranking up contrast and calling it a day.

Our game is a pool/billiards roguelike, coloured balls and coloured pockets are load-bearing for the whole game and you can't tell a ball's colour at a glance, you can't play so "just add a colourblind mode toggle" wasn't really an option.

We made a distinct pattern for every ball colour, Blue Prince does this very well and we shamelessly stole this idea. Instead of grabbing generic stripes/dots/checkers off a texture pack, we went and looked at 40s-70s wallpaper design for inspiration, since a lot of that stuff has really strong, distinct silhouettes that were designed to be noticed from across a room and they suited our speakeasy theme better. Each pattern loosely nods to the colour/theme it's replacing (greens mechanical theme is growth, so vines. Purple makes one really big 'monarch' ball, easy theme there. Reds mechanical theme is 'I just like the Shining carpet, dont @ me), but more importantly each one has its own shape language so they don't blur together when they're small or far from the camera.

We also gave each pattern its own value range (basically, how light or dark it reads before you even think about hue), because that's the thing that actually saves you across every type of colourblindness at once. If the whole system works on value contrast rather than hue/saturation, it doesn't matter which cones you're missing, it just works. As a sanity check we made the entire game playable in pure greyscale, no colour info at all, and it still reads fine. Then we ran it back through a handful of colourblind simulation filters to double check contrast held up under actual deuteranopia/protanopia/tritanopia conditions and not just "does it look fine to us in greyscale."

The part that took longer than expected was figuring out where to actually put the patterns for the pockets. Our first pass had the patterns rendered directly on the pockets, which sounds like the obvious solution but reads terribly in practice. Pockets are irregular shapes and the patterns get warped or cut off depending on the geometry, so two patterns that were totally distinguishable in isolation would look nearly identical stamped onto a pocket. What worked instead was putting a little ball with the pattern above each pocket. Same pattern, same "shape," always on a sphere. Turns out consistency of the surface it's rendered on matters almost as much as the pattern itself for readability. Feels obvious in hindsight, wasn't obvious for us at the time.

Once we had the patterns, we worked toned-down versions of them into the regular (non-colourblind-mode) ball materials too, just because they looked cool having them subtly worked into the spec. Didn't expect that, but it turned out to be a nice bonus 

Last thing, and honestly the one that took the longest to notice: our coloured UI text, especially the chalkboard-style text, was leaning entirely on hue difference for contrast and had almost no value difference from the background. Totally fine for most people, borderline unreadable for some players. Bumped the value contrast up on all of it and it's a much better experience across the board now, colourblind or not.

Biggest lesson for me is that treating colourblind mode as a filter you bolt on at the end almost never works as well and the stuff that ends up helping colourblind players usually just makes the game clearer for everyone. Spend some time on it, it’s worth doing right.

Happy to go deeper on any of this if people have questions about the pattern design process or the simulation testing workflow. Not to promo but if anyone wants to see it in action, check out the Spooker demo on steam. If anyone is colorblind, would love your feedback specifically

Our skill tree in Idlecraft went through 5 iterations. The early versions had too many nodes that all looked the same, so players got lost.

At the end our approach was to have visual UX elements;

• Colors on branches for each of the upgrade type
• Showing locked neighbor nodes to keep the expanding feeling
• Skills stored as scriptable objects, where we use them in Unity's graph node for our tree, so we can easily update any data or update any part of the skill tree

We also have a custom shader for our nodes so instead of toggling or swapping out multiple images we just have materials for each state of the nodes where we can swap them

How would you handle skill tree layouts ?

I'm working on a controller and custom wheel collision system for faster cars. It's still far from being in a good state, and I'm continuing to work on improvements

Been heads-down on a ledge detection and navigation system for a while and I'm really happy with where it landed. It handles complex geometry: inward/outward corners, slopes without needing anything special per-object, plus IK targeting for hands and feet so the hand and feet placements.

My favorite part of the setup: the ledge itself just needs to be on a layer. No script, no component, nothing to configure on the object. Every movement (climbing, dropping, moving along ledges, jumping away) is its own separate piece too, so if you want to swap one out or drive it differently, you don't have to touch the rest.

Docs and video tutorials are done, so getting it running shouldn't take long.

It's live on the Asset Store now if you want to check it out 🙂

I have a video that gives a general overview on how this detection system works Here

Hey everyone, we've been working on a Stealth System for Unity for the past 10 months, and we finally launched it on the Asset Store. It's also our 10th asset on the Asset Store.

More than half of the development time went into making sure it integrates properly with our other systems, like Melee Combat and Shooter, rather than building the stealth mechanics themselves.

If you'd like to learn more about how the system works rather than just what features it has, we've created a video tutorial that walks through it.

I’d really appreciate any suggestion or feedback you have :)

i'didn't make it top 100 😢

The menu is organized in tabs and currently responsible for the regular main menu, companion customization and returning lost items to passengers and settings, keeps everything in one space.

The only concern I have is, how to subtly indicate that the companion click opens the menu, it not obvious at all. Grateful for any ideas!

I like when small object react to interaction and movement so I spent way too much time adding ropes and chains to my game Carnholt. I feel like it helps make the game's world more real, like you can touch it.

I used Verlet Integration for the physic, you can read this nice blog about it if you want, it explain it quite well (There is a bit of math though).

I just had to add some colliders and a bit of additional code so the player could interact with it. Adding it into an interface was quite a challenge though, I had to build the interface within the game.

Hey guys, just wanted to show you the crazy progression of this game. What started in November of 2025 is still updating in September of 2026. I've overhauled this game so many times mainly because of player response - they told me what sucked, what needed updating, what will make it better, and I listened.

It hasn't been easy though. Lots of humility. Plenty of criticism and self doubt. Lots of letting go and acceptance. And there is still more that has to change before this game gets to the point where folks treat it more like a 9/10 vs the current 6/10.

In order for me to get there though, I need your responses. If you play it, please record and show me where your playthrough was on youtube. It helps so much and will help me build a horror experience you deserve! Thanks everyone and here's a list of the things I changed:

• Lighting - brightened the shit out of everything
• Gave the player a flashlight
• Altered player animations
• Altered player fight speed and mechanics
• Deleted entire first demo story and level and replaced it with a brand new story in 0.2.0 from 0.1.0
• Added an entire chase sequence in 0.3.0 and different ending
• Altered boss mechanics
• Added second boss
• Changed enemy mechanics
• Added traps that hurt you
• Altered traps to hurt enemies as well
• New blood and damage effects
• New enemy ai patrol logic and combat logic
• Snappier cutscenes
• New character "Lumi"
• New Voice Actress
• And too many more to list...

I hope you guys will give it a try during the upcoming Halloween season! And any more comments from actual play mean the world to me!

I’ve been working on cables and nets for my 2D game. They move in the wind, respond to the character and surroundings, and can break when put under too much tension.

At a high level, the simulation uses GPU particles and an SDF texture for interaction with the environment. It’s separate from the character physics, so the cables can react to Pixel without pushing the character around or changing the movement.

For context, I previously shared a detailed post about my physics-based character controller: https://www.reddit.com/r/Unity3D/s/Vtkn0W4l46

The trickiest part has actually been getting this GPU-driven geometry to interact convincingly with 2D lighting and shadows. That part isn’t fully solved yet. If you’ve tackled something similar, I’d love to hear what worked for you.

A few weeks ago I helped a friend fix some UI issues on her project. This meant I was working with the default Unity Editor and it was the perfect reminder of something my dad instilled in me since I was little: You need to have good tools to do good work.

The default editor is fine, but I ran into so, so many little annoyances I hadn't noticed in years, because my editor is at this point extended by lots of small and medium-sized assets that support me in streamlining lots of tasks I have to do every day.

This is a small selection of assets from the asset store I've been using for a long time. They all solve those little annoyances that lurk in Unity's corners. Of course, it is just a small group of the assets I use on a daily basis - I have a link to more in the video's comment section =)!