The Blog

The article explains what Unity serialization is and what [SerializeField] really does: it lets Unity serialize a private field and show it in the Inspector, but only if the field’s type is supported. It compares [SerializeField], [System.Serializable], [SerializeReference], [System.NonSerialized], [HideInInspector], and [FormerlySerializedAs], then lists common serializable types such as primitives, enum, Unity structs like Vector3 and Color, object references, and serializable custom classes and lists. It also covers what Unity cannot serialize directly, such as static and readonly fields, properties, Dictionary, multidimensional and jagged arrays, nested containers, and delegates/events; why properties are not serialized like fields; when [SerializeReference] is useful; how renaming fields can break saved data; and why Unity serialization is not the same as a game save system.

This article explains why ScriptableObject is great for shared configuration data, but a bad choice for per-enemy runtime state like current HP. It clarifies the difference between shared config and instance-specific state, recommends keeping ScriptableObject read-only while storing state in separate C# classes, and warns about editor/build behavior, save data, and the risks of mutable global state. It also notes that mutable ScriptableObject use can work for truly shared session data if ownership, reset rules, and cloning are handled carefully.

This article explains the differences between Unity Rigidbody Dynamic, Kinematic, and Static. Dynamic objects are fully controlled by the Physics Engine, so they respond to gravity, forces, and collisions. Kinematic objects are moved by code or animation, do not respond to gravity or force, but can still interact with Dynamic bodies and push them. Static objects do not move during gameplay, which lets Unity optimize them for things like floors, walls, and terrain. The post also compares their behavior, examples, and simulation cost, then clarifies the difference between Unity 3D and 2D: 3D uses isKinematic plus colliders without a Rigidbody for static objects, while Rigidbody2D has bodyType options for Dynamic, Kinematic, and Static.

This article compares Photon Quantum 3 and Fusion 2 in Unity. It explains that Quantum 3 uses deterministic input synchronization, where every client receives the same input and runs the same simulation, while Fusion 2 uses state synchronization, where an authority peer creates the official state and sends it to other peers. The post walks through differences in architecture, Unity workflow, rollback behavior, physics, AI, performance, anti-cheat, hosting, and game fit, then gives a practical decision guide: Quantum 3 is often better for frame-perfect deterministic games, many-entity simulations, and natural replay, while Fusion 2 is often better for familiar Unity workflows, Unity Physics, plugins, flexible topologies, and server-authoritative or hidden-information games.

This article explains Photon Fusion 2 Dedicated Server in Unity, focusing on the core rule that clients send input or requests while the server decides the real game state. It compares Photon Cloud, Unity headless server builds, and hosting/orchestration, then walks through authority models, `NetworkRunner`, `NetworkObject`, `State Authority`, `Input Authority`, tick-based simulation, prediction and rollback, RPCs, `[Networked]` state, player spawning, common configuration keys, gameplay examples, build and production lifecycle, security, performance, common mistakes, a setup checklist, and a short learning roadmap from Host Mode to Server Mode and production.

A Markdown playbook that helps AI choose a frontend stack before coding, so projects avoid unnecessary libraries and better match the product, UI style, performance, and motion needs.