리버티게임토론:청사진

• 이 문서에서는 각 단계별 계획 피드백 및 다음 단계 이행을 위해 논의를 진행합니다. 일단 매해 연말에 해당하는 기간이 적힌 문단에서만 토론하는 것을 원칙으로 합니다. 2030년 이후로 10년 단위로 발생할 것으로 예상되는 토론 문서 비대화에 따른 하위 문서로의 내용 분리 요청은 사이트가 그때까지 존속한다는 전제 하에 문제가 발생할 때 분리하는 것으로 하겠습니다. --Senouis(토론장, 기여) 2023년 2월 20일 (월) 19:21 (KST)

1단계 입안 토론

기간: ~2023년 02월 28일

일단 임시로 작업 기한을 명기하였습니다. 다만 1단계는 다소 급하게 계획을 짜게 되어, 저 기한이 공식 계획이 될 가능성이 매우 높음을 알립니다. --Senouis(토론장, 기여) 2023년 2월 27일 (월) 00:45 (KST)

• 백괴 클래식 분류 및 데이터/로직 손상 게임 처리 관련 토론

백괴게임 시절 게임과 리버티게임 창설 이후 게임을 분리할 이유는 충분합니다. 일단 사이트가 더 이상 '백괴스러운 게임'만을 만들지 않는다는 컨셉의 미묘한 변경이 있죠. 그리고 과거 2010년대 초반까지는 웹 컨텐츠가 상당히 정적인 경우가 다수여서 그 상황에서 텍스트와 조건문을 때려박아가며 한계를 쥐어짜낸 좋은 게임들은 지금도 고평가를 받아야겠지만 그땐 그 때고 이제는 반응형 웹이 대세이니 더 이상 동일한 게임 제작 전략만 가져오기는 어렵습니다.
따라서 그 시절의 게임을 구분해서 아카이브하는 작업이 필요합니다. 다음 3가지로 분할하여 게임 목록에 명시하는 방법이 제시됩니다.

1. 백괴게임 시절 특집 게임(예: 위키낚시)이나 장기간 광고하였던 게임들(예: Will It Blend?)
2. 그럭저럭 플레이 가능한 상태의 텍스트 어드벤처 게임들(절대 다수인 것으로 추정됩니다)
3. 애셋 부재 등의 이유로 로직이 깨졌거나 플레이 자체가 매우 어려운 게임(예: 백괴리겜 - 배경음악이 저작권 문제로 링크가 끊겼는지 오류를 냅니다. 기억하기로 xi의 프리덤 다이브를 재생했었습니다)

--Senouis(토론장, 기여) 2023년 2월 20일 (월) 19:21 (KST)

• 게임 분류용 메타데이터 문서 추가

일단 Hsl0님의 수고로 JSON 포맷 문서를 작성할 경우 가이드라인은 여기에 완성되었습니다. 해당 메타데이터는 각 게임의 메인 문서 부제목에 아이콘을 덧붙이는 식으로 게임 UI를 통일하는 데 활용할 수 있으며, 사이트 내 게임에 접속시 localstorage에 캐싱하고 최근 플레이한 게임 목록을 보고 싶을 때 불러오는 식으로도 응용이 가능하겠습니다. 해당 코드는 전역 common.js에 추가하는 것이 좋아보입니다.
리버티게임 분류에 붙은 게임들에 이것들을 추가한 후게임 목록 문서도 이걸 활용할 수 있으면 좋겠지만, 이게 실시간으로 동기화를 해야 게임을 만들자마자 알 수 있으니 메타데이터를 각 문서마다 만들어봤자 게임 목록을 불러올 때 클라이언트 측에서 사이트 전체를 크롤링해야하니 서버에게 부담을 주지 않는다는 게임 목록 분리 의도를 달성할 수 없습니다. 유일한 해결책은 미분류된 최상위 문서들의 리스트를 관리자가 쉽게 보는 것인데, 어떻게 구현하면 좋을까요? --Senouis(토론장, 기여) 2023년 2월 20일 (월) 19:21 (KST)

메타데이터는 이런 용도로 쓰려고 만든 것이 아닙니다. 게임아이콘 틀을 여러 군데에서 쓸 때 들어가는 데이터를 중앙화 시켜서 모든 틀을 찾아서 바꿀 필요없이 한번 수정했을 때 자동으로 바뀔 수 있도록 한 것입니다. JSON 문서는 루아 모듈을 통해서도 읽을 수 있으므로 클라이언트 사이드에서 별도의 크롤링을 할 필요는 없습니다. 이미 루아 모듈을 통해 기초적인 구현은 해두었으나리버티게임:연습장이나 사용자:hsl0/연구소에서 예시를 확인할 수 있습니다., 게임아이콘 틀 내용을 완전히 교체할 계획이 있고 사이트 전체를 편집해야 하는 관계로 포맷을 수정했을 때 다시 봇을 돌리는 일이 없도록 신중하게 접근하고 있습니다. 물론 틀 전개에서 부하가 올 수는 있겠지만 이에 대해서는 후술하겠습니다. 추가적으로 게임의 기본 정보를 봇, 스크립트, 확장 기능, 모듈, 틀이 읽을 수 있게 하고 각종 기술 스택의 게임별 설정을 저장할 수 있습니다. 최근 플레이한 게임 목록은 메타데이터 없이 접속한 문서 제목만 저장하면 됩니다. 게임 메인 문서에 정보를 표시하는 것은 적절한 활용입니다. --hsl(토론, 기여, 게임, 메일) 2023년 2월 20일 (월) 22:32 (KST)

일단 베타 버전을 저장할 신규 문서를 먼저 작성하고 정상 작동이 확인되면 기존 문서에 병합해버리는 방식으로 접근하면 안전할 것으로 보입니다. 게임 아이콘 틀 문서와 게임 목록 문서는 구 버전을 남기되 보존 처리를 하여 타 문서에서의 접근을 끊어 문서끼리 바꿔치는 식으로 적용하겠습니다. 메인 문서에 게임 정보 표시는 아예 자동으로 페이지 우상단에 표시하되 JSON 정보가 없을 경우 JSON 문서 생성 링크를 대신 달아놓는 것이 좋겠습니다. 이 작업은 늦어도 5월 전에 끝났으면 하는데, 이 기한 안에 해야 다른 작업에 영향이 없을 것 같기 때문입니다. --Senouis(토론장, 기여) 2023년 2월 27일 (월) 00:45 (KST)

더 구체적인 게임 목록 개선안입니다. 봇을 이용해 현재 리버티게임:게임 목록에 등재된 게임아이콘의 데이터를 읽어서 자동으로 game.json을 작성하고 (일회성, 새로운 게임은 게임아이콘 대신 game.json을 작성), 게임의 특성 별로 세분화된 분류를 만들고, 틀을 통해 game.json을 기반하여 자동으로 분류합니다. 그리고 게임 목록을 각 특성별장르, 제작자, 완성도, 연령 등급, 플랫폼, 평가 등로 필터링/정렬이 가능하고, 검색도 가능하도록 개편합니다. 필터링/정렬은 DPL을 활용하며, 쿼리된 문서가 많을 때 과부하를 방지하기 위해 자바스크립트를 활용해 n[20개, 50개, 100개, 500개(?)를 사용자가 선택 가능하도록 생각 중개씩 부분적으로 로딩합니다. 게임 목록에 게임을 직접 등록하지 않으며, 자동 분류를 바탕으로 불러옵니다. 게임 목록은 완성도 상관없이 모든 게임을 검색할 수 있지만, 필터를 변경하지 않는 한 완성도가 어느 정도 이상 3단계 이상을 생각하고 있습니다.인 게임만 기본값으로 표시되게 합니다. game.json은 게임 대문에서 제목 오른쪽 끝에 (game.json이 없다면) [게임 메타데이터 만들기] 같은 버튼이나, (있다면) 게임아이콘을 눌러서 조회/수정이 가능하도록 합니다. 저는 이런 방향으로 개선하기를 원하는데, 어떠십니까? --hsl(토론, 기여, 게임, 메일) 2023년 4월 7일 (금) 00:07 (KST)

• 인기 게임 순위 시스템

토론 문서 분석하는 미디어위키 플러그인이 있다는 의견을 오락실에서 들었습니다. 플러그인 분석 결과를 여기에 간단히 기록하고 작업에 착수해봅시다. --Senouis(토론장, 기여) 2023년 2월 20일 (월) 19:21 (KST)

• HTML5 게임 프레임워크 - 핵심 코드 관련 토론

네, 일단 BANIP님의 유산인 PluginX를 더 개선하여 완전한 프레임워크를 만들어야 하는데 핵심 코드와 애셋을 어떻게 할지 걱정됩니다. 일단 언리얼 엔진과 골드 소스 호환 엔진인 Xash3D를 분석해봤는데, 게임 내 등장하는 모든 오브젝트(캐릭터, 몬스터, 아이템, 바닥에 굴러다니는 장식들, 트리거 박스, 광원, 음원, 프롭 등) 및 게임 로직(전역 로직, 문서별 로직)이야 자바스크립트의 함수 프로토타입 상속으로 구현할 수 있겠습니다. 미디어위키가 익명 함수나 class를 지원 안해서 개발 편의가 떨어지는 건 좀 아쉽지만 일단 개발용 Documentation을 작성해가면서 시작해봅시다.

2D 게임 프레임워크를 먼저 만들고 3D 게임은 나중에 3D 모델링을 어떤 포맷으로 추가할지 논의합시다(페이즈 2로 미룰 확률이 매우 높겠네요). 남은 것은 실시간 P2P 통신입니다. WebRTC를 사용할 수 있을까요?--Senouis(토론장, 기여) 2023년 2월 20일 (월) 19:21 (KST)

화살표 함수나 class 등 ES6 기능은 컴파일하면 그만이죠. 저도 타입스크립트와 컴파일러를 적극 활용하고 있습니다. 그리고 pluginX는 ES6을 지원하는 것으로 알고 있습니다. --hsl(토론, 기여, 게임, 메일) 2023년 2월 20일 (월) 22:32 (KST)

앗, 그렇군요! 그럼 이제 게임 내 오브젝트인 엔티티의 기본 코드를 먼저 작성해보겠습니다. 먼저 공통적으로 스프라이트 정보 및 위치, 속성 등을 포함하고 정적인 오브젝트(프롭, 스카이박스 등)/동적인 오브젝트를 구분하여 상속시킨 다음 동적인 오브젝트는 스켈레톤 정보 및 부위별 추가 스프라이트와 애니메이션을 지정하고 거기서 사용자의 입력에 반응하는 캐릭터(플레이어블/논 플레이어블 가리지 않고)와 아이템, 버튼 같은 물체를 파생시키는 식으로 기본 코드를 한번 짜보겠습니다. --Senouis(토론장, 기여) 2023년 2월 27일 (월) 00:45 (KST)

• 페이즈 2 이후에도 진행할 필요가 있는 장기 프로젝트를 포함한 추가 계획 논의

그 외에 추가할 만한 계획이 있을까요? --Senouis(토론장, 기여) 2023년 2월 20일 (월) 19:21 (KST)

첫번째 항목에서 반응형 웹을 말씀하셨는데, 요즘 트렌드에 맞는 프레임워크를 도입하거나 이와 유사한 위키문법 기반 시스템을 만드는 것도 좋을 것 같습니다. 미디어위키는 Vue.js를 도입하여 점점 비중을 늘려가고 있는 중이며, 리버티게임에서도 스크립트에 mw.loader.using('vue')만 넣으면 당장 쓸 수는 있습니다. 하지만 자바스크립트 코드를 내용 중간에 끼워넣을 수 있으므로 보안을 위해 모두가 편집할 수 있는 일반 문서에는 쓸 수 없겠습니다. 특히 Vue를 어설프게 쓰려고 하다가 터져나올 잠재적인 보안 문제를 대비해야 합니다. 또는 위키문법을 확장해서 프레임워크 수준까지 개발해내서 자바스크립트 없이 위키 문법과 섞어쓸 수 있게 만들 수도 있겠습니다. 저도 이에 대해 구상을 해왔습니다. 다만 게임 엔진만큼 어려운 일이겠지요. 현재 이벤트 프레임워크기술 스택끼리 간섭하지 않고 다음에 실행될 (기본) 동작을 기존 작업이 끝날때까지 지연시킬 수 있고, 링크를 누를 때 또는 페이지를 로딩할 때 동작을 예약할 수 있으며, 추후 더 많은 이벤트에 예약할 수 있게 됩니다. 왜 필요하나 싶겠지만, DB2와 CGI보호 틀은 페이지가 넘어가는 링크를 누를 때 페이지 이동을 미루고 작업을 끝낸 뒤 페이지를 넘깁니다. 그런데 현재 DOM 이벤트는 기본 동작 미루기를 지원하지 않아 기본 동작을 취소하고 작업이 끝난 뒤 별도로 기본 동작에 상응하는 동작을 실행합니다. 이러한 기술 스택이 여러 개 구동될 경우 다른 기술 스택의 일이 끝나기도 전에 자기 일만 끝나면 페이지를 넘겨버릴 수 있기 때문에 이를 조율하는 시스템이 필요합니다. 이 이벤트 프레임워크가 그 역할을 합니다. 이 프레임워크를 도입하면 각 스크립트에서 동작을 수행할 링크를 넣을 자리를 일일이 찾을 필요가 없게 되어 HTML 요소 탐색이 줄어들고 성능이 향상됩니다. 궁극적으로 자바스크립트없이 동적인 웹페이지를 만들기 위한 주요 요소 중 하나입니다. 사용자:hsl0/연구소/2에서 예시를 볼 수 있습니다. html이 덕지덕지 있지만, 틀로 예쁘게 쓸 수 있습니다.를 만들고 있는데 이를 염두에 두고 개발하고 있습니다.

네, 그럼 이벤트 프레임워크로 사이트 동작을 정교하게 스케줄링하는 것도 추가하겠습니다. 작업이 마무리되기까지 한 2달은 걸리려나요? --Senouis(토론장, 기여) 2023년 2월 27일 (월) 00:45 (KST)

1단계 피드백 및 2단계 입안 토론

기간: 2023년 12월 10일 ~ 2023년 12월 30일

2단계 피드백 및 3단계 입안 토론

기간: 2024년 12월 10일 ~ 2024년 12월 30일

3단계 피드백 및 4단계 입안 토론

기간: 2025년 12월 10일 ~ 2025년 12월 30일