사용자:이의섭/위키 키우기

앞서 개정안을 내 주신 Malgok1님께 감사를 표합니다. 이 문서는 그 개정안을 조금 덧붙이거나, 아니면 다른 아이디어를 낸 것, 그리고 제 경험을 조금 덧붙여 쓴 문서입니다.

첫 번째 문장

첫 번째 문장은 게임이 시작되는 시점에 대한 내용입니다. 특별한 의견이 없습니다.

두 번째 문장

두 번째 문장은 게임의 목표 지점입니다. 특별한 의견이 없습니다.

세 번째 문장

세 번째 문장은 위키의 컨셉과 관련된 내용입니다. 위키가 엔하위키 스타일일 것이냐, 백과사전 스타일일 것이냐, 유머 위키 스타일일 것인지 결정하고 시작합니다.

위키 운영 중, 위키의 컨셉이 흔들리는 경우가 많습니다. 위키의 컨셉과 차이가 나는 글을 작성하는 경우입니다. 물론 위키백과에 백괴스러운 글을 올린다면 바로 삭제되겠지만, 위키백과에 아주 조금의 유머를 넣는 편집이 계속된다면 결국 위키백과는 조금 웃겨질 것입니다. 점진적인 변화가 일어나, 위키 초기의 지향점과 지금 위키의 상황이 큰 차이가 있을 수 있습니다.

이 딜레마를 표현하는 방법은, 시작할 때 엔하위키/백과사전/유머 위키 등 선택지를 주고, 기본적인 스탯을 제공한 뒤 스탯이 변화하는 방식으로 구현할 수 있어 보입니다. 관리자는 이러한 변화를 수용하거나, 아니면 이러한 변화를 적극적으로 저항하는 선택을 할 수 있게 하는 것도 좋은 아이디어처럼 보입니다. 아니면 아예 변화를 추구할 수도 있습니다. 일단 세 가지 컨셉 관련 아이디어가 떠오릅니다.

• 문서 평균 진지도: 문서가 진지한 정도를 나타냅니다.
  • 예를 들자면 위키백과는 이 수치가 높습니다.
  • 진지도가 높으면 사용자들이 문서 생성에 어려움을 겪고, 편집자 수가 적으나, 방문자 수가 매우 커집니다.
• 문서 평균 흥미도: 문서가 재미있는 정도를 나타냅니다.
  • 예를 들자면 백괴사전은 이 수치가 높으나 위키백과는 이 수치가 낮습니다.
  • 문서 평균 흥미도가 높으면 방문자 수가 매우 커집니다.
• 문서 평균 매니악도: 문서가 매니악한 정도를 나타냅니다.
  • 예를 들자면 백괴사전은 공대 개그의 수위가 높으므로 문서 평균 매니악도가 높습니다. 옛 나무위키 또한 문서 평균 매니악도가 높다고 볼 수 있습니다.
  • 매니악도가 높으면 사용자들이 새 문서를 많이 생성하지만, 편집자와 방문자 유입이 어렵습니다.

세 수치 대체로 높게 유지하기 힘듭니다. 사용자 수/문서 수 비율에 따라 천천히 떨어지는 것도 괜찮아 보입니다.

네 번째 문장

네 번째 문장은 위키가 어떻게 시작되는지와 관련된 내용입니다.

위키를 제로베이스에서 시작하는 경우에는 해당 사항이 없으나, 위키를 포크한 경우에는 전쟁이 발생합니다. 이를테면 리그베다위키는 나무위키와의 주도권 싸움에 패배했기 때문에, 거의 아무도 쓰지 않는 상황이죠. 포크를 한다면 기존 위키와 플레이어의 위키 간의 주도권 싸움이 발생하며, 이것과 관련된 이벤트를 추가했으면 좋겠습니다.

다섯, 여섯, 일곱 번째 문장

이는 안정도, 편집자, 문서 수, 문서 평균 완성도, 자금으로 나타낼 수 있겠습니다.

안정도는 위키가 얼마나 잘 운영되고 있는지 나타냅니다. 안정도가 높으면 문서가 많이 생성되고, 문서 평균 완성도 등에서 여러 이점이 있겠지만, 안정도가 낮으면 안 좋은 일이 발생할 것입니다. 안정도가 극단적으로 낮으면 게임 오버가 되거나, 포크 위키가 생성되는 문제가 생길 수 있겠습니다.

편집자는 말 그대로 위키를 편집하는 사람들을 나타냅니다. 이들은 여러 부문과 사이트 홍보 등 이벤트에서 영향을 받습니다. 이벤트를 통해 이들이 유입될 수 있습니다.

문서 수는 말 그대로 문서 수를 나타냅니다.

문서 평균 완성도는 문서가 얼마나 잘 짜여 있는지 나타냅니다. 반달이 발생하면 문서 평균 완성도가 깎이며, 이는 진지도, 흥미도, 매니악도 모든 방면에서 문제를 일으킵니다.

방문자 수는 위키를 방문하는 사람들을 나타냅니다. 이는 위키의 종류, 문서 수, 완성도 등 여러 부문에서 영향을 받고, 특정 비율로 돈을 벌 수 있습니다.

새로운 의견

위키 호스팅 위치 또한 영향을 줄 수 있어 보입니다. 만약 Miraheze같은 호스팅 사이트를 쓴다면, 유지비는 0이 되지만, 어떤 이벤트가 일어나지 않는 등의 방식으로 구현을 할 수 있어 보입니다.