version 1.2.2 (2005.3.22)
이 글은 토끼군 강 성훈이 정리한 한국어 버전의 BMS 포맷 스펙이다. 이 글은 GNU GFDL에 의해 무료로 배포되고 수정될 수 있다.
이 글의 고유 링크는 http://zenith.sparcs.net/article/bmsguide.phphttp://cosmic.mearie.org/2005/03/bmsguide이며 자유롭게 링크할 수 있다.
2013년 7월 5일: 이 문서는 매우 오래되었으며, 현재의 BMS 포맷을 제대로 반영하지 못 하고 있다. 보다 자세하고 최신의 문서는 BMS command memo(영문)를 참고하길 권한다.
BMS 포맷은, 원래 코나미 사의 비트매니아(beatmania)의 연습용으로 개발된 일종의 에뮬레이터인 BM98에서 사용되던 게임 데이터 포맷이다. 따라서 이 포맷의 원작자는 BM98의 개발자인 Yane Urao 씨이다. 나중에 BM98이 비트매니아의 곡 뿐만 아니라 자작곡을 비롯한 다른 곡을 플레이하기 위해서도 사용되면서 BM98과 그 뒤를 잇는 프로그램들은 더 이상 에뮬레이터가 아니게 되었으며, BMS 포맷도 필요에 따라 확장되었다. 기원이 기원이다 보니까 게임 방법은 비슷하지만, 그 이상의 유사점은 없다고 볼 수 있다.
BMS 포맷을 지원한다고 해서 현존하는 모든 BMS 포맷 확장을 지원하는 건 아니다. 하지만 최근에 나온 대부분의 프로그램들은 적어도 다음과 같은 세 종류의 서로 다른 BMS 파일 확장자를 지원한다.
BMS 포맷을 사용하는 프로그램을 비롯한 많은 리듬 게임(DDR이나 Pump It Up 같은 댄스 게임도 포함)의 플레이 방법은, 건반을 누르거나 턴테이블을 돌린다던지 하는 동작을 해서 판정선을 향해 접근하는 오브젝트들을 없애는 것이다. 판정선이 위에 있고 오브젝트들이 그 쪽으로 올라 오는지, 아니면 서로 반대의 위치에 있는 지는 게임에 따라 다르지만, 일반적으로 건반을 사용하는 게임은 판정선이 아랫쪽, 발판을 사용하는 게임은 윗쪽에 있다.
보통 오브젝트들은 각기 다른 입력에 반응해서 사라진다. 예를 들어서 어떤 특정한 건반을 눌러서 입력해야 하는 오브젝트는, 다른 건반을 아무리 눌러도 사라지지 않는다. 따라서 이들을 구분하기 위해서 각각의 오브젝트들은 판정선의 서로 다른 부분으로 접근하고, 판정선을 지나치기 전에 사용자의 입력으로 오브젝트가 사라지지 않았다면 그대로 판정선을 지나쳐서 사라진다.
다음 이미지는 이러한 종류의 게임의 화면을 갈무리한 것이다. 빨간색/파란색/흰색의 선들이 오브젝트들(정확히는, 빨간색은 턴테이블, 파란색/흰색은 건반으로 입력하는 오브젝트)이며, 아랫쪽으로 접근한다. 아래의 검붉은 선은 판정선이다. 그리고 오른쪽에 나오는 커다란 화면은 배경 동영상(BackGround Animation; BGA)이다.
아무렇게나 입력한다고 모든 오브젝트가 사라지는 건 아니다. 판정선 위아래로 얼마 정도의 간격 안에 오브젝트가 있을 때 입력(건반을 누르거나 턴테이블을 돌리거나)해야 비로소 그 오브젝트가 사라진다. 보통 판정선에 가까울 수록 더 많은 점수가 주어지며, 멀어질 수록 점수가 적어지거나 아예 입력이 무시될 수도 있다. (판정선이라는 이름이 나온 이유이다) 이러한 것을 판정이라 하는데, 판정 방법이나 그 정도는 프로그램에 따라 다르다. 리듬 게임에 나오는 거의 모든 곡들은 그 곡의 박자에 맞도록 오브젝트의 위치가 조정되어 있으므로, 보통 박자를 잘 맞춰야 좋은 점수가 나온다. 비트매니아/EZ2DJ 계열의 리듬 게임이나 BMS 포맷 같은 경우 오브젝트를 없앨 때 특정한 소리가 재생되도록 하는 것도 가능한데, 이 때 재생되는 음을 "키음"이라고 부른다.
보통 대부분의 오브젝트는 한 번의 입력으로 바로 사라지지만, 위의 화면에서 볼 수 있듯이 긴 오브젝트가 나올 경우도 있다. 이들을 롱노트 오브젝트(혹은 그냥 롱노트)라고 부르는데, 이들은 오브젝트의 앞부분이 판정 간격 안에 들어 갔을 때 입력이 시작해서 뒷부분이 판정 간격 안에 들어 갔을 때 입력을 끝내야 제대로 입력한 것으로 처리된다. (좀 더 간단하게 말하면, 오브젝트가 판정선을 통과하는 동안 입력을 계속 해야 한다는 것이다. 예를 들어서 건반이나 발판을 계속 누르고 있거나, 턴테이블을 계속 돌리거나 하는 것이 해당된다.)
오브젝트들이 내려 오는 속도는 BPM(Beat Per Minute)으로 표시한다. 이는 음악에서 사용되던 용어를 따 온 것으로, 원래는 1분에 몇 개의 4분 음표가 재생되느냐를 뜻하는 것이었으나 리듬 게임에서는 보통 "4분 동안 곡의 몇 마디가 재생되느냐"로 정의한다. (위의 화면에서 가로로 그어진 회색 선이 이 "마디"를 구분하는 선이다. 게임에 따라 나오지 않는 경우도 있다.) BPM이 높을 수록 오브젝트들이 빠르게 나왔다가 빠르게 사라지기 때문에 더 어려워지지만, 거꾸로 BPM이 너무 낮으며 오브젝트들을 구분하기 힘들어져서 오히려 어려워지는 경우도 있다. 이런 이유로 대부분의 리듬 게임이나 BMS 포맷을 지원하는 프로그램들은 배속이라는 개념을 가지고 있다. 예를 들어서 3배속이라고 할 경우, 오브젝트 사이의 간격이 원래의 3배로 늘어 나고 내려 오는 속도가 3배가 된다는 것을 의미한다. (곡 자체의 속도에는 영향을 주지 않는다.)
항상 존재하는 것은 아니지만, 배경에 깔리는 이미지 혹은 동영상이 있는 경우도 있다. (대부분의 리듬 게임들이 이를 지원하며, BMS 포맷도 이 기능을 지원한다.) 일반적으로 이들은 게임에 거의 영향을 주거나 받지 않으나, BMS 포맷의 경우 오브젝트를 입력하지 못 해서 판정선 너머로 사라져 버릴 때 나타날 배경 동영상을 따로 선택할 수 있다.
마지막으로 대부분의 리듬 게임에는 게이지(Gauge)라는 개념이 있다. 게이지는 사용자의 입력으로 오브젝트가 사라질 때 그 판정에 따라 차등적으로 올라 가며, 입력을 하지 못 해서 오브젝트가 판정선을 지나쳐 버릴 때 내려 간다. 많은 프로그램들은 이 게이지가 모두 깎여서 내려 갈 경우 게임을 중단하고 "GAME OVER" 표시를 보이게 하는데, 이를 보통 폭사라고 부른다. 게이지가 올라 가거나 점수가 올라 갈 때 그 정도는 판정 뿐만 아니라 얼마나 많은 오브젝트를 연속으로 없앴는 지에도 영향을 받는데, 연속으로 없앤 오브젝트의 수를 콤보(Combo)수라고 부르며, 모든 오브젝트를 없애서 콤보수가 오브젝트의 수와 같을 때 올콤(All Combo)이라고 부른다.
이 장에서는 BMS 포맷을 비롯한 관련된 파일들의 포맷을 살펴 본다.
BMS 파일에는 다음과 같은 정보가 들어 있다:
BMS 파일만으로는 오브젝트의 배열만 알 수 있기 때문에, 실제로는 BMS 파일과 함께 사용할 키음 및 배경음, 그리고 BGA에 사용할 이미지 파일 등이 함께 배포된다. (꼭 필요하지는 않다) 다음은 실제로 BMS 포맷으로 만들어진 곡을 받았을 때 나올 수 있는 파일들의 종류이다.
모든 프로그램에서 똑같이 동작하는 BMS 파일을 만드려면 bmp/wav 파일만을 사용해야 한다. 대부분의 프로그램들은 기본으로 지원하지 않는 jpg 등의 다른 포맷들을 Susie32 플러그인이나 Windows Media 등의 외부 라이브러리를 사용해서 처리하지만, 별도의 라이브러리 없이 자체적으로 이러한 파일 포맷들을 지원하는 경우도 있다.
다시 말하지만, BMS 파일은 일반적인 텍스트 파일이다. 개행 문자는 보통 윈도우즈의 개행 문자인 0D 0A
(C 형식으로 표시하면 "\r\n"
)를 사용한다.
BMS 파일에서 실제로 인식되는 줄은 #로 시작하는 줄 뿐이다. 명령 이름이나 파일 이름 등은 대소문자를 구별하지 않는다. #로 시작하지 않는 줄은 모두 무시되며, 일반적으로 제작자의 주석이나 BMS 파일을 만드는 데 쓴 프로그램의 정보 혹은 데이터가 들어 간다. #로 시작하는 줄들은 그 줄에 들어 있는 데이터의 종류에 따라서 헤더 섹션과 데이터 섹션으로 나뉜다. 보통 헤더 섹션이 데이터 섹션 앞에 나오는 경우가 많지만 항상 그렇지는 않으며, 두 섹션이 섞여 나오거나 위치가 바뀌어도 같은 뜻을 가져야 한다.
실제로 BMS 파일을 읽을 때는 보통 다음과 같은 과정을 거친다. 마지막 두 과정에서는 항상 먼저 나오는 줄부터 먼저 처리해야 한다. (기술적인 용어를 동원하면, 줄들을 정렬할 때 사용하는 알고리즘이 Stable해야 한다는 것이다.)
포맷의 특성 상, 사운드 파일과 이미지 파일들은 특정 명령으로 각 파일을 일정한 키값에 배당한 후 그 키값을 나중에 쓰는 방식을 사용한다. 예를 들어서 3F라는 키값에 특정 이미지 파일을 지정했다면, BGA를 표시할 때 3F가 나오면 이 이미지를 가리키게 된다. 이 때 똑같은 3F라는 키값에 다른 사운드 파일을 지정할 수도 있다. (이미지 파일과 사운드 파일 등은 키값을 지정하는 방법과 그 키값을 사용하는 방법이 서로 다르기 때문에 같은 키값에 다른 종류의 파일을 함께 배당할 수도 있다.) 키값은 0부터 9까지, A부터 Z까지의 36개의 문자를 사용하는 36진법 숫자 두 자리로 이루어지며, 각 종류 별로 1296개의 키값까지 사용할 수 있다. 하지만 옛날 프로그램들에서도 동작하게 하려면 0부터 9까지, A부터 F까지의 16개의 문자를 사용하는 16진법 숫자를 사용하는 것이 좋다. (이 때는 256개의 키값까지 사용할 수 있다)
헤더 섹션은 곡의 메타 데이터나 기본적인 정보, 그리고 사용할 사운드/이미지 파일들을 지정한다. 대부분의 프로그램에서 일반적으로 지원되는 명령들은 다음과 같다.
다음은 몇몇 프로그램에서만 지원하는 명령이다.
#BGA 채널을 제외한 모든 중복되는 명령은 마지막 명령만 인식한다. (예를 들어서 #TITLE이 여러 개 있다면 마지막에 나온 #TITLE만이 적용된다.)
데이터 섹션은 실제로 지정된 이미지/사운드가 어떤 순서로 재생되는 지를 결정하고 오브젝트의 배치를 지정한다. 데이터 섹션에 해당하는 모든 줄은 다음과 같은 형태로 되어 있다.
#xxxyy:aabbccdd...
또는,
#xxxyy:(데이터)
이 줄은 콜론(:)을 기준으로 두 부분으로 나뉜다. 각각의 부분은 다음과 같은 의미를 가진다.
채널은 그 종류에 따라서 다시 두 종류, 즉 이벤트 채널과 오브젝트 채널로 나뉜다.
이벤트 채널은 실제로 오브젝트를 배치하지는 않지만 곡이 재생될 때 발생하는 이벤트(BGA 변경, 배경음 재생 등)를 지정하는 데 사용한다.
오브젝트 채널은 실제로 사용자가 입력할 수 있는 오브젝트들의 배치를 지정하는 데 사용한다. 채널 번호에서 뒤의 글자("3F"에서 "F")는 오브젝트의 종류를 나타내기 위해 사용하며, 각각 다음과 같은 의미를 가진다.
여기서 프리존 영역은, 스크래치에 어떤 입력을 해도 판정에 영향을 주지 않는 영역이다. (영역은 해당 채널의 오브젝트 주변에 지정되며 실제로는 보이지 않는다.) BM98 시절에는 판정 영역에 아무 것도 없을 때 입력을 하면 틀린 것으로 간주했는데, 스크래치에서 자유롭게 입력을 할 수 있도록 하기 위해 만들어진 명령이다. 현재는 대부분의 프로그램들이 판정 영역에 아무 것도 없을 때 입력을 해도 틀린 걸로 처리하지 않으므로 더 이상 사용되지 않는다.
채널 번호의 앞의 글자("3F"에서 "3")는 오브젝트 그룹을 나타내기 위해 사용하며, 각각 다음과 같은 의미를 가진다.
참고로, 판정선 근처에 아무 오브젝트도 없을 때는 판정선에서 가장 가까운 오브젝트의 키음을 재생하게 되는데, 투명 오브젝트는 실제로는 보이지 않고 판정이나 점수에도 영향을 주지 않지만, 이와 같은 경우에만 오브젝트로 인식하는 오브젝트를 의미한다. (투명 오브젝트가 더 가까이 있을 경우 이 오브젝트의 키음을 재생하게 된다. 실제로는 더 많은 노력을 필요로 하므로 많이 사용되지 않는다.)
롱노트 오브젝트에 대해서는 다음 절을 참고하여라.
롱노트를 구현하는 방법에는 세 가지, 즉 #LNTYPE 1, #LNTYPE 2, #LNOBJ 명령을 사용하는 방법이 있다. 최근에 만들어진 많은 프로그램은 이 세 가지 방법을 모두 지원하지만 보통 #LNTYPE 1이나 #LNOBJ 명령을 많이 사용한다.
이 명령이 지정되었을 경우, RDM 타입이라 불리는 방법으로 롱노트를 구현한다. 이 경우 롱노트 채널(channel #5x와 #6x)을 사용하며, 롱노트 채널에 나타나는 키값은 다음과 같이 처리한다.
예를 들어서 "#00251:00AA00FF"는 2번 마디의 1/4 지점부터 3/4 지점까지 롱노트를 지정한다. 이 롱노트를 누를 때는 키값 AA에 배당된 사운드가 재생된다.
이 명령이 지정되었을 경우, MGQ 타입이라 불리는 방법으로 롱노트를 구현한다. 이 방법은 처음에 제안되었던 롱노트 구현 방법으로 당시 프로그램들은 이 명령이 없어도 자동으로 MGQ 타입으로 처리하도록 되어 있었다. 현재 많은 프로그램들은 기본적으로 RDM 타입으로 처리하게 되어 있다. 이 경우에도 롱노트 채널(channel #5x와 #6x)을 사용하며, 롱노트 채널에 나타나는 키값은 다음과 같이 처리한다.
예를 들어서 "#00251:00AAAAAABBBB00CC"는 2번 마디의 1/8 지점부터 4/8 지점까지, 4/8 지점부터 6/8 지점까지, 그리고 마지막으로 7/8 지점부터 8/8 지점까지 세 개의 롱노트를 지정한다. 이 롱노트를 누를 때는 각각 순서대로 키값 AA, BB, CC에 배당된 키음이 재생된다.
이 명령이 지정되었을 경우, RDM 타입 2라고 불리는 방법으로 롱노트를 구현한다. 이 때 xx는 사운드를 나타내는 키값이다. 이 방법은 롱노트 채널 없이 일반 오브젝트 채널(channel #1x와 #2x)을 사용하며, 다음과 같이 처리한다.
예를 들어서 "#LNOBJ FF"가 지정되어 있을 때, "#00211:00AA00FFBBCCFF00"는 2번 마디의 4/8 지점에 한 개의 일반 오브젝트를 지정하고 1/8 지점부터 3/8 지점까지, 5/8 지점부터 6/8 지점까지 두 개의 롱노트 오브젝트를 지정한다. 이 오브젝트를 입력할 때는 순서대로 BB, AA, CC에 배당된 키음이 재생되며, FF에 배당된 사운드가 있다면 3/8 지점과 6/8 지점에서 그 사운드를 배경음으로 재생한다.
다음은 전처리 과정에서 인식하는 명령들로, 다른 어떤 명령들보다도 먼저 실행된다.
문서에서 추가할 사항이나 수정할 사항은 이 글 맨 위에 있는 메일 주소로 메일을 보내 주시면 감사하겠습니다.
한국에서 만든 BMS 포맷을 사용하는 몇몇 프로그램들의 목록은 다음과 같다. (대부분의 프로그램은 Windows 환경만을 지원한다.)
다른 곳들은 잘 정리된 곳이 있으니 이 쪽을 참고하는 것이 좋겠다.
다음은 #EXTCHR 명령을 사용하지 않았을 때 기본적으로 지정되어 있는 스프라이트 번호들이다. 자세한 사항은 Yane Urao 씨의 글을 참고하여라.
x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0x | 0 | 961 | 962 | 963 | 964 | 965 | 966 | 967 | 968 | 969 | 970 | 971 | 972 | 973 | 974 | 975 |
1x | 976 | 977 | 978 | 979 | 980 | 981 | 982 | 983 | 984 | 985 | 986 | 987 | 988 | 989 | 990 | 991 |
2x | 992 | 993 | 994 | 995 | 996 | 997 | 998 | 999 | 1000 | 1001 | 1002 | 1003 | 1004 | 1005 | 1006 | 1007 |
3x | 1008 | 1009 | 1010 | 1011 | 1012 | 1013 | 1014 | 1015 | 1016 | 1017 | 1018 | 1019 | 1020 | 1021 | 1022 | 1023 |
4x | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
5x | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
6x | 941 | 942 | 943 | 944 | 945 | 946 | 947 | 948 | 949 | 950 | 951 | 0 | 0 | 0 | 0 | 0 |
7x | 730 | 731 | 732 | 733 | 734 | 735 | 736 | 737 | 738 | 739 | 740 | 741 | 742 | 743 | 744 | 745 |
8x | 746 | 747 | 748 | 749 | 750 | 751 | 752 | 753 | 754 | 755 | 760 | 761 | 762 | 763 | 764 | 765 |
9x | 766 | 767 | 768 | 769 | 770 | 771 | 772 | 773 | 774 | 775 | 776 | 777 | 778 | 779 | 780 | 781 |
Ax | 782 | 783 | 784 | 785 | 790 | 791 | 792 | 793 | 794 | 795 | 0 | 0 | 0 | 0 | 0 | 0 |
Bx | 800 | 801 | 805 | 806 | 807 | 808 | 810 | 811 | 812 | 910 | 911 | 912 | 913 | 940 | 0 | 0 |
Cx | 850 | 851 | 852 | 853 | 854 | 855 | 856 | 857 | 858 | 859 | 860 | 861 | 862 | 863 | 864 | 865 |
Dx | 866 | 867 | 868 | 869 | 870 | 871 | 872 | 873 | 874 | 875 | 876 | 877 | 878 | 879 | 890 | 891 |
Ex | 720 | 721 | 722 | 723 | 724 | 725 | 726 | 727 | 728 | 729 | 0 | 0 | 0 | 0 | 0 | 0 |
Fx | 880 | 881 | 882 | 883 | 884 | 885 | 886 | 887 | 888 | 889 | 0 | 0 | 0 | 0 | 0 | 0 |
여기서 961부터 1023까지의 스프라이트는 사용자 지정으로 남겨진 부분이다. 나머지는 글자, 기호와 같은 스프라이트가 기본으로 배당되어 있다.
Copyright © 2005, Kang Seonghoon <tokigun@gmail.com>