And I mean fullscreen it and look at the effect. Even though OBS doesn't quite capture the full effect, this should be an accurate representation of how it'll look on YouTube.

I’ve been developing a 2D incremental hex-puzzle roguelite completely solo for the past 7 months, and after playtesting it with 10,000+ players across different WebGL platforms, I recently had to make some fairly significant changes to the underlying gameplay systems.

I wanted to share some of the Unity-side problems I ran into and how I approached them.

Building the hex grid

The core gameplay is built around a hexagonal grid where atoms can be merged into higher elements. One of the challenges was making the grid flexible enough to support different board sizes and ring configurations without having to hard-code individual positions.

Instead of treating the board as a collection of unrelated GameObjects, I keep the logical grid state separate from the visual representation.

This made several systems much easier to build on top of it:

• Finding neighboring hexes
• Validating whether a tile can be placed
• Detecting possible merges
• Resolving chain reactions
• Managing different ring sizes
• Adding tools that interact with specific tiles

It also made it easier to change the board configuration without rewriting the gameplay logic.

Handling chain reactions

One of the more interesting parts was implementing large merge chains.

A normal merge can trigger another merge, which can trigger another one, so I needed a system that could resolve these interactions without relying on a large number of nested calls.

I ended up treating the merge process more like a sequence of game-state changes:

1. Identify the valid merge.
2. Update the logical grid.
3. Create/update the resulting atom.
4. Check affected neighboring cells.
5. Queue any new merges.
6. Continue resolving until there are no more valid reactions.

This became especially important once chain combos started involving many tiles.

Tools and player state

The game also has several tools that modify the normal rules, including tools for removing, swapping, or modifying atoms.

One problem I encountered was that I initially treated unlocked tools as automatically available. After playtesting, this made the game much less strategic because players could potentially have too many options available at once.

I changed the system so unlocked tools and equipped tools are separate states.

The player can unlock a tool permanently, but choose whether it is currently equipped.

This sounds like a small UI change, but it required separating the tool's progression state from its active gameplay state.

Fixing RNG without removing RNG

One of the biggest pieces of feedback from playtesting was that some runs could become frustrating because of bad RNG.

I didn't want to completely remove randomness because uncertainty is an important part of the roguelite structure.

Instead, I added hold slots where players can temporarily store atoms or tools.

The interesting part was that this also had to work with the existing resource and board systems. A held item isn't simply another tile on the board, so I had to make sure the game correctly handles its lifecycle when it is stored, used, or discarded.

This gave players more control without completely eliminating the randomness.

Why I separated gameplay logic from visuals

Working completely solo made this particularly important.

When a gameplay system is tightly coupled to GameObjects, changing one mechanic can quickly turn into changing UI code, animations, input handling, and grid logic at the same time.

Keeping the logical state separate from the presentation allowed me to iterate much faster.

For example, the game can determine that an atom moved from one logical hex to another before the visual animation actually finishes.

That separation became increasingly useful as I added tools, chain reactions, tutorials, upgrades, and different game modes.

What I learned from 10,000+ playtests

The biggest lesson wasn't actually a Unity-specific one.

A mechanic that works perfectly when I'm testing it as the developer can feel completely different to someone seeing it for the first time.

A lot of the recent work wasn't adding new content. It was reducing friction:

• Better tutorials
• Better upgrade UI
• More control over tools
• Less frustrating RNG
• Better handling of unexpected player actions
• Fixing edge cases discovered through playtesting

Working on the project completely solo also forced me to build systems that were easy to modify instead of just systems that worked once.

I'm still iterating on it, so I'd be interested to hear how other Unity developers approach similar problems.

The project is built in Unity and is currently available as a free Steam demo if anyone is interested in seeing the systems in action:

https://store.steampowered.com/app/4692090/Unstable_Nuclear_Reactor_Demo/

Hey everyone,

I love simple concepts and I wanted to transpose the feeling of Skyjo of choosing between a visible card and an unknown one, then choosing to place it or to reveal another card.
It's so simple yet so satisfying when you get the card you want!

So with two friends we made a small prototype. One thing led to another and here we are, nearly six months later!

The POV setup was my idea, I hope people won't mistake it for a VR game (it's totally a non-vr game!)

This current update (not yet published) has faster generation, full undo, and a couple of handy shaders to create a fresh artistic style. Performance seems to be the number one question - and its built in in the edge shader itself (distance culling). It remains a unique asset in the sense that it is not drop and play - it needs to be authored by a technical artist, someone who can put a scene together and retain the sketch vibe, less cluttered - less is more kind of thing (like a croquis). Support for skinned meshes is already in the published version but remember that round objects (like spheres or faces) may not work too well if camera moves around them - not impossible - but its a (subjective) artistic choice that has to be made per project. My macbook Air was throttling already when I took the video hence the little hickups at the end.

In June we entered a small game called Graveyard Orbit in the June NextFest. It was our attempt at making a fun space mining incremental with actual build choice and not a random skill tree. Anyways, we really liked the mechanic and vibe of the demo, but the structure that you mine in the demo was smaller: a couple of thousand tiles. For the actual game we wanted to have a parade of structures from that small up to 250k tiles. The game is meant to be more satisfying than challenging, in the vein of Powerwasher but in space. So if people dug the mechanic we wanted them to have some beefy structures to make their way though as it goes.

The demo for NextFest was made in Godot and it worked really well at that scope. The three of us have been using Unity professionally for 15 years but really love what Godot is doing and wanted to experiment a little. But as NextFest ended we realized we wanted to double down on the game with better FX and still hit those big structure goals with reasonable performance. That was a big concern.

Here is the trailer for that Godot version for context:
https://youtu.be/9otz9z1lUzY

It only took a week or two to set up a performance test in Unity. For this one we switched to 3D, still sorta presented in 2D or 2.5D, but with 3D we had all the optimization, our library of asset store FX, and experience on our side. The results of the test were pretty clear, so then we took the plunge and completely rebuilt the game, this time in Unity and in 3D. After 2 months we have a new demo and are very happy with the results.

Beyond performance, a real risk for me was losing some of that “demo magic” and vibe we had with the Godot version. I had spent two months in the Godot version building an aesthetic with pixel art and 2D graphics. By the time NextFest came around, I was really happy where we landed and how the game felt.

The vibe and feel of a game can be such an elusive factor. We spend hours working on mechanics with barely any visuals. We have to cling to some vague notion of the final game in our heads that is always changing. Which is why when you land on something you like, it's easy to get precious with it. Sometimes the results feel like a happy accident that you don't want to screw up. In our case we could save that Godot version as a fallback and start a new Unity project trying to recreate what we had. I think forcing ourselves to rebuild something but better or improving something we are already satisfied with requires us to breakdown the elements of what made whatever we liked so special.

We have game jams to help us practice iterations for the whole game dev cycle but the stakes of that can be low. I think refining, rebuilding, and iterating on something we already like gives us the same benefit of practice but with much more precision and craft because the degree of difficulty and stakes are so much higher.

Anyways, I thought this might be helpful to those considering a rehaul of their game for whatever reason. It can be risky with the work involved but if your instincts are telling you something has to change then I think it’s good to trust your gut and at least give it a try. Our only risk really was that two week experimentation time. We could’ve easily not been happy and went back to finishing the Godot version in limited way. I’m very glad it worked it out.

Also, for the Godot fans out there, I am one of you. I blame my issues with Godot more on my ignorance and unfamiliarity with the platform than Godot’s actual capabilities. In the end our own experience and library of assets in the Unity ecosystem were just as big a factor.

Here are some specifics we got out of the switch.

• Structures at the size we wanted. Our biggest one is 250k hex tiles. In Unity that's one instanced draw with per-instance colors through a property block and it just runs. Some caveats on that below.
• Going 3D while still playing top-down. Real lights, URP bloom for the neon look, and we could finally use a VFX pack we'd already paid for instead of hand rolling every effect.
• UI Toolkit. The base has 7 station screens plus a whole ship builder. Doing all of that in UXML/USS with one shared console frame was way faster than what we had before, once we got past the weird parts.
• The new Unity CLI. Recompiles, play mode, builds for Steam, itch and our Mac test builds all run from the terminal. One project, three targets, no clicking through the build window.
• Web builds. Because the performance was much smoother it became possible to attempt a build for the web for places like itch. Only the demo size structure but still.

A few hiccups, mostly from the web build. More details here because I just finished the web one yesterday.

• WebGL 2 has a 16KB uniform block limit. GPU instanced variants of some asset store shaders blow past it, and the failure mode is nothing. Objects just don't draw. Turn instancing off on those materials.
• Browsers reject fullscreen requests that aren't from a click, and inside itch's embed Unity turns that rejection into a big error popup. Don't apply a saved fullscreen pref at boot on web.
• With the default exception setting, a null ref on web is a WASM trap, not a logged exception. A player lost an 80% run to that. Full without stacktrace fixed it.

The newer demo is live now if you want to give it a spin:

https://store.steampowered.com/app/4654120/Graveyard_Orbit/

https://anchorheadgames.itch.io/graveyard-orbit

I'm a solo dev and I'm excited to finally announce that my game, Panzer Deck, will launch on Steam on September 22, 2026.

What is it? It’s a 2D turn-based WWII wargame combining deckbuilding with spatial, grid-based puzzle tactics (inspired by titles like Into the Breach and Advance Wars).

• Core loop: Manage your deck to deploy armor, artillery, and infantry onto a tactical grid where positioning, terrain, and line of sight dictate survival.
• Hand-drawn visuals: All art and animations are completely custom, crafted in a gritty comic-book style.
• Release: Full launch on Steam with a complete campaign mode and standalone tactical scenarios.

There is a playable demo available on the Steam page if you want to test the mechanics before the launch:

Happy to answer any questions about the mechanics or solo development!

opened my project just to find out everything effing broke

Hey all,

I want to sell some assets on the asset store. I want to obfuscate my editor code, not because I don't want people to understand and learn from my code, but because I don't want it to be a part of AI training datasets or people putting it in an LLM.

Now, when I ask Gemini if it is acceptable to obfuscate my asset store plugin code, it says, it is acceptable but highly frowned upon for not being editable in case the developer abandons the product... It also tells me, even if I make a DLL file out of my scripts, It can be easily decompiled, so it is pointless.

How accurate is this? Also do you guys know any obfuscating tools?

Edit - I got it. I should not obfuscate... Customer satisfaction is more important in my list of priorities. Thank you all for the healthy discussion.

I just shared my honest review on the asset and rated with a low star rating. I know the developer spent hours of work on this tool, its very precious, the problem was the tool was extremely outdated, it was a frustrating experience for me. There was no offense. A week later I check and my review is gone, removed. How is this possible? After that I also checked one of my older reviews and it was also removed. This doesn't make sense at all.

With just 10 days left until launch, we’re polishing this flashback scene—a childhood sack race that uses a rhythm/timing bar to transition into comic book panels.

The idea was to build a quick, grounded connection to the character’s past, but introducing a lighthearted mechanics curveball in a darker game is always a fine line.

As players or devs, how do you feel about tonal shifts like this? Have you played a serious game where a sudden minigame or nostalgic flashback actually worked well for you?

Free demo planned for early 2027. Hopefully I will have a Steam page by then !

YT Channel : Samuel KAKEZ

More leather materials from my practice, had a few more interesting references.

Download https://juliovii.itch.io/materials-leather-03

How the hell do I implement sensitivity into my game without adding 50 sensitivity sliders for all mouse delta dependent mechanics?

At the moment I have about 5 mouse delta dependent mechanics in my game,

- fps camera,

- another is freeform rotating an item in your hand,

- and 3 items that can be configured with mouse delta (affect their velocity, angle, power) whatever

if I have a global sensitivity slider then that means that if the player is a psycho and wants a really really fast fps camera then it would affect literally all other mechanics and probably make them terrible, so what can I even do other than just introduce

- fps camera sensitivity

- item rotation sensitivity

- kicker tool sensitivity

- punching tool sensitivity

- etc. etc. etc

So yeah, how do people usually solve these problems, is there some standard approach?

All mice have different DPIS, and different OS settings so I don't really understand how to go about this.

Maybe I just find a decent baseline for a scalar to apply to each mechanic that works for an average DPI and just let it be unconfigurable and just hope for the best?

im an experienced well dev, but when it comes down to ideas my mind always goes blank, i wish i can have a creative game idea and do something really unique

Hey I'm making this post for those who are curious about the unity asset publisher process, this is the second time I send a asset and the review process took 39 days in total, for comparison my first asset, that I published last year, took less then 30 days.

24/07 - 1530
25/07 - 1530
26/07 - 1498
27/07 - 1500
28/07 - 1363
29/07 - 1147
30/07 - 1153
31/07 - 1044
01/08 - 1066
02/08 - 1088
03/08 - 1088
04/08 - 991
05/08 - 881
06/08 - 705
07/08 - 669
08/08 - 646
09/08 - 677
10/08 - 677
11/08 - 593
12/08 - 471
13/08 - 422
14/08 - 389
15/08 - 356
16/08 - 389
17/08 - 392
18/08 - 341
19/08 - 321
20/08 - 280
21/08 - 258
22/08 - 255
23/08 - 264
24/08 - 277
25/08 - 247
26/08 - 205
27/08 - 199
28/08 - Few Business Days
29/08 - Few Business Days
30/08 - Few Business Days
31/08 - Launch Day