http://www26.atwiki.jp/himagine/ HIMAGINE Wiki ja 2011-07-14T21:54:04+09:00 http://www26.atwiki.jp/himagine/pages/1.html #image(http://www26.atwiki.jp/himagine/pub/images/HIMAGINE_LOGO.png) *ここは？ このWikiは、新世代オンラインキャラクターシステムの、「HIMAGINEプロジェクト」に関する情報をまとめて、整理するための場所として設置されています。 プロジェクト稼働までの間に行われる話し合いなどの内容はもちろん、稼働後も様々な情報を集積して行く予定です。 このWikiは、一部のページを除き、「誰でも」編集可能です。原則として、編集に当たってログインや管理者の承認を必要としません。 *HIMAGINEって？ [[HIMAGINEについて]]をご覧ください。 *どんな人が関わってるの？ [[関係者一覧]]をご覧ください。 *今何をしてるの？ [[ToDo]]をご覧ください *関連リンクは？ [[関連リンク]]をご覧ください。 *意見や情報を交換したい [[情報交換掲示板]]をご利用ください。 -リアルタイムの情報交換用にIRCチャンネルを用意しました。&br()サーバ：irc.freenode.net チャンネル：#HIMAGINE *HIMAGINE関連の話題を見つけたんだけど 情報ありがとうございます。お手数ですが、[[仮まとめページ]]に書き込んでください。 そこまでするほどの物ではないかな、と言う場合は、[[一般の話題用トピック>情報交換掲示板#IPPAN]]に書き込んでください。 *プロジェクトに参加してみたい ありがとうございます！プロジェクトへの参加をご希望の方は、[[プロジェクトへの参加について>HIMAGINEについて#JOIN]]をご覧ください。 *練習用ページ Wikiの編集の練習やテストなどは[[練習用]]でどうぞ。 *管理者 このWikiは[[せきやひろし]]が管理しています。何かありましたら、[[一般の話題用トピック>情報交換掲示板#IPPAN]]に書き込んでください。 //**@wikiへようこそ //-ウィキはみんなで気軽にホームページ編集できるツールです。 //-このページは自由に編集することができます。 //-メールで送られてきたパスワードを用いてログインすることで、各種変更（サイト名、トップページ、メンバー管理、サイドページ、デザイン、ページ管理、等）することができます // //**まずはこちらをご覧ください。 //-[[@wikiの基本操作>http://atwiki.jp/guide/category2.html]] //-[[用途別のオススメ機能紹介>http://atwiki.jp/guide/category22.html]] //-[[@wikiの設定/管理>http://atwiki.jp/guide/category6.html]] // //**分からないことは？ //-[[@wiki ご利用ガイド>http://atwiki.jp/guide/]] //-[[よくある質問>http://atwiki.jp/guide/category1.html]] //-[[無料で会員登録できるSNS内の@wiki助け合いコミュニティ>http://sns.atfb.jp/view_community2.php?no=112]] //-[[@wiki更新情報>http://www1.atwiki.jp/guide/pages/264.html]] //-[[@wikiへのお問合せフォーム>http://atwiki.jp/helpdesk]] //等をご活用ください // //**@wiki助け合いコミュニティの掲示板スレッド一覧 //#atfb_bbs_list(112) // //**その他お勧めサービスについて //-[[大容量１Ｇ、PHP/CGI、MySQL、FTPが使える無料ホームページは@PAGES>>http://atpages.jp/]] //-[[無料ブログ作成は@WORDをご利用ください>>http://atword.jp/]] //-[[2ch型の無料掲示板は@chsをご利用ください>>http://atchs.jp/]] //-[[フォーラム型の無料掲示板は@bbをご利用ください>>http://atbb.jp/]] //-[[お絵かき掲示板は@paintをご利用ください>>http://atpaint.jp/]] //-[[その他の無料掲示板は@bbsをご利用ください>>http://atbbs.jp/]] //-[[無料ソーシャルプロフィールサービス @flabo(アットフラボ)>>http://sns.atfb.jp]] // //**おすすめ機能 //-[[気になるニュースをチェック>http://atwiki.jp/guide/17_174_ja.html]] //-[[関連するブログ一覧を表示>http://atwiki.jp/guide/17_161_ja.html]] // //**その他にもいろいろな機能満載！！ //-[[@wikiプラグイン>http://atwiki.jp/guide/category17.html]] //-[[@wiki便利ツール>http://atwiki.jp/guide/category32.html]] //-[[@wiki構文>http://atwiki.jp/guide/category16.html]] //-[[@wikiプラグイン一覧>http://www1.atwiki.jp/guide/pages/264.html]] //-[[まとめサイト作成支援ツール>http://atwiki.jp/matome/]] // //**バグ・不具合を見つけたら？ 要望がある場合は？ //お手数ですが、メールでお問い合わせください。 2011-07-14T21:54:04+09:00 http://www26.atwiki.jp/himagine/pages/16.html - 技術的な内容に関する意見交換はこちらで。 -- (せきやひろし) &size(80%){2010-06-01 21:20:29} -確かに最初の段階で面倒くさいユーザ管理をしてもしょうがない気がしてきました。リスナー数千人＋シェル上限100体程度の想定で、全員同時通報＋ブラックリスト方式で始めるのが妥当という点に賛成です。この規模なら結局全員がほぼ全キャラの会話を欲しがる、というのもその通りと思います。 &br()●通信帯域について &br()　10MBのシェルは殆どありません。何十というアニメーションパターンを備えた現存最重量級のシェル「毒子」ですら10MB超えません。平均は1.5MBくらいのようです。 &br()シェルは静的ファイルなので、いざとなったらハッシュでsignature付けて、無関係なWebサーバ(シェルマスターの個人サイトとか)に丸投げできると思います。もちろんSourceForge的な管理付きミラーサーバの方がより安全でしょうが。またシェルは遅延DLで良いですが会話には即時性とお祭り時の瞬発力が要るので、会話処理の方が帯域処理が楽ということは必ずしも言えないと思います。まあこれは「将来ユーザが増えたら」の話なので、とりあえず今は考えない、というみかげさんの意見に同意です。 &br()あと会話の帯域がN^2で増えるというのも言い過ぎで、規模が大きくなればなるほどライトなROMユーザの割合が増えるでしょうから、実際はN^1.5くらいな気がしました。特にリスナーが1晩で突然増える可能性は十分考えるべきですが、その場合の負荷の増え方は単純にNに比例です。キャラクターが1晩で突然増える可能性は非常に低いでしょう。 &br()●Twitter連携について &br()　やっぱりサーバ側で処理するのは、そのサーバをブロックされると一発アウトなので、大変よくない気がしてきました(^^;) AIR版クライアントでTwitter投稿予約機能を付けるほうが現実的ぽいので、やるとしてもその方向、ということで…。 -- (naruto) &size(80%){2010-08-08 21:46:31} - シェルは思ったより容量少ないようですね．平均1.5MBならもう少し楽観できそうですね．いずれにしろスレーブサーバで分散できる構成には早めにしたいところです． (mikage) - Twitter連携をAIR版クライアントでやる場合，他のクライアントだと投稿できなくなるのがデメリットですね．ただ，クライアントであれば，xAuthが使えるはずなので，IDパスをそのまま入れてもらって連携ができるはず．色々面倒だと思いますし，Twitter側の修正に左右されるのは大変だと思うので，後々で良いとは思います． (mikage) * シェル・キャスト構造について (mikage) - シェル・キャストの2重構造は，柔軟にシェルを扱えるメリットはありますが，利用ユーザからすると複雑で，理解しにくいように思います． - 以下のような形ではどうでしょうか． -- シェルはアップロードしたシェルマスターのみが利用できる． -- オープンシェルとして公開したい場合は，シェルのzipファイル自体を作者が配布すればよい． -- パスワード付きシェルのレベルで公開したい場合，作者のページでこっそり公開するとか，友人のみにzipファイルを配布すればよい． -- クローズドシェルの場合は，zipファイル自体を配布しなければよい． -- シェルは，同じファイルを複数の人がアップロードした場合，別々のIDが振られ，別々のキャラクターとして振る舞う． -- シェルをクライアントがDLする場合は，zipファイルのSHA-1ハッシュ値を元に判断し，同じハッシュ値のシェルをDL済みであったら，そのファイルを利用する． - この形式では，以下のメリットがあります． -- 仕組みが単純で，キャストになるユーザがやることが明確． -- オープンシェル・パスワード付きシェルの利用者はクローズドシェルに比べれば少ないと考えられるので，システム側で対処するより，ユーザ側に任せた方がより柔軟な管理が可能．また，システム側でオープンシェル・パスワード付きシェルを実装したとしても，ユーザがzipファイルを再アップするような使い方をすれば意味が薄れてしまう． -- zipを配布するという形を取れば，シェルを少しだけ変えて使いたい，といった要望にも対応しやすい．（もちろん最初の作者が修正を許可する場合に限りますが） - みかげさん案のままでは、キャラクターを作る人はZIPファイルのアップロードなりシェルの能動的なWeb検索なり、僕が想定していたよりかなりハードルが高い作業をこなす必要があります(ゼロからSSPでゴースト作者になるよりはマシですが)。 &br()僕としては、「自作シェルの利用者より公開シェルの利用者がずっと多い」という認識で、Yahoo!のアバターやネットゲームのキャラを作成するのと同レベルの気軽さを考えていました。「キャラクター作成ボタンを押すと、とりあえずオープンシェルの一覧が出て、数クリックで作成完了」という感じです。各種ブログサービスとも似ています。既存のデザインから選んで数クリックで作成するのが普通であり、難しい自作デザインをやる人は全体の1割もいません。ZIPで配布されているデザインテンプレートをWeb検索で求める人など殆どいません。(そこまで気軽にキャラが増えることがそもそも望ましい方向性かという点で認識の統一は必要そうですが) &br() &br()ただ、みかげさん案は、シェルがアップデートしてもキャラクターは連動しないのでシェルバージョン整合の面倒くささを考えなくて良く、カスタマイズ版のシェルが作れる自由度もあるので、魅力的と思います。シェルとキャラクターを1対多の形でシステム上で縛り付ける構造は確かに悪そうです。 &br() &br()折衷案として以下のような感じはどうでしょう。 &br()・キャラクターはそれぞれ固有にシェルを持つ。SHA-1チェックで重複ダウンロードを避けるなどの負荷軽減はする(これはみかげさん案の通り) &br()・キャラクター作成時、上級者は直接シェルをZIPでアップロードするが、オープンなものについて公式のシェルセンター(仮称)を作り、そこから検索したり一覧したりZIPファイルを経由せずにインポートしたりできる。HIMAGINE版の「伺かゴーストセンター」にあたる物です。 &br()・シェルセンターからインポートする際にシェルマスターによるパスワード指定もできる。 &br()・シェルセンターからはシェルをZIPとしてDLして上級ユーザがカスタマイズする余地を与える(原作者が許可している場合のみ)。 &br()・シェルセンターはニコニコ動画に対するsmilevideo、みたいな感じで多少別サイトとして後から運用を始めても良い。初期のテスト段階ではひとまずシェルセンター自体要らない。 -- (naruto) &size(80%){2010-08-10 09:32:16} - なおこの方法で行く場合、PNGやPNAのファイルは全部SQLiteに放り込み、 &br()ファイル名ではなくSHA-1のIDで識別することになると思います。 &br()設定ファイルの文字が1か所異なるだけの微妙なカスタム版シェルや &br()1枚画像を増やしただけの新版シェルが無数に生まれる恐れがあるのでZIPファイルレベルの &br()粒度では帯域とストレージ容量がかなり無駄になりそう。 &br() &br()みかげさんには、シェルをZIP丸投げで渡すのでなく、ZIP内容のファイル名＋ハッシュ一覧の提供と、シェル名＋ファイル名を指定しての個別ファイルDL機能の提供をお願いしたいです。 -- (naruto) &size(80%){2010-08-10 09:58:54} - &br()では，こんな感じでどうでしょうか． &br()・ユーザはWebでアカウント登録をすると，シェルの登録もしくはオープンシェルの利用を（複数）選べる． &br()・シェルの登録の方を選んだ場合，zipでアップロードする．その際，そのシェルをオープンシェルにするか，クローズドシェルにするか選べる．オープンシェルの場合は，利用条件の記載ができるようにする．（zip改変を許可する場合は，zipの配布サイト等をそこで紹介する） &br()・オープンシェルの利用を選ぶと，アップロード済みのシェル一覧が表示され，その中から選ぶ事ができる．（ゴーストセンターのようなものはHIMAGINEサーバ側の基本機能として実装） &br()・いずれの場合も，選んだ後にキャラクターのプロフィール等を登録する． &br()以下の機能はやめます． &br()・パスワード付きシェル（仲間内の配布はzipで行えばよいし，一覧にパスワード付きシェルがいっぱい出るのはイメージが良くない） &br()・1つのキャラクターの複数人での管理機能（今のところ需要があまりなさそうなので） &br() &br()SHA-1でのチェック単位ですが，ファイル単位とするとシェルのファイル数がかなり増えるのが心配です． &br()アニメーション等で小さなファイルが大量にあると，それはそれでサーバに負荷がかかります． &br()とりあえず数千とかの単位であったらかなり厳しそうです． &br()（1000人がアクセスに来たら，100万アクセスになるので…） &br() &br()シェルというと，結構大量のファイルが存在するイメージがありますが，どうでしょうか．．． &br() &br()確かにカスタマイズしたものは無駄になりますが，カスタマイズする人はそんなにいないのではないかとも思いますので，どっちをとるかですね． &br() -- (mikage) &size(80%){2010-08-10 22:05:08} - だいたいこんな感じの仕様でOKです。 &br()1個のシェルに数十から100個くらいの画像は含まれていますので、 &br()小さな画像を個別にDLする方がむしろサーバーの負荷が高いと &br()みかげさんが判断するようなら、ZIP単位のDLで構いません。 &br()僕の方でローカルストレージ容量軽減のため、既にSHA-1レベルで同じ画像ファイルが &br()あるなら2個同じものをHDDに保存しないような仕組みを考えることにしますね。 &br()よろしくお願いします。 -- (naruto) &size(80%){2010-08-10 22:26:46} - &br()シェル登録などを以下のように考えていたのですが，いくつか問題がありそうなので， &br()オープンシェルは別サイト管理にしようと思いますが，どうでしょうか． &br() &br()■ 想定していた流れ &br() &br()・ユーザはキャラクターを作成する際に「シェルをアップロードして作成」か「オープンシェルから選ぶ」を選ぶ． &br()・シェルをアップロードする場合，そのシェルをオープンシェルにするかどうかを選択できる &br() &br()この流れだと，以下の問題がありそうです． &br() &br()・オープンシェルにした場合，削除したいと思ったときに問題になる．削除不可にすると，シェルを何度も更新すると古いシェルが残る． &br()　削除はしないけど一覧に出さない，という方法である程度回避はできるけれども，わかりにくい． &br()・オープンシェルから選ぶ時には，サムネイルくらいは欲しい．しかしzipからサムネイルは難しそう． &br()　また，理想としてはサーフィスをそれぞれ確認できると良いが，それをするためにはFlashを埋め込む必要があるので， &br()　この辺はなるさんに作ってもらった方が効率がよさそう． &br() &br()■ 別サイト管理の場合の流れ &br() &br()・別サイトは仮に「オープンシェルセンター」とする． &br()・オープンシェルセンターでは，シェルにIDを振っておく． &br()・ユーザはキャラクターを作成する際に「シェルをアップロードして作成」か「オープンシェルセンターのシェルを使用」を選ぶ． &br()・オープンシェルセンターのシェルを使う場合，オープンシェルセンター側のシェルIDを入力してもらう．（例えば 000-102 とか） &br()　そうすると，サーバはオープンシェルセンター側のファイルを裏で持ってきて，シェルとして登録する． &br()・そのシェルが削除されるタイミングはキャラクターを削除した時になるので，わかりやすい． &br()　ただし，オープンシェルセンター側でシェルを削除しても，既に利用中のシェルについては関与はできない． &br()　（互換性を考えるとこの方が望ましいと思う） &br() &br()■ その他 &br() &br()・シェルの削除については，既に利用中のものまで関与できない，という仕様でよいですよね． &br()・シェルの更新については，各キャラクター単位で，キャラクターの作者がシェルを差し替え可能にすれば良さそうです． &br()　その際，過去のスクリプトについては，差し替え後のシェルで再生される，ということでよいでしょうか． &br()　（シェル差し替え時に，互換性についてはキャラクターの作者の方に対応してもらう） &br()　ランダムトークではなく，即時トークがメインということであれば，過去のスクリプトは &br()　その時点でのシェルで再生できた方が良い，という考え方もありそうです． &br()　どちらも一長一短ですが，どうしましょうか． &br() &br() -- (mikage) &size(80%){2010-08-22 11:20:46} - ＞シェルの削除については，既に利用中のものまで関与できない &br()＞シェルの更新については，各キャラクター単位で，キャラクターの作者がシェルを差し替え &br() &br()はい、その通りでいいと思います。 &br()基本的にキャラクターに直に関連づけられているのは、登録時シェルセンターに &br()あったシェルの「コピー」ということで。 &br()なのでオープンシェルセンター側でシェルを削除することについては何ら問題ないですよね? &br()ただしシェルが更新されたときに通知とか、クリックで確認することで &br()自動更新くらいはできるようにしてあげたいです。 &br()単にサーフィスが1個増えるだけの更新に、いちいちZIPファイルを &br()DLさせるようなのは良くないと思います。 &br() &br()＞オープンシェルセンターのシェルを使う場合，オープンシェルセンター側のシェルIDを &br()＞入力してもらう &br()できればクリックで済む形になりませんか? &br() &br()＞過去のスクリプトについては，差し替え後のシェルで再生される， &br()＞ということでよいでしょうか &br()個人的には「当時の(差替え前の)シェルで再生させたい」派です。 &br()クライアント内部では、ファイルをZIP単位とかファイル名とかではなく、 &br()一旦SQliteに突っ込んでSHA-1で管理する方針です。だから差分シェルが沢山あっても &br()PNGファイル単位で共通な部分はストレージ容量を食わずに済みます。 &br()だから昔のシェルの画像セットもずっと持っておいて再生させるのに問題ありません。 &br()そのためにはキャラクターがシェルを更新するごとにそのシェルにリビジョン番号が付き、 &br()発言毎にそのリビジョン番号が対応している必要がありますね。 &br()あと昔のシェルもDL可能である必要がありそう。 -- (naruto) &size(80%){2010-08-22 12:33:21} - ＞前にzipの中身のファイル一覧が必要とかそういう話があったと思いますが &br()＞そちらは結局無しで大丈夫になりそうなんでしたっけ． &br() &br()これは単にDL容量削減の工夫というだけの問題ですから、ひとまずなしでOKかと思います。 &br()ただ伺かのシェルは、極端な場合「毎日ネットワーク更新で1個ずつ画像が増えていく」 &br()みたいなことをされてきた性質のものですから、差分を個別ファイルでDLして更新 &br()できたほうが嬉しいとは思います。 &br()過去ログを過去シェルで再生させる場合にも、当時のシェル内のSHA-1の一覧が手に入ると、 &br()「現在持ってる画像のセットで再生できる」とか「この画像だけ昔のをDLすればいい」 &br()と理解できて、DL容量を数MBから数KBに削減できます。 -- (naruto) &size(80%){2010-08-22 12:45:23} - &br()＞なのでオープンシェルセンター側でシェルを削除することについては何ら問題ないですよね? &br() &br()これは問題なしです． &br() &br()＞ただしシェルが更新されたときに通知とか、クリックで確認することで &br()＞自動更新くらいはできるようにしてあげたいです。 &br() &br()なるほど． &br()シェルが更新されたときは，シェルIDに対して後継シェルIDとメッセージを &br()登録できるようにしておき，ログイン時にそのシェルIDを利用していたら &br()メッセージを確認できるようにするのが良いですかね． &br()で，更新ボタンを押すと，後継シェルIDに差し変わると． &br() &br()そのことを念頭におきつつ，とりあえずはアップロード方式だけで &br()作成を進めますね． &br() &br()アップロードの方での更新の場合は，キャラクターを選んで， &br()そのキャラクターに対してシェルをアップロードすると， &br()新しくシェルが登録されて，キャラクターに対応する現行シェルIDが &br()更新される形にしようと思います． &br() &br()＞＞オープンシェルセンターのシェルを使う場合，オープンシェルセンター側のシェルIDを &br()＞＞入力してもらう &br()＞できればクリックで済む形になりませんか? &br() &br()オープンシェルセンターでシェルを選んだ後，サーバ側URLに特定のパラメータに &br()シェルIDを追加したものにリンクしてもらうと，クリック後にキャラクター登録 &br()画面に推移するような感じにしましょうか． &br() &br()＞個人的には「当時の(差替え前の)シェルで再生させたい」派です。 &br() &br()ではそうしましょうかねぇ． &br()シェルを差し替えた場合は，シェルIDの方を変えようと思ってました． &br()シェルの更新は，新しいシェルIDでファイルを登録した上で， &br()キャラクターのシェルIDを書き換えると行った形です． &br() &br()発言を管理する際に，発言毎にシェルIDを利用すれば当時のシェル再生ですし， &br()発言毎にキャラクターIDを利用して，そのキャラクターIDの現行シェルIDを &br()利用すれば最新のシェルIDになります． &br() &br()＞これは単にDL容量削減の工夫というだけの問題ですから、ひとまずなしでOKかと思います。 &br()＞ただ伺かのシェルは、極端な場合「毎日ネットワーク更新で1個ずつ画像が増えていく」 &br()＞みたいなことをされてきた性質のものですから、差分を個別ファイルでDLして更新 &br()＞できたほうが嬉しいとは思います。 &br() &br()シェルを更新する場合，新しいシェルと古いシェルの差分はわかりますから， &br()更新時は前後のzipの中身を比較して，更新がある部分だけzipで固め直した &br()差分ファイルを用意すると良さそうですね． &br()この方法ならDLファイルは1ファイルのままで容量を削減できますし， &br()毎日少しずつ更新するようなケースにはちょうど良さそうです． &br() -- (mikage) &size(80%){2010-08-22 12:56:49} - ＞シェルの更新は，新しいシェルIDでファイルを登録した上で， &br()＞キャラクターのシェルIDを書き換えると行った形です． &br()その形で大丈夫そうですね。 &br()発言毎に「キャラクターID」と「発言当時のシェルID」の両方があればOKです。 &br() &br()＞更新時は前後のzipの中身を比較して，更新がある部分だけzipで固め直した &br()＞差分ファイルを用意すると良さそうですね． &br()必ずしもインクリメンタルに更新されず数世代まとめて更新される可能性もありますし、 &br()過去ログ関連では大昔使われていたシェルIDをピンポイントで指定されることもありえますし、 &br()存在していたサーフィス画像が消える可能性もあるので、 &br()「シェルIDを指定されると、含まれるファイル名とSHA-1の一覧を渡す」 &br()「足りないものをクライアント側が判断して個別に要求する」 &br()という2段階を踏むのが楽のような気がします。世代の差分で管理すると大変そう。 -- (naruto) &size(80%){2010-08-22 13:06:54} - というか差分方式(update.dau)でやろうとした伺かのネットワーク更新は &br()人間には非常に扱いづらくて大変そうです。 -- (naruto) &size(80%){2010-08-22 13:08:26} - &br()＞必ずしもインクリメンタルに更新されず数世代まとめて更新される可能性もありますし、 &br()＞過去ログ関連では大昔使われていたシェルIDをピンポイントで指定されることもありえますし、 &br()＞存在していたサーフィス画像が消える可能性もあるので、 &br()＞「シェルIDを指定されると、含まれるファイル名とSHA-1の一覧を渡す」 &br()＞「足りないものをクライアント側が判断して個別に要求する」 &br()＞という2段階を踏むのが楽のような気がします。世代の差分で管理すると大変そう。 &br() &br()ファイルをばらばらに要求するとアクセス数が増えてしまう問題があるので…． &br()ディレクトリ構造を直しました，みたいな場合，数百アクセスが連続で &br()来る可能性もあると思うので，それは避けたいです． &br() &br()数世代まとめて更新した場合，それぞれの差分ファイルを全部DLするのは駄目ですか？ &br()複数回の更新で，画像が追加された後，それが消されたり，2回同じファイルが &br()更新された場合，多少無駄な転送は発生すると思いますが，サイズとしては &br()そんなに大きくないと思います． &br() &br()クライアント側としては，以下のような流れでシェルをDLするイメージです． &br() &br()１．DL済みではないシェルIDの発言が来たら，サーバにシェルIDの情報を要求する． &br() &br()２．サーバ側は，そのシェルIDの情報を以下のような形で返す． &br()　　　最新のzipファイルのURL　ファイルサイズ &br()　　　1世代前のシェルID　1世代前のシェルのzipファイルのURL　差分zipファイルサイズ &br()　　　2世代前のシェルID　2世代前のシェルのzipファイルのURL　差分zipファイルサイズ &br()　　 &br()　　※ただし，サーバ側は，差分zipファイルサイズの合計サイズが，最新のzipファイルサイズを &br()　　　超えるような場合，それ以前の差分のシェルID・URLは返さない． &br()　　 &br()　　クライアント側では，応答に既に持っているシェルIDが応答に含まれれば， &br()　　そのシェルID以降の全ての差分をDLし，順次適用． &br()　　そうでなければ，最新のzipファイルをDLする． &br() &br()差分のzipファイルはサーバ側で更新前のファイルと比較して自動生成するので， &br()利用者が意識する必要は無いです． &br()その点で，伺かの方式みたいなめんどくささはないかと思います． &br() -- (mikage) &size(80%){2010-08-22 13:18:29} - ディレクトリ構造やファイル名を変えたとしてもSHA-1が同じ画像ファイルを再要求する必要はありません。 &br()それに、シェルに基本的に深いディレクトリはなかったはず。 &br()また、世代管理だけでなく「あるオープンシェル」「少し違うその亜種」「その亜種」みたいな軸でのバリエーション管理も、ほぼ同じ枠組みで考える必要があり、そっちは差分ZIP準備で対応できません(シェルIDを別物にしているくらいなので、世代軸の更新も亜種軸の更新も内部的にほぼ同一に扱いたいですし)。 &br()さらに、シェルを単に最新に保つだけでなく、ピンポイントである{時点/亜種}のシェルが欲しくなることがそれなりに多いと予想されるので、差分を重ねる方式は(僕が)わけ分からなくなり、結局フルセットを頻繁にダウンロードする羽目になりそうです。 &br()究極的には毎回ツリーの差分を判定してまとめて送信するSubversion的な方式が理想かもしれませんが、面倒です。 &br()一度に数十ファイルも新規画像を追加するような人はかなり稀と思いますし、それでも精々ちょっと凝ったウェブサイトを1ページ表示するのと変わらないと思います。 &br()それでもきついなら、想定されるシチュエーションに対して汎用性が低すぎることを承知の上で、「直前の世代と現世代」という典型パターンのみ差分ZIP更新に「も」対応するのは可能と思いますが。 -- (naruto) &size(80%){2010-08-22 14:34:50} - &br()ファイル単位は性能的に厳しいです． &br()どのくらいの性能かというと &br()http://blog.mikage.to/mika/2007/07/erlangwebyaws_1c22.html &br()に記載したくらいです． &br()同時に１０００人とかからの１００ファイルのリクエストを &br()受け付けたりするには厳しい数値だと思います． &br() &br()% シェルの平均ファイル数がわかればもう少し正確な想定ができるかも． &br()% あと，別ポートで他のサーバを立ち上げれば，もう少し上がる余地はあります． &br() &br()差分zip方式の場合，過去のシェルについては，多くの場合 &br()フルセットDLになると思いますので，その点は不利ですね． &br() &br()Subversion的な方法は，１クライアント毎に差分判定が必要に &br()なると思いますので，これも厳しそうです． &br()差分zipの場合は，サーバ側で最初に１回判定するだけなので， &br()その点がメリットですね． &br() &br()究極的には，Bittorrentプロトコルなどを使って，クライアント &br()同士でP2Pで配信してくれればと思いますが，Flashではたぶん &br()無理ですよね． &br()（UPnP対応とかしないとほとんどの環境で役に立ちませんし） &br() -- (mikage) &size(80%){2010-08-22 15:38:38} - &br()シェルの配布ロジックについて． &br() &br()シェルを効率よく配布するために，アップされたシェルに対して &br()installShell コマンドというのを用意していたと思いますが， &br()これで配布を行うために，シェルをアップしてから利用開始までの &br()間にどのくらいユーザを待たせても良いでしょうか． &br() &br()シェルを順次配布すれば，かなり少ない帯域でシェルを配布できます． &br()シェルUPから利用開始まで1時間待たせて良ければ， &br()5Mbpsの帯域で2250人に配布できるとも言えます． &br() &br() &br()もともと一斉にシェルをDLされないように，（時間については後で &br()考えると言うことにして）installShell コマンドで &br()順次配布することを考えていましたが，これだと以下のような &br()ケースで問題になることが考えられます． &br() &br()深夜など人数が少ないとき，例えば接続者が300人， &br()アクセスが多い時間帯で接続者が1000人だとすると， &br()深夜にアップロードされたシェルは，300人に対しては &br()installShellで順次配布されます． &br() &br()その後アクセスが多い時間帯に，そのシェルでの発言があると， &br()一斉に700人がDLすることになります． &br()700人くらいなら，50Mbpsを2分間で配布できるので &br()たぶんなんとかなりますが，数が増えるとISPから目を &br()付けられそうです．(^^; &br() &br()サーバに接続する時間はばらけると思いますので， &br()その時間を上手く使って新しいシェルを配布できれば効率的です． &br() &br() &br()そこで，ログイン時にDL済みのシェルID一覧をサーバに送信し， &br()それを元にサーバ側がまだDLしていないシェルの installShell を &br()順次発行するようにすると良さそうですが，どうでしょうか． &br()新規ユーザは，例えば新しいシェルから，全てのシェルを &br()DLすることになると思います． &br()（ランダムトークが1つも登録されておらず，ずっと発言が &br()　無いシェルであればskipしても良いと思いますが） &br() &br() -- (mikage) &size(80%){2010-08-22 19:29:09} 2010-08-22T19:29:09+09:00 http://www26.atwiki.jp/himagine/pages/45.html *ユースケースと用語定義 このページでは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人のユーザは、複数のシェルをアップロードすることができます。 -シェルをアップロードするだけで、対応するキャラクターを作らないことは可能です。単にオープンシェルとしてアップロードしてそのまま放置しても問題ありません。 *以上まとめ &img(図1.png); *付記 SSTP Bottleのように「仮想的にそこに存在するゴーストは1人で、それを誰もが自由に喋らせる」といった実装にはしません。しかしクローズドシェルを使ったキャラクターオーナーが複数の人間を追加キャストとして認証するキャラクターを作れば、似たようなことは可能です。 配布するソフトウェアは、リスナー用のシンプルな受信用クライアントがメインです。キャスト用のクライアントは別配布とします。(SSTP Bottle Clientは送受信両用でした) *トラブル対策 -シェルの更新・削除関連 --シェルをアップデートする際、単にサーフィスが増えるのは構いませんが、以前使えていたシェル番号と絵柄の対応が大幅に変わるようなことがあると、そのシェルを使っていたユーザにとって問題となります。この辺の防御策について検討が必要です。 ---シェルにバージョン管理を持たせて同一名称の複数世代のシェルが管理できるとよい? これは過去ログを正しく表示できるようにするためにも必要。 --シェルを削除する場合はもっと大変です。この場合、紐付いているキャラクターがみんな同時に利用不可能になってしまいます。 ---対応として、1人でも自分以外がオーナーであるキャラクターが付いたシェルは、例えシェルオーナーといえども削除出来ないようにする必要がありそうです。 ---一方でシェルに著作権侵害などの法的問題が生じた場合は問答無用で削除せざるを得ません。この辺は「シェルマスターにシェル投稿時に警告を十分表示する」「キャストにもキャラクター作成時に注意を促す」ということでなんとかしましょう。「オープンシェルの場合は管理者の審査を要する」とかもでいいかもしれません。 2010-08-08T22:23:14+09:00 http://www26.atwiki.jp/himagine/pages/43.html -あちこちに分散しがちな情報を仮にまとめるためのページです。 -HIMAGINE関係の記述などを見つけたら、とりあえずここにぶち込んでください。 //-このページに記録した内容はほったらかしにせず、文書としてまとめるようにしましょう。 ---- *2010/06/06の12時前後に流れていた話題の仮まとめ。 Twitter上での大まかな流れ |なるさん|AIRを除くFlashアプリではディレクトリ内のファイル一覧が取得できない→サーフェス定義ファイルに記述されていないファイルを取得できないかも？&br()surface0とかsurface00とかsurface00000とかいろいろあるのはどうしよう？&br()※SSPではもっとも桁数が多い物が優先される模様 https://twitter.com/fm7743/status/15525316845| |みかげさん|サーバ側でファイルリストを作ってクライアントに渡せばその問題は回避できるかも？&br()そもそもZIPファイルを展開する前に中身の一覧とか取れないのかな？| |なるさん|元々、一つ一つファイルをアクセスして、404かどうかで判定するつもりだった。&br()でも、サーフェス番号のところに任意の桁数を指定できるとは思わなかった。&br()ZIPオンリーにしてアーカイブから直接シェルをロードする発想はなかった(遅くなるからやらないと思う)。| |みかげさん|個別にファイルにアクセスする場合、アニメーションサーフェスだとサーバに負荷が掛かりそう。&br()Flashに、ローカルストレージとかローカルキャッシュとかはあるのかな？| |なるさん|サーバへのアクセスはWEB起動を念頭に置いていたため。ローカル限定ならどうと言うことはない。&br()Flashにはキャッシュ的な物しかない。Flashである限り、永続的なファイル保持は絶対無理| |なるさん|AIRで組み立てるなら、ZIPで配布、ローカルに展開、ローカルから読み込み、でなんの問題もない。| |みかげさん|オンデマンド呼び出しだと、数百枚のアニメーションサーフェスがあった場合にサーバの負荷が凄いことになりそう……&br()たとえば、1000人が10秒間で100枚DLしたら１万アクセス/秒になる。| |なるさん|WEB版は、せいぜい作者の動作プレビュー用なので負荷は問題ないのでは？&br()エンドユーザはAIR入れて貰わないと大変かも。| |みかげさん|一般ユーザ向けにもWEB版も標準装備するのだと思ってた。&br()AIRインストールできないけどFlashなら大丈夫、と言うような環境を想定。| |なるさん|サーバ負荷を気にしないなら可能にしても良いと思います。| *2010/06/06の17:30頃～20:00頃のログ仮まとめ |なるさん|シェルフォルダのサブディレクトリに画像が置かれることってありましたっけ？| |くーぷらんさん|サブディレクトリに画像を置くことはしません。無視されるはずです。| |せきやひろし|基本は無視ですが、サーフェス定義ファイルで指定すれば読みます。&br()場合によっては上位ディレクトリに遡ってアクセスすることも可能。| |なるさん|上位ディレクトリに遡るのはセキュリティ上禁止したい。| |みかげさん|あんまり大変そうなら、シンプルにしたSERIKOのサブセットを定義するとか？| |なるさん|省略できるところがなかなか見つからない。下手に省略すると、シェル定義ファイルの書き直しの手間が凄いことになる。&br()プログラマが楽をするためだけに、そう言うことを絵師さんに押しつけたのでは上手くいかないと思う。&br()そもそも今はアニメーション表示以前の、静止画としての立ち絵を表示するところで躓いている。&br()たとえば、\s[2024]に相当するサーフェスを定義する方法が何通りもあるのでどうしよう、と。| |せきやひろし|SERIKO定義と言えば、水無月さんが公開されてる「れいちぇるのレストラン」が、かなり鬼畜なので、ご参考までにｗ| |なるさん|SERIKO定義もだけど、バルーン内部への画面貼り込みの方が脅威(汗)。&br()※画像貼り込みは\_bタグ。当面無視される模様。| |みかげさん|どうせだからFlashとかも表示できると面白いかも。| |[[noisenoise>http://twitter.com/noisenoise/status/15546897485]]|フルアニメーションシェルが簡単にできそう？| |せきやひろし|Flash使えると時計表示とかが簡単にできますね。今の仕様だと凄くめんどくさいので。| |なるさん|SWFをそのまま重ねるだけなら凄く簡単でしょうね。| #comment(,nsize=20,size=75,vsize=10) *2010/8月上旬の「ユースケース」欄での仕様議論アーカイブ。 **課題 - リスナーにアカウントを要求すると利用者が増えにくいのでは - Twitter連携の課題 -- 文字数の制限をどうするか -- ID・パスワード指定での連携はもう無理になるのでOAuthへの対応が必要そう． -- 作るのが大変．一度システムをくみ上げるところまではできたとしても，その後のTwitter側の仕様変更に追従できるほど時間の確保は難しい．TwitterのAPI仕様はちょくちょく変わっている模様．（この部分を他の人がやってくれるなら大丈夫） - リスナーの管理のサーバ側リソースの問題 -- リスナー毎にアカウントを管理すると，サーバ側で配信するデータを選ぶ操作が入る上，分散がしにくくなってしまう． -- リスナーの管理無しの場合，以下のような形でスケールアウトできます． --- サーバは，投稿が行われるマスターサーバと，メッセージの配信のみを行うスレーブサーバの2種類あります． --- スレーブサーバはマスターサーバに接続し，配信するメッセージを受け取ります． --- クライアントは，マスターサーバに接続しますが，その際にスレーブサーバへの再接続を指示されることがあります．その場合，スレーブサーバに繋げ直します． -- サーバ1台あたり，処理できるユーザ数は数千～1万人程度までです．常時接続なので，通常よりシビアになります． -- リスナー毎のアカウント管理を行うとした場合，上記のような分散はかなり複雑になってしまいます． -- リスナーがどのキャラクターを読むのか，といったのはクライアント側で区別して処理する形の場合，以下のように柔軟に対応できます． --- 最初は全部がデフォルトfollow --- キャラクターの数が増えて来た場合，デフォルトで著名なキャラクターをセレクトしておき，追加のfollowを手動で行うようにする． -- クライアント側で購読キャラクターを管理する場合，キャラクターの人気を測定できないので，そこは定期的にサーバに情報を送るなどして，別途集計する必要がありそう **Re:課題 (naruto) -2ちゃんやTwitterと違い、1個のメッセージ再生ごとに時間を食うため、SSTP Bottleの100人程度のコミュニティですら、全員同報では再生が追いつかないことが頻繁にありました。その経験から、まともに人間が処理できる購読キャラクターは、Twitterでのそれの1割程度、つまり精々数百キャラクターに留まると思います。サーバ1台で間に合わないほどユーザが増えた時点で、全キャラクターの発言を追いかけるのは到底無理です。 -仮にユーザが1万人を超え、複数サーバを考慮しないといけない事態になった場合、全員全文同報方式ではほとんど全てのトラフィックが無駄になります。サーバが5台になる頃にはもう、どんなヘビーユーザでも99%、普通のユーザは99.9%のトラフィックを無駄に捨てることになり、ちょっと許容できないレベルではないでしょうか。 -単純に、あらゆる個別サーバのネットワーク負荷が、全体のユーザ数に正比例して増えるシステムは、正しくスケールアウトできていない気がします。 -全同報方式の場合、仮にN人のユーザがいて、そのうち5%が5秒の間に「あけましておめでとう!」なり「日本勝った!」なり「バルス!」なりで、ヘッダ込み200バイト程度のメッセージを一斉に送信した場合、サーバ全体からのoutboundの帯域は 200(Byte) * 0.05N * N / 5(s) ≒ 10N^2(Bps) で、N=10000の場合で1GBps、N=50000の場合で23GBpsです。''N^2オーダーで増える''ため大変厳しいです。これが「1キャラの発言を受信するリスナーは平均100人」で済むなら、 200(Byte) * 0.05N * 100 / 5(s) ≒ 1000N(Bps) で、N=10000の場合に76Mbps、N=50000の場合に380Mbpsと、かなり現実的になります。 -数万キャラと数万人のリスナーとの購読対応テーブルは十分各サーバがオンメモリで持てる範疇と思います(ですよね?)。 -結論として、N＜1000くらいまでの間は「全リスナーが全キャラの全メッセージ受信」で大丈夫と思います(現状のボトルとほとんど一緒だし、結局永遠にそれで良い可能性もありますし)。が、本当に複数サーバを考えないといけないほど人気が出た場合、何としてもサーバ側で選別処理するのは必要になってくると思います。 -キャラ人気測定にも絡みますが、「ユーザがどのキャラクターを購読しているか」のリストは、ローカルの設定によるフィルタではなく、サーバサイドできちんと管理するのが必須だと思います(実際のフィルタリングをローカルでやるとしても、そのリスト自体はサーバから受信)。上記の様な将来の拡張性を見越す上でも必要ですし、複数箇所でログインする可能性の利便性もありますので。 -リスナーに最初からアカウント登録要求するのは確かに面倒くさいですね。例えば「HIMAGINEスタッフお勧めキャラクター数十人をとりあえず購読できるお試しモードを作る」というのはどうでしょう? -''ていうか、もし1万人を超えるようなら僕の手に負えないので、どっかで事業化考えてくださいw'' **Re:課題 (mikage) - 数万人のリスナーはなんとかなったとして，数万キャラはどうにもなりません．キャラクターとして対応できるのは数百程度までだと思います． -- 1つのシェルが 10MB だったとして，10分以内に1万人に配布しようとしたら，1333Mbps の帯域が必要になります．これはスレーブサーバの協力者がたとえ20人いたとしても無理があります． -- 1つのシェルが 10MB だったとして，1万キャラクターをHDDに記録するには 10GB の容量が必要です．更にアーカイブを展開したデータも持つならその2倍．マスターサーバ側ではこのくらいの容量は工面できますが，他の方にスレーブサーバの協力をお願いするときに「協力してくださる方はディスクは20GB用意してください．」というのはなかなかハードルが高いと思います． -- それに比べて会話データは大したボリュームではありません．10秒に1回1KBの発言があり，1万人に配布する場合は 8Mbps の帯域があれば十分です． --- 1万人のリスナーがいて，発言をする人が100人だとして，その100人が1日20回スクリプトを流すとしたら…というように考えると，実際に帯域が問題になるほどの発言量がでることはずっとずっと先の話だと思います．Twitterやボトルなどと違い，受け取るだけのユーザが大半でしょうし，トークを書く方もさくらスクリプト等で書く必要があるので，発言数もそんなに増えないと予想します． - 「数万キャラと数万人のリスナーとの購読対応テーブルは十分各サーバがオンメモリで持てる」というのは，それようにサーバを用意すればその通りでしょうが，スレーブサーバを誰かに協力してもらい，リソースを貸してください…ということで対処しようとしたら，難しい容量になると思います．レンタルサーバなどでは512Mなどのところも未だにありますし，自宅サーバでも4Gとか8Gとかのせている方は少ないと思います．1人のキャラと1人のリスナーの対応の保持に16バイト必要だとすれば，1万人×1万人×16バイト＝1.6GB になります．更にこのデータをスレーブサーバとマスターサーバで共有する必要があり，その通信も発生します． -- ちなみに，わたしの自宅のサーバは1.6Gはなんとかなるかもしれませんが，スレーブに使おうと思っていたレンタルサーバの方は512Mしかメモリがありません． --- 追記：スレーブサーバは自分が対応しているユーザ数分を持てばいいし，followしているものだけを管理すればいいので，実際には5000人×500フォロー×16バイト＝40MBくらいで済みそう． - キャラクター数が1万人超え，のような状況になったら，帯域の問題含め対処が必要で，現状のサーバリソースではどうにもなりません． -- 現状のサーバリソースでできる範囲を考えたら，サーバ側での選別処理は必要ないと思います． **Re:リスナーの動作について (mikage) - リスナーの新規キャラクターのfollowは自動でされる方が望ましいと思います． -- 前提として，キャラクターが1万とかの世界ではなく，100程度までの状態をイメージしています． -- この段階では，興味のあるキャラクターをユーザが探して，それをfollowするという作業自体が面倒なものになります．また，新規にキャラクターを作る立場からすれば，自分のキャラクターを別の経路で宣伝して，リスナーにフォローしてもらわないといけなくなります．フォロワーが少ないと，キャラクターのキャストのモチベーションも上がりにくく，悪循環です． -- 初期は全リスナーがアカウント登録不要で，全キャラクターを自動受信．不要なキャラクターをblacklist方式で除外する方式がよいと思います． --- もしそれで破綻するほどの人気が出た場合は，その段階で，インストール時はその時点で活発に会話がある上位○キャラクターを自動follow，その他は手動followにする必要があると思いますが，それまでにはキャラクターを選んで簡単にfollowできるシステムが必要だと思います． ---- フォロワーの数や，最近1週間の発言数などでのランキングがクライアントに表示されて，ワンクリックでfollowできるとか． - Twitter等に比べて，投稿のハードルが高いので，全キャラクターを自動受信方式で当面は問題が出ないのではないかと思います．むしろその方式でも会話数が少なすぎるのではないかという心配から，ランダムトーク相当の機能を考えていたくらいです． ** 未検討事項 - 現状ではランダムトークに相当するものがありませんが，これはある前提でOKですか？ -- 今のテストサーバ側ではランダムトーク相当の機能を実装しています． ** 合意・初期段階実装事項（とりあえずmikage/narutoで） - シェルに関する部分 - キャラクターに関する部分のうち，SSP・Twitter連携以外の部分 - Web上・AIR版クライアントからのメッセージ投稿 2010-08-08T21:51:21+09:00 http://www26.atwiki.jp/himagine/pages/14.html *HIMAGINE関連 HIMAGINE関連の外部資料など -[[オンラインゴースト/アイディア説明＠駄でべろぱの小ネタWiki>http://emily.shillest.net/specwiki/index.php?%E3%82%AA%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%B3%E3%82%B4%E3%83%BC%E3%82%B9%E3%83%88%2F%E3%82%A2%E3%82%A4%E3%83%87%E3%82%A3%E3%82%A2%E8%AA%AC%E6%98%8E]]&br()全てはここから始まった -トゥギャッターでの関連発言まとめ --その１；[[http://togetter.com/li/18115]] --その２：[[http://togetter.com/li/19076]] --その３：[[http://togetter.com/li/21486]] --その４；[[http://togetter.com/li/25323]] -TwitterでのHIMAGINE関連発言 --[[関係者をまとめたリスト(補足漏れが出ることがあります)>http://twitter.com/SekiyaHiroshi/himagine]] --[[#HIMAGINEタグで検索>http://search.twitter.com/search?q=%23HIMAGINE]] -外部掲示板 --[[外部にも掲示板を設置しました>http://himagine.hironet.jp/bbs/]]&br()ファイル添付ができます。また、新規トピックの作成も簡単に行えますので、こちらの方が使いやすいかも知れません。 *参考リンク HIMAGINEを作る上で参考になりそうな場所へのリンク -[[SSTP Bottle>http://bottle.mikage.to/]] -[[COLORS>http://sites.google.com/site/colorsprj/]] -[[Webゴースト 緑と青虫>http://lre.s361.xrea.com/uka/webgo/htmltalk.cgi?ghost=mna&event=OnTalk]] -[[Twitter上のなりきりアカウント>http://twitter.com/SekiyaHiroshi/narikiri]] *仕様関係のリンク -http://bottle.mikage.to/clihelp/begin.html -http://crow.aqrs.jp/reference/all/ -http://disc2.s56.xrea.com/manual/list_sakura_script.htm -http://jn.swee.to/cano/sstp/ssparserdoc.html -http://disc2.s56.xrea.com/manual/list_sakura_script.htm -http://sakura.nanika.jp/sstpviewer/svg/svg_doc.html -http://www.geocities.jp/poskoma/docs/2.html *その他 整備中 2010-08-04T19:32:43+09:00 http://www26.atwiki.jp/himagine/pages/18.html *キャッチフレーズ 創造してごらん、無限の可能性を *概要 HIMAGINEは、「伺か」の技術をベースにした、新しいキャラクタシステム兼コミュニケーションツールです。 HIMAGINEは「ゴーストの立ち絵やアニメーション、会話を表示できる」という点で、広義には伺か/SSPのようなベースウェアの一種ですが、materia/SSP/CROWと、かなり目標を異にしています。 -''SHIORIがありません''。当然SAORIもなければ、辞書ファイルもありません。人格という意味でのゴーストは、ユーザのディスク上に展開されません。 -会話文はサーバーからネットワーク経由でリアルタイム配信されることを前提としています。TwitterやSSTP Bottleのようなものをひとまず考えて下さい。オンラインでなければ何もできません。 -narファイルによるインストールがありません。代わりにシェルはネットワークから、ユーザの操作なしに自動でインストール・アップデートされます。 --実際のダウンロードのトリガーは、そのシェルを使うキャラクターをフォローした瞬間となります。 -ゴーストは、ネットワークから配信されるメッセージに反応して自動で起動します。 以上のような仕組みのため、メッセージを受信して掛け合いを楽しむユーザ（このようなユーザを''リスナー''と呼びます）には以下のようなメリットがあります。 -いちどHIMAGINEクライアントをインストールするだけで、DLL自動インストール等のセキュリティリスクを気にすることなく、シェルの自動ダウンロード・展開が行われます。HIMAGINEでのキャラクターの購読は、Twitterで1人フォローするのと同じくらいに簡単です。 -ゴーストは自動起動・更新・管理されるため、何百ものゴーストをインストールしていても困りません。 -DLLが存在しないため、仕組みは完全にクロスプラットフォームです。HIMAGINEクライアントは[[Adobe AIR>http://www.adobe.com/jp/products/air/]]で実装されており、Windows/Macでほぼ同様に動作します。 -辞書経由での会話ではないため、ゴーストの発言はリアルタイムです。ほぼチャットなみの速度で、ニュースなどの話題でゴースト同士が掛け合いを行うことも可能です。 ゴーストを発言させる側のユーザ（''キャスト''と呼ぶことにします: ゴーストを演じる「役者」、発言を「投げる人」の、両方の意味をかけています）として、以下のような複数のケースを想定しています。 -クローズドなシェルを自分専用に使い、自分専用のキャラクターを運用する。固有のゴーストとしての人格を自分だけで表現できます。他人によってゴーストの人格が乱される心配(SSTP Bottleのような)はありません。 -クローズドなシェルを複数人で使う。固有のゴーストとしての人格を、オーナーが認証した複数人で作り上げます。イベント/商品宣伝用のゴーストを複数人数のスタッフで運用する、などのケース。 -オープンなシェルを使う。オープンとして登録されているシェルを使うキャラクターを、誰でも作成できます。気軽に使用できる一方、ひもづいているキャストによってキャラクターは異なる人格になります。基本的には絵文字/顔文字の延長と考えるのがよいでしょう。 --オープンなシェルは誰でも登録することができます。 --とりあえずデフォルトオープンシェルとして「ぱせり」を準備しています。 なお、サーバ自体は公開のAPIのため、SSPが対応することで、既存のゴーストもリアルタイムな会話を繰り広げることが可能です。 更に詳しいシステム概念については[[ユースケース]]をご覧ください。 ---- -[[オンラインゴースト/アイディア説明＠駄でべろぱの小ネタWiki>http://emily.shillest.net/specwiki/index.php?%E3%82%AA%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%B3%E3%82%B4%E3%83%BC%E3%82%B9%E3%83%88%2F%E3%82%A2%E3%82%A4%E3%83%87%E3%82%A3%E3%82%A2%E8%AA%AC%E6%98%8E]]の内容をベースに、新世代のオンラインキャラクターシステムとして開発が進められているシステムです。 -&date(j)現在、このシステムは開発中の物であり、仕様等の検討を行っている段階です。 -以下整備中 *&aname(JOIN){プロジェクトへの参加について} 当プロジェクトでは、常に参加者を募集しています。プロジェクトへ参加ご希望の方はお気軽にお声かけください。 プロ・アマ・分野は問いません。何ができるか分からないけど参加してみたい、意見やアイディアを出してみたい、と言う方でも結構です。 参加をご希望される方は、[[このウィキに参加>http://www26.atwiki.jp/himagine/contributor]]からご参加ください(自動的にメンバー承認されます)。 その後、必要であれば、[[関係者一覧]]ページを編集し、ご自分のエントリの追加をお願い致します。 なお、現時点では、プロジェクトの方向性や仕様を決めるべく、議論を重ねて情報をまとめている段階なので、文書として整理されている情報がほとんどありません。 そのため、途中から参加される方には、プロジェクトの全体像が把握しづらい状況となっております。 参加ご希望の方にはご迷惑をおかけ致しますが、何卒ご了承くださいますようお願い申し上げます。 *その他 Twitter上でHIMAGINE関連の発言をされる場合は、#HIMAGINEというハッシュタグを付けて発言することをお勧め致します(強制ではありません)。 2010-08-04T17:28:36+09:00 http://www26.atwiki.jp/himagine/pages/2.html **メニュー -[[トップページ]] -[[HIMAGINEについて]] -[[ユースケース]] -[[関係者一覧]] -[[ToDo]] --[[検討中>ToDo/検討中]] --[[決定済>ToDo/決定済]] -[[関連リンク]] -[[情報交換掲示板]] -[[仮まとめページ]] -[[練習用]] &online()人が閲覧中 // //---- // //**リンク //-[[@wiki>>http://atwiki.jp]] //-[[@wikiご利用ガイド>>http://atwiki.jp/guide/]] // //**他のサービス //-[[無料ホームページ作成>>http://atpages.jp]] //-[[無料ブログ作成>>http://atword.jp]] //-[[2ch型掲示板レンタル>>http://atchs.jp]] //-[[無料掲示板レンタル>>http://atbbs.jp]] //-[[お絵かきレンタル>>http://atpaint.jp/]] //-[[無料ソーシャルプロフ>>http://sns.atfb.jp/]] // //// リンクを張るには "[" 2つで文字列を括ります。 //// ">" の左側に文字、右側にURLを記述するとリンクになります // // **更新履歴 #recent(20) &link_editmenu(text=ここを編集) 2010-08-04T14:21:02+09:00 http://www26.atwiki.jp/himagine/pages/36.html *サンプルキャラクター -[[量産機>http://pixiv.cc/ragn/]]さんの描いた[[「小人さん」の絵>http://pixiv.cc/ragn/archives/51425295.html]]に使用許可をいただき(2010.06.02許可取得済)、彩色をTwitterで公募の結果、[[青猫格子>http://guildhall.s56.xrea.com/]]さんが彩色して下さったもの。その他の画像加工、アレンジはくーぷらんが実施。 -なおこの画像は、くーぷらんがゴーストとしても利用する予定です（HIMAGINEのPR用）。 -小動物さんのフリー素材「Gハム長毛　毛色・模様」を利用して、相方を作成。(2010.06.04) -名前は「&bold(){ぱせり＆せろり}」に決定。(2010.06.06) ---- -以下、立ち絵サンプル。 --通常 #image(http://couperinjp.hp.infoseek.co.jp/kobito/kobito1.png,http://www26.atwiki.jp/himagine/?%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%82%AD%E3%83%A3%E3%83%A9%E3%82%AF%E3%82%BF%E3%83%BC%E3%81%AE%E7%AB%8B%E3%81%A1%E7%B5%B5) --照れ #image(http://couperinjp.hp.infoseek.co.jp/kobito/kobito2.png,http://www26.atwiki.jp/himagine/?%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%82%AD%E3%83%A3%E3%83%A9%E3%82%AF%E3%82%BF%E3%83%BC%E3%81%AE%E7%AB%8B%E3%81%A1%E7%B5%B5) --困惑 #image(http://couperinjp.hp.infoseek.co.jp/kobito/kobito3.png,http://www26.atwiki.jp/himagine/?%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%82%AD%E3%83%A3%E3%83%A9%E3%82%AF%E3%82%BF%E3%83%BC%E3%81%AE%E7%AB%8B%E3%81%A1%E7%B5%B5) --不機嫌 #image(http://couperinjp.hp.infoseek.co.jp/kobito/kobito4.png,http://www26.atwiki.jp/himagine/?%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%82%AD%E3%83%A3%E3%83%A9%E3%82%AF%E3%82%BF%E3%83%BC%E3%81%AE%E7%AB%8B%E3%81%A1%E7%B5%B5) -スクリーンショット。問題なければこの構成で行きます。 #image(http://couperinjp.hp.infoseek.co.jp/kobito/clip_1.png,http://www26.atwiki.jp/himagine/?%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%82%AD%E3%83%A3%E3%83%A9%E3%82%AF%E3%82%BF%E3%83%BC%E3%81%AE%E7%AB%8B%E3%81%A1%E7%B5%B5) -HIMAGINE上ではまだ動いていませんが、[[ゴーストとしてSSP上で動かしてみました。>http://lingerie.es.land.to/#MASCOT2]](2010.06.18) -[[サンプル動画はこちらに。>http://lingerie.es.land.to/mascot/parsley_celery_sample.html]](2010.06.18) *コメント #comment_num2(,num=10,log=サンプルキャラクターコメント,nsize=25,size=75,vsize=10,disableurl) 2010-06-18T22:38:16+09:00 http://www26.atwiki.jp/himagine/pages/15.html 必要に応じてトピックを増やしてください。 この掲示板は誰でも発言できます。関係者以外の方でも、何かご意見やご感想等がございましたら、お気軽にご利用ください。 [[ファイルを添付できる掲示板も用意しました>http://himagine.hironet.jp/bbs/]]。ご利用ください。 -&link_anchor(GIJUTU){技術的内容の意見交換トピック} -&link_anchor(TEIAN){機能提案トピック} -&link_anchor(IPPAN){一般の話題用トピック} -&link_anchor(TEST){テスト用} ---- *&anchor(GIJUTU){技術的内容の意見交換トピック} #comment_num2(logpage=技術的内容の意見交換,size=75,vsize=10,num=50,nsize=30) ---- *&anchor(TEIAN){機能提案交換トピック} #comment_num2(logpage=機能提案トピック,size=75,vsize=10,num=50,nsize=30) ---- *&anchor(IPPAN){一般の話題用トピック} #comment_num2(logpage=一般用,size=75,vsize=10,num=50,nsize=30) ---- *&aname(TEST){テスト用} #comment_num2(logpage=テスト,size=75,vsize=10,num=50,nsize=30) 2010-06-10T22:41:09+09:00 http://www26.atwiki.jp/himagine/pages/34.html - Wiki全体に関する話題や、その他雑談などはこちらへどうぞ。 -- (せきやひろし) &size(80%){2010-06-02 18:42:38} - 何となく思いついたので。キャッチフレーズとかコンセプトとか、そういう感じの物。 &br() &br()・無限の自由は無限の創造力を生み、無限の創造力は無限の可能性を生み、無限の可能性は無限の自由を生む。 &br()・とこしえの自由。あふれ出すイマジネーション。限りない可能性。そして、それらの融合。 -- (せきやひろし) &size(80%){2010-06-05 14:19:17} - 今後起こるであろう様々な話し合いのために、スレッドフロート式の掲示板があると便利かも、と思った。 &br()誰もが簡単にスレッドを作成できて、その中で流れがまとまれば、あとから参照する時にわかりやすさが向上する。 &br()スレッドフロート掲示板は、２ｃｈタイプのが有名だが、他にもそう言うスクリプトはあるので、そう言うのを使えば２ｃｈアレルギーの人も使いやすいだろう。 -- (せきやひろし) &size(80%){2010-06-09 11:45:48} - 掲示板を仮設置してみた。 &br()http://himagine.hironet.jp/bbs/ -- (せきやひろし) &size(80%){2010-06-10 12:58:32} 2010-06-10T12:58:32+09:00