第二部 13:15〜

「フィーネさんのはずかしい話」

  • 10年前のことじゃった。新しいゴーストを公開した初日に「このゴーストしゃべらないの？」と質問された。そんなわけないじゃないか…辞書ファイル入れ忘れてたああああああ！

「里々プログラミング」 - あーるでぃー

  • 概要
    • 里々で処理を作るデモンストレーションをする。
  • 里々でポーカーの判定を作ってみるデモ
    • 「ストレート」の判定をどうする？
      • 全パターン書く：1万行以上
      • 全部足して5で割れるか判定：3579Jで誤判定
    • 「whenlist」関数を使って判定処理
    • 「1〜13」の枚数をそれぞれ変数に突っ込む→手札のデータ化が可能（YAYAなら13要素の変数）
    • 「手札表示」変数を作る。枚数の数字を（2,3,4,5…12,13,1）の順で並べる
    • ストレート成立の場合、「０００００１１１１１０００」などとなり、「count」関数で「１１１１１」の個数が1となればよい
    • 他の役もすべて同じように判定可能
    • 「バケットソート」という名前がついており、多くの人が里々で似たようなことをやっている。
  • 必要なのは「知識」
    • たとえば「魚は魚屋で売っている」ことを知らないと、魚を食べたいときに南氷洋へ行くことになる
  • SSPで出来る範囲と出来ない範囲
    • できる：パズル、ターン制RPG、クイズ、謎解き脱出ゲームなど
    • できない：弾幕ゲームなど。計算速度、処理するデータ量が莫大なもの
  • 複雑な機能は作れないの？
    • 作る必要なくない？
    • フリーのゲームエディターがたくさんある。
    • アクション「Unity」、弾幕ゲー「弾幕風」など。SSPで出来るか？を判定基準に
  • SSPだからこその機能
    • 難しい機能は作らなくていい、キャラクターが常にそこにいることが伺かの特徴。
    • キャラクターを前面に出して、人間味を出す。表情、ブラフをかけてくる、など
    • 判定機能（強いAI）はいらない、そういうロジックはすでにある
    • ブラフをかけるか？の判断は、キャラの性格に基づいて最初からフラグを立てればいい
    • 初期の手は最初から割合表示で設定してしまえばいい
    • （乱数1〜1000000）などで乱数をとり、最初から役を決めてしまってよい
      • ユーザはロジックに興味があるわけではなく、その勝負の結果に興味がある。理不尽でなければ問題ではない
  • 例
    • 理不尽な例：昔の脱衣麻雀。「積み込み」で2順目に上がられたりした
    • 「豪運キャラ」として役の確立を増やすなども個性づけになるが。あまり強くしない。「ワンペア率を極端に下げる」などのバランス調整。
  • デモンストレーション
    • また後日！ゴースト公開するとのこと。



資料を使って設定やトークを考える - りすな

  • 手塚治虫は絵を描かなかった。「おまえの書く女は色気がない」と言われたことがあるが、「自分が描いているのは絵じゃなくて象形文字だ、自分の中のパターンを組み合わせて一つの記号を作っている。自分の漫画は表現のための記号だ。キャラクターは単語なんだ」と応えている
  • 当時はリアルタッチの絵が流行っていたのでヤケで言ったのかもしれないが、それをもとに「漫画記号論」という言葉が生まれた。漫画やキャラクターを記号の集合体として見る観点がある
  • 「キャラクターは記号の集合体」
  • さてゴーストを記号化してみよう。まずはキャラクターの周囲。ゴーストの職業、そのゴーストが他社と異なる点、を決める。前者は必須。
  • ゴーストが起きてから寝るまで接するものや人、出来事を上げる。通る道の脇にあるものなど接点の浅いものでもいい。便宜上これを「周囲の記号」と呼ぶ。サラリーマンなら、家族、通勤電車、キヨスク、上司など。ファンタジーなら剣、魔法使い、境界、など
  • 周囲の記号を上げたら、それに対して疑問を投げる。「5W1H」が基本。「いつどこで〜」
  • 家族はどんな人？通勤電車はどこ走ってる？キヨスクは誰が働いてる？同僚はどんな人？
  • 剣は何を使ってるの？魔法使いどんな人？など
  • 疑問を投げたら自分で回答するんだけど、自分の知識だけだといまいちよくわからなかったり、知識不足でリアリティ出ないときは「調べる」さらに疑問が出たらさらに問い、調べる
  • 複数ソースを見るのをオススメする。資料の正しさが判断できない。事象専門家の怪しい本もある
  • 一人ぐらし→なぜ一人ぐらし？→実家はどこ？→家族は？
  • 剣は何を使っているの？→カッツバルゲルという剣→なんでその剣を使っているの？→なにその名前ふざけてるの
  • 疑問と答えを繰り返していくことによってゴーストの周囲の環境が細かく決まっていく。実在の単語（ｶｯﾂﾊﾞﾙｹﾞﾙ)を埋め込むことでわかる人にはリアリティが上がる
  • 周囲の記号を調べるうちに周囲の記号そのものが増え、設定が追加されていく
  • 調べ物をしてて調べきれない、資料があわない、というものは、同一の系統の別物をもってきて差し替えてしまうのもあり
  • クニグンデ（略）では宗教の教義として儒教をベースにしている。（イメージはキリスト教だが）
  • キャラクターが住んでいる地域のことがわからなければ勝手に設定をつけたり地元を設定にしてしまったり…
  • 職業も自分のやってる仕事と置き換えてしまったり、実在するものをミックス。専門外の人から見たらすごい、みたいなものができる
  • プロだってその道の人が見たらなんだこれみたいなのを出している。架空世界ならやりたいほうだい
  • 自分のわかるものに置き換えることで調べるのが楽になる。中世の生活史を調べるかわりに、江戸時代をベースに名前だけ中世っぽくしてもいいのでは。リアリティ出る
  • 次にキャラクターを記号化する。容姿性格考え方住所氏名年齢現在歩状況誕生日血液型好きなもの嫌いなものキャラクターの望み趣味性癖など
  • 人物そのものに注目する。身長などは数字を決めずに相対的に「高い」「低い」でもいい
  • 人物の記号を上げたらそのキャラクターにとって最優先とされるものを１つ、次に優先されるものいくつか、そこそこ優先するものをいくつか選ぶ。身体が恵まれているなら逆に趣味嗜好などが選ばれる
  • 周囲と人物をかけ合わせてトークを作る。周囲の記号を取り出し、組み合わせにできる人物の記号を考える
  • 「周囲の記号」について話す「優先される人物の記号」で「任意の人物の記号」（な）（の）人
  • あてはめていく順番は優先順、内容がかぶったら任意の内容に変える
  • 「水が苦手だけど女児の水着が見たいからプール行く」
  • 「女児の水着が見たいけど水が怖いからプールへ行かない」
  • 優先度を変えるとこんなふうに二通りのトークが派生する。
  • そのキャラクターにとって希望することを設定することでキャラがぶれなくなる。物語の創作でも利用できる。キャラクターが何を優先させるかを決めておけばキャラをぶれずに話しを展開させられる
  • 働くのが嫌な怠け物だけど雨が大好きなアイドルの女の子〜飴＞怠け物　なら飴で釣って仕事させてOK
  • 周囲の記号を考える際に、キャラは別のキャラのすべての面を知らなくてもよい。同僚が（１）イケメンの（２）殺人鬼であるなら、１だけ知っていればよい。ただし２を匂わすのはアリ。ユーザにも真相が不明な思わせぶりなトークや、話しぶりからユーザーが察することができるトーク、などが可能。「○○は××なんだよ、なんでだろう、なんでだなんでだろう〜〜」と言わせればOk
  • ２はキャラクターが間抜けな場合に活躍する。ユーザからは「ばかだなー」と思わせてもよい
  • キャラクターの話し以外から真相が判明しているパターンは、別モードに別のキャラクターに喋らせるのが一番徹取り早い。別の作品で判明させるのもあり。
  • 資料と人物をかけ合わせてトークを作る。先程のトークの公式に「周囲の記号」の華和梨に知識を当てはめればおｋ。
  • 「なんらかの知識」について話す「優先される人物の記号」で「任意の人物の記号」（な）（の）人
  • 「リカちゃん人形の味は苦い」について話す「甘党のロリコン」
  • ヤコブソンの「範列関係」。「ぽなさんが喫茶店でSSPを更新してバグを出した」→「喫茶店」のかわりに「自宅」「宿」「うかべん会場」に置き換えてOK。この関係を範列関係という。範列関係を使うことでトークを増やせる。どこいつトークにも似ているが、単純なランダム単語トークだと範列関係と矛盾する内容が出てきたりするので注意。
  • トークを描いているうちにただ事実を話すだけになっていた、自分のキャラクターがわからなくなってきた、ゴーストの性格に厚みを持たせたい、などというときに活用したい。
  • キャラクターの立ち位置について資料の使い方が変わる。詐欺師のゴーストを作るのに消費者生活センターの詐欺被害についての資料を参照した。人を騙すゴーストを作るにはそういう資料の見方
  • ユーザーに対して設定をどこまで公開するか？→人それぞれ。オタクは深読みするのが大好きなので放り投げておいて勝手に類推させるのもあり。あんまり設定詰めすぎると動けなくなってしまう。出していいかよくわからないあやふやな点は隠しておいて、ダメだと思ったら設定そのものを蹴ってしまってもよい。
  • 診断メーカー「ゴーストのランダムトークのお題」も活用できる。最優先の事項だけ固めて、「周囲の記号」を集めるのに使える。



「インターネットを活用して、共同作業を進めよう」 - 高見知英

  • 概要
    • インターネットストレージとは
    • ストレージサーボスを使った共同作業
    • 作業を補完するツール
  • 自己紹介
    • 活動内容、地域NPO活動、開発関係書籍作成、動画配信、プログラミングなど
  • ゴースト関連ファイル管理どうしてる？ 複数人で共同開発するときどうしてる？
  • インターネットストレージ
    • インターネット上にPCのファイルを補完するサービス、特定のフォルダのファイルを自動アップロード
    • PCとストレージ間のデータ共有（シンクロ）、複数PC間の連携も可能
  • 主要サービス
  • 使い方
    • フォルダにファイルを入れると、しばらくしてファイルがアップロードされる
  • サービス紹介
    • Dropbox：2GB〜1TB（個人）、他のPCでアップロードされたファイルをお知らせ、1000円/月
    • OneDrive：5GB〜50GB（個人）、Win8/10は最初からフォルダあり。Office365契約すると1TB追加,

249円/月

    • GoogleDrive：15GB〜30TB、GmailやGoogleフォトと容量を共有。独自形式ドキュメントは容量無制限。かなり無理がきく、250円〜39000円/月
  • ストレージサービスを使った共同作業（共有機能）
    • Dropbox：「共有」メニューからURLを作り相手に教える、Dropboxユーザ名で指定
    • OneDrie：Dropboxとだいたい同じ。期限日の設定もできる。
    • Google Drive：一番特殊。URLを取得して共有、人を指定して共有、で画面が違う
  • 特定の人と共有する方法
    • それぞれのアカウント（メアド）を指定して共有
    • URLを公開し、みんなで閲覧（or編集）
  • Googleドキュメント
    • 複数人で同じファイルを同時に編集可能、相手がどこを見ているかもわかる
    • 編集の衝突の処置はどうしているのか？
  • 予定管理：Google Calendar
    • 予定を共有、外部に公開も可能。告知の方法の一つとして使える（フォローしてる人のカレンダーに表示される）
  • 改版管理：Git（ギット）
    • 開発者向け改版管理ツール
    • いつ誰が何を解決するために○○をした、を追跡できる
    • GitHubはGitのサーバーサービスのようなもの
    • Gitは基本的にコマンドライン操作だが、Git Extensions などのGUIクライアントもある
  • 内部連絡ツール
    • メーリングリスト
    • 少人数ならチャットもいいかも。Facebook、LINE、Slack、Skype
      • LINEはスマホとパソコン各1台ずつからしかログインできない
      • Slackは会話のスレッドを分岐させられるので話を脱線させやすい人がいるときはこれ
  • 多くのインターネットサービスの活用
    • 無料サービスいっぱいある。各種サービスを活用し、快適な共同制作を！

「ゴーストにおけるユーザインターフェース」 - あーるでぃー（再）

  • 概要
    • UIのうち、操作性に焦点を当てる。操作性とキャラクター性は同時に成立しないのをどう考えるか。
  • 自己紹介
    • UKADOCの精査、里々wikiの補強、伺的フォーラムのリプライ、「伺かのシェルの作り方」など
  • 活動の根源
    • ゴースト作成の疑問が検索のみで９９％解決するようにしたい。始めて作る人が一人で黙々と作ってゴースト公開まで持っていけるようにしたい
    • TIPSは「こんあんことも出来る」という例。それぞれの頭の中で発展してほしい。知らなければ出来ない。
  • ゴーストにおけるユーザーインターフェース（UI）
    • ユーザーが見るもの触るもの全部。デザイン、操作のしやすさ、操作のわかりやすさ。
  • デザイン
    • キャラクターや服が可愛いなど、主に見た目。今回は扱わない。
    • 良い例：各種スマホゲームがデザイン。
    • 悪い例：一部コンビニのコーヒーマシン。黒ベースでデザインは良いが操作がわかりづらい。テプラまみれになってデザインが失われた。
  • 操作のしやすさ
    • ボタンの押しやすさ（正方形や円形など）、多少の間隔があって押し間違えしにくいのがよい
    • 悪い例：項目がごちゃっと並ぶ、設定したい項目がどこにあるかわからない
      • SSP本体メニューか？ゴースト側メニュー課？始めて使う人にはわかりづらい。
      • 例えばシェルの設定をするのなら、シェル切り替えも出来た方が便利。
  • 操作のわかりやすさ
    • やりたいことをすぐ探せる「設定）メニューにあるなどアクセスしやすい
    • 悪い例：ボタンを押すたび処理して固まる、何度も（スクロールさせるなど）面倒な操作をさせる
    • Webでは、最近「ボタンを押したら確認」ではなく、「押したら実行、キャンセル（取り消し）ボタン付き」に変わってきている。たかが1クリックと侮ってはいけない
    • 階層メニュー化は必要だが、よく使う機能は1〜2クリックにとどめたい
    • マジカルナンバー7±2：人が覚えられる最大の項目数。メニューの項目は7個ぐらいまでにした方が良い
    • 細分化しすぎるのもダメ。操作しやすいのは「3段まで」
  • 操作の共通性とキャラクター性
    • どちらも両立するのは困難。
    • 操作の共通性とは：操作をテンプレート化する、SSPの機能でできることには手をいれない、どのゴーストでも同じ操作感にする。など
    • キャラクター性とは：ユーザーは架空のキャラとして考えている。「人扱い」しすぎると破綻する。
      • 操作のしやすさを取ると人への扱いではなくなってしまう。何を命じても拒否しない。
      • 人への扱いをすると操作がしづらくなってしまう。夜は寝てるので喋り頻度0で変更不可、など
  • 操作の共通性について
    • 全ゴーストでなるべく同じ動作にする。
    • ゴースト間で統一されている暗黙の動作（ダブルクリックでトークなど）
  • バルーンでの統一
    • バルーンによりフォント指定してる可能性がある
    • \b[2]への対応、フォントの色、など
  • 以上を全部守ると操作の共通性が守られていてユーザに優しいが、作る側にとって窮屈すぎる。
  • どれくらい守るべきなのか
  • -
    • 頭をダブルクリックしたら叩くではなく頭をポンポンする扱いになるゴースト
    • 暴力性のないキャラクターの表現にはなるが、ユーザーは少し混乱する
  • 着せ替えメニューを独自実装するなら？
    • 着せ替え自体に膨大な了がある、特定条件でのみ出てくるおまけの管理
    • プレビュー加増を一覧表示している、きせかえセットの保存など
  • スマフォ向けUIとの親和性
    • バルーンは狭いので表示できるものが限られている
    • 狭い画面でなんとかしようというスマフォのUIと重なる部分がある
  • 限られた表示範囲でいかに良いUIを作るか？
    • これまでの試行錯誤についてはたくさん資料ある
    • タッチする場合はンや正方形がタッチしやすい。文字列選択肢は横長でタッチしづらい
    • インライン画像を活用するといい
  • UIの評価は減点方式
    • たいてい、使いづらいと直接言われることはない。
    • 悪いインターフェースで始めて「悪い」と感じるが、少しずつ慣れてしまう。
    • 「慣れ」が発生すると、ヘビーユーザーにはわかるが新規の人にはわからないこともある
    • 操作性が改善されたときに批判が大きい。ヘビーユーザーには「前のほうが良かった」と言われる
    • 最初から良いUIを作ることの重要性
  • 例：SSPの右クリックメニュー
    • 「指令の確認」？？
    • 慣れてるユーザーは「上から３番めなのでネットワーク更新だ」とわかるが、初心者には理解できない
  • 操作性
    • 里々の選択肢：「表示文言」文法で\qに変換してくれるが、下線もマーカーもないのでマウスオーバーするまで選択肢かどうかわからない。冒頭に「○」を入れるなど選択肢として目立たせるべき。
  • キャラクター性
    • 一体感、連帯感、親近感あたりが大事
      • 同じ世界にいることをアピールする
      • ユーザーごとに違うものを提供する（選択肢でどちらか片方しか手に入らないようにする）
      • 触った回数をカウントして傾向によって反応変化
    • ユーザは「自分が選択したこと」に対して特別な思い入れを持ちやすい。選択の結果を後のランダムトークで触れるなども有効。「誕生日にもらった○○だけど…」など
  • まとめ
    • 操作性の考え方：どこまでを共通にして、どこから独自にするか。理由がなければ共通に統一しておくと良い
    • キャラクター性の考え方：実在人物扱いは不可能。メニューなどで却下するなどは操作性があwルクなる。思い入れを持たせる方法を探ってみるといい。

「SSPの次期メジャーアップデート版プレビュー」 - C.Ponapalt

  • 「音声認識」「音声合成」
    • トークの読み上げ、音声でのコマンド入力が可能？
    • Windows公式の音声認識機能を使用
    • 音声認識をさせるときは認識の選択肢を限定する方がいい。選択肢を読み上げて選択するときなどに有効
    • Windows標準の音声認識ライブラリは調教できるので、もしかしたら主人の声にしか反応しないようにできるかも
    • ぽなさん女の子に「ちんちん」を連呼する

第一部 11:00〜

本日のおしながき

  • -




「情報サイトを作ろう」 - Fine Lagusaz 様

  • 概要
  • -
  • 情報サイトとは？
    • 公開、更新、イベントなどのお知らせ→Disc-2、さくらナビ、un.yu.to…
    • リファレンス→UKADOC Project
    • 作り方や小技の開設→伺かWiki、各種SHIORIの解説Wiki
    • 感想・レビュ→
  • -
  • 新しく作りました「Uka-Ni-Sphere」
    • 伺的なニュースブログ「霊界通信」、レビューWiki、フォーラム　の３点
  • CMS（コンテンツの管理を楽にする仕組み）
    • ブログ（WorcPress）
      • ブログ以外にサイト構築もできる
      • 今回はオーソドックスにブログとして利用する
      • プラグインは高速化、SEO対策関連を追加する
  • 感想やレビューWiki（Docuwiki）
    • 開発が活発なWikiシステムの一つ
    • ユーザ管理、スパム対策などの昨日が充実している
    • 本体や拡張のアップデート、インストールが管理画面からできる
    • コメント機能を追加するプラグインを中心に追加で導入
  • サイトのデータ量
    • ガワを作るだけであれば数MB。コンテンツであるnarファイルが一番でかい。
  • フォーラム（fluxBB）
    • メジャーなフォーラムのひとつ
    • これもスパム対策が取りやすいので導入した
    • 国内だとあまり使われていない、ような気もする
    • カスタマイズはほとんどしていない。かなり素でもOK
  • 作った後の話し
    • 構築自体は実は楽。マニュアルどおりでOK。
    • CMSのアップデートなどもマニュアルどおり。
    • 課題はコンテンツを更新し続けること、定期的に宣伝をする必要があること
    • 霊界通信はまわりが活動してくれれば更新できる！

それはさておいて〜

  • サイトをもっと楽に作れる方法はないのか？
    • レンタルサービスで対応できるっぽい
    • ブログ→はてなブログ（マークダウン方式対応＝簡易記法）、FC2ブログ、、、
    • Wiki→@Wiki、Wikidot（SCP財団がこれ）…乱立中
    • フォーラム（というか掲示板）→したらば掲示板
      • ほとんど死んでいる。スパムが多すぎて制御しようがない！
      • したらばは海外アクセス遮断やNGワード設定が可能
  • かわりにGitHubが使えるのでは？
    • 模索中
    • リンク集や簡単なドキュメントなら残せそう
    • 引き継ぎも楽だし割りと良いのでは？よく知らない人にはとっつきにくいかも
    • リンク集は管理が大変めんどくさい。HTMLからURLを抜き出すのが大変
    • いかに簡単に残し、いかに簡単に誰かに引き継ぐ・手伝ってもらうか？
    • 簡易記法でリンクを書けるGitHubは良いかもしれない
    • 「いつまでもいると思うなサイトと管理者」
  • 質疑応答
    • WikiやGitHubはトップページが殺風景すぎないか？
    • Wikiはランダムで画像が表示されるプラグインを入れた。本筋に関係ない画像がクルクルしたりヒュンヒュンするのは嫌い
    • SSPのリファレンスについて
    • マークアップ記法について
  • さいごに
    • うちのさいと（霊界通信）よろしくね！！




「ベースウェアを作ろうとして Web サービスができた話」 - notona 様

  • 概要
    • SSPの限界を感じたので自分で作ってみようと思ったら出来た。
  • あらすじ
    • HI-DPI環境でキャラが宙に浮いて表示されたのを見て「SSPはそろそろ厳しいのかな…」と思った
    • 「じゃあ自分でベースウェアを作ればいいんじゃね」「Chrome上で動くようにしよう」
    • 目標：ゴースト「うりねとじゃがー」を正しく動かすこと
  • システム構成
    • 伺かの基本的な構成→ 表示部⇔ベースウェア部⇔栞部。そもそも栞がないとはじまらない
    • SHIORIの実装をどうするか？→里々だけ（Webコーディングで）内蔵してしまえばいいのでは？
  • 実際に作ってみた
    • 名前は「Lunalis」※（「nar」を入れたかったけどだめだったのでnalを入れた）
    • Chrome上で動作するベースウェア
  • スタンドアロンクライアント作ってみた
    • デスクトップ上に表示するデモ
    • Mac上でも動く。
    • NwjsというJavaScriptとHTMLみたいなのを使って簡単に出来た
    • Androidでも動作。壁紙アプリを作るための機構を乗っかる形で実装している。
    • AndroidはCanvasに描画する形でしか書けないので、別の関係ない画面に描画したものを横から無理やり壁紙に書き込んでいる
  • Lunalisのアクセス
  • 質疑応答
    • 栞はどうしたの？→最初とりあえず自分で書いてみて、里々のコード読んでみたりして、でも結局全部自分で解析して書いた。サイト上のコードに全部入っているから読めるもんなら読んでみな！（意訳）
    • セーブデータはとこに？→ブラウザのローカルストレージに突っ込んでいる。
    • 複数ゴーストもインストール可能
    • ブラウザ上のシェルとデスクトップに立ったシェルのまばたきの間隔が違う気がするが？→タイマーの扱いなどが違うからかも。
    • SSPのHi-DPI対応について→バグ修正します。（ぽな）

うかべん横浜 #9 実況

ghost


本日9月16日（日）、伺的ソフトウェア勉強会（うかべん） 横浜 #9 が実施されます。
というわけで恒例のテキスト実況をおこないますので皆様よろしく。


【この記事の内容について】
この記事は、私がスピーカーの皆さんの発表を聞き、自分なりに理解し、かみ砕いて書き下し（ていませんが）、感想を付け加えたものです。
（各発表の冒頭にある「概要」と末尾にある「感想」は、私自身の意見・感想です。）
とくに私の理解力不足により、スピーカーの皆さんが発表された内容と相違している可能性があります。
誤りや問題点がありましたら、コメント・拍手等でご指摘ください。
また、公式記録ではありません。ご了承下さい。


【Youtube実況中】https://www.youtube.com/watch?v=A2dsZ-srtkI にアクセスしてください。

第二部 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になるにはどうしたらいいですか？
      • ぽなさんに言えばもれなくなれます。

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

  • 概要
  • 統合開発環境とは・
    • ゴーストを作るのに必要なものを色々集めたもの
      • 例：SSP＋メモ帳、FFFTP、フォトビューアー、さとりて、れしば、エクスプローラー
      • SSP以外のすべてを「さとりすと」で！
    • 画面例
  • （特長１）辞書のリスト化
    • 「同じ名前で」「同じ名前と条件で」トークを追加するようなことが簡単にできる。ランダムトークのリストを作れる。
    • 辞書を直接編集することもできる。
      • 初回起動時にどちらにするか尋ねられる。あとで変更も可能。ファイルごとに変更も可能。
  • （特長２）デバッグ機能
    • 「さとりて」を使わずに、書いたトークをそのままゴーストに喋らせられる。（コピペ不要）
    • 変数の確認と設定、リロード、イベント呼び出しが「さとりすと」から可能。いちいちデバッグ処理をゴーストに組み込む必要がない
    • 「れしば」を内部に持っているので、新たに起動する必要がない
  • （特長３）設定ファイル編集機能
    • satori_conf や developer_options をリスト形式で編集することができる
    • 更新ファイル設定なども可能（削除ファイル等の設定）
  • （特長４）更新アップロード機能
    • FFFTPなどを起動しなくてもOK（自動化システムと同じ機能）
  • （特長５）立ち絵確認機能
    • シェル合成もやってくれるため、別に画像を用意する必要がない
    • 「サーフェスパレット」も作れる
  • （特長６）さわり反応領域表示・編集
  • やってみたいこと
    • 里々との直接連携
      • 里々本体に「さとりすと」連携専用の機能を搭載して、デバッグをより手軽にしたい。（変数一括取得など）
      • 「さとりすと」専用の機能をつけてもいいのかな…→ぽなさん「いいです」（1秒）
    • リクエスト対応
      • 需要に応じて機能を拡張する、など。いつも使っている人の意見を聞きたい。
      • バグが出てきたら修正します
  • まとめ（一番いいたいこと）
  • -
  • おまけ
    • ゴースト配布サイトジェネレータ
      • HTML/CSSを一切書かずに公開サイトを作れます。配布サイト→
  • 実際にやってみた（デモ）
    • スクリプト作成支援機能（サムネイルをダブルクリックでサーフェス番号入力など）
    • 更新ファイルアップロード機能（誰も気づかないくらい一瞬で更新完了→自動ツイート）
    • ukadoc連携、SHIORIイベントリファレンス表示機能
    • 「さとりすと」自動アップデート機能
    • ゴースト新規作成ウィザード
    • その他、痒いところに手が届く機能満載！（めっちゃすごい）
  • 質疑・要望
    • ワンクリックでウエイト挿入できないか？
      • 右クリックメニューをカスタマイズ可能です
    • REPLACE と REPLACE_AFTER の色分け？
      • 設定で可能？
    • 今出来ないけどそのうち実現したいことは？
      • サーフェスプレビューの精度が悪いので、ukadocの拡充してほしい
    • 一部処理で速度が出ない
      • 里々本体との連携ができれば最高
    • 自動でネタを考えてください
      • 恒例なので気にしないでください（ぽなさん）
    • 設定のエクスポート・インポート機能ほしい
      • 全部の設定でよければ設定ファイルを複製してください
    • プラグイン作りたい
      • 入出力まわりの仕様を教えてもらえれば対応したい
    • すでに里々で作っているゴーストを読み込んで編集することもできるか？
      • できる。最初からさとりすとで開発している必要はない。
      • すでに機能をつくりこんだゴーストも読み込めるのか？
      • 可能。さとりすと専用のゴーストになることもない。
    • \eのあとをコメント扱いにしてほしい（\eでトークとしては終了するが、あとにコメントをつけることがある）
      • 「//」と同様の扱いにすればいいのかも。できればやる方向で。

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

＊奈良阪某さんパート＊

  • なぜ作ったか？
    • スマートフォン全盛時代にデスクトップの消滅危機
    • ゴーストが立つ場所がなくなる→やばい
    • Windowsデスクトップ依存からの脱却→ブラウザ上で動作させたい
    • 伺かという創作表現の存続を図るために開発
  • なぜ作ったか（２）
    • 先発のSSP等よりもよりよい設計のものが作れるかも？
    • SSPが動かない環境を制覇することがSSPに淘汰されない唯一の道である
  • どう動くのか
    • システム構成図
    • シェル系・イベント処理系・ファイルシステム系・SHIORI系に別れている
    • 存在するファイルからSHIORIを判別する（栞プラグインを利用）
    • シェルとバルーンを起動（duxcaさん担当）
    • 「こういう動作がおこなわれたら」「イベントを発生させる」という処理をプラグイン方式としている
    • 以降、ベースウェアの動きの話を始められる（SSPなどもやっていること）
    • （イベント発火チェーンの開設）→OnBoot発生→さくらスクリプト発生→サーフェス表示！（拍手）
  • 課題

＊duxca（ダクスカ）さんパート＊

  • ゴーストプレイヤー　フロムウエブブラウザア
    • 伺か互換環境の人
    • ウェブブラウザで動くシェル描画エンジンを作戦（CATTLEBONE、イカの殻＝如何かのシェル）
  • なぜウェブブラウザで動かすの？
    • 最近ゴーストを起動していない理由？
      • ゲイのサディストだから
      • ではなく、Windowsを使っておらず、パソコンを持っておらず、パソコンを使ってないから
      • 最近の若い人はWindows離れが著しい…が、どれも「Webブラウザが動いている」
    • WEBブラウザで動く＝移植性が高い！
    • そしてCUTTLEBONEとは…伺かを多様化するコンピュータ環境に潜り込ませるための技術
  • どういうしくみなの？
  • どう使えばいいの？
    • 描画エンジンを叩く必要がある
    • 再利用も可能
  • まとめ
    • 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の先に物理ロボットをつなげばリアルシェルも実現可能！？
      • 合成音声バルーンも実現可能！？
    • ぽなさんのコメント
      • すげぇ。
  • おわび
    • 若干まとめきれてない部分があるので、詳しくは発表資料を参照してください（ヒノハル）

第一部 11:00〜

本日のおしながき

https://twitter.com/hinoharu/status/594690455410839553

「新しい伺的勉強会のかたち」 - 畝傍 様

  • 概要
    • これからのうかべんについて
  • 基調講演「イベントのやり方」（初級）
    • 気合を入れる
    • ぶちあげる
    • 終わり。出来る。
  • ちゃんとしたやり方（その１）
    • 日時を決める
      • 該当ジャンルのイベントの開催日が被っていないかを確認。逆に被らせることで参加者が増えることも
    • 予算を決める
      • 無理のない範囲で。参加費設定時も注意。内臓を売るのは１回まで。
    • 場所を決める
      • 予算と相談しながら利便性のいいところを選ぶ。
  • ちゃんとしたやり方（その２）
    • 参加者募集する。
      • パンフレットやチラシの作成
      • 依頼する場合、現行作成に１ヶ月、校正１ヶ月、掲示に１ヶ月以上
    • 参加者募集は余裕をもってやること。キャンセル時の対応も要考慮（キャンセル締切日を設ける等）
    • パンフレット等は２〜３日は考えておけば間違いない
    • 開催予定日から逆算して動き始める
    • 不測の事態に備えて余裕のあるスケジュールを！
      • やってみて経験することが大事。小さいイベントからホップ・ステップ・かーるいし！
      • 過去に似たようなイベントを主催した人がいたら、話を聞いてみるのも役に立つ。（こともある）
      • うかべんの主催に聞いても何も出てきません。（by 主催）
  • お金の話
    • 部屋代、印刷代、その他消耗品代等で赤字にならないように計算
  • うかべんの現状
    • アクティブなスタッフはぽなさんと畝傍さんのみ→鋭意募集中
    • うかべん以外でも、オフ会・開発オフ・取材旅行オフ（遊び）等、いろいろなイベントを是非主催してください。
    • 次のうかべん（関西・その他地域）の主催は君だ！！！！！

「伺かのための三角関数講座」 - ミラヤギコ 様

  • 概要
    • シェルを動かすmove関数での三角関数の書き方と、三角関数の仕組みを頑張って分かりやすーく説明してみます。
    • 今回話すこと＝「move関数（伺かの知識）」＋「三角関数（数学の知識）」
    • 今回は数学再度からのフォローをします
  • 三角関数をわかりやすく…の前に、関数とはなにか？
    • 関数とは「なぞのはこ」です
    • 「なぞのはこ」は「何かを入れると」「（別の）何かが出てくる」
      • 何か入れたら何か返してくれるもの
      • 毎回同じ処理をしてくれる
      • 同じものを入れると「毎回同じ結果が返ってくる」
  • 数学の関数例
    • y=2x … 入れた数を2倍する関数
    • 前項の「関数の特徴」をすべてそなえている→関数
    • 三角関数も同じ！
  • 単位円上を動く点Pを考える
    • 図がないと説明できないのであとでスライドを見てください！（ごめん）
  • ここまでをまとめると
    • 関数：何かを入れたら何かが出てくる
    • 三角関数：「角度」を入れる
    • 半径1の円と点Pを使うをわかりやすい
    • sinは三角形の「たて」、cosは三角形の「よこ」
  • 質問
    • 里々で使えるのか？→里々はyayaの関数を借用する必要がある。灯（あかり）は今は単体で可能