킹머핀의 제작 일지
리듬 노트 생성 시점 본문
나는 리듬 노트를 생성하면 정해진 시간 동안 시작 위치와 판정 위치를 흐른 시간만큼 보간하며 이동하게 만들었다.
이 때 속도를 조절하기 위해서 처음에는 이 두 위치의 간격을 조절하는 방법을 생각해보았다. 정해진 시간 동안 이동할 것이므로, 간격을 벌리면 빨라지고 좁히면 느려질 것이다.
이 방법은 속도가 너무 빠르면 불필요하게 화면 밖 너무 멀리서부터 생성되고, 너무 느리면 화면 안에서 생성될 수 있지만, 최소 속도를 고려해 화면 밖으로 거리를 둔다면 딱히 문제는 아니다.
장점: 구현이 간편함.
단점: 활성화 중인 리듬 노트가 너무 많아서 성능에 취약할 가능성이 있음.
다른 방법으로는 개별 리듬 노트의 총 이동 시간을 조절하는 방법이 있다. 시작 시간과 이미 흐른 시간을 제어하면 된다. 그렇다면 속도에 따라 리듬 노트가 나타나는 시간도 다를 테니, 미리 생성되는 시간을 계산해야 한다.
이 방법은 만약 속도를 변경한다면 이미 생성된 리듬 노트를 다시 비활성화해야 할 수도 있다는 번거로움이 있다.
장점: 최적화에 유리함.
단점: 번거로운 구현.
둘 다 기능적으론 차이가 없다. 아직 뭐가 더 나은지도 확신이 안 선다. 그렇다면 2중 속도 조절을 구현하는 경우도 따져보자. 가령 전체 속도와 개별 리듬 노트 속도를 따로 조절한다던가.
1. 두 위치의 간격을 조절하는 방법: 전체 속도에 따른 거리에 비례해서 개별 리듬 노트 생성 위치를 갱신해야 함.
2. 총 이동 시간을 조절하는 방법: 애초에 시작 시간으로부터 목표 시간까지 정확히 도달하는 방식이라서, 생성 시간을 이중으로 갱신해야 한다.
그러니까 정확히는, 원래 생성되어야 했을 시간으로 이미 생성된 시간과 흐른 시간을 미뤄야 한다. (이 당연한 걸 한 시간이나 고민해서 결론 내렸다.)
첫 번째 방법 당첨.
이유1: 두 번째 방법을 고민한 이유는 단지 최적화 때문인데, 큰 차이가 없을지도 모른다.
이유2: 두 번째 방법은 번거롭다. 난 언제가 쉽고 간편한 걸로 한다.
이유3: 두 번째 방법의 결론을 내리기까지 긴 시간이 걸린 건 내가 아직도 멍청하기 때문이기도 하겠지만, 관련된 다른 문제로 애먹을 가능성이 있다.
오늘도 "고민보다 Go"에 실패했다. 난 진짜 어쩌면 좋냐.
+ 23.1.12. 추가
ㅋㅋㅋㅋㅋ 오랜만에 블로그에 들어 와서 읽어 봤는데, 이 글이 리듬 노트 관련 글인지 한탄 글인지 구분이 안 된다! 뭐, 남들 보라기보단 나를 정리하기 위해서 쓰는 글이긴 하지만.. 과거의 나를 보니 재밌네. 역시나 자책하고 있구나! 괜찮아, 미래의 너는 결국 달라져 있으니까. (게다가 프로그래밍은 관뒀다구 해방됐다구)
'인디 게임 개발 > 개발 일지' 카테고리의 다른 글
AutoHotkey vs Power Automate (0) | 2023.07.31 |
---|---|
로우레벨 텍스트 프로그래밍이 적폐인 이유 (0) | 2023.07.31 |
부정형 함수와 긍정형 함수 중 문자열 유효성 판단에 무엇이 더 합리적일까 (0) | 2022.08.06 |
스프레드 시트를 Construct 3 에디터로 옮기는 과정 (0) | 2021.07.03 |
습관 오답 노트 (0) | 2021.07.01 |