前半の部
「システム開発から見たゴースト開発」 - フィーネ・ラグサズ
- 前説
- 今回で横浜も5回目。なんか気分いいですね！
- 懇親会参加率も9割以上！にぎやかになるといいですね！
- 概要
- システム開発の流れ
- 要件定義＝どんなものが欲しいのか整理すること
- 基本設計＝どんな形（インタフェース、データ形式）がいいかを大まかに設計すること
- 詳細設計＝基本設計を元にして細かく画面や機能の設計図を書くこと
- 実装＝プログラム本体を作る。コーディング、リソース作成
- テスト＝バグ探しと修正、一番大変とも言われる
- リリース＝完成。納品。この後契約に応じて修正や機能追加もある
- ゴーストの開発にあてはめると…？
-
- 基本設計・詳細設計＝性格は？シェルは？搭載機能は？SHIORIは？ねとわくは？
- 本来なら設計図を書くのだが、ゴーストではそんなの書かなくてもOK
- 基本設計・詳細設計＝性格は？シェルは？搭載機能は？SHIORIは？ねとわくは？
-
- 実装・テスト・リリース＝そのまんま。
- とくにイベント等はテスト必須（しないとどうなるか身を持って知った）
- 実装・テスト・リリース＝そのまんま。
- 応用できそうなこと
- 辞書を書くときに役に立ちそうなネタ
- わかりやすい名前をつける
- 書き方（コーディング）に規則性を持たせる
- コメントをつける
- 辞書を書くときに役に立ちそうなネタ
-
- 関数などにわかりやすい名前をつける
- 一文字変数はやめよう（ a, i, hensu1 ）
- 意味のある単語を使おう（ useNm＝ユーザー名 ）
- →意味が通る範囲で母音を省略するなどして、短い変数名にするのが通例。
- 関数などにわかりやすい名前をつける
-
- 書き方に決まりをつくろう
- 改行やカッコの使い方を全体で統一する。辞書の書き方はかなり自由度が高い。
- 書き方に決まりをつくろう
-
- コメントをつけよう
- だいたいの栞では辞書にコメントを挿入できる。実行時は無視されるので何を書いてもいい。
- 「明日の自分は今日の自分とは別の人」といいます！ 一年後に見返すとコメントなしでは理解できません
- 関数の機能、引数の定義、if条件の中身（ここはどんな条件？）
- コメントに愚痴とか書くとユーザにも読めるので注意！
- コメントをつけよう
- まとめ
- システム開発の流れとゴースト開発の流れは似ている
- 段階を追って考えるやり方は流用できる
- 辞書を書く際はルールを決めると読みやすくなる
- 名前はわかりやすく
- 書き方に規則をつける
- コメントをつける
- システム開発の流れとゴースト開発の流れは似ている
- 質疑応答
-
- ループに i とか使うのは？
- その場限りで短い変数を使うのはあり。（ for ($i=1;$i<$length;$i++)
- ただ、たとえば好感度を「$L」などで表すのは好ましくない。後で見て意味がわからない。
- ループに i とか使うのは？
- 感想
- コメントアウトで使わなくなったコードを隠したりしますが、本当はあまり良くないのですよね…。
「Ghostの設計と進化」 - C.Ponapalt
- 自己紹介
- 伺かデータランタイム「ベースウェア」SSPの現開発者（初代はDoiChan!氏）
- http://ssp.shillest.net/
- 通称「所長」「バグのひと」もはやエンバグが持ちネタ
- 概要
- 全体構造の外観（おさらい）
- （全体概要）
- （外部通信）
- 見た目（Shell）と中身（Ghost）の分離
- 互いの制御は「本体」を介さないとできない（制御用はSakuraScript経由）
- 昔はShellしかなかった
- 元々はShellが複数、Ghostは1つだった。（口調語尾変更機能はこのへんがモト）
- 内部処理用実装（Shiori、Saori、Makoto、Plugin）…中で何をやっているのか？
- 中身はただのDLL。（細かいことはスライド参照）
- インタフェース（戸口）は「load、unload、request」の3つのみ。
- うち、本当に働いているのはrequestのみ
- BOOL load(HGLOBAL h. LONG len)
- hの中身は「データを読み込むパス」へのポインタ、通常DLLの場所と同じ
- lenはパスの長さ。（hは冒頭の場所だけを示しているため、パスの長さを指定）ゼロ終端ではない
- ゼロ終端であること前提の処理をするとDLLが原因で落ちることがある。
- ただしSSPではこっそり最後に\0をつけてるので大丈夫
- BOOL unload(void)
- 解放時に呼び出される。
- 失敗（返値FALSE）でも誰も面倒見ない（あとは野となれ山となれ）
- 中身はただのDLL。（細かいことはスライド参照）
- 利点欠点
- 利点＝とにかく超高速
- プロセス間通信やソケットやその他複雑な仕組みは一切ないので高速
- 同じメモリ空間内でデータを行ったりきたりさせるだけ（YAYAの関数呼び出しなんかより全然速い）
- 実装もずいぶん楽
- 欠点＝子亀こけたら親亀も…
- DLL内で不具合があればアプリごと落ちる
- DLLを別プロセスにすれば大丈夫（ex.Google Chrome）だが、互換性が…
- 別プロセスにすると、たとえばosuwari.dllなどは動作しない。（他のウインドウの情報を得られなくなるため）
CROWはそういう実装
- 利点＝とにかく超高速
- その他終端
- 続きはウェブで！（流されました）
- なぜゼロ終端ではなく長さ指定なの？
- なぜ _cdecl なの？
- そのた
- 外部との通信（SSTP = Sakura Script Transfer Protocol）
- SocketSSTPとDirectSSTP
- DSSTPの仕組み
- IPC用ウインドウメッセージを打ち込む
- SendMessage(相手先hwnd, WM_COPYDATA, 自分のhwnd,COPYDATASTRUCTポインタ)
- IPC用ウインドウメッセージを打ち込む
- 現状の問題点
- キャラリナ
- Apricot
- デジタルスプライト（ぐぐれ）
- まとめ
- 機能強化
- ゆるい結合の利点
- 疎結合の利点を損ねない拡張
- ゆるい結合の利点とは
- 柔軟なデータの変更（追加Shellとか）
- 開発が楽な「まるなげ」構造」
- 同時に考えなくてはいけないものが少なくてすむ
- 「イベント駆動」、「Model-View-Controller」→開発を楽にするための一般的構造
表示部分、データ部分、それらを制御する部分にわけられる - 「オブジェクト指向」の根幹にも通じる
- 機能の強化
- 表現力強化
- 「ふきだしアニメーション」「バルーン内のリッチテキスト」「Shellにテキスト入れたい」
- こういう拡張は「結合がゆるいまま」、する必要がある
- 動的Shell定義機能、噴出しへの過度な拡張などはちょっと危険
- そのような点を重視しながら開発をしている。ので、機能要望する側もすこーしだけ考えてね！
- 表現力強化
「例の検索システムを里々で作ってみた」 - yamagashi
- 「例の検索システム」とは？
- うかべん横浜#4でのないんないん氏の発表（http://d.hatena.ne.jp/hinoharu/20091108）
- ゴーストが検索語句を受け取り、googleの検索引数につっこんで、ブラウザのかわりに検索をする
- 返ってきたHTMLを解析し、ユーザに提示する（もしくはブラウザで結果を表示する）
- まずメニューから検索エンジンを選択（google、yahoo、wikipediaなど）
検索エンジンに対応するURLはゴーストに内蔵されている。 - OnUserInputイベントを使用し、検索語句をユーザに入力させる
- 検索エンジンのURLとユーザの入力した検索語句を合成し、\![open,brouser,...]タグへ突っ込む
- エラー処理
- 入力された検索語句が""（なにもない）場合
- 例1）トップページURLを用意しておけば、トップページに飛ぶようにする
- 例2）ランダム用語で検索する（これだからマサオは etc）
- 入力された検索語句が""（なにもない）場合
- 質疑応答
- 検索結果表示をブラウザに任せるのではなく、ゴースト内でdigestして表示できないか？
- がんばればできるかも？やってみる。
- 検索結果表示をブラウザに任せるのではなく、ゴースト内でdigestして表示できないか？
「今日から役に立つ（かもしれない）豆知識」 - 神夜みゅん
- 概要
- SSPの一部機能をおさらい。
- 開発パレット＝今や必須の機能！
- 利点
- サーフェス一覧が簡単にチェックできる
- エラーログ表示させバグ拾いができる。
- 当たり判定表示でシェル作成時にも確認可能
- 欠点？
- 常に表示させておくとちょっと邪魔！（ぽな「小さくする仕様書書いてください」）
- 利点
- 本体設定
- フォルダ設定（ゴーストフォルダ、バルーンフォルダ他）
- 利点
- たくさんゴーストをインストールしている場合、フォルダわけをすることでメニューから選びやすくなる
（ゴーストメニューが階層化されるのは初耳！）
- たくさんゴーストをインストールしている場合、フォルダわけをすることでメニューから選びやすくなる
- 欠点
- セーブ読み（Reta）を使っていたり、その対象となるゴーストを別フォルダにするとRetaが読んでくれない？
- ゴースト間でセーブデータを読み合ったりする場合（FSWなど）
- 本体設定-開発/その他
- （危険）って何？！
- 同じゴーストを複数起動できる。→セーブデータの書き換えが競合する、ファイル読み込み
- 同時に複数同じものを起動することは基本的に危険
- でもぽなさんはチェック入れてる。
- 使ってるぞグラフ
- ゴースト名のところで右クリックするとゴーストを呼び出すことができる
- 「データ削除」が並んでるので注意
- おまけ「Reta」って何？
「絵の描き方〜とりあえず手を動かしてみよう〜」 - こいずみ玲衣（rera）
- 概要
- 絵を描いてみたいけど難しそう、という人に、まずは手の動かし方をレクチャー。
- 大丈夫！できる！できる！諦めなければ大丈夫！（shuzo風に読んでください）
- すでに絵を描いてる人はお絵かきでもしていてください。
- 必要な道具
- アナログ＝白っぽい紙、鉛筆（シャーペン）
- デジタル＝ペンタブレット、絵を描くためのアプリケーション（ドローソフト）
- とりあえず練習してみる
- ただひたすらに円を描く。綺麗な円になるように意識しながら描く。
- 円がめんどうならうにゅうを描く。良いうにゅうになるように意識しながら描く。
- だけどうにゅうは難しい。
- 疲れたり飽きたらやめる。またやりたくなったらやる。
- こいずみさんの絵の描き方
- 描き始める前にどんな絵にするかぼんやり考える。
- 自分の中でなんとなく決まったら描き始める。ずっと考えててもダメ。
- （書き方の例画像）
- 塗り方とかはpixivで調べる
- イメージ通りにならないことの方が多い。気にしないようにしよう
- 描くのがつらくなることもある。そんなときは…
- 寝る。夜更かしや徹夜をしてたら休む。
- 別のことをする。好きなことをしながらまた描きたくなるまで待つ
- こいずみさんは空や建物の写真を撮ったりしてるそうです。気分転換に、絵の資料に。
- うまくいかない理由を考えるのはほどほどに。
- いろいろ考えるのはいいこと。でも、考えすぎてただの言い訳にならないように。
- まとめ
- 絵を描いてみたいと思ったら、その気持ちが消えないうちに何か描いてみる。円でもうにゅうでもOK。
- 年単位で放置しても大丈夫。完全に投げ出さなければ大丈夫。
- 最初は思い通りにならないかもしれないけど、描きたくなったときにまた手を動かそう！
- 質疑応答
- なんで○なんですか？
- 丸の方がなんとなくいいような気がするから？
- 丸は描くのがむずかしいし、ゆがむとすぐわかるから？
- 描いたものはすぐ人に見せるのがいいの？それとも自分の中でつきつめた方がいいの？
- うまくなりたいのか、楽しくやりたいのかによる。ほめられたい人はうまく出来たと思うのを見せていくといい。
- なんで○なんですか？
-
- 32bitPNGには対応しないの？
- してます。ただし互換性の関係でデフォルトではPNAのみ読み込む。
- 32bitPNGには対応しないの？
-
- いまの講座中にお絵かきをしていた方＝3人
-
- （以下、明日香さんとぽなさんのやりとり）
- PNAファイルってなんのためにあるんですか？なんか容量食ってるんですが→PNGの中にアルファチャンネルを埋め込める環境が少なかった。
- PNAファイルがあるとどう違うの？→エッジがなめらかになる。透明度も変えられる。
- 消したらまずいの？→まずいです！！！！
- （以下、明日香さんとぽなさんのやりとり）
- 参考
- PNAを作るソフトウェア http://sakura.nanika.jp/software/maskalpha/ （TravelerJoe氏作）
