MVC와 관찰자

회사를 다니면서 열심히 게임 개발 공부를 하는데, 옆자리 과장님께서 이런저런 지식과 꿀팁들을 마구마구 전수해 주시고 계신다.
잘 모르던 엔진 기능의 사용법이나 직렬화, 유명한 디자인패턴까지 알려 주신 덕에, 오지게 하드코딩만 갈기던 내 코드가 점점 유지보수에 눈을 뜨고 있다

야미보이

이 참에 싱글톤 MVC 같은 패턴 말고 다른 용이한 것들도 익히기 위해 게임 프로그래밍 패턴 책을 샀당

출근길마다 지하철에서 읽는데 나 쫌 갓생인 듯 ㅋ

MVC가 무엇이오

Model : 애플리케이션이 갖는 정보, 데이터와 비즈니스 로직
View : 사용자에게 보여지는 부분, UI
Controller : 이벤트 처리 및 모델과 뷰를 연결

모델, 뷰, 컨트롤러 3개의 컴포넌트를 구분하고 각 컴포넌트마다 분리된 역할을 수행하게 한다. 분리된다는 것이 코드를 수정하는 데 있어 굉장한 이점이다. 회사를 다니며 배운 것 중 가장 중요하다고 느끼는 게 바꾸기 쉬운 코드였다. 여태 내가 쓰던 코드는 함수 하나에 여러 기능을 때려넣거나 하드코딩을 위주로 실행에만 중점을 둔 깨끗하지 못한 코드였다. 스크립트마다 확실하게 역할을 부여하고 그 안에서의 로직 분리도 수행하니 고치고 싶은 부분이 생길 때 전부 뜯어고칠 필요가 없어지는 게 엄청난 이득이라 할 수 있다. 아니 아무튼 MVC도 컴포넌트를 나누는 패턴이니 가독성, 재사용률, 확장성과 유지보수 면에서 강하다고 할 수 있다.

협업할 때도 좋고, UI에 기능을 넣는 등의 실수도 방지되니 게임 개발에 짱 좋다

이 MVC 패턴은 관찰자 Observer 패턴을 기반으로 한다. 워낙 흔한 패턴이라 자바에 내장 라이브러리로 있거나 C#에서 event 키워드로 지원하는 것을 볼 수 있다.

관찰자 패턴

객체 사이에 의존 관계를 만들고, 어떤 객체의 상태 변화를 감지하고 그 변화를 알려 주는 디자인패턴

이 무슨 뜻일까

특정 개체의 상태 변화를 궁금해하는 관찰자, 옵저버를 그 개체에 등록하고, 해당 개체의 상태 변화가 일어날 때 등록되어 있는 옵저버들에게 통지해 준다. 예를 들어 업적 시스템을 구현한다고 치자. 어떤 물리적 행동을 수행하면 업적이 해금되는 기능을 만들 때, 물리 코드에 if(캐릭터 상태 == 업적 조건) 업적.달성() 을 추가해도 되지만 모든 업적을 이런 식으로 관리할 수는 없고 코드가 지저분해진다. 같은 if문을 작성하되 업적 시스템을 관리하는 클래스 안에 옵저버 인터페이스를 구현해 두고 물리 코드에서 알림만 보내 주면 깨끗하게 분리된 코드로 원하는 기능을 만들 수 있다.

관찰자를 여러 개 등록할 수 있다는 것도 장점이다. 예시로 낙하하는 행동 하나에 업적, 오디오, 애니메이션, 체력 등 여러 시스템을 연결해야 하는데, 각 시스템마다 가지는 관찰자를 붙여 두면 알림을 보낼 때 서로 독립적으로 기능을 수행할 수 있다. 관찰자들은 암시적으로 서로 커플링되지 않고, 같은 대상을 관찰하는 다른 관찰자가 있는지 알지도 못한다.

말이 이렇지 이벤트 리스너라고 생각하면 된단다

모든 기법이 그렇듯 얘도 남발해서는 안 된다고 한다. 너무 많은 관찰자가 돌아가면 상태 관리가 힘들어질 수 있고, 동기적 패턴이기 때문에 하나라도 느리면 다음 작업으로 넘어가지 못하고 블록될 수 있다. 또 멀티스레딩에 적용할 때 이 동기성이 교착 상태를 몰고 올 수 있다는 위험성이 존재해 이벤트 큐를 동반해야 한다.

그래서 MVC와 관찰자 사이에 무슨 연관이 있니?

관찰자는 특정 객체에 달라붙어 이놈이 뭐하고 있는지 감시한다. 여러 뷰들이 각자 갖고 있는 관찰자를 모델에 붙여 두면 HP가 깎일 때마다 알림을 받아 어떤 뷰는 체력바 UI의 FillAmount를 조정하고, 또 어떤 뷰는 화면을 붉게 물들이고, 다른 놈은 데미지 텍스트를 생성할 수도 있다.

즉 모델이 관찰당하는 대상, 뷰가 관찰하는 CCTV가 된다. 컨트롤러가 뷰와 모델을 연결하지만 뷰가 모델에 관찰자를 달아 준다면 모델이 보내는 알림만으로 뷰를 업데이트시킬 수 있다.

관찰자는 목록을 관리할 때 메모리 관리를 위해 동적 할당보다 연결 리스트를 사용하고, 가비지 컬렉터 하나만 믿고 등록 취소를 하지 않다가 화면엔 없는데 메모리엔 있는 오류가 발생하는 등 몇 가지만 잘 신경쓰면 서로 연관없는 코드 사이의 상호작용을 만들 때 굉장히 유용하다고 한다.

끗

지환이와의 협업으로 첫 번째 게임인 에임 트레이너의 프로토타입이 완성되었다. 난 다이어그램으로 전체적인 코드 구조만 짜 주고 대부분 로직은 지환이가 구현하게 뒀는데, 모르는 건 물어보거나 구글링하면서 열심히 공부해서 기특하다 굿보이

이번에 기획하는 게임은 개발하는데 시간이 좀 걸릴 것 같다. 플레이어가 한 마을에 정착해 일을 해서 돈을 벌고 삶을 꾸려나가는 싱글 게임인데, 이거 만들려고 에셋 스토어에서 3만 2천원인가 주고 에셋도 샀다. 스팀에 5천원에 팔 테니까 11명만 사 주세요
55000 - 32000 = 23000 이니까 지환이랑 치킨 한 마리만 사먹게요