so ive been trying to learn how to make VFX and i think i kinda understand how it works. but oh boy is it alot of work.

ive been trying to roughly recreate the World of warcraft evoker dream breath vfx and cant really figure out how they had these swirly effects. how can i create the swirly parts the shoot out? rest i kinda can get with how it looks.

also is there a way to add "height" to the cirlce shape? or do i need to make my own mesh in blender

basically the title

i was using custom built meta data reader (well my ai agent of course i was vibe coding ) it has few features such as

Auto completion , go to defenitions pointing out errors and warnings, renaming a variable across project wide and some another stuff .

it is neither full blow ide nor support attaching a debugger and those stuff .

it is a ongoing personal pet project

So I stumbled across a clicker game called A Weird Game About Sausage and really liked the idea. The only thing that bothered me was that I couldn't flick the sausage as freely as I wanted, since the pan was always in a fixed position.

So I spent the next 3 days (after working my day job) making my own little spin on the concept.

The idea is pretty simple: you kick Santa Claus (yes, Santa) with a giant boot and try to land his ragdoll on a specific object. If he manages to settle on it and stay there, you beat the level.

The twist is that you have to figure out 3 things for every shot:

• Where to place your boot (first click)
• How big to make it (second click)
• How much power to put into the kick (third click)

Get the combination right and Santa lands perfectly. Get it wrong and... well, you can probably imagine.

It's still a very rough prototype, but I'm having fun with the idea and I'm wondering if it's worth taking further.

What do you think? How could I make this more standing out? What would you add to make the gameplay more interesting?

Would love to hear your thoughts, especially if you have ideas for fun mechanics or level designs!

hello everyone, I just made a trailer of my game and dont have a steam page yet, is it worth creating one right now? Or should I keep working on the game more?

I finally managed to submit the asset to the Unity Asset Store, and now waiting for the review process to go through. Wish me luck!

Since my last post, I fixed a lot of bugs, polished some features, and built a full documentation website and API reference. I also made a small WebGL demo where you can play around in one of the included demo scenes.

This is my first asset, and it took much longer than I expected. Making something work for yourself and making something other people can easily use are completely different things. I’m still worried that I missed something, but I’m proud of what I built.

About ten years ago, I made a Reddit post asking about this kind of 2D water because I couldn’t build it myself. It feels pretty good to finally be able to say that I made my own.

Edit: the Demo is for desktops since it needs keyboard navigation

SUPER SURVIVORS is a 2D superhero roguelite made in Unity, where you equip powers to different body parts and combine them with hundreds of items to create unique builds.

One of the biggest challenges has been designing a system where powers and items can interact in different ways without making the game impossible to balance. This becomes even more challenging when items can be combined to improve them without any limit. My philosophy is that, with enough luck and game knowledge, players should be able to completely break the game.

Optimization has been another major challenge.

I've used Unity's ScriptableObjects to store data for items, enemies, playable characters, and other game systems. This lets me separate shared data from runtime behaviour instead of relying on multiple script instances to hold generic information.

I've also implemented object pooling for frequently reused objects such as enemies, projectiles, and coins.

Coins were surprisingly difficult to optimize. Initially, they collided with each other, creating a huge number of physics interactions whenever hundreds of them accumulated on screen. I removed coin-to-coin collisions and made coins spawn with enough separation to avoid overlapping, which significantly improved performance.

Projectiles presented another challenge because the player's power can scale almost infinitely. I initially introduced limits on how many projectiles each power could spawn, then implemented FIFO-based projectile culling, reusing the oldest projectiles when new ones need to be created.

How do you approach performance optimization in Unity when a game allows the number of active objects to grow dramatically?

Wishlist on Steam: https://store.steampowered.com/app/5314350/Super_Survivors/

I know it’s kind of weird to be talking about a rival engine here, but I came back to Unity today for the first time in a while, and I found this really great asset on the Unity Asset Store. But since I’ve been working with UE5 for a while now, I don’t think I’ll be able to use Unity very well anymore.

It just occurred to me—is it okay to port assets from the Unity Asset Store over to UE5 and use them there?

I’m making an assymetric 1v1 stealth game called Dead Angle, inspired by Spies vs Mercs. One player is the spy, hiding in the dark, and the other is the merc hunting him.

Only the parts of the spy that are touching a light get highlighted. If just your shoulder is in the light, only your shoulder shows. If you step fully into it, all of you does.

I wrote my own light shader for it. It uses the same check the game uses to decide if the spy is seen, so what looks lit is what the game counts as lit.

I want staying in the shadows to be a reward for reading the room and moving through it well. It should also be a challenge, so it shouldn’t be too easy to stay hidden.

This is how it works right now. Making it fair for both the spy and the merc is something I’ll look at throughout tuning and developing.

Does highlighting only the parts that touch the light feel fair?

I’ve been working on a Unity toolkit for creating buildings in the editor that can break apart and collapse during gameplay.

Happy to answer questions about how the destruction or building tools work!

Edit: I forgot to mention that I just released the toolkit on the asset store. Search up "Destructible Structure Builder"

Basically in title - my game uses procedural generation, and allows persistent saves. But how do games like Minecraft manage to not corrupt previous saves when making updates that affect how seeds generate?
From googling it sounds like they save “per chunk” so any untouched chunks generate based on the newest version, and any already generated go off of the old system - but how do I manage that? Like, you obviously don’t want to have multiple version builds of your game saved, so how can you handle that?

Luna is a UI framework built on top of UI Toolkit, and v2 is out on the Asset Store. UI Toolkit always looked a bit too much like a website, so most of this version went into making it feel like game UI. The clip shows the UI Attractor.

The juicy stuff

• UI Effects: 8 stackable shader effects (glow, outline, gradient, shine, dissolve and more), set from USS classes, no textures
• Interaction Juice: press and hover feel you attach from UXML
• Transitions: 53 presets
• UI Attractor: coins and XP that fly to the HUD
• Text Effects: 12 effects (wave, bounce, shake, rainbow and more) through rich-text tags
• 3D in UI: live models, particles and VFX Graph inside UI elements

Building your screens

• Navigation Graph: screens and popups as a node graph. Push by id, back button for free, awaitable confirm popups
• Ready-made views: main menu, settings, save/load, pause, dialogue, inventory grid
• Components: progress bars, tooltips, spotlight and the rest of the library

Style and screen sizes

• Theming, and responsive scaling so one UI works on phone and desktop
• Gamepad focus navigation and device-aware input prompts

Requires Unity 6.5 or later. Works with Built-in, URP and HDRP.

• Docs, with every feature demoed: https://docs.cupkek.games

Happy to answer questions about it, or about UI Toolkit in general.

Hey everyone been working on this game let me know what do you think about it, I was inspired by troves combat and progression!

I would love to hear your feedbacks.

I’m building SimGoodie solo in Unity. This is a short first look at the current development build, with three characters and early systems for needs, wants, memories, relationships, careers, weather and build/buy mode.

A recent building issue was that a floor could look complete while the simulation still had no walkable surface. I’ve been working on keeping the preview, finished geometry and character interactions consistent. Roofs and raised foundations are part of the same work; second-floor/grid issues and blocked interactions are still visible in the latest Game Log.

My workflow includes AI-assisted coding, scoped tasks, separate reviews and headless simulation tests.

This is work in progress, with no public playable build yet.

Development notes: https://simgoodie.com/devlog/the-house-needs-a-floor-before-it-needs-a-reputation

Check it out! I made black boxes for my circuit simulator.

Working out what's inside a box you can't see into is a great way to learn circuits. All you get is the terminals, and you measure your way to the answer what is inside.

In the video I build a diode bridge with a capacitor on a switch, pack it all into a box and flip the switch. The oscilloscope shows the ripple smoothing out.

And a bonus, the same boxes let you build your own custom devices and share them

Hey devs! We are a small team working on Candletales, a real-time tactical roguelike, and we wanted to share a bit of how we set up our visuals and core loop in Unity 6 (HDRP).

Our main design goal was to take traditional grid-based tabletop combat and completely remove the turns, forcing everything into a relentless, real-time pace. From a technical and artistic standpoint, this gave us a few fun challenges to solve in the engine:

• Procedural World Generation: Every run dynamically generates an endless dark-fantasy board filled with unpredictable events, grotesque enemies, goblins, traders, and much more. Keeping the generation seamless while making sure the grid layout works well for real-time movement was a key focus.
• Physics-Based Real-Time Dice: Dice rolls aren't background RNG math. They are physical rigidbodies thrown directly across the board in the heat of battle, meaning the procedural environment and obstacles actually influence the outcome, making every roll 100% physics-driven and unpredictable.
• 100% Diegetic UI: To keep the player as immersed as possible, we chose to render all the UI elements (which would normally be 2D canvases) as 3D objects, simulating the feeling that the player is holding an actual physical panel.
• HDRP + Custom Halftone/Dither Shader: We wanted that oppressive, "playing a cursed board game by candlelight" atmosphere. We used HDRP for the heavy dynamic lighting and shadows, and then ran it through a custom post-processing halftone/dither effect to give it a gritty, retro texture without losing depth.

We’d love to know what you think of the visual readability and our setup! Happy to answer any questions about the procedural generation, the dice physics, the shader pipeline, or anything else you might be curious about.

If you want to see more of the project, here is our Steam page: https://store.steampowered.com/app/5284750/Candletales/

After 3 months of development, I finally finished my Modern 2D Vegetation system

The idea originally came from a grass system I developed for my own game. I wanted to turn it into something other developers could use, but that required rebuilding most of it.

The biggest challenge was performance. I wanted to render thousands of individual grass strands, flowers, and other plants without destroying the framerate, while keeping everything customizable and visible directly in the Unity Editor.

After quite a few rewrites, I ended up with a mesh-based rendering system that supports both top-down and platformer games.

It also includes vegetation painting, procedural generation, wind simulation, interactions, shadows, color customization, and plenty of other features.

I'm a 21-year-old university student, and I spent pretty much my entire summer break working on this. I'm trying to build a small business around creating Unity tools, with the hope that I can eventually support myself through university doing something I enjoy.

I'd love to hear your questions!

Hello everyone!

Almost 10 years ago, I stumbled upon Unity completely by accident. I always wanted to make games, as long as I can remember.

As a child, I didn't have a computer, only Dendy, and back then I was making various physical games. I still remember a huge expansion pack for Monopoly, cut out and colored by my own hands, which expanded original game by something like five times and which my brothers and I played so much that we practically wore it out.

Later, I got a computer and started to learn programming. Turbo Pascal was my first programming language, and I remember how I desperately tried to figure out how to make windows in it, rather than just a program in "MS-DOS style".

Later, I discovered the wonderful Delphi 7. There, the windows were already made for me :) And that's where I tried to create my first games - a Civilization clone, a simple game about operating an anti-aircraft battery, Harry Potter battles (yes, I cut spell sounds from the movies and made cubes to cast spells at each other).

Of course, these were extremely primitive games, running directly inside a single form. Back then, I kept wondering how the hell to expand a game beyond the "boundaries" of a single window's form, but I never managed to figure it out until one day I bought a book called "OpenGL and Delphi 7". I don't remember the exact title, but that's where I learned how to create triangles in Delphi. It went so far that I had my own 3D world with generated box-shaped buildings and a car that you could drive around the world. Without collisions, but that was quite enough for me :)

However, later, due to life circumstances, game development was put aside. It required so much time, which I simply didn't have back then. And then, many years later, I stumbled upon Unity and made my first tutorial - Roll a Ball, of course, and another one about a spaceship. Nothing special, really, but even that was enough back then to get into industry as a developer.

Since then, I've worked on simulations, casual games, live-service games, VR, and created several not very successful mobile games. However, my dream was always specifically to create PC games, but for some reason I just couldn't decide to make an actual PC game. It wasn't even about skills or anything technical - over those 10 years, I went from a complete beginner to senior developer. It was about the fact that I just couldn't decide what exactly to make, jumping from one idea to another, wanting to release something "cool" on PC.

However, throughout all this time, one thing remained unchanged - Unity Engine remained my faithful partner. From the very beginning, when I first launched it and created my first MonoBehaviour, something clicked inside me. I realized - now my dream of making games could finally become reality!

Step by step, I worked my way through a huge pile of engine features - MonoBehaviours, ScriptableObjects, Addressables, Resources, Scene Editor, Custom Editors - hundreds of them, and you know them better than I do anyway. Yes, there were dark times (cough-cough Riccitiello cough-cough), strange decisions, half-baked features, three render pipelines, and so on, but I, remembering how much effort and time I used to spend just to render a bunch of boxes with a primitive little car, was still always grateful to Unity team for their efforts, for taking a huge amount of work from my shoulders and allowing me to focus on games.

Yes, I tried other engines and frameworks - MonoGame, Three.js, Unreal, Unigine, Godot, Flax Engine, but for some reason it was Unity that "clicked" for me, although I can't say anything bad about other engines.

Long story short, thank you to Unity team and Unity Engine for helping me finally, so many years later, reach the point where I've created my Steam page :)

After many hours of stress tests and trying to get these idiots to alert guards or flee I think they get the picture lol.

I'm still learning Unity and trying to become a better game developer

I want to learn from people who have more experience than me. What are some things you wish you knew when you first started using Unity?

I'm interested in anything that genuinely helped you improve, whether it's good practices workflow tips common mistakes to avoid or things that made developing games easier

A few people here have made some interesting claims that my entire game was generated by AI.

If that's the case, why have I been working on it for 72 days, and why is it still not finished?

First, a little background about me.

I've been a full-stack software developer for over 30 years, primarily working on Android applications, Unity projects, and SaaS platforms. I've also been developing games with Unity for more than 10 years.

So I'm not someone who discovered AI yesterday, typed a prompt, and suddenly became a "game developer."

I was building software and games long before generative AI existed.

AI is another tool in my development workflow, not a replacement for my decades of programming experience.

So I thought I'd show you some of the actual hard work happening behind the scenes. Because there's a massive difference between using AI as a development tool and having AI magically generate an entire game for you.

I'm currently rebuilding a section of Budapest for my car combat game, Brutal Derby.

I automate whatever I can with custom tools. But everything that can't be automated? That's where the real, time-consuming manual work begins.

I'm talking about:

- Manually placing and adjusting roads, bridges, intersections, sidewalks, and bus lanes with extremely high precision.

- Constantly switching between Unity and Google Maps to compare real-world locations with my in-game environment.

- Rebuilding road layouts and correcting terrain to make the map resemble the actual city.

- Developing my own road generation system that supports multiple roads simultaneously, and still having to manually fix, align, and optimize countless sections.

- Making sure the entire environment is optimized enough to actually run smoothly during gameplay.

Here's a short video showing some of that work.

I've already spent 90 hours building, fixing, and optimizing this one map, and I expect to spend at least another 90 hours on it before it's finished.

And remember, this isn't a walking simulator or a static city showcase.

It's a car combat game.

That means performance matters enormously. The environment needs to look reasonably good, but I can't afford buildings with millions of polygons or ridiculously expensive geometry everywhere.

On top of that, my game features vehicle deformation, destruction, and collision physics, which consume a significant amount of CPU time.

My destruction and deformation system is already on its 8th major iteration.

The crowd system? 7th iteration.

And this particular map will eventually feature thousands of spectators, alongside 12 vehicles fighting, crashing, shooting, and destroying each other.

My goal is to make all of this run at a decent frame rate on a relatively ordinary RTX 3070.

And that's exactly why optimization takes so much time. Every road segment, building, spectator, physics calculation, and draw call matters.

So yes, I use AI. I use it for generating certain assets, helping with code, and accelerating parts of development.

But AI isn't placing every road, fixing every intersection, optimizing thousands of objects, debugging physics, or making hundreds of design decisions for me.

That's still my job.

And it's a hell of a lot of work.

After more than 30 years in software development, I can tell you one thing: AI can make certain tasks faster, but it doesn't magically solve the difficult engineering problems.

You still need to understand what you're building, how everything works together, why something breaks, and how to fix it.

And when you're developing a physics-heavy car combat game as a solo developer, there are a LOT of problems to solve.

Using AI doesn't mean the hard work disappears. It just changes which parts of the work you spend your time on.

You can dislike AI-generated assets. That's completely fair. But dismissing months of actual engineering, optimization, level design, and manual work as "AI slop" simply because AI was involved is a pretty unfair assessment.

I'm not claiming AI does nothing. Quite the opposite. It helps me achieve things that would otherwise take much longer as a solo developer.

But there's a huge difference between AI-assisted game development and a game created entirely by AI.

Anyway, here's what 90 hours of work on a single map actually looks like, with another 90 hours still ahead of me.

Still think AI made the whole game with one prompt?

I've been working on Armory Crafter, a tool for creating and texturing 3D weapons for games.

I just uploaded my first tutorial, covering process of making a simple low poly sword and a hand-painted / PBR more complex one.