The Blog

This article explains why HDRP can look more realistic than URP: not because it has sharper models or textures, but because it spends more GPU budget on the lighting details people notice most, such as light size, bounce light, contact shadows, per-pixel reflections, material response, and atmospheric scattering. It compares URP and HDRP across neon lights, shadows, reflections, specialized material models like subsurface scattering and anisotropy, and volumetric fog, then shows why URP simplifies these systems for broad platform support while HDRP targets higher-end PC and console visuals. It also outlines when to choose URP, HDRP, or the deprecated Built-in Render Pipeline.

This article explains how to migrate player save data in Unity without resetting progress. It shows why simply adding new fields is not enough, and why a separate schemaVersion should be used instead of the game version. The post walks through version-by-version migration, including changes like renaming level to highestUnlockedLevel, adding gems, merging Coins and Gems into Wallet, and converting Inventory IDs into ItemStacks. It also covers safe migration workflow, reading version data before creating defaults, backing up the original save before overwriting, validating migrated data, and testing edge cases such as corrupted JSON, missing versions, and interrupted writes.

The article explains Unity’s move from Mono to CoreCLR and what it really changes for developers. It says CoreCLR replaces the C# runtime under Unity, not MonoBehaviour or IL2CPP, and the main benefits are a more modern garbage collector, better managed-code runtime performance, and faster code reloads in the Editor. It compares Mono and CoreCLR, shows why static state and events need more careful cleanup, notes that CoreCLR uses RyuJIT and aligns Unity with modern .NET, and clarifies that IL2CPP still remains necessary for platforms that do not allow JIT. The post also lists areas of older projects that may need review and gives a preparation checklist before CoreCLR becomes standard in Unity 7.

The article explains that AI concepts are often easy to define but hard to visualize, such as tokenization, embedding, attention, and RAG. To address this, the author created Visual Knowledge, an interactive visual space for exploring AI ideas through images and hands-on interaction. The first version includes seven topics: Tokenization, Neural Network, Embeddings, Attention, Transformer, LLM, and RAG, with the goal of turning abstract ideas into moments of real understanding. The project is still being developed and will add more topics in the future.

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.