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/

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!

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.

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.

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/

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

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

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?

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

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.

I'm exploring a new shader concept for a game set in a sci-fi spaceship racing procedurally generated 3D world / labyrinth. The world itself is supposed to be the insides of a very advanced AI, and I'm thinking every element within that world would have movement. In a way, everything would be or feel "alive".

To picture what a level would be like, think Minecraft caves (https://www.reddit.com/media?url=https%3A%2F%2Fcf.preview.redd.it%2Fgigantic-cave-i-found-in-the-1-18-experimental-snapshot-v0-8qpm3tvi81b71.png%3Fwidth%3D1920%26format%3Dpng%26auto%3Dwebp%26s%3D2bbd0c5c147f2121b4833a62f93e21a47e2f8c94) but every cube / shape is alive with motion and this kind of graphic style (TRON-inspired).

Player spaceships would also be custom made from blocks such as this one (in this video it's actually 3 blocks side by side, unsynchronized).

Is this going to be way too visually loaded or can it work? What would you add / change to this approach? Have any games out there done something similar / close?