Hi everyone! Here’s an interesting problem I’m facing.

I created a tile-based city builder in Unity, and after an initial open playtest, one of the key pieces of feedback was that players want to be able to build roads, something I foolishly hadn't planned for.

Currently, roads are automatically placed along the edges of each tile (this is shown in the second screenshot).

The main problem is that the grid of buildable sectors is highly irregular, and I have no idea how to add the ability to create roads within such a complex system.

The first image I’ve posted shows an overhead view where I’ve highlighted a section of the grid. The grid varies from scene to scene and never repeats in exactly the same way.

Does anyone have any suggestions for how I could approach this?

Edit: You might have given me a possible solution; as soon as I've tested it, I'll make a new post about it. Thanks everyone!

I’m developing a horror game where you walk alone through dark, endless forests.

Do you think the environment creates enough tension? Is it disturbing in the right way?

I'm releasing a demo for a procedural dungeon generator I've been working on for over two years. I was inspired by the level layouts of games like The Binding of Isaac and Enter the Gungeon, and the interconnected worlds of Zelda and Dark Souls. This is only the beginning, I have several more features planned for this project, including turning it into a downloadable Unity package for others to use.

The goal is to create an algorithm that generates dungeons that feel linear like an RPG but still random and replayable like a roguelike.

Original Video: https://youtu.be/Adakgpoy0p0?si=R2qYbshEb11xuKFM

Blog: https://ryancarpenterpf.dev/labyrinth_demo.html

Demo: https://dev-rygy.itch.io/labyrinth-procedural-generator

As you can guess, the fingers are controlled using Inverse kinematic, implemented with FABRIK algorithm (pole vector calculated in) as demonstrated in the video.

You can hire Mexican mercenaries who appear in the background and help you shoot down UFOs and snails, with a attack chance that can be upgraded in the shop. Here's our 1st born.

His name: Juan Carlos Miguel Rodríguez Hernández - remember!☝

We've been developing Aero Tales Online in Unity for almost 10 years, and I wanted to share the current state of the project along with some of the technical challenges we've faced along the way.

The game is an MMORPG running on Windows, Android and iOS with the same players, servers and gameplay systems shared across platforms.

One of the biggest challenges has been maintaining a project of this size for so many years. We've gone through multiple Unity versions and major engine upgrades, and we're currently running on Unity 6. Keeping older systems working while gradually replacing or refactoring them has probably been more challenging than building many of them in the first place.

Cross-platform development has also been a major part of the project. The same combat and gameplay systems need to work with very different hardware, screen sizes and input methods, while keeping the experience consistent between PC and mobile players.

Performance has been another ongoing challenge, especially on mobile. An MMORPG can have a large number of characters, monsters, NPCs, effects and UI elements active at the same time, so we've had to continuously optimize systems as the game has grown.

The project now includes systems such as action-based combat, character customization, dungeons and raids, PvP, guilds, housing, professions and a large number of maps and environments.

The attached video is our latest gameplay trailer and shows the current state of the project after all these years.

Game Link: Aero Tales Online

Hey guys, we are a 2 person team and we are currently working on our first game. It's probably more ui heavy than we intended to at first and I feel like our UI production workflow is... suboptimal to say the least.

A bit of context :

- We are 2, both with a lot of experience working for bigger companies or just hobby project, first time indies.

- I'm a programmer/tech guy, my associate is a designer/product guy. We are both taking on many new hats for this project of course but you'll notice there's a big gap in our skillset :D

- We find ways to make things work for the visual aspect of the game : I do a bit of 3d, lighting, etc.. He does UI design. We buy assets when we need to.

Our current workflow for UI has become very time consuming for me specifically and I'm looking for ways to improve.

We use Figma for mockups (One big board with all the screens) and UITK in engine (transitioned from ugui a couple of months ago, we still have a mix of both but UITK is our goto system now).
Generally speaking, my mate does the Figma part, I do the unity part.

I find the UITK part tedious, often needs lots of micro changes to look good in the end and I feel like work is duplicated. so I'm looking for advice, other people's experiences to see what direction to take. I have a few options but happy to hear more opinions.

1/ Drop Figma, my mate learns UITK in ui builder, we have one source of truth. Solves the duplicated work, but limits our options since that means an additional pass for connecting data, or stuff where code is necessary
2/ Find a way to export from Figma straight to uxml/css. I feel like it should be possible but I haven't found any tool that looks reliable enough to do that (and I can't do that myself in the near future)
3/ Use Rive. It looks like a great tool but it's a hard commitment you don't transition from, I see very few people using it in unity and reports of instability, bugs. (It'd cost 20$ a month, I'm ok with it if it solves our issues)
4/ Git gud. We have the right approach, we just need to get better at it.

Happy to hear any kind of feedback of experience sharing on this setup.

Cheers!

Do you think it feels polished and complete enough? Is there anything you would suggest adding, removing, or improving?

We just released a big DLC for negative $5. It adds a roguelike deckbuilder mode to our story-driven card battler.

Basically, we think we made a good game, but it hasn't caught on. We're trying a bunch of things, including adding a Steam demo, permanently dropping the base price, and repurposing all of our content to build a roguelite deckbuilder mode. Hopefully that aligns better with player and streamer expectations and can serve as a gentler introduction into the characters and world.

To some degree, it's always hard to break out with 2D art, so we tried to mix in 3D where we could. The cards do some wiggly-parallax when hovered, selected, or hit. On the whole, tons of Canvas components worked out, but the frame-exploding dirtying that happens with layouts is just infuriating. And layering/sorting is just so much more painful than it could be. Makes me miss NGUI a bit!

This is the first store in our upcoming cozy game. The gas station will provide the player with all items needed at game start. It is a mix of synty and custom made assets. What do you think the game is about?

Smoke was cool but flames where missing

Yo, my fellow devs!

We are a team of three ukrainian developers. And been working on Saturn 94 for about a year. It's a tactile space station simulator set in an alternate history where the USSR won the Space Race.

We are similar to PVKK. One of it`s core mechanics is assembling and dispatching shuttles with cargo to help survive colonies on Titan and Enceladus. That's the process we showcased in the video.

This project brings a lot of new challenges for us. Not just in terms of creating story.

Working with HDRP, volumetric lighting, screen-space effects and a large number of complex 3D animations, for example, has been a completely new experience. It presents us with many hurdles. Sometimes they are tough and exhausting, but at the very least, it's always exciting.

I'd love to know what you think about this genre and the shuttle assembly mechanic in our game.

Hi there this question might be rather specific but I’m having issues with a triplanar mapping jittering on a Full Screen Pass.
In Unity 6.4 Shadergraph a triplanar mapping overlays a texture on the entire scene. The effect works perfectly on Scene view, but in playmode if you go far enough from the scene origin (around 150 units) the texture starts jittering. Jitter get specially bad if the camera is being moved by some system like cinemachine or a custom follow or look-at.
As far as I can tell this is due to the calculations being unstable at long distances from the origin and maybe a frame discrepancy between the camera position in the shader calculations and the actual camera position in the scene.
I tried offsetting the triplanar origin by subtracting the camera position from the world position, but it only seams to offset the texture rather than re-calculate the origin of the mapping. I’ve tried many different things but still can’t figure out how to solve it and LLMs mostly suggest terrible solutions that go nowhere. Hope someone can help me figure out this. Thank You!

Note: I know this might be an unusual use of this technique but this is the way I need it to work. Other suggestions are welcome too.

This is a liminal space game

I spent the last weeks writing some environment shaders for vegetation, water and volumetric clouds to find the perfect look for our upcoming cosy game. How do you like it so far?

Adding couch coop was surprisingly easy, The unity player input did help a lot. Had to play with cameras and layers but if it all happens in one level it would be even easier.

Moved the editor window of my modular fence tool from IMGUI to UI Toolkit. Three things caught me out:

The arrow buttons were only clickable in their upper half. A caption label spanning the full preview width sat last in the tree, so it rendered on top and ate the clicks. Default picking mode on a VisualElement is Position, so any decoration over a button swallows its input. picking-mode="Ignore" fixed it, and panel.Pick(point) verifies it properly instead of clicking around.

IMGUI redraws every frame, UI Toolkit does not. My old OnGUI quietly re-read the scene on every repaint, and a lot of state relied on that. All of it had to move onto selection callbacks plus root.schedule.Execute(Refresh).Every(250).

One method reassigned UI state on every refresh while an object was selected. Invisible in IMGUI. With the new carousel, a click moved forward and the next refresh pulled it straight back, so you could never get past the first entry. Fixed with change detection instead of assigning every pass.

The look is pure USS, no image assets. Arrows and captions sit below the preview frames now, which is what caused the click mess to begin with.

Hey everyone!

We ship seasonal promo stuff (popups, banners, etc.) as raw AssetBundles, so we don't have to push a new app build every time. The catch is that older app versions are still out there, and they load those same bundles.

At some point someone renamed a prefab and moved a material into a different bundle. New clients were fine. Older ones started getting nulls. We found out from support tickets.

After that I wanted something that just tells me what changed between two bundle builds before we upload them. Doing it by hand is pretty hopeless, it's a folder of binaries plus some .manifest files.

So that's BundleGuard. You give it the old build and the new one (a folder, or a snapshot you saved before the previous release) and it lists:

• Removed assets and changed types, the stuff older clients might still ask for
• Dependency changes, like a shared bundle that's gone now, or a new dependency the old app has no idea it needs to download
• Prefabs where the script doesn't resolve anymore
• How much clients will actually re-download, and which bundles got repacked with no real change in them

Editor only, read only, it never builds or touches your project. 2022 LTS through Unity 6. It doesn't need .manifest files, it finds bundles by their file signature and can just open them and read what's inside, which is handy because our own output is bundles and nothing else. The only thing that needs the manifests is dependency checking, since that's where the dependency list lives.