第一部 11:00〜

「ゴースト製作支援ライブラリ『あやりりす』の紹介」 - C.Ponapalt 様

  • 自己紹介
  • 「あやりりす」って何?
    • 伺か向けDSL「文」(AYA)の改造版「YAYA」向け開発支援ライブラリ
    • C言語ライクに書けるAYA→プログラマ専用の雰囲気
    • 普通の人(非プログラマ)にも書けるスクリプト、PGも納得の強力な支援機能の両立をしたい
    • それって都合良すぎ??
  • あやりりすの適用前・適用後
  • できること
    • 簡単で適切な自動トーク制御
    • 難しい細工のいらないイベント反応
    • SakuraScriptをあまり使わない
  • できないこと - 「AYA以外の何か with 違うもの」
    • 里々の辞書を読む
    • AYAの文法がまったく要らない記述
  • 開発動機と名前の由来
    • くーぷらん氏、水無月藍氏の開発支援経験
    • 何でも書けるが難解なAYA・華和梨
    • 一見簡単だが、ややこしいことをすると即刻記述が破綻状態になる里々系“括弧悪い”
    • 「何でも書けて簡単に書ければ問題ないよね」→内輪で使うために開発
    • 名前の由来
  • 「あやりりす」と「あやりりすEX」
  • 「あやりりす」→イベント処理支援ライブラリ
    • OnBoot→「朝に起動」
    • OnGhostChange→「*Emilyへ変更」
    • OnMouseMove+ややこしい条件分岐→「なでなで0Bust」
    • AYAに慣れた人でもめんどくさい処理記述を完全支援!Tipsを全部投入!
  • ランダムトーク管理
    • 「新規追加ランダムトーク」で新ネタ優先→慣れていても実装が面倒
    • 季節や時間帯専用トークを特別な記述なしに通常トークに混ぜて喋らせることができる→大量のif分の山よサヨウナラ!
    • 「ランダムトーク秋」とか書ける
  • コミュニケート管理
    • 泣きそうな条件分岐の山→「ユーザーコミュ好き|愛し」
  • 今後の展開
    • モードのサポート→まだ完成度が低い
    • アンカー(単語解説)サポート→別ファイルで実装中。できれば単独で使えるようにしたい。(あやりりすACとして分割?)
  • あやりりすEX
  • トークべた書き支援ライブラリ(「あやりりす」抜きで単体仕様可)
    • 行ベースで台本を書くようにベタ書きできる設計→副産物:誰がどの表情で喋ってるかわかる
  • -
    • チェイントーク支援→「=====」で区切るだけでチェイントーク
    • メニュー記述支援
      • @メニュー:テキスト|イベント
      • @半分メニュー:テキスト|イベント
      • →一行全部ハイライトするメニューが一瞬で書ける
  • 今後の展開
    • サーフィス番号変換処理→実はそこそこ実装済み、運用中(aya_lilith_ex_config.dicを参照)
    • 「番号」の代わりに文字で書けるように→「りりす笑:わっはっは」
      • 最初は便利に思うけれど、そのうち飽きて番号に戻ることが多い?(ボツ?)
    • 行ベースの条件分岐→ローカル変数が使えないので調整中(一応動く)
  • まとめ
    • 里々レベルの簡単さと、AYAの拡張性をあわせもつ強力なライブラリを開発
    • AYAゴースト開発に必要な着手当初の学習量を劇的に軽減→プログラマさん以外にも使える
  • -
  • 終わり(?)
  • 本当の開発動機
    • 「ぽなさんが」がトーク書くのが面倒臭かった
      • 下書きをいちいちスクリプトに手作業で直す工程に飽きた
    • 「ぽなさんが」イベント処理描くのが面倒臭かった
      • 毎回再利用不可能なコードを書き直すのが面倒だった
  • 実装詳細
    • AYAはプロトコルまで実装が可能
    • イベント処理やトーク処理を自分で書くことができる
    • 普通の設計:「SSP」→「DLL入り口」→「プロトコル解釈」→「イベント処理」→「DLL出口」→「開発者が書く辞書」
    • AYAの設計:「SSP」→「DLL入り口」→「最低限の処理」→「DLL出口」→「プロトコル解釈」→「イベント処理」→「開発者が書く辞書」
    • 「開発者が書く辞書群」に手をつけず、新しい記法を追加することができる
    • 開発者向け辞書と、支援部実装詳細との完全な切り離しが目的
      • Tipsサイトからテキストコピペはもう嫌だ
      • まともなプログラミング環境なら当たり前
    • 辞書として読み込むだけで追加できる「きわめて簡便な追加操作」
      • 新しいゴーストを作るたびに手作業が伴うとか正直やってられない
      • 更新するときもあやりりす関係ファイルを入れ替えればOK!

うかべん大阪 #8 実況


本日11月4日(日)、伺的ソフトウェア勉強会(うかべん) 大阪 #8 が実施されます。
というわけで恒例のテキスト実況をおこないますので皆様よろしく。


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

続きを読む

「ゴースト『電池ぺろぺろ』ができるまで」 - くーぷらん様

  • 自己紹介(原文ママ
    • 出戻りゴーストマスターです。
    • 国際交流が好きなのに海外経験なし。
    • うさぎが好きです。
    • 大映の特撮時代劇シリーズ「大魔神」とは直接の関係はありません。
    • ゴースト公開用サイト「陽気な羊飼い」 http://lingerie.shillest.net/
  • 今回の内容
    • ゴースト制作上のアドバイスはサイトに詳しく書いてあるので今回はナシ
    • 今回は新作ゴースト「電池ぺろぺろ」ができるまでについての話。
  • ゴースト「電池ぺろぺろ」
  • 電池の歴史
    • 紀元前250年ごろ、バグダッド -- 電池と思われる痕跡が発見されている。(めっきをしていたと思われる)
    • 1791、電池の原理を発見
      • ルイージ・ガルヴァーニ(イタリア):カエルの足の筋肉に電気を流す実験を繰り返し、電池の原理を発見した。
      • 電気の源が筋肉にあると考え、「動物電気」と名付けた。
    • 1800、ボルタ電池の発明
    • 1868、ルクランシェ電池の発明
      • ジョルジュ・ルクランシェ(フランス):現在のマンガン電池の原型を発明
    • 1887、乾電池の発明
      • やい・さきぞう(日本):屋井式乾電池を発明。特許を取り忘れた。
    • 日本人が乾電池を作るまで、電極をなめることができる電池などなかった!
    • 電池おを舐めないなんて乾電池に失礼! ゴースト化しよう!
  • 電池の味を感じるには
    • 電池の味=「電流」。人体はもともと電気抵抗が低く、とくに舌はしめっており感電しやすい。また舌は神経が集中している。
    • +極と−極が離れている電池では、下で両方の局を触ることが困難なため、味わいにくい。
    • +極と−極が近く、容量も大きい角形9V電池(006P電池)が、もっとも電池の味を感じやすい。
  • 006P電池とは?
    • 形や電池を考案したのはソニー。1957年にラジオ向けに販売監視。
    • 単一、単二などの単層乾電池と違い、積層乾電池。1.5ボルトの小型電池6個が直列で内蔵されている。
    • 主な用途:トランジスタラジオ、ラジコンのコントローラー、エレキギター、屋内煙探知機など
  • 作成までに調べたこと
    • ここまでが「電池ぺろぺろ」を作りはじめるまでにくーぷらんさんが調べたこと
    • ゴーストを作る際に事前に調査をした。
  • シェルの選定
    • シェル作成をお願いしたい人はいるがこんな作品では気が引けた→フリー素材を採用
    • ただしイケメンに限る」本当か?というのを確かめるために少年にした
  • ()
  • その他、作成にあたって
    • 普段は立ち絵からキャラクターを起こすので、手順が逆になり不慣れな作業になった。
    • 一発ネタゆえに後悔する気はなかったが、意外に浮けたので一般公開ページを作った。
  • 質疑応答
    • トークいくつ?
      • 15くらい。10を超えたら一度出してみることにしている。
    • 味は?
      • 電気の味でした。ぴりっとしました。

結論:電池。

「Excel2007でSurfaceを描いてみる。」 - 草葉犬死朗 様

  • 自己紹介
    • 一発ネタには鮮度があり、それを絵に出来る能力がある人は少ない
    • Excelという身近なツールを使って絵描きしよう!
  • Excelの機能
    • 図形ツールで平面図形を作り、立体的に回転や移動をすることで3Dモデル的なパーツを作成
    • パーツを組み合わせることで飛行機などの複雑な図形を作ることができる。
  • 利点
    • 目か・節足動物などの描画に由利
    • 角度を変えたアニメーションパターンの作成が簡単
  • 欠点
    • 人間等を描くのは難しい。l
    • 塗りが3DCGになってしまうので、2D塗りサーフェスとの混在が難しい。
    • 飛行機の尾翼など、縦方向の板やナナメ方向の構造物の表現が困難。
  • まとめ
    • 仕事でExcelを使ってる人なら仕事中にシェルを作れる!

「バルーンというインターフェース 〜 トークを表現するためのTips」 - NOBニャー様

  • ゴーストにとってバルーンとは?
    • ゴーストは、バルーンを使って話す(トーク
    • ゴーストは、バルーンを使って機能を提供する(メニュー等)
    • ゴーストにとって、バルーンはユーザーとの「重要なインターフェース」(※ごく一部に例外もいるが…)
      • ex.握江トク(発生と同時にバルーンも表示)
  • ところで…
    • バルーンは、会話を文字の形で表現する→会話と同じように、少しずつ画面に表示されるのが一般的。
      • その点で、文章とは若干異なる
    • せっかく改心のトークが書けたのに、見せ方が悪くて損していませんか?
      • トークの書き方そのものは扱いません
  • Tips.1 適度に間(ウェイト)を置く。
    • いわゆる「、」で一拍、「。」で二拍。(音読の練習で教わるように)
    • 実際野間の置き方は単純ではないが、バルーンでの表現では、そうした方がユーザーは混乱しないと想われる。
    • また、デベロッパーも音型を浮けやすい。(\w?タグを意識しなくて良い)
    • 里々:自動ウェイト挿入が標準機能!
      • $自動挿入ウェイトタイプ【タブ】里々(「、」→\w5、「。」→\w9)
    • YAYA:喋り記述支援ライブラリ「あやりりすEX」で、同等の機能を実現。
      • これを使うとウェイト漏れがない
  • Tips.2 トークの長さはバルーンのサイズを意識して
    • キャラにもよるが、長すぎるトークは読んでもらえないことも…
    • 1つのトークは、バルーンにスクロールなく収まる長さをメドに
    • 改行の位置にも気をつけよう(写真参照)
    • 標準的なバルーンの文字数は、\0=24文字×10行、\1=24文字5行
    • 専用バルーンの文字数がある場合はどうすれば?→SSPの開発用パレットにある「バルーンテストモード」でチェック。ドヤァ
  • Tips.3 アンカーを活用しよう
    • レチハルカ
    • 地名・人名などの説明は入れたいが、説明的な台詞回しは避けたいもの。→用語にアンカーをつけて説明を分離(実装例:http://yfrog.com/nvesquqj
    • 専門用語ゴーストでとくに有効。日常トークでは不要かも?
    • 実装例(里々):自動アンカー機能は標準機能。
      • $自動アンカー=有効 dicAnchor.txtでアンカーを定義する。
    • 実装例(YAYA):現状は完成度の高いライブラリーがない。
  • Tips.4 過ぎたるは猶及ばざる画ごとし
    • 1. テキストサイトみたいなゴテゴテした装飾は禁物
    • 2. 紛らわしいリンク(色つき文字、下線付き文字)の多用
      • どちらも一発ネタでやる分にはアリ
      • バルーンでのトーク表現であってもユーザーを混乱させるような表示や操作の要求は極力避けるべき
      • 設定状やむを得ず必要とする場合でも、あらかじめ説明しておくなどのユーザーへの配慮を忘れないように
    • ex.選択肢には必ずマーカーをつけるなど、ユーザーにわかりやすい提示方法を考えるべき
  • まとめ
    • 今回のTipsはあくまで基本形。慣れてきたら自分なりのアレンジを加えて、表現してみるのも良い
    • バルーンそのものにこだわってみるのもOK。良いモノができたら同梱するのも良い
    • バルーン作品集企画「うかとか(仮)」にも参加してみては。
  • 質疑応答
    • バルーンを常に一番手前に表示してくれれば、本体に重ねられるんだけど?
      • Windowsのウインドウ順位設定はもんのすごくめんどい。いちいちコードに書かなくてはいけない。「どれかのウインドウの一つ後ろに表示する」か、「一番前のウインドウのさらに前に固定」しかない。今後の課題。
    • バルーンを特定の位置にそろえて置いている。シェルと関係なしにバルーンの位置を固定できないか?
      • 両方の意見がある。現状はシェルごとに保存していて、ゴーストごとにも保存している。スタジオ行き(Todo送り)。一ヶ月後くらいに実装されているかも。

「moveであそぼう!〜デスクトップを動きまわるゴーストを考える〜」 - buynowforsale様

  • 自己紹介
    • 作品「エイミーとチー兄ィ」「スペースインベーダー
    • デスクトップをインベーダーが動き回るゴースト(写真)
  • デスクトップを動き回るゴーストって?
    • The Hand (moveタグ)
    • ゆっくりさんぽ (moveタグ)
    • (・∀・) (wmove.dll)
    • とことこシリーズ (winpos.dll)
    • ゆかさくら(?)
  • スペースインベーダー」ではmoveタグを利用しているが、moveって?
    • デスクトップ座標系は左上が(0,0)で、下・右へ行くと数字が増える。
    • \![move,200,fix]→デスクトップの指定座標へ動かす。(200,元のY座標)
    • \![set,alignmentとdesktop,free]→デスクトップのどの辺に固定するかを指定。
    • 移動完了までの時間を指定することも可能
    • 指示する座標の基準点も指定できる(\![move,200,-400,0,screen,left.bottom])
      • →左下の角から、右に200、下に-400(上に400)移動した点に移動する。ゴーストの\0側を基準にするなども可能。
    • サーフェスのどこを位置の基準点にするかも指定可能。(\![move,50,50,0,1,center.center])
      • 上記の例では、\0のleft.topを\1のcenter.centerにもって来る
      • \![move,50,50,0,1,center.center,center.center] のとうな書き方も可能。
    • 指示する座標の基準点も指定できる。
      • 自分自身(me)、「Sakura名/ID」で他のゴーストも指定できる。
      • キャラクターを利用した基準点指定について、surface.txtのpoint.basepos 指定を用いることができる。(デフォルトではleft.topが基準)
  • 例:ゴーストの演技として
  • moveとmoveasyncの違い
    • 扱うパラメータに差はない
    • さくらスクリプト実行時に、キャラクターの移動をスクリプトの実行に同期させるかさせないかの違い
    • 要するに、移動しながら喋り続けるかどうかの違い(asyncだと動きながらも喋る)
  • moveとSHIORiイベントを組み合わせてみる
    • スペースインベーダーの例
      • OnDisplayChangeでデスクトップの大きさを取得
      • OnSecondChangeで一秒ごとにmoveasyncで場所を移動
      • 里々での繰り返し命令を使い、\0〜\8を動かしている
  • 動きに変化をつけたい
    • 直線移動だけでなく曲線的な移動もできるとより可愛くなる
    • ふわふわと漂うように動いてみたり、円や渦巻きをぐるぐると動かす
      • 三角関数を使用する(x=t、y=sin t)
      • 円運動させる(x=cos t、y=sin t)
      • サイクロイド(x=(5-2)cos t+2 sin(1.5t)、y=(5-2)sin t+2 cos(1.5t)、
  • まとめ
    • move、moveasyncは単体で使うだけでなく、他のイベントや関数と組み合わせることでより多彩な動きをデスクトップ上で表現することができる
    • 数学や物理の知識を利用すればより豊かな動きを表現できるよ!
  • 質疑応答
    • 文系にもわかる数学の本はないですか
      • ちくま書房から最近出た「数学入門」とかオススメ。
    • 現在のシェルの位置を取得するのは?
      • ゴースト側で実装してください。
    • move中のゴーストを掴みたい
      • moveキャンセルタグをつくります。スタジオ行き。
    • moveasync中にmoveasyncすると?
      • バグります。やんな。
    • キャラクターは動かし、バルーンは動かさないようにしたいが?
      • moveasyncでは現状できない。仕様書提出してください。

「デスクトップは衰退しました 〜 Windowsストアアプリ流の開発計画の立て方」 - 駅長様

  • はじめに(開発の初期計画の話をします)
    • 開発計画の前段階、思いつきの段階
  • Windows8が発売された
    • タッチパネルUIの勢力が広がり、マイクロソフトが押され気味になっている
    • 逆転の一手としてWindows8が開発された
    • タブレットに対応する新しいUIのアプリ→Windowsストアアプリ
    • 特徴:全画面占有型、タッチ操作が基本(Windows8 Phoneとか携帯アプリを作成することも可能)
  • デスクトップは衰退しました?
    • デスクトップアプリの価値は相対的に下がった?
      • そんなことは無いとは思うgた、話は進まないので前提としてみる
    • デスクトップマスコットはどうなるのか?
      • 画面の一部を間借りすることでユーザーとの距離感を保っている
      • そもそも画面占有型アプリではない
    • ゴースト権の侵害だ!
  • Windowsストアアプリでも画面の一部を使う機能、スナップビューを利用
    • 画面の左右いずれか320pxの領域にアプリを縮小表示する機能(写真)
      • 全画面表示のアプリ以外は認めない?のか?
  • ここまで前置き。ここから、アプリを作るためのとっかかりの計画をそろえる手法の一つを紹介する
    • 参考文献
  • アジェンダ
    • アプリの長所を決める
    • サポートするユーザーのアクティビティを決める
    • アプリに含める機能を決める
    • アプリで収益を得る方法を決定する
    • アプリのUIを設計する
    • 第一印象を良くする
    • デザインのプロトタイプを作成して検証する
  • 1. アプリの長所を決める
    • 最も重要なのはアプリの特徴。何を作りたいのか?
      • スナップビューをメイン画面とする、可愛い女の子に癒されたい、二次元の嫁が欲しい、ゴースト辞書をウェブサービス連携したい、など
    • 一番の特徴を考える。アイデアを見ながら、一文で特徴をまとめる
      • 「窓のすきまからパスタさんの生活を覗きます」
      • ゴーストというキーワードはちょっと通じないものとする。とりあえずは「パスタ*1」という1ゴーストが動けばいいと考える
    • 最大の目標を決めることで、妥協すべき点もはっきりする。ゴースト切替もいつか実装したいが、まずはリリース。
  • 2. サポートするユーザーのアクティビティを決める
    • 目的に沿って、ユーザーが行う一連の操作の流れを定義
      • スナップビューにしてもらう(必須)
      • パスタさんをかわいがる
      • パスタさんの会話を眺める
      • パスタさんを触る
    • 必須項目(ここではスナップビューの説明)を漏らさないこと!
  • 3. アプリに含める機能を決める
    • ユーザーの目的を理解し、その目的を助ける方法もわかったら、次にすることは、それをじつげんするための機能を探すことです。(〜Windows ストア アプリの計画」より抜粋〜)
      • 開発環境をしら部、実現できる機能を決定する
      • まずは言語、ネイティブかHTML(マスコットアプリならHTML/JavaScriptで十分か? Windows以外でも動かせる可能があるし…)
    • 操作系や表現で今回重要視した機能
      • タッチの検出方法
      • 縦書き表現
    • (余談)WebKitでは縦書きバグっている。アニメーションさせると表示が死ぬ。→IE9限定というものすごい縛りのHTML
  • 4. アプリで収益を得る方法を決定する
    • 対価は必ず必要(お金である必要はない)
    • なんでもいいから、モチベーション維持ができる対価があることを必ず意識する
  • 5. アプリのUIを設計する
    • マスコットアプリなので「かわいらしい立ち絵」大事
    • 絵心が無い場合はフリーシェル。(写真)
  • 6. 第一印象を良くする
    • 「この絵に縦書きの恥ずかしいメッセージが流れまくったら絶対萌えるだろう!」(このへんは勢いが大事)
    • 一般的な注意事項
      • 最低限の操作以外は説明しない。ユーザーに発見させるUIであること、無理にすべての機能を使わせる必要はない
      • ユーザーは常に見てはいない。マスコットはチラ見が基本。選択肢を出す場合でも必須にならない工夫が必要。
  • まとめ
    • 計画がそろっていれば、開発のぶれを押さえられる
    • 7つの項目の考える順はこの通りじゃなくても大丈夫
    • 「ゴーストの開発」でも使える
    • わかりやすい資料なので一読することをおすすめする
  • あと作る必要があるもの
    • まともな栞システム
    • ちゃんとしたタッチ反応
    • 辞書
    • えちょの冒険は始まったばかりか!
  • 質疑応答
    • ネイティブコードで書くと問題があるのか?
      • 書けるが、DirectXになる。これまでのWindowsデスクトップはGDI利用だったが、今後GDIは使われなくなる予定。やるなら描画をDirectXに持って行く?
      • 10年後にWindowsが生きてるかどうかもわからない。
    • Windows8のアプリにした場合、narとかの考え方はなくなるのか?
      • Microsoftのアプリ配布所に登録しないといけないことになっている。アプリ作成も完全無料というわけにはいかないと思う。
      • 配布するとしたらベースウェアとゴーストの一体配布?
    • スナップビューを表示するには?
      • メイン画面が1024ピクセル以上ないといけない。(つまり、1024+320ピクセル以上の横幅の画面が必要)
    • これまでのデスクトップとの関係は?
      • デスクトップが1つのアプリになっている
    • ディスカッションできるの?
      • ディスカッションは衰退しました。

最近の動向

まとめ

  • 次回、横浜! フィーネさんと契約してスピーカーになってよ!
  • このあと懇親会
  • 実況はここまでです。ありがとうございました!

*1:もちろん、スパゲッティコードが由来

「ユーザーに愛されれるデベロッパーになるために 〜 ゴースト製作初心者のための簡単Windowsセキュリティ術」 - ミヤノ様

  • 背景
    • コンピュータウィルスによる事件が取りざたされているが、伺かユーッザとしては何を気をつければいいのか?
    • セキュリティソフトやセキュリティ対策というものがよくわからない…
  • セキュリティソフトを導入する理由
    • コンピュータウイルスの感染防止→narファイルの配信で感染源(加害者)にならないため。
    • もし知らずにウイルス入りnarをアップロードしてしまったら、今後あなたのゴーストを入れてくれる人がいなくなるかもしれない。
  • 過去にも事例がある
    • マルウェアに幹線し、ゴーストのフォルダに有害な「folder.htt」が入ってしまっていた。
    • ちなみにSSPはfolder.httやdesktop.iniを削除して解凍処理している。ドヤァ!
  • なので、こうならないためにも、セキュリティソフトをインストールしよう!
  • どう使い分けるの?
    • 最低限のものだけ欲しい=アンチウィルス。無料のセキュリティソフトはほとんどがこっち
    • 面倒臭くないものが欲しい=総合セキュリティソフト。有料はこっちもある
  • 有料と無料どっちを使えばいい?
    • 無料だからといってウィルスの検出率が悪いというわけではない。中には有料ソフト並のものもある。
    • 無料のソフトは使い方にテクが必要なことも。
  • 伺か的セキュリティ
    • narアーカイブやネットワーク更新ファイルをアップロードする時は、必ずこれらをウイルススキャンしてから!
    • これができる人はユーザーさん想いの一流デベロッパーになったも同然!
    • できるデベロッパーとして一目置かれる存在に!
    • 具体的な資料やセキュリティソフトの違いはサイトに掲載するので詳しい情報はそちら。
  • まとめ
    • 伺かの未来を作るのはあなたです
    • 皆様のすばらしい伺かライフの一助になれば幸いです。