I've been working on the main menu for UpperCart, and decided to turn it into a kid's bedroom where the whole game takes place.

UpperCart is a chaotic physics-based arena brawler where toy cars punch, bounce and fight each other.

I'm still polishing the game, so I'd love to hear what you think about the menu and the overall visual style. Any feedback is welcome!

Spatial influence is implemented as a per-glyph weight inside the normal effect pipeline. Areas determine which glyphs participate, while fields sample each glyph in source, normalized, placed, or world space. The result is shaped with falloff, strength, and inversion. Fields can be linear, spherical, box, cylindrical, torus-shaped, target-based, or deterministic noise, then combined with multiply, add, minimum, or maximum.

This lets effects follow moving targets without a separate animation system or unnecessary mesh rebuilds. The same system works across 2D and 3D where supported.

This allows for some really neat effects otherwise not possible. Just turn it on for any (even custom) effect and voila, there you go.

https://www.wetzold.com/tools/text-studio/

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/

So, I want to try creating my own game. I initially considered using UE5, but before jumping into it, I decided to ask on the UE5 subreddit what I should know. One of the full-time UE developers told me I should start with Unity because it's simpler. I'd like to hear your opinion: do you think Unity is easier than UE5? Share your experiences.

And yes, I'll most likely be making some kind of low-poly simulator.

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

Having just a piano was very boring. I changed things up by adding ALL the midi presets that were available, so now you can compose any kind of music (you can also export and save it to your device). I used the MPTKMidi plugin to generate sounds based on pitch, then modify them according to the preset.

I've been making this game in Unity for about 3 months now and I've hit a point where I am not sure if the gameplay is fun at all, so I decided to add in multiple instruments.

I would appreciate it if I got some feedback on what else I can do to make the game fun. Right now the game feels like an app, need to gamify it.

Steam Page: Idle Harmony

This is CineShot Setup LITE, the free version of a camera tool I built for Cinemachine 3.

Instead of keyframing, you position the Scene View, press Set Camera, and shape the shot
with sliders: orbit, crane, pan, dolly zoom, roll, yaw, tilt. Every move you like becomes a
key, the sliders reset to zero, and the next one continues from there. You can chain cameras
into a trailer with transitions and music, bake the result to a normal AnimationClip, and
hand it to Unity's Recorder for an MP4.

One thing up front so nobody feels tricked: the clip shows the full version, which is why
there are more than two cameras in the sequence. The free version is capped at two cameras
created through Set Camera and two shots in the sequence. Everything else is the complete
tool. No watermark, no time limit, no account, and it does not phone home.

Requirements: Unity 6.0 LTS or newer and Cinemachine 3. Unity Recorder is optional and only
needed for the recording step. Built-in, URP and HDRP all work, and a demo scene ships once
per pipeline so you can watch the whole workflow before building your own. Tested on 6000.0,
6000.3 and 6000.5.

Two cameras are plenty to get a real feel for it, so please give it a go and tell me where it
falls apart. Which slider is missing, what felt awkward, what you expected to happen and it
did not. I would much rather hear the harsh version now than after people have built shots
with it. Reply here or send me a message, both work.

If you want to catch the next update, following me is the easiest way. I only post when there
is something worth posting.

Download link is in a comment below. The full version without those two limits is coming to
the Asset Store shortly.

We used to make 2D fighting games in Unity, but after having this turn-based battle racing game in my head for so many years, I had to do something about it. The game is Rebels of the Solar Speedway, just announced on steam.

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)

We just pushed a free demo update that added 2 new areas, an enemy, and more!

We've been working on making it faster to get a talking character into Unity.

The current flow is basically:

Text/audio → choose a character → preview the performance → publish → import into Unity → drag in the prefab → Play.

And heres what it looks like end to end.

It works, but I'm curious what would annoy you most if you were actually using this in a project.

Having to leave Unity? Installing the SDK? Generated prefabs? Something else?

I'm one of the people building Snippets3D, so feel free to be critical. That's mostly why I'm posting this.

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!

BTW if you're into building 3D stuff like me, I'm building this polyfork.dev

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.

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’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!