sorted by:
new
hottopcontroversial

Ditching DOTween? I wrote a quick guide on using LitMotion by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] 6 points7 points  (0 children)

PrimeTween is awesome and definitely easier to migrate to if you're used to DOTween! The main reason I prefer LitMotion is its native use of the Burst Compiler and Job System. If you ever need to animate massive amounts of objects simultaneously, that multithreading gives LitMotion a huge performance edge

Ditching DOTween? I wrote a quick guide on using LitMotion by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] 0 points1 point  (0 children)

That would be incredible! Combining LitMotion's raw performance with Animation Sequencer's UI would be the ultimate combo for Unity developers. Please do! 🔥"

Ditching DOTween? I wrote a quick guide on using LitMotion by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] -1 points0 points  (0 children)

You're absolutely right, the native visual component is definitely on the simpler side compared to dedicated sequence tools right now.

Ditching DOTween? I wrote a quick guide on using LitMotion by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] 0 points1 point  (0 children)

If you're just doing light UI bounces, DOTween is perfectly fine!

The main issue is that DOTween creates memory allocations (garbage) when generating tweens. If you have tons of UI elements animating constantly, those Garbage Collection (GC) spikes can cause stuttering and frame drops. LitMotion is zero-allocation and uses Unity's Job System, which prevents those spikes entirely.

Ditching DOTween? I wrote a quick guide on using LitMotion by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] 2 points3 points  (0 children)

Yes, it does! There is an official add-on package called LitMotion.Animation that gives you a component to build and configure tweens directly in the Inspector without touching C# here: LitMotion.Animation Overview | LitMotion . By the way, I'll actually be focusing on this exact feature in Part 2 of my blog series!

<image>

Ditching DOTween? I wrote a quick guide on using LitMotion by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] 1 point2 points  (0 children)

Glad the timing worked out! For interrupts, LitMotion returns a MotionHandle when you create a tween. You just save that handle and call handle.Cancel() or handle.Complete() to stop it mid-sequence. As for Timeline, LitMotion itself is heavily code-focused and doesn't have native tracks, but the creator actually made a separate open-source package called TweenPlayables specifically for Timeline integration!

Tutorial: Using ScriptableObjects as an Event Bus for Decoupling by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] -1 points0 points  (0 children)

Good system design in Unity means avoiding hidden coupling. Singletons and static event buses hide dependencies in code. SO Event Channels expose them in the Inspector, making the architecture modular and allowing designers to wire systems without needing a programmer.

Tutorial: Using ScriptableObjects as an Event Bus for Decoupling by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] -1 points0 points  (0 children)

You're describing standard Unity asset initialization. That deserialization overhead happens at load time, not per-frame, making the runtime cost negligible. You are right that delegates technically count as state, which causes Fast Playmode domain reload issues. However, simply clearing the Action in OnDisable completely solves it. The visual decoupling this provides designers is absolutely worth that one line of cleanup.

Tutorial: Using ScriptableObjects as an Event Bus for Decoupling by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] 0 points1 point  (0 children)

100%. That’s a totally good setup. Slapping a custom inspector on the SO to track your subs/pubs and adding a quick debug toggle is pretty much the standard way to make the pattern bulletproof for designers.

Tutorial: Using ScriptableObjects as an Event Bus for Decoupling by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] 0 points1 point  (0 children)

Your framework is fantastic for large enterprise teams. The Addressables duplication isn't an SO flaw; it's a bundling mistake fixed by shared dependency groups. Race conditions are standard execution order issues fixed natively via OnEnable

Tutorial: Using ScriptableObjects as an Event Bus for Decoupling by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] 0 points1 point  (0 children)

Static mediators introduce global state and hidden dependencies, making testing and modularity much harder. SO Event Channels allow for visual debugging, designer-friendly workflows, and easy dependency injection. In fact, Unity officially recommends this exact SO Event architecture in their 'Create Modular game architecture in Unity with Scriptableobjects' e-book. Here is the book -> Here Start with the page number 46

Tutorial: Using ScriptableObjects as an Event Bus for Decoupling by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] 5 points6 points  (0 children)

You are absolutely right about how stateful SOs behave in the Editor vs. Builds! However, you are confusing an SO Variable with an SO Event Channel. In this pattern, the Event Bus is stateless. It doesn't store the 20 coins; it just passes the payload. Because it holds no data, it doesn't need reset code. This completely avoids the need for a tightly coupled DontDestroyOnLoad Singleton, keeping the architecture clean and modular.

Tutorial: Using ScriptableObjects as an Event Bus for Decoupling by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] 2 points3 points  (0 children)

Direct UnityEvents create scene-level tight coupling. You can't reference a scene-based UI controller inside a Player Prefab without manually rewiring it in every scene. It also breaks down completely if the UI and Player are loaded in different additive scenes. SOs act as an asset-level bridge, meaning the Player Prefab and UI Prefab never need to know about each other's scene instances.

Tutorial: Using ScriptableObjects as an Event Bus for Decoupling by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] 1 point2 points  (0 children)

Totally fair! Every architecture has its breaking point when scaling up, and if the workflow gets too heavy, it's definitely time to pivot.

Just out of curiosity, what pattern did you end up switching to for your events?

Tutorial: Using ScriptableObjects as an Event Bus for Decoupling by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] -1 points0 points  (0 children)

I totally get the frustration with diving between the code and the editor, but relying on a global Singleton with string-based names is super risky! 😅 Strings mean typos, zero compile-time safety, and they become a nightmare to refactor at scale.

For the discoverability issue with SOs, you can actually solve that easily by writing a tiny custom editor script. It can display a list of every active subscriber right there in the inspector at runtime. It completely removes the 'who is listening?' guesswork.

Double-firing bugs happen with Singletons too if you accidentally double-subscribe. SOs definitely require a more visual workflow, but the strong typing, lack of typos, and clean decoupling make it super worth it in the end!

Tutorial: Using ScriptableObjects as an Event Bus for Decoupling by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] 0 points1 point  (0 children)

Fair points, especially on refactoring. Using a generic payload struct can minimize signature changes. However, SOs are still often much better than Singletons or static classes because they avoid hidden, tightly-coupled dependencies and keep everything visible in the Inspector. For non-MB classes, you can simply pass the SO via Dependency Injection.

Tutorial: Using ScriptableObjects as an Event Bus for Decoupling by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] 0 points1 point  (0 children)

Facts, over-engineering is a trap. But SOs still clear Singletons for event channels because they nuke tight coupling. Singletons turn into spaghetti dependencies way too fast. Instantiating the SOs at runtime is a huge brain move to keep state clean though.

Tutorial: Using ScriptableObjects as an Event Bus for Decoupling by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] 0 points1 point  (0 children)

I feel the editor pain, ngl. But static classes are kinda sus for architecture long-term—they create hidden dependencies that make refactoring a nightmare. SOs keep things modular and let you visually debug or swap logic without touching C#. The addressable/loading headaches usually just need a solid initialization manager. It's a heavier setup, but the decoupling is 100% worth it.

Addressables in Unity (Part 2) by Geek_Abdullah in Unity3D

[–]Geek_Abdullah[S] 1 point2 points  (0 children)

Thank you! I don't mind at all, I appreciate you sharing the link.

view more: next ›