KSSRs-2024 Project

このプロジェクトは、星のカービィシリーズのコピー能力別のタイム集計のためのプラットフォームを開発しています。

はじめに

ざっくり言えば、ゲーム中で提示された特定の目的をできるだけ早く達成するというゲームの遊び方の一種

事前に特定のルール（達成条件と禁止事項をまとめたもの：レギュレーションとも）を定めておいた上で、多数のプレイヤーがそれに従って競合し合う。

そのためのコミュニティが形成されており、早く進めるための手法が開拓・共有されつつある。

そのプレイは、しばしば通常プレイのそれとは大きくかけ離れたものになりやすい。

ある時はプレイヤーの技巧が光る洗練されたプレイだったり、

あるいは、研究や偶然により発見されたバグやグリッヂをフル活用したプレイだったり。

意外性とともに「憧れに対する魅了」を与えるような、エンタテインメント性がある。

そのようなコミュニケーションが行われている場の一つに、記録集計プラットフォーム（例 speedrun.comなど）が挙げられる。

ここでは、ユーザが出した記録を集計し、誰もが順位表を見れるようにするという

このようなサービスはコミュニティにおける競合意識・発展を促す点で重要。

任天堂・HAL研究所の開発するゲームシリーズ「星のカービィ」においても、その動きは活発

メインのゲームをできるだけ素早くクリアするという"Any%"というレギュレーションも活発だが

「そのゲーム中に出てくるボスと連戦するゲームモード」（以下、格闘王への道）において、できるだけそのモードを早く踏破しようとする動きもまた活発である。

星のカービィシリーズには様々なコピー能力（プレイヤーの状態）が存在し、それぞれのコピー能力に様々な戦い方がある。

その特性をもとに、コピー能力を固定した上でできるだけ早くクリアするというレギュレーションも活発だ。

そのようなTAコミュニティがすでに発展している

動画投稿による記録・手法シェアも活発。

しかし、そのような環境には自動で集計管理を行うようなプラットフォームが存在しなかった。

（手動では行われている）

本プロダクトでそのような問題を解決したい。

関連事例

Speedrun.comは、スピードランニングの活動を中心にゲームコミュニティを組織するための主要なプラットフォームです。数千ものゲームのコミュニティをホストし、それぞれ独自のリーダーボード、ルール、モデレーター、参加者があります。

ゲームのspeedrunに関する記録の集計・コミュニティ運営を担っている大規模サイトの一つ

しかし、コピー能力ごとに記録が行われているわけではない。

記録管理が煩雑になるため、モデレータから却下されていると想定される？

あるいはコピー能力ごとにおける最適性の探究はspeedrun.comの関心に合致しないとも言える？

コピー能力の選択自体も戦略の一つとなっている

このスタイルでもいいっちゃいいけど

一方で星のカービィのシステムの魅力を活かしきれているとも言い難い。

記録最適化の過程で、使われるコピー能力は強く限られてしまう。

また、近年のカービィシリーズのコピー能力は多い。

そのコピー能力ごとにルールの種類が数多く分岐するため、記録の集計が大変になる。

speedrun.comでは、ルール別順位表がルールごとに変えることはできるが....。

その切り替えのためのUIはどうしても煩雑になってしまうだろう。

現状、記録の管理は全てExcel・特定のWebページにて管理されている。

これには柔軟性がある一方で、次の問題点がある

ヒューマンエラー

見たい記録をすぐに閲覧できない可能性がある

トレーサビリティがない

これらの問題を部分的に自動化することで解決を行いたい。

STASpeedrun

始めに、このプロジェクトはSTASpeedrunから始まった（筆者が高校生の時）

しかし、多くの問題があったため、それをKSSRsというアプリケーションに作り直した。

旧KSSRsとその課題

概要

そこで、星のカービィシリーズの記録を管理するために打ち立てられたツールがKSSRsである。

https://gyazo.com/d55bafe31505bf79c0521b69ab0e0dad

以下の機能を有していた。

記録の投稿・編集機能

記録の条件付き検索

その作品モードに対する簡単な統計の閲覧（記録投稿数・走者数・最終投稿日時）

アカウントログインとロール管理

ログインすると、記録の投稿ができる

管理者権限を持つ人だと、記録の削除などができる。

レギュレーションの管理

しかし、記録数はあまり伸びることはなかった。

要因の一つとして記録投稿の手間が挙げられる。

利用者からのインタビューにより、次のような問題点が明らかとなった。

(1) ゲームモードに基づいた、モーダルなインタフェースを実現してしまっていた

---> 混乱の元

ゲームモードによるページの分割により、さまざまなゲームの記録を管理するKSSRsで、異なるゲームの記録が混雑しないことを狙った。

しかし、記録に辿り着くまでの手数が多く、複雑でない(手軽でない)。

統一検索ボックスの導入により、記録に直ぐにたどり着けるようにユーザー体験を改良する。

(2) 記録申請の煩雑さ

手動の方法において投稿者のすべきことは、究極的に言えば(i) 投稿する部門を選び (ii)Twitterリンクを投げることだけである

投稿者にそれ以上の複雑な要件を増やしてはならない。

記録申請をするために、申請者が記録, タイム, レギュレーション種別などを全て入力する必要があった。

しかし、一般には二重確認の必要性が薄い。(記録のメディアを見れば明らかなため)

一度に大量の記録を投稿することができない。

よって、記録, タイム, レギュレーション種別の入力を管理者側で入力する仕様に変更する。

RTAなどでは、小数点以下のタイムは有効桁でない場合もある。

投稿にログインが必要な点も煩雑さを増している要因

ログインを必要とせずに本人を確認できる手段を設けたい

Discordをうまく使い、管理者に信頼をおくことでもっとシンプルなシステムにしたい

以下は内観法による改善点

内部IDとアイテムの対応を理解していないとAPIを動かすことはできない、

この点を、内部IDを理解せずとも、英語の略称を使えるように改善する。

また、HTTPリクエストメソッドの基準に沿った、純粋なREST APIとなることを目指す。

c.f. speedrun.comのAPIは、推奨こそはされていないが英語の略称を用いた検索が可能

te that you will be redirected, because the API wants you to not use the ephemeral username (S.), but rather their fixed IDs. It is recommended to use IDs whenever possible.

(6) 記録の網羅性がない

記録をざっくりと眺めたいときに、全体像を一度に見渡せる機能がない

STASpeedrunでは、表形式により一人プレイの様子を全て網羅できていた

検索でしか閲覧できないのは問題

開発上の問題点

(1) 保守の難しさ

多くのユースケースに対応しすぎた

稀と思われるケースにも対応できるよう、できる限りの機能を作り込んでしまった

そのせいで、操作が必要以上に煩雑になってしまった。

個人開発に対して、保守・管理も難しくなる

できるだけ機能をミニマムに保たなくてはならない。

Firebaseのアップデートに追従できない

この文章を執筆している現地点で、すでにKSSRsのコードは最新版のコードスタイルから大きく外れている。

いつかdeprecatedになる可能性も否定できない。

(2) 開発の難しさ

NoSQLの検索制約の束縛

開発にはFirestoreが用いられていた

多くの条件付けによる記録の検索が想定されるので、NoSQLの検索制約がかなり厳しく響いた。

また、開発者の自分にNoSQLの知識が十分にないという点もある

SQLを用いた開発に切り替えたい

一般的な設計を重視しすぎた

名前被りの可能性が小さいにも関わらず、できるだけ名前被りを自動的に解消するシステムを実装してしまった

こう言った場合はad-hocに解決して済む場合がほとんど

将来、他の人に管理を受け渡す際に、システムに対する理解が進まない点も問題

(3) 開発中にフィードバックを受けていなかった

このプロダクトは、一通り作り切ってからアプリをリリースした

その内容が本来望まれていたものとは大きく異なる中身になっていた可能性がある。

とは言えど、事前にアイデアだけがある状態でインタビューを開いて了承をもらったとして、その後開発だけを進めるのも問題がある

実際に触ってみないと具体的なアイデアや不満は出てこない。

できるだけ少なく迷いのない操作・ページ遷移で記録を網羅・閲覧できる仕組みづくりを目指す。

従来KSSRs：モーダルなインタフェース

1. トップページ

2. ログイン

3. トップページ

4. ゲームタイトル選択

5. ゲームモード選択

6. トップページ

7. 記録検索

8. 操作完了

操作が多すぎる！

記録投稿者からみて、(i) 投稿する部門を選び (ii)Twitterリンクを投げるの二つの操作以上を要求しないようにする。

現在の開発方針

現状開発者本人（自分）が狙った仕様が本当にタイムアタックの環境において適切かどうか不明。

重視すること

最低限のデザイン

ライブラリを使って即座に実現できる内容に限る。

実現しないと大きくコンセプトを損なうものは実装する。

重視しないこと

ハイコンテキストであることの解消

シリーズ全体を網羅して管理できるようにすること

英語言語での表示・検索の実装

デザイン・アニメーションの

統一性

なめらかさ

微細なユーザビリティ

リンク集