Hatena::ブログ(Diary)

げっかんにっき このページをアンテナに追加 RSSフィード

伺かゴースト「レチハルカ」等の更新記録と
鉄道旅行記と、列車コンセント情報がメインの日記です。
伺かゴーストって何? という方は外部解説サイトも御覧下さい。


本体サイト

ゴーストダウンロード

伺か最萌トーナメント終了

2015年5月3日(日) うかべん大阪 #9 テキスト実況

第二部 12:50〜

12:53 | 第二部 12:50〜 - げっかんにっき を含むブックマーク 第二部 12:50〜 - げっかんにっき のブックマークコメント

「3Dで行こう!」 - yasi 様

  • 概要
    • 3Dシェル描画モジュール「Uka3D」について。
  • 2000年以降のゲーム等コンテンツ。
    • 3Dコンテンツが増加。リアルタイムレンダリングによる高品質アニメーションが使われるようになった。
  • もし、3Dシェルが使えたら?
    • 「可愛い仕草」「ゲームのような動き」「めくるのではなく、そっと覗..」
    • →「Uka3D」を使ってみよう!
    • 4年前の「うかべん横浜 #7」にも関連発表あり → http://d.hatena.ne.jp/hinoharu/20111009 「お楽しみ枠」

ーUka3Dの概要

    • 3DモデルをShellとしてリアルタイムレンダリングを行うモジュール。
    • SAORIとしてゴーストに組み込む。本体サーフェスウィンドウと半連動して稼働。
    • テストゴースト「MIKUさんDay's」で公開中。SAORI単体公開を実施。
  • 目的
    • 3D描画による安価なアニメーション表現を実現し、新たなキャラ表現を実現。
    • 一定のプログラミング力が必要であった3Dデスクトップマスコットの作成を安易に。
    • MMD界などからの新たな人材の取り込み。
  • デモンストレーション(MIKUさんDays)
    • 配布版は少し古いバージョン。新バージョン0.2は多ゴースト(多キャラ)立ち上げられるようになっている。
    • きせかえ機能も実装
    • ランダムトークはないが、かわいい仕草をする。新しい表現。
    • https://twitter.com/hinoharu/status/594714373160996864 多キャラモード
  • システム(概要)
    • 描画コア:DirectX9.0C以降(DXライブラリ)
    • 3Dデータ:PMD、モーションデータ:VMD(MMDで利用されているデータ形式
      • MMDの3DデータはPMXに変わりつつある。PMXも読めるが、上位互換部分の機能は動作しない。
    • Surfaces.txtに代わる独自規格の定義ファイル、Character.txt等を使用。
  • システム(構成)
    • 構成図 https://twitter.com/hinoharu/status/594715434496053248
    • Uka3Dでも2D仕様のsurface*.pngなどを保持しているが、ダミーファイル。(黒画像)
      • 旧来のサーフェスウインドウに重ねて3Dモデルを描画している。
    • GhostフォルダにSAORIとしてdllを保存。Ver.2では「Uka3D_Proxy.dll」と「Uka3D.exe」に分けている。
      • キャラクターの数だけ「Uka3D.exeのプロセスが立ち上がり、Proxy経由で本体と通信」
    • Shellフォルダの中に「Uka3D」フォルダを配置し、中にキャラクターデータ・3Dデータ・テクスチャ・アニメ等を保存
      • Uka3DのpmdファイルはDirectXの仕様で「連番」でなければならないが、使いやすさのため、「Character.txt」でエイリアス番号を割り当てしている
    • https://twitter.com/hinoharu/status/594716726517837826
  • システム(通信)
    • 既存のダミーウインドウとUka3Dウインドウの間でデータを通信
    • 起動時:既存ウインドウ→【位置情報】→Uka3Dウインドウ
      • Uka3Dウインドウの作成時に既存ウインドウのWHNDを要求している(?)
      • 前回終了位置をUka3Dレイヤーで保存するのが面倒なので、毎回位置情報を要求
    • 起動後:Uka3Dウインドウ→【マウスイベント、位置情報、Zオーダー】→既存ウインドウ
      • クリック時にバルーンも手前に出てきてもらうためにZオーダーを利用
      • Zオーダーは制御できるときだけしている。「常に手前に表示」には未対応。※SSP本体の「常に手前」と併用のこと
    • Uka3Dウインドウ(Uka3D.exe)だけでなく、Uka3D_Proxy.dll も本体SSPにデータを送っている。(DirectSSTPなど)
      • 複数キャラクターからまとめて本体でデータを受け渡ししないといけないときはproxy経由
  • 定義ファイル
    • 既存のsurfacestxtと同じような書式。
    • アニメイションさせることを前提としたシステム。
      • ループアニメ指定可能(アニメの最初と最後を同じポーズにする)
      • 次に再生されるアニメーションが指定可能
      • モーションA・B間のブレンドアニメーション(モーフィング)設定
    • コリジョン設定ではマテリアルIDを指定する。
      • 3Dの部品のIDみたいなもの
    • 着せ替えのかわりにアクセサリ設定が可能。
    • アニメーションの構成→3つの部分。「動きのある最初の部分」「ポーズ部分」「元に戻る部分」
      • ex.「ビックリして」「固まって」「もとに戻る」→一連の設定を指定することができる
  • 辞書での実装
    • すべての開始イベント(起動、切り替え受け等)でcreateリクエストを実行。
      • createリクエストの引数に「イベント名」を含めることができる→On3DBootのref0で帰ってくる
      • ref0で分岐可能
      • uka3Dウインドウを作る→初期準備を終えたらOn3DBootイベントを返す。
    • すべての終了イベントで明示的アンロード、もしくはallresetリクエストを実行する必要がある。
      • 基本的に、Shioriは終了時にSAORIを自動的にはアンロードしないので、これをしないとUka3Dプロセスが残ってしまう
    • On3DMotionChange (2DでいうOnSurfaceChangeと同じ働き)で通知されるモーションIDをもとに、次に再生するべきモーションIDをリクエストする
  • 課題
    • Character.txtを記述するためにDXライブラリ付属の「DxLibModelViewer」が必要。マテリアルIDを調べるのに使う。
      • 今後、開発ツールに上記ソフト同等の機能を実装する必要がある。誰かやってください。
    • 起動中、ウインドウサイズの変更ができない。(シェルサイズを変更したい、等)
      • 本当は変更できるが、DXライブラリの初期設定を破棄→再読み込みする必要がある。資料を読み込みきれていない。
    • 多キャラ対応したことで更に定義ファイルの企画策定が難航中。一人で決めるのは大変。
      • 実際にゴーストを作ってみるしかない。
      • 仕様公開後に大幅な仕様変更をかける可能性も否定できない
    • SAORIでの実装には限界はある。
      • ex.更新時、SHIORIがSAORIをアンロードするため、更新時はキャラが隠れてしまう
      • できればSAORIの枠の先を目指したいが…SERIKOの切り離しができれば…(ここでぽなさん逃亡)
    • ※2012年当時のやりとり
      • 現在2Dで表示されているゴーストに3Dの追加シェルを作ることはできるか?
      • SERIKOシステムの切り離し仕様に依存するものと思われる。が、おそらく作れるでしょう。それを考えて作っている。(ぽなさん談)
  • 今後の展開
    • 最低限の規格策定後、単体・仕様の公開(専用サイトの開設)
    • テンプレ用サンプルゴーストの作成
    • 3Dシェル支援ツールの作成
    • モデル本体以外の描画(エフェクト等)
  • 企画の策定には皆様の協力が不可欠!今後ともご協力をおねがいします。
  • 質疑
    • 物理演算はリアルタイムなのか、ベイクされているのか?
      • MIKUさんDaysではベイクしていない。(ベイクすることもできる。読み込みが若干遅くなるが、起動後の計算量は減るので軽くなる)
      • 物理演算は入っているが、使うか使わないかデベロッパが決められる。MMD側で定義されているアニメーション(髪の動き方など)はそのまま動く。

「よろしくUKADOC -実写版-」 - もっしょくし 様

  • UKADOCとは?
    • 「Disc2の文章を基盤に、散逸しがちな伺かの仕様文書をできるだけ集めるプロジェクト」
      • いろいろな人が作ったものを集めて一つの作品を作るため、仕様がまとまっていることが大事
    • 伺か関係の仕様文書集約プロジェクト。および、その成果物としてのドキュメントのこと。
    • SSPの公式仕様文書 (※materia、CROWなどの公式文書ではない)
    • サブプロジェクトとして、SSPのヘルプのメンテナンスも実施
      • 現在はヘルプが完全オンライン。オフラインヘルプも整備したい
  • 誰が管理してるの?
    • 「特定」多数共同の管理(コミッタ制)
      • メリット:手がいっぱいある。個人管理のものは情報が古いまま更新が止まってしまったものがある。
      • メリット:Wikiと違い特定管理なので荒らされにくい
    • Ownerは2名(ぽなさん、緋龍華さん)
    • Committer14名(もっしょくしさん、畝某さん など)
  • Disc-2との関係は?
    • Disc-2(緋龍華さん管理)とデザインが似ている→許可を得てデザイン提供いただきました
    • 情報はukadocのほうがup-to-dateなのでぜひご利用ください
  • どう使ったら便利?
    • ページ内容の概要が記載されているので熟読のこと
    • 「記述例」を追加しているので、SSPのSendboxから本体にスクリプトを投げるとサンプル動作させられる(powered by あーるでぃ様)
    • ex:\_bタグの実演。画像をbase64エンコードした文字列を与えてインライン表示するサンプル。かっこいい!
    • ex:ShioriEventのサンプル。OnMouseDoubleClickイベントのリファレンス(引数)の意味を調べてみる。便利!
    • 現状では辞書のような使い方を想定だが、将来的には「教科書」にもしたい。ukadocを見ればゴーストの作り方のツカミを理解できるようにしたい。
      • あまり教科書成分を強くし過ぎるとサイトの軸がぶれるので、「参考書」レベルには濃くしたくない
  • 今後の予定は?
    • 各仕様概説をきちんとまとめる
      • 「駄でべ」にあるSSPの仕様文書を引き上げる(ただしこれはもともとの伺か仕様とSSP仕様の差分でしかない)
      • うさださくら」の根本仕様を補完。ukadocだけ見て全体がわかるようにしたい
    • SHIORI/3.1
      • SSPの仕様をSHIORI/3.1として新しく定義してはどうか?という話
    • もっと根本的な用語定義がほしい(うさださくらにはあるが…)
      • 伺か、GHOST、SHELL など
    • SERIKO描画メソッドなどに図解を追加。
      • Overlay、Replace などをわかりやすく
    • さくらスクリプト以外にも凡例を追加したい
    • 助けてくださるかた募集中!
      • Committerにならなくても良い、画像の編集とか手伝ってくれるだけでok
    • Google Code終了に伴い、GitHubに引っ越し予定
  • 誤字報告や要望はどこへ?
    • サイトのヘッダにある「報告・連絡」ボタンから、SSP Bugtraqの「Todo(SSP以外)」へ!
  • まとめ
    • UKADOCは(SSPの公式)仕様文書集です
    • UKADOCは現在進行形のプロジェクトです
    • UKADOCへのリンクをよろしくお願いします
      • (TIPSを外部記事で書いたときにリファレンスとしてリンクを貼ってもらえると嬉しい)
    • UKADOCはあなたのコミットをお待ちしてます
  • ところで
    • マスコットキャラクターがほしいのですが
      • UKADOG(犬)っていう名前だけ思いついたので、どなたかシェルと辞書書いてください!(安心と信頼の丸投げ)
  • 質疑
    • 「\p[x]タグのサンプルで文中の「\0」がエスケープされてないが?
      • \が抜けています。某あーるでぃーさんを叱っておいてください(byもっしょくしさん)
      • 治りました。(byぽなさん)
    • 万一に備えてうさださくらをバックアップ(保存)しているか?
      • 個人的には念のためしている。
    • Committerになるにはどうしたらいいですか?
      • ぽなさんに言えばもれなくなれます。

「『さとりすと』里々ゴーストの統合開発環境をつくったよ」 - ななっち 様

  • 概要
    • ヤンデレが好き。
    • 「さとりすと」里々ゴーストの統合開発環境。
      • 公開して1年1ヶ月。今も開発・更新中。
  • 統合開発環境とは・
    • ゴーストを作るのに必要なものを色々集めたもの
      • 例:SSP+メモ帳、FFFTP、フォトビューアー、さとりて、れしば、エクスプローラー
      • SSP以外のすべてを「さとりすと」で!
    • 画面例
  • (特長1)辞書のリスト
    • 「同じ名前で」「同じ名前と条件で」トークを追加するようなことが簡単にできる。ランダムトークのリストを作れる。
    • 辞書を直接編集することもできる。
      • 初回起動時にどちらにするか尋ねられる。あとで変更も可能。ファイルごとに変更も可能。
  • (特長2)デバッグ機能
    • 「さとりて」を使わずに、書いたトークをそのままゴーストに喋らせられる。(コピペ不要)
    • 変数の確認と設定、リロード、イベント呼び出しが「さとりすと」から可能。いちいちデバッグ処理をゴーストに組み込む必要がない
    • 「れしば」を内部に持っているので、新たに起動する必要がない
  • (特長3)設定ファイル編集機能
    • satori_conf や developer_options をリスト形式で編集することができる
    • 更新ファイル設定なども可能(削除ファイル等の設定)
  • (特長4)更新アップロード機能
    • FFFTPなどを起動しなくてもOK(自動化システムと同じ機能)
  • (特長5)立ち絵確認機能
    • シェル合成もやってくれるため、別に画像を用意する必要がない
    • 「サーフェスパレット」も作れる
  • (特長6)さわり反応領域表示・編集
  • ヘルプについて
  • やってみたいこと
    • 里々との直接連携
      • 里々本体に「さとりすと」連携専用の機能を搭載して、デバッグをより手軽にしたい。(変数一括取得など)
      • 「さとりすと」専用の機能をつけてもいいのかな…→ぽなさん「いいです」(1秒)
    • リクエスト対応
      • 需要に応じて機能を拡張する、など。いつも使っている人の意見を聞きたい。
      • バグが出てきたら修正します
  • まとめ(一番いいたいこと)
    • ヤンデレゴーストを作ってください!

--

  • おまけ
    • ゴースト配布サイトジェネレータ
      • HTML/CSSを一切書かずに公開サイトを作れます。配布サイト→
  • 実際にやってみた(デモ)
    • スクリプト作成支援機能(サムネイルをダブルクリックでサーフェス番号入力など)
    • 更新ファイルアップロード機能(誰も気づかないくらい一瞬で更新完了→自動ツイート)
    • ukadoc連携、SHIORIイベントリファレンス表示機能
    • 「さとりすと」自動アップデート機能
    • ゴースト新規作成ウィザード
    • その他、痒いところに手が届く機能満載!(めっちゃすごい)
  • 質疑・要望
    • ワンクリックでウエイト挿入できないか?
      • 右クリックメニューをカスタマイズ可能です
    • REPLACE と REPLACE_AFTER の色分け?
      • 設定で可能?
    • 今出来ないけどそのうち実現したいことは?
      • サーフェスプレビューの精度が悪いので、ukadocの拡充してほしい
    • 一部処理で速度が出ない
      • 里々本体との連携ができれば最高
    • 自動でネタを考えてください
      • 恒例なので気にしないでください(ぽなさん)
    • 設定のエクスポート・インポート機能ほしい
      • 全部の設定でよければ設定ファイルを複製してください
    • プラグイン作りたい
      • 入出力まわりの仕様を教えてもらえれば対応したい
    • すでに里々で作っているゴーストを読み込んで編集することもできるか?
      • できる。最初からさとりすとで開発している必要はない。
      • すでに機能をつくりこんだゴーストも読み込めるのか?
      • 可能。さとりすと専用のゴーストになることもない。
    • \eのあとをコメント扱いにしてほしい(\eでトークとしては終了するが、あとにコメントをつけることがある)
      • 「//」と同様の扱いにすればいいのかも。できればやる方向で。

「"ゴーストプレイヤー フロムウエブブラウザア"」 - duxca 様、奈良阪某 様

*奈良阪某さんパート*

  • 如何か(いかがか)とはなにか
    • 新しいベースウェア=SSPみたいなもの
    • SSPはWindows上で動くアプリケーション
    • 如何か=ブラウザ上で動作する。IE/Firefox/Android 等々…
    • Javascriptベースのベースウェアを作り上げるプロジェクト
  • なぜ作ったか?
    • スマートフォン全盛時代にデスクトップの消滅危機
    • ゴーストが立つ場所がなくなる→やばい
    • Windowsデスクトップ依存からの脱却→ブラウザ上で動作させたい
    • 伺かという創作表現の存続を図るために開発
  • なぜ作ったか(2)
    • 先発のSSP等よりもよりよい設計のものが作れるかも?
    • SSPが動かない環境を制覇することがSSPに淘汰されない唯一の道である
  • どう動くのか
    • システム構成図
    • シェル系・イベント処理系・ファイルシステム系・SHIORI系に別れている
    • 存在するファイルからSHIORIを判別する(栞プラグインを利用)
    • シェルとバルーンを起動(duxcaさん担当)
    • 「こういう動作がおこなわれたら」「イベントを発生させる」という処理をプラグイン方式としている
    • 以降、ベースウェアの動きの話を始められる(SSPなどもやっていること)
    • (イベント発火チェーンの開設)→OnBoot発生→さくらスクリプト発生→サーフェス表示!(拍手)
  • 要するにイベント処理のプラグイン大活躍! 自在にカスタマイズ可能
    • さらに、SHIORIもJavascriptで作れる!
  • 課題
    • SAORI対応、美坂栞(クローズドソース)対応 など

*duxca(ダクスカ)さんパート*

  • ゴーストプレイヤー フロムウエブブラウザア
    • 伺か互換環境の人
    • ウェブブラウザで動くシェル描画エンジンを作戦(CATTLEBONE、イカの殻=如何かのシェル)
  • なぜウェブブラウザで動かすの?
    • 最近ゴーストを起動していない理由?
      • ゲイのサディストだから
      • ではなく、Windowsを使っておらず、パソコンを持っておらず、パソコンを使ってないから
      • 最近の若い人はWindows離れが著しい…が、どれも「Webブラウザが動いている」
    • WEBブラウザで動く=移植性が高い!
    • そしてCUTTLEBONEとは…伺かを多様化するコンピュータ環境に潜り込ませるための技術
  • どういうしくみなの?
    • サーフェス描画までの道
      • narダウンロード
      • zip回答jszip
      • Shift-JISのエンコードencoding.js
      • surfaces.txt読んで(sufracesToYaml利用)
      • canvasに描画
  • どう使えばいいの?
    • 描画エンジンを叩く必要がある
    • 再利用も可能
  • まとめ
    • Webブラウザでシェル病がするライブラリを作った
    • IKAGAKA SHELL APIで抽象化
    • 再利用してください!(いろいろなところで活用してね!)
  • 質疑
    • 作った動機は?
      • (duxca)ゴースト配布ページのサンプル画像を(ゴーストのように)動かしたかった!
      • (奈良阪)ブラウザをベースウェアにしたかった!
    • 描画系とベースウェア系に分けてあることでどんな活用ができるか?
      • ユーザが投稿したトークをブラウザで再生したりできるようになる
    • ページをブラウジングしながらゴーストをいじることはできないのか?(専用タブでなく、任意のタブに立たせたい)
      • Chrome Extention などを使えば実現できるかもしれないが、今のところ不明。
      • ぶっちゃけJavascriptが動くならどんな動かし方もできる
    • SAORIの実現のめどは?
      • オープンソースのSAORIがあまりないので、Javascriptで再開発する必要がある。それをするリソースがない。
      • SAORIのインターフェースをどうするかが未定。(Windows上であればdllとして読みこめばいい)
    • (ぽな)いまどきアンマネージドDLLはないよね(と10年前から言っていた)。SSPは過去互換をしながら維持している間に、クリーンな実装が出てくるのを期待していたが、これで実現してしまっている。
    • 開発者側からみてDLLは鬼っ子。できれば脱却したいが…。
      • たとえば「ゴミ箱を空にする」を実現するのに、ブラウザだと各OS用の処理が必要になる。課題。
    • 先の発表のUka3Dとの連結は?
      • Uka3D仕様をCUTTLEBONE上で実現すれば可能では。
    • WebArchiveやウェブ魚拓の中でもゴーストが動くってロマンじゃない?
      • WebArchiveはデータが飛ぶからどこでも動くようにしようよ
    • プラグインカプセル化で実現できそうなこと
      • Ikagaka Shell APIの先に物理ロボットをつなげばリアルシェルも実現可能!?
      • 合成音声バルーンも実現可能!?
    • ぽなさんのコメント
      • すげぇ。
  • おわび
    • 若干まとめきれてない部分があるので、詳しくは発表資料を参照してください(ヒノハル)

2013年11月3日(日) うかべん横浜 #8 実況

第一部 13:15〜

12:15 | 第一部 13:15〜 - げっかんにっき を含むブックマーク 第一部 13:15〜 - げっかんにっき のブックマークコメント

本日のおしながき


「トーク数を水増しするゴーストの作り方」 - りすな 様

  • 概要
    • 外面と内面にギャップを作る
    • 食べ物の話をさせる
  • 食べ物の話をさせる
    • 人は共通の話題だと話しが話がはずみやすい
    • 食事は「相手を選ばない共通の話題」
    • 人は食事に対して何らかの考えを持っているものだ→ネタにしよう!
  • 食事をトークネタにする方法
    • キャラクターに好きな食べ物、嫌いなものの話をさせる
    • 食糧事情について
    • 料理について
    • お店で食べ物を食べたときの話
    • 滅多に食べられないような珍しい食べ物の話 など
  • 実例
    • 燃える稲穂(ラーメン)、ラベンダー畑(パスタ)、どっかのゴースト(いも)←原文ママ
  • 自分のゴーストに食べ物トークがないなあと思ったら実装してみよう! 造るの比較的楽!
  • 食べ物を食べないキャラクターの場合は?
    • 食事しない場合も、料理をするとか、食事に対する関心とかの話は可能だろう
  • 外面と内面にギャップを作る(新規のゴーストを作る人向け)
    • トークを作る際に話しのネタになる
    • ギャップから「なぜ」が生まれる、その「なぜ」が話のネタになる
    • 汎用性が高い
  • ギャップを作る方法→?イメージに反抗する
    • 見た目のイメージを裏切る
    • 人の印象の多くは見た目から決まるらしい。見た目は大切
  • イメージを裏切る方法について
  • イメージに反抗する方法
    1. 見た目を用意する(セーターを着ているキャラクター)
    2. 見た目から連想される言葉を挙げる(寒い、冬)
    3. 連想された言葉からかけ離れたものを考える(暑い、夏)
  • 夏場でもセーターを着ているキャラクター
    • なぜ夏場でもセーターを着ているのか?
      • その方がかっこいいと思っているから
      • 特殊な毛糸で邪悪な力を封じている
      • セーターに見えていたのは体毛
      • 信じられないくらいの寒がり
  • こうして出来た珍妙な特徴に対して、ゴーストに感想を述べさせることでトークネタになる。
  • キャラクターが複数出てくる場合、それぞれの立ち位置(意見)を違えることで、さらにトークが増える
  • 見た目から生まれる一般的なイメージを大事にする
  • イメージに反抗するキャラクターの実例(ヴァンプ将軍)
    • 世界征服を企図する悪役なのに「家庭的」「近所づきあいが大事」「理想の上司」 etc.
  • ギャップが与えるもの
    • ギャップから生み出される葛藤
      • 「とりかえばや物語」(平安時代)
      • 男児と女児を取り替えてそれぞれが貴族として働くお話。若君とされた女児はどんどん出世していく。
      • 若君(女性)の親友が若君の妻と関係を持ってしまう→不倫的な葛藤が生じる
      • 設定としては難しい話だが、葛藤が心理描写を深くしている
  • 何もしなくてもすでにキャラクターにはギャップが存在する
    • キャラクター自体が生物でありながら生物でないギャップを持つ存在である「サザエさん時空」
    • 漫画やアニメのキャラクターは人間として描かれつつも成長する人間とは違う存在である
    • 人間として描かれている以上、成長しないことは不自然
  • このギャップ(不自然さ)を利用した人→手塚治虫鉄腕アトム
    • 天馬博士は交通事故で死亡した息子、トビオに似た感情豊かで高性能なロボットを作った。が、成長しないことに怒ってサーカスに売り飛ばした。(ヒドイ)
    • 漫画のキャラクターが人間として描かれているにもかかわらず、成長しないことに対して多くの人が不自然に思うのと同じ描かれ方
    • 「生き物として描かれているのに成長しない存在」への不自然さを利用して、天馬博士の怒りに説得力を与えている
    • 読者が漫然と感じてきたであろう不自然さを(再)発見した
  • 伺かゴーストの実例(追悼歌)
    • ゴーストの宿命である「トークかぶり」を取り込んだ設定
  • ギャップを作ることで、トークネタを水増しできるだけではなく、感情表現に深みを持たせることすらできる。

「共同作業に使えるオンラインストレージの使い方」 - 高見知英 様

  • もくじ
    • インターネットストレージとは?
    • ストレージサービスを使った共同作業
    • 作業を補完するツールについて
  • はじめに
    • ゴースト関連ファイル管理をどうしている?
    • 複数人で共同制作をするときどうしてます?
    • →インターネットストレージサービスを使うとファイル管理などをやりやすい!
  • インターネットストレージとは?
    • インターネット上にPC上のファイルを保管するサービス
      • Yahooブリーフケース、ATOKオンラインストレージ、etc...
    • 昔:ファイルを手作業でアップロード
    • 今:特定のフォルダ内のファイルを自動的に同期 <近頃増えてきた!>
  • どんな動作をする?
    • ローカルPCの特定フォルダに新しいファイルを作ると→インターネットにも作られる
    • ローカルPCのファイルを編集すると→インターネットも修正される
    • PC AとPC Bのシンクも可能
  • Dropbox
    • 2GB〜有料プランで500GBまで共有可能
    • 他のPCでアップロードされたファイルをタスクトレイのバルーンで通知してくれる(共同作業を前提としたインターフェイス)
  • SugarSync
    • 5GB〜有料プランで500GBまで共有可能
    • 日本法人があり、日本円で支払い可能、若干高い
    • 複数のフォルダをインターネットに共有できる。柔軟な設定が可能。若干めんどうなところがある
  • SkyDrive(Microsoft)
    • 7GB〜有料プランで最大107GB(初期登録特典は25GB)
    • マイクロソフトのサービス。Winows8からはOS機能として利用可能。8,1からOSに統合
    • Officeファイルの連携に強い「このファイルは○○さんが使用しています」とか出てくれる
    • Office2013から保存先として標準装備
    • 大量のファイルのアップロードがとにかく速い
  • Google Drive
    • 5GB〜有料プランで最大16TB(GmailGoogle Photoと容量が共有)
    • 独自形式のドキュメントを保存可能、独自形式ドキュメントは「容量に含めない」→ドキュメントを置くだけなら実質無制限

https://pbs.twimg.com/media/BYH2QvdCIAAGIhS.jpg

  • ストレージサービスを使った共同作業
    • オンラインストレージの「共有」機能
    • Webから特定のフォルダを「共有」に設定
  • Dropbox、SugarSync
    • Web上の「フォルダに招待」からメールアドレスを入力することで共同作業者を招待できる
  • SkyDrive
    • Windowsユーザだけのコミュニティなら楽(Macは向かない)
  • Google Drive
    • オーナーと共同編集者、見るだけの人、などの設定を細かく出来る
    • 共有(招待)の方法は前者と同様。
    • 読み取り専用のURLを作成できる。(パブリックリンクの共有)
    • 明示的にリンクURLを削除できる(期間限定公開など)
  • 高見さんの例
    • 外部の人とのやりとり→Dropbox(バルーンでの通知が便利)
      • Dropboxはファイル共有専用のサービスのため、「誘いやすい」
    • 自分専用のファイル置き場→SYugarSync(複数フォルダの同期が便利)
  • まとめ
    • 多くのインターネットサービスが存在している。
    • 無料で使えるものもたくさんある。各種サービスを活用し、快適な挙動作業を!
  • 質疑
    • 一時期、Google Driveの規約について取りざたされたことがあったが、実際どうなのか?
      • 本人は「Don't be evil」と言ってるので使ってもいいんじゃないかな。でもあんまり信用していないから自分ではあんまり使ってません。
    • ファイルのバージョン管理をしたい場合は SubVersionなどを使った方がいいのか?
      • 他にもGit(バージョン管理)などのバージョン管理可能なツールもある。(だが難しい)
      • Google Drive なども一つ・二つ前くらいのバージョンは残る
      • 以前、SubVersionをはやらそうとしたがはやらなかった。Dropboxは今も使ってる人もいる。(使いやすい)
      • DropboxとSubVersionは同居させない。慢心、絶対ダメ!
      • シンボリックリンクも危険! データ消えます!(サイズが同じで真っ白なファイルができあがったりする)→シンボリックリンク先を消したため。(シンボリックリンクを拒絶するサービスもある)

「グループ制作のススメ 〜みんなでやればこわくない〜」 - 八神 翔太 様

  • テーマ
    • やれるひとがやれることをやれるように
    • 伺かは一人作業が多く限界、現状をどうするか
    • アイシーエスの実際の作業から、活用できるノウハウや考え方を説明する
  • 自己紹介
    • 2002〜2004ごろゴースト作っていた「車掌たんとDJうにゅう」
    • 2002〜2003年 彩伺祭に音楽サークルで参加
    • 2007年ごろから現在のジャンルへ移動(東方)
  • 一人作業の強み
    • やりたいことをやりたいようにできる
    • 世界観を表現できる。総合表現として最適なソリューション
  • 弱み
    • 個人のモチベーションに依存している。
    • 手段と目的が入れ替わる瞬間がある
    • 義務感になったら終わり
    • モチベーション低下防止は息抜きも有効、ゲーセンで遊ぶとかのことも重要
    • ROなど洞窟に行って帰ってこない人もいる。かんこれ? 知らない子ですね。
  • よくある更新停止の例
    • 横連携をし、アドバイス、QAのやりとりができれば強いのだが、
    • 隣の作品はよく見える→自信喪失しやすい
  • どうすればいい?
    • 自分に足りないものを隣の庭からかりてくればいいのでは?
    • しかし…お手伝いしてくれる人に声をかけることがえきるか?
    • やってみたいけどやり方がわからないことがほとんど
    • どのくらいの範囲をお願いすればいいのか?
  • やってみたい人がやればいいじゃない
    • 「範囲を限ってぶんなげる」丸投げ!
    • やれる人が(何かをやってみたい人が)
    • やれることを(自分のスキル・技術を)
    • やれるように(無理なく発揮していただく)
  • ぶんなげるとどうなる?
    • 毎回「やれるひと」が変わる→毎回同じ人・状況で作業出来るとは限らない
    • 毎回「やれること」が変わる→同じスキルがそろっているとは限らない
    • 人にお願いする→相手の状況・考え方がある
  • 制作モチベーション維持のためには
    • マイルストーンの設定
    • いつまでに何をどこまで終わらせる?
  • 制作インフラの構築・運用
    • 制作作業を共有できるようにする→相互フォロー
  • 遅れたときの対処
    • こびとさん(プロジェクトマネージャー)の必要性
  • 制作管理
    • 制作管理のリソース不足「やれるひと」が実はできないひとだった
    • スキル不足を補う人が必要→「実際にやっていただいたら、あれ?」ということはある
    • 制作管理ができる人が必要。バラバラに動いたらまとまらない。プロジェクトマネージャー。
    • だが、プロジェクトマネージャーは仕事っぽい。→「中の人」がお出ましになる
  • 「那珂の人」をつくる
    • スキル:やろうとすれば関連タスクを一人ですべてやることができる
    • 制作管理:全体を統括し、必ず発生する「ブレ」を「活用できる」人
    • 創作ではブレは面白くなる要素(ex;女性キャラのCVに男性が応募してきた!)
  • (例)シェル作成・ゴースト構築・トーク作成
    • マイルストーン:一ヶ月後ゴースト公開
    • いつまでに?
      • シェル:速いほうがいい
      • 構築:シェル確定後速いほうが言い
      • トーク作成:公開ぎりぎりまでやった方が良い
    • 流れ
      • 途中からシェル作業者がトーク作成に合流
      • 構築担当者もトーク作成に合流
      • 後半になればなるほどスピードアップ!?
  • 実際の制作例
    • 2013夏「ファンタムクイズ」
    • スタッフ4名、キャスト12名
    • 制作の方針、手順、「システム」
  • やろうと思えばすべて自力構築が可能
    • 月額2000円程度、最低限のサーバ知識は必要
  • なぜシステム化をするのか
    • 制作中に余計なことを考えたくない
    • 余計なことを考えると能に余裕がなくなる→進まなくなる→面白くない→>轟沈<
  • システムに任せられる部分は任せる
    • 制作の本質のみに専念できる環境を作る
    • 徹底したシステム化は心理的にも余裕ができる。
      • 人間の同時進行タスクは3まで、記憶量は同時に7まで。
      • 記録を残すことで次の改善につながる。

https://pbs.twimg.com/media/BYICceNCcAAKCRd.jpg

  • システムの内部(写真)

https://pbs.twimg.com/media/BYICwRACcAAiuKU.jpg

  • 実際のやりとり
    • 声優さんとのやりとり:
    • 台本制作の場面:Reedmine+Skype、Redmine+Subversion
  • まとめ
    • 多人数の制作はおもしろい! 面白いことを伝えていくのが創作
    • より多くの人に制作に携わってもらうことで、おもしろさ・楽しさを伝えていくのが当サークルの役割
      • もともと「何か」は「広める」がテーマ!
  • 質疑
    • OTRSって入れやすい?
      • 入れにくいです。perl環境前提。日本語対応が甘い。
    • タスク管理はGoogle Sitesで出来るのか?
      • 結局スプレッドシート頼み。
      • →Google Sitesで最低限のことはできる。
      • 大規模にやるときに「誰に連絡をとったか」を管理したいので、Redmineでシステムを組んだ。
    • 今、個人のタスクはGoogleタスクに置いてる。まわりのタスクは、、グループのタスクは、、と広がっていくと、自分のやることは何だかわからなくなる。最終的には「統合タスク管理インターフェイス」を作ることになる。作ろうかと考えている。
    • リーダーが悩む点として、メンバーのおしりたたく必要が出てくる。リーダーとしてメンバーの進捗管理のコツを知りたい
      • 信頼感しかない。「この仕事は〜だから何日が締め切りなんだ」と説明することが大事。Skypeに常駐するなどしてコミュニケーションを密に取る。ただ叩かないといけない。ex「人変えるよ」
    • デイリー・ウィークリーで進捗管理しているのか?
      • スタッフ間はSkypeで。声優さんなどの応募系の方は「何日までに出てこなければ変える」とドライに
    • 進捗どうでしょう?
      • ダメです。
    • 複数人で台本を制作すると、書いた人の間で口調・主題・状況などの食い違いが発生すると思うが?
      • みんなで読み合わせて修正する。
    • 多人数でやっていると声の大きい人が権力を握ったりしないか?
      • 距離感は気をつけている。近づきすぎる離れすぎず、というバランス感覚が大事。長い時間をかけて醸成する必要がある。

「ゴースト間の交流について 〜暦にしき宣伝添え〜」 - もっしょくし 様

  • テーマ
    • ゴースト同士の「絡み」
      • 複数ゴー0スト間で成立するしかけ全般(コミュケート、切替反応…)
      • 総じて最近見かけなくなった
      • ソロゴ、設定・世界観重視が増えてきた?
    • 絡みに使える「道具」はかなり増えている。SSP拡張機能が強化されている
    • そういう機能を紹介します!
  • おことわり
    • SSP上で動作させる前提
    • いくつか暦にしきの宣伝します
    • 関連するいくつかのテーマはあえて無視
      • ゴースト間設定のすりあわせの問題
      • 「交流」のメリット・デメリットの問題 ・・・今回はパス!
    • あくまで手法の紹介のみに絞った発表
  • ながれ
    • よく知られた手法のおさらい「コミュニケート」「railseother」「切替反応」
    • 新しい手法「呼び出し反応」「OnOther系」
  • よく知られた手法:コミュニケート
    • ゴースト間の絡みといえば代表的存在
    • 「暦にしき」は乱読にしきのコミュニケートを利用sちあきのウニ対応
  • よく知られた手法:raiseother
    • 最近メジャーになってきた?
    • 「奏でる日常の音色」さんの「お茶会」
  • ここまでは先行発表あり(うかべん横浜#1)
  • コミュニケートとraiseother
    • どちらも似ている=他のゴーストにSHIORIイベントを発生させる仕組み
    • SHIORIイベントとは?=(おおざっぱに言えば)ゴーストがしゃべれるタイミング(いわゆるイベントドリブン)
      • ex.マウスがクリックされた、1秒が経過した、など
      • 「イベント」を発生させてやるのは本来SSP本体の仕事。referencceという付属情報もついてくる
    • 相違点1:発生するSHIORIイベントが違う
      • コミュニケート:OnCommunicate
      • raiseother:「任意名のSHIORI Event」\![raiseother,対象,【任意名】,ref0,ref1,...]
    • 相違点2:対象
      • コミュニケート:一度に一人まで
      • raiseother:その場にいるすべてのゴーストに投げられる _SYSTEM_ALL_GHOST_
    • 相違点3:reference
      • どちらも基本的に好きな中身を相手に渡せるが、コミュニケートは「スクリプト全文が勝手にreference2に入ってくれる」ので、使い方によってはraiseotherより便利(特化している)
    • 以上に気をつければ割といっしょ
  • よく知られた手法:切替反応
    • 現在でも比較的生き残っている手法(手軽さが理由か?)
      • 相手にことわりを入れない、投げっぱなしの更新が可能
      • コミュニケートやraiseotherのように相手に暗に情報を伝えるにはコツがいる(後述)
  • ここから新しい手法の説明
  • 呼び出し反応「OnGhostCalling」「OnGhostCalled」
    • 切替反応の「OnGhostChanging」「OnGhostChanged」に対応
    • 切替反応と同じようなことができる、そのままコミュニケート等に派生させることができる
      • OnGhostCallxxxと違い、呼び出した側が終了しないため
    • 「OnGhostCallComplete」というタイミング機能もある。(トーク終了の合図)
  • 暦にしきに機能あり!(デモ)
    • \![call,ghost,暦にしき]で暦にしきを呼び出すとき、トークに特定の文字列「明日の予定全て」などが含まれていると、その内容を喋りながら起動する
    • トークに特定の文字列を表示したくない場合、「\e」の後に文字列をつければOK。
    • \eの後はトークとしては有効ではないが、スクリプトとしては有効なため、「トークに表示させずに情報を伝える」という技が使える
  • OnOther系イベント
    • 他のゴーストの状態を監視できてしまうイベント。色々な種類がある
      • とてもヤンデレと相性がいい(ex. 耶美、奏、etc..)
    • 起動、終了、サーフェス変更、、などいろいろ取れる
    • やれることのポテンシャルはあると思うが、結構使い勝手にはクセがある
    • OnOtherGhostTalk:オーナードローメニュー操作など、広範囲のイベントが流れ込んでくる
    • OnOtherOverlap:他のゴースト同士が重なっている情報が流れてくるが、referenceの形が独特。
      • sakura名/ID番号-sakura名/ID番号 的なものが流れてくる
      • 里々の自動計算仕様: 54/0 → ゼロ除算エラー! >轟沈<
      • 必ず文字列加工が必要になる。→里々では実装が難しい >轟沈<
  • 関連する手法
    • 切替反応やコミュニケートをフラグにする
      • ゴースト内のトークだが、切替反応やコミュニケートがあって始めて見られるゴースト
      • 同時に立っているゴーストが誰かによってトークが発現する
      • 暦にしきで多用
    • installedghostnameの内容も見て他のゴーストへの切替を勧める、など
    • →(一部)里々の情報取得変数でも利用できる
    • プロパティシステム
      • 他のゴーストのsakura名、パス、などを取得することができる
    • データ読み
      • (yayaでは)相手のゴーストのパスがわかれば全てのテキストを読める
      • あんまり行儀がよくない方法なので扱い注意。ウイルス的挙動すら可能。
      • mopでも各ゴーストのmopデータを読んでいる
  • デモ(こわい)
  • まとめ
    • 絡み方にも色々ある
      • 性的なコンテンツと動的なコンテンツ
      • 対応してくれるゴーストが増えればどこまでも広がっていく
    • 投げっぱなし? 打ち合わせ必要? いろいろな手法がある
    • 「情報取得」が多様な絡み方を考える鍵
    • 取得できる情報
      • 積極的に提供される譲歩(OnOther〜系のreferenceなど)
  • 今回の本当の主張
    • 手段を知るべき機会はHowToだけではない(何か目的があって知識を探す、だけではない)
    • 何もやりたいことがなくても、里々wikiとかを流し見するとおもしろいネタが見つかるかも!
  • デモゴーストはうかべんサイトで公開予定
  • 質疑
    • OnOtherGhostTalk(他のゴーストがトークしたときに発生)などを組むときに使えるサンプルゴーストはないかな?
      • やりたいことが違うと取得すべき情報が全然違ってくる。難しい。今悩んでる。
      • 丸投げしましょう!(ぽ)
      • やれる人に投げるのも手ですね
    • OnOtherOverlapのデモで、The handを思い出した。
      • The handは独自機能を実装しているが、今はベースウェア機能でもできる時代!

「ゴーストの作成とその後のこと 〜持続可能な開発の実現を目指して〜」 - みゆ様

  • 自己紹介
    • 3年目のゴーストマスター、学生
    • ソロゴ4隊、合作ゴースト1隊、トーク寄与 などなど
  • はなすこと
    • 里々を使ったゴースト制作のsわりからその先
  • 里々を用いたゴーストの作り方
    • 最初はテンプレゴーストの利用をおすすめ、とくに「Rポストと狛犬」
      • トークの改変をするだけで一通り機能のそろったゴーストが作れる
      • 多くの里々ゴーストが採用しているので、情報がたくさんある
      • システム関連がすべてdic02_Event.txtに入れてあるので、当該イベントを探すのが大変
      • 大時代的な機能が残ってる
    • セルフテンプレートゴースト
      • 自分用の複数隊作るときの素体となるゴースト
      • 自分が構築しなおすので、辞書構造や必要なものが理解できる
      • 自分で構造が把握できる。バグ修正のときに有効
      • 最初に作るの面倒
    • 一体目はテンプレゴーストをもとに作り、二体目以降はセルフテンプレゴーストをもとに使うとよい
  • トークの出し方
    • トークのモチーフとなるモノ、コトを設定すると出やすい。三段噺
    • 部屋にあるもの、過去の経験、その日見聞きしたもの、井式をどっかに飛ばしたり(妄想)、ひとにきく
    • 環境づくり(参考文献などをそろえる
    • 図書館や喫茶店、古書店、床に落ちている絶対読まないような本からでもネタは拾える
  • 更新を続ける上で
    • 自分にあった更新頻度を見つける
      • どれくらい更新に時間を割けるか?
      • ゴーストのキャラクターを忘れるのはどれくらい?
    • 普段かける時間
    • トーク=5〜30分、レシピ30〜1時間、合計1時間程度
  • 合作ゴースト
    • スカイプを用いたトーク出し、なりきりチャットに近い
    • お互いの背景が違うのでトークの広がりに幅ができるが、お互いに都合が合う必要あり
    • 分業できるので速くできる。トーク1週間くらい?
  • 困ったときのはなし「トークがでない」
    • トークの出し方を参考に。それでもでないときはPCを閉じて頭を冷やす、寝る。
    • 複数ゴーストを作る。トークを作りやすいゴーストを作る、普段から立てる。
  • 困ったときのはなし「バグがとれない」
  • 困ったときのはなし「モチベーションが維持できない」
    • 3〜4日くらい辞書に触れないようにして休む。それ以上放置するとガチで面倒になる)
    • 他に楽しいことを見つける。(なるべくゴーストのネタになりそうなことで9
    • 無理矢理更新しよう
    • ちょっとしたことでも更新してみよう
  • モチベーションが維持できなくて困ってる人を見かけたら
    • ユーザとして出来ることをして応援してみよう
    • ブログなどにコメント
    • うわひょ、など
  • 更新する時間がないとき
    • 大きな更新でなければ案外時間はある
    • ネタを書き留めるモノを常に持ち歩く
    • 本当に時間がないときはやめておこう
  • まとめ
    • これかもよきゴーストライフを!
  • 質疑
    • サンプルゴーストはいつ公開?
      • 触り反応が30個くらいになったら公開! R-13!

2009年7月20日(月) OCAT大阪難波市民学習センターで僕と握手!

午後の部(3) - 特別枠(1時間講演)

15:25 |  午後の部(3) - 特別枠(1時間講演) - げっかんにっき を含むブックマーク  午後の部(3) - 特別枠(1時間講演) - げっかんにっき のブックマークコメント

「Colors Widget からクラウドゴーストを考える」- 芝やん様

  • 自己紹介。現在、大学で2次元に入る研究中
  • アウトライン
    • Colors widget の紹介…説明
    • クラウドコンピューティングとは?
    • 伺かとクラウドコンピューティング
  • COLORS Widget とは
    • Web上から簡単にウィジェットを作成するサービス。COLORSで作成したシェルを利用し、辞書もCOLORSと互換
    • 専用のランタイム上で実行され、Silverlight 2 を使っているため Win と Mac で動作可能
  • Widget の仕組み
    • サーバサイド:Webインタフェース提供、サーフェス・辞書管理
    • クライアントサイド:ミニかわりエンジン、簡易さくらスクリプトエンジン
    • (システム図)
  • Widget の特徴
    • Win と Macの両方で動作する(Microsoft公式サポート)
    • 作成から公開までブラウザで完結する
      • 公開サーバ不要(COLORS環境そのものはWinですが)
    • 伺かとの互換性アリ
      • トークはさくらスクリプト、栞はかわりのサブセットとなっている
  • ウィジェットからゴーストへ
    • ウィジェットはWebページにしか設置できない
    • じゃあゴーストを作れるようにすればいいんだ!

  • ゴーストをクラウドへ
    • サーバがゴーストデータをすべて保持する(辞書・サーフェス・各種定義など)
    • 数が多くなると1台のサーバでは処理が追いつかなくなる
      • サーバのストレージは有限
    • これはクラウド向けではないか?
  • クラウドとは
    • インターネットを基本とした、新しい形のコンピュータの使い方
      • インターネット接続環境は必須
    • インターネット上のサーバにデータを預けたり(ゴースト作成)、利用(ダウンロード)したりする
  • 主なクラウドの例
    • Amazon(Amazon Web Services)
    • Google (Google App Engine)
    • Microsoft (Windows Azure)
  • クラウドの利点
    • 安定したサーバを低価格で利用できる
      • 前述のデータセンターより信頼度の高いレンタルサーバはほぼない
      • 使った分だけ課金される
    • 負荷に合わせてリソースを増減できる
      • 安定してサービスを提供できる、障害対策もばっちり(サーバ落ちるとシステムそのものが使えなくなるため、重要)
    • 大容量ストレージが使える(Blob=バイナリデータ、Queue、Table が使える)
  • 安定なサービスとは?
    • ハードウェアとソフトウェアの両方の問題に対処する必要がある。
    • 常に動いているのが当たり前と思うな!(特に個人管理のサーバ)

  • 休憩10分

  • 伺かの難点(ユーザ視点)
    • ゴーストが多すぎて探すのが大変
      • センター・タウンがあるがわかりにくい。検索タグが更新されない。
    • インストールが必要
      • CROW のゴーストマネージャみたいにできれば便利
    • セーブデータが共有されない
      • 2台以上のPCを持っているとセーブデータがばらばらになってしまう
      • USBメモリに入れておけばいいが、アクセスが多いと消えてしまう危険も…
  • 伺かの難点(開発者視点)
    • 定義ファイルの処理が多い
      • ゴースト・シェル・サーフェスなど、手書きだとミスも多くわかりにくい
      • 公式の仕様書がない! スペルミスのまま登録されている!
      • CROW&SSPリファレンスが一番の近道か?
    • 公開するにはサーバを借りる必要がある
      • 無料のサービスは多いが、手軽とはいえない
    • ネットワーク更新に対応するのが大変
      • 専用の定義ファイル(updates2.dau)を作成したりとか…
      • ゴーストをはじめて作る人にとっては五里霧中である
  • 伺かとクラウド
    • 伺かとクラウドを結びつける
      • 開発・更新・配布をブラウザから行う。さらにバージョン管理も行う(Dropboxでも使える(ぽなさん談))
      • セーブデータなどのユーザ固有の情報も同時に管理する(俺の嫁は一人!)
    • クラウドゴーストと命名

  • クラウドゴーストとは?
    • クラウドサービス上でホスティングされるゴースト
      • ゴーストをユニーク(唯一)なものとして扱う。
      • 実際にデスクトップで立つゴーストはクラウド上のインスタンスのコピー
      • インスタンスはユーザーごとに1つだけ割り当てられる
      • ユーザー毎にゴーストインスタンスを作成。同一ユーザの異なるPCでは同じインスタンスがロードされる。


  • 途中質問タイム
    • ゴースト削除の対応は?
      • 削除フラグを立てる?削除レベルをいくつも作るべきか?
    • ゴーストをある特定のバージョンで保持したい場合は?
      • ユーザ側の考え次第だが、特定のバージョンをダウンロードできるようにする?
  • クラウドかが実現すれば
    • COLORS でゴースト作成の敷居は大幅に下がったる予定
      • クラウド化でゴースト公開の敷居を大幅に下げることが出来る
      • 今までと違う層へのアプローチが容易に
    • ゴースト以外の形態として公開もできる
      • サーバがすべてのデータを持っているからできる技
      • ウィジェット化も容易(ブラウザで実行、携帯電話上、Windows Mobile、etc.)
  • 今後の展望
    • クラウドゴーストホスティングサービス
      • Microsoft C# + ASP.NET + Silverlight 3
      • Cocoa
    • 開発目標
      • COLORS 正式版と同じくらいの時期に(=一周年には間に合わせます(さとーさん談))
    • Windows Azure 上で動作するサービス
      • ゴーストの開発・更新・ホスティング、セーブデータリポジトリ
    • SSPで動作させるためのプラグイン
      • 栞ラッパーかプラグインの形で提供(仕様書出せばコーディングしてくれるらしい)
    • ブログパーツとして実行するランタイム
      • Silverlight 3
    • Cocoaで書かれたほにゃらら(COLORS が 2.0になるごろ(さとーさん談))
  • 実現可能性は
    • 技術的には全く不可能ではない
      • すでにCOLORS Widget で実現している
      • シェルエディタ、ウィジェットランタイムもプロトタイプは完成済み
    • 何が難しい?
      • 時間が足りない
      • サーバは無料ではない(課金?)広告収入などでなんとか…
  • 何ができるようになるの?
    • 複数PCでゴーストセーブデータの共有、バックアップ
    • 低コストでゴーストの公開が可能
      • COLORS と OpenID があれば誰でも。フリーシェルでも何でも使える
    • ゴーストデータの自動同期(流れるように同期!)
      • ネットワーク更新よりも一歩進んだ機能
  • 注意すべき点
    • すでにゴーストを公開している人向けではない?
      • 公開してる人は使わなくても公開できるよね!
      • 乗り換えるにはそれなりに手間がかかるよね!
    • 外部へのアプローチ(広める!)
  • クラウド化を進める理由
    • 今までの不満を部分的に解消することが出来る
    • 開発・公開の敷居を下げることができる
      • これまで考慮されなかった部分で、ツール使えば手間は1/3くらいに
    • 新しいユーザ・開発者を引き込むことができるはず
    • いつでもどこでも同じゴースト
      • ゴーストの実行に必要なデータはすべてクラウドサーバが保持するので環境に依存せずに同じゴーストを使える
      • ランタイム作るの大変よね…
  • Runtime?
    • まともなランタイムはSSPのみ。これでは価値は半減以下
    • スマートフォン向けは欲しい(iPhone/iPod touchはOSの制限があるのでだめ(シングルタスク))
      • 酢酸さん「仕様書くれたらやる」芝やんさん「書く☆」
  • 質疑応答
    • (畝傍)追加シェルは?
      • 仕様は考えている。できればSSPに丸投げしたい。

生駒精華生駒精華 2009/07/22 04:25 その個人的疑問に多少なりともお答えします。
なんだかんだで十数年、創作活動らしきものをしてきているわけですが、その当時知らなかったこの「Mary Sue」の概念に抵触して、わたしが常日頃から引っかかっては筆を折ってきたわけですね。そこで、まあ、これから育っていく後輩の文章書きの各位に、同じ轍を踏んでもらいたくない、という念もあり、加えて自戒と自嘲の意味も込めて、腹かっ捌いて恥を曝しに行った…まあ、そんな感じです。
あのプレゼンで、1人でも多く、1秒でも早く、後に続く作者の卵の方々に、いわゆる中2キャラクタからの脱却をしてもらえれば、それに勝る幸せはありません。
……とまあ、そんなわけでした。

hinoharuhinoharu 2009/07/23 10:15 ご自身の経験からでしたか。ただ、Mary Sue の概念が気になり始めるのは、大なり小なりの世界観を作り上げたうえで、その中のキャラクターが暴れ始めた段階以降でしょうから、ある程度のレベルまで創作を進めないとそもそもこういう問題は起きないような気がします。
そういう意味で、Mary Sue 問題に悩む人はきちんと創作をしているんだなというふうに感じますね。
(どこだかわからない世界で超人がなんとなく俺すげぇ!って言ってるだけなら、壊れる世界観も何もないわけですし…)

638158
この日記のはてなブックマーク数