인프런 커뮤니티 질문&답변

software님의 프로필 이미지
software

작성한 질문수

이득우의 언리얼 프로그래밍 Part2 - 언리얼 게임 프레임웍의 이해

8강 아이템 시스템

아이템과 캐릭터의 관계

작성

·

112

0

현재 프로젝트의 아이템 시스템은
캐릭터가 아이템을 습득 -> 아이템 관련된 함수를 캐릭터에서 직접 구현
방식으로 되어있는데
캐릭터에 스탯 컴포넌트 또는 무기 장착 함수 등을 public 형태로 두고 접촉한 아이템이 캐릭터의 함수를 호출하는 방식으로도 생각을 했습니다

어떤 방법이 더 나은걸까요?

현재 프로젝트(게임이랑 성격이 조금 다릅니다)에서는 UI도 쓰이는데 이 때 레벨마다 UI를 사용할 때도 있고 아닐 때도 있어 캐릭터는 기본 함수 제공, UI에서 Delegate 또는 직접 접근으로 처리중인 상황입니다

어떤 설계가 더 나은지 또 캐릭터에서 아이템 등을 직접 참조하고 아이템 등은 캐릭터를 모르게 설계하신 자세한 이유도 한 번 여쭤보고 싶네요~

답변 1

0

이득우님의 프로필 이미지
이득우
지식공유자

안녕하세요. 좋은 질문입니다.

이론적으로는 시스템의 많은 부분을 최대한 디커플링시켜 다양한 기획변경에 유연하게 대응하는 것이 이상적일 것으로 생각합니다. 하지만 디커플링 설계와 적용, 테스트 및 유지보수까지 감안하면 개인이 감당하기 무시못할 개발 자원이 투입될 수 밖에 없을겁니다.

저도 예제를 만들 때 이 점을 많이 고민했는데, 결론만 정리하면 최종 스펙에 맞춰서 필요한 만큼만 확장하자로 요약할 수 있겠습니다. 예제에서 무기를 구현했지만 학습을 목표로 설계한 최종예제에서 다양한 종류의 무기를 구현할 일이 없을 예정이라 딱 필요한 만큼만 구현했습니다. 왜냐하면 실제 구현하지도 않을 부분을 미리 고민해 설계하고 그 의도를 설명하는 것은 학습에 불필요하다고 생각했기 때문입니다.

만일 진보적인 최신의 디커플링 구조 설계가 궁금하시다면 파트4강좌를 참고해보시라고 권장하고 싶습니다. 어빌리티-이펙트-어트리뷰트로 구성된 기본 구조에서 유연하고 다양한 방법으로 필요한만큼 콘텐츠를 확장할 수 있는 정석 방법론을 배우실 것으로 생각됩니다.

software님의 프로필 이미지
software
질문자

감사합니다
프로젝트 특성 별로
캐릭터에서 모든 기능을 감당하지 않는 구조가 더 좋은 경우도 있는 거군요
어빌리티 시스템은 4강 먼저 보면서 기본 개념은 훑었었는데 아직 프로젝트에 적용하기에는 설계가 많이 필요해서 보류중입니다 ㅎㅎ

이득우님의 프로필 이미지
이득우
지식공유자

더 좋다기보다는 리소스투입과 관리에 대한 부가적인 부분을 고민해야한다는 의미였습니다 ^^

software님의 프로필 이미지
software

작성한 질문수

질문하기