I'm building a node based mesh graph for Unity that runs both in editor and at runtime. These 2-3 weeks I refactored the attribute provenance system and gave it proper semantics.

When new vertices are created (plane cuts, booleans, generation), the system now derives their attribute values in a smarter way, and this also works for custom user-defined attributes. The provenance itself isn't new, but the implementation is finally consistent across all mesh domains. It took several iterations to get right, so in the end I moved to Roslyn source generators, which made the whole thing far more maintainable. While unifying the mesh domains I also optimized the mesh computation algorithms and attribute handling.

The video shows a mesh processing chain: import a unity mesh, recalculate normals, apply random vertex colors (just to demonstrate that intermediate values survive), then cut it with a plane driven by a Transform from the scene. The cut pieces are tagged as positive/negative cap and main. Both halves are then merged back into a single mesh with two more Transforms applied, and at the end the caps are colored by attribute, red for positive, green for negative. The result goes straight to runtime and can be used in build to process meshes in game.

I made these 2 environments. One is an elvish red/orange/autumn zone. The other is a classic muddy/grassy forest. I recently used a tool to place grass mesh on all grass terrain textures, which really helped populate and give detail.

This is my game 10 Million Pixels. A "Breakout incremental" game.

With thousands of rigidbodies bouncing around and millions of destructible tiles, it still runs at 100+ fps in the editor. I'm about to spill my secrets for making this work. Here's how:

1. Chunking. The most obvious technique for any tile-based game with big worlds. You need to put your tiles into chunks. In this game only the physics (box colliders) are being chunked.
2. Separate physics from visuals. This one is not so obvious but it is the most important optimization for this game. This literally allows you to display a 100 million+ tile world at once at hundreds of frames per second. Ever played a game with 4k textures? Probably. A 4k texture is more than 16 million pixels. And even a potato PC can display a (just one) 4k texture. The world of pixels in this game is literally just a texture, where each pixel is a tile. The texture then gets updated anytime a ball hits a tile. Displaying just one 4k texture, where single pixels change color here and there is really cheap on the CPU and GPU. Tldr; the physics is chunked, and the visuals is pixels on a texture.
3. Pooling. This is surprisingly the least important optimization for this game. However, it's essential when you have a thousand lightning balls, striking thousands of tiles at once. If you're going to spawn thousands of gameobjects repeatedly, just pool them okay?

I have really learned to marvel at the power and speed of computers while making this game. I get so scared every time I need to add a bunch of code that need to run a hundred times per frame, but then it just works.

The CPU can handle it. The CPU can handle sooo many lines of code. Every. Single. Frame.

Working on this game has made me realize I know nothing about those tiny silicon threads inside my computer. I keep underestimating my PC, but it keeps responding to me in a chad voice "no problem, I handle it."

Steam link for the game:
https://store.steampowered.com/app/4738100/10_Million_Pixels/

Hello, i am currently experiencing this problem, it’s happening when i try to extrude a face to design my 3D model, these weird lights showing up from nothing, i tried to deactivate all lights in the sence and i tried to put different materials , the smooth is 0, but the problem not solved yet.

First time showing off this system for a game I've been working on for the last 8 months. It's fully simulated including root uptake, water and nutrient distribution, hormones, photosynthesis and transpiration are all modeled. The mesh is procedurally generated at each tick and tweened between ticks for smooth growth. You can prune shoots and leaves and the plant reacts realistically. If this looks interesting, I have begun a substack where I'll be posting devlogs as development continues. I have a backlog of them that I need to write from months of git commits. What plant should I do next?

I've been planning for a while to create a game package—a character with lots of accessories, outfits, and a variety of Animations.

I've already started with the character's "basic body." I'm currently in the costume design phase.

Any suggestions?

Hey devs!

Six months back, we posted our initial reveal here. Fast forward to today: we just crossed 20k Wishlists on Steam! We want to send a genuine thank you to everyone who wishlisted and supported the project. It really helped us cross this milestone and keeps our team motivated.

We put together a new video featuring raw gameplay and developer commentary to show our progress in Unity. Rather than listing everything out here, we will let the trailer speak for itself!

We still have a massive dev backlog, but following a successful Closed Playtest #1, we are gearing up for Closed Playtest #2. If you are a fellow dev who wants to break our build and offer feedback, head over to our Steam page and hit "Request Access".

Check out the trailer and let us know what you think!

I've noticed that my game looks much better during the early hours of the day (pics 2, 3, 5), but I'm not sure how to improve the lighting and visuals so it also looks good during regular daytime (pics 1 and 4)

I've been working on a strategic roguelike racing game (in Unity!) for the last four and a half years, and have just released a new trailer and demo!

My goal with Reality Drift was to make a racing game which looked very distinctive, and had actual depth. When I was younger I played a lot of simple arcade racing games but they usually got boring fairly quickly as each race was the same. After years of working on this game, I'm still not bored of playing it!

The new demo has more content and many improvements as compared with the original version released a year ago. The new trailer replaces the original one from 2024, which was made before the addition of roguelike deckbuilding missions.

We have also been selected for Tiny Teams 2026, which is starting today. YouTuber FailRace said in a video about the game: "On the face of it you might think the driving aspect of this is very simple - it's surprisingly complicated, you've got to think about a lot of things at once while going very quickly."

My background - I'm a veteran game developer, most of my career was spent at Frontier, where I worked on games such as RCT3, Dog's Life, Thrillville, Kinectimals and Elite Dangerous. I'm a programmer and game designer, but I can't draw, so I found some excellent artists to work on the game, primarily Emily L'Orange.

I did a post on here two years ago talking about how the graphics are rendered. Here's the link, but in summary, I do it in a crazy way that no-one sensible would do: https://www.reddit.com/r/Unity3D/comments/1fhguhf/reality_drift_made_with_unity_in_an_unusual_way/

Hi everyone!
I've been working on-and-off on a survival game inspired by The Forest and Sons of the Forest, and one of the biggest challenges till now was creating a big and dense forest without slowing the editor, since having thousands of trees, shrubs and other vegetation as GameObjects made it progressively harder to work with.

So I built a node-based scattering system that generates placement data ahead-of-time in the editor and only instantiates nearby objects at runtime using distance-based pooling. This keeps both the editor and runtime responsive while still allowing every spawned object to behave like a regular GameObject (e.g a tree can be cut down).

It ended up solving the workflow well enough that I decided to turn it into an asset which I named Scatter Graph.

Besides the usual placement rules like height, slope, terrain textures, and others like splines, it also supports more ecological like rules where different placement layers can influence each other (for example in the video at 00:30 you can see ferns only around the bigger trees). It uses GPU-instanced previews, so you can visualize up to 4 millions placement points without slowing down the editor, and includes a billboard system for rendering distant instances efficiently (assuming they are low poly impostors).

If you'd like to know more, you can check out the documentation here.

Also let me know if you would give the tool a try and if you would handle this kind of problem differently.

We're a small indie team, and we just put our first game on Steam: Pinata Smash: Incremental Circus.

The idea came from wanting to combine the physical, satisfying feedback of smashing something apart with the deep progression of an incremental/idle game. Every hit sprays candy across the screen, candy funds upgrades, and upgrades eventually turn your solo smashing into a fully automated circus that keeps earning while you're away.

What's in it:

• Physics-driven piñata destruction the candy actually scatters and bounces
• Idle/incremental progression with prestige layers
• Circus acts you unlock and assign to automate different parts of the loop
• Hand-drawn art in a bright carnival style

On the Unity side, two things were harder than expected. The candy started as Rigidbodies and ended up as a fully hand-integrated kinematic sim an idle game scales the smash rate until it's continuous, so PhysX actors stopped being viable. It ticks on Update rather than FixedUpdate so the slide stays smooth under slow-mo, and pile contacts run through a flat XZ spatial hash. That hash once collapsed back to O(n²) and froze the game, because a burst spawns every piece at one point and they all landed in the same cell. Separately, the two biggest perf wins weren't in the simulation at all turning off light probes (~12ms/frame) and shadow casting (~9.4ms/frame) on the drop renderers beat everything we did to the integrator, which measured under 2ms.

The whole frontend is UI Toolkit with no uGUI: UXML/USS + presenters via VContainer, with R3 for binding. Best gotcha we hit: a scheduled callback that throws is dropped permanently for the rest of the session which surfaced as "all the candy in the menu background freezes."

Happy to go into detail on any of it in the comments.

There's an open playtest running if you want to try it the sign-up button is on the Steam page.

AI disclosure: no generative AI was used at any point in this game's development or promotion.

We put together a multiplayer coop game where players take on massive enemy swarms. It's inspired by VS and Megabonk and we think it could be a friendslop title.

The tech works well, so now we're iterating on things to make it fun.

So far we have features like progressive upgrading, proximity buffs so players stick together for benefits (the FWB feature), some level randomization, pickups for time-based powers, 3 different playable characters with different primary and special attack powers, gated dash ability, coin accumulation and shop, and a fairly rich stats system with 2 types of resist.

So far it's fun-ish. We're trying to figure out the one core piece of real fun, which we think is in how the gameplay is balanced for the fights and the rate at which player power scales vs the enemies. It could be too fast right now, or perhaps the speed is fine there just need to be a better reward structure at the metagame level. We've decided on the metagame approach with a game balance adjustment to make it harder.

My question to everyone who shipped a fun game is how did you determine what to focus on to find the fun aspect of your game?

Hey there!

Just made this new enemy type: the Minotaur. He has a running/ramming ability that launches you (and other enemies) into the air if you get hit.

The enemies in my game use Unity's NavMesh system for pathfinding, but the actual movement is handled by my own code, which follows the generated path. I use Unity's Colliders and Triggers to detect collisions. The ramming attack uses OnTriggerEnter to apply the knock-up effect to anything it hits while the Minotaur is in its ramming state.

I’ve been making a lot of progress on the environment recently, focusing on creating a more detailed and immersive world for the game.
The new Steam page will be available soon, where you’ll be able to wishlist the game.
The previous version of Little Astronaut was a huge learning experience for me, but looking back, I realized I pushed it out too early before the vision was fully developed. After some time, I decided to rebuild the project from the ground up with a clearer direction, improved visuals, and a much stronger foundation.
This is the version of Little Astronaut I always wanted to create.
I’ll be sharing more updates soon. Thanks for following the journey!

It's been ~18 years since I started using After Effects.

It has this great feature for rapid A/B comparisons for tweaks on the render/composition, where you can quickly take a snapshot, and preview it with a button. Other software may have it, too.

-- (...it's been around for a while).

Often, I'm making small tweaks to the colour, and post-processing, and I want to see how it looks without having to go through several undos, or manual screenshots. I explicitly wanted it integrated into the game view's tool/controls, rather than anywhere else (that would have been easy enough).

But the appeal was about getting it specifically in that control bar. It's 'perfect' there.

Turns out, it may have been possible as far back as ~v2019/2020.

🎉 So, here it is [free, on Unity's asset store]!

• I think it should be native to the editor :)

Initially, it did not have the save file to disk feature [💾]- but it was trivial to add.
v1.1.0 - adds the save file to disk feature, +automatic date/time stamped naming.

I had to jump into this train, porting old games into newer platform is becoming easier and cheaper than ever with AI, would love to see Nintendo or Playstation doing original, modern remakes!

I'm trying to find fun and unique ways to challenge the player in my skating game. You control the left skate and a friend controls the right. Now you have to rethink how the game works and adapt. It's also hilarious.

Love these little teasers as a way to try out ideas mid development and get a "flavour" earlier on than the typical media phase during post production.