📘 TIL-멀티플레이 RTS 개발 회고록

[Keep]

오전과 오후에 간단한 스크럼을 진행하면서 서로의 개발 상태나 이슈를 빠르게 파악할 수 있어서 좋았다.
오전, 오후 스크럼을 통해 오늘 진행할 작업과 현재 상태를 계속 공유하면서 전체 흐름을 놓치지 않고 따라갈 수 있었다.
짧은 시간이지만 방향성을 계속 맞춰가는 데 도움이 되었고, 우선순위를 정리하는 데에도 도움이 되었다.
처음 사용해보는 기술을 공부하고 프로젝트에 적용시켜보는 도전
매일 짧은 스크럼을 통해 작업 진척도를 공유하고 타인의 시선에서 검증받을 수 있는 개발 분위기
멀티플레이어 환경을 구축하며 레플리케이션 로직을 구현할 때, 각 클래스와 함수에 명확한 책임 분리를 적용하여 코드를 작성함.

[Problem]

개발 막바지에 여러 기능이 한 번에 합쳐지면서 테스트 범위가 급격히 늘어났다. 특히 멀티플레이 환경에서는 호스트와 클라이언트의 동작이 다를 수 있기 때문에 양쪽 모두 테스트해야 했지만, 호스트만 먼저 확인하고 클라이언트 테스트를 뒤늦게 진행하는 경우가 있었다. 앞으로는 멀티플레이 테스트 체크리스트를 만들어 기능을 확인할 때마다 호스트와 클라이언트를 모두 반드시 테스트하는 습관이 필요한 것 같다.
UI 로직 구현한 것에 기능 구현한 것을 결합하는 과정에서 멀티플레이 환경에 대한 고려가 부족했던 부분이 아쉬웠다.
특히 서버 기준으로 동작해야 하는 로직들을 뒤늦게 맞추다 보니, 예상보다 많은 버그가 발생했고 시간도 많이 잡아먹은 것 같다. 결과적으로 처음부터 서버 환경을 기준으로 구조를 점검해서 진행했어야 했다는 점이 크게 느껴졌다.
각 파트(특히 로비-게임프렐이까지 이어지는 흐름)를 뒤늦게 합쳐 작업 후반부에 이슈들이 많이 생겼다. 코드의 문제라기 보다는 게임에 전체 흐릅을 미리 이어두고 작업하지 않아 생긴 문제라고 생각한다.
게임 전체의 기반이 되는 부분을 알고 있었지만 이 작업 위에 다른 작업이 올라가야 된다는 것을 확실하게 팀의 방향으로 밀어붙이지 못한 점
이번에 GridSubsystem과 BuildComponent를 주로 작업했다. 처음 작업을 분배할 때 하고싶었던 파트를 할 수 있었서 좋았고, 하고싶은 새로운 구현을 할 때 그 원리를 이해하고 구현한 것이 동작할 때 성취감을 얻어가는 과정이 재밌었기에 더 집중하여 할 수 있었다. 성격상 게임이든 공부든 관심사가 생기면 엄청나게 집요하게 공부하고 오래 붙잡는 것을 좋아하기에 그런 성향을 살려서 다른 기술을 공부할때도 그 원리를 이해하고 그 원리를 이해하는 과정을 재밌게 느끼면서 하면 학습과 공부의 능률을 올릴 수 있을 것 같다.
얕은 지식이 발목을 잡았던 것 같다. 언리얼을 이번 트랙으로 처음 해본 것도 있지만, 언리얼이 가지고 있는 기능을 잘 활용하지 못한 것이 좀 아쉽다. 이 현상을 해결 하려면 기록을 해야한다고 느꼈고, 이번에 구현한 기능도 TIL로 몇개 기록하지 못하였지만, 날을 잡아 TIL을 재 작성 하며 복습도 하고 다음에 활용할 때 술술 쓸 수 있게 하고 싶다.
개발 학습 및 업무에 생각이 많아짐으로써 팀원과의 회의 시간 때, 제대로 집중하지 못하여 상대방의 "의도"를 파악하지 못하고 표면적인 대화에 그치는 경우가 많았음
해결 방안 : 타이핑을 하면서 팀원의 말을 요약하는 글을 쓰면 집중이 잘 되는 것을 느낌

[Try]

테스트 시나리오를 미리 정리해 더 정확하게 테스트하고, 밸런스 수치는 모든 기능이 안정화된 뒤 최종 단계에서 적용하는게 좋을 것 같다. 또한, 테스트가 끝난 부분의 로그는 바로바로 지워서 다음 작업에 방해되지 않도록 하는게 좋을 것 같다.
앞으로는 UI와 기능을 바로 연결하기 전에, 더미 데이터나 간단한 테스트 구조를 만들어서 어떤 방식으로 붙는 게 맞는지 먼저 검증해보려고 한다. 또한 초반 UI 설계 단계에서부터 멀티플레이 환경을 전제로 구조를 잡고, 이후 확장이나 변경이 생기더라도 부담이 적도록 유연한 구조를 고민해볼 예정이다.
UI에 필요한 수치 등 다른 작업에 필요한 부분을 충분히 노출하지 않아 협업을 쉽게 할 수 있었던 것을 어렵게 만들었다. 외부에서 필요한 부분을 미리 만들어 두어야 겠다고 느꼈다.
코드 뿐만 아니라 내가 한 작업물들을 당장 못 쓰면 키워드만이라도 TIL에 적어두고 다음에 꼭 작성해서 마치 내가 정보를 검색해서 해당 블로그에서 정보를 가져가듯 내 코드를 남이 봐도 어떻게 구현하는지 이해할 수 있는 TIL을 작성하려 노력해야겠다.
Mass Entity와 ST 시스템이 머릿속에서 지워지기 전에 추가 학습을 진행하고 개인 프로젝트에 적용해볼 예정

[Feel]

버그를 해결하는 과정에서 디버깅 로그가 매우 중요하다는 것을 다시 한번 느꼈다. 단순히 오류가 발생한 결과만 보는 것이 아니라, 어느 단계에서 값이 달라졌는지 로그로 확인해야 원인을 정확히 파악할 수 있었다.
UI 기능 구현에 집중하다 보니 전체 구조보다는 당장 동작하게 만드는 데에 치중했던 것 같다.
그 과정에서 코드가 여기저기 흩어지고, 리팩토링 타이밍을 놓친 부분이 아쉽게 느껴진다.
결국 기능에 대한 이해와 설계 없이 진행하면, 나중에 더 많은 시간을 쓰게 된다는 걸 다시 한번 느꼈다.
앞으로는 구현 중간에도 구조를 한 번 더 정리하고 들어가는 습관을 가져야겠다고 생각한다.
각 개인이 가진 게임 경험이 모두 다르다는 것을 간과하지 말아야겠다고 느꼈다. 큰 프로젝트에서는 이런 일이 없을 것 이라고 생각하지만, 비슷한 경험을 가진 사람들끼리 서로 '뭔지 알지?' 와 같은 방향으로 분위기가 잡히면 비슷한 장르 게임 경험이 없는 개발자 입장에서는 명확히 어떤식으로 구현해야 할 지 알 수 없으며 물어보는 것에 부담감을 느끼게 될 수 있다는 생각이 들었다.
이번 팀 프로젝트룰 진행하면서 내 작업물을 좁은 시야로 일단 생각한 대로 실행만 되게 만든 것 같다. GridSubsystem을 구현 할 때 이후로 개발할 건설기능을 생각 하지 않고 짜다 보니 건설 기능을 구현할 때 GridSubSystem 쪽을 많이 수정한 것 같다. 물론 처음부터 다 예상하고 코드를 구현할 순 없지만 폭 넓은 시야를 길러 보고 싶다.
못할 것 같으면 일찌감치 포기하자. (계속 붙들고 있어봐야 이도저도 안된다.)