时间戳

首页 > 解决方案 > 实例化 ScriptableObjects

c# - 实例化 ScriptableObjects

问题描述

谁能告诉我我的方法的优点/缺点？

我有状态效果，作为脚本对象的技能，具有独特的字段，对于每个游戏中的角色都不同（如持续时间、伤害、施法时间，这都取决于个人角色的统计数据）。此外，我在其中拥有大部分逻辑，即仅通过每个对象的 StatusController/SkillCastingController 中的事件进行控制。所以我想出了使用： Object.Instantiate(assigned shared ScriptableObject instance) 为每个人提供单独的实例。

Object.Instantiate(ScriptableObject) 的内存开销很大吗？因为它将在运行时以这种方式大量使用（在运行时应用状态效果 = 使用 Object.Instantiate）。

我只是希望，以这种方式使用 ScriptableObjects 就像它们是简单的类一样工作，不同之处仅在于在编辑器中创建和编辑它们的能力。如果这个假设成立 - Object.Instantiate（在检查器 StatusEffect/Skill ScriptableObject 中分配）与使用复制构造函数创建简单类的新实例相同（new StatusEffect(statuseffects[0]/Skills[0])）。如果这是真的 - 不应该有很多内存使用，对吧？

来自专业人士的引用，有什么想法吗？：

SO 只是一个为在 Unity 序列化中具有方便含义的数据而设计的类。如果您正在创建 SO 的运行时实例，这是确保运行时只读的常见模式，那么您只是在复制根 ScriptableObject 的内存。因为 Object.Instantiate 不会隐式复制任何子资产，如果它们被根引用，则克隆将保持对原始 Scriptable Object 子资产的引用。除非这些 ScriptableObjects 分配大量内存，否则重复的不利影响应该是名义上的。

标签： c#unity3dscriptable-object

解决方案

SO - 可编写脚本的对象。

创建 SO 比创建类消耗更多的内存，并且通常如果您在播放模式下实例化它们，则简单地实例化一个类要好得多，因此您可以摆脱大部分 SO 开销。

一般来说，SO 最适合在播放前在编辑器模式下创建。

为了更深入地了解 SO，并找到 SO 与 GameObject 之间的最佳策略，您还可以阅读此问题。

推荐阅读