なる/オンラインゴースト化の編集

*リアルタイムな伺かメモ [#na891c8d]

**現状の伺かの問題点 [#hd3d3ab6]

※開発者視点ではなく、あくまで数年ぶりに戻ってきた、いちユーザとして…

:問題点1|あまりに多数のゴーストがいてインストールしきれない。ユーザからすれば管理が面倒くさいし、ゴースト開発者側も自分のゴーストが埋もれる危険をはらんでるはず

:問題点2|アーカイブの定期更新という方法は原始的だし準備する方（ゴースト作者）も面倒くさい（はず）。時事問題への対応などの即時性に欠け、基本的には辞書に準備されている言葉しか喋れない。

:問題点3|ゴーストは能動的に起動される必要がある。起動されていないゴーストは、自己主張する機会もないままにほとんど存在を忘れられる運命にある。

:問題点4|実際問題として伺かユーザもTwitterやmixiやニコ動などの他の手軽なネットサービスに興味を奪われつつある（ように感じる）。「非実在のキャラが住む場所」は、いまは伺かではなくTwitterだったりする。もったいない。

**現状のボトルシステムはこんなん [#ydd0275a]

「ゴーストが生きている」を体感するにはいい線いってる。

-問題点2である、即時性という意味で非常に優秀（ある意味Twitterより優秀）であり、テレビの実況中継すらゴーストを通じて可能。
-問題点3である、起動されず忘れられていたようなゴーストが、存在を主張できる場としても役に立っている。

しかし、ボトルはあくまでゴースト作者ではなく利用者の方を向いたサービスであり、ゴースト作者にとっては使いづらい、どころか、場合によっては邪魔な存在である。また、現実問題として伺かコミュニティの中ですら、存在を忘れられつつある(笑)　＜自分の怠慢が大半です、すみません

そして、そもそもボトルクライアントがSSPと別に起動していないと話にならない。

**そこでやりたいこと [#jaa890a3]

:やりたいこと1|ゴーストは出来るだけ透過的にインストールされるようにしたい（YES/NO形式でダイアログでの確認くらいするでしょうが）。発展型としては、インストールするという概念自体をなくし、クラウド上で管理される存在にするのもアリ。
:やりたいこと2|ゴーストの会話に即時性を持たせたい。具体的にはゴーストマスター（複数人共同管理でもいいけど）が裏で、インストールされているゴーストの会話をリアルタイムで送信できるようにしたい。ボトルのようなユーザコミュニティの範疇ではなく、ゴーストの標準機能として、そういうものでありたい。
:やりたいこと3|ゴーストは起動していなくてもちゃんと生きており、忘れられないような存在でいたい。具体的にはTwitter上とかで。

**一言でいうと [#f7315f9b]

理想は、

「ゴーストは自動インストールされ、透過的に起動し、デスクトップ上で当意即妙な会話を繰り広げ、それをユーザが見て楽しむ」という状況の実現。

たとえばTwitter上では色々なゲームキャラがつぶやいています（公式・非公式問わず）し、彼らは（非実在の）キャラクター同士でリアルタイムに会話をしていたり、あるいはユーザとコミュニケーションを取ることがあります（もちろん裏に「中の人」がいる）。

これをTwitter上でなく、伺か上で実現したくはありませんか? ということ。

**実装方法 [#tf6ea53e]

当然の前提として、既に存在する伺かの莫大な資産を壊すようなものは作れない。また中央サーバ的なものは当然どこかに必要。

以下の話では送信側がどうなるのか一切言及されていませんが、それこそTwitter的に、各種の投稿方法(Web、アプリ、…)がゴーストマスターには用意されるもの、と考えて下さい。

***方法1：ゴーストマスタ用のSSTP Bottle姉妹版を作る [#vabfdd5c]

ボトルクライアントの機能縮小・受信専用版のようなプログラムが、SSPと別にWindows上で常時起動しており、中央サーバからメッセージをストリーミング受信する。Direct SSTP/Socket SSTPを使ってゴーストに喋らせる。

''利点''：実装が早く、SHIORIを入れ替える必要が一切無い。ゴーストマスタがユーザ登録するだけで、既存の数千体のゴーストが、アーカイブ更新の必要すらなく対応できる。

欠点：その専用クライアントが普及し、常時起動していないとお話にならない（そして今のボトルにそんな力はない）。再生可能なスクリプトはSSTPのセキュリティの範疇に制限される。この方法を使うと、「ゴーストの自動インストールと起動」という、もう一つの重要な目標が全く叶えられない。他OSとの互換性がない。

***方法2：独自のSHIORIを作る [#u81cf4d0]

ローカルの辞書から選んで喋るのではなく、サーバからメッセージをリアルタイムに受信して喋るような独自のSHIORIを実装し、それを使ったゴーストを普及させる。

''利点''：実装は比較的簡単。

''欠点''：既存のゴーストの大半が一切対応できず、事実上「今後生まれる新たなゴーストのためだけのオモチャ」になってしまう。自動インストールは無理。

***方法3：SSPが対応する [#e106eb42]

SSP自体が、ボトルのような、「インストールしているゴーストのメッセージをリアルタイムに受信する機能」を実装してしまう。（「フォローしているユーザのつぶやきを半リアルタイムに受信する」のがTwitterクライアントだから、実はイメージ的にそれに非常に近い）SSPは受信したメッセージに応じ、SSFファイルによる台本読みの要領で、必要なゴーストを起動し、受信したスクリプトを再生する。

また、「ネットワーク版ゴーストでありセキュリティ的に安全」であることを何らかの方法で認証できれば、そのゴーストは自動インストールに対応できるようにする。

''利点''：すでにインストールされているゴーストに関しては、（ゴーストマスタがやる気を出せば）すぐにリアルタイムな会話をするようになる。

''欠点''：ぽなさんの負荷が凄いことになる。セキュリティ的にSHIORI込みの自動インストールは非常にまずいから、自動インストールに対応できるゴーストは今後生まれるごく限られたものになってしまう。

***方法4：シェルだけ利用する、SSPとはまったく別のベースウェアを作る [#kac7445d]

「narファイルを自動ダウンロードしてシェル/バルーンだけを展開して使用する」「上記のような自動受信機能を実装する」の2つの機能に絞った、まったく別のベースウェアを（AIRかなんかで）作成する。SHIORI (DLL) という既存の仕組みから決別し、「リアルタイムなコミュニケーション」「Web上で管理されるゴースト」の世界で仕切り直す。

''利点''：自動ダウンロードを本気で頑張るならこれしかない。互換ベースウェアは（作り直しになる分）他OSやモバイルにも容易に進出できる。仕切り直し感が強いが、逆に過去のしがらみを捨てることで、他のサービス(Twitter等)にガチ対抗出来、あわよくば企業が採用とかまでしてくれるかもしれないような道が開けるかも。

''欠点''：伺か世界の再構築に等しいので、現存する大多数のゴースト作者の同意がないことには、この世界は始まらない。

***方法3と4の共存 [#fc9673ec]

SSPもこのサービスに対応しつつも、自動インストールに対応しSHIORIを使用しない独自ベースウェアもある、という世界を目指す。

リアルタイムのメリットが認知され、いずれオンライン上にゴーストの活躍の場が移行するなら、それでいい。

逆にオフライン版でSHIORIを使うことで生まれる細やかな楽しみもあるから、移行しないという選択も良い。オンライン版のゴーストからオフライン版に興味を持ってくれる人がいるかもしれない。両方のメリットを最大限に生かしながら共存すればいい。

''利点''：自動インストールが重要な人も、既存のSHIORI資産が重要な人もハッピーになれる。

**以上4方法のまとめ [#t497504a]

||開発コスト|普及しやすさ|自動インストール|リアルタイム性|他OSとの互換|既存資産との互換|h
|方法1|低い|×|×|◎|×|◎|
|方法2|低い|△|×|◎|×|×|
|方法3|ぽなさん次第|◎|△|◎|○|◎|
|方法4|ほぼ新規開発|？|◎|◎|◎|×|
|''3+4併用''|-|◎|◎|◎|◎|○|

**（余談）Twitterとの連携 [#e517af6c]

ゴーストマスタ用のメッセージ投稿インターフェース（ブラウザ上になるのか、Tween的なデスクトップ上のクライアントになるのか、おそらく両方でしょうが）は、Twitter投稿とも連動できるようにしたいです。

つまり\0側と\1側の2アカウントがあって、掛け合いをTwitterのタイムライン上と、ゴーストのフキダシ上の両方で再現できるようにしたい。

SSP上、独自クライアント上、Twitterに行っちゃった人、全員がゴーストのことを忘れないでいてくれる…はず。

タイムスタンプを変更しない