소식

안녕하세요, 이뿡식입니다. 8월에는 수정된 기획에 따라 엔진을 변경하는 큰 변화가 있었습니다. 재미있게 읽어주시면 감사드리겠습니다. 엔진을 바꾸기로 했다 그리드 인벤토리가 아닌 일반 인벤토리를 사용하기로 하면서 게임에는 인벤토리, 퀘스트, 대화 기능만 남게 됐고, 이 정도는 다른 비주얼 노벨 툴로 구현할 수 있다고 판단해서 개발 초기에 빠르게 엔진을 교체하기로 결정했습니다. 물론 지디벨롭으로도 위의 기능 구현에 큰 문제는 없지만, 대화 스크립트 작성에 yarn spinner 클래식을 사용해서 기능이 제한적이고+파서에 버그가 있어 명령어가 빠르게 실행됐다가 느리게 실행됐다가 종잡을 수가 없다는 점에 불만을 가지고 있어 더욱 엔진 교체의 필요성을 느꼈습니다. 어떤 툴을 사용할까 렌파이 https://www.renpy.org/ 비주얼 노벨 툴로 바꿔야겠다고 생각했을 때 가장 먼저 떠올린 것은 단연 렌파이입니다. 파이썬을 사용해서 다양한 기능을 추가할 수 있다는 확장성, 두터운 커뮤니티, 상세한 도움말 문서 등의 장점이 있습니다. 하지만 제가 파이썬을 몰라서 버그가 발생했을 때 스스로 해결하기가 어렵다는 점 때문에 후보에서 탈락하게 됐습니다. 라쿠고, 다이얼로직 https://github.com/dialogic-godot/dialogic 둘 모두 고도 엔진 비주얼 노벨 라이브러리입니다. 렌파이와 마찬가지의 이유로(GD스크립트를 몰라서 버그를 스스로 고칠 수 없다) 탈락했습니다. 투스데이 https://kirill-live.itch.io/tuesday-js 투스데이는 5년 전에 출시됐는데도 업데이트가 활발하고 생각보다 커뮤니티 규모가 있어서, 조용히 치고 올라오는 강자라는 인상입니다. 스크립트가 아닌 노드를 사용해서 스토리를 쓸 수 있고, JS 엔진이라 html css js를 알고 있다면 쉽게 수정할 수 있습니다. 하지만 이미지가 엄청나게 깨져서 픽셀아트 그래픽에 치명적이라 탈락했습니다. 트와인 https://twinery.org/ 서양권에서는 렌파이는 물론 알만툴(!) 이상의 인기를 가진 인터렉티브 픽션 엔진입니다. 투스데이처럼 JS 기반의 엔진이라 웹 개발 지식이 있다면 쉽게 수정이 가능하고, 노드로 대화문 사이를 이어서 스토리를 쓸 수 있습니다. 또 알만툴처럼 커뮤니티에서 다량의 스니펫과 테마를 배포하고 있기 때문에 이것들만 사용해도 근사한 게임을 만들 수 있습니다. 다만 근본이 인터렉티브 픽션 엔진이라 이미지 사용이 제한적이고 그마저도 깨지는 경우가 많아서 탈락했습니다. 티라노빌더 https://tyranobuilder.com/ 티라노 스크립트의 GUI 빌더로, 연출부터 스크립트까지 코드 한 줄 없이 블럭만 쌓아서 개발할 수 있어 매우 쉽습니다. 그러나 성능, 보안 문제가 있고 게임의 규모가 커지면 가독성이 크게 떨어져서(사실 이쪽은 모든 이벤트/블럭 기반 툴의 고질적인 문제) 탈락했습니다. 나랫 https://narrat.dev/ 디스코 엘리시움 스타일의 CRPG를 만들 수 있는 엔진입니다. 인벤토리, 퀘스트, 스킬 체크 등 CRPG에서 흔히 보이는 기능을 기본으로 제공하고, 엔진의 설정 파일 또는 CSS로 UI를 수정할 수 있지만 새로운 UI를 추가하기 위해서는 vue를 써야 하는 등 다른 JS 기반 엔진에 비하면 약간의 난이도가 있습니다. 비교하자면 렌파이 > 나랫 > 기타 JS 엔진 > 티라노 빌더 순서로 쉬워진다고 생각합니다. 제가 원하는 기능이 이미 만들어져 있고, 스스로 버그를 고칠 수 있기 때문에 최종적으로는 나랫 엔진으로 교체하기로 결정했습니다. 진행 상황 모달과 배경을 제외한 UI를 다듬고, 나랫에는 없는 기타 기능(미션의 남은 턴을 표시하는 게이지 등)을 만들고 있습니다. 특히 지디벨롭에서는 성능 코스트가 심해서 쓰지 못했던 연출을 CSS로 가볍게 적용할 수 있어서 만족하고 있습니다. 그리고 플라이의 디자인을 다시 리파인했습니다. 아무리 그래도 서부극, 로드트립을 레퍼런스 삼은 게임에 하라주쿠 스트릿을 입은 캐릭터는 좀 아닌 것 같아서 작품의 톤에 맞게 펑키하게 바꿨습니다. 호불호가 갈릴 수 있을 것 같아 좀 걱정입니다만... 그건 예전에도 그랬어서(ㅋㅋ) 별다른 문제가 없다면 이대로 픽스할 듯 합니다.

안녕하세요, 이뿡식입니다. 7월에는 지난 6월에 개발을 쉬면서 생각했던 문제점을 개선하기 위해 기획과 UI를 수정했습니다. UI 개선 기존의 레이이아웃은 중앙에 인벤토리가, 사이드에 대화창이 있는 구조였습니다. 그러다보니 대화창이 옵션이고 인벤토리가 메인처럼 느껴지게 되어서 게임의 흐름을 설계하기가 어려웠습니다. 게임에서 계속 쳐다봐야 하는 건 인벤토리가 아니라 대화창과 미션인데 말이죠. 또 아이템에 피직스를 적용해서 실제 물건처럼 쌓이게 한다는 아이디어도 처음에는 획기적으로 보였지만 가방이 꽉 찼을 때 피직스가 불안정해지는 점, 아래쪽에 깔린 아이템을 꺼낸 후에는 잉여 공간을 없애기 위해 계속 정리를 해야 한다는 점 등 갈수록 장점보다는 단점이 더 두드러졌습니다. 다양한 게임과 강의를 보며 수련 기간을 가지고 다시 수정한 레이아웃입니다. 여행 수첩이라는 컨셉으로, 게임 속 세계를 묘사하는 중요한 역할을 하는 미션과 대화창을 중앙에 놓았습니다. 설정, 스탯, 인벤토리 등 부수적인 정보는 가장자리로 밀어서 필요할 때 마우스로 클릭하거나 호버해서 확인하도록 했습니다. 인벤토리의 중요성이 낮아진만큼 피직스를 제거하고 격자 그리드에 아이템을 배치하는 일반적인 인벤토리로 바꿀 예정입니다. 스탯 또한 중요한 정보이니만큼 중앙에 놓는게 낫지 않을까 고민중인데, 스탯을 HUD로 표시해서 현재의 컨셉(여행 수첩)을 깨는 건 피하고 싶습니다. 좀 더 시간을 두고 생각해봐야 할 듯 합니다. 스토리 UI와 함께 스토리에도 많은 변화가 있었습니다. 스포일러가 되지 않도록 시놉시스만 간략히 말씀드리자면, 소를 다루는 능력을 가진 주인공 플라이(의뢰인)가 정부의 소를 관리하는 카우걸이 되기 위해 잭(용병)과 함께 수도로 여행을 떠난다는 내용입니다. 뜬금없이 초능력이나 소라는 설정이 생겨서 전작을 플레이 하신 분들께 어색하게 다가올 것 같아 걱정입니다만, '플라이와 잭이 여행을 떠난다' 외에는 없다시피 하던 크램프드 로드의 스토리에 개연성과 깊이가 생겼다고 생각합니다. 아마도…!

안녕하세요, 이뿡식입니다. 5월에는 BIC 제출을 위해 열심히 개발했고... 실패했습니다! 하지만 개발을 시작한 이래 가장 진척이 큰 달이었습니다. 역시 개발 의욕을 끌어올리는 데에는 이런 행사나 지원사업의 힘이 강한 것 같습니다. 프로토타입 개발 기본적인 대화, 보상, 전투 시스템을 완성하고 3개의 스토리 인카운터와 12개의 랜덤 인카운터로 구성된 프로토타입을 만들었습니다. 하지만 개발 막바지에 인카운터들을 모두 연결했을 때 예상치 못한 버그가 터져서 제출을 실패했습니다. 나중에 끈질기게 디버깅을 해보니 yarn spinner 스크립트 파서 자체에 문제가 있어서 같은 커맨드를 사용해도 실행이 되거나, 안 되거나, 늦게 되는 등 제멋대로였던 것이었습니다. 시간이 좀 더 있었다면 제출이 가능했을 텐데 아쉽습니다. 처음부터 만들어보자 버그를 발견하고 나니 yarn과 연계된 모든 이벤트를 다시 만들어야 하는 지경이 되어서, 테스트 플레이에서 발견된 문제를 개선할 겸 해서 아예 처음부터 다시 만들어보자고 생각했습니다. 1안입니다. 게임기 모양 프레임을 포기하고 내부 요소를 키우고, 네오 브루탈리즘을 참고한 플랫한 디자인으로 변경했는데, 포스터와 달리 게임 화면은 요소의 크기나 색상 조정이 제한적이다보니 시인성이 낮아진 것 같고...무엇보다도 화면이 심심해서, 이 때 만든 대화+로그 저장 기능 빼고 전부 폐기했습니다. 이후 개발을 조금 쉬면서 기획과 UI에 관한 공부를 하고 다시 만든 2안입니다. 기존의 게임과 가장 큰 차이점은 인벤토리입니다. 그리드 인벤토리에서 동물 타워처럼 피직스를 사용해서 물건을 쌓는 인벤토리로 변경했는데, 다른 그리드 인벤토리 게임처럼 그리드를 활용한 메카닉(같은 열의 아이템을 강화하는 등)이 없을 것이라면 굳이 어렵고 리소스도 많이 잡아먹는 그리드를 구현할 필요는 없다고 생각했습니다. 그리고 가방 아래쪽은 물건, 가방 위쪽은 정보(메모, 사진, 로켓 등 스토리의 단서가 되는 아이템)를 저장하는 인벤토리로 구분해서, 커다란 가방을 보면서 진행하는 아기자기한 CRPG라는 컨셉을 강화했습니다. 컨셉에 맞춰 스토리도 둥글게 변경할 예정입니다. 프로그래밍 저는 지금까지 모든 이벤트를 한 씬에 때려넣고 개발을 했는데... 규모가 있는 게임에서는 이렇게 하면 유지 보수가 어렵다는 사실을 깨달았습니다! 그래서 이벤트를 기능별로 정리해서 외부 이벤트로 만든 다음 상황에 따라 불러오도록 해서 당장 불필요한 이벤트를 차단하고, 이벤트의 시인성도 좋아지도록 정리했습니다. 각 이벤트를 논리적으로 구분하는 일종의 교통경찰이 생긴 셈입니다. 또 Gdevleop를 쓰지 않는동안 프리팹이라는 기능이 생겨서 이것을 활용해 아이템의 이름과 개수를 표시하는 프리팹을 만들어보았습니다. 기존에는 오브젝트에 수동으로 요소를 결합시켜야 해서 이런 오브젝트가 화면에 많이 있으면 성능이 떨어질 수밖에 없었는데, 이제 여러 오브젝트를 하나의 프리팹으로 만들어서 성능 걱정이 덜해졌습니다.