浮子屋/キーワード式井戸端会議

キーワード式井戸端会議

本件、SSP2.0.11で実装されました!ぱちぱちぱち!
http://ghost-dev.g.hatena.ne.jp/ponapalt/20080405/1207386033

Category:仕様メモ

台本コミュがらみで、ゴースト間の連携についてちょっと考えて いたのですが、以下のようなアイデアが実現するとちょっと楽しい かなー、とか。

  • コンセプト
    • たとえば3体ゴーストを立たせたら、その3体が相互に話をしている  のをみてみたい
    • ゴースト作成者の負荷をそれほど増やすことなく、沢山の相互作用を見たい
  • アイデア
    • RegisterKeyWord タグ、及び OnKeyWordイベントをベースウェアに実装
    • ゴーストはRegisterKeyWordタグで、ベースウェアに単語(正規表現?)を  登録する
    • ベースウェアは、起動中の全ゴーストが喋ったトークを監視し、  上記で登録された単語が含まれていた場合、登録したゴーストに対し   OnKeyWord イベントで単語が現れたトーク、どの単語が現れたか、  及び喋ったゴースト名を通知する。
    • OnKeyWordを通知されたゴーストは、それに合わせて適当な反応を喋る。

要は、単純なBOTが複数立っている状態だと思ってください。
RegisterKeyWord,及びOnKeyWordが実装されたゴーストが複数立っていれば、 そこに相互作用が生まれます。(片方が未実装だと、一方通行の反応です)
無限ループに陥らないように、同じ台詞はn回まで、等の制限は必要かも しれません。

…ゴースト周りの技術仕様を完全に理解せずに書いてます。
実はもう可能だったりして。


仕様案。適当にここをいじってください。

\![execute,registerkeyword,(or|and),キーワード,キーワード...]
GET SHIORI/3.0
ID: OnKeyWord
Sender: ゴーストSakura名
Reference0: きーわーど
Reference1: \0\s[5]きーわーど。\w8\w8\uわーどやね。\e

メリット

  • いわゆる「キャラ破壊」が起きない―台詞を考えるのは全部ゴースト作成者です―
  • ゴースト作成者が予想もしなかったようなコラボレーションが生まれうる

デメリット

  • ベースウェア側でかなり重い実装が必要になると思われる
  • 結局は本仕様に対応したゴーストがある程度出てこないと意味がない

Public/Private

  • 現在の想定だと、全てのゴーストの全ての台詞をPublicなものとして扱います。 つまり、「ユーザさんと1対1で話してるのに割り込むんじゃない!」という Privateな扱いができない。
  • 逆に、明示的な指定が無いと、全ての会話をPrivateとして扱う、とした場合、 対応ゴーストが沢山でてこないと会話が発生しない、というデメリットが生まれます。

その他

  • 正規表現と書きましたが、処理の重さを考えると、精々、複数単語のAND/OR 程度 の条件がいいところかもしれません。
  • Referenceにゴースト名等を含めるとして、複数単語で絞りこんで、イベントを 受けた側のSHIORIで条件判定をすれば、「ある特定のゴーストの特定の会話に反応」 することもできるかと思います。
  • 逆に、「よくある単語」でゴーストに関わらず反応すれば、予想もしなかったような コラボレーションが生まれるかもしれません。(本来はそれを想定しています)
  • 発展形として、他のゴーストの撫で反応に反応できたりすると面白いかもです。 さくら&うにゅうが、
    「\uさくらには撫でる胸あらへんもんな。\hうるさいよっ!」
    とか。

  • ベースウェアが面倒を見る(キーワード方式)の場合であれば、ベースウェアが「このゴーストにはさっきこのキーワード送ったばっかだからしばらくいいな」とか判定することは「可能」なのですが。・・・いや、「可能」ってだけで実装考えてませんが。 -- 浮子屋 2004-12-11 (土) 05:36:57
  • Communicateは、Ageヘッダというのがあります(ありました)。これで受信ごとに足し算してping-pongの回数を数えるわけです。 -- ぽな@ばぐとら 2004-12-09 (木) 23:30:24
  • 単純に反応率で――例えば「ゴーストがさくらで、会話に”胸”が含まれていたら」のような条件の場合、ゴースト側の反応率を25%にする、とかすればかなり抑えられそうでもありますが。 -- 浮子屋 2004-12-09 (木) 21:05:37
  • そんな気もします。無限ループ防止は…ゴースト側で対処、ですかねー。今コミュニケーションとかどうやって無限ループ防止してるんだろう。 -- 浮子屋 2004-12-09 (木) 21:04:01
  • いっそ開き直って、特定の設定を最初にやるだけで全ての喋りを丸投げ、でもよさそうですが。 -- ぽな@ばぐとら 2004-12-04 (土) 16:06:22
  • キーワードとして例えば * を設定すると、全ての会話が飛んでいくようにすると、例えば他のゴーストの会話を学習するAIを積んだゴーストとか出来れば、面白そうですね。 -- 浮子屋 2004-12-03 (金) 00:38:41
  • あ、idはゴースト毎にユニークってつもりでした。まあunregisterの需要ってあんまりないですかね。 -- 浮子屋 2004-03-29 (月) 21:08:35
  • idにあたるものは内部的にSSP内でゴーストごとに持って振り分けしようかなと思ったわけですが。idがカブる危険性がありますし。 -- ぽな@ばぐとら 2004-03-29 (月) 10:05:37
  • execute,registerkeyword,id,キーワード[(and|or)キーワード]とか。idは自分で割り振る方向で。そうすればunregisterできますので。 -- 浮子屋 2004-03-28 (日) 02:44:44
  • たとえPrivateな喋りでも、壁の向こうから聞こえてきたのにツッコミ入れるとかそんなイメージで、そうたいして問題にはならないんじゃないですかね。 -- ぽな@ばぐとら 2004-03-28 (日) 02:42:28
  • 横で話を聞いていきなりイヤミなツッコミをぶつぶつしゃべるオバチャン嫌ゴとか(待て -- ぽな@ばぐとら 2004-03-28 (日) 02:39:20
  • 実装仕様にもよります。正規表現はヤバそうですが、単純な単語検索ならたいしたことはないと思います。 -- ぽな@ばぐとら 2004-03-28 (日) 02:39:04

リロード   新規 編集 凍結 差分 ファイルUp コピー 名前変更   ホーム 一覧 検索 最終更新 バックアップ   ヘルプ
feed rss feed rdf feed rss20 feed lirs emily4 inside marble note
Last-modified: Sun, 06 Apr 2008 05:16:52 JST (3276d)