うかべん大阪 #9 実況


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


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


Ustream実況中】
http://t.co/qIPXq2IfV2 にアクセスしてください。

第一部 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は今も使ってる人もいる。(使いやすい)
      • DropboxSubVersionは同居させない。慢心、絶対ダメ!
      • シンボリックリンクも危険! データ消えます!(サイズが同じで真っ白なファイルができあがったりする)→シンボリックリンク先を消したため。(シンボリックリンクを拒絶するサービスもある)

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

  • テーマ
    • やれるひとがやれることをやれるように
    • 伺かは一人作業が多く限界、現状をどうするか
    • アイシーエスの実際の作業から、活用できるノウハウや考え方を説明する
  • 自己紹介
    • 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

  • 実際のやりとり
  • まとめ
    • 多人数の制作はおもしろい! 面白いことを伝えていくのが創作
    • より多くの人に制作に携わってもらうことで、おもしろさ・楽しさを伝えていくのが当サークルの役割
      • もともと「何か」は「広める」がテーマ!
  • 質疑
    • 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時間程度
  • 困ったときのはなし「トークがでない」
    • トークの出し方を参考に。それでもでないときはPCを閉じて頭を冷やす、寝る。
    • 複数ゴーストを作る。トークを作りやすいゴーストを作る、普段から立てる。
  • 困ったときのはなし「バグがとれない」
  • 困ったときのはなし「モチベーションが維持できない」
    • 3〜4日くらい辞書に触れないようにして休む。それ以上放置するとガチで面倒になる)
    • 他に楽しいことを見つける。(なるべくゴーストのネタになりそうなことで9
    • 無理矢理更新しよう
    • ちょっとしたことでも更新してみよう
  • モチベーションが維持できなくて困ってる人を見かけたら
    • ユーザとして出来ることをして応援してみよう
    • ブログなどにコメント
    • うわひょ、など
  • 更新する時間がないとき
    • 大きな更新でなければ案外時間はある
    • ネタを書き留めるモノを常に持ち歩く
    • 本当に時間がないときはやめておこう
  • まとめ
    • これかもよきゴーストライフを!
  • 質疑
    • サンプルゴーストはいつ公開?
      • 触り反応が30個くらいになったら公開! R-13!

うかべん横浜 #8 実況


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


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

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

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

「デスクトップは衰退しました 〜 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:もちろん、スパゲッティコードが由来

「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では現状できない。仕様書提出してください。

「バルーンというインターフェース 〜 トークを表現するための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送り)。一ヶ月後くらいに実装されているかも。