[TIL] 2025-05-29 알고리즘 문제, 로그라이크의 유물 시스템 구현 고민, 데이터 테이블 구조화
2025-05-29 TIL
알고리즘 문제
트리 구조 기반 문제로 DFS나 BFS로 풀 수 있었는데, DFS로 탐색하는 것이 좀 더 익숙하여 DFS를 사용해보았습니다.
그런데 트리 탐색을 진행해야하지 않고, 그래프 탐색으로 진행해야한다는 점을 파악하지 못해서 문제를 풀지 못했습니다.
전체적으로 확실히 3레벨 문제가 어렵다고 느껴지지만 이번 문제가 더 어렵게 느껴졌던 것 같습니다.
[프로그래머스][C++] 양과 늑대
최종 프로젝트
오늘은 로그라이크의 유물 시스템에 대해 결정을 하고, 구현을 해보았습니다. 또한, 팀원의 작업에서 데이터 테이블을 사용해야하는 로직이 있었는데 해당 데이터 테이블의 구조를 어떻게 구성할 것인지 회의하여 결정해보았습니다.
로그라이크의 유물 시스템 구현 고민
어제에 이어서 로그라이크의 유물 시스템을 어떻게 구현할지에 대해 좀 더 알아보고 조언과 의견들을 들어보았습니다.
결과적으로 현재로서 가장 좋은 시스템은 GAS를 사용하는 것 같습니다.
그렇게 생각한 이유는 GAS 시스템의 의도와 맞게 능력, 버프 및 디버프, 스탯 등의 시스템을 모듈화하여 사용하기 때문에 로그라이크의 유물 시스템에 적합하다고 판단했습니다.
하지만, GAS를 사용할 경우 팀장인 저와 팀원들이 이 시스템에 대해 이해한 상태에서 작업을 해야하는데, 현재로서는 이 시스템을 정확하게 이해하고 사용할 수 있는 인원이 없습니다.
그렇기 때문에 해당 시스템을 당장 프로젝트에서 사용할 수 없는 상태입니다.
해당 시스템을 학습하고 작업을 수행하기에는 학습 곡선이 높아 시간이 부족하다는 점이 문제되는데 이 부분을 해결할 수 없어서 유물 시스템에 적용할 수 없을 것이라고 판단합니다.
그렇기 때문에 어제 구현하려고 고민했던 방법인 UObject클래스를 사용해 동작만을 분리하고, 이 클래스를 상속 받아 로직을 일반화하여 수를 최소화하는 방법을 선택하게 됐습니다.
오늘은 이 기능을 구현하는 것에 필요한 베이스 클래스 및 멤버 함수와 관련된 로직을 구현해보았습니다.
후에 시간적 여유가 된다면 해당 기능을 GAS로 변경해볼 수 있을 것 같습니다.
데이터 테이블 구조화
몬스터를 작업하던 팀원과 몬스터 데이터 테이블의 구조에 대해 이야기하고 정리해보았습니다.
팀원의 기존 계획은 데이터 테이블을 3가지로 세분화하여 사용하고자 했었습니다.
스탯, 스킬, 설정 데이터 테이블로 3가지가 나뉩니다.
저는 데이터 테이블을 3가지로 세분화하여 사용하는 구조가 코드에서 로직이 길어지고 가독성이 떨어지는 것을 우려해 다른 방향을 제시했습니다.
제가 제시한 구조는 다음과 같습니다.
- 데이터 테이블의 종류를 1가지로 줄입니다.
- 줄인 데이터 테이블에서는 스탯과 몬스터의 블루프린트 클래스만을 관리합니다.
- 스킬과 설정 데이터는 몬스터의 블루프린트 클래스에서 가지도록 합니다.
스탯의 경우 몬스터가 스폰되기 전에 특정 요인으로 인해 체력이 감소하는 등 몬스터에 값이 설정되기 전에 스탯이 변경 되어야하는 경우가 있을 수 있기 때문에 데이터 테이블이 값을 가지도록 해줍니다.
나머지 데이터들을 블루프린트 클래스에서 데이터 테이블의 일부 요소를 저장하여 관리하도록 해주었습니다.
이유는 한번 값이 설정되면 기획이 굉장히 크게 변하지 않는 이상 변경되는 값들이 아니며, 데이터 테이블을 사용할 경우 불필요한 연산과 코드 복잡도를 발생하기 때문입니다.
예를 들어, 몬스터가 공격 시 재생해야하는 애니메이션이 있습니다.
현재 기획과 팀 상황에서 특정 스켈레톤을 가진 몬스터의 애니메이션을 변경해야하는 경우는 없다고 보고있습니다.
해당 경우가 발생하기 위해서는 기존 스켈레톤을 사용하여 애니메이션을 직접 생성하거나, 새로운 애니메이션을 제작해야하는데 이러한 작업을 할 기술이나 인원이 없기 때문에 발생하지 않습니다.
그리고 몬스터의 공격 애니메이션에서 공격에 대한 로직이 복잡하게 구현되어 고정적으로 사용하는 변수 값이 많은 상황입니다.
이 값을 기획에 따라 변경해야하는 경우가 없다고 보기 때문에 몬스터의 블루프린트 클래스 자체에서 가지도록 설정해주었습니다.
이외에는 몬스터가 특정 베이스 클래스를 기준으로 내부의 값을 채워주어 동적으로 사용하는 구조가 아니기 때문입니다.
즉, 특정 클래스를 상속받은 블루프린트 클래스를 생성하고, 해당 블루프린트 클래스에서 스켈레탈 메시, 애님 인스턴스, 재생하는 몽타주 등을 가지며 몬스터 종류 별로 이미 블루프린트 클래스가 있기 때문에 특정 요소들에 대해서 동적으로 값을 채워주어야할 필요가 없습니다.
간단하게 정리하면 기획상 자주 변경되어야 하는 값이 아니거나 게임 시스템 상 값에 영향을 주려는 경우가 아닌 경우 데이터 테이블을 사용할 때 가독성과 연산의 효율성을 위해 특정 값은 블루프린트 클래스에서 직접 값을 가지도록 설정해주었습니다.
댓글남기기