참고: 이 일지는 네이버 카페로부터 옮겨진 레거시 게시물입니다.
![](https://blog.kakaocdn.net/dn/qGGWe/btrSM49ZWVu/KTlAfLzJ8rwVc7g1cx62k1/img.png)
개선 이전
![](https://blog.kakaocdn.net/dn/cbQgcD/btrSSMOgOrt/gXZ6Z8LDolTkID4KilLFrK/img.png)
이후
사실 코드를 짜고 테스트를 할 때마다, 이 약간의 컴파일 딜레이가 굉장히 거슬렸습니다. 어느 부분에서 얼마나 걸리는지 확인을 했고, 스크립트 초기화 과정만 약 5초가 걸린단 사실을 알아냈습니다.
먼저 불필요한 명령어 초기화를 걷어냈습니다. 이들은 애당초 디코 봇 개발 초기, 게임 기획 이전부터 약간의 연습과 슬래시 커맨드 등록 자동화를 위해 만들었던 일종의 샘플들이었기에 굳이 지금 사용할 필요가 전혀 없기 때문입니다.
![](https://blog.kakaocdn.net/dn/B0Sfa/btrSLJkPbAU/nJJRHOcS6bIKDOhYpxLIOk/img.jpg)
![](https://blog.kakaocdn.net/dn/bi46L8/btrSRR3fOdA/9K2CL6xsBU9kaUpEW0sA1K/img.png)
두 번째로 명령어 초기화도 최적화를 했습니다. 이 초기화 과정은 게임을 재시작할 때마다 실행되는 초기화 과정과 달리, 디스코드 API 요청을 통해 소스코드에 저장된 명령어들을 디스코드에 업로드하는 과정입니다. 명령어와 관련된 모든 데이터들은 변경 시 무조건 이 과정을 거쳐야 합니다.
무기 변경은 전투 이벤트에서 변경 기능이 이미 있어서 필요가 없고, 선택지 초기화는 디버그 용도여서 그 문제가 해결된 지금은 필요가 없습니다. 이 둘을 제거하니 초기화 속도가 많이 개선되었습니다.
![](https://blog.kakaocdn.net/dn/cBpmou/btrSJX4Roow/LT0W0OoB7JDqmKQHOzvx11/img.png)
![](https://blog.kakaocdn.net/dn/bzObqw/btrSSLIBb9W/kGtKhQI4U7lcIkBWs9DqK1/img.png)
아이템 소모에서 소모 개수를 선택할 수 있게 만들었습니다. 이에 따라 개수가 보유량을 초과하면 에러를 출력하게 만들었습니다. 선택한 아이템이 없거나 포션이 아닐 비정상적인 경우에도 에러 메시지를 대비해두었습니다. 이들은 타입 스크립트에서 잘못된 import, export로 인해 일부 타입 체크가 무시되었을 경우 게임이 망가지는걸 어느 정도 막아줄 것입니다.
![](https://blog.kakaocdn.net/dn/BCirE/btrSJUHdd0k/cYVF3qapE6K0cl6LJNvKqk/img.png)
포션, 섭취 가능한 아이템은 섭취량과 값, 유저를 인자로 가진 콜백 함수를 지닙니다. 이 콜백 함수는 아이템을 섭취할 때마다 호출되며, 갯수에 따른 능동적인 결괏값을 가능하게 만들어줍니다.
![](https://blog.kakaocdn.net/dn/chPQWD/btrSLITMcqP/3M3Z6UUGk9GiV37jC3Xoe0/img.jpg)
사실 이 봇은, 커밋 기준으로 어림잡아 약 1달 반밖에 안지난 매우 젊은 봇입니다. 저 또한 디스코드 봇 개발과 타입 스크립트 개발이 모두 다 이것으로 처음입니다. 그럼에도 불구하고 300개 이상의 커밋은 올해에 끝내보겠다는 의지, 즉 차후 만들 포트폴리오의 두 번째 수록 프로젝트의 달성 의지를 의미합니다.
처음부터 포트폴리오를 노린건 아녔습니다. 처음은 카톡 봇에서 새로운 아이디어가 없자 카페에서 다들 하는 rpg 제작이란 걸 혼자 해보자는 생각에 시작되었습니다. 처음 rpg를 만들 땐 Mindustry 모딩 경력으로 눈에 익혀온 게임 구조의 성격이 제작 중 자연스레 녹아들어 갔습니다. 선택지의 개념과 아이템 소모, 교환, 전투 등 카카오톡 봇에서의 게임 기능과 개념은 현재 디스코드 봇으로써의 기능과 별다른 차이가 없습니다. 역설적으로, 추가적인 콘텐츠 개발이 전혀 없었단 말이 되기도 하지만요.
계속 개발을 하다보니 결국 라이노 스크립트의 es6 미지원과 문법적, 성능적, 그리고 기능적 한계에 부딪혔습니다. 게임의 다양한 특징을 표출하기엔 텍스트 하나뿐인 상호작용과 텍스트, 카카오링크뿐인 표시 수단이 게임의 확장성을 저하시킨다는 걸 의식했습니다.
이때 디스코드 봇은 하나의 솔루션으로 저에게 다가와졌습니다. 주변에서 하는 유니티 엔진을 사용할 수도 있었지만 이건 게임을 더 무겁게 만들고 전에는 없었던 그래픽 요소의 부담까지 생기기 때문에 저에게는 좋지 않은 선택이었습니다.
그 이후 정말 정말, 정말로 많은 구조적 변화가 있었습니다. 단일 스크립트였던 게임은 얼마 지나지 않아 여러 개의 모듈로 이루어진 단일 프로젝트가 되었습니다. type에 instanceof를 적용할 수 없는 프로토타입 기반 언어적 문제나 discord.js, 디스코드 봇 자체에 대한 생소함과 무지함은 개발 속도를 정말 처참하게 만들었습니다. 하지만 그럼에도 불구하고 전 개발을 멈추지 않았습니다. 아니, 멈추고 싶지 않았습니다.
매일 코딩을 하는 것은 자신에게 매일 새로운 것을 느끼고 탐구하고 깨닫고 이해하게 만들어줍니다.
또한 새로운 개념을 이해하기 전, 그 개념이 없음에 따른 고통을 먼저 느끼고 그 개념을 익혀 사용함으로써 과거와 상반된 편리함을 느끼는 것은 그 개념에 대한 필요성을 확실하게 인지하도록 만들어줍니다.
결과적으로, 이러한 매일매일의 변화는 코딩을 정말 재미있게 만들어줍니다. 재미있기에 더 자주 하고, 더 자주 할수록 더 재미있어집니다. 이것이 제가 코딩을 좋아하는 이유입니다.
새벽에 글을 쓰다 보니 의도치 않게 이야기가 많이 와전되었다만 이참에 할 말은 끝내고 마칩시다.
코딩은 가끔 고통스럽기도 하고 짜증 나기도 하지만 그것들은 모두 깨달음과 함께 쾌감으로 돌아옵니다. 짜증 난다고, 어렵다고 내던지지 마시고 그것을 계속 탐구하고 시도하여 성취하는 쾌감을 아셨으면 좋겠습니다.
'프로젝트 > RTTRPG' 카테고리의 다른 글
[RPG 개발] 43일차 (0) | 2022.12.05 |
---|---|
[RPG 개발] 근황 (0) | 2022.12.05 |
[RPG 개발] RPG 개발중 (0) | 2022.12.05 |
[RPG 개발] 신나는 로컬라이징 (0) | 2022.12.05 |
[RPG 개발] 26일차 (0) | 2022.12.05 |