BMS 형식의
에 대하여 (1) #PLAYER (미완)

      BMS 형식의
에 대하여 (1) #PLAYER (미완)에 댓글 없음

원본:

BM98
지원:

대부분 (실 사용보다는 호환성 측면에서 지원)

  • 플레이어의 수를 정의한다.
  • 없으면 기본값은 1
  • 플레이어의 수나 위치가 아니라 게임모드를 선택하는 값이다. 이하 값에 대한 설명.

    명령

    요약 게이지

    약칭

    설명
    #PLAYER 1 1P 1 guage Single Play, 1P, SP 기본
    #PLAYER 2 1P + 2P 2 guages Couple Play, 2P 최근엔 잘 지원하지 않는다.
    #PLAYER 3 1P + 2P for 1P 1 guage Double Play, DP

    최근 구동기에서는 “CENTER DOUBLE”로 넣는 모양.

    #PLAYER 4 1P vs 2P 2 guages Battle Play

    BM98 (BM98k)에서만 지원.(같은 패턴을 양쪽에서 쓴다.)

  • #PLAYER 2 는 더블플레이 전용 채보를 둘이서 플레이하는 모드이다. 합주 내지는 듀엣. 1P와 2P가 내려오는 노트가 다를 때가 많다.

    • “Couple Play” 는 beatmaniaIIDX 19 Lincle 에서 삭제되었다.
    • 그 대신 싱글플레이를 위한 채보를 두명이서 플레이 할 수 있는 “FREE PLUS” 모드가 추가되었다.
    • 예를 들면, 1P에서는 “DIAVOLO (SP-HYPER)”,를 치고 2P에서는 “DIAVOLO (SP-ANOTHER)”를 치는 식.
  • “Battle Play” 는 “Single Play” 패턴을 양쪽에서 같이 플레이 하는 것을 의미한다.

    • 이 모드는 두 플레이어가 같은 SP 패턴을 동시에 플레이하고 점수를 비교한다.
    • 파일에서 #PLAYER 1 로 정의해도 프로그램단에서 가능하도록 할 수 있다.

      “Battle Play”만을 위한 패턴을 만들 필요는 없는 것이다.

    • 파일 규약이 무의미 해지면서 BM98 이후의 모든 BMS 구동기는 #PLAYER 4.
    • #PLAYER 2  역시 구동기단에서 비슷하게 구현한다.
  • 비트매니아의 “Single Play” 플레이 화면은 3단으로 고정된 레이아웃이다.

    +--------+ +--------+ +--------+
    |1P side | |movie   | |2P side |
    |notes   | |display | |notes   |
    +--------+ +--------+ +--------+
    • 왼쪽: 1P 패턴
    • 가운데: 영상
    • 오른쪽: 2P 패턴

    오락실의 물리적인 비트매니아 기기에서는 이러한 디자인이 채택되었다.

  • 하지만 BMS에서는 이 레이아웃이 크게 채택되지는 않았다.

    • PC 키보드는 두 명이 동시에 작업하도록 만들어지지 않았기 때문
    • 두 사람이 하나의 키보드를 동시에 쓰는건 별로 좋은 방법은 아니다.
    • 그래서 “Couple Play”나 “Battle Play”는 크게 환영 받지는 못했다. 대신 온라인기반 대전이 퍼지기 시작했다.
  • BM98, BM98de, DDR, bemaniaDX, DDR, and fgt++ 는 이 3단 고정 레이아웃을 그대로 사용했다. 몇몇 LR2 스킨에도 적용되었다.

    그러나 이 레이아웃은 다른 구현에 비해 완전하게 보이진 않았다.

  • By these reasons, #PLAYER 2 and #PLAYER 4 are implementation-depending.

    • For example, bemaniaDX interprets #PLAYER 2 and #PLAYER 4 as #PLAYER 3.
  • The beatmania type apps are implementing “Double Play” surely. It is #PLAYER 3.

    • It is because DP is in game mode which is very popular in beatmania.
    • The layout of DP which 1P-side musical score and 2P-side musical score do not adjoin may be commonly called “TWIN MIX PLAY (TMP)”.

      • Since early beatmania series was not supporting “CENTER DOUBLE”, DP was very difficult.
    • The play screen of “CENTER DOUBLE” is the layout which 1P-side musical score and 2P-side musical score adjoin.

      +--------+ +--------+ +--------+        ┌┐+--------+ +--------+┌┐
      |1P side | |2P side | |movie   |        └┘|1P side | |2P side |└┘
      |notes   | |notes   | |display |   or   ┌┐|notes   | |notes   |┌┐
      +--------+ +--------+ +--------+        └┘+--------+ +--------+└┘

      The movie screen is displayed on spaces other than musical scores.

      Some implementations can display the movie by multi-views. (http://www.youtube.com/watch?v=FtQ8woowZiM)

    • “CENTER DOUBLE” appeared for the first time by beatmania complete MIX 2. ()

      Therefore, some old BMS implementations are not supporting “CENTER DOUBLE”.

  • Since #PLAYER does not bind channels, #PLAYER 1 and the channels #xxx21-29 can be written side by side.

    for example: in nazobmplay: remarks
    #PLAYER 1
    #00111:1100000000000000
    #00121:2100000000000000
    #00122:0022000000000000
    #00123:0000230000000000
    #00124:0000002400000000
    #00125:0000000025000000
    #00128:0000000000260000
    #00129:0000000000002700
    #00126:000000000000002S
    in_nazobmplay

    In implementation which depends for the rendering on the #PLAYER command, a problem occurs.

    Since it is #PLAYER 1, “Single Play” is applied as game mode.

    However, naive implementation will also display the 2P-side objects.

    This bug of rendering is intentionally caused by some humorous musical scores.

    How to count the objects which player should hit is implementation-dependent.

  • Modern implementation does not trust #PLAYER any longer.

    • LR2, nanasi, ruvit, and pomu2 disregard #PLAYER and guess actual play mode by the parsed channels.
    • Since this method does not make a naive mistake, it is better than dependent on #PLAYER.
    • However, the method of guessing play mode by channels may not work.

      • When the musical score is using only the channel #xxx16, it has a possibility that the following all corresponds:

        5KEYS, 7KEYS, 10KEYS, 14KEYS, 9KEYS (if the filename extension is PMS), 18KEYS…

        Implementation cannot judge which is the play mode which noter desires.

      • When the channel #xxx21-29 is not used but only #xxx41-49 or #xxx61-69 is used:

        Although visible objects do not exist in 2P-side of this musical score, noter wants the rendering to be carried out as DP.

        But old ruvit was interpreting this musical score as SP. (fixed in b5p6)

    • For the moment, BMS format does not have the method of solving these problems theoretically.

      • Therefore, LR2 and ruvit are processing the exceptional musical score by hardcode individually.
      • Next-generation format will adopt notation which can specify play mode in detail in order to solve this problem theoretically.
      • It will use identifiers like the #OCT/FP command as flags.
  • In recent years, #PLAYER only exists for backward compatibility.

 

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다