アプリは、UI、ビジネスロジック、データモデルを持つ
→一般的なUIは、リスト、コンボボックス（クリック領域、スクロール領域）を持ち、
→ビジネスロジックは、入力にたいしてどのような処理、どんなデータモデルなのか知っている。
データとインターフェイスの分離に失敗すると
→オブジェクトを外部から利用しがたくなる（データを保持する形の入力フォームは駄目）
→UI変更が容易でなくなる（いろんな形のグラフ作成）
→同一データの多重同時参照が困難（表示携帯ごとにデータのコピー要）
→データの同期が困難（表示携帯ごとに処理わけが必要になる）
★モデル
ビューや、コントローラーから独立して存在できる格納庫。
→文字のような、プリミティブなデータを保持するが、複雑なデータ構造ももてる。
モデルはビューやコントローラーへの参照を持つことはない。
→モデルの柔軟性を保つという重要概念
★ビュー
UIサブシステムの視覚部分
→アニメーション、入力フォーム、チャート、ボタン、オーディオプレイヤーに不可欠なUI要素から構成
ポイント：視覚的な要素、モデルデータを読み取るロジック、ＵＩの要求を処理する、これらで構成される
★コントローラー
入力処理を行う。
モデルやビューの更新もここで行う。
それぞれ（サブシステム）の関係性
モデルは他の要素の情報を持たないが、情報をブロードキャストはする
→ひとつのモデルは複数のビューから参照されることが可能
ビューはモデル情報を持ち、モデルから情報を受信し、モデル情報を読み取ることが可能
→モデルに何かを書き込むということはないが、すべてのビューはモデルへの参照を持つ
コントローラーもモデルにアクセス可能
→ユーザー入力、もしくはシステムイベントでモデルのデータを変更する役割を持つ
コントローラーとビューの関係は密接
ひとつのコントローラーが複数のビューを制御するのは一般的ではない
コントローラーとビューの関係性は1対1が望ましい
ただし、ASではコントローラーとビューをまとめてクラス化することが多い。(ドキュメントビュー実装)
モデルは独立したもので、ビューやコントローラーへの参照は持たない。
ビューはモデルデータの変更を描画に反映
Tags: AS3, DesignPattern, Flash
ポリモーフィズムとは、同一インターフェースを持つ、実装部分が微妙に異なるクラス。
時計でいったら、デジタル時計とアナログ時計における表示部分の実装。
Tags: AS3, DesignPattern, Flash
イベントメモ
◆「on the fly」「another shadow」の技術的な話
緒方 壽人さん（リーディング・エッジ・デザイン）
「on the fly」
原理概要
・projectorにて投影した映像をIRカメラで画像認識
・投影面にはRetroReflective Materialというものを使用
（入射角と反射角が同じにする性質があるものらしい→高価）
・IRカメラには、OptiTrackを使用
・soft ImageProccesing OpenCV
YCAMでの展示と、骨展での展示では、紙の認識方法が違う
・YCAM ver：紙内の穴で紙の向きを認識。
・骨展 ver：手の影も踏まえて紙の向きを認識
（手の影から一番遠い頂点→隣の頂点から2辺を抽出→四角を認識)
計算部分はC++、描画部分はFLASHを使用
通信方法は、ExternalInterface
現実空間と映像の同期には遅延が致命的なためネットワーク経由での通信では駄目だった。
（Socket、LocalConnectionとか）
「another shadow」
原理概要は「on the fly」と同じ
アルゴリズムは影を三角形に変換して三角形の塊として考える。
三角形分割
・影の輪郭から領域を三角形に分割
（有限要素法、ドロネー分割、ボロノイ図）
制御点を決めて、アニメーションさせる。（頭、手、足、胴体中心等に）
制御点は、グラフ理論の考え方で設定
（三角形の辺の中点をとり、そこに線を引くような感じ）
処理の順番（計算処理はC++)
・輪郭抽出
・三角形分割
・制御点決定
・事前計算
・描画
※C++のPoco というライブラリがJAVAライクでお勧め
まとめ
DesignEngineering→新しくて使えるものを作る
Usable + Innovative = Interactive Art
技術的にはスピードとレスポンス感を大切に
あとは使うシチュエーション（シナリオ）を合致させる。
つまりはプレゼントを作る
→（ユーザーが）欲しい物を考える
→サプライズ要素も忘れない
Q&A
Q：苦手な人へのアルゴリズムとかの効率的な勉強方法は？
A：とりあえず仕事で受けて必死にやる（笑）
あとは過去の遺産の見直すことも大切
◆Gumbo、Catalystを中心としたAdobe Labsの技術紹介
上条 晃宏さん（アドビ システムズ）
・Alchemy
C#並みの演算速度をAS3で利用するためのフレームワーク
FLASHでスーパーマリオ、Webブラウザ(WebKit）の移植が可能になるらしい
ただし、AS3でできなかったことがこれでできるというわけではない。
プログラムサイズも大きくなる。
変換処理には、Gluegen：AS3←→C
コードをまとめて書いてあるものを変換したほうが良い。
（毎回変換処理させると遅くなる）
Cではメモリ開放は手動だから気をつける。
・Struts
P2Pさせるための橋渡しというか準備みたいなもの。
ただし、お互いのIDを知るための仕組みを別途用意しないと駄目。
FLASH COLLABORATION SERVICEなら、IDの仕組みも組み込まれてる。(Flexのみ）
・FLASH Catalyst
デザイナー向けツール
ASなしにインタラクションがつけれる
・FlashBuilder
年内には正式リリース予定
デバッグにプロファイルとデータとサービスが便利そう
日本語版Betaテスター募集中
Tags: Event
インターフェイスで定義するメソッドは、パブリックメソッドのみ
(修飾詞は指定できない。privateとか）
パブリックメソッドにはgetter/setterも含む。
インターフェイス
package {
public interface IPlus {
//myPlus関数定義
function myPlus(number1:Number , number2:Number):Number;
//ゲッターを定義
function get myNumber():Number;
//function set myNumber(value:Number):void;
}
}
クラス
//IPlusを実装したクラス
package {
public class Plus implements IPlus {
private var _myNumber:Number;
public function Plus() {
var num1:Number = 10;
var num2:Number = 5;
_myNumber = 10;
trace(myPlus(myNumber, num2));
}
//myPlus関数が無いとエラー
public function myPlus(num1:Number, num2:Number):Number{
return num1 + num2;
}
//get myNumber()ゲッターが無いとエラー
public function get myNumber():Number { return _myNumber; }
}
}
また継承することでもインターフェースも受け継がれる。（実装も継承される)
その際は抽象クラスという概念を持ったクラスを利用する。
抽象クラスはインスタンスを持てないクラスという意味。
ただしＡＳ３では抽象クラスを管理するルールがないので自分で管理する。
Tags: AS3, DesignPattern, Flash
書籍：ActionScript3.0デザインパターンを読みながらのメモ（自分用）
1.分析フェーズ
→ユースケース作成（フォーマルユースケース)
→→主アクター、事前条件、基本経路、代替経路、特殊用件、検討事項
例）flickrAPIによる検索を使ったスライドショー
◆主アクター：
エンドユーザー
◆事前条件：
エンドユーザーは検索テキストボックス、送信、早送り、巻き戻しボタンの付いた画面を見ている
◆基本経路：
1.検索ワードを入力
2.送信ボタンをクリック
3.flickrがxmlを返す
4.xmlから画像を表示する
◆代替経路
3a.flickrAPIに接続できないときはエラーを表示
4a.検索結果でxmlが空っぽの場合は仮画像を表示
4b.画像の幅が規定サイズより小さい場合は拡大して表示
◆特殊要件
マウス操作以外にキーボードのみでの操作も可能とする
◆検討事項
ローディング処理方法
2.設計フェーズ
→CRCカード作成(Calss：クラス Responsibility：債務 Collaborator：コラボ)
→→クラスに債務を設定したら、当てはまるコラボ（当てはまるクラス）を設定
→クラス関係の精査：関連、集約、継承
→→関連：依存(uses)関係（MAPとMAPDATA)
→→集約：所有(has a)関係(MAPとSTREET)
→→継承：一般的な継承(is a)の概念→ポリモーフィズム
→パブリックAPIの書式を決める：債務のpublic,privateの割り振り
3.実装フェーズ
→コーディング規約の確認（俺流の設定)
→→ローカル変数名の先頭文字にはアンダースコア
→カプセル化：クラスをブラックボックス化するという考え方
→→パブリックなプロパティを使わない
→→→アクセサメソッドを使う
→→外部クラスのオブジェクトを直接参照しない
→→→そのクラスの引数を経由した参照は除く
→→→（駄目な使い方の例がないので、よくわからない p20）
→→配列などはコピーしたものを返すような設計が必要
→継承とコンポジション
→→継承は既知
→→→継承のメリット：利用が簡単
→→→継承のデメリット：サブクラスが良いカプセル化ではない、ひとクラスしか継承できない
→→コンポジション：元のクラスをバックエンドクラス、新しいクラスをフロントエンドクラス
→→→フロントエンドクラスはバックエンドクラスのインスタンスを利用する。
→→コンポジションのメリット：カプセル化が強い
→→コンポジションのデメリット：コーディングが増えて面倒
→→継承か、コンポジションかの判断の仕方
→→→A is BならAはBの継承とする
→→→A has B なら、AはBのコンポジションとする
Tags: AS3, DesignPattern, Flash
getter/setterの存在意義としては、オブジェクト指向における
「パブリックなプロパティを使わない」
という概念からあるっぽい。
ということは、プライベートなプロパティへのアクセス方法としてgetter/setter（アクセサメソッド)という概念があるということかな。
明示型のアクセサメソッドについて
パブリックな関数を用意してその戻り値にプライベートなプロパティを設定する。
こんな感じ。
package {
public class NewClass {
private _number:Number = 10;
public function getNumber():Number{
return _number;
}
public function setNumber(num:Number):void{
_number = num;
}
}
}
こんな感じで呼び出す。
//フレームアクションとかで
var newClass:NewClass = new NewClass();
newClass.setNumber(200);
trace(newClass.getNumber) //出力：200
で、暗黙型のアクセサメソッドについて
いわゆる、よく参考書に書かれているアクセサメソッドを使った方法。
こんな感じ
package {
public class NewClass {
private var _number:Number = 10;
public function get number():Number {
return _number;
}
public function set number(value:Number):void
{
_number = value;
}
}
}
こんな感じで呼び出す
//フレームアクションとかで
var newClass:NewClass = new NewClass();
newClass.number = 200;
trace(newClass.number) //出力：200
二つの違いは、通常通り関数としてアクセスするか、横着してプロパティっぽく使いたいかってことなのかな。
使い勝手として、元来、関数的な処理なので、例外処理とかを追加して使うのが王道っぽい。
たとえば、_numberには正の数値のみという条件があった場合は、
明示的な例
package {
public class NewClass {
private var _number:Number = 10;
public function getNumber():Number{
return _number;
}
public function setNumber(num:Number):void{
if (num < 0) {
_number = 0;
} else{
_number = num;
}
}
}
}
getter/setterがプロパティもどきと、考えてたから色々こんがらがってた。
けれど元来は関数でやってたことをプロパティっぽく使える便利機能だよって感じだということを知って、ちょっと納得。
Tags: AS3, Flash, getter/setter
とりあえずよくわすれるからメモ
バネの動きについて
原則としては、
単位時間での、「目的位置」 – 「現在位置」を「加速度」と設定する。
この加速度でオブジェクトを動かせばそれはバネの動きとなる。
ステージにball_mcをおいた状態でのフレームアクション
簡単に書くと、
//初速度
var v0x:Number=0;
//速度
var vx:Number=0;
addEventListener(Event.ENTER_FRAME, entarFrameHandler);
vx=v0x;
function entarFrameHandler(e:Event):void {
//マウス位置とボールの位置の差を加速度とということにする
//つまりは目的位置 - 現在位置 を加速度にするということ。
//この加速度は毎フレームごとで当然変化する。
//良くわからんが、(目的位置 - 現在位置) で求めた加速度はバネの性質を持つ
var ax = mouseX - ball_mc.x;
//速度に加速度を単位時間毎に足すということ
vx += ax;
//位置に速度を単位時間毎に足すということ
//ここでの速度はマウス位置で変化
ball_mc.x+=vx;
}
ただしこれだと、バネは収束しないので二つのパラメータを設定して制御。
空気抵抗：1以下の数値を設定し、バネの収束する速度を調整
バネ定数：1以下の数値を設定し、バネの硬さを調整（小さい方が軟らかくなる）
//初速度
var v0x:Number=0;
//速度
var vx:Number=0;
//バネ定数(1以下、数値を上げるほど硬いバネ）
var spring:Number = 1;
//空気抵抗（数値を下げるほど、行ったり来たりが短く）
var friction:Number = 0.9
addEventListener(Event.ENTER_FRAME, entarFrameHandler);
vx=v0x;
function entarFrameHandler(e:Event):void {
//マウス位置とボールの位置の差を加速度とということにする
//つまりは目的位置 - 現在位置 を加速度にするということ。
//この加速度は毎フレームごとで当然変化する。
var ax = mouseX - ball_mc.x;
//加速度にバネ定数をかける
//良くわからんが、(目的位置 - 現在位置) * バネ定数で求めた加速度はバネの性質を持つ
//(目的位置 - 現在位置) (* バネ定数：かけなくてもバネっぽい動き)で求めた加速度、これを忘れないように。
ax = ax * spring
//速度に加速度を単位時間毎に足すということ
vx += ax;
//速度に空気抵抗かける
vx *= friction;
//位置に速度を単位時間毎に足すということ
//ここでの速度はマウス位置で変化
ball_mc.x+=vx;
}
Tags: AS3, Flash
よくこんがらがるので基本的なまとめ
基本概念
速度とは、単位時間あたりの位置の変化
加速度とは、単位時間あたりの速度の変化
（ここではENTＥR_FRAMEでの繰り返しを単位時間と設定する）
ステージにball_mcを配置した状態でのフレームアクション
等速運動
//初速度
var v0x:Number=10;
addEventListener(Event.ENTER_FRAME, entarFrameHandler);
function entarFrameHandler(e:Event):void {
//位置に速度を単位時間毎に足すということ
ball_mc.x+=v0x;
}
等加速度運動
//初速度
var v0x:Number=10;
//速度
var vx:Number=0;
//初加速度（そんな言い方あるのか）
var a0x:Number=1;
addEventListener(Event.ENTER_FRAME, entarFrameHandler);
//速度に初速度を代入
vx=v0x;
function entarFrameHandler(e:Event):void {
//速度に加速度を単位時間毎に足すということ
vx+=a0x;
//位置に速度を単位時間毎に足すということ
//ここでの速度はどんどん増えていく
ball_mc.x+=vx;
}
Tags: AS3
ドキュメントクラスでの初期化処理の方法について
偉いの人のソースを見るといろいろ方法があるみたい。
でも、どういったケースで使いわけるのかが、よくわからない・・・
★例1：普通にコンストラクタ内に書いちゃう
面倒なときはこれ。
package {
import flash.display.Sprite;
import flash.events.Event;
public class Test0 extends Sprite{
//コンストラクタ
public function Test0() {
//↓初期化処理を書く
trace("init")
}
}
}
★例2：ドキュメントクラスがステージに追加されたら実効
よくみる書き方。
package {
import flash.display.Sprite;
import flash.events.Event;
public class Test1 extends Sprite{
//コンストラクタ
public function Test1() {
this.addEventListener(Event.ADDED_TO_STAGE , init);
}
private function init(e:Event):void {
removeEventListener(Event.ADDED_TO_STAGE, init);
//↓初期化処理を書く
trace("init")
}
}
}
★例3：loderInfoプロパティをトリガーにする
たまたま発見。（全部完全に読み込んでからってこと？）
package {
import flash.display.Sprite;
import flash.events.Event;
public class Test2 extends Sprite{
//コンストラクタ
public function Test2() {
this.addEventListener(Event.ENTER_FRAME , enterFrameHandler);
}
private function enterFrameHandler(e:Event):void {
if (this.loaderInfo){
if ( this.loaderInfo.bytesTotal > 0 &amp;&amp; this.loaderInfo.bytesLoaded >= this.loaderInfo.bytesTotal ) {
removeEventListener( Event.ENTER_FRAME, enterFrameHandler );
init();
}
}
}
private function init():void {
//↓初期化処理を書く
trace("init")
}
}
}
結局のところ、どれが一番ベターな書き方なんだろう？？？
作ってるモノのレベルで変わるのだろうけど1でも不自由したことがないのでよくわからない・・・
Tags: AS3, Flash
scaleformとADOBEによる共同セミナー
2009/6/18 19:00～21:00
参加メモ
◆ADOBE CS4紹介 西村
ガイドに沿って移動
→鉛筆ツール等で線を書く→コピー→移動対象のオブジェクトのあるレイヤーにペースト
◆ScaleForm紹介 阿部
3Dゲームの2D的な部分
→パネル系、MENU、ゲーム内のミニゲームとか
ベクターグラフィックをテッセレートしてGPUでレンダリング
→高速・低不可
EddgeAA エッジだけアンチエイリアス
クロスプラットフォーム（wii Ps3,Xbox)
ベクターテキスト使える。
メモリ管理が最重要
リッチなSTATS有（AMP)
GFx CLIKのソースは見れる。
ScaleFormVideo
→ビデオ対応、FLASHに張れる
ScaleForm IME
IMEのUIデザイン（スキン変更容易）
◆ホームメディア事例「あいうえ おーちゃん」
ハードウェアとScaleFormを連携させるエンジンを自作
→一番大変
◆Q&A
IPHONE対応は？
→いずれ（ScaleＦｏｒｍ)
SWFをgfx対応は簡単？
→簡単らしい(ホームメディア）
NetConnectionとかサーバーにアクセスするのは不可？
→ScaleFormでは不可（ScaleＦｏｒｍ)
FLASHERがゲーム開発するには
→ゲーム会社に入るのが一番早い（でもMenuとかだけになっちゃうかも）（ScaleＦｏｒｍ)
→業界にAserは少ないみたい。
→FLASH部分の外注ということは一般的ではない
(日本は内向的）
インターフェース部分の互換について
→MainProgramにて変換処理をマッピング（ホームメディア）
→Flash側はいつもどおりに作ればOKにする
FLASHコンテンツ、SDKのライセンス問題
→特に公式にライセンス取り交わしてないけど、ADOBEとは話は通してある。（好意的）
→レンダリングエンジンとか作っても特に問題ないよ
開発コストどれくらい削減できました？
→答えられないけど、もっとも大変なのは、MainProgram（ホームメディア)
→C++で5万行くらい
→ScaleFormを使わなかったら10倍くらい？
FLASHをUVマップできるか？
→できる
