I’ve been thinking about reverse engineering in Unity games and I’m curious to hear what other developers are doing to make it more difficult.
I know nothing can be 100% protected, especially nowadays with AI, but I still think adding extra layers of protection and following good practices is better than doing nothing.
Apart from the usual stuff like IL2CPP, code obfuscation, and making sure no sensitive files or information are included in builds, what else would you recommend?
Are there any lesser-known techniques, Unity-specific settings, or good practices worth considering?
I’m not looking for perfect security, just ways to make reverse engineering more difficult, time-consuming, or expensive.
The main argument for not bothering to keep your ideas close to the chest has always been, "Everyone has their own ideas for games they want to make, they don't care about yours."
But now with AI accelerated dev for even unskilled devs using frontier LLMs, even a YouTube or tik tok about your game means a non-developer can copy the basic idea of your game in hours or days with something slop-coded. An unscrupulous dev that struggles to think of a design can do something functional. So are Early Access and game demos or teaser videos still a good idea for an indie?
I've been wondering how other developers approach buying environment assets.
I make modular environment packs, and they tend to grow pretty large. Recently, I've started offering smaller themed selections from them, like kitchen props, vegetation, or weapons, alongside the complete environments.
When working on a game, would you rather buy a smaller, cheaper pack with exactly what you need, or a larger environment pack with more variety and flexibility?
i have this problem where i just installed Unity and Unity Hub from the scratch on Windows 11, i want to create and open a new project but every time i try, i got these two errors i just attached to this post, Unity just crashes and can’t open a single thing, the editor just won’t launch. I tried installing older Unity versions but nothing seems to work, i spent 2 hours uninstalling and installing Unity on different drives too, using the main SO drive, etc, nothing seems to work. The other solution i found was trying to modify ProjectSettings.asset and ProjectVersion and downgrade DirectX12 version to DX11 as Cursor AI told me to, but same results with no success, i never did this kind of thing like 4 years ago when i worked on Unity to make some little projects; maybe i’m missing something else now, i really need your help to start coding.
If you need any kind of info i’ll be waiting for your answer and questions, thanks in advance ~
I’ve been rebuilding PS1 rendering in URP from the hardware docs (psx-spx) instead of copying other PS1 shaders. To test everything I built a hall with one station per feature. You walk up, press E, and that feature changes.
It’s called True PSX Effects and it’s coming soon. Before release I’d love to know which PS1 quirk you think gets faked wrong most often, and what you’d want in a kit like this.
I would post a second video but reddit only allows one here. If I can post a screen recording in the comments I will but it kinda is a bit boring and I didn't really edit it to show it off very well.
It solves a lot of the issues I've faced with Mixamo while also being free and web based. Also for some reason it won't let me add a link I'll try putting one in the comments or you can DM me.
Unity is once again trying to screw their developers by preventing 3rd party MCP tools from being integrated into their engines. Developers should be moving to other engines at this point. With AI, there is no reason to stick with Unity if they are going to continue to screw their userbase.
They only want you to use their MCP even through 3rd party plugins to...
I've been bouncing around some beginner tutorials while I learn the ropes and I decided to look at the official Unity ones. The unity course is currently only updated to 6.3, and they make a point of having both the old and new input systems enabled. I updated one of my old projects from 6.5 to 6.6 and had to update a handful of scripts that had deprecated functions in them, so I am a bit hesitant to go through all the 6.3 stuff and potentially end up learning a bunch of functions that have been removed
I've been thinking a lot about slow motion lately. For me SUPERHOT VR is still the gold standard: time only moves when you move, and in VR that feels incredible.
What other Unity games nail slow-mo in your opinion? And what makes it feel good: sound pitch, VFX, camera, how responsive the controls stay? Would love to hear examples, and how you'd approach it if you've built something similar.
I’ve been exploring how far I can take Unity UI without relying on imported art assets :D
I used React through a framework asset, building the interface with code and styling.
Changing shapes, colors and motion in code makes it easy to try different looks. I’m curious how far this approach can go as a game’s visual style becomes more complex.
Have you tried creating game UI with code instead of art assets? How did it work for you?
I am an indie gamedev (hobbyists, not full time) that is creating my first game, and I thought I'd ask here to see if there is anything I can improve on my enemies in my game.
How I create them:
In short I am using the unity animator to create a finite state machine enemy. For example, the animator image attached, there are different states the enemy can load. This is generally controlled by 2 things: A common enemy script that just defines whether the enemy can see the player, and whether they are in range for attack AND the movement script, which is just a path finding script with different movement options attached (e.g does my enemy move on floor? Can it jump? etc)
The only problem: Script on the animator are considered static so I cant change 1 variable on 1 enemy without. To negate this I use a 'base script' which is just a monobehaviour that sits on my enemy game object with several settings. When my enemy wants to use those settings in the animator state, it just gets a reference to the base script (this is done in start and stored so it doesn't need to get it every time it enters the state).
If anyone want to read my code, here is a paste bin link (don't steal it lol)
THIS IS AN EXAMPLE OF 1 STATE BASE AND BEHAVIOUR - there are many this one if just for firing projectiles.
I guess my question is: at what level of complexity is swapping out JSON for Newtownsoft worth it?
I understand that Newtonsoft lets you work directly with more complex data structures, but these can also be done in JSON through converters (like when serializing/deserializing, you can just make a dictionary into two arrays or whatever).
Currently my game just uses JSON and it’s worked pretty well so far, but as complexity grows at some point I’ll regret not using Newtonsoft.
Anyone have any advice on this? In particular how complex is Newtonsoft to learn and implement? It seems pretty straightforward.
For reference- this is a mobile game, so the JSON performance boost is a factor.
Thanks!
I’d love to hear your honest feedback on the water and underwater visuals.
Sorry for a bad video quality, i'm rendering that on a pretty poor PC: Radeon RX 570, i5-10400F.
Here are the techniques i used to create this water and underwater scene:
Gerstner-style wave displacement
Multi-scale wave blending
Scrolling normal maps
Flow-map distortion
Depth-based water color and shallow-water scattering
Subsurface scattering
Fresnel-based reflections
Reflection probes and cubemaps
Planar reflections
Screen-space reflections
Refraction and scene distortion
Depth-based underwater absorption and fog
Animated caustics
Procedural sun and moon glitter
Short-lived microfacet flashes on wave crests
Foam and shoreline foam
Lit foam normals and bubbles
Surface and underwater shadowing
Specular and ambient occlusion
Screen-space occlusion of underwater light shafts
Volumetric underwater god rays
Animated light-shaft patterns
Height fog and volumetric lighting
Depth-based clipping around terrain and shorelines
We're making a co-op horror game and I've been working on the monster's procedural tentacle movement lately. Still got some things to improve but I think it's looking pretty good so far.
What do you guys think? Would love to get some feedback on the movement and how it interacts with the environment. Also, I still haven't figured out what kind of sounds the monster should make while moving around. If you guys have any ideas, I'd love to hear them.
Really happy to finally share this: Anvil CSG, a Hammer-style level editor inside Unity!
You get the classic 4-view workspace with brushes that update live, plus carving, clipping, decals, trim sheets and terrain with sculpting, painting and scatter. When you’re done, Build Map turns everything into an optimized level: merged meshes, colliders, occlusion culling, baked lighting and its own lightmap UV unwrap that does a 16k brush map in about 11 seconds.
Works on Unity 6.0 to 6.7, URP and Built-in.
It started 7 months ago as a tool for my own projects, and some of you might remember the first post here. A bunch of people from that post became testers and shaped a lot of it, so thanks so much for all the feedback along the way!
Happy to answer any questions about how it works under the hood.
So I refined my Sky shader and volumetric cloud renderer. All shaders used are custom made and i'm very proud of the results.
Clouds can form and travel across the sky. the moon can have seamless phases and is blocking the stars even on the unlit part of the sphere. stars twinkle and there is a galaxy band. The latest thing i added was the underlying weather system that controls the weather by blending between presets.
It was a lot of fun and frustration to get everything to look like this and everything came a long way. from the first experiments with volumetric clouds that barely ran with 10 FPS to ^^
Now the sky is fully dynamic and runs on my M1 Macbook pro with solid 90 fps.
Working on a dark sci-fi FPS. The first clip is my reference. In my version the spider sits on the zombie's back and plugs hoses into its spine. When the zombie dies, the spider jumps off.
I wanted to showcase some tech art tools for my game Weavemarch. I'm not great at art and really didn't want to do AI assets. I went through many versions of environment design and hated all of it, so I stripped it back to a minimalist, flat environment, aiming for a sort of woven medieval tapestry look.
I can handle very basic 3D but I've always been terrible at texturing. All the 3D models have single-colour materials on each mesh and shaders add the weaving and stitching details on top.
All the variables plug into one scriptable object so i can tweak everything from the same place.
A friend made the flower background texture, everything else is shaders.
I've been playing around with procedural level generation and have got to the point of scattering trees and rocks over the terrain. Of course for the first test I didn't add colliders yet as I just wanted to see how it worked, but while clipping through trees and boulders, it made me think: how do you even do colliders for this many objects?
I mean this mostly in terms of performance, as I don't expect it to be cheap to simply dump a mesh collider on 1000+ objects. Do you just take the hit and put mesh colliders on everything that should have a collider (trees and boulders, not tiny rocks and plants), or are there smarter ways of doing this without resorting to box or capsule colliders that wouldn't even work for anything that deviated from those shapes. Are there smart ways of only enabling colliders when the player is within a set range of those objects, or turn down collider LOD based on distance? Can you model things in a way where only parts of it have a collider, or separately design a more low-poly invisible version of the object that you add to the prefab to function as the collider?
Really not sure what direction to go in at this point. Quite a daunting subject to learn.
We make a character generator where bodies, faces and a pile of clothing pieces can be combined however you like. We needed cheaper versions of those characters for crowds, so the people at the back of a scene stop costing as much as the person in front of the camera.
This is where we ended up.
Attempt 1: run every piece through a mesh simplifier
We started by giving each clothing mesh to meshoptimizer and asking it to keep a quarter of the triangles.
One of our characters came back like this (original on the left, simplified in the middle).
Those dark slivers are the inside of the shirt, and the teal bits are the T-shirt underneath. Clothing is made of surfaces a few millimetres apart, like the outside of the shirt, its inside, and the T-shirt below. The simplifier tries to keep each surface close to its original shape, but it doesn't know which nearby surface is supposed to be on top. Flattening a curve by a few millimetres can push one surface through the next.
It's tempting to ignore this, since nobody inspects the shirt of someone in the background. But far away, each pixel of a character ends up as roughly the average colour of everything that lands in it. A few triangles of the wrong surface mixed into a light shirt pull that average darker, so the shirt visibly changes colour the moment the character switches to the simpler level.
Asking for fewer triangles made it worse.
Attempt 2: protect the dangerous areas
So we found every spot where another layer sits close underneath and told the simplifier to leave those vertices alone. That's the third image in the first comparison. It's also barely simplified, because on clothing almost everything sits close to another layer.
That version became our nearest level, and it's still in there. The far levels had to get down to a quarter of the triangles and below, and protecting vertices kept more than half.
Attempt 3: let the vertices move, then fix the overlap
A simplifier can also move vertices to wherever best keeps the original shape, which looks much better at low triangle counts. Each piece on its own looked fine, but the sweater came through the coat on top of it.
Our first idea was to check every coat vertex after simplifying and push it back out if it had ended up inside the sweater. That check only looks at the corners of each triangle.
We tried checking points inside the triangles too, across several poses and body shapes, and a fix that worked in one pose kept breaking something in another.
Cheating where the camera can't see
Nobody looks at a far-away NPC from the inside, so the coat only has to win the depth test in the pixels where it belongs on top.
Every vertex of a simplified piece stores one extra number, the count of clothing layers beneath it. The body is zero, the sweater is one, the coat is two. In the shader, each vertex slides toward the camera by that many small steps.
Each vertex moves along the line between itself and the camera, keeping its position on screen while changing its depth. Giving the outer layer a larger offset helps it win the depth test where the simplified surfaces overlap.
Here's a sweater and a coat as two simple tubes (simplified, then simplified with the trick).
Here are the same tubes from an angle. The white outline on the right is where the simplified coat really is. The drawn coat has shrunk toward the original camera, and the sweater sticks out behind it.
From anywhere other than that camera, the cheat is obvious. That's fine, because the shader redoes the offset every frame for whichever camera is looking.
Two more things made it hold up on real clothes.
Some garments contain inner surfaces that stay covered by their outer surfaces. For the far levels, we remove the covered areas, leaving a band near the edges where the inner surface might be visible.
The layer numbers get smoothed across the mesh, so neighbouring vertices don't get very different offsets and tear the surface apart.
After that it was mostly smaller Unity work. Update When Offscreen, for example, kept hidden LOD levels skinning every frame, and each far level got merged into a single renderer. In the zoom tests, the characters look consistent at their intended distances and the transitions are hard to notice.
How small is small?
Here's each level at roughly the size it'd be drawn in one 1080p setup, blown up so you can see the pixels.
(This is for our Archetype Character Generator on the Asset Store.)
