22afd921ecdc39aa23be84e24482256a8c26d576d28955624aa1a9213e9ce0fdc45b95bc833581f5c0a507cbacadbfc49605f47aeb7b47ef5ea5




인디쪽 소스 도와주다가 늘 느끼던 걸 좀 써봄.



객체의 행동이나 활용 등의 중점적으로 짧은 숏텀 프로젝트가 개발의 경험의 대부분이거나,


방금 스터디 졸업 등의 큰 프로젝트 단에서 설계를 많이 안해본 사람들을 위한 글임.


특히 사수 없이 개발부터 한 애들이 자주 하는 실수기도 함.




게임 개발에서 첫 삽으로 프로젝트를 뜨려고 할 때 기획쪽과의 타협이 끝나면(요구사항 정의서 후 기능 분석 종료 후)


게임 대부분이 Component가 대부분의 시스템 개발의 중점이 되는 경우가 상당히 많음.




이럴때 가장 중요한게 Component 설계인데, 처음 게임 개발 잡은 사람들은 기능적인 구현을 통해서


먼저 좀 보여주자는 느낌으로 Component를 개발하고, 이후에 남은걸 개발하는 경우가 잦음.


특히 Prototyping 후에 바로 투자로 연계된 경우에 기술총괄 이 공백인 경우 그러함.




이런 경우 보통 Data의 변경등에서 상당히 까다로워지고, 단위/ 통합 테스트가 어려우며


세이브/로드/게임 초기/게임 종료/레벨 이동 등의 게임의 전체적인 사이클에서


골탕먹기 너무 좋음.






그래서 그러한 걸 최대한 피하고자 Component를 설계-개발-테스트하기 가장 좋은 패턴은



   A. Data(Struct 개발)


   B. 각 Component별 역할 분리. Interface 처리, 프로젝트에서 필요한 BPFL 정의, 기본 Wrapper 구조화


   C. GameInstance와 해당 Struct 간 데이터 연동 처리 과정 적용.


   D. Component 구체화. Instance 간 초기화 패턴 구성


   E. Controller/Pawn 등에 해당 내용 적용 및 연동


   F. 통합 테스트 및 비상 상황 대응 처리




의 순서대로 개발하는게 경험적으로 합리적임.






어떠한 Component여도 보편적으로 저 패턴에서 벗어나기 어렵고, 


저 구조에서 벗어나는 Component면 어차피 Data가 없는 구조이지만 타 Component간의 연계는 필요하기에


가장 마지막에 구현하는게 바람직함.


또 V테스트 해보기에도 가장 단순화하기 좋은 구조임.


나아가서 어차피 Component 내부에서도 가장 간단한 Event Driven 부터 State Machine Pattern, Data Driven, ECS 등의 패턴으로 또 나뉘는데, 여기서 방향을 잃지 않으려면 초보때부터 저 구조는 반드시 지켜서 개발하고 있어야함.


굳이 게임 아니라 백엔드 개발쪽이나 다른 개발 장르도 같은 프로세스기도 함.




7ce9887eb0ed69f336e6838a4782756d53176c0aef9c3f49d52a8db812acca


건물을 예시로 들면 토목공사랑 같은거라 아무것도 없는 맨땅에서 작은 건물은 잘 지어질지 몰라도


점점 프로젝트가 커지고, 이런저런 고민을 하게 될때부터는 늦을 수 있음.




어느정도 짬찬애들은 당연해보이는 얘기인데, 놓치는 프로젝트를 은근히 봤어서 쓴 글이니 귀엽게 봐주셈


무너진 프로젝트는 모 야다..

8