ユースケースと用語定義


このページではHIMAGINEシステムの、やや技術寄りの詳しい概要と用語説明を同時に行います。

アカウント・ユーザ


「アカウント」とは、ID・パスワードの組み合わせでログイン可能な、ユーザの識別子のことです。
「ユーザ」とはそのアカウントを利用する個人(botかもしれませんが)のことです。説明の都合上、「ユーザ」の行う行為は(難易度が低い順に)「リスナー」「キャスト」「シェルマスター」の、3通りの役割で区別します。

  • これらはいずれも共通のアカウント1個で操作します。ユーザがHIMAGINE関連で複数のパスワードを管理する必要がないようにしましょう。
  • 大部分のユーザは「リスナー」のみの利用形態だったとしても、十分楽しめることを想定しています。(ちょっとだけTwitterラジオをリッチに楽しみたい、とか)
  • ユーザに紐付いたごく最小限のプロフィール(自己紹介)情報を持てます。
  • しかし、原則として通常ユーザ(リスナー)はキャラクターを経由して他者を認識することに注意してください。mixiやpixivやTwitterとは異なり、自分以外のユーザアカウントを直接認識することは滅多にありません(例外は、後述するコラボ関連の設定の場合)。ユーザアカウントに直接紐付くようなコミュニケーション機能(mixi的なメッセージ機能など)はありません。
    • 1つのログインIDで複数の操作キャラを作成できるオンラインゲーム(ROなり何なり)を連想してください。
  • ユーザが管理しているキャラクター(公開分のみ)およびシェル(オープン分のみ)のリストアップは一応可能です。

シェル


「シェル」とは、サーフィス画像の組み合わせのことであり、紐付いている人格/キャラクター情報は含まない概念です。

  • シェルマスターは、ログインして新しいシェルをアップロードすることができます。シェルには1人のシェルマスターが紐付きます。
  • シェルには、それをアップロードしたシェルマスターによって、利用可能範囲を3通りに制限できます。
    • オープンシェル。すべてのユーザが、このシェルを利用したキャラクターを作成し、キャストとなることができます。
    • パスワード付きシェル。特定のパスワードを入力したユーザのみが、このシェルを使ったキャラクターを作成し、キャストとなることができます。そのパスワードは秘匿して友人のみに教えるのでもいいですし、シェルマスターの個人サイトで公開するとかでもいいでしょう。
    • クローズドシェル。アップロードしたシェルマスター本人のみが、クローズドシェルを使ったキャラクターを作成し、キャストとなることができます。
  • 上記の利用範囲のいずれの場合でも、シェルは複数のキャラクターと関連づけることができます。(クローズドの場合でも、シェルマスター自身は、そのシェルを使ったキャラクターを複数作成することが一応できます)
  • シェルマスターはシェルの管理権を他のユーザに委譲することができます。
  • シェルをアップロードする際にシェル名を指定できます。これはキャラクターとは別の、アバターとしての名称です。
  • シェルを利用しているキャラクターの数は公開されません(あるいは、シェルマスターのみに公開されます)。

キャラクター


「キャラクター」とは、シェルを利用して生まれる「1個の人格」であり、HIMAGINEシステムの中心となる概念です。

  • 1個のキャラクターは、1個のみのシェルを利用します。
  • しかし1個のシェルは、複数のキャラクターで共有することが可能です。
  • 同じシェルを用いていても、キャラクターが異なれば、それはシステム上は「外見が似ている別人」として扱われます。
  • キャラクターにはキャラクター名と、1名のみのキャラクターオーナーであるキャストが紐付いています。
  • キャラクターにはシェルとは別のプロフィール文字列を設定可能できます。
  • シェル名とは別にキャラクターに名前が付きます。リスナーは主にこちらのキャラクター名でキャラクタを区別します。もちろんクローズドシェルなキャラクターであれば、これは完全に1対1での対応となります。
  • キャラクターには1人のキャラクターオーナーがいますが、加えてオーナーが認証することで複数のキャストが参加可能です。すなわち1個の人格を複数人が協力して演じることが可能です。
  • 一方、同じシェルを使って、10人のキャラクターを無関係の10人が作る、という形態もありえます。これらのキャラクターは、顔が似てるだけの、別名の赤の他人です。
  • キャラクターを購読しているリスナーの数は公開されます。そのキャラクターの人気のバロメーターとなります。
  • キャラクターに対応しているキャストが誰なのか(ユーザアカウント)は非公開です。ただし設定で公開もできます。
    • 非公開を原則とする理由は、キャラクターはキャラクターであり、中の人のアカウントを意識させるのは望ましくないからです。あくまで通常のリスナーに目に見える必要があるのは「キャラクター」のみであるべきです。
  • キャラクターはSSP等の既存ベースウェアと連携するため、SSPなど既存のゴースト用識別名文字列(「さくら,うにゅう」)を指定できます。
    • これを指定できるのはそのゴーストのオリジナル作者のみに限ります(とりあえず自己申告制ですが問題があれば事後認証も可能)
    • これを指定した場合、既存ベースウェアはこれをパラメータとしてHIMAGINEサーバに接続することで、そのゴースト用に流れてきた会話を受信できます。
    • つまり、SSPの既存のゴーストに、突然オンラインでリアルタイムに喋る機能が付加されるということです。もちろんSSPが対応した場合ですが。
  • キャラクターはTwitterと連携するため、キャラクタごとに1個または2個のTwitterアカウント(IDとパスワード)を指定することができます。
    • Twitter連携によって、キャストは発言をHIMAGINEとTwitterの両方にミラーリングすることができます。
    • 2個のTwitterアカウントを指定する場合、2個のTwitterアカウントは\0側と\1側に対応します。HIMAGINEサーバは適度なディレイを置きながら、まるで掛け合いに見えるかのように2キャラ交互の自動ツイートを行い、タイムライン上でHIMAGINEと同じ会話を再現します。(サーフィス変更などはどう頑張っても再現できませんが) つまりHIMAGINEに登録せずTwitterのみを使っているユーザもTwitter上のタイムラインで、同じ会話を楽しむことが可能です。
    • 1個のTwitterアカウントによって、会話があったことをTwitter側のフォロワーに通知もできます。この場合は「掛け合いの再現」というより、もっと普通の意味での通知機能です。ツイート内容にはHIMAGINE側の個別会話ログ表示画面へのURLが含まれます。

  • シェルとキャラクターの関係については、ゲーム"世界樹の迷宮"の「ガンナー」やROの「プリースト」等の無個性(?)テンプレートと、それぞれの絵柄から全国何十万人と作成される個別キャラとの関係をイメージしてください。ああいうの観てると、オープンシェルであっても、勝手にシェルのみからシェル固有に人格設定が育つ可能性も感じたりします。
  • 「キャラクター」ではなく「ゴースト」という名称にしようかと考えましたが、"名前が違う複数のゴーストがいる"という状況は伺かに慣れた人にとって違和感があります。「ゴーストに複数のシェルが対応する」のが伺かの基本仕様ですから、HIMAGINEを「シェルに複数のゴーストが対応する」と説明するのは、真逆になってしまいますし。逆に伺かに慣れていない人にはゴーストという単語自体が唐突です。従って「キャラクター」という無難な名前にしておきます。
    • 無論、クローズドシェルとキャラクターが1対1対応しているとき、それはまさに「オンラインゴースト」として見えることになります。

リスナー


「リスナー」とはユーザの役割の一種です。メッセージを受信して楽しみます。

  • 初期段階では、リスナーについては当面アカウント不要とします。リスナーはサーバから、全キャラクターの全発言をストリーミング受信します。ユーザ数合計が1000人を超えないような状況では、結局ほとんどのユーザはほとんどのキャラクターの会話を閲覧しようとするだろうという想定です(現状のSSTP Bottleでもチャンネル機能してないし)。
    • 対応するシェルは必要に応じてダウンロードされます。この際サーバにダウンロード負荷が一斉に集中するとマズイので何か遅延配布の方法を考えます。
    • クライアント毎のブラックリスト方式で見たくないキャラクタは除外できます。
    • 完全に特定のキャラにしか興味がない人もいるので、ホワイトリスト方式も実装したほうがいいかも。
  • シェルが同一である複数のキャラクターを区別できるようなインターフェースは必要ですね。バルーンに名札を付ける案が有力。

ただし上記のような実装は、ユーザ数の規模が一定以上になると破綻します。サーバの通信量は「キャラクター数×リスナー数」に比例しますから、ユーザ数の2乗のオーダーでサーバの帯域負荷が増えていきます。サーバ上に存在するリスナーが数千人、アクティブなキャラクターが100人を超える辺りからサーバのリソースが厳しく、単純に受信する人間側も大量の発言を処理しきれなくなってきますので、その場合はリスナーもアカウント登録必須とします。以下はその場合の暫定仕様。

  • リスナーは、どのキャラクターをsubscribe (ないしfollow) するかを指定。
    • subscribeに対応する、素敵な用語募集中。キャラがデスクトップに立つのを「フォロー」と呼ぶんじゃ寂しいし、「受信」「購読」 も味気ない感じ。「招待」とか「召喚」とか…?

キャスト


「キャスト」とはユーザの役目の一種です。キャストは、キャラクターの会話を投稿します。「役者」という意味のcastと「投げる」という意味のcastの両方の意味があります。

  • 1人のユーザは、複数のキャラクターのキャストとなることができます。どのキャラクターに喋らせるのかを選択するUIが存在します。
    • もっとも、単純なる掛け合いがやりたいだけなら、複数のキャラクターを使わなくてもsakura/keroの2体を使えるのが伺かシステムの良いところです。
  • メッセージの投稿は、Web上、AIR版クライアント、携帯電話などの複数の方法で可能です。手軽であるほど良いと思います。

シェルマスター


「シェルマスター」とはユーザの役目の一種です。シェルを投稿・更新します。

  • 1人のユーザは、複数のシェルをアップロードすることができます。
  • シェルをアップロードするだけで、対応するキャラクターを作らないことは可能です。単にオープンシェルとしてアップロードしてそのまま放置しても問題ありません。

以上まとめ


;

付記


SSTP Bottleのように「仮想的にそこに存在するゴーストは1人で、それを誰もが自由に喋らせる」といった実装にはしません。しかしクローズドシェルを使ったキャラクターオーナーが複数の人間を追加キャストとして認証するキャラクターを作れば、似たようなことは可能です。

配布するソフトウェアは、リスナー用のシンプルな受信用クライアントがメインです。キャスト用のクライアントは別配布とします。(SSTP Bottle Clientは送受信両用でした)

トラブル対策


  • シェルの更新・削除関連
    • シェルをアップデートする際、単にサーフィスが増えるのは構いませんが、以前使えていたシェル番号と絵柄の対応が大幅に変わるようなことがあると、そのシェルを使っていたユーザにとって問題となります。この辺の防御策について検討が必要です。
      • シェルにバージョン管理を持たせて同一名称の複数世代のシェルが管理できるとよい? これは過去ログを正しく表示できるようにするためにも必要。
    • シェルを削除する場合はもっと大変です。この場合、紐付いているキャラクターがみんな同時に利用不可能になってしまいます。
      • 対応として、1人でも自分以外がオーナーであるキャラクターが付いたシェルは、例えシェルオーナーといえども削除出来ないようにする必要がありそうです。
      • 一方でシェルに著作権侵害などの法的問題が生じた場合は問答無用で削除せざるを得ません。この辺は「シェルマスターにシェル投稿時に警告を十分表示する」「キャストにもキャラクター作成時に注意を促す」ということでなんとかしましょう。「オープンシェルの場合は管理者の審査を要する」とかもでいいかもしれません。

タグ:

+ タグ編集
  • タグ:

このサイトはreCAPTCHAによって保護されており、Googleの プライバシーポリシー利用規約 が適用されます。

最終更新:2010年08月08日 22:23
添付ファイル