左脳Script

もチャット作成日誌：2010年7月11日～12日

2010-08-30T11:57:28Z

もチャット作成作業日記です。

]]>

2010年7月11日

アンドゥ＆リドゥ機能コーディング。
→未テスト＆未デバグ。
アンドゥ、リドゥ、一時保存、一時読み出し、エクスポート、のボタンアイコン作成。

思ったより作業が進まなかった・・・orz

2010年7月12日

ボタンアイコンの整理。ポップアップのようにボタンが出る仕掛けにし、画面をすっきりさせた。

レイヤ編集ボタンにマウスカーソルを合わせると、レイヤの透明度を設定できるボタンが表示される。

アンドゥ、リドゥ、一時保存、一時読み出し、を事前にコーディングしたものと関連付け、ようやくデバグ＆動作確認開始。
→ひとまず、動作を確認できた。破綻もなく動いているようだ。
結局全ての操作ボタンをアイコンから作った。
- FlexコンポーネントでU/Iを作ると、キーボードフォーカスの管理が面倒になる。
- 一部ボタンを作り始めてしまったが、操作体系から言って統一感があるほうが馴染み易い。
というもっともらしい理由により、操作を全てアイコンボタン化した。

やっとの事で、本腰を入れてマップの作成に着手できる・・・カナ？！
ひとまず、初期ログイン地点のひとつとして想定している「森の泉」っぽいものを作ってみる。

泉しにちゃデカイとかキニシナイ！

エディットを始めて気づいたこともあるので、それらに一つずつ対処して行こう。

マップチップでのフィル（塗りつぶし、矩形領域描画）が無い。イキナリ大きめのマップで当たりをつけるような作り方が出来ない。
コピー＆ペーストが無い。
当たり判定の試験で解ったが、チップの移動方向抑制は出る向きだけではなく、入る向きも判定したほうがマップを作る時に楽。
レイヤの透明度を指定できるが、上層レイヤのマップチップ描画状態によっては、透明度が反映されない。それぞれのレイヤに描画した後のレイヤの透明度を設定している為、今の時点では構造上仕方ないとも言えなくも無い。が、エディットするには実は中途半端な機能で、不便である。

それでも、これだけのマップが作れるので、なんとかならなくも無いのだが。
当たり判定は、ゲームのシステムにも関わるので、早急に対処したいところ。

Object とキャスト

2010-08-29T06:01:03Z

AVM（Action Script 仮想マシン）上で動くオリジナル仮想マシンを作る場合、変数を何らかの配列なりに格納する必要があります。

そこで変数をなんらかの配列で管理しようという事になる訳です。

Object：連想記憶配列。すべてを名前で管理できるので、とてもとても楽。VMを作るのは。
Array：つまるところ、添え字に整数を使うことを前提とした、便利メソッドが追加された Object クラス。特に速度が優れているとかは無い。ハズ。
Vector：添え字を整数に限定、格納するデータの型を予め設定し変更できない、という制約が在るが、この制約の為に、上記２つのクラスより早い。沢山の要素にアクセスしなければならない用途を想定しているようだ。

Vector が整数インデックスで早いのは判りますが、要素の型を指定するのは、具体的にどんな影響があるのでしょうか。

]]>

いきなりベンチマーク

検証コード。


{
    var ary:Vector. = new Vector.();
    var aryi:Vector. = new Vector.();
    var aryn:Vector. = new Vector.();
    var aryx:Vector.<*> = new Vector.<*>();
    var i:int;
    for (i = 0; i < 100000; i++)
    {
        ary.push(i);
        aryi.push(i);
        aryn.push(i);
        aryx.push(i);
    }

    function test0():void 
    {
        var sum:Number = 0;
        for (var i:int = 0; i < 100000; i++)
        {
            sum = sum + ary[i];
        }
    }
    function test1():void 
    {
        var sum:Number = 0;
        for (var i:int = 0; i < 100000; i++)
        {
            sum = sum + aryn[i];
        }
    }
    function test2():void 
    {
        var sum:Number = 0;
        for (var i:int = 0; i < 100000; i++)
        {
            sum = sum + Number(ary[i]);
        }
    }
    function test3():void 
    {
        var sum:Number = 0;
        for (var i:int = 0; i < 100000; i++)
        {
            sum = sum + aryi[i];
        }
    }
    function test4():void 
    {
        var sum:int = 0;
        for (var i:int = 0; i < 100000; i++)
        {
            sum = sum + int(ary[i]);
        }
    }
    function test5():void 
    {
        var sum:Number = 0;
        for (var i:int = 0; i < 100000; i++)
        {
            sum = sum + (ary[i] as Number);
        }
    }
    function test6():void 
    {
        var sum:Number = 0;
        for (var i:int = 0; i < 100000; i++)
        {
            sum = sum + aryx[i];
        }
    }

    trace(getTerm(test0));
    trace(getTerm(test1));
    trace(getTerm(test2));
    trace(getTerm(test3));
    trace(getTerm(test4));
    trace(getTerm(test5));
    trace(getTerm(test6));
}

public static function getTerm(f:Function):Number 
{
    var av:Number = 0;
    for (var i:int = 0; i < 10; i++)
    {
        var st:int = getTimer();
        f();
        var tim:int = getTimer() - st;
        av += tim;
    }
    return  av / 10;
}

私の環境では、以下のような結果になりました。絶対値はあくまで目安です。

一番上の「sum = sum + ary[i];」は要素の型をキャストしていないので、演算実行時に型の評価を行っているようです。特に"+"演算子は、数値の加算の他に、文字列の連結も可能ですので、要素となる Object が具体的にどんな型なのか真面目にチェックしなければなりません。そのため、キャストを使わない場合に比べ、３倍程度の時間がかかっています。

"+" が駄目なら、と"-"に変更したところ、コンパイルの段階で型のエラーが出ました。"+"演算子で試験した事自体あまり良くなかったようです。他の演算子では、Object から明示的なキャストが必須です。
Vector で要素の型を指定するパターンと、要素の型を Object のまま、演算時にキャストするパターンで、あまりに差がありません。また、int と Number の差は、この検証コードでは測れないほど微小？なようです。
「as」でキャストするパターンが実は最も重く、型変換できなかった時の処理、と言うより型変換ができるかどうかの判別に処理が割かれているようです。最後の「要素の型に＊を使う」パターンも、処理自体は Object と同じ程度の時間がかかっています。

個人的結論

Vector.

要素の型を Object にし、演算時にキャストするのが最も簡単なようだ。
キャストに「as」は使うな。

もチャット作成日誌：2010年7月10日

2010-08-29T01:42:23Z

もチャット作成作業日記です。

]]>

2010年7月10日

マップエディットの場合に限り、別の方法でデータの管理を行う形にした。こういう時に、クラスの継承は便利である。
本来マップチップオブジェクトが保持しない、チップID（どのファイルの、どの位置にある画像データをチップとして扱うか、またチップの移動判定を文字列で管理。）の詳細を保持するようにした。
マップチップパレットで設定した「当たり判定」「移動可能方向」「表示状態」を SharedObject に保存する形にした。作業のモードを変更する際に、いちいち保存するので、ユーザーはそれほど、設定の保存を意識しなくてもよい。
→いずれは、アプリケーション設定のファイルに書き出す形式にしたい。
編集したマップデータを、asソースコードの Object 記述形式で出力出来るようになった。
しかし、ファイル名は時間をミリ秒まで表した単純なもので、出力ディレクトリはデスクトップ固定。
そして、この書き出したデータはエディタで再利用できない。ソースコードにマージして、マップをハードコーディングする形となる。
→マップチップの設定と、編集中のマップデータをマップエディタプロジェクトファイルとして書き出せるようにしたい。

とにかく、「マップを編集し保存できる」形に、ようやく達した。
正直いうと、今日一日朝から気力が上がらず、やっつけで機能実装した状態になってしまった。ひとまず動くものが出来たので、ブラッシュアップしていく事にする。

データの保存場所

設定を恒常的に扱えるようにする為、SharedObject に保存していたが、データの保存場所が良くわからない。機能はしているようなので、どこかにデータがあるはずなのだが。

「AIR アプリケーションなんだし、ファイル使おうよ」という訳で、ドコにあるか解らないデータを探すのは早々にやめた。しかし、単純に「データを保存する」という機能に特化しているのか設計の観点から見ると SharedObject は使いやすい。
データ保存のキーのようなものを指定するだけで良いのだ。これがファイルだと、その保存場所から保存時の名称までを入力、もしくは設定する必要があり、その U/I を作らなければならないと言うことになる。

作業途中の維持地データの保存なので、保存場所はアプリケーション固有のディレクトリでよい。ファイル名は「データ保存のキー」（SharedObjectでも使っている）でよい。と、指定が必要な部分を限定すればどんどん間単になり、最終的に SharedObject と使い勝手のあまり変わらないデータ保存クラスが出来た。

FileObject.as


package editor 
{
    import flash.filesystem.File;
    import flash.filesystem.FileMode;
    import flash.filesystem.FileStream;
    /**
     * ...
     * @author 
     */
    public class FileObject
    {
        private var dataObject:Object;
        private var target:File;
        /**
         * 初期化。
         */
        public function FileObject() 
        {
            target = null;
            dataObject = new Object();
        }
        /**
         * 対象のデータを読み込み。
         * @param   index
         */
        public function getLocal(index:String):void 
        {
            target = File.applicationStorageDirectory.resolvePath(index);
            load();
        }
        /**
         * 対象データの実体となるファイルを読み込む。
         */
        private function load():void 
        {
            dataObject = null;
            if (target && target.exists)
            {
                var fs:FileStream = new FileStream();
                try
                {
                    fs.open(target, FileMode.READ);
                    dataObject = fs.readObject();
                }
                catch (err:Error)
                {
                    dataObject = null;
                }
                finally 
                {
                    fs.close();
                }
            }
            if (!dataObject)    dataObject = new Object();
        }
        /**
         * 読み込んだオブジェクトへの参照。
         */
        public function get data():Object 
        {
            return  target ? dataObject : null;
        }
        /**
         * オブジェクトを書き出す。
         * @return
         */
        public function flush():Boolean 
        {
            if (!target)    return  false;
            //
            var fs:FileStream = new FileStream();
            try
            {
                fs.open(target, FileMode.WRITE);
                fs.writeObject(dataObject);
            }
            catch (err:Error)
            {
                return  false;
            }
            finally 
            {
                fs.close();
            }
            return  true;
        }
    }
}

使い方は簡単だ。AMF 万歳。
SharedObject の使い方を踏襲しているので、SharedObject を使っていた方なら解るはず。

→2010年7月11日追記：保存場所がわかった。WindowsXP では以下のようになった。

C:\Documents and Settings\ユーザー名\Application Data\アプリケーション名\Local Store\#SharedObjects\アプリケーションSWF名\データーキー名称.sol

さらに言うと、データの保存場所がわかってしまったので、FileObject.as の存在意義が問われ始めている。機能はSharedObjectと同じなので、ソースを弄れば保存場所を変更できる程度にしか優位点がなくなってしまった。

もチャット作成日誌：2010年7月9日

2010-08-19T13:21:17Z

もチャット作成作業日記です。

]]>

2010年7月9日

昨日実装部分の「チップ属性設定機能」をテスト出来るモードを実装。
キャラクターを直接操作することで、マップの整合性を運用レベル？で確認できる。

動くものを逐一確認しながら作ってきたが、保存で躓く。

正しくは、実運用には必要のない編集用の中間データと、実運用のデータを切り分けていなかった。これをきれいに分解管理できないと、マップデータの Export が出来ない。

機能を維持しつつ構造を変更する必要が出てきた。

もチャット作成日誌：2010年7月8日

2010-08-18T13:37:43Z

もチャット作成作業日記です。

]]>

2010年7月8日

マップエディタへ、マップチップの状態を設定できるU/Iの実装。
チップ毎に、「通り抜けの可、不可」「キャラクタとの重ね描画」「チップ移動判定」の設定が出来る機能の実装。
→上層レイヤのチップに「Low」「Middle」「High」を設ける。Lowは下層レイヤ、Highは上層レイヤに描画する。 Middleは、ウディタのチップ▲指定を実現する。

マップチップの状態をマップへ反映するには、マップチップがチップ状態への参照を持つ必要がある。参照先だけを変更すれば、同じチップは全部更新される仕組みだ。
しかし、現在はマップチップそれぞれがチップ状態をuint変数で持っている。物理的にはこちらのほうが、メモリも食わない上に速い。

マップエディットの時だけ、参照タイプに、ゲーム実行の際には直接型に出来ないだろうか。
→コーディングだけはした。コンパイルも通ったが、物理的なテストはまだ。

操作アイコンを作ってしまった・・・

もチャット作成日誌：2010年7月7日

2010-08-17T11:14:41Z

もチャット作成作業日記です。

]]>

2010年7月7日

マップチップに種別によっては、チップ毎の当たり判定だけでは自然な利用が出来ないものがあった。
高台の角や縁に当たる部分だ。チップの中から別の（移動可能な）チップへの移動を阻止する判定がないと、高さの異なる高台を表現できなくなってしまう。

そこで、この当たり判定の機能を実装した。

チップの辺を跨ぐ際にそれを阻止する判定。と、その設定画面。

もチャット作成日誌：2010年7月5日～6日

2010-08-16T09:27:19Z

もチャット作成作業日記です。

]]>

2010年7月5日

オートタイルの親和性を実現する機能の追加。これに伴い、マップチップのシグネチャ表記を変更。
→親和性の設定は、オートタイルを見て手作業で追加している。自動化が出来ると楽だが・・・どうするか。

エディタのU/IコンポーネントにFlexを利用する事にした。やっとペンの状態を表示する所に着手。
当初の想定より、結構ヘビーな箇所が多い。頑張ろう。

2010年7月6日

マップチップは、ツクールユーザーでは有名なFirst Seed Materialから。

Flexの mx.containers.TitleWindow を使い、ペンの状態をサブウィンドウに表示する機能の実装。
マップチップのサブウィンドウ実装。

現時点で、下層レイヤだけ、上層レイヤだけ、という編集が出来ない。これはまずい。

ボタン追加でアプリケーションとしての機能が充実？してきた。

「ドラッグ」「下層編集」「上層編集」ボタンで主だった作業モードを変更できるようになった。
上層の「透明」「半透明」「通常」を切り替えられるようになった。
拡大率「1倍」「2倍」「4倍」の広域表示が出来るようになった。が、「4倍」は重い。

→チップ毎の当たり判定プリセット編集機能。
→作ったマップをテストキャラで歩き回れる（移動テスト）モード。
→作ったマップの保存機能。
後は、これくらいあれば問題ないだろうか。

もチャット作成日誌：2010年7月3日～4日

2010-08-15T12:24:12Z

もチャット作成作業日記です。

]]>

2010年7月3日

マップエディタをAIRで作成することにした。
過去に、HTML+Javascriptで作成したことがあったが、コードが膨大でドキュメンタイズしていなかった（趣味レベルなので仕方なかったorz）ので、とても扱えない。RPGツクール2000系のマップチップ画像を直接扱え、オートタイルの配置にまで対応した結構な大作なのだが・・・おしい。

→マップチップのクラスを作りこむ。
アニメーション指定で難儀。一度やってるんだがなぁorz

マップ表示部分コーディング。ひたすらコーディング。

2010年7月4日

マップ表示部分コーディング。ひたすらコーディング。

マップチップの情報をテキストで与えられるようにした。データは大きくなるが、エディタで管理しやすくするため。
オートタイルを展開したビットマップを作らずに描画する方法に。
アニメーションチップ、アニメーションタイルの表示を可能に。
マップチップオブジェクト、画像、その他もろもろを明示的に管理＆開放できるようコーディング。オブジェクトをプールする事で徹底的に使いまわし、GCをなるべく起こさないように対策した（つもり）。

一通り、想定したマップチップの表示が出来るようになったので、マップエディタのU/Iに着手。

オートタイルとの親和性
オートタイルとは、「種類の異なる地面を滑らかに繋ぐ境界を描くもの」である。厳密に言うとちょっと違うかもしれないが。

草原～砂地～暗い砂地～暗い草地～暗い草原～草原、と滑らかにつながっている。

しかし、滑らかな境界もデータとして用意しておかなければならない。
暗い草地～草原の境界データがないのでエッジが見えてしまう。

全ての境界線を繋ぐオートタイルを用意できるのが理想だが、データが膨大になる。
現在、上層と下層の２枚のレイヤーでマップを表示している。もしレイヤーが３層あると、そうとう柔軟性が広がり、少ないデータでも境界を表現できるようになるが、Flash のマップチップ描画処理は結構重い（フレーム毎に全描画している）ので、これ以上レイヤーを増やせない。

結局は今在るデータでなんとかするしかないのだ。

せめて、境界を滑らかに繋ぐ部分は自動でやりたい。いちいちタイルのデータを配置していては、いくら時間が合ってもマップが完成しなくなってしまう。

→オートタイルの親和性チェーンのようなものを定義できるようにする。
例えば「海」～「砂地」～「草原」～「雪山」のような繋がりを明確にする。ユーザーは、特に意識することなくマップチップを配置していけばよいだけにしたい。

もチャット作成日誌：2010年7月2日

2010-08-14T10:27:28Z

もチャット作成作業日記です。

]]>

2010年7月2日

ログ部分そっちのけで、通信部分を弄くっていた。

エリアをある程度の範囲に区切り、その範囲でNetGroupを作成。局地的な集まりをNetGroupで管理しようと試みた。

→NetGroup接続から、マルチキャスト送信Streamオープンまで、間が空くとFlashPlayer がフリーズする。
NetGroup.Connect.Success イベント内で送信Stream を作成せず、もっと後のタイミングで new NetStream～publish をすると、publish でフリーズ。デバッガがエラーを拾えない致命的な止まり方をする。

この他、いくつも NetGroup と NetStream を作ると、あっさり重くなり、実用に耐えうるか微妙になってしまった。

→結局、それほど検証せずに Flash では、複雑な通信はまだ重くて安定しないと判断し、作業を進めることにした。

ひとまず、チャットが出来る状態になった。

普通のチャットのルームに当たる機能がない為、ログインで行き成りフィールド上に放り出される。チャットのための面倒を徹底排除した結果こうなった。

実はログが3行しかないのだが、TextField なので、マウスで操作すると全てのログが見れる。TextField さまさま。
→ログ一覧のしっかしした機能を作る。
→ログのフィルター機能を作る。

展望

家やダンジョンをチャットルームに見立てて、パスワードをかける。認証が通らないと入れないエリアを作る。
名前のトリップみたいなものを作れないか？
ブラックリスト。リストにあるキャラは、チャットからキャラまで一切画面に表示されない。など。

展望を語る前に、マップ切り替え機能とマップエディタを作る必要がある。

TextField と IME 入力について

2010-08-14T06:38:33Z

「もチャット」チャット入力機能の使い勝手を向上させるために、入力関連についてあれこれ検索＆実験＆検証した事をまとめてみました。

]]>

IME と TextField の入力フォーカス

英数字１文字の入力をトリガーにチャット入力を開始できるようにしたいが、IME がネックでなかなか上手くいかない。

TextField にフォーカスが無い状態で IME 入力があると、このように IME 入力パレットが出てしまう。

「TextField にフォーカスが無い状態」かつ「IME 日本語入力状態」の時に、このパレットを出さずに正しく TextField から入力する方法はないものか。

→検索＆検証＆実験の結果、それっぽいものが出来た。

チャット入力シミュレーション

水色の入力領域以外の場所をクリックしても、イキナリ文字列の入力を始められる。 どこにフォーカスがあっても、入力を始めると指定TextFieldへフォーカスが移り、正しくIMEの入力ができる。

ただし、完璧ではない（後述）

ソース

たいした大きさではないので、全容公開。


package  
{
    import flash.display.Sprite;
    import flash.events.Event;
    import flash.events.FocusEvent;
    import flash.events.KeyboardEvent;
    import flash.events.TextEvent;
    import flash.events.TimerEvent;
    import flash.text.TextFieldType;
    import flash.ui.Keyboard;
    import flash.text.TextField;
    import flash.utils.Timer;

    import flash.system.Capabilities;
    import flash.system.IME;
    import flash.system.IMEConversionMode;

    /**
     * ...
     * @author 
     */
    public class inputBase extends Sprite
    {
        private var logField:TextField; //  入力ログ
        private var inputField:TextField;   //  入力領域

        private var statusField:TextField;  //  フォーカス情報
        private var keycodeField:TextField; //  キーコード情報

        public function inputBase() 
        {
            //  入力ログ
            logField = new TextField();
            logField.width = 256;
            logField.height = 160;
            logField.x = 32;
            logField.y = 64;
            logField.background = true;
            logField.backgroundColor = 0xeeee99;
            logField.selectable = false;
            logField.multiline = true;
            addChild(logField);
            //  入力領域
            inputField = new TextField();
            inputField.type = TextFieldType.INPUT;
            inputField.width = 256;
            inputField.height = 32;
            inputField.x = 32;
            inputField.y = logField.y + logField.height + 32;
            inputField.background = true;
            inputField.backgroundColor = 0x99eeee;
            addChild(inputField);
            //  フォーカス情報
            statusField = new TextField();
            statusField.width = 256;
            statusField.height = 32;
            statusField.background = true;
            statusField.backgroundColor = 0xee99ee;
            statusField.x = 32;
            statusField.y = 0;
            statusField.selectable = false;
            addChild(statusField);
            addEventListener(Event.ENTER_FRAME, onEnter, false, 0, true);
            //  キーコード情報
            keycodeField = new TextField();
            keycodeField.width = 256;
            keycodeField.height = 32;
            keycodeField.background = true;
            keycodeField.backgroundColor = 0x99ee99;
            keycodeField.x = 32;
            keycodeField.y = 32;
            keycodeField.selectable = false;
            addChild(keycodeField);
            //
            if (stage) init();
            else addEventListener(Event.ADDED_TO_STAGE, init);
        }
        private function init(e:Event = null):void 
        {
            removeEventListener(Event.ADDED_TO_STAGE, init);
            //
            startKey = new Array();
            var i:int;
            for (i = 0x30; i <= 0x39; i++)  startKey[i] = true; //  数字
            for (i = 0x41; i <= 0x5a; i++)  startKey[i] = true; //  アルファベット
            for (i = 186; i <= 192; i++)    startKey[i] = true; //  記号
            for (i = 219; i <= 222; i++)    startKey[i] = true; //  記号
            //
            stage.addEventListener(KeyboardEvent.KEY_DOWN, onKeyDownStage);
            inputField.addEventListener(KeyboardEvent.KEY_DOWN, onKeyDownInput);
            inputField.addEventListener(FocusEvent.FOCUS_OUT, onFocusOut);
            //  FOCUS_INは特に必要ない。IME.setCompositionStringが「IME.enabled = true;」を兼ねる。
    //      inputField.addEventListener(FocusEvent.FOCUS_IN, onFocusIn);
        }

        //  判定用
        private var startKey:Array;

        /**
         * 入力開始判定
         * @param   e
         */
        private function onKeyDownStage(e:KeyboardEvent):void 
        {
            if (startKey[e.keyCode])
            {
                var t:Timer = new Timer(0, 1);
                t.addEventListener(TimerEvent.TIMER,function (te:TimerEvent):void 
                {
                    t.stop();
                    t.removeEventListener(TimerEvent.TIMER, arguments.callee);
                    /*  キーダウンイベントを抜けた後でTextFieldにフォーカスをあわせないと、
                     *  TextFieldが入力文字を拾ってしまう。    */
                    stage.focus = inputField;
                    //  TextFieldにフォーカスが無いとIME.conversionModeから正しい値が拾えない。
                    if (Capabilities.hasIME
                    &&  IME.conversionMode != IMEConversionMode.ALPHANUMERIC_HALF
                    &&  IME.conversionMode != IMEConversionMode.UNKNOWN )
                    {   //  IMEインライン入力モード
                        IME.setCompositionString(String.fromCharCode(e.charCode));
                    }
                    else
                    {   //  IME変換入力モードではない
                        inputField.appendText(String.fromCharCode(e.charCode));
                        var last:int = inputField.caretIndex + 1;
                        inputField.setSelection(last, last);
                    }
                });
                t.start();
            }
            //
            keycodeField.text = "STAGE:" + e.keyCode.toString();
        }

        /**
         * 入力フィールドキー入力判定
         * @param   e
         */
        private function onKeyDownInput(e:KeyboardEvent):void 
        {
            switch (e.keyCode) 
            {
                case    Keyboard.ENTER: //  文字列入力完了検知
                    logField.appendText("\n" + inputField.text);
                    logField.scrollV = logField.maxScrollV;
                    inputField.text = "";
                    break;
                case    Keyboard.ESCAPE:
                    stage.focus = stage;    //  フォーカスを別のコンポーネントへ移動可能
                    break;
            }
            e.stopPropagation();
            //
            keycodeField.text = "INPUT:" + e.keyCode.toString();
        }

        //  TextField以外のDisplayObjectがフォーカスを得る場合、IME.enabledの操作が必要。
        private function onFocusOut(e:FocusEvent):void 
        {   //  これが無いと、IME 入力パレットが出てしまう。
            IME.enabled = false;
        }

        /**
         * フォーカス表示
         * @param   e
         */
        private function onEnter(e:Event):void 
        {
            if (stage.focus === logField) 
            {
                statusField.text = "入力ログ領域";
            }
            else if (stage.focus === inputField) 
            {
                statusField.text = "入力領域";
            }
            else if (stage.focus === statusField) 
            {
                statusField.text = "ステータス領域";
            }
            else if (stage.focus === keycodeField) 
            {
                statusField.text = "キーコード領域";
            }
            else
            {
                statusField.text = "どこか";
            }
        }
    }
}

ポイントは、２点。チャット入力開始判定をしている onKeyDownStage にある。

入力のあった文字が文章入力の開始であると判定した際、直ちに入力の TextField にフォーカスを設定していない事。判定のあったイベント処理内でフォーカスを設定すると、TextField が最初の一文字を拾ってしまう。

もし、IME のモードが日本語入力状態だった場合、ここでフォーカスを移すと、冒頭で述べた入力パレットがでるか、フラッシュの左上に入力文字列が表示されてしまう事になる。

入力判定をした後、そのイベント処理をぬけた直後に、入力 TextField へフォーカスを移動し、最初の一文字を、モードによって場合わけ処理をする。
「イベントを抜けた直後に処理をする」を実現するために、遅延ゼロの Timer イベントを利用。
一定時間後である必要はないが、一旦処理を抜けた後に実行したい処理が在る場合に使う。これは、意外に応用範囲が広い。

バグと言うか不具合

バグというか不具合がある。

ごく稀に（初回入力時が多いので追求が不可能ではないと見ている）、IME の入力パレットがでる。

マウスによる操作で、適切にフォーカスを設定してやると入力は出来るようになるので、致命的なレベルではない。また、動作モードが不安定で（今のところ）このようになるモードが特定できない。

限界

もうチョっと便利にしようとしたが、IME 関連の仕様の壁は厚かった。

TextField にフォーカスが無いと「半角/全角キーによる IME モード切替」が不可能であることが判明。どんなに検索しても、IME 周りは不安定でバグが多いとしか情報が出ない。「半角/全角キーによる IME モード切替」をメソッドなりプロパティなりで変更が出来ない。

Flex SDK 4 で、IME 関連のインターフェースが追加されたようだが、解決したい問題との関連性を見出せなかった。

もぅ、Adobe の今後に期待するしかない。

もチャット作成日誌：2010年7月1日

2010-08-13T10:35:19Z

もチャット作成作業日記です。

]]>

2010年7月1日

アバターキャラクター選択と、ハンドルネームの設定画面を作った。
ハンドルネームの指定を端折ると「ナナシ」に設定される。基本なんでも入力可能なので、ドット一文字なども可能。チェック機構が必要かもしれない。

キャラクターどころかボタンデザインまでも借用させて頂いた。
→http://uros.web.fc2.com/

ようやく、メイン画面からチャット文字列を入力する部分に着手。

TextField のフォーカスイベントの取得について、以下のページがわかり易い。
→http://www.5ive.info/blog/archives/214
フォーカスの変化を検出できたが、強制的にフォーカスを設定するには？
→Stage の focus に InteractiveObject を設定するらしい。InteractiveObject が判りにくいが、要は TextField のようキー入力を受け付けられるオブジェクトの事。
→参照：http://livedocs.adobe.com/flash/9.0_jp/ActionScriptLangRefV3/flash/display/Stage.html#focus
KeyBordEvent で Enter キーを検知すると、IMEでの候補確定の Enter まで反応してしまう。
→判別の方法はあるようだ。http://blog.swee.jp/proto/2009/02/as3-ime-enter.html
つまる所、KeyboardEvent.KEY_DOWN の Enter だけを拾えば、IME の確定 Enter を避けられる。というか実際うまくいったので良しとする。

チャットの入力欄はそれっぽく出来た。しかし、なぜかまだ実際の送信は出来ない。
明日は、チャットログ。

もチャット作成日誌：2010年6月30日

2010-08-12T11:55:37Z

もチャット作成作業日記です。

]]>

2010年6月30日

NetStreamを使う上で参考になるコードを公開しているページ。
http://createwave.blog104.fc2.com/blog-entry-112.html
http://cuaoar.jp/2010/03/rtmfp.html

マルチキャストについて。
http://cuaoar.jp/2010/03/rtmfp-1.html

NetStream について勘違いがあったが、それを克服し、動くものが出来た。
NetGroup.post と比べ、反応速度が格段に早い。post では、キャラクターをしばらく動かさない状態（同じデータを送信し続ける状態）にすると、何故か反応が鈍くなる（データ受信取りこぼし？が増える）ように見える状態になることがあったが、ストリームを使うと、その頻度も激減し、きわめて良好なアクション性を示したと感じた。
→2010年7月2日追記：同じデータを送信すると、端折るのは post 送信の仕様だそうだ。ゲームに使うなら NetStream を選択するべき。

これならば、ものにもよるがオンラインアクションゲームに十分に耐え得ると思われる。

作って解ったこまごました事

NetGroup.Neighbor.Connectについて
グループに後から参加したユーザーは、グループに接続した際、すでにグループにいるユーザーが一気にログインしてくるように見えるようだ。

プログラム技術的な山は越えた。後はお化けアバターチャットというアプリケーションとしての完成度を高めるばかりである。
→アバター選択画面作成に着手。

もチャット作成日誌：2010年6月28日～29日

2010-08-11T12:30:59Z

もチャット作成作業日記です。

]]>

2010年6月28日

いきなりマップフィールド部分から作り始める。最初は、一面草原のマップで、時キャラが操作できる事を最低目標に。

アバターキャラクターのゴブリンを動かそう！
→とりあえず、マップの当たり判定をし、フィールドを動き回るキャラクターを作成できた。

2010年6月29日

複数キャラの表示と、キャラクター管理部分の体系化を目標に。 P2P通信部分の調査。出来れば実験レベルでの実装。

→「Stratus Developer key」で検索すると、かなりのページがヒットする。

ここが詳しい（というか説明が日本語）。
→参考：http://blog.katsuma.tv/p2p/

FlashでP2Pをするには、中継サーバーが必要。そのサービスは、βらしいがAdobeが提供しているようなので、それに関するページ。
→参照：http://labs.adobe.com/technologies/stratus/

P2P中継サービスを利用するには、「Stratus Developer key」が必要。無償で取得できるらしい。
→取得ページ：https://www.adobe.com/cfusion/entitlement/index.cfm?e=stratus
AdobeIDがない状態だと、AdobeID取得からになるようだ。

この表示の右側に、Adobe ID ログインフォームがある。

入力項目に異常がなければ、そのまま「Stratus Developer key」取得へ移行する。

承諾すれば、「Stratus Developer key」を得られる。

後は、このキーでP2Pコードを書くのみ。

コードについては、FMSと同じように・・・と書かれているページが多い。困ったことに当方 FMS は未経験。見当もつかない。調べるしかなさそうだ。


private var con:NetConnection = null;

con = new NetConnection();
con.addEventListener(NetStatusEvent.NET_STATUS, onStat);
con.connect("rtmfp://stratus.rtmfp.net/取得したキー/");

private function onStat(e:NetStatusEvent):void 
{
    switch (e.info.code) 
    {
        case    "NetConnection.Connect.Success":    //  成功
            trace(con.nearID);

こんな感じで実行すると、64桁の16進数がトレースされる。
これが、クライアントのIDになるのだろう。

マルチキャストするには、グループという概念を導入する。これは Flash Player 10.1 からの（現時点で）最新の機能だ。 P2Pのノードネットワークの中に、ノードの纏まりを作りその纏まりの中でマルチキャストできる。という認識でよいのだろうか。
→参考：http://www.flashrealtime.com/simple-chat-p2p-netgroup-rtmfp/

Flash Player 10.1 の新クラス NetGroup を使おうとすると、エラーが出る。というか、オートコンプリートの一覧に出ないので、ライブラリにすらない状態のようだ。
調べてみると、Flash Player 10.1 の新機能を使うには、Flash Player 10.1 に対応した playerglobal.swc が必要な模様。対応の playerglobal.swc だけを探したがどうにも見つからず、途方にくれて昼寝。

http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4 から改めて Flex SDK 4系を落とす。落としたバージョンは、Flex SDK 4.1.0.16076 。
これには frameworks/libs/player/10.1/playerglobal.swc が存在した。

やっと見つけた playerglobal.swc を、開発中の Flahs Develop プロジェクトの lib に置いて Add To Library でプロジェクトに設置。ようやく、新クラスを使ったコードでコンパイルが通るようになった。

このページを大いに参考にさせて頂いた。
→参考：http://cuaoar.jp/2010/03/netgroup.html

その結果、とりあえず動くレベルになった。

起動すると、接続の確認を取られる。

それぞれの画面を中心にオバケが動き、クライアントが増えれば自動的にそのキャラを追加、クライアントが接続を終えれば、自動的にキャラを削除する。
全員同じ・・・

キャラクターデータは、http://uros.web.fc2.com/の物をお借りした。
ホームページのデザインセンスについてはシンプルで良いと感心するがどこもおかしくはないな。

P2P接続の割には、動きがぎこちなく重い。データ送信メソッドに post を使っていることが原因のようだ。
ひとまず、情報送信間隔が開いても、動きを保管するようにした所、それなりにスムースになった。
しかし・・・やはり遅延が大きい。0.5秒ほどずれる。さすがに、これは大きいので、別の方法を模索。

NetStreamマルチキャストで、sendを使うと生データを送れるらしいが・・・要調査。

Flash P2P チャット「モ（ンスター）チャット」

2010-07-30T12:56:20Z

かねてから思い描いていたオンラインアプリ？をようやく形にできたので公開してみます。

]]>

Flash で P2P 通信

Flash で P2P 通信を・・・

とかいう記事は、２年程前からネット上にあふれています。
あくまで「新機能のドキュメントを読み、サンプル試験コードで機能を確認した」レベルの記事ばかり。
しかし、それで「こんなもの作ったよ～」というものになると、数がぐんと減ります。

やはり、Adobeが提供する P2P中継サーバがβである事が大きいのでしょうか。

ここではひとまず、βがどうのとかいう事は置いといて、P2Pアプリケーションについて考えて見ましょう。

P2Pアプリケーションの有名どころでは、ファイル交換ソフトが挙がることでしょう。この他に、身近なものと言えば、オンラインゲームでしょうか。

今、巷にあふれるオンラインゲームは結局の所コミュニケーションツールだと思っています。
MMO-RPG も、つまるところ高級なチャットソフトという位置づけになりますね。

いきなり極論ですが、「だったら最初にまず、チャットありき。」でアプリを作り、只のチャットアプリから高級チャットアプリへとブラッシュアップして行けばよいではないかと、開発に着手しました。

もちゃっと

Monster Chat

今時のアバターチャットアプリケーションです。
と一言で終わってしまう内容ですが、ここまでクルのに結構な時間がかかりました。

構想自体は２年前から、作業は１ヶ月以上かかっています。

詳しい内容は、公開までにつけていた作業日記を順次公開するのでそちらを見ていただくとして、最終的にこれを作るきっかけとなった素材作者様へこの場を借りて御礼申し上げます。あろがとう！

キャラクターデータ:ひみつゲーム用フリー素材
マップチップ：First Seed Material

後者の方は、RPG製作者筋には有名どころでしょうか。

懸念

冒頭でも述べた「Adobeが提供する P2P中継サーバがβである事」も、さることながら、 P2P 通信の rtmfp の能力を信用するしかないといった作りになっています。

自分がこのような通信のアプリを作る事自体初めてなので、見当が付かないまま突き進んでいるところも多く、動いちゃいるけど本当に大丈夫？と念を押して聞かれるとしどろもどろにならざるを得ない。orz

今後

いずればドメイン取ってちゃんとしたサービスとして公開できる日を目標に、精進して参りたいと思います。

Adobe AIR 2.0

2010-06-23T09:08:15Z

AIRが 2.0 になりました。長らくのβ期間を終えたようです。Release Candidate ですけれどネ。

http://labs.adobe.com/technologies/air2/

Flash Develop も、何時の間にやら RTM 3.2.1 となっております。開発環境を一新しましょう。

AIR SDK 単体での使用についてはここでは説明いたしません。
flex sdk に統合？された AIR 開発環境を Flash Develop から使う方法を説明します。
]]>

インストール

既に FLEX SDK での開発環境が整っている前提で話を進めます。そうでない方はコチラから。

flex SDK を展開した所へ、AIR SDK を上書きして下さい。

元となる Flex SDK ファイルリスト。3.4 安定版辺りをお使いならば、AIR SDK のバージョンは 1.5 になるでしょう。

FLEX SDK 3.5.0.12683 では、AIR 1.5.3 が同梱されています。

今回の件の AIR 2.0 SDK RC。構成は同じですので、上書きで問題ありません。
AIR SDK だけを上書きできます。

~~これだけで開発が可能になります。~~ランタイムが 2.0 以上と、開発ターゲット以上でないと、実行時エラーが起きます。忘れずにインストールしましょう。→AIRランタイム

プロジェクトを作成したら、ターゲットを設定しましょう。デフォルトが Flash Player 9 ままなので、プロジェクト新規作成の度に明示的に設定してやる必要があります。

AIR 2.0 サンプル

とりあえず、AIR 2.0 で出来るようになった、Socket サーバー機能を試して見ましょう。

→大いに参考：http://192.150.8.55/jp/devnet/air/flex/quickstart/communicating_with_sockets.html

UDP ソケットの話は、AIR 2.0 β の新機能説明ページが山ほどあり散々既出ですので、一つ捻って TCP サーバを扱って見ましょう。と言っても上に挙げた参考ページで主な事は述べられて居るので、応用として簡易 HTTP サーバーを作って見ることにします。

実際、弄くると判りますが、デバッグの段階でサーバーソケットを開くために、Windows ﾌｧｲｱｳｫｰﾙが一度だけ反応します。

実際に許可されるプロセスは、adl.exe かと思いきや Flash Develop になるようです。

いきなり躓く

ターゲットバージョンを正しく設定し、コンパイルも無事に通り、いざ実行するとエラーダイアログが。


Error #1014: Class flash.net::ServerSocket could not be found.

上記のエラーメッセージをそのまま検索すると、Adobe のフォーラムに解決策がありました。

プロジェクト中の、application.xml にAIRのバージョンが記述されている箇所があります。

これを、以下のように。

フォーラムでは 2.0beta とか 2.0beta2 とかの細かい指定をしていましたが、実際は必要なかったようです。
もしかしたら何か問題が在るかも知れませんが、とりあえず上記のエラーが出ずに動作するようになりました。

プロジェクトテンプレート編集

これらの記述を、プロジェクト作成の度にするのは面倒なので、大元のテンプレートを編集してしまいましょう。

Flash Develop をインストールした所に Projects と言うフォルダがあります。ここに、新規プロジェクトの際に列挙されるプロジェクトテンプレートが幾つか有ります。

それぞれのプロジェクトを書き換えます。

application.xml.template
→application タグの xmlns 末尾を 2.0 へ変更。
Project.as3proj
→ とタグ辿ったところに在る、version の値を 10 から 11 へ変更。

これで、次から新規作成されたプロジェクトも、最初から AIR2.0 開発設定になります。

とりあえず動いた

さて、紆余曲折、躓きもありましたが、ひとまず動くものが出来ました。

動的ページは使えません。CGI 未対応。
というか、POSTアクセス未対応。GETアクセスのみです。
アドレス 127.0.0.1:80 にHttpサーバーを立てます。httpのルートは C:\public\ です。
テスト扱い＆面倒なので、ハードコーディングされてますが、初期化の際に与えるパラメータとして設定できるので、ソースコードを見てみてください。

フリーなソースコード。Flash Develop プロジェクトになります。
→air2http.zip

使う為のサンプルでは無い為、アプリケーションとしてはとてもとても微妙。
アクセスログも、trace されるだけなので、Flash Develop のデバッグ起動でしかログを確認できません。

各自で頑張って、改造しましょう。CGI など動かせれば、十分使える物（一般公開とかではなく、個人試験環境レベルで）に化けるはず。

2010年6月28日追記：
CGI起動について、意気込んでプロセス起動の調査をしたところ、現時点での仕様では「プロセスへ環境変数を渡せない」「プロセスへ渡す環境変数を加工する手段がない」事が判りました。

実現するには、「CGIへ環境変数を渡せるネイティブアプリを作り、仲介しなければならない」模様。現時点（AIR2.0RC）では、純粋なAIRアプリケーションだけでは CGI対応Webサーバーは作れないようです。

とてもとても残念ネ・・・orz=3

左脳Script

もチャット作成日誌：2010年7月11日～12日

2010年7月11日

2010年7月12日

Object と キャスト

いきなりベンチマーク

個人的結論

もチャット作成日誌：2010年7月10日

2010年7月10日

データの保存場所

もチャット作成日誌：2010年7月9日

2010年7月9日

もチャット作成日誌：2010年7月8日

2010年7月8日

もチャット作成日誌：2010年7月7日

2010年7月7日

もチャット作成日誌：2010年7月5日～6日

2010年7月5日

2010年7月6日

もチャット作成日誌：2010年7月3日～4日

2010年7月3日

2010年7月4日

オートタイルとの親和性

もチャット作成日誌：2010年7月2日

2010年7月2日

展望

TextField と IME 入力 について

IME と TextField の入力フォーカス

チャット入力シミュレーション

ソース

バグと言うか不具合

限界

もチャット作成日誌：2010年7月1日

2010年7月1日

もチャット作成日誌：2010年6月30日

2010年6月30日

作って解ったこまごました事

もチャット作成日誌：2010年6月28日～29日

2010年6月28日

2010年6月29日

Flash P2P チャット 「モ（ンスター）チャット」

Flash で P2P 通信

もちゃっと

懸念

今後

Adobe AIR 2.0

インストール

AIR 2.0 サンプル

いきなり躓く

プロジェクトテンプレート編集

とりあえず動いた

Object とキャスト

TextField と IME 入力について

Flash P2P チャット「モ（ンスター）チャット」