목표

게임에서의 UI 갱신과 데이터 관리에 대한 방법을 알아보자.

들어가며

안녕하세요. 여러분. 즐거운 개발하고 계시나요?

오늘은 UI에 대한 이야기를 해볼까 합니다.

여러분들은 UI를 어떻게 갱신하고 있으신가요? 데이터와 UI를 일대일 매칭으로? 하드코딩?

만약 위와 같은 방법을 사용하고 계신다면 한 번쯤 읽어볼 만할 내용이라고 생각됩니다.

일단 우리의 게임을 생각해 보겠습니다. 유저의 플레이 화면에는 지금 체력, 마나, 돈이 표시되고 있습니다.

처음 게임을 접속하고 보이는 데이터는 초깃값이겠죠?

그러면 이 데이터를 갱신하는 시점은 언제일까요? 만약 매 프레임마다 갱신하면 그만큼 성능에 문제가 생길 거예예요.

이때 사용할 것이 바로 유저의 반응, 즉 액션(Action)입니다.

액션은 유저의 캐릭터가 사냥을 나서고 대미지를 입으면 체력이 닳겠죠? 또 스킬을 사용하면 마나가 닳을 것입니다. 혹은 몬스터가 드롭한 돈을 습득하면 돈이 오를 거예요. 그러면 여기서 액션은 다음과 같습니다.

이러한 액션에 대해서 결과를 출력하는 것은 UI 화면일 거예요.

출처: 디아블로2

그래서 우리는 위와 같이 데이터를 토대로 화면을 구성하는 것을 View라고 부르기로 했어요.

View 가 어떻게 구성되는지는 알겠어요. 이제 값을 얻어오고 싶어요!

이제는 데이터를 들여다볼 차례입니다. 우리가 가정한 게임이 가지고 있어야 할 데이터는 무엇일까요?

아마 체력, 최대 체력, 마나, 최대 마나, 돈, 최대 보유 가능한 돈 등이 있을거예요.

이를 처리하기 위한 함수 로직 혹은 알고리즘으로 캡슐화 과정을 거쳐요.

이러한 과정에서 남은 결과물을 Model이라고 불러요.

위의 이미지처럼 뷰에서 모델에 직접적으로 데이터를 요청하는 것은 올바른 방법일까요?

물론 특정한 상황 혹은 설계를 개발자가 일부러 했다면 올바른 방법일 거예요.

하지만 일반적인 상황에서는 그렇게 좋은 방법은 아닙니다. OOP에 따르면 하나의 클래스는 하나의 책임을 가져야 한다. 아시죠?

만약 프로젝트의 규모가 커져서 다음과 같은 상황이 있다고 해볼까요?

뷰는 여러 곳에서 하나의 모델만을 참조하고 있습니다. 의존성이 모델 하나에게 집중되는 것이죠.

그러면 모델은 하나의 기능이 더 추가됩니다. 바로 어떻게 뷰의 데이터를 나눌 것인가? 앞선 모델은 무엇을 할 것인지 결정만 하면 되었습니다.

그래서 등장한 것이 이를 연결시킬 징검다리입니다.

View 와 Model 을 이어주는 징검다리인 Controller에요.

컨트롤러는 뷰의 요청을 모델에게 전달하고 처리한 데이터를 모델이 넘겨주면 다시 뷰에게 전송해 주는 역할을 해요.

여기서 컨트롤러가 부여받은 임무는 어떻게 데이터를 잘 전달하냐입니다.

내부적으로 알맞은 뷰와 모델을 찾는 게 중요하답니다.

위 이미지는 앞의 상황을 정리해 봤습니다. 이해가 되시나요? 이를 부르는 말로 MVC 패턴이라고 합니다.

MVC의 패턴은 개발 방법론 중에서 아주 기초적인 방법론이라 다른 방법론의 어머니 같은 존재예요.

단점으로는 뷰와 컨트롤러의 의존성이 높다는 점인데 게임 UI에서는 장르에 따라 심각한 단점으로 다가오지 않습니다.

개선한 다른 방법론도 있으니 한번 찾아보시는 것도 좋아요.

오늘은 게임 UI 갱신 방법에 대해 알아봤습니다. 3분 정도 길이의 짧고 간단한 글을 쓰고 싶어서 최대한 내용을 줄여보았습니다.

더 자세히 알고 싶으시다면 다른 블로거분들이 설명을 해놓았으니 찾아보시면 좋을 것 같아요.

또 MVC 패턴이라고 말하고 있지만 조금만 생각해 보면 데이터와 뷰를 분리하고 컨트롤러로 다루는 방법은

패턴을 모르고 계신 분들도 본능적으로 사용하실 정도로 흔한 패턴이기 때문에 거창하게 생각할 필요가 없다고 생각합니다.

그럼 다음에 더 좋은 게시물로 찾아오겠습니다.