[📜일지] 유니트레인 개발일지 #2. 프로그램 설계도

[로코복실한(dovecreative)]

저번 개발일지를 쓰면서 느낀 건데, 일지를 보면 알겠지만 뭔가 내가 짠 프로그램을 상대방이 알아들을 수 있게 써놓은 것 같진 않았더라.

게임을 평생 혼자서 만들 게 아닌 이상 내 생각을 보다 직관적이고 효과적으로 나타낼 수 있는 방법이 필요한데, 그래서 표를 만들어 프로그램을 정리해 봤어.

만들어본 표의 구조야. 같은 클래스는 같은 색으로 표현되고, 변수/구조체는 삼각형, 클래스/참조는 사각형, 함수/대리자는 원으로 표현돼.

색으로 클래스를 구분하는 방법은 클래스 안에 자신이 아닌 클래스의 참조가 있는지 한눈에 알아보기 쉽게 해 주는데, 덕분에 클래스간의 관계를 보다 쉽게 이해할 수 있어.

오늘은 이 방법을 이용해서 저번 내용을 정리해볼께.

UMesh는 관계 모듈이야. 나의 이전 프로그램들에서는 왼쪽 그림처럼 한 클래스에 모든 연관된 정보를 저장했는데, 그것 때문에 클래스 내부는 고유 함수들과 관계 함수들이 뒤섞여서 더러웠고, 여러 관계들을 한번에 관리하는 것이 어려웠어.

이 문제점을 해결하기 위해 관계에 대한 처리만 전문적으로 하는 UMesh라는 클래스를 따로 둬서 코드를 보다 깨끗하게 정리할 수 있게 했어.

지금부터는 UMesh의 생성, 관계를 맺는 법, 관계를 끊는 법에 대해 설명할께.

우선 UMesh의 생성이야.

UMesh를 만들 때, 마스터 클래스는 자신의 참조를 UMesh에 넣고, UMesh의 참조를 자신이 저장해.

이로서 UMesh를 통해 마스터 클래스에 접근하거나 그 반대의 접근이 가능해져.

UMesh를 만든 다음에는 UMesh에 채널을 만들어야 해.

채널은 특정 Type의 연결에 대한 모음이라고 생각하면 돼. 예를 들어, 클래스 A가 B, C와 관계를 맺는다면 채널은 2개가 되는 거지.

채널은 각각 Type에 대한 딕셔너리로 저장되며, 타겟을 리스트르 저장하기 때문에 한 채널에는 같은 인터페이스의 클래스 여러 개가 들어갈 수 있어.

채널을 만들 때 타입뿐만 아니라 connect, disconnect라는 함수도 들어가.

이들은 UMesh가 관계를 맺거나 끊을 때 Master에게 알려주는 역할을 해.

다음으로 관계를 맺는 법에 대해 설명할께.

그림은 기본적으로 위에서 아래로, 수평적으로는 화살표 방향으로 보면 돼.

그림은 갈색 클래스가 파란색 클래스에 관계를 맺는 상황을 표현한 거야.

먼저 갈색 클래스의 UMesh가 파랑 클래스의 UMesh의 채널에 연결돼.

그러면 미리 저장해 둔 파랑 클래스의 connect 함수가 발동해서 갈색 클래스의 본체를 파랑 클래스의 본체에 연결해.

클래스간의 상호작용은 크게 2가지가 있는데, 하나는 단순히 클래스에 접근해서 값을 읽어오는 것(target values)이고, 나머지 하나는 대리자를 위임해서 상대 클래스에서 때에 맞게 호출할 수 있게끔(trigger) 하는 거야.

첫번째 방법은 자신이 필요할 때 값을 읽고 싶을 때 쓰고, 두번째 방법은 반대로 상대방의 요청이 있을 때 작업을 수행할 때 사용해.

이 두 상호작용을 보려면 파란색 클래스의 아래 부분을 보면 되는데, 갈색 클래스가 들어오면 connect 함수는 1) target의 참조들을 저장하여 원하는 때에 감시할 수 있도록 해놓고 2) trigger을 target에 저장하여 target이 원할 때 trigger을 호출할 수 있도록 해.

이렇게 갈색 -> 파랑 저장 작업이 끝나면 반대 작업도 똑같이 진행돼.

마지막으로 관계를 끊는 상황에 대해 설명할께.

사실 위에 부분까지만 보면 이전 방식과 차이가 크게 없어 보이지만, UMesh를 사용하면 관계를 끊을 때 disconnect 함수가 자동으로 관계를 끊으면서 클래스 안에 저장되었던 모든 참조를 함께 없애주기 때문에 개발자가 어떤 변수를 null처리 해줘야하는지 신경쓰지 않아도 되게 해줘.

이건 실제 코드에서 구현된 connect 함수와 disconnect 함수야.

보이는 것과 같이 disconnect에서는 단지 connect에서 할당한 것들을 null처리하면 되기 때문에, 이전의 방식에 비해 훨씬 관리가 쉽고 직관적이야.

지금까지 UMesh라는 관계 모듈의 작동에 대해 알아봤어.

저번과는 다르게 그림을 사용해서 좀더 프로그램을 이해하기 쉽게 설명하려고 노력해봤는데, 쓰면서도 저번보다는 조금이나마 글이 깨끗해진 느낌이 들더라고.

앞으로도 이런 그림을 사용해서 프로그램을 설계하고 설명하는 것에 대해 익숙해져보려고 해

다음 시간에는 UMesh를 사용하여 게임을 저장하는 방법에 대해 설명할께. 안녕!

[소년(59.13)]

내가 우매해서그런가 뭔말인지 하나도 몰겄다..

[리슬링?(lucid74)]

기만에반데

[김메가(scw973108)]

[익명(112.168)]

클래스 분할했단거지? UMesh란게 연결을 도와주는 애고 연결하고 연결 끊어주는 방법이 있는거 같은데 이걸 왜 해주는진 이해가 안된다. 한가지 더, 너 말대로 혼자 개발할게 아닌데 개발자들이 쓰는 UML 쓰지 굳이 표를 만들어서 설명하는 거야?

[로코복실한(dovecreative)]

1. 위에 써놨듯이 클래스 안에 그냥 넣으면 정리가 안 돼서 클래스 만들어서 묶어둔거. 아직 유니티 초보라 프로그래밍 지식 아는건 많이 없으니 앙해좀. 2. UML도 찾아봤는데 자료의 참조관계나 시스템 운영 과정을 구현하는 게 어려워 보여서 그낭 새로 만듦. 쓰다보면 문제점이 보이겠지만 일단 만든걸 정리하고 타인에게 이해시킬 수 있는 뭔가를 했다는 것에

[로코복실한(dovecreative)]

의의를 두려고.

[로코복실한(dovecreative)]

끊어주는거는 c#특성상 다른데 참조 남아있으면 객체 삭제가 안된다는 점을 유니티 안에서 해결하고 싶었음.