작성자 없음
작성자 정보가 삭제된 글입니다.
작성
·
372
·
수정됨
0
강의에서 알려주신 것처럼 OOP적인 관점에서 상속을 통해 몬스터-플레이어에 대한 내부 속성(체력, 속도 등등)의 정의와 그에 따른 변화를 함수(데미지처리, UI처리 등등)로 구현하다보면 때때로 모호한 경우가 생겨 고민에 빠진적이 종종 있었습니다.
참고하기 위해 인터넷을 통해 다른사람 코드를 보다, 내부 속성들 조차 클래스로 정의 및 컴포넌트화하여 활용하는 것을 보았습니다. 예를들면, OOP에선 플레이어 클래스안에 존재해야하는 것들이 Health, Stamina 등등 클래스로 만들어 붙이는 것을 보았습니다.
이런 방식이 처음엔 좀 이질적이었는데, 몇번 보다 보니 정리하기는 좀 난잡해보이지만 의외로 논리적으로 처리하는데 편리하게 느껴졌습니다. 그러다 문득 어떤 방식이 좀더 선호되는지, 해당 방식을 쓰는게 좋을지 궁금하여 질문 올립니다
또한, 최근 유니티쪽에서 언급되는 DOTS 같은 경우에 대해 어떻게 생각하시는지, 위의 컴포넌트 방식의 극대화하여 최적화를 추구하는 방식으로 이해하면 되는 것인지 궁금합니다.
답변 1
0
그 부분은 둘 다 괜찮고 선택을 하면 됩니다.
실제로 최상위 클래스에서 스탯을 관리하는 경우도 있고,
StatComponent를 따로 빼는 경우도 있습니다.
(다만 Heatlh, Stamina를 각각의 클래스로 하는 것은 본 적도 없고 큰 장점은 보이지 않네요.)
언리얼의 경우에도 언리얼에서 미는 GameAbilitySystem쪽을 보면
GameAttribute라는 클래스로 스탯을 관리하는데 비슷한 맥락입니다.
그 외 ECS, Job System 등은 유니티에서 엄청 밀어주지만
실제로 그다지 사용하는 것을 보지도 못했고
이전 Unity Network와 마찬가지로 적당히 밀다가 사장되는 경우도 많아
저는 저어엉~말 누구나 사용하는 핵심 기능이 될 때만 사용하는게 좋다고 봅니다.