TIL 2025.05.08 기록
0. 개요
오늘은 오전에는 노션 이슈로 밀렸던 문서 정리, 데일리 스크럼을 진행하고 오후동안에는 템플릿 분석을 진행했다.
하지만, 오후에 노션 이슈가 해결되지 않아 기록했던 것들이 다 날라갔다는 사실을 파악하고... 경악을 금치 못했다... 아오 노션!!!!!
때문에 21시부터는 노션을 캠프에서 제공한 노션이 아닌 개인 노션으로 돌려 팀원분들을 초대드려 작업하기 위해서 노션을 처음부터 다 다시 작성했다..
그래도 노션 이사를 마치고 나니 롤백 현상 뿐 아니라 노션 페이지 삭제를 못하는 이슈도 해결되서 오히려 마음은 편했다..
이럴 줄 알았으면.. 진즉 이사해서 시작하는 거였는데... 그나마 빨리 이사해서 다행이다 싶기도 하다..
노션 이슈로 원래 일정과 다르게 목요일부터 코드 작업을 스타트하지 못한게 아쉽긴 하지만, 이제부터 시작이고 달리면 되니까 긍정적이다.
또, 기획한 스케일이 크긴 하지만 결코 못할 작업량도 아니기에 충분히 가능하다.
다만, 세부적인 일정들은 조금 정리해서 그 페이스를 유지하도록은 주의를 기울여야할 것 같다.
암튼.. 오늘은 템플릿 분석했던 것들을 정리하고, TIL을 마치겠따...
03:22... TIL 작성 완료.. ;ㅅ; 오늘도 잠을 늦게 자네..
1. 프로젝트
레퍼런스 참고용으로 찾아두었던 템플릿을 분석해, 시스템을 구상하고 오브젝트 배치 및 그리드 표시 기능을 구현하려고 한다.
1. 템플릿 분석하기
[ 빌드 매니저 ]
변수
각 인덱스 마다 데이터 테이블을 가지고 있고, UI로 배치할 오브젝트를 선택하면, 해당 데이터 테이블에서 오브젝트 이름을 Key값으로 오브젝트의 Value를 찾아오도록 구현되어 있다.
⇒ 원래 설계 했던 대로 이 부분을 그대로 차용하기 때문에 구조를 약간 변경해 적용하면 될 것 같다.
⇒ 데이터 테이블을 하나로 관리하거나, 조금 구분지어서 방 모듈, Prop(함정, 구조물), 몬스터를 UI에서 탭으로 따로 표시되도록 해주면 될 것 같다.
해당 템플릿에서는 빌드 매니저 내에서 그리드를 그리고 관리한다.
Update Grid Actor | 더 확인해봐야함. |
Grid Size | 그리드 X,Y 별 개수 |
Cells Count | Grid Size로 계산되는 셀 개수 (VisibleOnly로 변경해야함.) |
Grid Cell Size XY | 셀 하나의 가로 세로 길이 |
Vertical Step | Z축으로 어느정도 거리가 있어도 배치가 가능하게 허용할 것인가 ⇒ 우리의 경우 이 부분은 제외해도 무방할 것 같음. |
Start Trace Height & End Tracee Height | 아마도 라인 트레이스와 관련된 변수로 추정 ⇒ 로직을 확인해봐야 할 것 같음. |
Grid Material & Grid Texture | 그리드를 그릴 때 사용할 머티리얼과 텍스처 |
Grid Color | 그리드 색상 |
[ 추가적으로 확인해봐야할 부분 ]
마우스 아래에 충돌 검사를 진행할 때, 전달할 변수
⇒ 우선 해당 변수는 둬도 좋을 것 같다.
⇒ 복잡한 메시 형태 그대로 트레이스할 때 사용하는 것 같다.
⇒ 기본적으로는 false를 주면 될 것 같다.
[ 필요하지 않는 부분 ]
피직스 머티리얼로 각 표면의 마찰등을 설정해주는데, 해당 부분은 우선 제외하고 해도 괜찮을 것 같다.
⇒ 기획상으로 타일 브러시는 만들지 않기 때문.
⇒ 따라서 필요하다면, 방 모듈마다 지니도록 하는게 적합해보인다.
연속으로 오브젝트를 배치할 때, 최대 최소 수량이다.
⇒ 해당 부분도 기획상 없기 때문에 구현하지 않아도 될 것 같다.
오브젝트 아웃라인 색상인데, 우리의 경우 던전 에디팅을 하고 인게임에 들어가는 방식이기 때문에 이러한 아웃라인 처리는 필요없다.
⇒ 필요하다면, RTS 파트에서 필요할거 같아 레퍼런스 정도는 삼을 수 있을 것 같다.
기능
BeginPlay() | 플레이어 컨트롤러 Ref, Grid Size(최소 1로 설정되도록), 초기 리소스 초기화, 빌드 가능 영역 여부 체크 빌드 가능 영역 존재 여부 체크 ⇒ 중복은 적용안되고 레벨에 해당 영역은 하나만 존재해야함… ⇒ 우리의 경우엔 해당 영역 로직과 그리드 출력 로직을 하나로 묶어서 구현해주어야 할 것 같음. |
UpdateResourcesValue() | 리소스 수를 전달 받아 리소스 값을 변경해준다. 이때, bool 변수를 받아 감소인지, 증가인지를 확인해 적용한다. ⇒ 우리는 넥타르만 적용하면 되도록 하면 될 것 같다. |
Tick() | UI를 통해 건물 배치 OR 건물 철거 기능을 켜면, 매 Tick마다 BuildingManagerValues()를 호출 이후 현재 모드가 철거인지 배치인지에 따라 분기를 나눠서 진행한다. 철거일 경우 ⇒ 마우스 클릭을 통해 인터렉션을 시작한다면, 특정 시간 뒤에 해당 오브젝트를 Destroy해준다. (DestroyObjectUnderCursor()) 배치일 경우 드래그가 가능한지 판단하기 위해 DetectMouseDrag()를 호출해준다. |
BuildingManagerValues() | 마우스 아래에 라인 트레이스를 진행해, 오브젝트가 있다면, 각 위치들을 기록하고, 그리드내에서의 Cell 인덱스를 구한다. 이때, CellIndex를 구할 때, GetCellfromWorldLocation()을 이용한다. |
GetCellfromWorldLocation() | WorldLocation을 받아 그리드 셀 Index로 변경한다. 이때, 단순 Round()로 반올림만 하지 않고, 반환값을 Abs(), Sign()을 이용해 정확한 Int 값을 구한다. ⇒ 단순 Round()만 사용할 경우 -1.6 ⇒ -2.0이 되고, 이상한 값이 되어버릴 수 있어서 예방 차원에서 Abs()와 Sign()을 추가적으로 이용하는 것 같다. |
드래그가 가능한 오브젝트인지를 판단하고, 드레그 거리 조건 가능을 체크해 bool 변수를 OnOff 해준다. ⇒ 해당 템플릿의 벽의 경우 드래그로 배치가 가능해서 존재하는 기능이다. ⇒ 우선 우리는 드래그로 배치하는 기능을 제공하지 않을 생각이기 때문에 이는 불필요하다. |
|
DestroyObjectUnderCursor() | 커서 아래의 오브젝트를 확인해서 Vaild 체크를 해준뒤, PlaveableObejct의 DemolitionPlaceableObject()를 호출해준다. |
[ Buildable_Boundary ]
빌드가 가능한 영역을 잡기위해 만든 클래스
⇒ 해당 부분을 빌드 매니저에 포함해 만들어도 괜찮을 것 같다.
⇒ 생각해보니 Room의 경우와 Prop의 경우를 구분해 구현해야할 것 같다…
Prop의 배치 조건을 Room의 영역내로 잡히도록 조금 수정을 해주어야 할 것 같다.
함수
BeginPlay() | Border를 보이게 할지 안할지(ShowBorder)를 확인해 보더를 삭제해준다. |
SnapToGrid() | 빌드매니저에 |
[ DataTable ]
PlaceableObjectClass | 실제 배치할 BP 레퍼런스 |
ObjectPlacerClass | 배치 전 실루엣 BP 레퍼런스 |
ObjectSize | 배치할 오브젝트의 X,Y Size ⇒ 오브젝트 크기를 고려해 그리드 상 오브젝트 크기를 저장하면 될 것 같음. |
MaxHeightDifferenceForConstruction | 건설 시 최대 높이 차이.. ⇒ 빌드 매니저의 Vertical Step과는 다르게 건물 마다의 Z축 건설 가능 한도 |
ConstructionCost | 건물 배치시 소모될 재화 ⇒ 넥타르 시스템이 추가되면 해당 부분에 값을 수정하면 될 것 같음. |
ReturnResourcesPercent | 건물 제거시 반환되는 재화 ⇒ 추후에 몬스터가 죽을 때 에테르를 늘려주는 것을 해당 데이터 테이블에서 해도 괜찮을 것 같음. (아마 몬스터만 해당 됨) |
HealthPoints | 건물 체력 ⇒ 에테르 제외 불필요 (따라서 아에 오브젝트 클래스 단위로 빼는게 좋아보임) |
CanBeDestroyedByPlayer | 플레이어에게 피해를 입는지 여부 ⇒ 위와 동일 |
CanBeDestroyedByInfantry | 보병에게 피해를 입는지 여부 ⇒ 제외 |
CanBeDamagedBySiegeArtillery | 공성 포병에게 피해를 입는지 여부 ⇒ 제외 |
Flammable | 인화성 ⇒ 제외 |
Icon | UI에 표시할 이미지 |
Mesh | 실제 배치할 Mesh ⇒ 어짜피 BP 레퍼런스로 배치할건데.. 메시가 필요한가? |
Name | HUD에 표시할 이름 ⇒ 이부분은 각 Prop에 넣는게 맞는것 같음. |
Description | UI에 출력할 설명문 |
EnableBorder | 배치된 건물을 클릭했을 때 띄워줌 보더 ⇒ Prop으로 빼는게 나을 것 같음. |
EnableOutline | 아웃라인이 안뜨는걸 보니.. 팀 설정이 있어야 가능해 보임 |
EnableHpBar | 배치된 건물을 클릭했을 때, HP HUD를 띄워줌 ⇒ Prop으로 빼는게 나을 것 같음. |
HpBarVerticalOffset | HUD Vertical OffSet |
HpBarWidth | HUD Width |
ResourceType | 리소스 타입 ⇒ 아마 특정 타일에만 건물을 배치할 수 있도록 할 때를 위한 타입인 것 같다. ⇒ 결론 아직 불필요 |
2. 시스템 구성하기
레벨에 존재하는 BuildManager를 가져올 수 있도록 해야함.. (컨트롤러 BeginPlay()쪽에서 찾아서 알고 있도록 해도 괜찮을 것 같다. 아니면, 게임 스테이트나..)
자원 체크 클래스도 필요할 수 있다.
더 정확한 것은 시간이 너무 늦어져서 내일 하는게 좋을 것 같다..
2. 마무리
노션 이슈로.. 노션 이사 때문에 오후에 대부분 시간을 노션 작성쪽으로 빠져버려서.. 결국 템플릿 분석은 50% 정도 밖에 진행하지 못한 것 같다.
그나마 대부분 주요 기능들 분석 & UI 구현 분석 (기록은 안해뒀지만...)은 다 끝이나서 내일 거의 바로 시스템 설계에 들어가고, 빌드 매니저, 그리드까지는 구현할 수 있을 것 같다.
이후 주말간.. UI를 간략히 만든 후 바로 오브젝트 배치 기능을 구현해 테스트해보면 될 것 같다.
이전보다 더 빠르게.. 시간도 더 투자해서 프로젝트를 진행해야할 것 같다.
아오 노션.. 증말..