리버티게임:토론란/스키마 수정안 논의/총의

참고: 이 주제는 36일동안 편집되지 않았으므로 이 주제는 보존된 것으로 간주됩니다. 정말로 답변이 필요한 주제가 아니라면 추가하지 마세요.

발의 및 첨삭

이 부분의 본문은 리버티게임:토론란/스키마 수정안 논의입니다.

조정안 투표

• 표결 기간: 2023년 8월 28일 (월) 11:10 (KST) 부터 2023년 9월 9일 (토) 09:00 (KST)까지
• 표결 가능 유저: 조정안 투표는 prouser 혹은 자동 인증된 사용자, 최종안 의견은 모든 리버티게임 사용자, 1인당 1계정으로만 투표할 것

장르명 변경

게임 메타데이터(game.json)에서 genre필드로 사용되는 값의 변경을 위한 토론입니다.

제안

• 1안 : 기존 코드 사용
• 2안 : 별도의 코드 대신 실제 분류 이름 사용 (adv => 어드벤처 게임, mus => 음악 게임)
• 3안 : 별도의 코드 대신 '게임'낱말을 제외한 실제 분류 이름 사용 (adv => 어드벤처, mus => 음악)

투표

3안 --BANIP (토론) 2023년 8월 28일 (월) 11:31 (KST)

1안 이것까지 굳이 변경할 필요가 있을까요? --Senouis(토론장, 기여) 2023년 8월 28일 (월) 15:40 (KST)

3안 그 자체로 의미가 드러나므로(Self-explanatory) 사람에게도 직관적이고, 기계에게도 분류로의 변환이 간단합니다. 사람이 읽기 편하고 기계가 활용하기 편한 것이 좋은 스키마가 갖춰야할 조건이고, 2, 3안이 이를 만족하는 최적의 안입니다. 저는 둘 중에 '시간 낭비하기'에 '게임'을 붙일 필요가 없는 3안을 선택하겠습니다. --hsl(토론, 기여, 게임, 메일) 2023년 8월 28일 (월) 23:33 (KST)

3안 찬성 --명진 (토론) 2023년 9월 8일 (금) 15:42 (KST)

3안 일일히 메타데이터 안내 문서에서 장르 코드를 확인할 필요가 없어지면 신규 제작자들에게도 도움이 될 것입니다. — Malgok1 (토론·기여) 2023년 9월 8일 (금) 16:50 (KST)

2안 또는 3안 한국어 사이트인 만큼 2안이랑 3안이 이용자들에게 시안성이 좋을 것 같습니다.--오니츠카 (토론) 2023년 9월 8일 (금) 22:27 (KST)

결론

전체 6개 표 중에 4표가 확실하게 3안을 지지하여 과반을 득표했습니다. 따라서 3안으로 결론 내려도 되겠습니다. --Senouis(토론장, 기여) 2023년 9월 10일 (일) 15:03 (KST)

게임 내용 정보(rating.libertygame.summary) 필드 추가

게임 메타데이터(game.json)에서 등급 심의 하위 필드인 게임 내용 정보(summary)의 추가 시점에 관한 토론입니다. 게임 내용 정보에는 선정성, 폭력성, 언어의 부적절성 등 게임 등급 판단의 기준에 대한 내용이 담기게 됩니다.

제안

• 1안 : 리버티게임:등급 심의 개편 후 추가
• 2안 : 추가 후 리버티게임:등급 심의 개편, 개편전까지 해당 필드는 비표준이므로 실제 효력이 없음을 명시

투표

2안 기존의 {{등급}}, {{게임 등급}} 틀을 {{게임 정보}}로 통합시키기 위해서 기존에 등급 분류에서 사용되던 게임 내용 정보들을 담아둘 곳이 필요합니다. 게임 메타데이터가 각종 도구에서 읽히기 위해 만들어진 만큼 보다 유연하게 사용되었으면 좋겠습니다. --BANIP (토론) 2023년 8월 28일 (월) 11:31 (KST)

2안 지금 토의 진행 중인 등급 심의 개편과 별도로 제작자가 자율적으로 등급을 정할 때 해당 등급으로 기준을 정한 이유에 대한 근거를 제대로 기록할 위치가 없습니다. 현재 명시된 메타데이터 명세는 아직 버전 1.0 선언이 안 되었으니 임시라고 명시하는 것이 좋겠습니다. --Senouis(토론장, 기여) 2023년 8월 28일 (월) 15:44 (KST)

1안 현재 각 게임의 내용정보표시는 제작자가 등급을 정한 이유를 직접 표시한 것이 아닌 사용자:명진님이 임의로 리버티게임 등급 분류 체계에 없는 내용정보표시를 틀을 수정해 변수를 추가한 것입니다. 오해 없으시길 바랍니다. 물론 등급 분류 체계에 내용정보표시가 도입된다면 그대로 활용할 수 있으니 고마운 일이지만, 아직은 도입되지도, 도입된다는 보장도 없습니다. 따라서 인과관계를 바꾸면서까지 진행시켜야 할 급한 일이 아닙니다. --hsl(토론, 기여, 게임, 메일) 2023년 8월 28일 (월) 23:16 (KST)

hsl0님이 데이터의 무결성을 중요시하는 생각도 이해되지 않는바는 아닙니다만, 명세 변경으로 인한 유지보수의 비용이 큰 프로젝트에 대해서는 변인통제가 힘들기 때문에 철두철미하게 지키는게 맞습니다.

하지만 게임 메타데이터에 비정규 데이터가 있다고 해서 시스템이 망가지지는 않기 때문에 유도리있게 처리되었으면 좋겠다는게 제 생각입니다. 메타데이터를 일괄 수정하는 제입장에 대해서도 한번에 수정했다가 부결되었을때 나중에 내리는쪽이 편하기도 하고요..

이유가 어찌됐든 명진님도 좋은 의도로 추가하셨고 게임플레이전에 사전에 민감한 요소에 대해 플레이어에게 환기시키는 역할을 하고있는것도 사실입니다. 큰 문제가 되지 않는다면 프레임을 중시하는것보다 느슨하게 풀어주는게 편집자분들 모티베이션 상승에 도움이 될 것 같습니다. --BANIP (토론) 2023년 8월 29일 (화) 00:38 (KST)

2안 찬성 선 요소 추가 후 개정하여도 문제가 없다고 생각합니다. --명진 (토론) 2023년 9월 8일 (금) 15:42 (KST)

2안 — Malgok1 (토론·기여) 2023년 9월 8일 (금) 16:53 (KST)

결과

전체 5표 중 2안이 4표를 득표했으므로 결론을 2안으로 해도 되겠습니다. --Senouis(토론장, 기여) 2023년 9월 10일 (일) 15:03 (KST)

기타 이견이 없는 최종안

발의 및 첨삭단계에서 추가된 의견 중 특별히 문제가 없다고 판단되는 안입니다. 더 수정이 필요해보이는 안은 자유롭게 지적해주시면 감사드리겠습니다.

네이밍 통일에 필요한 명명이 필요한 필드

1. Summary => summary
2. IssueTracker => issuetracker
3. Changelog => changelog
4. Description => description

간결화가 필요한 필드

1. rating.grac.contentdescriptor => rating.grac.summary
2. CurrentVersion => version
3. AuthorName => author

신설 필요 필드

1. featured.date - 특집기사 선정일
2. featured.description - 특집기사 추천평
3. rating.libertygame.summary - 선정성, 폭력성과 같은 게임 내용정보
4. rating.libertygame.author - 등급 지정자 표기 (선택 사항)

   rating.libertygame의 경우 수정으로 확정 시 리버티게임:등급 심의 개편 필요

   개편전까지 해당 필드는 비표준이므로 실제 효력이 없음을 명시

5. tech - 사용된 기술수준, 플랫폼 구분 없이 0~2까지 3단계로 지정

장르 필드 관련

• 실제 장르로 분류되는 값만 사용할 수 있도록 화이트리스트 구현 필요
• 1차분류 정리 필요
  1. 어드벤처 게임의 하위장르에 해당하는 분류:오픈 월드 게임, 분류:철도 교통 게임, 분류:도로 기행 게임, 분류:탈출 게임, 분류:함정 피하기 게임을 1차 장르로 격상
  2. 어드벤처 분류를 사용하는 게임 중 장르 분류를 두 개 이상 사용하는 경우, 해당 게임의 어드벤처 게임 장르 삭제
• 장르명 '시간 낭비하기'를 '시간 낭비하기 게임' 장르로 교체

기타

• saves 규격 구체화
  1. 스키마에 명시 필요, 타입은 (string || string[])
  2. 게임명과 유저명에 해당되는 $name, $user로 템플릿스트링 변수명 수정
• issuetracker 규격 구체화
  1. 외부 링크로 한정
  2. 리버티게임 내부 게임은 해당게임 토론 이름공간으로 통일을 강조, 소스코드를 리버티게임 외 외부 저장소를 사용하는 경우 사용 할 수 있게 적절히 유도

총의

찬성 발의 및 첨삭 과정에서 검토하였습니다. --BANIP (토론) 2023년 8월 28일 (월) 11:31 (KST)

중립 is's'uetracker라고 적어야 하는데 오타가 났네요. 수정되면 찬성으로 돌리겠습니다. --Senouis(토론장, 기여) 2023년 8월 28일 (월) 15:45 (KST)

지적 감사합니다. 수정하였습니다. --BANIP (토론) 2023년 8월 28일 (월) 15:48 (KST)

찬성 그럼 찬성입니다. --Senouis(토론장, 기여) 2023년 8월 28일 (월) 15:56 (KST)

찬성 — Malgok1 (토론·기여) 2023년 9월 8일 (금) 16:52 (KST)

찬성을 하지만 의견 기존 오픈 월드 게임을 생활 게임으로 다시 변경을 한 다음 오픈 월드는 따로 분리하는 것을 원합니다. 한편 시간 낭비하기를 제외한 어드벤처와 캐주얼과 같은 장르의 하위 장르의 모든 2차 분류를 1차로 올리겠다는 것은 game.json 상에서는 찬성을 하나, 게임 목록의 장르의 표현에서는 반대를 표명합니다. (예를 들어 기존 탈출 게임이 어드벤처, 탈출로 분류되어 있으면 탈출로만 분류하며 게임 목록의 장르에서는 어드벤처 게임의 하위 장르로 표기합니다. 예언 게임의 경우도 캐주얼, 예언에서 예언으로만 분류합니다.) --명진 (토론) 2023년 9월 9일 (토) 00:54 (KST)

이번 토론이 끝나면 미처 생각이 미치지 못했던 사안들을 정리해서 다시 스키마 수정 첨삭안을 내는것이 좋겠습니다. 오픈월드 게임을 생활게임으로 변경, 등급 분류자 추가, 기획 문서의 위치 등이 대상이 되겠네요 --BANIP (토론) 2023년 9월 9일 (토) 03:15 (KST)

등급 분류자는 이번 토론에 이미 논의되어 총의를 모으는 과정에 있습니다. --명진 (토론) 2023년 9월 9일 (토) 08:50 (KST)

일단 1차 분류 제외하면 전원 찬성표를 던졌고, 생활 게임 1차 분류 아래 2차 분류로 오픈 월드를 둘지 고민하는 것만 아래 '기타 토론'에서 추가로 토의한 뒤에 정식 반영하는 것이 좋겠습니다. --Senouis(토론장, 기여) 2023년 9월 10일 (일) 15:06 (KST)

이번 토론에서 확정된 부분은 시간내서 전체 게임과 사용되는 틀에 반영하겠습니다. --BANIP (토론) 2023년 9월 11일 (월) 11:53 (KST)

기타 토론

의견 충돌이 있던 일부 안을 분리하고 최종안 토론을 열었습니다. --BANIP (토론) 2023년 8월 28일 (월) 11:26 (KST)

질문 혹시 생활 게임이라는 장르 아래에 오픈 월드 외에 다른 게임 장르를 둘 수 있다면 어떤 장르를 둘 수 있나요? 도시 탐험이나 도시 운영 게임도 하나의 장르로 봐야 할까요?--Senouis(토론장, 기여) 2023년 9월 29일 (금) 20:57 (KST)

대체 의견 음…토의가 너무 지체되었네요. 올 2분기에 미완성 도시 생활 게임을 단체로 발전소로 보내고자 하는데, 해당 발전소가 종료되는 시점에서 줄어들 도시 생활 게임의 수에 따라 오픈 월드 장르를 세부적으로 설정할지 아니면 도시 생활 게임을 통째로 오픈 월드 게임으로 분류할지 결정할 수 있을 것 같습니다. 그 시점에서 이 토의는 종료된 것으로 간주하는 것이 좋겠습니다. --Senouis(토론장, 기여) 2024년 2월 19일 (월) 15:31 (KST)

이미 문서에도 반영되었고 사실상 종결된 것으로 알고 있었는데 아직 종결된 것이 아니었군요... 그 사이 사:hsl0/saves 규격에 saves 필드의 상세적인 규격 아이디어가 정리되었고, tech에 대한 설명이나 예시가 빈약하다고 느껴집니다. 잘 활용이 될지도 모르겠고요. 이미 완전히 합의된 내용을 반영하는 시간을 늦출 필요는 없지만 논의가 불완전한 일부는 확실히 해야 할 것 같습니다. 논의가 필요한 부분 각각 합의되는 대로 문서에 반영시키면 될 것 같네요. --hsl(토론, 기여, 게임, 메일) 2024년 2월 19일 (월) 21:31 (KST)

의견 의견 제시입니다.

• 규격 문서는 상당히 괜찮은 것 같네요. 그런데 리버티게임에 정규표현식의 수량자로 쓰는 특수 문자를 이미 사용한 백괴로또 6/45나 백괴낚시+ 같은 게임이 있어서, 저 메타데이터를 파싱하여 DB 문서 인식을 하려고 할 때 게임 이름을 따로 구분을 해야 할 것 같습니다. 아예 단일 기호 수량자(*, ?, +)는 빼 버리는 것이 어떨까요? {m,n}(중괄호만 사용)으로 통일하는 겁니다.
• tech는 메인 플랫폼의 기술 스택에 따른 노력의 양에 따라 다음과 같이 정리하면 되겠습니다.

• 웹 게임: 개발 환경을 따졌을 때 데이터의 휘발성 대응과 스크립트 사용 여부에 따라 정리했습니다.

• 0 - 하이퍼링크 어드벤처 방식 + CGI나 Linkget 같은 URL 파라미터 조작 게임: 사용자 별 데이터에 휘발성이 있습니다(volatile).
• 1 - 위키낚시 같은 초기 DB형 게임 및 DB2 등의 브라우저 저장소 활용 게임: 사용자 별 데이터에 휘발성이 없으며(non-volatile), 초심자용 편집 게임에도 현재 이런 기술 스택을 가진 게임은 한 개밖에 없습니다.
• 2 - {{플러그인}} 및 {{PluginX}}, 게임 엔진 등을 제작에 사용한 JavaScript/WebAssembly 활용 게임: 전반적인 개발 난이도가 0~1과 차원이 다릅니다. 아래 네이티브 프로그램 환경에서 나오는 게임들을 미디어위키에서 제공하는 기능만으로 구현하려면 날코딩 + 무지막지한 노가다로 구현해야 합니다.

• 네이티브 프로그램(windows, linux, mac, android, etc.) 게임은 애초에 특정한 프로그램(예: IDE, 게임 엔진 에디터) 등을 활용해 실시간 렌더링이 이루어지는 환경에서 제작할 수밖에 없습니다. 그리고 싱글플레이/멀티플레이 구분이 웹 게임에 비해 훨씬 중요하며 데이터 휘발성 문제가 장면 하나 넘어갈 때마다 고려해야 하는 기존 하이퍼링크 어드벤처 종류의 웹 게임만큼 중요하지 않습니다. 따라서 '컴퓨터 그래픽스 지식을 얼마나 요구하는가'에 따라 숫자 상의 표기를 조정합니다.

• 0 - 간단한 UI 요소를 활용한 정적 화면 어드벤처(기술 요소만 따지면 웹 게임의 0~1에 대응하나, 투하한 노력과 배경 지식을 보면 게임 제작 환경 및 기술 스택에 비해 구현이 손쉬움)
• 1 - UI 요소 없어도 사용자의 입력에 반응하는 일반적인 2D 렌더링 게임(기술 요소만 따지면 웹 게임의 2에 대응, 그러나 여기까지는 게임 제작 관련 지식이 많이 없는 사용자가 게임을 제작해도 멀쩡한 게임으로 내보낼 만한 상황이 있음)
• 2 - 3D 렌더링 요소가 있는 게임(2.5D로 불리는 효과가 있는 게임 포함, 웹 게임의 2에 대응하나 더 많은 컴퓨터 그래픽스 지식을 요구)

• 그러고 보니 오픈 월드라면 보통 단순한 탐험 외에 지역 이동에 제약을 느끼면 안 되는 완성된 게임으로 존재해야 하는데, 리버티게임의 도시 생활 게임에서는 없는 문서로 가는 링크를 기존 제작자가 만들어서 다른 사용자가 잠깐이나마 그 문서가 없다는 사실에 제약을 느끼기도 하고, 개별 문서마다 유저의 상상이 불가능하게 선택지가 정해져 있으며, 도시 생활 게임에 일거리를 고르는 컨텐츠가 없어서 심심해지는 경우도 있습니다. 이것들은 편집 개방된 게임이라면 모딩이 있는 샌드박스 게임이 되겠지만, 편집이 막힌 몇몇 개인 개발 도시 생활 게임은 오히려 테마파크형 게임으로 분류할 수 있겠네요. 그럼 오픈 월드는 추후에 게임 엔진 사용 개발이 정착될 경우에야 가능한 2차 분류로 두고 1차 분류 이름을 바꾸는 것이 좋겠습니다. 오픈 월드 -> 생활 시뮬레이션으로 변경하는 안에 찬성하는 것으로 의견을 변경할게요. 그리고 2차 분류로 '오픈월드', '샌드박스', '테마파크' 3개를 두는 것이 어떤가요? (개인 개발 도시 게임은 테마파크 분류, 백괴민국 등은 샌드박스로 분류, 오픈월드를 비움)

--Senouis(토론장, 기여) 2024년 5월 29일 (수) 20:26 (KST)

예전에 피드백이 있었군요. 이러한 수량자들은 이미 이러한 충돌 가능성을 고려하여 중괄호 안에서만 쓰도록 설계되어 있기 때문에 충돌 우려가 없습니다. 그리고 오픈 월드 게임과 리버티게임의 도시 생활 게임은 차이가 있기에 이름 변경에 찬성합니다. 먼 훗날 리버티게임에서도 진짜 오픈 월드가 나오기를 기원합니다. 그리고 tech에 대해서 방향성은 어느 정도 동의를 하나, 이게 정확히는 웹게임용, 네이티브 용이 아니라 위키용, 엔진용으로 나뉘는 것으로 압니다. 그렇다면 어딘가 활용할 때 이 둘을 구분해야하는데 구분할 방법이 없어 구현이 어렵습니다. --hsl(토론, 기여, 게임, 메일) 2024년 10월 11일 (금) 18:50 (KST)

네, 그럼 0.7 버전부터 생활 시뮬레이션으로 변경하고 오픈 월드는 명목상 2차 분류로 하기로 합시다. 그리고 tech는...제작 환경을 구분할 기술적인 방법이 없다면 어쩔 수 없겠군요. 그러면 스마트폰 운영체제에서 앱이 사용하는 기기 권한 설정처럼 게임이 주로 사용하는 API 세부 분류(I/O, 입력 이벤트 등)를 넣은 배열로 바꿔서, 어떤 기능을 사용해 게임이 구현되었는지 배열의 길이로 레벨링을 하는 것이 좋겠습니다. 그러면 아마 값이 3 이상으로 크게 늘어날 수도 있겠고요. Senouis(토론장, 기여) 2024년 10월 20일 (일) 16:09 (KST)

0.8 버전?

0.7에서 확실하게 업데이트를 하고자 genre에서 '오픈 월드' 대신 '생활 시뮬레이션'을 1차 분류로 삽입하는 것이고, '오픈 월드'는 선택적으로 포함 가능한 2차 분류로 변경하는 것이며, 별다른 이의가 장기간 없었기에 saves를 Hsl0님의 제안으로 먼저 확정하려고 합니다. 그러나 두 가지 문제가 아직 남아 있습니다.

• tech를 숫자 값으로 할 경우 제작 환경에 따라 기준을 세우기 어려움
• 리버티게임의 개방된 CSS 편집 특징 때문에 메타데이터 내의 특정 문자열 값을 직접 게임 대문이나 리버티게임:대문 등에 보여줄 경우 CSS 테러가 우려되며, 이에 따라 UI의 심미성/통일성을 유지하며 메타데이터 값을 직접 이용할 방법이 필요

그래서 0.8 업데이트에서는 마지막 대규모 변경으로 이렇게 바꾸고 싶습니다.

• tech는 더 이상 값으로 지정하지 않고, 대신 스마트폰의 앱 사용 기기 권한 설정처럼 사용하는 기술이나 사용자로부터 게임이 취득하는 데이터 유형의 배열로 지정하며 해당 배열의 길이를 tech level로 간주
  • 배열의 값이 될 수 있는 것은 LocalStorage 혹은 파일 시스템에 대한 I/O, 카메라, 마이크, 음성 및 진동 시스템(틀:효과음이나 틀:TTS 사용한 경우), 사용자 입력
• Description처럼 장문의 텍스트가 그대로 사용되던 메타데이터 값을 이 링크의 내용처럼 단문 문자열의 배열 형태로 통일하여 HTML 목록 태그로 렌더링하도록 유도

이렇게 전환하면 문제가 해결될 수 있을까요? --Senouis(토론장, 기여) 2024년 10월 20일 (일) 16:45 (KST)