うかべん大阪 #9 実況
本日5月3日(日)、伺的ソフトウェア勉強会(うかべん) 大阪 #9 が実施されます。
というわけで恒例のテキスト実況をおこないますので皆様よろしく。
【この記事の内容について】
この記事は、私がスピーカーの皆さんの発表を聞き、自分なりに理解し、かみ砕いて書き下し(ていませんが)、感想を付け加えたものです。
(各発表の冒頭にある「概要」と末尾にある「感想」は、私自身の意見・感想です。)
とくに私の理解力不足により、スピーカーの皆さんが発表された内容と相違している可能性があります。
誤りや問題点がありましたら、コメント・拍手等でご指摘ください。
また、公式記録ではありません。ご了承下さい。
【Ustream実況中】
http://t.co/qIPXq2IfV2 にアクセスしてください。
第一部 13:15〜
本日のおしながき
「トーク数を水増しするゴーストの作り方」 - りすな 様
- 概要
- 外面と内面にギャップを作る
- 食べ物の話をさせる
- 食べ物の話をさせる
- 人は共通の話題だと話しが話がはずみやすい
- 食事は「相手を選ばない共通の話題」
- 人は食事に対して何らかの考えを持っているものだ→ネタにしよう!
- 食事をトークネタにする方法
- キャラクターに好きな食べ物、嫌いなものの話をさせる
- 食糧事情について
- 料理について
- お店で食べ物を食べたときの話
- 滅多に食べられないような珍しい食べ物の話 など
- 実例
- 燃える稲穂(ラーメン)、ラベンダー畑(パスタ)、どっかのゴースト(いも)←原文ママ
- 自分のゴーストに食べ物トークがないなあと思ったら実装してみよう! 造るの比較的楽!
- 食べ物を食べないキャラクターの場合は?
- 食事しない場合も、料理をするとか、食事に対する関心とかの話は可能だろう
- 外面と内面にギャップを作る(新規のゴーストを作る人向け)
- トークを作る際に話しのネタになる
- ギャップから「なぜ」が生まれる、その「なぜ」が話のネタになる
- 汎用性が高い
- ギャップを作る方法→?イメージに反抗する
- 見た目のイメージを裏切る
- 人の印象の多くは見た目から決まるらしい。見た目は大切
- イメージを裏切る方法について
- イメージに反抗する方法
- 見た目を用意する(セーターを着ているキャラクター)
- 見た目から連想される言葉を挙げる(寒い、冬)
- 連想された言葉からかけ離れたものを考える(暑い、夏)
- 夏場でもセーターを着ているキャラクター
- なぜ夏場でもセーターを着ているのか?
- その方がかっこいいと思っているから
- 特殊な毛糸で邪悪な力を封じている
- セーターに見えていたのは体毛
- 信じられないくらいの寒がり
- なぜ夏場でもセーターを着ているのか?
- こうして出来た珍妙な特徴に対して、ゴーストに感想を述べさせることでトークネタになる。
- キャラクターが複数出てくる場合、それぞれの立ち位置(意見)を違えることで、さらにトークが増える
- 見た目から生まれる一般的なイメージを大事にする
- イメージに反抗するキャラクターの実例(ヴァンプ将軍)
- 世界征服を企図する悪役なのに「家庭的」「近所づきあいが大事」「理想の上司」 etc.
- ギャップが与えるもの
- 何もしなくてもすでにキャラクターにはギャップが存在する
- このギャップ(不自然さ)を利用した人→手塚治虫「鉄腕アトム」
- 天馬博士は交通事故で死亡した息子、トビオに似た感情豊かで高性能なロボットを作った。が、成長しないことに怒ってサーカスに売り飛ばした。(ヒドイ)
- 漫画のキャラクターが人間として描かれているにもかかわらず、成長しないことに対して多くの人が不自然に思うのと同じ描かれ方
- 「生き物として描かれているのに成長しない存在」への不自然さを利用して、天馬博士の怒りに説得力を与えている
- 読者が漫然と感じてきたであろう不自然さを(再)発見した
- ギャップを作ることで、トークネタを水増しできるだけではなく、感情表現に深みを持たせることすらできる。
「共同作業に使えるオンラインストレージの使い方」 - 高見知英 様
- 自己紹介
- もくじ
- インターネットストレージとは?
- ストレージサービスを使った共同作業
- 作業を補完するツールについて
- はじめに
- ゴースト関連ファイル管理をどうしている?
- 複数人で共同制作をするときどうしてます?
- →インターネットストレージサービスを使うとファイル管理などをやりやすい!
- インターネットストレージとは?
- インターネット上にPC上のファイルを保管するサービス
- Yahooブリーフケース、ATOKオンラインストレージ、etc...
- 昔:ファイルを手作業でアップロード
- 今:特定のフォルダ内のファイルを自動的に同期 <近頃増えてきた!>
- インターネット上にPC上のファイルを保管するサービス
- どんな動作をする?
- ローカルPCの特定フォルダに新しいファイルを作ると→インターネットにも作られる
- ローカルPCのファイルを編集すると→インターネットも修正される
- PC AとPC Bのシンクも可能
- 今回紹介するサービス
- Dropbox, SugarSync, SkyDrive, Google Drive
- SugarSync
- 5GB〜有料プランで500GBまで共有可能
- 日本法人があり、日本円で支払い可能、若干高い
- 複数のフォルダをインターネットに共有できる。柔軟な設定が可能。若干めんどうなところがある
- SkyDrive(Microsoft)
- 7GB〜有料プランで最大107GB(初期登録特典は25GB)
- マイクロソフトのサービス。Winows8からはOS機能として利用可能。8,1からOSに統合
- Officeファイルの連携に強い「このファイルは○○さんが使用しています」とか出てくれる
- Office2013から保存先として標準装備
- 大量のファイルのアップロードがとにかく速い
https://pbs.twimg.com/media/BYH2QvdCIAAGIhS.jpg
- ストレージサービスを使った共同作業
- オンラインストレージの「共有」機能
- Webから特定のフォルダを「共有」に設定
- Dropbox、SugarSync
- Web上の「フォルダに招待」からメールアドレスを入力することで共同作業者を招待できる
- Google Drive
- オーナーと共同編集者、見るだけの人、などの設定を細かく出来る
- 共有(招待)の方法は前者と同様。
- 読み取り専用のURLを作成できる。(パブリックリンクの共有)
- 明示的にリンクURLを削除できる(期間限定公開など)
- 高見さんの例
- 補完するツール
- まとめ
- 質疑
- 一時期、Google Driveの規約について取りざたされたことがあったが、実際どうなのか?
- 本人は「Don't be evil」と言ってるので使ってもいいんじゃないかな。でもあんまり信用していないから自分ではあんまり使ってません。
- ファイルのバージョン管理をしたい場合は SubVersionなどを使った方がいいのか?
- 他にもGit(バージョン管理)などのバージョン管理可能なツールもある。(だが難しい)
- Google Drive なども一つ・二つ前くらいのバージョンは残る
- 以前、SubVersionをはやらそうとしたがはやらなかった。Dropboxは今も使ってる人もいる。(使いやすい)
- DropboxとSubVersionは同居させない。慢心、絶対ダメ!
- シンボリックリンクも危険! データ消えます!(サイズが同じで真っ白なファイルができあがったりする)→シンボリックリンク先を消したため。(シンボリックリンクを拒絶するサービスもある)
- 一時期、Google Driveの規約について取りざたされたことがあったが、実際どうなのか?
「グループ制作のススメ 〜みんなでやればこわくない〜」 - 八神 翔太 様
- 自己紹介
- 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でシステムを組んだ。
- OTRSって入れやすい?
-
- 進捗どうでしょう?
- ダメです。
- 進捗どうでしょう?
-
- 複数人で台本を制作すると、書いた人の間で口調・主題・状況などの食い違いが発生すると思うが?
- みんなで読み合わせて修正する。
- 複数人で台本を制作すると、書いた人の間で口調・主題・状況などの食い違いが発生すると思うが?
-
- 多人数でやっていると声の大きい人が権力を握ったりしないか?
- 距離感は気をつけている。近づきすぎる離れすぎず、というバランス感覚が大事。長い時間をかけて醸成する必要がある。
- 多人数でやっていると声の大きい人が権力を握ったりしないか?
「ゴースト間の交流について 〜暦にしき宣伝添え〜」 - もっしょくし 様
- テーマ
- おことわり
- 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」というタイミング機能もある。(トーク終了の合図)
- 暦にしきに機能あり!(デモ)
- OnOther系イベント
- 他のゴーストの状態を監視できてしまうイベント。色々な種類がある
- とてもヤンデレと相性がいい(ex. 耶美、奏、etc..)
- 起動、終了、サーフェス変更、、などいろいろ取れる
- やれることのポテンシャルはあると思うが、結構使い勝手にはクセがある
- OnOtherGhostTalk:オーナードローメニュー操作など、広範囲のイベントが流れ込んでくる
- OnOtherOverlap:他のゴースト同士が重なっている情報が流れてくるが、referenceの形が独特。
- sakura名/ID番号-sakura名/ID番号 的なものが流れてくる
- 里々の自動計算仕様: 54/0 → ゼロ除算エラー! >轟沈<
- 必ず文字列加工が必要になる。→里々では実装が難しい >轟沈<
- 他のゴーストの状態を監視できてしまうイベント。色々な種類がある
- 関連する手法
- 切替反応やコミュニケートをフラグにする
- installedghostnameの内容も見て他のゴーストへの切替を勧める、など
- →(一部)里々の情報取得変数でも利用できる
- プロパティシステム
- 他のゴーストのsakura名、パス、などを取得することができる
- データ読み
- (yayaでは)相手のゴーストのパスがわかれば全てのテキストを読める
- あんまり行儀がよくない方法なので扱い注意。ウイルス的挙動すら可能。
- mopでも各ゴーストのmopデータを読んでいる
- デモ(こわい)
- まとめ
- 絡み方にも色々ある
- 性的なコンテンツと動的なコンテンツ
- 対応してくれるゴーストが増えればどこまでも広がっていく
- 投げっぱなし? 打ち合わせ必要? いろいろな手法がある
- 「情報取得」が多様な絡み方を考える鍵
- 取得できる情報
- 積極的に提供される譲歩(OnOther〜系のreferenceなど)
- 絡み方にも色々ある
- 今回の本当の主張
- 手段を知るべき機会はHowToだけではない(何か目的があって知識を探す、だけではない)
- 何もやりたいことがなくても、里々wikiとかを流し見するとおもしろいネタが見つかるかも!
- デモゴーストはうかべんサイトで公開予定
「ゴーストの作成とその後のこと 〜持続可能な開発の実現を目指して〜」 - みゆ様
- 自己紹介
- 3年目のゴーストマスター、学生
- ソロゴ4隊、合作ゴースト1隊、トーク寄与 などなど
- はなすこと
- 里々を使ったゴースト制作のsわりからその先
- 里々を用いたゴーストの作り方
-
- セルフテンプレートゴースト
- 自分用の複数隊作るときの素体となるゴースト
- 自分が構築しなおすので、辞書構造や必要なものが理解できる
- 自分で構造が把握できる。バグ修正のときに有効
- 最初に作るの面倒
- セルフテンプレートゴースト
-
- 一体目はテンプレゴーストをもとに作り、二体目以降はセルフテンプレゴーストをもとに使うとよい
- トークの出し方
- 更新を続ける上で
- 自分にあった更新頻度を見つける
- どれくらい更新に時間を割けるか?
- ゴーストのキャラクターを忘れるのはどれくらい?
- 自分にあった更新頻度を見つける
-
- 普段かける時間
- トーク=5〜30分、レシピ30〜1時間、合計1時間程度
- 困ったときのはなし「トークがでない」
- 困ったときのはなし「バグがとれない」
- 困ったときのはなし「モチベーションが維持できない」
- 3〜4日くらい辞書に触れないようにして休む。それ以上放置するとガチで面倒になる)
- 他に楽しいことを見つける。(なるべくゴーストのネタになりそうなことで9
- 無理矢理更新しよう
- ちょっとしたことでも更新してみよう
- モチベーションが維持できなくて困ってる人を見かけたら
- ユーザとして出来ることをして応援してみよう
- ブログなどにコメント
- うわひょ、など
- 更新する時間がないとき
- 大きな更新でなければ案外時間はある
- ネタを書き留めるモノを常に持ち歩く
- 本当に時間がないときはやめておこう
- まとめ
- これかもよきゴーストライフを!
- 質疑
- サンプルゴーストはいつ公開?
- 触り反応が30個くらいになったら公開! R-13!
- サンプルゴーストはいつ公開?
うかべん横浜 #8 実況
本日11月3日(日)、伺的ソフトウェア勉強会(うかべん) 横浜 #8 が実施されます。
というわけで恒例のテキスト実況をおこないますので皆様よろしく。
【この記事の内容について】
この記事は、私がスピーカーの皆さんの発表を聞き、自分なりに理解し、かみ砕いて書き下し(ていませんが)、感想を付け加えたものです。
(各発表の冒頭にある「概要」と末尾にある「感想」は、私自身の意見・感想です。)
とくに私の理解力不足により、スピーカーの皆さんが発表された内容と相違している可能性があります。
誤りや問題点がありましたら、コメント・拍手等でご指摘ください。
また、公式記録ではありません。ご了承下さい。
「ユーザーに愛されれるデベロッパーになるために 〜 ゴースト製作初心者のための簡単Windowsセキュリティ術」 - ミヤノ様
- 背景
- コンピュータウィルスによる事件が取りざたされているが、伺かユーッザとしては何を気をつければいいのか?
- セキュリティソフトやセキュリティ対策というものがよくわからない…
- セキュリティソフトを導入する理由
- コンピュータウイルスの感染防止→narファイルの配信で感染源(加害者)にならないため。
- もし知らずにウイルス入りnarをアップロードしてしまったら、今後あなたのゴーストを入れてくれる人がいなくなるかもしれない。
- 過去にも事例がある
- なので、こうならないためにも、セキュリティソフトをインストールしよう!
- 何を使えばいいの?〜アンチウィルスソフトと総合セキュリティソフト
- アンチウイルスソフト=ウィルスの感染防止を担う。警備員やお巡りさんみたいなもの
- 総合セキュリティソフト=アンチウイルスソフトと一緒にさらにお役立ちソフトが入っている。お巡りさんにメイドさんもついてくる
- ファイアウォール、迷惑メール対策、有害サイト接続防止、等
- どう使い分けるの?
- 最低限のものだけ欲しい=アンチウィルス。無料のセキュリティソフトはほとんどがこっち
- 面倒臭くないものが欲しい=総合セキュリティソフト。有料はこっちもある
- 有料と無料どっちを使えばいい?
- 無料だからといってウィルスの検出率が悪いというわけではない。中には有料ソフト並のものもある。
- 無料のソフトは使い方にテクが必要なことも。
- 伺か的セキュリティ
「デスクトップは衰退しました 〜 Windowsストアアプリ流の開発計画の立て方」 - 駅長様
- はじめに(開発の初期計画の話をします)
- 開発計画の前段階、思いつきの段階
- Windows8が発売された
- デスクトップは衰退しました?
- デスクトップアプリの価値は相対的に下がった?
- そんなことは無いとは思うgた、話は進まないので前提としてみる
- デスクトップマスコットはどうなるのか?
- 画面の一部を間借りすることでユーザーとの距離感を保っている
- そもそも画面占有型アプリではない
- ゴースト権の侵害だ!
- デスクトップアプリの価値は相対的に下がった?
- Windowsストアアプリでも画面の一部を使う機能、スナップビューを利用
- 画面の左右いずれか320pxの領域にアプリを縮小表示する機能(写真)
- 全画面表示のアプリ以外は認めない?のか?
- 画面の左右いずれか320pxの領域にアプリを縮小表示する機能(写真)
- ここまで前置き。ここから、アプリを作るためのとっかかりの計画をそろえる手法の一つを紹介する
- 参考文献
- アジェンダ
- アプリの長所を決める
- サポートするユーザーのアクティビティを決める
- アプリに含める機能を決める
- アプリで収益を得る方法を決定する
- アプリのUIを設計する
- 第一印象を良くする
- デザインのプロトタイプを作成して検証する
- 1. アプリの長所を決める
- 2. サポートするユーザーのアクティビティを決める
- 目的に沿って、ユーザーが行う一連の操作の流れを定義
- スナップビューにしてもらう(必須)
- パスタさんをかわいがる
- パスタさんの会話を眺める
- パスタさんを触る
- 必須項目(ここではスナップビューの説明)を漏らさないこと!
- 目的に沿って、ユーザーが行う一連の操作の流れを定義
- 3. アプリに含める機能を決める
- ユーザーの目的を理解し、その目的を助ける方法もわかったら、次にすることは、それをじつげんするための機能を探すことです。(〜Windows ストア アプリの計画」より抜粋〜)
- 開発環境をしら部、実現できる機能を決定する
- まずは言語、ネイティブかHTML(マスコットアプリならHTML/JavaScriptで十分か? Windows以外でも動かせる可能があるし…)
- ユーザーの目的を理解し、その目的を助ける方法もわかったら、次にすることは、それをじつげんするための機能を探すことです。(〜Windows ストア アプリの計画」より抜粋〜)
- 4. アプリで収益を得る方法を決定する
- 対価は必ず必要(お金である必要はない)
- なんでもいいから、モチベーション維持ができる対価があることを必ず意識する
- 5. アプリのUIを設計する
- マスコットアプリなので「かわいらしい立ち絵」大事
- 絵心が無い場合はフリーシェル。(写真)
- 6. 第一印象を良くする
- 「この絵に縦書きの恥ずかしいメッセージが流れまくったら絶対萌えるだろう!」(このへんは勢いが大事)
- 一般的な注意事項
- 最低限の操作以外は説明しない。ユーザーに発見させるUIであること、無理にすべての機能を使わせる必要はない
- ユーザーは常に見てはいない。マスコットはチラ見が基本。選択肢を出す場合でも必須にならない工夫が必要。
- 7. デザインのプロトタイプを作成して検証する
- 動作サンプル(写真 http://yfrog.com/oer0jibcj)
- デバッグモード(写真 http://yfrog.com/nvmw8mpj)
- まとめ
- 計画がそろっていれば、開発のぶれを押さえられる
- 7つの項目の考える順はこの通りじゃなくても大丈夫
- 「ゴーストの開発」でも使える
- わかりやすい資料なので一読することをおすすめする
- あと作る必要があるもの
- まともな栞システム
- ちゃんとしたタッチ反応
- 辞書
- えちょの冒険は始まったばかりか!
- 参考文献
- 質疑応答
- ネイティブコードで書くと問題があるのか?
- Windows8のアプリにした場合、narとかの考え方はなくなるのか?
- スナップビューを表示するには?
- これまでのデスクトップとの関係は?
- デスクトップが1つのアプリになっている
- ディスカッションできるの?
- ディスカッションは衰退しました。
最近の動向
- ガチガチにプログラマ向けな栞が出た「灯(あかり)」http://le.silk.to/
- わしづかみ
まとめ
- 次回、横浜! フィーネさんと契約してスピーカーになってよ!
- このあと懇親会
- 実況はここまでです。ありがとうございました!
「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,200,-400,0,screen,left.bottom])
- moveとmoveasyncの違い
- moveとSHIORiイベントを組み合わせてみる
- スペースインベーダーの例
- OnDisplayChangeでデスクトップの大きさを取得
- OnSecondChangeで一秒ごとにmoveasyncで場所を移動
- 里々での繰り返し命令を使い、\0〜\8を動かしている
- スペースインベーダーの例
- 動きに変化をつけたい
- まとめ
- move、moveasyncは単体で使うだけでなく、他のイベントや関数と組み合わせることでより多彩な動きをデスクトップ上で表現することができる
- 数学や物理の知識を利用すればより豊かな動きを表現できるよ!
- 質疑応答
- 文系にもわかる数学の本はないですか
- ちくま書房から最近出た「数学入門」とかオススメ。
- 現在のシェルの位置を取得するのは?
- ゴースト側で実装してください。
- move中のゴーストを掴みたい
- moveキャンセルタグをつくります。スタジオ行き。
- moveasync中にmoveasyncすると?
- バグります。やんな。
- キャラクターは動かし、バルーンは動かさないようにしたいが?
- moveasyncでは現状できない。仕様書提出してください。
- 文系にもわかる数学の本はないですか
「バルーンというインターフェース 〜 トークを表現するためのTips」 - NOBニャー様
- ゴーストにとってバルーンとは?
- ゴーストは、バルーンを使って話す(トーク)
- ゴーストは、バルーンを使って機能を提供する(メニュー等)
- ゴーストにとって、バルーンはユーザーとの「重要なインターフェース」(※ごく一部に例外もいるが…)
- ex.握江トク(発生と同時にバルーンも表示)
- ところで…
- Tips.1 適度に間(ウェイト)を置く。
- いわゆる「、」で一拍、「。」で二拍。(音読の練習で教わるように)
- 実際野間の置き方は単純ではないが、バルーンでの表現では、そうした方がユーザーは混乱しないと想われる。
- また、デベロッパーも音型を浮けやすい。(\w?タグを意識しなくて良い)
- 里々:自動ウェイト挿入が標準機能!
- $自動挿入ウェイトタイプ【タブ】里々(「、」→\w5、「。」→\w9)
- YAYA:喋り記述支援ライブラリ「あやりりすEX」で、同等の機能を実現。
- これを使うとウェイト漏れがない
- Tips.2 トークの長さはバルーンのサイズを意識して
- Tips.3 アンカーを活用しよう
- レチハルカ
- 地名・人名などの説明は入れたいが、説明的な台詞回しは避けたいもの。→用語にアンカーをつけて説明を分離(実装例:http://yfrog.com/nvesquqj)
- 専門用語ゴーストでとくに有効。日常トークでは不要かも?
- 実装例(里々):自動アンカー機能は標準機能。
- $自動アンカー=有効 dicAnchor.txtでアンカーを定義する。
- 実装例(YAYA):現状は完成度の高いライブラリーがない。
- Tips.4 過ぎたるは猶及ばざる画ごとし
- まとめ
- 今回のTipsはあくまで基本形。慣れてきたら自分なりのアレンジを加えて、表現してみるのも良い
- バルーンそのものにこだわってみるのもOK。良いモノができたら同梱するのも良い
- バルーン作品集企画「うかとか(仮)」にも参加してみては。
- 質疑応答
- バルーンを常に一番手前に表示してくれれば、本体に重ねられるんだけど?
- Windowsのウインドウ順位設定はもんのすごくめんどい。いちいちコードに書かなくてはいけない。「どれかのウインドウの一つ後ろに表示する」か、「一番前のウインドウのさらに前に固定」しかない。今後の課題。
- バルーンを特定の位置にそろえて置いている。シェルと関係なしにバルーンの位置を固定できないか?
- 両方の意見がある。現状はシェルごとに保存していて、ゴーストごとにも保存している。スタジオ行き(Todo送り)。一ヶ月後くらいに実装されているかも。
- バルーンを常に一番手前に表示してくれれば、本体に重ねられるんだけど?