Hatena::ブログ(Diary)

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

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


本体サイト

ゴーストダウンロード

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

2008年11月3日(月) うかべん実況隊

うかべん大阪#4

| 10:52 |  うかべん大阪#4を含むブックマーク  うかべん大阪#4のブックマークコメント

本日、大阪・なんばにて伺的ソフトウェア勉強会(うかべん)大阪 #4 が開かれています。

幸い、現地入りすることができましたので、今日のエントリで内容を速報中継することにしてみました。


【この記事の内容について】

この記事は、私がSpeakerの皆さんの発表を聞き、自分なりに理解し、かみ砕いて書き下し、感想を付け加えたものです。

(各発表の末尾にある項目「感想」は、私自身の意見・感想です。)

とくに私の理解力不足により、Speakerの皆さんが発表された内容と相違している可能性があります。

誤りや問題点がありましたら、コメント・拍手等でご指摘ください。


  • (11/4 9:20)一部追記および修正しました。
  • (11/4 10:07)【この記事の内容について】を追記しました。
  • (11/4 11:47)感想等を追記しました。
  • (11/5 19:20)講演者ご本人の補足により、記事を修正しました。
  • (11/5 20:05)講演者ご本人の日記の内容に基づいて、記事を修正しました。
  • (11/11 13:00)恥ずかしいスペルミスを修正しました。

重くなってきたので折りたたみます。本文はこちらから。


伺かをフロントエンドに使ってみたら』/早坂千尋様

  • 「伺か」をコマンドラインアプリケーションの情報入出力インタフェース(フロントエンド)に使うことについて
    • 伺かプラットフォームは「入力」「出力」が揃っているため、コマンドラインソフトウェアのフロントエンド(入出力インタフェース)に使うことができるのではないか。
    • デモンストレーション。SETI@home(地球外生命体探索プロジェクト)の計算進行状況を取得し、表示するゴーストを起動(黒姉シェル)。
    • 仕組みの解説。setimon.dllというSAORI(伺かゴースト用外部ライブラリ)を使用。setimon.dllはSETI@Homeクライアントが吐き出すステータスファイルを解析し、SHIORI(nasino.dll)に投げ渡す役割をする。
    • SETI@Homeクライアントの吐くステータスファイルを勝手に読むので、実装としてはあまり綺麗ではないとのこと。
    • このシステムの欠点は、SETI@HomeはCPUパワーを食えるだけ食うので、進行具合をモニタするためだけに伺かを起動するのは割に合わなかった。(2000年代当初の話)
    • 解決のために:SSTPでネットワーク越しにモニタればよい。SETI計算用のマシンでは、SSTPを投げる小さなプログラムを動かすだけでよい。また、複数台で計算をおこなう際は、情報を一箇所にまとめることができ、さらに便利。
    • なぜこのようなことを考えたのか:理想のコンピュータは、ユーザが寝ている間に勝手に仕事をしてくれるのが理想。さまざまなアプリケーションがバックグラウンドでタスクを実施し、伺かプラットフォームに報告し、「ゴーストが」ユーザに結果や経過をまとめて報告してくれる、ということをしたかった。
    • 昔はSSTPで情報を投げるプログラムが流行っていたんだけど、今はどうよ・・・?
  • フィジカルインタフェース(物理的な情報入出力手法)と伺か
    • ノートPCを傾けるとうにゅうが下に滑っていくデモンストレーション。
    • ThinkPadの内蔵センサをSAORIで読み取る。メーカー純正のsensor.dllをSAORIインタフェースに合うように改修メーカー純正のsensor.dllを操作するC++クラスがネットで公開されているので、それをSAORIインタフェースに合うように改修して使用。
    • 問題点と課題は?
      • OnSecondChangeを使用しているので、f=1Hz以下。
      • 地震を検出したい
      • 操作者の動作を検出したい
      • SHIORIイベントトリガで情報をやりとりするのでは限界があるので、別にモニタ用のdllかプログラムが必要?
    • この考えは「フィジカルインタフェース」というもの。いわゆる物理的媒体による電脳空間への干渉。それを実現するのに伺かベースウェアは使いやすい!
    • 最終的には実体化したい!
    • ニコニコ技術部でも同様の発表を実施。伺かインタフェース自体への反応より、ノートPCの加速度センサを使うということに注目が集まった。
  • 感想
    • PCを傾けるとうにゅうが滑っていくデモンストレーションは面白かったです。新しいiPodにも似たような機能のゲームがあったりしますが、それが(ある特定の機種に限られるにせよ)ノートPCだけで実現できるのはとても興味深く、電車の加減速度を計測してみたいと思いました。
    • PCで簡単に使える外部機器として、WebカメラやGPSユニットがありますが、たとえばGPS情報をゴーストに喋らせる、などは比較的簡単に実装可能な気がします。座標情報と地名の変換テーブル(もしくは、ウェブ上の変換API)を用意すれば、カーナビの女の子みたいなものが出来るかも・・・?

『やめといた方が良い栞の作り方』/駅長様

  • 【テーマ】 SHIORIを作ろうと思ったときにぶちあたる壁のあれこれ、について。
    • SHIORIを作るのは言語処理専門家かつ理系のマゾではないと難しい!
    • SHIORIとは?→伺かプラットフォームで、本体(SSPなど)の要求に応じて、適切な答を返すプログラム。(やりとりは規定されたフォーマットの文字列でおこなわれる)
    • 通常は「使う」ものであって、「作る」ものではないが、今回は「作る」お話。
  • どこいつ文章を作るAIを実現するための一手法、「ルールエンジン」
    • 「SHIORIとは、辞書管理である」=辞書をいかに管理しやすく記述効率のよいものにするかがカギ
    • 世の中の複雑な事象を管理する手法として、「ルール」を考える。ルールは、「フラグ」と、フラグが立つことで起こる「イベント」から成る。
      • LHS(Left Hand Side)=条件、フラグ。「Handに触られた」
      • RHS(Right Hand Side)=行動、イベント。「叫ぶ」
      • LHSとRHSの組み合わせ=ルール。
      • すべてのルールの集合を「ナレッジベース」(知識の集合)と呼ぶ。ルールによって記述される世界の全て。
      • 発火=ルールのフラグが成立しイベントが発動すること。
      • 連鎖=ルールの発火により新たなフラグが立ち、別のルールが発火すること。
    • ルールエンジンの例:フラグ「投手がすっぽぬけ球を投げる」+フラグ「ランナーが一塁にいる」+フラグ「ライトの守備はイチロー」→最終イベント「レーザービームで人類滅亡」
      • 最初に単発的なフラグがいくつか成立することで、いくつかの連鎖を経て、最終的なイベント(結果)が生じる。(ナレッジベースにランダム要素が含まれていない場合、「世界」の全てを決定的に記述しているルールに従って状態が推移していくため、同じ初期条件からは同じ結果が決定的に生じることになる。)
    • このような思考を通常のプログラム言語で表現することは困難。(条件文の嵐になるうえ、フラグ数の累乗で組み合わせが増えるため)
    • それを簡単に実現できる「推論エンジン」(ルールエンジン)というものがある。
  • ルールエンジン CLIPS(C Language Integrated Production System)の紹介
    • 当初NASAが開発、パブリックドメインとして開発続行中。文法はほぼLISPに似る。
    • 連鎖中枢「Reteアルゴリズム」の元祖。
      • 前向き連鎖(事実駆動、起こる順番がフラグ→イベントの順)
      • ルールが競合(複数のイベント発生条件が同時に成立)したとき、イベントが発動する順番などを決められる。これにより怪しい連鎖反応も実現可能に。
      • UTF-8対応。

(コマンドプロンプトによるイベント連鎖のデモ)

    • ゴーストによるデモ。
  • まとめ
    • 前向き連鎖(事実駆動)は、フラグ→イベントという流れを一本追っていけば結論にたどりつくため、動作が速い。ゲームやゴースト向け。
    • 後向き連鎖(仮設駆動)というものもある。結果から、それの成り立つ条件を探す。計算量は莫大。結論(ゲームでいえば、勝利条件)から現状までの流れを求めるような用途に向く。詰め将棋や、オチを最初に考えてネタを作る芸人のようなもの。
    • 前向き連鎖のナレッジベースはゴースト向けである。CLIPSは比較的カベが低いので、興味のある人は試してみてほしい。.netならWF付属のエンジンが使えそう。
  • 質疑応答
    • SAORI向きではない。SAORIは一時的に呼ばれるもので、イベント連鎖を延々と続けていくゴーストの動作そのものに適用するにはSHIORIにするしかなさそう。
    • 動的にルールを追加することも可能。(runコマンドを実行した段階の「世界」の中でイベントが連鎖していくため、runコマンドを打ち直せばOK)
    • ルールエンジンには、「ステップ実行(どのようにイベントが連鎖するかを参照する)」「トレース(なぜこのフラグが立ったかを参照する)」機能がついており、デバッグが可能。
    • CLIPSにおいては厳密にいえばイベントは同時に発生しないが、実装によっては同時(並列)にイベントが発生・進行していると「見なす」ことができるので、ニューロコンピューティング的な思考も可能になるかもしれない。
  • 感想
    • ルールエンジンの動作原理は単純なので、既存のSHIORI(文など)でエミュレートすることもできそうな感触。(動作速度を考えなければですが。文の関数として実装するのも面白そう・・・)
    • ナレッジベースを作る作業は非常に網羅的であることを要求されるため、かなり大変ではないかと感じます。将棋ゲームの話が出てきましたが、現在進行形で対局中のある局面に関しては最善手を指すことができても、「すべての局面における最善手を網羅する」となるととんでもないことになってしまいます。現実的にそれは無理なので、プログラマには「すべての局面」を「いくつかの特徴的な局面」に抽象化する作業が要求されるでしょう。
    • とはいえ、「ルール」という断片だけを用意してやって、いざイベントが発火し連鎖が起こり(予想もしなかった素晴らしい)結果が生まれたら、それは至福の時だと思います。私、そういうのが大好きなんです。

昼休み(12:15〜13:00)

  • OCAT地下1階のサイゼリアでピッツァとドリアをいただきました。チーズうめえ!

ライトニングトーク『ゴーストなんとか機的何か』/ケノ様

  • キャラクターなんとか機をゴースト上で実現する試み。
    • ゴーストの(SHIORIが出す)メニュー上で、髪、服などのパーツを選択・色替えをし、追加シェルの作成までおこなうことができる。
    • 画像ファイルをあとから追加することも可能。
    • 将来はゴーストアーカイブを作成できるところまで持っていきたい、とのこと。
    • ゴーストなんとか機のデモンストレーション
      • 実際に、Emily/Phase4のデフォルトシェルとそっくりなちびシェルを作成。
      • 製作時間3分。(アセンブルにかかった時間。Emily/Phase4のシェル風パーツは事前に製作してあった)

(左が Emily/Phase4 デフォルトシェル、右が今回のトーク中に作成した「追加シェル」)

  • 感想
    • 髪、目からはじまり、各所のパーツの色まで細かく指定できるツワモノ仕様でした。(カラーピッカーまで出る!)ライトニングトークの短い枠での発表でしたが、もっと長い枠でじっくり見てみたかったです。ぜひ触ってみたいと思います。

ライトニングトーク『なでしこ勉強会』/しらたま様

  • 来週11月9日(日)13:30〜、大阪・千里公民館にてなでしこ勉強会をおこないます。
    • なでしこ作者の「なでしこの将来」展望の発表
    • なでしことデータベースとの連携について
    • しらたまさん「なでしこで配列変数」
    • あと10名ほど参加募集中。よろしく!
  • 感想
    • こぢんまりとした会場での勉強会ということのようです。言語作者さんと触れ合えるチャンスですね。

『シェル@SVGのはなし』/しお様

  • 【テーマ】 ベクタ形式の画像(SVG画像)をゴーストのシェルに使ってみませんか?
    • ※11/3現在、SVG画像をサポートしているベースウェアはありません。が・・・
  • SVG(Scalable Vector Graphics)=拡大縮小が自由なベクタ形式。(ベジェ画像、ベクタ画像)
    • SVGを編集できるソフトウェア:IllustratorInkscapeなど。(PhotoshopGIMPでも読めるが問題が多い)
    • ベジェ画像の得意なこと・苦手なこと
      • 曲線の形を計算式で生成するため、拡大縮小が自由。さまざまな大きさのデスクトップに登場する必要があるゴーストにとって絶大なアドバンテージになりうる。
      • 単純な形状の変更も簡単。
      • アンカーポイントで、線の位置や曲がり具合を指定するので、作成に手間がかかる。
      • 色塗りの自由度が低い。(複雑なグラデーションなどが不得手)
    • SVGファイルにラスタ画像(通常の画像)を埋め込むこともできるが、拡大縮小が自由である利点が消えるうえに、ファイルサイズが巨大になるために勧めない。
    • ベクタデータの編集デモンストレーション

うにゅうの角を伸ばしてみたところ。このような変形はお手のもの。

  • なんということでしょう、SVG形式のシェルが近日中にSSPで読めるようになるということです。

  • 感想
    • SVG形式のシェルは、現在よくあるような一枚絵のサーフェスの代替としての手法に加えて、ベジェ画像の特性を生かした新しいゴーストのジャンルを作れるような気がします。前述のようにベジェ画像は基本的に計算で形を生成するので、ゴースト側からオンザフライで形状を生成して表示する・・・というような野望も。

『梨の季節』/さとー様

  • 【テーマ】 伺か用SHIORI「華和梨」を使う上での、様々なノウハウについて。
  • エディタを選ぼう!
    • ゴーストのデータは基本的にテキストファイルである。
    • Notepadで編集せず、キーワード色分け機能などのある高機能エディタを使うとよい。編集効率が段違いに良くなる。
    • エディタのカッコ対応チェック機能は必須。華和梨向けにカスタマイズするなら、Sakura Editor+おば9氏の華和梨キーワード色分け設定の組み合わせが便利*1
  • 華和梨の書き出したログを読もう!
    • 華和梨はエラー情報をログファイルに出す。
    • 華和梨のログを日本語にする方法
      • kawari.kisに「rccharset Shift JIS;」と加えると、エラーの文字列の大部分が日本語になる。
    • 華和梨のログから読み取れる情報って何?
      • ダブルクォーテーションの閉じ忘れ
      • カッコの閉じ忘れ
      • 存在しないコマンド/エントリを呼んでいる
    • エラーメッセージの詳細については華和梨同梱の「エラーメッセージ一覧」を参照。
  • ツールログファイルを楽に見よう!
    • 「tail」というツールを使うと、専用ログツールのようにリアルタイムでログ表示を参照できる。
    • tailツールの画面表示例

Tail for Win32 を使ったデバッグの様子


  • 情報をログファイルに積極的に書き出そう!
    • 華和梨で、ゴースト側からログに情報を(能動的に)書き出すコマンド「logprint」
      • ある条件下における変数の内容を知りたいときなどに使える
      • バルーン内にデバッグ情報を書き出す人が多いが、リリースミスでユーザにもデバッグ情報を見られる可能性があるし、「\」文字のエスケープの手間がある
      • 仕様上、Notifyイベント時はそもそもバルーンが出ないので、ログファイルへの出力が必須。
  • 「幸水」+「ログ」=最強デバッグ環境
    • 華和梨デバッグ環境「幸水」はKISインタプリタ機能があるため、プログラムの断片を突っ込んで実行させることができる。ステップ実行も可能
    • 「幸水」のデモンストレーション
  • まとめ
    • プログラムは失敗することで上達するのが常道。そのためのツールがログである
    • 華和梨で楽しくデバッグしてください。(太字筆者)
  • 感想
    • 普段はなかなか目にしない、ゴースト作成の裏側「デバッグ」に主眼をおいた講演。華和梨という特定のプラットフォーム上の話ではありましたが、どの栞でも共通して直面する面倒さをどうやって回避するかという、たいへん役に立つ話でした。(でもやっぱり「YAYAではこの機能はどうやれば・・・」って考えてしまいます。さとーさんごめんなさい)

『Webカメラでゴーストとお話』/酔狂様

  • 【テーマ】 ディスプレイ上のゴーストに、ユーザが直接触ったり叩いたりできるインタフェースを作れないか?(前回のうかべん横浜#2の話題の続編となります)
  • AR(Augumented Reality)=カメラで三次元空間を撮影し、ディスプレイ上に表示し、バーチャルなデータ(ゴーストや3Dキャラクターなど)と合成する。
    • でも人間が直接に触ることはできない
  • 前回の提案=ウェブカメラをディスプレイ周辺に向け、「ユーザの動きを撮影」
    • ユーザが直接、ゴーストの支配空間に対してアクセスすることができる(ユーザがディスプレイに手を近づけるとゴーストが逃げる、など)
    • 今回、実際にユーザの手をウェブカメラで検出してみた。
  • 前回(うかべん横浜#2)から進んだこと
    • カメラの姿勢推定が正確になった
    • 背景からオブジェクトを切り出す精度が上がった
    • 名前が決まった「Ruchia」(語源:アイマス)
  • Ruchiaの基本アルゴリズム

一台のカメラ映像から、物体(この場合は手)の三次元位置(タテ・ヨコ・奥行き)を求める方法


解説を聞いて難しいと感じた部分(アルゴリズム)を漫画にしてみました。

    • ディスプレイと指の接触判定は、ユーザに接触を宣言させることでキャリブレーションをおこなう。
    • ※2D・3D上の垂線、交点を求められる演算ライブラリを知っている人は情報が欲しいそうです。
  • ウェブカメラで撮影したディスプレイ周辺の映像から、まさに今ゴーストに触ろうとしているユーザの手を切り出す方法は?
    • 偏光シートを使い、ノートPCの液晶モニタを(画面に何が写っているかにかかわらず)真っ黒にすることができるので、手のリージョン(=領域)を切り出すのが容易になる。

(液晶モニタの前に、偏光面が直交する偏光シートを重ねた例。偏光シートそのものは半透明)

  • Ruchiaを使うと何ができる?
    • モノや指がディスプレイの近くにいることがわかる、そのだいたいの場所がわかる
    • モノや指がディスプレイに触った、そのだいたいの場所がわかる
      • ゴーストと乾杯、ゴーストとジャンケン、ゴーストに指をしゃぶらせる、等
  • 次のステップ:物理エンジン
    • 物理エンジンとは物理的な動き(固体、液体などの物質の動きを)エミュレートする
    • 画像をメッシュ化し、格子点に質点を配置し、それぞれの間の拘束条件を設定して物理的な動きをエミュレートする。例:PCを傾けるとうにゅうが坂を転がっていく

  • 質疑応答
    • 必要なカメラの解像度は?
      • 今は30万画素くらいのカメラでもOK。将来は、撮影した画像をシェルに取り込むなどのアクションを想定しているので、その瞬間は高い解像度が必要。
  • 感想
    • 前回のセッションの続き。実際に手の切り出しのデモンストレーションをされていました。照明条件さえ整えば十分「手」のリージョンを切り出すことができそうな感じです。今後は、いかにカメラの前に差し出される「物体」(ここからは、手だけでなく、ワイングラス、カッターナイフなどさまざまなもの)に特化した検出パラメータを作りあげるか、という、ある意味一番キツいカットアンドトライの領域に入っていかれることと思います。いや、楽しみ。

『里々とLispとリーダマクロ』/zick様

  • 【テーマ】里々の辞書をLispのプログラムに変換して実行できないか?
  • そもそも、里々とLispは似ているのか?
    • Lisp(Common Lisp)は汎用のプログラミング言語、里々は単一目的のスクリプト言語
    • 共通点はカッコが沢山出てくること
      • 里々では、((季節)の食べ物)→(秋の食べ物)→サンマ のように、カッコは内側から順に解釈される
      • Lispでも、(defun 食べ物of (季節) if... ) のようにカッコの内側から解釈されていくが、食べ物of (季節) のように「関数」「引数」に分離される。
      • Common Lispではマクロ機能を搭載しているので、里々と全く同じ記法をすることも可能(Lisp最強説
    • カッコの解釈の順番
      • カッコが必ず内側から解釈されるため、if文内の実行文にset命令を入れるときなどに問題が起きる。(先に代入が行われてしまうことになる)
      • Lispでは特殊オペレータなどが先に解釈される
      • 里々にはLispでいうlambda(先行評価でない関数)のような命令がない
    • 結論として、里々とLispは似ているのか?
      • 構文は似ているが、文法が違う。
      • 里々の辞書を、Lispのプログラムに変換できないか?
      • それができれば機械語に変換でき、高速に動作させることができるぞ!
  • 里々からLispへの変換はできるか?
    • 里々特有の記号をLispの命令語に変換し、マクロ展開
    • SHIORIとして動作させる手順、手法は?
      • Lispプロセスとベースウェアを、DLLを介して通信させる。

(里々プログラムをLisp栞で実行するアルゴリズム)


(Lispで実行したウマウマ)

  • オリジナルの里々と、Lisp栞(+Lisp変換した里々スクリプト)で実行速度の比較
    • 【計算式】$計算結果=1+2*3−4÷2+(計算結果)%5
    • 上記の計算式を400回および200回試行し、両試行にかかった時間の差を求める。
    • Lispコンパイラによる最適化の効果が出たと考えられる。その場合、Lispの方が高速なことが示された(里々は毎回全角半角変換が入っているため遅い?)
    • 【計算式】:((季節)の食べ物)が食べたい!
    • 上記の計算式を100回および50回試行し、両試行にかかった時間の差を求める。
      • オリジナル里々:7600usec
      • Lisp(未コンパイル):61800usec
      • Lisp(コンパイル済):16300usec
    • LispではGC(Garbage Collection)に4割ぐらいの時間を食われていた。チューニングが必要。
  • まとめ
    • 里々とLispは構文は似ているが、評価規則は全く異なる
    • Common Lispで読めるように里々のプログラムを書き換えて実行した
      • Lispがコンパイルできる部分については非常に高速。
      • カッコの解釈など、アルゴリズム上の実装のチューニングはまだ足りていない。
    • Lisp化できればマルチプラットフォーム環境化の夢が!(Macでも動く)
  • 質疑応答
    • Lispをインラインスクリプトとして使えるようにすれば最強では?
      • やりたい。
  • 感想
    • トークを書くことの簡単さについては追随を許さない里々と、最強プログラミング環境Lispが緊密に手を結んだら、非常に協力なSHIORIとなるのでは、という期待をかいま見ることができました。最近はラインインタプリタ型の栞が流行していますが、コンパイル可能で高速な栞という選択肢もあるといいですね。

CMタイム

  • 畝傍氏による伺か@Lingrの宣伝。新しい方に来ていただき、話題に新風を吹かせたいとのこと。デバッグをして欲しいときに役にも立つよ! http://www.towano.net/room/ukgk/

『お蔵入り伺かネタを今すぐにサルベージするシンポジウム(OUISS!2008)』/ディスカッション

※以下敬称略

    • (さとー)さて、これまでいろいろな都合によってお蔵入りになったネタを順次挙げていただきます。
    • (さとー)華和梨と里々の融合。トークを里々で書き、やりにくいことを華和梨で書ける環境。
    • (Ponapalt)文にもそういうアイデアはあった。
    • (さとー)ひたすらSF作家の話ばかりをするゴーストがお蔵入りになってる。2001年ごろ、華和梨チームによるサンプルゴーストとして企画された?
    • (畝傍)SFファンを集めてプロジェクトを作ったら?
    • (さとー)SFファンを集めた段階で空中分解のフラグが立ってしまうのでは。
    • (しらたま)ゴーストセンターの登録をする「ゴーストマネージャ(NGM)」の軽量版を作ろうと思いなでしこで作り始めたが、ListViewで作ったら重くなってしまった。また、ゴーストセンターに外部アプリが勝手にアップロードしていいのか?という問題があったので中断。
    • (Ponapalt)管理者さんに連絡取りましょうか?
    • (畝傍)私の環境ではNGMでアップロードできない。
    • カトマンズ)かつて自営サーバでゴーストの古いアーカイブを保管する企画をしたことがあるが、結局途中で倒れてしまった。一番面倒なのが二次配布の可否を調べること。
    • (Ponapalt)人の資源が足りない。
    • (カトマンズ)CCなどの使用許可の話になると大変。ほかに、伺かForgeのような、伺かのコードを保管するサーバを作りたかったが、実現していない。あとMacOS Xで安定して動くベースウェア?
    • (Ponapalt)(困笑)
    • (カトマンズ)Mac環境は無い物づくし。みんなマック買って下さい。芝やん氏によるiTunes4uもいつか掘り返したい。
    • (畝傍)地球上が森林に占拠されている世界で、一人で住む女の子との対話ゴースト。好感度等のフェイズ進行が多く、シェルのパターンも膨大になるうえ、トークが40くらいしか作れなかったのでお蔵入り。
    • (畝傍)トークの自分的最低ライン(60)を越えないネタがたくさんある。
    • (Ponapalt)60でも多いと思う人!(挙手多数)
    • (畝傍)多人数で合作という手もある。私よりもトークを書ける人、がんばって下さい。
    • (一同ツッコミ)
    • (おぞん)伺か界隈入ってから2年。まだ手をつけていないネタが多い。
    • (畝備)実現可能性が低いものは?技術的にとか
    • (おぞん)次の次に公開する予定の制作中ゴーストがコケかけている。
    • (Ponapalt)具体的にどこが問題?
    • (おぞん)データ量が多すぎて扱いきれないこと。具体的には×××なんですけど。
    • (一同)(驚き)
    • (畝傍)そういうのが得意な作者さんに聞いてみるとか?
    • (おぞん)そもそもデータ読み出しの段階で重すぎる。
    • (質問)フェーズが替わるごとにネットワーク更新で別のゴーストにするとか・・・
    • (さとー)専用プラグインを作るとかは?
    • (おぞん)それはやる気です。
    • (さとー)また一つ忘れていたの思い出した。共有変数プラグイン・・・
    • (Ponapalt)キャラクタ間でデータをやり取りしたり保存したりするモノですね。
    • (Ponapalt)駅の黒板形式(誰でもデータを入れられるし、データは古い順に削除される)という形の共有変数を考えたことがある。
    • (航)伺かを始めて間もない。なかなか時間がないが、現在開発中のゴーストで、【これからやりたいことにつき検閲削除】を考えている。
    • (Ponapalt)私はお蔵入りのカタマリだから言わなくていいですね。
    • (一同)(総ツッコミ)
    • (さとー)本体更新!
    • (Ponapalt)(絶句)
  • ここで時間切れにつき終了。
  • 感想
    • 最初、「お蔵入りネタ」というのはちょっと難しいテーマかと思いました。というのは、自分の中でどのアイデアがお蔵入りで、どれはまだ再利用の価値があるのかという線引きが難しいと思ったから。そういう意味では、今回のディスカッションは2つの意味があったと思います。一つは、すでに自分は撤退を決意したネタを公開し、実現可能なスキルやアイデアを持った人に提供するという意味合い。もう一つは、完全に捨てきってはいないネタをよってたかって掘り返し、本人のモチベーション発奮を促す意味合い(例:Ponapalt氏)があったと思います。何回かに一回はこういうコーナーがあると良いかもしれません。

 

*1:私も独自にYAYA用のキーワード色分けルールを作って使用しています。EmEditor向け。EmEditorのFreeバージョンはルールのexportができないので、レジストリファイルになりますが、欲しい方はお問い合わせ下さい。さすがに.regファイルをネットに放置しておく気はしないです。

CoHALCoHAL 2008/11/04 23:53 解説漫画のハルカの顔が「君は本当に馬鹿だなぁ」になってる気が…

早坂千尋早坂千尋 2008/11/05 00:16 レポお疲れ様です。ちょっと修正指摘です。「メーカー純正のsensor.dllをSAORIインタフェースに合うように改修」→「メーカー純正のsensor.dllを操作するC++クラスがネットで公開されているので、それをSAORIインタフェースに合うように改修して使用」です。そのあたりは私の書いたコードではありませんので。このC++クラスを公開されている方が東海道新幹線でこだまの振動計測の実験を行われています。http://www.hirax.net/dekirukana8/accelerometer/index.html 鉄な人にとっては気になる点なのでしょうか。GPSは思いつきませんでした。間接的ですが写真に埋め込まれているGPSデータを勝手に読み取って感想を述べるとかも面白そうです。

hinoharuhinoharu 2008/11/05 19:20 早坂様:了解しました。該当部分を修正しましたのでご確認下さい。ご迷惑をおかけしました。
鉄道の話ですが、たとえば列車の座席に座ったままで、今の速度やカーブの曲線半径はいくらか、ブレーキやマスコンのノッチはいくつか(もしくは加速曲線の検証)など、様々な技術的情報を得られないか・・・という憧れがありました。加速度センサだけでは重力による力と加速による力が区別できないので限界はありますが。(カントによる横向きの重力と遠心力の区別がつかないとか・・・)
ExifのGPSデータはまだあまり普及していませんが、駅の写真を渡すと何駅!と断定するレチハルカとか、手品的で面白いかもしれません。

hinoharuhinoharu 2008/11/05 19:20 師匠様:見ないで描いたものでなんかヘンかもしれません。ゆっくり乗っていってね!

早坂千尋早坂千尋 2008/11/05 23:14 修正ありがとうございます。あの説明でそこまできちんと解れというほうが無理なのでお気になさらず。ただ、他人のコードが混ざっているというのが、現時点で加速度検出SAORIを一般配布してない主な理由だったりしますので。

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