[📜일지] 우당탕탕 리듬 게임 패턴 에디터 만들기

[일상일상(scroll0957)]

게임 개발을 하다보면, 하나 하나 레벨 데이터를 직접 입력하는 것이 진절머리가 날 때가 있습니다.

그것이 csv나 json을 이용하는 것이던, 게임 엔진에서 직접 입력하는 것이던,

무진장 많은 데이터의 텍스트를 작성하거나 드래그 앤 드롭으로 꾸역꾸역 바인딩하는 것은 분명 즐거운 일은 아닙니다.

특히 리듬 게임은 실제 게임 플레이와는 달리 평면적인 데이터가 많게는 수 천 회 반복되는 구조이기 때문에, 

직접 하나 하나 입력한다는 것은 재미가 없어서 무척 어려운 일입니다.

그래서 만들어진 것인 웹 브라우저에서 작동하는 패턴 에디터입니다.

로컬이나 서버에서 node.js같은 웹 엔진으로 기동할 수도 있지만, 

별도 서버 워크 없는 정적 서비스로 구성해 깃허브 페이지로 배포했습니다.

웹 브라우저를 이용한 레벨 에디터는 성능면에서는 메리트가 없지만, 개발이 빠르고 이용자의 접근성이 좋다는 점이 메리트입니다.

노트는 크게 Tab, Direction, Both의 3 종류로 나뉘어지고

롱노트를 위한 각 노트의 Long 타입, 추가로 변속이나 이벤트 제어를 위해서만 존재하는 Node 타입이 있습니다.

경로는 Node 타입 노트의 방향 제어가 아니라면 Direction의 위치와 방향만으로 그려지므로,

패턴 디자이너들은 Direction 노트를 이용해 음악에 어울리는 경로를 만들 수 있습니다.

이 패턴 에디터는 각 노트 별 bpm, 레벨, 분박과 전역적인 정밀 보정 등의 설정을 모두 지원하고,

데이터 변경 시 브라우저 스토리지에 자동 저장하며, 인게임과 유사한 프리뷰 플레이를 제공합니다.

건반형이 아닌 경로 위를 캐릭터가 이동하는 형태의 리듬 게임이므로, 이러한 프리뷰 기능은 필수였습니다.

위의 노트 기능만으로도 저희 게임의 근본이 되는 경로와 노트 배치는 가능하지만,

카메라 조작이나 배경 이미지 변경, 순간적인 점멸 효과나 광원 효과 활성화 등의 특수 효과는 실행할 수 없었습니다.

특히, 대세 해상도인 16:9 비율에서 위, 아래에 위치한 노트가 너무 늦게 화면에 등장해 불쾌감을 주는 주요 원인이 되었습니다.

따라서 줌인, 줌아웃과 같은 카메라워크를 지원하고자 이벤트 기능 개발에 착수했습니다.

처음에는 해당 노트에 실행하고자 하는 이벤트를 추가하는 식으로 데이터 구조를 설계하려 했지만,

이 경우 실제 json 데이터 뿐만 아니라 에디터에서도 극히 비직관적인 형태로 보여졌습니다.

그럴 수 밖에 없는 것이, 기존 데이터 아래에 추가적인 데이터 구조를 표시하는 것이니까요.

또한 동시에 렌더링 해야할 것이 많아진다는 것은 안그래도 안좋은 성능의 웹 에디터를 더욱 느리게 만든다는 뜻이었습니다.

따라서 기존의 노트 데이터는 NoteList, 실행할 이벤트 데이터는 EventList로 나누어서 json에 저장되도록 했습니다.

웹 에디터에서도 물론 두 리스트를 탭으로 나누어 표시하도록 하여 랜더링과 연산 부하를 가능한 최소화했습니다.

note들은 pre-delay와 bpm, subdivision(분박) 값을 기반으로하는 beat 값을 설정하도록 했습니다.

즉, 120 bpm의 16 subdivision에 pre-delay가 30ms라면, 10beat에 해당하는 시간은 

10(beat) * 60(초) / 120(bpm) / 16(subdivision) + 0.03(pre-delay) = 0.3155초에 해당하는 식입니다.

이렇게 했을 때 유리한 점은, 따로 시간을 계산하지 않아도 BPM과 subdivision 값에 따라서 결과 시간이 도출된다는 점입니다.

시간으로 입력할 수 있다면 입력의 자유도는 높아지겠지만 사람이 직접 음악의 BPM과 subdivision을 고려해서 시간을 입력해야할테니까요.

하지만 event들은 시간으로 입력할 수 있도록 했습니다.

일단 note 들을 만들어 두고 작업하는 것이 전제이기 때문에 그 노트의 시간을 가져와서 입력하면 됩니다.

또한 이벤트는 그 시간에 판정이 이루어지는 것은 아니기 때문에 의도에 따라서 음악의 박자와 다르게 재생되는 연출도 지원해야 했기 때문입니다.

event의 데이터 구조는 Type - id - parameters - param(key-value)로 구성되어 있습니다.

Type, id는 에디터와 게임 양쪽에 enum으로 정의되어 있습니다.

type은 카메라, 배경 등의 이벤트의 카테고리를,

id는 줌인, 줌아웃, 이미지 변경 등의 카테고리 내부에서 처리할 구체적인 이벤트 내용을 정의합니다.

parameters는 사전 정의가 되어 있지는 않지만, 이벤트를 처리할 때 필요한 파라미터 키와 함께 값을 입력하면 그에 맞게 처리되는 식입니다.

이제 게임에서 지정된 시간이 되었을 때 실행되는 event 시스템을 위한 데이터 구조가 완성되었습니다.

게임 이벤트의 꽃, 다이얼로그를 구현합니다.

리듬 게임 중간에 다이얼로그 이벤트를??? 이게 무슨 개소린가요 개발자님?

이렇게 생각하신 분도 계시겠지만, 튜토리얼을 위해 만들어야 했습니다.

튜토리얼만을 위한 새로운 시스템을 만들 수도 있겠지만, 그 편이 오히려 시간이 더 걸린다는 판단이었습니다.

게다가 전용 시스템은 유사한 상황에서의 재사용도 어렵구요.

튜토리얼을 위해 만드는 것이기는 하지만, 스토리 진행 등에서 충분히 사용할 여지가 있다고 생각합니다.

이 시스템의 특히 어려웠던 부분은, 기존의 음악 시간에 따라서 움직이는 게임 시스템 사이에서 순차 처리되는 대화 시퀀스를 넣어야 하는데,

그 데이터가 기존 노트, 이벤트 데이터 위에 얹어져서 나와야 한다는 부분이었습니다.

이 두 데이터는 모두 시간 기반의 데이터로, 실행 시간이 같으면 동시에 처리할 뿐이고 순서를 기다리는 기능은 없습니다.

처음에는 기존 이벤트 시스템만으로 처리할 방법이 없을까 고민했으나,

기존의 방식으로는 순차적으로 처리하기 위해서는 대화 데이터 하나 하나에 처리 순서 index를 넣어줘야 하고,

불필요하게 이벤트 필드가 길어져서 가독성을 매우 해친다는 문제가 있었습니다.

또한 같은 시간에 여러 이벤트를 실행시키게 되는데, 이것을 순서대로 처리하기 위해 index를 파싱해서 재정렬하는 등의 처리가 매우 번잡스럽게 느껴졌습니다.

결과적으로 선택한 방법은, parameters를 대체하는 dialog용 데이터 구조를 만드는 것이었습니다.

event 내에 또 다른 구조의 event가 존재하는 방식이지요.

이벤트에서 system - dialog를 선택하면, 기존 이벤트 변수를 입력하는 parameters 필드 대신 dialogItems 필드가 표시됩니다.

즉, 게임에서 dialog 이벤트가 실행되었을 때는 parameters 대신 dialogItems에 입력한 값을 이용해서 이벤트를 처리합니다.

dialogItems에서는 텍스트 설정, 캐릭터 설정, 표정 설정, 특정 지점 포커스와 같은 기본적인 튜토리얼, 다이얼로그 기능을 선택할 수 있도록 되어있습니다.

또한 특정 키가 입력될 때까지 기다리도록 하는 기능을 만들어 튜토리얼 시 플레이어의 올바른 키 입력을 대기할 수 있도록 했습니다.

이렇게 해서 리듬 게임 중간에 표시되는 다이얼로그 시스템까지 구현을 완료했습니다.

지금까지 개발한 것은 여기가 끝이지만,

아마 앞으로도 새로운 요구사항에 대응하기 위해서 다시 한 번 데이터 구조와 시스템 구현이 필요할 때가 올겁니다.

그 때, 지금까지 만든 것을을 전부 다시 만들어야 하는 상황만은 오지 않기를 간절히 바랍니다...

[SEOHAN(poiu8545)]

노트가 많은게 아니면 노트 perfect 될때 화면 흔들림 조금 있으면 좀 더 쾌감이 있나 싶기도 하고 - dc App

[SEOHAN(poiu8545)]

[일상일상(scroll0957)]

캐릭터가 판정점이라 흔들리면 불분명하다는 의견이 있어서 조심스럽네요

[비월(lunar1228)]

[불타는키보드(1bnmaker)]

[211214(tomatoss)]

[익명(114.200)]

고생하십니다