리버티게임토론:청사진: 두 판 사이의 차이

리버티게임, 모두가 만들어가는 자유로운 게임
imported>Senouis
(생성)
 
imported>Hsl0
편집 요약 없음
13번째 줄: 13번째 줄:
* 게임 분류용 메타데이터 문서 추가
* 게임 분류용 메타데이터 문서 추가
일단 Hsl0님의 수고로 JSON 포맷 문서를 작성할 경우 가이드라인은 [[리버티게임:게임 메타데이터|여기]]에 완성되었습니다. 해당 메타데이터는 각 게임의 메인 문서 부제목에 아이콘을 덧붙이는 식으로 게임 UI를 통일하는 데 활용할 수 있으며, 사이트 내 게임에 접속시 localstorage에 캐싱하고 최근 플레이한 게임 목록을 보고 싶을 때 불러오는 식으로도 응용이 가능하겠습니다. 해당 코드는 전역 common.js에 추가하는 것이 좋아보입니다.
일단 Hsl0님의 수고로 JSON 포맷 문서를 작성할 경우 가이드라인은 [[리버티게임:게임 메타데이터|여기]]에 완성되었습니다. 해당 메타데이터는 각 게임의 메인 문서 부제목에 아이콘을 덧붙이는 식으로 게임 UI를 통일하는 데 활용할 수 있으며, 사이트 내 게임에 접속시 localstorage에 캐싱하고 최근 플레이한 게임 목록을 보고 싶을 때 불러오는 식으로도 응용이 가능하겠습니다. 해당 코드는 전역 common.js에 추가하는 것이 좋아보입니다.
<br>[[분류:리버티게임|리버티게임 분류]]에 붙은 게임들에 이것들을 추가한 후게임 목록 문서도 이걸 활용할 수 있으면 좋겠지만, 이게 실시간으로 동기화를 해야 게임을 만들자마자 알 수 있으니 메타데이터를 각 문서마다 만들어봤자 게임 목록을 불러올 때 클라이언트 측에서 사이트 전체를 크롤링해야하니 서버에게 부담을 주지 않는다는 게임 목록 분리 의도를 달성할 수 없습니다. 유일한 해결책은 미분류된 최상위 문서들의 리스트를 관리자가 쉽게 보는 것인데, 어떻게 구현하면 좋을까요?
<br>[[:분류:리버티게임|리버티게임 분류]]에 붙은 게임들에 이것들을 추가한 후게임 목록 문서도 이걸 활용할 수 있으면 좋겠지만, 이게 실시간으로 동기화를 해야 게임을 만들자마자 알 수 있으니 메타데이터를 각 문서마다 만들어봤자 게임 목록을 불러올 때 클라이언트 측에서 사이트 전체를 크롤링해야하니 서버에게 부담을 주지 않는다는 게임 목록 분리 의도를 달성할 수 없습니다. 유일한 해결책은 미분류된 최상위 문서들의 리스트를 관리자가 쉽게 보는 것인데, 어떻게 구현하면 좋을까요?
--{{사용자:Senouis/서명}} 2023년 2월 20일 (월) 19:21 (KST)
--{{사용자:Senouis/서명}} 2023년 2월 20일 (월) 19:21 (KST)
:  
: 메타데이터는 이런 용도로 쓰려고 만든 것이 아닙니다. 게임아이콘 틀을 여러 군데에서 쓸 때 들어가는 데이터를 중앙화 시켜서 모든 틀을 찾아서 바꿀 필요없이 한번 수정했을 때 자동으로 바뀔 수 있도록 한 것입니다. JSON 문서는 루아 모듈을 통해서도 읽을 수 있으므로 클라이언트 사이드에서 별도의 크롤링을 할 필요는 없습니다. {{주석|이미 [[모듈:Metadata|루아 모듈]]을 통해 기초적인 구현은 해두었으나|[[리버티게임:연습장]]이나 [[사용자:hsl0/연구소]]에서 예시를 확인할 수 있습니다.}}, 게임아이콘 틀 내용을 완전히 교체할 계획이 있고 사이트 전체를 편집해야 하는 관계로 포맷을 수정했을 때 다시 봇을 돌리는 일이 없도록 신중하게 접근하고 있습니다. 물론 틀 전개에서 부하가 올 수는 있겠지만 이에 대해서는 후술하겠습니다. 추가적으로 게임의 기본 정보를 봇, 스크립트, 확장 기능, 모듈, 틀이 읽을 수 있게 하고 각종 기술 스택의 게임별 설정을 저장할 수 있습니다. 최근 플레이한 게임 목록은 메타데이터 없이 접속한 문서 제목만 저장하면 됩니다. 게임 메인 문서에 정보를 표시하는 것은 적절한 활용입니다.
:사이트 부하 문제에 대해서는 카테고리, 완성도, 평가, 연령 등급, (기술, 제작자) 등 각 게임 특성에 대한 분류를 만들고 각 게임을 적절히 분류한 뒤, 게임목록에서 원하는 특성을 선택하여 필터링하고 정렬할 수 있도록 개편하여 사용자가 필요한 부분만 볼 수 있도록 하면 어떨까 싶습니다. --{{사용자:hsl0/서명}} 2023년 2월 20일 (월) 22:32 (KST)
* 인기 게임 순위 시스템
* 인기 게임 순위 시스템
토론 문서 분석하는 미디어위키 플러그인이 있다는 의견을 오락실에서 들었습니다. 플러그인 분석 결과를 여기에 간단히 기록하고 작업에 착수해봅시다. --{{사용자:Senouis/서명}} 2023년 2월 20일 (월) 19:21 (KST)
토론 문서 분석하는 미디어위키 플러그인이 있다는 의견을 오락실에서 들었습니다. 플러그인 분석 결과를 여기에 간단히 기록하고 작업에 착수해봅시다. --{{사용자:Senouis/서명}} 2023년 2월 20일 (월) 19:21 (KST)
23번째 줄: 24번째 줄:


2D 게임 프레임워크를 먼저 만들고 3D 게임은 나중에 3D 모델링을 어떤 포맷으로 추가할지 논의합시다(페이즈 2로 미룰 확률이 매우 높겠네요). 남은 것은 실시간 P2P 통신입니다. WebRTC를 사용할 수 있을까요?--{{사용자:Senouis/서명}} 2023년 2월 20일 (월) 19:21 (KST)
2D 게임 프레임워크를 먼저 만들고 3D 게임은 나중에 3D 모델링을 어떤 포맷으로 추가할지 논의합시다(페이즈 2로 미룰 확률이 매우 높겠네요). 남은 것은 실시간 P2P 통신입니다. WebRTC를 사용할 수 있을까요?--{{사용자:Senouis/서명}} 2023년 2월 20일 (월) 19:21 (KST)
:  
: 화살표 함수나 class 등 ES6 기능은 컴파일하면 그만이죠. 저도 타입스크립트와 컴파일러를 적극 활용하고 있습니다. --{{사용자:hsl0/서명}} 2023년 2월 20일 (월) 22:32 (KST) 
* 페이즈 2 이후에도 진행할 필요가 있는 장기 프로젝트를 포함한 추가 계획 논의
* 페이즈 2 이후에도 진행할 필요가 있는 장기 프로젝트를 포함한 추가 계획 논의
그 외에 추가할 만한 계획이 있을까요? --{{사용자:Senouis/서명}} 2023년 2월 20일 (월) 19:21 (KST)
그 외에 추가할 만한 계획이 있을까요? --{{사용자:Senouis/서명}} 2023년 2월 20일 (월) 19:21 (KST)
:  
: 첫번째 항목에서 반응형 웹을 말씀하셨는데, 요즘 트렌드에 맞는 프레임워크를 도입하거나 이와 유사한 위키문법 기반 시스템을 만드는 것도 좋을 것 같습니다. 미디어위키는 Vue.js를 도입하여 점점 비중을 늘려가고 있는 중이며, 리버티게임에서도 스크립트에 <code>mw.loader.using('vue')</code>만 넣으면 당장 쓸 수는 있습니다. 하지만 자바스크립트 코드를 내용 중간에 끼워넣을 수 있으므로 보안을 위해 모두가 편집할 수 있는 일반 문서에는 쓸 수 없겠습니다. 특히 Vue를 어설프게 쓰려고 하다가 터져나올 잠재적인 보안 문제를 대비해야 합니다. 또는 위키문법을 확장해서 프레임워크 수준까지 개발해내서 자바스크립트 없이 위키 문법과 섞어쓸 수 있게 만들 수도 있겠습니다. 저도 이에 대해 구상을 해왔습니다. 다만 게임 엔진만큼 어려운 일이겠지요. 현재 {{주석|이벤트 프레임워크|기술 스택끼리 간섭하지 않고 다음에 실행될 (기본) 동작을 기존 작업이 끝날때까지 지연시킬 수 있고, 링크를 누를 때 또는 페이지를 로딩할 때 동작을 예약할 수 있으며, 추후 더 많은 이벤트에 예약할 수 있게 됩니다. 왜 필요하나 싶겠지만, DB2와 CGI보호 틀은 페이지가 넘어가는 링크를 누를 때 페이지 이동을 미루고 작업을 끝낸 뒤 페이지를 넘깁니다. 그런데 현재 DOM 이벤트는 기본 동작 미루기를 지원하지 않아 기본 동작을 취소하고 작업이 끝난 뒤 별도로 기본 동작에 상응하는 동작을 실행합니다. 이러한 기술 스택이 여러 개 구동될 경우 다른 기술 스택의 일이 끝나기도 전에 자기 일만 끝나면 페이지를 넘겨버릴 수 있기 때문에 이를 조율하는 시스템이 필요합니다. 이 이벤트 프레임워크가 그 역할을 합니다. 이 프레임워크를 도입하면 각 스크립트에서 동작을 수행할 링크를 넣을 자리를 일일이 찾을 필요가 없게 되어 HTML 요소 탐색이 줄어들고 성능이 향상됩니다. 궁극적으로 자바스크립트없이 동적인 웹페이지를 만들기 위한 주요 요소 중 하나입니다. [[사용자:hsl0/연구소/2]]에서 예시를 볼 수 있습니다. html이 덕지덕지 있지만, 틀로 예쁘게 쓸 수 있습니다.}}를 만들고 있는데 이를 염두에 두고 개발하고 있습니다.
== 1단계 피드백 및 2단계 입안 토론 ==
== 1단계 피드백 및 2단계 입안 토론 ==
<p style="text-align:center;">기간: 2023년 12월 10일 ~ 2023년 12월 30일</p>
<p style="text-align:center;">기간: 2023년 12월 10일 ~ 2023년 12월 30일</p>

2023년 2월 20일 (월) 22:32 판

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

1단계 입안 토론

기간: ~2023년 02월 28일

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

백괴게임 시절 게임과 리버티게임 창설 이후 게임을 분리할 이유는 충분합니다. 일단 사이트가 더 이상 '백괴스러운 게임'만을 만들지 않는다는 컨셉의 미묘한 변경이 있죠. 그리고 과거 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)답변[답변]
  • 인기 게임 순위 시스템

토론 문서 분석하는 미디어위키 플러그인이 있다는 의견을 오락실에서 들었습니다. 플러그인 분석 결과를 여기에 간단히 기록하고 작업에 착수해봅시다. --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 기능은 컴파일하면 그만이죠. 저도 타입스크립트와 컴파일러를 적극 활용하고 있습니다. --hsl(토론, 기여, 게임, 메일) 2023년 2월 20일 (월) 22:32 (KST)답변[답변]
  • 페이즈 2 이후에도 진행할 필요가 있는 장기 프로젝트를 포함한 추가 계획 논의

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

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

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

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


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

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


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

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