[💬] ScriptableObject 이거 문제있을까?

[Remake(wogus950328)]

ScriptableObject 안에 가령

public bool TestValue; 를 만듬

그리고 이 SO를 사용할 때

에디터모드의경우

플레이모드중 TestValue = true;로 바뀐다면

플레이모드를 종료해도 TestValue = true가 유지가 될테고

실제 빌드에선

TestValue 의 초기값이 항상 빌드시점의 

최초값으로 보장되기 때문에

빌드할때 TestValue = false;였다면

게임을 킬때 false일것이고, 게임도중 값이 true로 변한다하더라도

나중에 게임을 껏다 킬땐 다시 false상태로 돌아가 있고

런타임중 값을 바꿔가며 쓸 순 있지만, 저장은 못한다

이렇게 알고있는데 맞지?

질문은 이거임

에디터모드에서의 동작방식과 실제 빌드후의 동작방식이 위처럼 다른거땜에

의도하지 않은 버그나 실수 문제가 생길 수 있는거같은데

이걸 막기위해서 플레이모드 도중에 SO값이 변한경우, 초기값으로 지정한 SO값이 바뀐채로

저장되어 유지되는것을, 일반 Mono 변수들 처럼 유지되도록 하는 방법이있나?

당장 떠오르는건 SO에서 OnEnable을 사용해서 변수를 매번 직접 초기화해주면

에디터모드에선 기존에 플레이모드에서 값변경이있었어도

OnEnable시점에 다시 초기값부터 시작하기 때문에

빌드시점에서의 동작과 동일하게 돌지 않을까 라고 생각중인데

이렇게 했을때 문제가없을지, 아니면 다른방법이 있을지 궁금합니다.

[익명(usnned)]

런타임중에 SO 수정하는것부터 좀 문제라고 봄

[Remake(wogus950328)]

유니티 공식으로 제공되는 컨퍼런스나 튜토리얼같은데서 런타임에 SO 수정해서 활용하는 방식도 많이나오던데 이걸 문제라고 봐야하나?

[익명(usnned)]

https://unity.com/kr/how-to/architect-game-code-scriptable-objects

[익명(usnned)]

PlayerHP 예시 부분 보면 런타임 중에는 가급적이면 수정하지말고 굳이 한다면 NonSerialize로 필드를 분리해서 쓰고 있음

[익명(usnned)]

SO의 기본 취지부터가 Static 데이터를 Asset으로 만들어서 관리하는거니까 SerializedField를 런타임 중에 바꿔버리면 위험한것

[익명(usnned)]

에디터랑 런타임의 동작을 다르게 하고싶은거면 define을 쓰는게 나을듯?

[Remake(wogus950328)]

으음.. 에디터랑 런타임동작을 같게 해주고싶은걸(런타임처럼 매 게임실행시마다 설정해논값이 유지, 에디터 플레이모드에서 값변경해도 플레이모드 껏다 켯을때 다시 원상복귀되있게) 이게 Scene 객체가 아니고 .asset이라서 에디터모드 수정시에 고쳐진값이 안돌아온다는 내용자첸 납득은가지만... 먼가 편의를위해서 어트리뷰트나 설정 등으로 지원되는게 있을법한느낌이여서 찾다 못찾아서 여쭤본건데... 없나보네요 딱히..

[Remake(wogus950328)]

에디터모드에서 변경된값이 박혀버리는것 외에 빌드버젼에서 런타임에 값수정해서 쓰는게 문제될 영역이 있을까요? 가령 저 hp예제를 에디터모드에서 안건든다고 하면 그냥 변수 하나 가진 SO로 런타임에 변경해가면서 display해주는 용도로 쓸 때 문제될 케이스가있을까요??

[익명(usnned)]

주의해서 쓴다면 심각한 문제는 없을듯 싶은데

[익명(116.38)]

OnEnable은 시작할때만 불리는 게 아니라서 문제되는 케이스 생길듯

[익명(116.38)]

굳이 SO를 런타임에 수정하고 싶다면 실행할때 복사해서 쓰는 방법도 있음

[익명(116.38)]

[NonSerialized] private bool _runtimeValue; public bool RuntimeValue { get { return _runtimeValue; } set { _runtimeValue = value; if(OnChangedEvent != null) { OnChangedEvent.Raise(); } } } public void OnAfterDeserialize() { _runtimeValue = initialValue; }

[익명(116.38)]

이런 식으로 했던 적도 있는데 장단점이 있었...

[Remake(wogus950328)]

이거 위엣분 hp 예제랑 같은방식같은데 단점은뭐엿나여? 솔직히 이렇게 쓰는거 자체만으로도.. 모든 변수가 두개씩 있어야하고 골아픈문제생길거같긴한데.........

[익명(116.38)]

나도 저 링크 보고 했던 것 같네 ㅋㅋ; 모든 변수를 각각 2개씩 만드는게 아니고 타입별로 SO 상속받은 걸 만들어 놓는 거임

[익명(116.38)]

단점은 이게 생각보다 손이 자잘하게 많이간다는 게 컸음. 코드에서 한줄 적으면 될 걸 SO 생성하고 끌어서 연결하고...

[익명(116.38)]

타입별로 안 하고 다른 SO를 멤버로 가지는 하나를 만들면 쉽게 될거 같긴 함

[Remake(wogus950328)]

아고고..

[익명(116.38)]

근데 위엣분이 답글 달아준 것처럼 NonSerialize 붙이면 런타임에 바꿔도 에셋은 안 바뀌는 거 아닌가? 단순히 SO를 런타임에 고치는 것만으로는 문제 되는 건 없을 거라고 생각함 다만 고치면 안되는 SO까지 실수로 고쳐버리는 경우가 쉽게 발생할 것 같음

[Remake(wogus950328)]

NonSerialize 아니여도 런타임(빌드이후)엔 안바뀌지않아요? 오로지 에디터때만 바뀌는게 문제되는것 아닌? 가령 [SerializeField] public int TestValue; 값 인스펙터에서 30으로 해놓고, 빌드해서 게임실행한뒤 게임도중 이거 80으로 바꾸고 겜끄면 다시실행할때 30이 보장되는거 아니에여?

[익명(116.38)]

NonSerialize 이걸 붙이면 에디터에서도 안 바뀌니까 에디터랑 빌드랑 동작이 같아지는 걸로 알고 있어요 (테스트해봐야함; ) 에디터에서만 바뀌는게 문제였던게 해결되는 것?

[Remake(wogus950328)]

또생각해보니 이거 런타임벨류를 NonSerialize로 하나더 만들어서 복사본으로쓰면 에디터에서 플레이모드시 변경되는 실시간값은 인스펙터 확인이불가능하고 최초값만 보이는 불상사가 생기겠네여.. ㅋㅋㅋㅋㅋㅋㅋㅋㅋ....

[Remake(wogus950328)]

머 어트리뷰트나 설정방법 등 명쾌한 깔끔한 해결책이 만들어져있지는 않는것같네요 원래 그런 논리로 만들어진 애인거라 그런걸로 생각해야겠음다..

[익명(126.110)]

데이터랑 상태를 한클래스에 짬뽕하지말고 분리하면 이런 고민할 필요가 없어짐