리버티게임토론:게임 메타데이터

게임 메타데이터에 Summary 추가 필요

Google Play 스토어나 F-Droid 같은 데에는 Description 뿐만 아니라 Summary (80자 제한)도 입력하게 되어 있습니다. F-Droid 메타데이터 참조 빌드 게임 메타데이터라면 가능하면 Google Play 스토어와 같이 Name, Summary, Description과 같이 메타데이터를 넣는 방향을 고민할 필요가 있습니다. --명진 (토론) 2023년 4월 3일 (월) 01:19 (KST)

원래 description은 짧은 설명을 의도하고 추가하였습니다만 이번에 다시 생각해보니 둘 다 필요할 것 같기도 하군요. 더 간단한 설명인 summary를 추가하도록 하겠습니다. description은 한 문단 정도의 분량을, summary는 한 문장 정도의 분량 (Google Play 스토어에서 앱 정보 설명을 누르기 전에 나오는 분량)의 설명으로 설정하겠습니다. 참고로 yaml은 미디어위키에서도 지원하지 않고 별도의 파서를 가져와야 하기 때문에 리버티게임에서는 쓸 계획이 없습니다. --hsl(토론, 기여, 게임, 메일) 2023년 4월 3일 (월) 02:33 (KST)

summary와 description에 넣을 내용도 뭘 넣어야 할지 고민이네요. 추천평이 곧 생길 특집 게임이나 게임 메인 문서에 게임에 관한 설명이 있는 게임이면 Description 작성에 문제가 없으나 처음부터 바로 게임 내용이 시작되는 종류라면 좀 애매하고, 백괴게임 시절 만들어진 게임들은 '백괴클래식 + (장르명)' 정도로 summary를 달 수 있겠지만 리버티게임에서 만들어진 독자 컨텐츠의 summary는 제작자가 직접 고민해야 할 것 같습니다. --Senouis(토론장, 기여) 2023년 5월 10일 (수) 13:34 (KST)

게임 목록에서 게임의 기술 구조를 표시하는 것은 더 이상 의미가 없다고 생각합니다.

과거 백괴게임에서는 중국어판, 영어판을 따라 게임의 기술 구조를 썼는데요, 안드로이드 앱에서 자바로 개발했는지 코틀린으로 개발했는지를 따지지 않는 것처럼 더 이상 게임 목록에서 게임의 기술 구조를 표시하는 것은 더 이상 의미가 없다고 생각합니다. 그 대신에 서버에 저장 및 회원 가입 필요 여부, 플랫폼(웹, 윈도우, 리눅스, 맥)으로 표기하는 것이 보다 바람직하다고 생각합니다. --명진 (토론) 2023년 4월 3일 (월) 19:41 (KST)

• 1안: 기술 스택 간 우선순위를 둬서 높은 우선순위의 기술 스택 하나만을 대표로 선택한다. - 현재의 관습과 유사
• 2안: 기술 스택 분류를 통폐합한다. 위키 문법으로 가능한 링크, CGI, 루아는 위키로 (DB, 입력 상자와 같이 자바스크립트를 활용한 틀은 아마도 이쪽?), 플러그인이나 자체 소도구가 필요한 경우 자바스크립트로, 브라우저에서 바로 실행할 수 없고 별도의 파일을 다운받는 경우 네이티브? (윈도우 이외 플랫폼도 고려한 네이밍 필요)로 통폐합
  • 2-1안: 2안에서 DB 계정 추가
  • 2-2안: 웹, 설치로 단순화
• 3안: 여러 기술 스택 선택 가능
  • 3-1안: 게임 정보에서 여러 기술 스택 중 우선순위가 높은 기술 스택 하나만 대표 기술 스택으로 표시
  • 3-3안: 게임 정보에서 모든 기술 스택을 표시
• 4안: 기술 스택을 메타데이터와 게임아이콘에서 제외한다.

저도 위와 같이 비슷한 구상과 고민을 하고 있습니다. 이 제안의 주제는 4안처럼 보이지만 내용은 2안과 유사하군요. 2안에서 DB를 추가한 형태겠네요. 다만, 틀:DB2같이 서버에 저장하지만 공개되지 않는 저장소의 경우 특별한 취급을 받을 필요가 없다고 생각됩니다. 그리고 자바스크립트는 기존 위키 게임과 조금 많이 다르기 때문에 위키 게임과 자바스크립트 게임을 웹 게임으로 합칠지 말지 고려할 필요가 있겠습니다. 윈도우에서 바로 실행 가능한 프로그램인지, 자바 같은 런타임을 깔아야하는 프로그램인지와 비슷하게 플러그인을 쓸 지 말지는 사용자에게도 와닿는 차이이기 때문이죠. 다만 자바스크립트로 문서를 자동 편집하는 게임은 DB로 표시할지, 자바스크립트로 표시할 지 문제가 있죠. 이 문제는 아래 1안과 절충할 수도 있겠습니다. 그리고 게임의 기술 구조를 알면 사용자가 게임의 퀄리티를 예상할 수 있을 것 같기도 해서 사용자 입장에서 완전히 불필요할 것 같지는 않지만 그래도 그리 중요한 역할은 아닌 것 같습니다. 저는 1, 2, 4안 중에 고민하고 있습니다. --hsl(토론, 기여, 게임, 메일) 2023년 4월 3일 (월) 20:45 (KST)

그렇다면, 기술 구조는 게임아이콘에서 빼는 대신에 수집 데이터 항목을 신설하여 미라헤이즈에 계정 만들기를 해야 하는지(개인 정보; True, False, Optional로 지정하며, 기본값은 False), 데이터를 저장해야 하는지(앱 활동의 앱 상호작용; 개인 정보를 False로 지정하지 않는 경우 무조건 True로 자동 지정), 플러그인 또는 데이터 등 사용자 문서/데이터의 공개된 장소에서 저장해야 하는지(앱 활동의 사용자 문서에 저장/공개된 장소에 저장)를 밝히면 될 일입니다. 게임 개발자는 가능하다면 데이터를 비공개로 저장하도록 개발할 것을 유도하면 됩니다. 그리고 플랫폼은 자바스크립트 기반의 플러그인 설치 필요 여부와 상관없이 웹, 혹은 다운로드하여 플레이 가능한 운영체제들을 표기하면 됩니다. 참고로 스팀과 itch.io에서는 게임 목록에서 사용 가능한 플랫폼이 표시되어 있고, 에픽 게임즈 스토어에는 그게 표시되어 있지 않습니다. --명진 (토론) 2023년 4월 4일 (화) 01:49 (KST)

일단 로그인 필요 여부는 명세에 반영하였고, 공개된 장소에 세이브 여부는 세이브 문서 경로를 지정하는 기능도 겸하여 형식을 구상하고 있습니다. 만약 설치형이 윈도우, 맥, 리눅스, 안드로이드, iOS 등 여러 플랫폼을 지원할 경우 게임아이콘을 어떻게 해야 하나의 문제도 발생하겠군요. 기술 구조 개편에 대해서는 이번주 동안 다른 사용자의 의견도 기다려보겠습니다. --hsl(토론, 기여, 게임, 메일) 2023년 4월 4일 (화) 13:13 (KST)

조금 더 구체적으로, 플랫폼 속성은 선택적으로 작성하게 하여 웹만 지원할 경우 생략이 가능하고, 그 외의 플랫폼을 지원하는 경우 3-3안처럼 여러 플랫폼을 배열로 작성할 수 있게 하고 모두 표시하는 것이 좋겠습니다. 물론 직접 작성할 때에도 웹을 포함할 수 있고요. 기존의 link, cgi, javascript, lua는 web으로 통합하고 windows는 유지하며 linux, macos, ios, android 정도를 추가할 수 있겠네요. 속성 이름도 platform으로 바꾸는 것이 좋겠네요. 게임아이콘은 전면적으로 개편하는 것이 좋겠습니다. --hsl(토론, 기여, 게임, 메일) 2023년 4월 6일 (목) 23:50 (KST)

완료 리버티게임:게임 메타데이터에 제안사항을 반영하였습니다. 게임 메타데이터는 아직 확정되지 않았으므로 누구나 얼마든지 제안하고 수정할 수 있습니다. 확정 이전까지는 언제든지 이의제기나 다른 의견을 제시하셔도 좋으며, 이러한 의견을 환영합니다. --hsl(토론, 기여, 게임, 메일) 2023년 4월 7일 (금) 19:03 (KST)

플랫폼 표기에서 iOS는 앱 스토어 전용이므로 뺄 필요가 있습니다.

현재 리버티게임의 플레이 가능한 플랫폼에 iOS가 포함되어 있습니다만, 애플의 정책에 따라 iOS용 게임의 경우 리버티게임을 통할 수 없고 앱 스토어에서만 다운로드가 가능합니다. 따라서 저는 플랫폼 표기에서 iOS는 빼는 게 바람직하다고 봅니다. --명진 (토론) 2023년 4월 7일 (금) 23:17 (KST)

저도 그래서 넣을까 말까 고민하다가 웹 버전이나 데스크톱 버전을 제공하면서 같이 곁다리로 지원할 때 사용할 때와 같이 만일을 대비해서 넣은 것이었습니다. 하지만 솔직히 요즘엔 웹으로 다 되므로 웹 이외의 플랫폼을 지원하는 경우는 손에 꼽을텐데 앱스토어에 수수료까지 내면서 올릴 가능성이 희박하기는 하죠. 이 부분은 좀 더 검토해보겠습니다. --hsl(토론, 기여, 게임, 메일) 2023년 4월 8일 (토) 01:04 (KST)

저도 빼는 것에 찬성합니다. 일단 제대로 개발하려면 사용자가 적은 맥이 있어야 하고, 앱스토어 수수료까지 감수하며 iOS 앱으로 포팅된 게임이 리버티게임에서 발표될 가능성이 0%에 수렴한다고 생각합니다. 리버티게임의 웹 게임이 모바일 게임으로 포팅된다면 안드로이드가 전부일 텐데 모바일 아이콘은 과감히 안드로이드 심볼로 통일해도 문제가 없을 것 같습니다. --Senouis(토론장, 기여) 2023년 4월 8일 (토) 14:11 (KST)

그렇다면 일단은 빼두고 혹시라도 필요할 일이 생긴다면 요청을 받아서 추가하거나 기타로 분류해야겠네요. --hsl(토론, 기여, 게임, 메일) 2023년 4월 8일 (토) 16:01 (KST)

제작자와 제작자들을 authorname으로 통일시키는 것이 어떻습니까?

대신 authorwebsite를 추가하여 기본값은 authorname에 적힌 사용자 문서로, false를 지정하면 개별로 링크를 추가할 수 있는 겁니다. --명진 (토론) 2023년 5월 29일 (월) 23:50 (KST)

이미 현재 프로젝트 문서에 적혀있는 메타데이터 구조가 제작자와 제작자들을 구분하지 않고 author element로 통일합니다. 현재 Hsl0님이 남겨주신 매크로 코드 역시 그에 맞춰서 주 기여자가 맨 앞에 오는 배열이나 단일 string으로 author를 설정하네요. 그래서 일단 그걸로 돌릴 예정입니다. --Senouis(토론장, 기여) 2023년 5월 30일 (화) 00:36 (KST)

Category 멤버를 만들어야 할 것 같습니다.

game.json 전체 목록을 미디어위키의 search API로 가져올 수 있긴 하지만 장르별 보기 기능 구현을 위해 현 메타데이터 구조에서 category 멤버를 추가해 미디어위키 categorymembers API로 정확하게 해당 장르의 게임만 가져오게 해야겠습니다. 매크로 편집으로 game.json의 genre 멤버를 가져와 첫째 Element 값을 기반으로 category 멤버를 만들 때 [[분류: (genre element 값) 장르 태그가 붙은 게임 JSON]]를 넣으면 JSON 파일에 분류가 붙는 걸 이용한 거죠. 가령 어드벤처 게임이라면 [[분류: adv 장르 태그가 붙은 게임 JSON]] 문자열 데이터를 삽입하면 어드벤처 게임의 game.json 문서에 해당 분류가 삽입되며 어드벤처 게임만 불러오게 할 수 있습니다. --Senouis(토론장, 기여) 2023년 6월 5일 (월) 23:57 (KST)

일단 철회하겠습니다. 직접 편집으로는 안 붙네요. --Senouis(토론장, 기여) 2023년 6월 6일 (화) 00:03 (KST)

이왕이면 F-Droid에서 불러오기 쉽게 genre를 categories, author를 authorname으로 정합시다. 그렇게하면 특별히 변수를 변경하지 않고도 F-Droid에서 쉽게 리버티게임의 안드로이드 앱을 불러올 수 있습니다. --명진 (토론) 2023년 6월 6일 (화) 01:48 (KST)

어드벤처 게임의 도로교통 게임 중 가상 노선에 속한 게임들의 game.json이 만들어지지 않았습니다.

이 문제는 제가 특정 게임의 AuthorName을 추가하기 위해 game.json을 찾아봤으나, 그게 없어서 제가 그 특정 게임의 game.json을 직접 만들었습니다. --명진 (토론) 2023년 6월 8일 (목) 03:32 (KST)

완료 제가 발전소에서 토론 중인 게임을 제외한 모든 게임을 game.json을 만들었습니다. --명진 (토론) 2023년 6월 28일 (수) 17:52 (KST)

특정키만 첫글자만 대문자인 이유가 무엇인가요?

AuthorName, Name, IssueTracker, Changelog, Summary, Description, CurrentVersion만 캐피털라이즈 문자열 방식을 사용하고 나머지 키는 전부 소문자인 이유가 궁금합니다. 필수값만 그런줄 알았는데 그것도 아닌 것 같네요.. --BANIP (토론) 2023년 8월 1일 (화) 11:53 (KST)

리버티게임:게임 메타데이터의 설명에 따르면, ‘소문자 표기는 리버티게임에서만 사용하기 위한 변수 표기이며 대소문자 표기는 리버티게임의 game.json을 F-Droid에서 직접 읽을 경우 호환을 위한 변수 표기입니다.’이라고 되어 있습니다. --명진 (토론) 2023년 8월 1일 (화) 15:06 (KST)

대소문자란 뜻이 캐피털라이즈된 문자열이라는 의미였군요. 일반적으로 json 프로퍼티는 한가지 네이밍규칙을 사용하기에 언젠가 전부 카멜케이스로 통일시켰으면 싶네요 --BANIP (토론) 2023년 8월 2일 (수) 09:08 (KST)

그런데 왜 굳이 리버티게임 메타데이터를 F-Droid에 호환시키려는 건지 의문입니다. 제가 알기로는 미디어위키는 F-Droid에 호환되지 않는 것으로 알고 있습니다. 관련 확장 기능도 없고, F-Droid 저장소를 만들려면 미디어위키와는 별개의 서버 소프트웨어가 필요합니다. 서로 관련없는 곳에서 호환시키려고 노력하는 것은 무의미한 작업이 아닌가 싶습니다. 어차피 호환이 안된다면 기존의 간결한 네이밍 규칙을 사용하는 게 맞다고 생각됩니다. --hsl(토론, 기여, 게임, 메일) 2023년 8월 6일 (일) 12:47 (KST)

찬성 명진님께서 그리시는 그림이 무엇인지 확실히 이해가지는 않지만 간단한 json변환작업으로 F-droid와 호환되는 메타데이터로 변경할 수 있음과 키 네이밍 규칙의 다름으로 혼란을 겪는 기존 사용자의 입장을 생각하면 hsl0님의 말씀이 정당하다 생각합니다. --BANIP (토론) 2023년 8월 6일 (일) 13:07 (KST)

찬성 저의 무리한 건의사항이었네요. 무엇보다 F-Droid용 자체 저장소를 운영하려면 별도의 서버가 있어야겠죠. author를 authorname으로 변경하는 것 및 changelog, currentversion만을 제외하고 대소문자 변경 이전의 스키마로 롤백한다면 찬성합니다. 솔직히 IssueTracker는 위키 기준으로 토론에다 쓰면 되기 때문에 불필요합니다. --명진 (토론) 2023년 8월 7일 (월) 00:20 (KST)

제가 game.json이 서버의 부하를 줄이기 위해 존재한다고 했었죠? 그렇다면 AuthotName은 그냥 author로 롤백하는 게 맞습니다. 다음으로 currentversion은 CarmalCase 표기법을 철회하는 거니까 간단하게 version으로 변경할 것을 건의합니다. --명진 (토론) 2023년 8월 7일 (월) 00:53 (KST)

찬성 이 의견은 철회하신걸로 확인되는데 AuthorName => author로 변경, CurrentVersion => version 변경은 괜찮다고 생각합니다. 의미전달에 이상이 없으면 최대한 명료한 문자열로 두는게 맞습니다. --BANIP (토론) 2023년 8월 7일 (월) 02:43 (KST)

changelog를 쓰고 있거나 쓸 예정인 틀이나 시스템이 있나요? 그렇지 않다면 체인지로그도 따로 지정할 필요는 없을 것 같습니다. --hsl(토론, 기여, 게임, 메일) 2023년 8월 7일 (월) 01:09 (KST)

이미 몇몇 게임에서 게임의 변경이력이 적혀 있습니다. 예: 위키방송 체험/변경이력 --명진 (토론) 2023년 8월 7일 (월) 01:20 (KST)

물론 그렇긴 합니다. 하지만 이러한 문서를 트래킹할 필요성이 있는지 모르겠습니다. 게임 메타데이터에서 트래킹하는 문서는 전부 틀이나 시스템에서 필요로 하기 때문에 존재합니다. 개인정보 취급방침은 틀:개인정보를 위해, 게임별 편집 지침은 추후 개발될 편집 정책 요약앞으로 게임의 편집창 상단에 편집 가능 여부를 나태내는 틀이 표시됩니다. (부분) 편집 가능한 게임은 편집 지침의 요약을 틀에 포함시킬 수 있습니다.에 링크되거나 첨부될 예정입니다. 체인지로그는 트래킹이 필요한 시스템이 있습니까? --hsl(토론, 기여, 게임, 메일) 2023년 8월 7일 (월) 01:30 (KST)

개발자가 게임에 사용자와 내용을 수정할 경우 (위키방송 체험/변경이력에 데이터 이관법이 나와있듯이) 이관법을 알릴 필요가 있습니다. 이 파라미터는 이런 일이 일어날 때 필요한 틀을 통한 표시 및 링크입니다. 레이아웃이 미구현 상태이지만 이게 예시입니다.​ --명진 (토론) 2023년 8월 7일 (월) 10:15 (KST)

키를 세개정도 추가하려고 합니다.

• created(선택) : 게임이 작성된 날짜가 기입될 예정입니다. 개발일에 따라 백괴클래식 분류를 추가하고 새로 개발되는 게임아이콘 틀에 개발일을 추가하기 위해 만들 예정입니다.
• image(선택) : 게임을 대표하는 이미지가 기입 될 예정입니다. 메인페이지에 게임 광고를 올릴때, 특집게임 선정 광고에 업로드할 때, 새로 개발되는 게임아이콘틀에 사용됩니다. 등재가 결정되면 game.json 수정봇을 돌려 메인 페이지에서 사용되는 이미지를 기입할 예정입니다.
• webtech(선택) : 이전에 웹 기술 스택에 명시에 관한 토론이 한번 있었다가 플랫폼 프로퍼티로 교체가 된 값입니다. 웹 게임 플랫폼의 하위 항목에 사용 될 프로퍼티입니다. 기존 게임아이콘의 기술스택 분류에 해당합니다. webtech는 문자열 상수값으로 한가지를 선택 할 수 있으며 상수에 해당하는 설명은 아래와 같습니다.
  • link : 일반 링크 사용(기본값)
  • cgi: url 파라미터 사용
  • db : DB 사용
  • js : 자바스크립트 사용
  • engine : 자바스크립트 엔진 사용

더 나은 키 네이밍이 있을지, 추가할 값이 있을지, 또 추가적으로 문제 될 사항이 있는지 검토 부탁드립니다. --BANIP (토론) 2023년 8월 1일 (화) 12:00 (KST)

이미 ‘#게임 목록에서 게임의 기술 구조를 표시하는 것은 더 이상 의미가 없다고 생각합니다.’를 통해서 기술 구조 대신에 플랫폼을 사용하기로 했습니다. 제가 보기에는 기술 구조는 따로 표기하지 않고 플레이어가 직접 플레이해보면 체감할 수 있으리라 봅니다.
image는 좋네요. 저는 사실 image, icon과 screenshot 세 가지가 필요하다고 생각합니다. image와 icon은 게임을 한 눈에 볼 수 있는 시각 디자인적인 포스터와 아이콘을 지정하는 자리이고 screenshot은 게임이 어떻게 진행되는지 대충 볼 수 있는 스크린샷입니다.
created는 게임을 개발하는 시점(리버티게임:삭제 정책#즉시 삭제될 수 없는 게임의 기준 참조)을 나타낼 때 유용합니다. --명진 (토론) 2023년 8월 1일 (화) 15:31 (KST)

저도 image는 추가가 필요하고 생각하며, created는 게임 정보를 불러올 때 성능 문제를 줄일 수 있다면 추가에 찬성하며, webtech는 어차피 추가하지 않아도 웹 게임이라면 딱히 구별할 필요가 없다고 생각합니다. --Senouis(토론장, 기여) 2023년 8월 1일 (화) 15:23 (KST)

그런데 게임이 하루 아침에 완성되지는 않는 만큼 created의 기준을 명확히 할 필요가 있습니다. 게임 개발을 시작한 날짜로 할 지, 개발이 끝난 날짜로 할 지와 같이 다양한 기준이 있습니다. 그리고 추가적으로 최근 업데이트된 날짜인 updated 추가도 건의해봅니다. --hsl(토론, 기여, 게임, 메일) 2023년 8월 6일 (일) 23:14 (KST)

명진님께서 언급하신 기술스택 명시에 대한 토론은 살펴보았으며 이의제기나 다른 의견을 제시하셔도 좋다는 결론으로 확정나서 다시금 주제를 세웠습니다. '기술스택별 분류는 코틀린과 자바를 구별하는 것과 별반 다르지 않다'는 근거에 기반하여 의견을 제시하셨던데 저는 이와 같은 생각을 하지 않습니다. 아래 항목으로 제 생각을 명확하게 표현해보겠습니다.

• 일반적인 설치형 게임들은 어느 언어로 만들던 어느 엔진을 쓰던 상한점이 엇비슷해 게임을 분류할때 큰 분류로 작용하지 않습니다. 하지만 링크로만 이루어진 게임, CGI를 사용한 게임, 자바스크립트를 사용하는 게임들이 각각의 한계가 다르다는것은 모두가 인지하고 있습니다. 이들은 게임에서 표현할 수 있는 수준에서 큰 차이를 만들며, 이것은 사용자 경험에 분명히 영향을 미치기에 분류할 가치가 있습니다.
• 현재 플랫폼별 분류는 웹게임이 대부분을 차지하고 있어, 실질적으로 그다지 유의미한 구분을 제공하지 못하고 있습니다. 차후에 다른 플랫폼이 개발 될 여지가 있기에 플랫폼별 게임 분류는 남겨두는게 좋습니다. 하지만 현재는 기술스택별 분류가 더 실질적인 의미를 제공 할 수 있다는 의미입니다.

첫번째 항목은 사용된 기술에 따라 게임 줄세우기를 하자고 해석될 여지가 있겠네요. 물론 게임의 질과 완성도는 사용된 기술보다는 게임 설계자의 역량에 달려있기에 링크게임과 CGI게임에 따라 골품제를 나누자는 의미는 아닙니다. 보다 실질적인 게임분류로 사용자의 선택지를 넓혀주고 이후에 개발되는 게임필터에 대한 기능을 향상시키는 점에 초점을 두고 싶습니다. --BANIP (토론) 2023년 8월 1일 (화) 19:29 (KST)

그렇다면 기술 수준을 대체하여 개발 난이도로 바꾸어서 이렇게 합시다: 초급: 위키 문법만 사용, 중급: 파서 함수를 사용, 고급: 자바스크립트 등 스크립트 언어를 사용 --명진 (토론) 2023년 8월 2일 (수) 00:19 (KST)

찬성 전문용어를 쓰기보다 모든 사용자가 이해할 수 있는 용어로 통일하는게 맞을 것 같습니다. 편집요약에 남기신 기본적인 수준의 파서함수 사용이 중급게임의 기준이라는것 또한 동의합니다. --BANIP (토론) 2023년 8월 2일 (수) 00:31 (KST)

파서함수를 쓰고 안쓰고를 나눈다면 틀을 사용한 게임은 구분이 모호해진다고 생각됩니다. {{USERNAME}} 역시 단순한 파서 함수정확히는 파서 함수를 그대로 담은 별칭 틀에 속하기 때문에 정말 간단한 게임도 중급으로 표시해야 할 수도 있습니다. 따라서 저는 초급 중급을 통합하고, 초급은 위키, 고급은 스크립트와 같이 더 직관적인 명칭을 적용하는 것이 좋다고 생각됩니다. 그리고 이 경우 별도의 속성을 쓰는 대신 platform의 web을 확장하여 쓸 수 있을 것 같습니다. --hsl(토론, 기여, 게임, 메일) 2023년 8월 6일 (일) 13:05 (KST)

hsl0님의 의견대로 파서함수 사용을 전제로 두면 고려해야 될 사항이 많기에 파서함수를 기준으로 두는건 재고할 필요가 있을 것 같습니다. 링크로만 이루어진 문서는 초급, cgi와 cgi2혹은 이외의 방법으로 페이지간 변수를 관리하는 문서는 중급, 해당 게임을 위한 별개의 루아/자바스크립트가 만들어진 문서는 고급으로 두면 좋을 것 같습니다. --BANIP (토론) 2023년 8월 6일 (일) 13:55 (KST)

윈도우, 리눅스, 안드로이드용으로는 초급: 단순 씬 전환, 중급: 2D 씬 이동 가능, 고급: 3D 프로젝트 정도가 적당한 듯 합니다. --명진 (토론) 2023년 8월 2일 (수) 01:51 (KST)

설치형 게임은 고려해보지 않았으나 설치형 게임도 개발 난이도를 두자면 초급에 cli게임과 비주얼 노벨이라 명시하는 편이 좋을 것 같네요. 사실상 게임 엔진의 존재 때문에 초급보다 고급이 더 쉬울수도 있기에 개발 난이도라 표현하는게 맞나 싶기도 하지만요..--BANIP (토론) 2023년 8월 2일 (수) 09:25 (KST)

그럼 방법이 있지요. 고급을 없애는 겁니다. 중급과 고급을 하나로 통합하는 것입니다. --명진 (토론) 2023년 8월 2일 (수) 10:34 (KST)

웹 게임은 초급, 중급, 고급으로, 설치형 게임은 초급과 고급으로 두신다는 말씀이실까요? --BANIP (토론) 2023년 8월 2일 (수) 10:39 (KST)

네. 그런데 정확히는 웹 게임이 아니라 개발 난이도(위키), 개발 난이도(기타)로 두는 겁니다. 리버티게임에는 웹 게임 중에 추후 서비스 예정인 게임 앤진으로도 게임을 만들 수 있을 예정이기 때문입니다. --명진 (토론) 2023년 8월 2일 (수) 13:35 (KST)

저는 초급, 중급, 고급 보다는 특성을 더 직관적으로 나타내도록 초급은 텍스트 또는 그래픽 없음, 중급은 2D, 고급은 3D 정도로 표현하는 것이 좋다고 생각됩니다. --hsl(토론, 기여, 게임, 메일) 2023년 8월 6일 (일) 13:05 (KST)

의견 3D 게임은 카메라 뷰 배치, 조명의 특성(점 라이트, 디렉셔널 라이트, 스포트라이트)에 대한 지식이 필요하고, Projectile과 히트스캔의 구현 및 최적화에 더 노력을 기울여야 한다는 걸 생각하면 그냥 2D 중급, 3D 고급이 맞는 것 같습니다. 개발 난이도 표기는 중요할 것 같네요. --Senouis(토론장, 기여) 2023년 8월 6일 (일) 14:04 (KST)

설리 그걸 생각하면 개발 난이도는 웹 게임이든 플랫폼 의존적인 게임이든 단계 구분에 차이는 없을 것 같습니다. --Senouis(토론장, 기여) 2023년 8월 6일 (일) 14:06 (KST)

질문 created와 image키에 대해서는 이견 없으시는것으로 보이는데 지금 명세에 반영시켜도 될까요? --BANIP (토론) 2023년 8월 7일 (월) 21:04 (KST)

완료 created와 image키에 대해 메타데이터 명세에 기재했습니다. tech 필드는 절충안이 필요해보이는데 관리자분께서 조정해주시면 감사드리겠습니다. --BANIP (토론) 2023년 8월 16일 (수) 09:25 (KST)

2023년 8월 6일 메타데이터 변경사항 내용입니다.

변경된 문서는 특수:기여/BANBOT에서 확인 가능합니다.

• game.json이 없는 문서 일괄 생성
• created 키 일괄 추가
• tech 키 일괄 추가

  기존 게임목록의 리스트를 참고하여 기본 1, cgi및 db는 2로 지정하였습니다. 추후 플러그인, 플러그인X 틀을 포함하고 있는 게임은 3으로 일괄 수정 예정입니다.

• image 키 일괄 추가

  메인 페이지에서 이미지를 사용하고 있는 경우 해당 이미지를 추가했습니다.

• repair, abandon, construction키 일괄 추가

  메인 페이지에서 {{수리중}} {{공사중}} {{버려진 게임}}을 사용하고 있지만 game.json에 기재되지 않은 경우 해당 문서의 마지막 리비전을 사용해 날짜를 포함하여 기재했습니다.

• 콘텐츠타입이 JSON이 아닌 문서 일괄 변경

tech값의 경우 추후 초급/중급이 통합되는것으로 결론나면 2 => 1로 변경토록 하겠습니다. --BANIP (토론) 2023년 8월 7일 (월) 01:21 (KST)

새로 추가된 몇몇 키는 아직 게임 메타데이터 명세에 반영되지 않았습니다. 물론 대부분은 총의가 모이기는 했지만 tech의 경우 그렇지 않은 것 같습니다. 규격은 계속 바뀔 수 있기 때문에 적어도 명세를 먼저 작성한 뒤에 봇을 돌리는 것이 맞다고 생각됩니다. 너무 섣부르지 않았나 싶습니다. --hsl(토론, 기여, 게임, 메일) 2023년 8월 7일 (월) 01:36 (KST)

말씀해주신 것처럼 이번 게임 메타데이터 일괄 변경 작업에는 아직 명세에 포함되지 않은 사항이 포함되어 있습니다. 이번에 새로 게임목록 문서의 리뉴얼 작업이 있었던것을 알고계실겁니다. 이 문서에서 사용되는 데이터들의 대부분이 게임 메타데이터에서 들고 오는 것이기에 일부 부정확하지 않은 게임 정보들의 많은 수정이 필요했습니다. 이번 변경은 기존 게임 목록, 문서의 최근 리비전, 최초 리비전 등에서 취합된 정보를 기반으로 합니다. 메타데이터에서 사용할 정보 취합과정이 생각보다 난해하였기에, 메타데이터 변경이 필요한 작업이 생길 때 마다 일괄 반영하는것 보다, 기존에 변경이 필요한 사항을 모두 반영한 뒤 차후에 지우는것이 작업 효율성 측면에서 유리하다고 판단해 이번에 토론에 올린 사항까지 선반영하게 되었습니다. 작업 내용에 대해 상세 설명이 부족했다고 생각되며 제 의견을 강행하기 위해 이런 방법을 선택했다고 느껴지셨으면 사과의 말씀을 드리고 싶습니다. --BANIP (토론) 2023년 8월 7일 (월) 02:06 (KST)

저에 이어서 BANIP님도 건의에 대해 의견을 모으는 것을 잊으신 것 같습니다. --명진 (토론) 2023년 8월 7일 (월) 01:44 (KST)

아, 갑자기 전에 보지 못했던 키들을 며칠 전에 몇몇 game.json에서 발견했는데 그런 목적으로 추가된 거였군요. 그런데 초심자 개방용 편집 개방 예정인 게임들에 abandon 키 때문에 모듈 에러가 등장해서 키가 추가된 걸 발견한 날에 해당 게임들의 abandon 키를 지웠는데, 복구할까요 아니면 그냥 지운 상태로 둘까요? --Senouis(토론장, 기여) 2023년 8월 7일 (월) 14:05 (KST)

초심자 개방용 게임이면 지우셔도 무방할것으로 보입니다. 버려진 게임 키가 존재시 모듈 에러가 발생하는 부분은 확인 해 보겠습니다. --BANIP (토론) 2023년 8월 7일 (월) 20:11 (KST)

created와 image 필드는 별다른 이견이 없으시면 금일 자정 이후 스키마에 반영하겠습니다. tech필드는 의견이 갈리는것 같으니 관리자분께서 중재해주시면 감사드리겠습니다. --BANIP (토론) 2023년 8월 9일 (수) 02:45 (KST)

이용등급의 게임 내용정보를 입력 필드(contentdescriptor)가 리버티게임 등급정보에도 필요해보입니다.

폭력성, 사행성, 언어의 부적절성 등에 속하는 게임 내용정보가 게등위의 등급 승인을 받은 경우에만 입력 할 수 있게끔 되어있습니다. 모든 게임에 등급 틀을 제거하고 장르 분류와 같이 자동 관리되게 하려는데, 생각보다 내용정보가 담긴 게임이 많아서 이러한 값들을 먼저 game.json에 담아둘 필요가 있어보입니다. --BANIP (토론) 2023년 8월 16일 (수) 09:18 (KST)

새로운 saves 규격을 제안합니다.

새로운 saves 규격은 제목 문법과 겹치지 않는 특수 문법과 정규표현식으로 제목의 패턴을 정의하고, 각 문서에 약칭을 정할 수 있으며 콘텐츠 모델과 스키마나 기반 틀을 지정할 수 있습니다. 자세한 내용은 사용자:hsl0/saves 규격에 작성했습니다. 다만, 사용자 하위 문서에 저장될 게임 별 세이브 문서의 접두어를 지정하는 방식에 대해서는 더 논의되어야 할 것 같습니다. /Data/나 /DB/로 통일할 지, 아니면 사용자 별로 JSON이나 단독 텍스트 문서로 설정하는 문서를 만들거나 option API를 통해 직접 선택할 수 있게 할 지 말입니다.--hsl(토론, 기여, 게임, 메일) 2023년 10월 11일 (수) 23:04 (KST)

image의 배열화?

가령, 마법의 MD-5 시뮬레이터는 현재 2개의 대표 이미지가 있는 것으로 압니다. 이런 경우에는 대문이나 게임 목록에서 랜덤하게 이미지를 뽑아 보여줄 수 있도록 배열인 경우를 규격에 추가할 필요가 있다고 생각합니다. Senouis(토론장, 기여) 2024년 8월 19일 (월) 01:59 (KST)