F-Siteセミナー行ってきました
以下相変わらずメモ
１１月6日
FーSiteセミナー
□モックアップ制作の楽しさ
・ワイヤーフレームが簡単に作れる
・FBを間に挟める
・開発の前段階の演出をFLASHでコード書かずに試す事ができる
・設計のモックアップを色々なパターンをみんなで試すのに最適なツール
□詳しくは何ができるのか
・ワイヤーフレーム
・AiやPsdファイルが読み込める
・CS5にCatalyst入ってる模様
・ステートはページ
・コンパイルエラーがほぼ無い？
・アニメーションが簡単に作れる
2
デザインパターン
しっぽさん
尾野まさきさん
DotWarとか作った人
Template Methodパターンや、Flyweightパターンをよく使っている
Null Objectや
・難しい言葉が多くてめんどくさいよね、UML図とか
Facade（前面様式）
使う側はクラス統括をするクラスのみに命令を渡せば細かいクラスを意識しなくてよい
外側向け
Mediater（調停者様式）
クラス同士のつながりを管理するキングクラスを作ってまとめる
内側処理向け
Prototype（模倣様式）
Clone的な
Mement（形見様式）
アンドゥとかを作りたい時の情報保存
Prototypeパターンで応用が効く、ただし必要なデータだけ持ちたい時はこちら
Observer（監視者様式）
全員をチェックするより何か起きたら教えてもらう方が効率的よね
クラスの方にキングクラスさんの呼び鈴をつける感じかな？
Flyweight（軽量級様式）
一度作ったクラスを使いまわしたい、つまりはキャッシュ
Singleton（独身者様式）
使いすぎる事で有名なパターン
Balking
NULLだったらReturn
Ifが多くなる
Null Object
何もしないインスタンスを作成しておく
Ifが減る
Chain Of REsponsibility（責任連鎖様式）
優先順位をつけたいときに使う
複数人いて、誰か一人に処理をさせたいときに使う
Template Method（雛形方法様式）
空のメソッドを作っておいて、あとで継承したときに埋める
Composite（複合物）
ファイルとフォルダの関係を作る
フォルダもファイルと同じように扱える
フォルダがファイルの要素を継承して、さらにファイルのとフォルダのを持てる機能を追加する
Command（指揮様式）
処理をクラスにする
Progression使えば便利さがわかる
State（状態様式）
ProgressionのScene
Bridge（橋様式）
多重継承できないとき
継承ではなく、それぞれ部分にして変数にデータで持たせる
Decorator（装飾様式）
従来メソッドの前後に処理追加してやりたいことをやる
Interpreter（通訳者様式）
使いません
オリジナルスクリプトを内部を作るときに使用する
Factory Method（工場方法様式）
一連のクラスを生成するクラス
Abstract Factory（抽象工場様式）
キングクラスを作っておく、こちらの方がカスタマイズ性が高い
3
ニコゲー開発の舞台裏
新藤愛大氏
□コンセプト
つくる
シェアする
ニコニコする
技術が無い、素材が無い、場所がないっていうのをカバー
STGとADVジェネレーターを担当
ニコゲーのデモ
ClockMaker 池田さん
FlashDevelop開発の本
STGジェネレーター
去年末から今年初めて
クラス214個
25000行
cs4、テキストエディタ
ADVジェネレーター
今年中旬
FB4
クラス180個
22000行
自作BEライブラリ多数
全体設計
ゲームエンジン
プレイヤー
に基づいた編集をするジェネレータをつくる
UPDATEとDrawを分ける
・優先度を別に管理できる
・負荷が高い時に描画を飛ばせる
・同じ状態で何回でも描画できる
STG
入力
マップ
自機
自機弾
敵
敵弾
アイテム
衝突判定
ADV
入力
シーン
テキスト
レイヤー
Actorクラスをベースとする（UPDATEとDRAWをもつ）
それとActorCollectionでまとめて管理できる
AddActorでコレクションに追加
敵のコレクション
弾のコレクション
自動的に削除してくれる
BEGameEngine
□動きのStrategy化
IMoveStrategyというインターフェースで敵の動きや弾の動きの、アイテム効果はインターフェースとして切り出しておく
□衝突判定
四分木を利用
画面を分割して対応した所だけの判定を行う
何回か分割する
Rectangleのintersectsで十分な速度が出せている
□ポーズとリプレイ
UPDATEの呼び出し以外でゲームが進行する要素を入れない
UPDATEが二回呼ばれたら同じ状態になるべき
入力の抽象化
INPUT用のクラスにをひとつだけ作って、そこでまとめる
人間から行われてるかリプレイデータか意識しなくてすむ
ゴーストはゲームエンジンをもうひとつ作っている
□エディタ編
novelEngine,novel - novel;
でうごく様にしたい
BEFoundation
モデルクラスやバインディングのためのクラス
BEComponents
カスタマイズしやすいコンポーネント集
sourceというプロパティに突っ込めばうごく様にかつ、デフォルトの動きのもある
例えばリストクラスのレイアウトが縦横あって、カスタマイズしたければできるように
とにかくカスタマイズしやすいように
あとコンポーネントはモデルに追従するように
バインディング＞クラス同士の値の連動
AとBはNAMEプロパティ持ってて、変更された時は特定の動作を行う
あまり反応が薄かった
iWorksとかKeyNoteとかの動きの経験をベースにしてエディターを作成
特に既存のエディタとかを参考にはしていない
ifelという言語？
内部状態を変えるものでないのはプロパティに、修正かけるようなのはメソッド
修正に関してはとじて、拡張には開くような思想
