[💬] 정말 놀라운! '토끼 키우기'의 저장 시스템은 어떻게 작동합니까?

오늘은 내가 만든 게임의 저장 시스템에 대해 한번 소개해볼게!

[방치형 힐링 게임 "토끼 키우기"]

처음 게임을 기획할때, 나는 이 게임에 저장 버튼이 없었으면 했어.

다른 방치형 게임들처럼 사람들이 게임을 끄고 싶을 때 굳이 저장 버튼을 누르지 않고 앱을 종료하더라도 다음 게임을 켰을 때 이전 진행 상황이 로드되는 경험을 주고 싶었거든.

다행히도 이 게임은 게임에 변형이 가해지는 순간, 즉 저장이 필요한 순간들은 사용자가 개입하는 순간인 시설 구매, 밭의 강제 수확 등으로 명확했고, 그렇지 않을 경우에는 자동 진행이 되니까 굳이 종료 직전의 정확한 게임 상황을 저장할 필요는 없었어 - 사용자가 개입하지 않는다면 게임을 켜놓든 꺼놓든 일정 시간 후엔 같은 결과를 내는 게임이니까.

이를 구현하기 위해서 저장 시스템의 요구되는 사양으로는 크게 2가지가 있었어.

1. 아주 빠르게 저장이 가능할 것 - 플레이어가 행동을 하는 도중 느려지면 렉이 걸린다는 느낌도 받고 짜증이 날 수도 있으니까, 플레이어가 인식하지 못할 정도로 빠른 속도를 가지는 게 필요해

2. 임의의 순간에도 정확한 저장이 가능할 것 - 예를 들어, 이런 일이 일어날 가능성은 적겠지만, 만약 [토끼가 밭의 수확을 시작 - 저장 - 밭이 토끼의 수확을 승낙] 의 순서로 저장이 이루어진다면, 다음 로딩 때 토끼는 수확 상태로, 밭은 기본 상태로 로드가 되어 오류가 발생할 수도 있을 거야.

먼저 두 번째 조건을 충족하기 위해, 나는 한 tick에서 게임의 모든 활동이 끝난 이후에 저장이 시작되도록 시스템을 설계했어.

7ff3c028e2f206a26d81f6e747837d69

이건 내 프로젝트에 사용되는 Update 시스템인데, 이 객체의 Registe r 메소드에 원하는 대리자를 등록하면 자동으로 매 tick마다 실행시켜주는 구조로 되어 있어.

이 방법의 장점은, 대리자를 등록할 때 뒤에 순서를 지정해줄 수 있는데, 이 값에 따라 한 tick 내에서 원하는 대로 호출 순서를 정할 수 있다는 점이야.

7cf3c028e2f206a26d81f6e443877369

호출 순서는 임의로 정해도 되지만, 혼란을 피하기 위해 기초적인 가이드라인을 클래스 맨 위에 적어놨어.

이 가이드라인을 따라 프로젝트를 개발한다면 [입력 처리 - 게임 - 출력 처리] 순으로 대리자가 호출돼.

여기서 나는 4번째 순서인 '저장' 카테고리를 만들었고, 이는 게임의 입력부터 출력까지의 모든 과정이 끝난 이후에 실행되도록 했어.

이렇게 되면 게임의 한 tick이 '진행 중에' 저장이 일어나는 일을 피할 수 있어.

이제 남은 건 첫 번째 조건인 '아주 빠르게 저장하기'인데, 나는 저장을 여러 tick에 걸쳐 진행함으로써 이 조건을 구현했어.

엥? 근데 지금까지 말한 거에 따르면 저장은 한 tick에 일어나야 하는 거 아냐?

물론 모든 게임 객체의 '저장'은 방금 말한 대로 하나의 tick에서 일어나. 하지만 이 tick과 tick 사이의 아주 짧은 시간에 게임 전체를 직렬화하고 출력하는 것을 한다면 게임이 느려지는 건 피할 수 없을 거야.

이 문제를 해결하기 위해, 나는 저장을 두 가지 부분으로 분리했어. 하나는 존재하는 모든 게임 객체들의 정보를 문서화하는 '캡쳐' 과정이고, 나머지는 캡쳐한 객체들의 정보를 취합하여 하나의 파일로 만들고 출력하는 '프린트'하는 부분이야.

이렇게 하면 캡쳐는 한 프레임 안에 일어나야만 하지만, 나머지 부분은 굳이 한 프레임 안에 이루어져야 할 필요는 없으니 게임이 진행되는 동안 다른 스레드에서 느긋하게 처리해도 되는 일이 돼.

그럼 캡처는 어떻게 진행되는지 알려줄게.

7ef3c028e2f206a26d81f6e74081726a

먼저, 저장하고 싶은 객체에서 '객체'를 '문서'로 저장하는 함수를 만들어. 위 예시에서는 정적 클래스의 함수로 만들었지만, 객체를 XmlNode 형식으로 저장할 수만 있다면 무명 함수가 됐든 뭐가 됐든 상관없어.

그 다음에, 해당 객체의 캡처를 담당하는 캡터를 만들어. 이때 캡터를 생성할 때 이 함수를 넣게 돼.

79f3c028e2f206a26d81f6e44f89776d

나는 Farm이 Farm Manager에 등록될 때 자동으로 캡터도 생성되도록 만들었어. 이때 생성된 캡터는 저장 명령이 떨어졌을 때 위의 함수를 사용해서 객체를 문서화하고 임시로 저장해두는 역할을 수행해.

추가로 객체를 캡쳐하는 작업은 각 객체에 대해 독립적이기 때문에 멀티 스레딩을 사용하여 빠르게 저장을 진행할 수 있어.

이렇게 문서화 작업이 끝났으면, 프린트 작업 명령을 메인 스레드가 아닌 다른 스레드에 예약하고 시간 소모를 줄이기 위해 신속하게 메인 스레드를 재개해.

프린트 작업은 모든 객체의 정보를 하나의 문서에 쓰는 작업이기 때문에 객체에 대해 독립적이지 않고, 따라서 멀티 스레딩을 사용할 수 없어서 시간이 좀 걸려. 그리고 이렇게 작성한 파일을 출력하는 데도 시간이 걸리고. 하지만 이 작업은 메인 스레드가 진행되는 동안, 즉 게임이 구동 중인 동안 일어나기 때문에 사용자는 퍼포먼스 저하를 체감할 수 없어.

만들어놓고 보니까, 이 저장 시스템은 다른 장점도 가지고 있다는 걸 확인할 수 있었어!

예를 들어 게임의 저장을 하나의 함수 또는 클래스가 담당한다면, 게임이 업데이트되어 특정 객체의 저장 파일의 형식이 바뀌었을 때 저장 알고리즘 전체를 다 손봐줘야 하는 일이 일어날 수 있어. 하지만 이 시스템은 하나의 객체는 하나의 함수가 담당하기 떄문에, 한 객체의 저장 형식이 바뀌어도 모든 저장 시스템을 손볼 필요 없이 해당 객체를 담당하는 캡터의 직렬화/역직렬화 함수만 손봐주면 돼.

오늘은 이 저장 시스템에 대해 알아봤는데, 글을 읽고 유익한 아이디어들을 가져갈 수 있으면 좋겠어. 아니면 관련해서 새로운 아이디어가 있으면 언제든지 댓글 남겨주면 좋을 것 같아.

다음에 올 땐 게임의 디버그 시스템에 대해 써 볼게!

[💬] 정말 놀라운! '토끼 키우기'의 저장 시스템은 어떻게 작동합니까?

댓글 5

다른 게시글