리버티게임:오락실/2024년 7월
리버티게임 오락실 |
---|
◀ 2024년 7월 ▶ |
새 글 쓰기 |
새로 고침 |
이름 바꾸기 요청은 어떻게 합니까?[원본 편집]
{{준부적절}}을 편집하는데 독립 서버라서 특수:전역이름바꾸기요청이 없어진 지금은 다른 걸 넣어야할 것 같습니다.--Chabiytb0792 (토론/기여/기타) 2024년 7월 4일 (목) 15:27 (KST)
- 저는 관리자 요청은 오락실에서 받는다는 것으로 알고 있습니다. --명진 (토론) 2024년 7월 4일 (목) 17:28 (KST)
- 오락실에서 변경하는 것으로 수정했습니다. Miraheze 이전 독립 서버 시기에도 오락실에서 요청을 받았습니다. --hsl(토론, 기여, 게임, 메일) 2024년 7월 4일 (목) 17:49 (KST)
20240707 업데이트: 2024년 상반기 설문조사 결과 발표[원본 편집]
이번 달의 첫 업데이트입니다.
지난 달 처음으로 리버티게임에서 구글 폼을 이용해 설문을 진행했었습니다. 이 설문조사는 청사진 3단계 계획과 같이 추후 리버티게임이 발전할 방향에 관한 제대로 된 데이터를 수집하기 위해 시행되었습니다.
이제 리버티게임 2024년 상반기 설문조사 결과를 이전에 예고했던 대로 발표하겠습니다. 이 설문조사에는 총 9분이 응답해 주셨습니다. 결과를 분석하면서 제 의견을 추가할 것이며, 이 자료는 리버티게임:청사진 아래 별도의 문서로도 추가될 예정입니다. 이 글이 올라온 직후 기존 응답 데이터는 파쇄할 예정이며, 이후 내용을 변경하거나 보강하여 올해 11월 정도에 하반기 설문조사를 하는 것을 기획하고 있습니다.
그럼 이제부터 문항 별로 통계를 보겠습니다.
- 1번: 리버티게임의 게임 제작법에 대한 평가
먼저 리버티게임에서 사용하는 미디어위키 문법을 활용한 게임 제작법에 대한 평가입니다. 모든 응답자들께서 괜찮다 내지 매우 좋다는 평가를 내려주셨습니다.
가장 많이 장점으로 언급된 부분은 편집이 쉽다는 부분이었으며, 다양한 템플릿과 확장 기능을 조합해 게임을 만드는 부분에도 좋은 평가가 많았습니다. 확실히 하이퍼링크 텍스트 게임 제작에 최적화되었다는 의견에 저도 동의하는 바이며, HTML을 완전히 대체하는 성격만큼은 미디어위키로 만든 게임의 강점으로 남을 것으로 생각합니다.
이런 게임 제작 방식의 단점으로 가장 많이 지적된 것은 문서 편집 시스템의 불편이었습니다. 제가 생각하기에도 미리 보기 버튼을 눌러 렌더링 결과를 수동으로 요청하는 방법은 많이 불편하며, 요즘 편집기에 거의 필수로 붙다시피 하는 자동저장이나 임시저장 기능 같은 것이 편집기에 있다면 좋다고 생각했습니다. 웹 기반 공식 IDE가 있다면 완벽하겠지만, IDE의 개발에는 상당한 시간이 소요되기에 현 편집기를 개량하는 방법을 먼저 시도할 수밖에 없습니다.
그래서 먼저, 미디어위키 1.39 버전 WikiEditor 확장 기능에 추가된 실시간 프리뷰 기능을 오늘 활성화했습니다. 이제 미리보기 버튼으로 매번 결과를 요청하는 대신 편집기 오른쪽 미리 보기 탭을 눌러서 실시간으로 편집 결과를 확인할 수 있습니다. 다만 아직 기능이 구현된지 얼마 안 되어서 그런지 미리 보기 탭으로 볼 때 CSS 적용이 잘 안 되며, 편집 창 오른쪽 절반 공간을 차지하기 때문에 틀의 레이아웃(모양새) 부분에서 차이가 날 수 있습니다. 하지만 두 번 줄을 바꿔야 문서를 볼 때 줄이 바뀌는 문제 정도는 미리 예방할 수 있습니다.
그리고 임시 저장 기능을 리버티게임과 자매결연을 맺은 큰숲백과에서 자체적으로 구현했었는데, 그 기능에 관해 큰숲백과 최고관리자님께 리버티게임으로의 수입이 가능한지 여쭤보려고 합니다. 소도구 기반으로 작성된 기능이면 자동저장으로 개선하면서 개선된 부분을 큰숲백과 측에 되돌려 줄 수도 있습니다.
그 외에 눈에 띄는 의견은 다음과 같습니다.
- 문서 포크가 지나치게 쉬워 양산형 게임이 생기기 쉬운 부분에 대한 공감이 있었으며, 엔트리 같은 대체 플랫폼이 많다는 의견, 복잡한 틀의 사용법을 좀 더 쉽게 알 수 있어야 한다는 의견이 있었습니다. 개인적으로는 도움말이나 리버티게임:편집 초심자용 추천 게임에 우선 기여하는 것을 대문에서 보여주는 것이 제일 낫겠다고 생각합니다. 이건 후술할 대문 관련 이슈와 같이 다루겠습니다.
- 비영리 조건이 있는 기본 저작권 정책에 의해 게임을 제작할 동기 부여가 잘 안 되는 한계에 관해서는, 현재 청사진 3단계로 제안된 도전과제 시스템에 특집 게임 선정/게임잼 우승 항목 등을 반드시 추가하는 명세를 제시하는 방향을 먼저 생각하고 있습니다.
- ES6의 지원이 불완전한 것처럼 위키 시스템 자체의 기능이 미비하거나 엔진이 무겁다는 시스템 자체에 관한 지적도 있었습니다. 이 부분에 관해서 제출된 자유 의견을 소개할 때 같이 다루겠습니다.
- 2번: 리버티게임 게임 목록 체계에 대한 평가
다음은 현재 리버티게임:게임 목록 등에 적용된 게임 분류 및 검색 체계입니다. 제가 자바스크립트 기반 게임 목록 소도구를 처음 기획할 때만 해도 이 정도까지 빠르게 게임 목록 문서가 바뀔 것이라고 생각하지 못했습니다. 리버티게임의 JSON 편집에 막대한 기여를 하신 Hsl0님, 그리고 게임카드 틀을 제작하시고 이것을 이용해 게임 목록을 크게 개선하신 BANIP님의 기여 덕분에 현재 게임 목록의 UI가 백괴게임 시절에 비해 훨씬 깔끔해졌으며, 여기에 대해 호평이 대체로 우세합니다.
특히 분류에 따라 자동으로 관련 게임을 확인할 수 있는 점에 호평이 많으며, 모양새에 일관성이 있고 개별적인 특성 파악이 쉬워진 점도 장점으로 많이 언급되었습니다. JSON 편집으로 규칙성이 생긴 부분도 장점으로 보는 분들이 있었습니다. 이 장점들이 게임 목록 자동화 작업의 핵심이었는데, 평가가 이렇게 나오는 것으로 보아 처음 기획 당시 추구했던 목표는 확실하게 달성한 것 같습니다.
그렇다고 완전히 편리한 체계는 아니며, 엄연히 게임 제작자 입장에서 신경쓸 것이 늘어난 만큼, 단점으로 지목된 사항들도 있었습니다. 가장 많이 동의한 단점에 관한 의견은 JSON 포맷에 따라 편집하는 방법에 대해 적절한 안내가 필요하다는 의견이었습니다.
원래는 리버티게임:JSON 문서가 이 부분에 대한 도움말로 존재하지만, 이 문서를 설문조사 기간에 한 차례 보강했음에도 여전히 이해하고 편집하기에는 조금 난해할 수도 있다고 생각합니다. 현재 리버티게임에서 JSON 포맷을 사용하는 대표 사례인 게임별 메타데이터 문서(game.json 문서)의 경우 게임 목록에 자신의 게임을 제대로 노출하려면 반드시 작성되어야 하기 때문에, 관련된 JSON 생성 마법사가 리버티게임:게임 만들기에 존재합니다.
그러나 이미 만들어진 game.json 문서를 다시 편집해야 할 경우에는 미디어위키 문법과는 다른 JSON 포맷 자체를 잘 몰라 편집하기 어려워하시는 분들이 있습니다. 아마도 추후에 특수 문서를 사용하여 게임 이름을 입력하면 game.json 하위 문서를 직접 편집하지 않고 항목 별로 편집하는 기능이 필요할 것으로 생각됩니다. 이미 '특수:빈문서/DB2'라는 문서를 들어가려고 하면 Localstorage 객체를 사용하여 틀:DB2를 사용한 게임의 개인별 저장 데이터를 편집하는 소도구 기능이 리버티게임에 있으며, Localstorage 역시 JSON 객체의 일종이라 이것을 응용하여 game.json 편집기를 제작하는 방법이 제일 빠른 해결책이 될 것이라고 생각합니다.
다만 리버티게임의 게임 메타데이터는 지금도 규격 변동에 관한 요구사항이 아직 존재하기 때문에, 해당 선택 요구사항에 대한 확정이 필요하여 편집기가 바로 하반기에 도입되기는 조금 힘들 것입니다. 해당 토의가 종결될 수 있도록 다른 분들의 의견을 기다립니다.
- 3번: 리버티게임 관리단 체계에 대한 평가
다음은 관리단 체계에 대한 평가입니다. 부정적 평가 없이 대체로 호평이 우세합니다.
민주적인 관리자 선발이나 신뢰 가능한 민원 처리, 새로운 기능 추가에 대한 호평이 높습니다. 제출된 기타 의견이 없는 것으로 보아 장점은 확실하게 문항의 내용으로 요약된 것으로 보입니다.
단점 평가는 그리 많지 않은데, 이미 추가된 기능의 유지 관리 능력 등에 의문이 좀 있는 것으로 보입니다. 이 사이트가 별도의 법인이나 사업자 등의 운영 주체 없이 여러 개인이 모여 취미에 가깝게 운영하는 소규모 사이트다 보니 기능의 개선 속도가 많이 느린 한계가 있습니다. 이건 규모 상의 한계라 짧은 시간 내에 해결되긴 어려우며, 개선하는 방법도 리버티게임의 개발에 관심 있는 개발자 지인을 초대하는 방법 정도로 한정되는 점 양해해주시길 바랍니다. 타 위키 사이트 중 리브레 위키의 전례를 따라 비영리 성격의 사회적협동조합을 운영주체로 설립하는 방법은 출자금이라는 명목으로 개발에 어느 정도의 자본이 투입되기에 기능 개발 속도는 급속히 빨라지겠지만 그 순간 대한민국 게임물관리위원회의 개입 가능성을 대폭 올리며, 그외에 법적으로 고려할 것이 많기 때문에 선택이 어렵습니다.
- 4번: 리버티게임의 게임 엔진 지원에 대한 평가
다음은 게임 프로그래밍 지원에 관한 평가입니다.
현재 리버티게임은 전신인 백괴게임 시절부터 있었던 자바스크립트/루아 모듈을 사용한 프로그래밍 지원을 계승했으며 올해부터는 고도 엔진 3을 시작으로 게임 엔진 에디터를 사용해서 만든 웹 게임을 가져오는 기능이 도입되었습니다. 그러나 PluginX와 같은 스크립팅 방법은 난이도 문제가 상당히 심각하며, 엔진 지원은 배포된 게임이 하나 뿐이고 기능 구현이나 도움말 제작이 아직 초기 단계라 더 많은 작업이 필요할 것으로 예상됩니다. 이 기능에 대한 평가도 혹평은 없는데 보통의 비중이 큰 상황이라 더 많이 작업을 한 다음에 평가가 호평 위주로 바뀔 것 같습니다.
참고로 틀:고도3에 캔버스 크기 조정(가로폭 최대 800px로 제한하는 기능) 기능을 추가하게 되면 베타로 넘어가게 할 예정인데, 그러면 해당 틀이 의존하는 소도구는 계정이 없어도 기본값으로 활성화될 예정입니다. 즉 모든 사이트 방문자에게 고도 엔진 3으로 만든 리버티게임의 모든 게임이 공개된다는 겁니다. 고도 엔진 3은 아직 3D 게임을 만드는 데 부적합한 부분이 크다는 점 때문에 이 엔진으로 만든 게임의 요구 사양이 높지 않은 경향이 있고, 고도 엔진 4처럼 한동안 특정 플랫폼에서 웹 게임 관련 버그가 발생하는 상황도 없었기 때문에 지금처럼 회원 전용으로 둘 이유가 없습니다.
이제 앞으로 추가되어야 하는 스크립팅 / 게임 엔진 관련 지원 중 제일 시급한 사안에 대해 의견이 매우 갈렸는데요. 더 많은 엔진을 지원해야 한다는 의견의 비중이 단일 항목으로는 제일 컸습니다만, 기존의 PluginX나 루아 모듈 기능을 강화해야 한다는 의견의 비중도 상당합니다. 아래 기타 의견으로 아예 안 해봤다는 의견도 나왔기에 프로그래밍에 대한 쉬운 접근이라는 응답에도 주목해야 합니다.
기타 의견으로는 게임 엔진으로 만든 비영리 게임은 차라리 itch.io에 배포하는 것이 좋다는 의견이 있습니다. 당장 리버티게임에 배포 중인 Duck Invasion은 동일한 저작권 조항(CC BY-NC-SA 4.0)으로 itch.io에도 같이 배포 중이기에 이 의견도 주목할 이유가 있습니다. 리버티게임에 게임 엔진 사용 게임을 배포할 유인이 더 필요할 것 같습니다.
그리고 게임 엔진 추가 지원의 경우 유니티 WebGL과 고도 엔진 4 정도만 당장 리버티게임에 추가될 것 같습니다. 그 외의 작업(Xash3D 개발 재개 및 게임메이커, Cocos2d-x 등의 도입 등)은 수요가 대단히 낮을 것으로 예상되어, 2020년대 안에 작업이 될 가능성이 0%에 수렴할 것 같습니다.
또 프로그래밍 없이 자바스크립트로 가능한 것을 미디어위키 문법 형태로도 가능하게 해야 한다는 의견이 있었습니다. 이것 역시 중요한 부분이며, 동일한 내용이 자유 의견 란에 조금 더 자세히 설명되어 있었기에, 아래 자유 의견 소개 때 좀 더 이야기하겠습니다.
- 5번: 발전소 체계에 대한 평가
그리고 개인적으로 꼭 넣어야 하는 문항으로 판단하여 리버티게임:발전소 자체에 대한 의견을 들어보고자 5번 문항을 넣었습니다. 백괴게임 시절부터 이어진 발전소라는 시스템은 대단히 특이한데, 다른 어느 게임 배포 플랫폼을 가도 커뮤니티의 합의를 근거로 게임 배포를 직접 중단시키는 체계를 마련한 곳이 없습니다. 아마 현존하는 게임 배포 플랫폼 중에서 가장 강력하고 급진적인 QA(품질관리) 정책을 리버티게임이 가지고 있지 않나 생각합니다. 결과는 예상대로 호평이 많기는 하나 부정적 응답도 나왔으며, 리버티게임을 게임 배포 플랫폼으로 선택할 때 호불호가 갈리는 영역으로 존재할 수도 있다고 생각합니다.
역시 QA 측면에서는 저질 게임의 난립 방지가 가장 많은 응답을 받았으며, 그 다음으로 많은 응답을 받은 내용들처럼 게임의 기획과 커뮤니티의 게임 평가를 제작자/제작진이 중요시하게 되는 요소로 작용한다고도 볼 수 있겠습니다. 또한 기타 의견으로는 잊혀진 게임에 대한 발굴에 도움이 된다는 의견도 있었습니다.
다만 발전소가 게임성 향상에 도움이 되지 않는다는 의견도 나왔으며, 복수의 게임이 함께 발제된 발전소 토의의 경우 세심하지 못한 처리가 이루어진다는 의견도 공감을 얻었습니다. 그리고 제일 많이 받은 의견이 홍보 미비/참여자 부족으로 인한 토의 지연입니다. 그런데, 사실 이 부분이 제일 해결하기 어렵습니다. 지금까지 20명 정도가 리버티게임에 계정을 가지고 활동하는데, 이 중 40%에서 50% 정도가(8~10명 정도)가 발전소 토의에 참여한 기록이 있고, 다시 그 중 절반이(4~5명)가 토의에 대해 자주 의견을 제시합니다. 그리고 다시 절반(2~3명)이 모든 토의에 대해 즉시 의견을 제시합니다. 현재 저는 3명 이상의 의견이 나오면 처분을 제시하는데, 단일 발제 발전소가 3일 정도 처리가 걸리며, 처분 제시 후 유예기간까지 두는 것을 생각하면 1개의 게임이 최소 1주 가까이 걸려야 처리가 되는 수준입니다. 아마 토의가 순식간에 진행되는 것을 기대하려면 사이트에서 주기적으로 접속하는 활동적인 사용자가 50명 정도에 도달해야, 하루에 몇 개 단위로 의미 있는 의견이 달리면서 조치를 빠르게 내릴 것으로 보입니다.
그래도 복수의 게임을 합쳐서 토의하는 상황은 이미 거의 다 처리한 상황이라 이제 가급적 지양하는 방향으로 갈 것이고, 기타 의견으로 나온 기획 재활용의 문제는 내년에 도전 과제 시스템 개발 후 제1회 리버티게임 게임잼(가칭)을 열까 고민 중인데, 이 문서의 기록을 바탕으로 게임잼을 여는 방향으로 생각하고 있습니다.
- 6번: 리버티게임에서 지금 제일 중요하고 시급한 작업에 대한 의견들
역시 예상했던 대로 게임 평가 및 사이트 내 홍보 체계 개선이 가장 많은 선택을 받았습니다. 사이트 모양새의 개선과 합쳐서, 사이트에 처음 방문했을 때 이 사이트에서 제일 인기 많은 게임이 바로 눈에 띄어야 할 필요가 있습니다. 그러므로 올해 남은 최대의 작업은 게임 평가에 따른 랭킹을 구현하여 대문에 자동으로 노출하는 것으로 하겠습니다.
그 다음에는 도움말과 정책과 지침 개선입니다. 먼저 리버티게임:도움말의 배치를 바꾸고 더 많은 곳에 링크를 만들어야 할 수도 있겠습니다. 가독성이 약간 떨어지는 부분도 있고, 리버티게임 이름 공간에 있는 문서 중 여기 없는 문서가 아직 있습니다. 그 외에 사이트 기능 중 도움말이 부족한 부분(예: 게임 엔진 지원 및 튜토리얼, 유용한 틀에 대한 언급 추가, JSON 편집에 대한 조금 더 자세한 내용, 관리자 가이드 내 확장 기능 설명 등)이 있어서, 이 부분은 계속 고쳐 나가려고 합니다.
그 다음 순서로 더 많은 확장 기능을 도입하거나, 티들러위키 등 타 위키 엔진으로도 내용을 내보낼 수 있어야 한다는 확장성에 관한 의견이 있습니다. 올해부터 리버티게임과 다른 플랫폼(예: 안드로이드, iOS)의 앱을 연결하는 OAuth나 올해 확장 기능에 쓸 RatePage 같은 신규 확장 기능을 개발 서버에 먼저 도입하고 테스트한 다음 다시 본 서버에 도입하려고 하며, 신규 확장기능도 계속 탐색하고 있습니다. 다만 StructuredDiscussion[1]처럼 리버티게임에 맞지 않는 확장 기능들도 있기에, 아무 확장 기능이나 바로 도입하기 어렵습니다. 그리고 타 위키의 포맷으로 내보내려면, 현재 리버티게임에서 작동 중인 TextExtracts 확장 기능 등을 이용해 HTML/XML 형식으로 내보내는 기능 자체는 있는데, 제약이 많아서 그리 유용한 상황이 아니고, 직접 개발하기에는 애로사항이 대단히 많습니다 ㅠㅠ
그것보다 조금 더 시급한 것이 개인적으로는 모바일 편집용 앱이 아닐까합니다. 4개의 호응하는 응답이 나온 마지막 항목이며, 이전에 다른 회원 분이 노코딩 앱 제작 서비스로 만든 버전으로는 문제를 제대로 해결하기 어려웠기에 따로 만든 기획은 이미 존재하지만, 사이트 내 개발 참여 가능한 인원만으로는 올해 앱이 나오는 건 아예 불가능한 상황입니다. 외주...를 주는 것도 사이트 규모 대비 효용을 따졌을 때 테스트 인원을 구할 때라면 모를까, 개발 용도로 돈을 쓰기엔 좋은 생각이 아니구요. 아마 빨라도 내년에야 테스터를 모집하면서 개발용 채팅방도 파고 작업을 시작할 수 있을 겁니다.
그 외에 한국 외 타 국가의 공용어로 된 리버티게임 국제 사이트나, 게임 개발에 필요한 보조 프로그램들(이미지 편집/작곡 프로그램 등)도 장기적으로 필요하다고 보이는 상황입니다. 그럼 이제 클라이맥스로, 자유 제출된 의견들을 보겠습니다.
- 그 외 자유롭게 제출된 의견들
제출된 의견들 중 3개를 주목할 만하여 요약하고, 위에서 말한 것처럼 제 자세한 의견을 정리해서 밝히도록 하겠습니다.
- 피드백 1
플래시, 쯔꾸르, 로블록스 등과 경쟁하기 위해 자바스크립트 등의 기존 프로그래밍 언어를 사용해 코딩의 영역에 들어가는 순간 리버티게임의 타깃 연령층이 매력을 가질 요인인 제작 편의성이 증발하며, 그렇다고 텍스트 게임만 계속 만들기엔 플레이어가 보기에 퀄리티가 낮아 보인다. 그러므로 위키 문법 수준의 문서 작성 만으로 자바스크립트를 동원해야 했던 기능들을 구현할 수 있게 해야 하며, 이런 게임들이 돋보일 수 있도록 평가와 조회수 집계로 랭킹을 만드는 작업이 같이 필요하다.
전적으로 동의하게 되는 내용입니다. 백괴게임의 단점으로 지목되었던 내용이며, 리버티게임 창립 5주년이 다 되는 지금도 완전히 해결되지 않은 상황입니다. 게임 엔진 도입으로도 완전히 해결하지 못하는 것이, 고도 엔진 3에는 자바스크립트처럼 별도의 줄글 문법으로 코딩하는 GDScript 뿐만 아니라 VisualScript[2]라고 엔트리의 블럭 코딩 같은 일이 가능한 확장 기능이 있기에 제가 바로 도입을 했지만, 이게 기능 설명이 영어로 되어 있다는 문제가 있습니다. 그래서 이쪽을 더 강조하기도 어려운 상황입니다.
이 문제의 근본적인 원인은 플레이어가 '실시간'으로 입력을 하여 '실시간'으로 화면에 보이는 내용을 바꿀 수 없다는 점에 있습니다. 즉 키보드나 마우스를 눌렀을 때 생기는 '입력 이벤트'에 대응하는 콜백(Callback)과 1초에 60번 화면을 갱신하는 프레임 단위 동작을 틀이든 확장 기능이든 소도구로든 빨리 구현을 해야 하는 상황입니다. 그러나 미디어위키 문법은 원래 웹 페이지를 만들 때 필요한 기능인 HTML, CSS, 자바스크립트 중 HTML(HyperText Markup Language)만을 대체한다는 점입니다. CSS는 확장 기능으로 따로 적어줘야 하고, 자바스크립트는 반드시 커먼자스와 소도구 기능을 불러와야만 사용 가능하도록 되어 있습니다.
그렇기 때문에 저는 현재 리버티게임의 파서 함수와 유사한 규칙을 가지며 별도의 문서나 이름공간에 필요한 동작을 적도록 하는 위키스크립트라는 것을 생각하고 있습니다.
백괴사전이나 디시위키처럼 틀을 도배하면 안 되겠냐고 생각할 수도 있겠지만, 페이지마다 초기에 정해진 값을 딱 한 번 적어주면 되는 현재 리버티게임 게임 제작 체계와, 1초에 60번씩 언제 끝날지 모르는 어마어마한 양의 동작을 한 페이지 안에 구겨넣는 상황은 아무리 가능한 경우의 수를 줄인다 해도 작성해야 할 글의 양이 차원이 다르며, 이런 경우 사이트 개발자가 하나의 기능을 추가하게 되면 그 기능과 아주 작은 차이만 있는 최소 수십 개의 파생 기능에 대한 요구가 생깁니다. 차라리 최소한의 논리적인 동작을 게임 제작자가 직접 적어야 하는 문서를 마련하는 작업이 훨씬 낫고, 그것을 생각하면서 만든 것이 지금 소개한 위키스크립트입니다.
이 위키스크립트는 위키 문서의 '문단'에 따라 필요한 동작을 구분하여 적게 되어 있는 등 위키 문법과의 유사성을 가장 중요하게 생각합니다. 아직 확정된 내용도 아니며, 명세대로 설계하고 구현하는 데에도 시간이 많이 필요합니다.[3] 화면에 표시되는 내용은 가능하면 canvas 요소[4]이면 좋겠지만, 미디어위키 문법이 이미 지원하는 표(table)로도 화면 출력이 가능하면 좋을 겁니다. 그러면 미디어위키 표에다 HTML id만 적어줘도 그 표의 내용을 바꿀 수 있으니까요.
게임 평가 시스템의 경우 현재 개발 서버에 문서 평가 데이터베이스를 구축하고 문서별 별점 평가 기능을 주는 RatePage 확장기능을 설치했으며, 이 확장기능은 게임 토론이 있는 토론 이름공간에서 별점을 부여할 수 있게 설정했습니다. 남은 작업은 이 확장기능이 만드는 데이터베이스에 백괴게임 시절부터 있었던 기존 문단별 평가를 추가하는 기능을 API로 구현한 다음 그 평가에 따른 결과를 게임카드 틀로 내보낼 수 있도록 쉼표로 구분된 문자열을 루아 모듈이 게임카드 틀을 해석하기 전에 먼저 보내는 기능만 추가하면 됩니다. 물론 하위 토론 문서의 별점은 반영하지 않도록 '/' 문자를 제외할 필요는 있습니다만, 이 문자를 이름에 쓰는 게임이 있기 때문에 도입에 신중할 필요가 있습니다. 그냥 편집 필터 설정 후 기존에 있던 게임들의 이름을 몇 개 바꿀 수도 있고요,
- 피드백 2
구글 플레이에는 현재 대문에서 관심 있는 게임 주제를 선택하고 게임 목록에서 평점 정보와 최근 업데이트 여부를 알려주는 기능이 있는데 리버티게임에도 이런 요소가 필요하다. 그리고 리버티게임이 사용하는 미디어위키 엔진은 기능은 다양하지만 상당히 무거운 단점이 있으므로, 경량화된 엔진을 원한다면 리브레 위키의 리버티엔진 개발에 참여하면서 사이트 엔진을 옮기는 방법이 있다.
현재 리버티게임 대문은 올 하반기에 한 번 갈아치울 계획이 있습니다. 작년 하반기에 있었던 대문 모양새 제안의 내용을 현재 개발 서버에 옮겨 둔 상황이며, 게임 평가 체계 도입과 연동하여 늦어도 연말에는 리버티게임 대문 버전 3을 제작하려고 합니다.
그리고 리브레 위키와의 협력 및 리버티엔진 개발 참여의 경우는 리버티엔진이 2020년대 들어 개발이 사실상 중지된 모양새가 되어서, 리버티게임 측이 개발에 합류한다고 가속이 급격하게 붙을까 싶긴 한데, 지금 리버티게임에 있는 자바스크립트 소도구 등을 전부 타입스크립트(Typescript)로 개발한 후 변환하여 적용하는 방법을 응용한다면 또 달라질 수도 있다고 생각하고 있습니다. 왜냐하 ES5 버전 문법으로 자바스크립트 코드를 작성하는 일이 이젠 상당히 비효율적으로 변한지 오래되었기 때문입니다. 이미 Hsl0님이 DB2 틀에 쓰이는 소도구부터 타입스크립트 개발 환경으로 옮기려는 시도를 하고 계셔서, 제가 같이 뛰어들면서 위에 소개했던 위키스크립트 파서나 다른 소도구까지 통합하여 개발 방법을 바꿔 타입스크립트로 사이트 기능을 개발하는 방향에 가속을 붙이려고 합니다. 그리고 타입스크립트와 리버티엔진 모두 Node.js에 기반하여 개발하게 됩니다. 그래서 어쩌면 추후에 리브레 위키 측과 엔진 기능 개발 측면에서 접점이 생길 수도 있겠습니다.
- 피드백 3
리버티게임 이용자들의 사이트 유입 경로와 주 관심 분야(ex. 철도, 코딩, 음악 등)를 조사하여 외부 홍보 전략과 내부 운영 전략을 재고할 필요가 있다.
좋은 아이디어입니다! 이건 하반기 설문조사부터 반드시 반영하도록 하겠습니다!
응답해 주신 모든 분들께, 좋은 의견 감사하다는 말씀 전해드립니다. 오늘 나온 결과에 따라 진행되는 프로젝트들의 상황은 추후 오락실에 계속 업데이트로 공유하겠습니다.
--Senouis(토론장, 기여) 2024년 7월 7일 (일) 02:29 (KST)
- ↑ 게시판 형태로 토론 문서를 바꾸는데, 기존 토론 데이터가 없어지는 것은 물론, 동시에 게임 평가 문단이나 이슈 보고 같은 고정된 문단을 위해 API로 파싱하는 것이 불가능해집니다. 하위 토론 문서를 만들기 어려운 것은 덤이고요.
- ↑ 고도 4.0에서 지원 중단
- ↑ 살짝 구현하는 기술에 관해 이야기를 하자면, 위키스크립트를 틀 형태로 인용할 경우 대응하는 소도구에 실행 스택(Exection Stack)이라는 것이 반드시 구현되어야 합니다. 적어도 1초에 60번씩 화면을 바꾸다가 키보드 방향키를 누르면 잠깐 키보드 이벤트 콜백으로 건너갔다가 되돌아오는 작업이 필요해서, 프레임 단위 동작만 하는 바닥 상태에서 콜백 실행 상태를 쌓아 올리고 끝나면 다시 빼서 돌아오는 실행 스택을 구현한 소도구가 리버티게임에 필요합니다.
- ↑ Duck Invasion 게임처럼 특정한 사각형 안에 게임 화면이 픽셀 단위로 그려지도록 하는 HTML 요소입니다.
설문조사 결과의 생략된 범례는 파일을 클릭하여 자세히 볼 수 있습니다. --명진 (토론) 2024년 7월 8일 (월) 00:15 (KST)
참고: 제 기타 의견의 원문 앞쪽입니다: 구글 플레이의 2024년 최근 근황은 게임의 관심 있는 주제를 선택할 수 있고[1] 게임 목록은 아이콘, 제목, 요약, 평점 및 추천이나 업데이트가 있음을 알리는 기호(및 유료인 경우 가격 표시)가 있습니다. 간혹 스크린샷과 게임 태그들이 나열된 목록도 있지만 리버티게임의 강점은 손쉬운 텍스트 게임 개발이라는 점을 기억하여야 합니다. 따라서 전자처럼 목록을 표시[2]하는 것이 좋습니다.
미디어위키는 그 특성상 엔진이 시스템 자원을 많이 소모하므로 무겁지만 그만큼 위키와 관련된 관리 기능이 많아 편리한 장단점이 있습니다. 경량의 위키 엔진을 원한다면 리브레 위키와 리버티 엔진 공동 개발을 추천합니다. --명진 (토론) 2024년 7월 7일 (일) 23:57 (KST)
- 어차피 게임 엔진을 사용하는 게임은 itch.io를 쓰게 될 것이라는 의견에 동의합니다. 이러한 게임들은 itch.io에 업로드하기 편하지만, 리버티게임은 직접 업로드가 불가능하여 우회하는 절차가 매우 불편하고, itch.io는 기부금도 받을 수 있고, 인지도도 훨씬 높기에 굳이 리버티게임을 쓸 이유가 없는 것 같습니다. 개발 난이도와 퀄리티가 높은 게임을 유치하려면 리버티게임을 써야만 하는 이유를 제공하는 리버티게임만의 특색있는 락인 전략이 필요합니다.
- 그리고 문법의 특성을 살려서 전문적인 프로그래밍 기술이 없어도 자바스크립트로만 가능한 것들은 위키 문법으로 가능하게 개선하자는 의견에 위키스크립트라는 대안을 제시하셨는데, 저는 위키스크립트에 회의적입니다. 해당 의견은 프로그래밍을 몰라도 할 수 있는 것들을 늘리자는 취지이나, 위키스크립트는 그냥 자바스크립트 언어를 위키 문법으로 포팅한 것으로만 보이며, 이는 결국 프로그래밍 언어이고 오히려 자바스크립트보다 생태계와 참고자료도 적어서 쓰기 더 난해할 것이라고 생각됩니다. 저는 자바스크립트로 가능한 일을 CGI 이하의 난이도로 구현할 수 있도록 개선하는 것을 목표로 하고 있으며, 현재 자바스크립트 기반 틀들이 문서 로딩과 링크를 트리거로 삼는 것에서 착안하여, 이러한 틀들을 더 쉽게 만들고 각 틀의 이벤트를 서로 조합하며 로딩과 링크 클릭을 넘어 대부분의 사용자의 입력을 핸들링할 수 있게 확장하는 LinkTools(가칭)와 EventTools(가칭)를 개발하고 있고, 문서 전환 없이 동적인 페이지를 만들고 요즘 유행하는 SPA 프레임워크의 컴포넌트를 흉내낼 수 있도록 CGI를 영역별로 쪼개는 local CGI를 구상하고 있습니다. 하지만 상용 게임 엔진을 쓰는 게임은 그냥 자바스크립트나 게임 엔진에서 사용하는 언어를 쓰는게 최선이라고 생각됩니다.
- 또한 사이트 유입 경로를 파악하여 이에 맞는 전략을 수립하자는 의견이 있는데, 리버티게임에 구글 태그 매니저 스크립트라는 구글 애널리틱스 관련 코드로 추정되는 물건이 있는 것으로 확인됩니다. 만약 애널리틱스를 활용하고 있다면, 관련 통계나 분석자료를 주기적으로 공개하면 좋을 것 같습니다. --hsl(토론, 기여, 게임, 메일) 2024년 7월 15일 (월) 22:53 (KST)
- 답변 감사합니다. 사실 프레임 단위 액션이나 이벤트 콜백을 구현할 경우에는 프로그래밍이 불가피할 것 같아서 문제 해결력을 높이도록 유도할 겸 생각한 것인데, 의견을 듣고 생각해보니 이벤트 콜백을 별도의 틀로 분리하고 프레임 단위 액션을 상태 머신으로 구현할 수도 있을 것 같네요. 다른 문서에 문단 단위로 정의한 상태 머신을 돌리는 소도구만 만들어도 목적 달성이 가능하겠습니다. --Senouis(토론장, 기여) 2024년 7월 21일 (일) 14:09 (KST)
- LCGI랑 LinkTools 및 EventTools 문서도 보았는데, LCGI의 경우 소도구가 LCGI로 정의한 상태를 requestAnimationFrame 등으로 끊임없이 프론트엔드 내에서 내용을 바꾸는 옵션도 제공했으면 좋겠습니다. 위키 문법으로 작성한 정적인 화면만 가지고 게임을 만들기에는 이제 충분하지 않은 시점이라 생각되거든요. 이제 네트워크 통신을 최대한 줄이는 방향으로 게임을 만들도록 장려하는 방향이 필요합니다. 현 리버티게임에는 해당되지 않으나, 망 사용료 이슈가 클라우드 쪽에도 영향을 주는지, 제 Azure 관련 경험이나 AWS 입주 시절 BANIP님에게 통계 자료를 받아 본 경험을 봤을 때 인스턴스를 돌리는 것 못지 않게 네트워크 트래픽도 요금이 꽤 비쌉니다. --Senouis(토론장, 기여) 2024년 7월 21일 (일) 14:52 (KST)
- 답변 감사합니다. 사실 프레임 단위 액션이나 이벤트 콜백을 구현할 경우에는 프로그래밍이 불가피할 것 같아서 문제 해결력을 높이도록 유도할 겸 생각한 것인데, 의견을 듣고 생각해보니 이벤트 콜백을 별도의 틀로 분리하고 프레임 단위 액션을 상태 머신으로 구현할 수도 있을 것 같네요. 다른 문서에 문단 단위로 정의한 상태 머신을 돌리는 소도구만 만들어도 목적 달성이 가능하겠습니다. --Senouis(토론장, 기여) 2024년 7월 21일 (일) 14:09 (KST)
- 저는 피드백 3에 관해서는 관심 분야에 대해 게임 장르와 게임의 기획에 쓰일 법한 그 밖의 관심 분야로 구분하여 조사하는 것도 하나의 방법이라고 생각합니다. --명진 (토론) 2024년 7월 16일 (화) 01:21 (KST)
틀:플러그인 관련된 조치 하나[원본 편집]
일종의 핫픽스입니다.
PluginX가 아닌 일반 플러그인 틀은 현재 실행 취소 버튼이 없기 때문에, 예스맨(?)들에게 위험할 수 있다고 판단되어, 기존에 작성된 스크립트 문서들에 자동 인증된 사용자부터 편집 가능하도록 지정하고 있습니다. 다만 사용자 이름공간에 있는 스크립트 문서들은 보존된 게임에 사용하는 것인지, 아니면 게임은 배포 중인데 사용자 문서 아래 스크립트 문서만 있는지 확인할 시간이 필요하여, 시간을 두고 지정하겠습니다. --Senouis(토론장, 기여) 2024년 7월 12일 (금) 10:54 (KST)
되돌리기 전 확인 기능[원본 편집]
기존에 되돌리기 전 확인 소도구를 사용해서 잘못 터치해서 되돌리는 것을 억제하였는데, 이러한 기능을 제공하는 기본 기능을 찾았습니다. 환경설정의 보이기 탭에서 고급 옵션의 되돌리기 링크를 클릭할 때 확인창을 표시 기능이 있습니다. 이 기능을 기본적으로 활성화 시키면 좋을 것 같은데, $wgDefaultUserOptions.showrollbackconfirmation 을 참으로 바꿔주실 수 있겠습니까? --hsl(토론, 기여, 게임, 메일) 2024년 7월 14일 (일) 09:39 (KST)
- 완료 네! 되돌리기 링크를 누르니 누른 자리에 확인하는 문구가 송출되고 거기서 한 번 더 되돌리기를 눌러야 하네요. 활성화되었습니다! --Senouis(토론장, 기여) 2024년 7월 14일 (일) 14:23 (KST)
고도 엔진 3 튜토리얼 제작자를 모집합니다.[원본 편집]
제가 지금 틀:고도3을 사용하기 위한 도움말 문서를 제작하고 있는데, 아무래도 엄연한 게임 엔진을 설명하다 보니, 시간이 많이 걸릴 것 같습니다.
그래서 게임 엔진으로 게임을 만들고 배포할 것이라면 고도 엔진을 사용할 것을 사이트 차원에서 어느 정도 장려할 필요가 있다고 생각하여 튜토리얼 문서를 같이 제작하실 분을 모집하려고 합니다. 제가 개인 사정으로 다음 달 초까지 거의 작업을 못하기 때문에, 그 사이 고도 엔진 3을 쓰려고 계획하신 분이 있다면 간단한 연습 후에 시간에 맞춰 8월 10일 이후 제 사용자 문서로 연락해 주시기 바랍니다. 그 전까지 현재 진행된 부분을 읽어보시고, 3.5버전 영문 도움말을 조금씩 구글 번역이나 ChatGPT, DeepL 등으로 바꿔 읽으면서 간단히 연습하시면 더욱 좋고요.
참고로 고도 엔진 3과 4를 비교했을 때 고도 엔진 3이 가지는 돋보이는 장점이 엔트리나 언리얼 블루프린트처럼 마우스로 로직을 이어주는 비주얼스크립트(VisualScript) 기능이라고 생각하기 때문에, 해당 튜토리얼은 VisualScript을 사용하여 제작하려고 합니다.
VisualScript도 어느 정도는 한글화가 되어 있어 사용이 10대 회원에게 심각하게 어려운 상황은 아니라, 참여 대상은 만 13세 이상의 모든 리버티게임 회원으로 하겠습니다. 아마 디스코드로 소통하면서 튜토리얼 제작과 스터디를 병행할 것으로 생각되기에, 사이트 디스코드에 부모님 도움 없이 스스로 입장할 수 있다면 그것으로 나이 증명이 된 것으로 하겠습니다. --Senouis(토론장, 기여) 2024년 7월 14일 (일) 21:37 (KST)
리버티책의 임시 관리자를 맡을 분을 찾습니다[원본 편집]
갑자기 리버티게임에서 왜 리버티책 이야기를 하시나 싶으실 텐데, 리버티책 사무관을 맡고 계신 Existentialism님이 8월 초에 군 입대를 하신다고 합니다. 그래서 Miraheze에 계정을 갖고 계신 분들 중 리버티책의 임시 관리(한 달에 한 번 정도 간단한 UI 관련 편집 및 반달 차단 후 되돌리기 정도만 하면 될 겁니다)를 하실 분을 찾고 있습니다.
리버티게임도 2023년 상반기까지 Miraheze에서 사이트가 돌아갔기 때문에 지금 그곳에 계정을 아직 갖고 계신 분들이 있을 것이라 생각하며, 리버티책이 명목 상으로라도 리버티게임의 연계 프로젝트로 생겼던 위키면서 리버티게임 관련 몇몇 자료가 리버티책에 있어서 관리가 안 되거나 위키가 버려졌다고 판단되면 약간 곤란한 부분이 있습니다.
그래서 리버티책에 관심이 가는 분들은 본인의 Miraheze 계정 링크를 가지고 8월 3일까지 리버티책 사무관의 리버티게임 사용자 토론 문서에 임시 관리자 신청을 하겠다고 연락하시기 바랍니다. --Senouis(토론장, 기여) 2024년 7월 21일 (일) 13:12 (KST)
알고 계십니까?[원본 편집]
'미리보기'나 '차이 보기' 기능으로 임시 저장이 가능하다는 사실을... 문서를 작성하다가 잠시 중단하고 나중에 편집창을 다시 열면 저장하지 않는 이상 기존에 작성하던 수정사항이 모두 날라가는 경우가 있습니다. 하지만 미리보기나 차이 보기 버튼을 눌러 해당 기능을 사용 중인 탭은 브라우저를 복원해도 '만료된 페이지입니다.' 창이 뜹니다. 여기서 새로고침을 해주면 기존 작업이 반복돼서 결제가 중복될 수 있다고 뜰텐데, 무시하고 과감히 새로고침을 해주면 기존에 미리보던 창이 다시 뜨고 편집창도 미리보던 기존의 초안이 그대로 남습니다. 탭을 따로 닫지 않는 이상, 미리보기만 해주면 임시 저장이 되는 셈입니다. --hsl(토론, 기여, 게임, 메일) 2024년 7월 29일 (월) 12:28 (KST)