구현에 앞서 기획을 하거나 계획을 세울 때, 항상 내 게임에서 어떻게 구현되어야 좋을까에 대해 고민해봐야 함.
단순히 다른사람들이 이렇게 구현하니깐, 이렇게 구현하는게 멋지니깐 등의 이유로 결정을 내리면 안됨.
왜 이런 생각을 했냐면, 지금까지 바이옴은 반드시 노이즈로 구현해야한다는 생각에 사로잡혀 있었어.
근데 내 게임의 맵은 고작 6km x 6km 크기이고, 여기에 꽤나 큰 산이 하나 들어가는데,
여기서 노이즈로 바이옴을 생성하기엔, 결과가 불안정해.
게다가, 여기에 높이를 기반으로 바다를 넣으면, 실질적인 맵이 너무 작아지고, 유일하게 들어간 사막 바이옴이 바다에 가려서 사라지는 등의 문제가 발생할 가능성이 있어.
그리고 바이옴의 크기에 대한 컨트롤이 어려워서 엄청 작은 바이옴도 나오고 큰 바이옴도 나와.
괜찮아 보이는데? 싶을수 있지만,
실제론 모든 바이옴을 모든 시드에서 비슷한 비율로 내보내기 위해 노이즈의 빈도를 상당히 증가시켜서 그래.
실제로 보면 바이옴들이 다 너무 작아.
고려중인 새로운 바이옴 시스템은 이러해.
이러면 바이옴에 대한 100% 컨트롤을 가져갈 수가 있어.
강도 노이즈를 이용하지 않기 때문에, 원하는 바이옴에 길게 설치해줄 수 있어.
바이옴의 형태 등에 확신을 가질 수 있기 때문에 절차생성을 할 때 좀 더 적극적인 방법을 이용해도 될 것 같아.
작은 월드인만큼 자유자재로 꾸미기 위해서는 이런 방식이 좋다고 판단했어.
실제 세상을 떠올리면 부자연스러워 보일 수 있다는건 아는데, 실제 내 게임의 게임플레이를 상상해보면 이게 나을것 같아.
애초에 실제 세상은 6km x 6km의 반복되는 세계가 아니잖아.
게임의 컨셉을 간단히 소개하자면, 의문의 장치를 주어서 실행시켰더니, 주변환경이 바뀌고, 돌아가기 위해선 생존하면서 장치를 보호/충전 시켜야 하는 게임이야.
그래서 좀 더 이런 "게임"같은 환경이 어쩌면 더 재미가 있을수도 있다고 생각했어.
고정관념에서 벗어나서 사고의 초점을 "재밌는 게임을 만들기"에 맞추는 습관이 필요해보여.
그건 그냥 대작병 초기증세임 ㅇㅇ 나는 코딩을 잘하니까~ 하는 개허세로 만들기만 하면 키우기 게임 다바른다 상상딸치는거. 뭐 절차생성? 최적화? 지랄 ㅋㅋ 언제 완성하려고. 플레이어의 첫번째 마을 첫번째 30분 플레이도 재밌게 설계 안하면서 기술딸치면 6개월동안 코딩만하다 접음. 남들이 바보여서 안하는게 아님. 알면서 안하는거
어려운 길이라는거 알아. 너가 생각하는것보다 오랫동안 고민했고 어떤 게임을 만들지도 확고해. 남들이 바보여서 안하는게 아니라 내가 바보라서 그냥 끝까지 하는것 뿐이야. 무슨 소리를 하고싶은지 알겠는데, 개발 시작한지 1년 넘어가고 있고, 코딩한 시간만큼이나 게임에 대해 생각한 시간도 길어.
1.234님께서 출시하신 게임의 첫번째 마을은 재밌겠구나 우와~ 30분 정도 플레이해보고 싶어요~ - dc App
길게 보자 개발은 마라톤이니까
고마워, 번아웃 안오게 조심해야지.
윗댓말대로, 바이옴이 어떻고 어떻고, 게이머한텐 알바가 아님. 코드에 잡아먹히지마라 재미랑 상관 없는 요소는 과감하게 버리셈
바이옴은 게이머한테 알바가 맞음. 게임 핵심요소인데 포기 못하지. 그래도 요즘 많이 버리고 있어. 길찾기라던가 그런거.
인디가 로그라이크 많이 하다보니 절차생성을 쉽게 상상 하기마련인데 이 늪에 빠지면 몇년간 게임안나옴
맞는 말인데, 그건 절차생성의 목표에 따라 다르지. 내가 하려는건 그리 고차원적인게 아니야.
보드게임 판 까는거같네