神風記

swfobjectでswfを貼り付けたらエンジンの一部が動かなかった現象が発生。解決策を考え中。

エンジン工事中。

演出面が一段落したので、実際に動かして色々やってます。


実際に動かして見て必要な事がわかる事機能がたくさんある事に気づく

自分の場合あらかじめ必要な機能を予測して実装するのもいいけど実際にバリバリ動かして必要とわかった機能をそのつど実装する方が色々な作業が前に進むのは間違いないとわかりました。

いままで放置していた「,」で区切られた文字列を一つ一つ効率良く取得する方法を考え中。今までは超ローテク方法で取得していたのでそろそろ綺麗に取得できんもんかと考えてます。

現在のコードの一部

fi_str=String(item_xl[index_ui].filta);//XMLオブジェクトのitemにある「filta」要素を取得

var fiP1_in:uint=fi_str.indexOf(",",0)

var fiP2_in:int=fi_str.indexOf(",",fiP1_in+1);

//第一引数の区切りにあたる「,」がfilta要素の文字列の何番目にあたるかを取得。第一引数、第二引数は必須項目のため、indexOfの結果が-1(記述していないと返す値）はありえないため、「fiP1_in」の型は-の符号を取得する事ができない「uint」を指定してます。


第三引数以降は記述しなくても動作するようにしている、つまりエンジン側でデフォルト値を割り当てています。ですので第三引数の値を検索するために必要な「fiP2_in」はindexOfで検索結果無しを表す「-1」の値を受け止める事ができる「int」に設定しています。



var fiImg_str=fi_str.substring(0,fiP1_in);//第一引数で区切られた


var fiTy_in=0;

//================特にここが効率が悪い
if(fiP2_in!==-1)
{
//XMLが第3引数以降を指定している場合
fiTy_in=String(fi_str.substring(fiP1_in+1,fiP2_in));//
} else
{
//第2引数で記述を終えている
fiTy_in=String(fi_str.substr(fiP1_in+1));//
}

//==================


擬似的な引数がXMLに記述されているかどうかを表す「,」をindexOf()で検索した結果によって取得方法が微妙に違うのですが、この辺りの文字列の取得ロジックが効率が悪いです。

クラスに文字列だけ投げて勝手に引数を取得できるメソッドを数時間ほど考える予定です。
数時間考えて駄目だったら保留します。

地震効果の設定が落ち着いたのでいまからXMLの疑似クラスに対応できるようエンジンを実装します。

地震効果のXMLの疑似クラス設定。

1 対象のオブジェクト

2 オブジェクトの揺れる揺れ幅

3 オブジェクトの揺れる時間

XMLにこの三つを入れる事で揺れる命令が実行できるようにする予定です。

テキスト表示関連の処理を最適化中。

スタイルシートでテキストを装飾するか、テキストフォーマットで装飾するか迷ってるので両方試してみようと思います。

dispatchEvent()のイベントのブロードキャストがうまく動作してくれました。

今からSWfアニメーションの完了通知をdispatchEvent()する方法を研究します。

ゲームエンジン改造中です。XMLの命令の伝達をhasOwnPropertyで検索、実行していた処理からdispatchEvent要素を検索し、イベントトリガで制御する形式に書き換えそうです

今までのhasOwnPropertyはitemに記載されたプログラムで決められた順番通りに処理の実行を行ってくれるので、シナリオは書きやすい形でした。
しかし一つのアイテムを検索するのに必要以上に検索幅を広げるので、エンジンの命令の種類が多くなるほど情報検索量が多くなるという問題がありました。

今は特に問題ありませんが、これから結構な量の立ち絵やCGのアニメーション機能やエフェクト呼び出し機能を拡張する予定です。

後々の事を考えるとhasOwnPropertyに依存していたXMLの命令処理をdispatchEvent経由の命令に書き換えた方が良いと判断。

軽く1000行はエンジンコード書き換える必要がありますが、こういうのは早くした方がいいので今日明日中に大工事を予定してます。

取得したXMLのitem要素の順番を優先順位が高い順に並び替えられないかどうか試行錯誤中。

一応、できるといえばできるのですが、微妙に処理がかかるので結果、ならびかえずに、別の手法でXMLを処理した方が早かった。

XMLの命令を認識する事は、エンジンの根幹部分にあたるので高速かつシナリオファイルが簡単に記述できるコードを色々試していきたい所。

AS3ADVエンジンの簡単なアニメーション機能を追加実装中。

秒数を指定して画像の座標を移動させるだけの簡単なアニメーションです。

シナリオファイルの書きやすさを重視して、XMLの要素一つで座標移動のアニメーションを実行できるようにするのが目標。

AS3ADVエンジンの総コード数が3000行超えているのですが各関数と変数の位置に統一性がなく、コードが整理されていないので今日はエンジンをコーディングをしやすいように整理を行っています

今日明日中には関数と変数の位置に統一性を持たせ、エンジンを改造しやすいようにしたい所。

エンジンコードを整理することは作業効率を向上させる事において非常に大事な事だと実感。

ADVエンジンの今後の開発方針を色々考え中。

やりたい演出はたくさんあるけど、Flashの性能的にどこまでそれが実現可能かわからないのでいまいち効率が上がらない。

良い演出技法を思いついても、オンラインでこれだけの画像処理をやると重くなるのでは？システムダウンするのでは？など余計な事を考えてしまうため、非常に開発効率が悪い状態。

この原因は自分がAS3とFlashPlayerの性能の限界を把握してない事に起因していると判断。

AS3とFlashPlayer9がどこまでの処理に耐えられるか自分でも計りかねているため、いい演出技法を思いついても積極的に実装する作業に踏み込めない。この状態は開発者として非常い効率が悪い。

方針変更

これからはAS3の性能を測る事も含めてADVエンジンに自分が考え得る総ての機能を実装する事にしました。

今後はADVパートで使えると判断した演出技法は総て実装するという方法をとります。

やりたい事を総て詰め込んでその結果重くなったりダウンするようならそれを適時修正しいく方針。

実際に色々試してみて明確にAS3の性能を把握しておく事が今後の開発において重要だと思う。

これから重さや処理速度の事は除外してとにかく表現したい演出を総て詰め込む。結果、重くなったりシステムがダウンするようなら随時修正という形を取っていきます。

最低限のプランとゴールだけ決めて後先考えず開発しいきます。

クロスフェードの最適化が終了。

フェードインとフェードアウトの関数を一つにまとめました。

簡単にデバッグした所一応動いてます。

MCをフェードアウト→MCのラベル移動→MCのフェードイン
を一つの関数で行う様にしました。

Booleanの簡単なフラグを使って+−を変更するだけ。各MCのインとアウトの速度はそれぞれXMLで自由に設定できます。

思ったより手間取ったのが、複数のMCを同時に処理する時。

それぞれ違うフェードの速度をXMLで指定した場合に一つのMCが規定値に達すると、他のMCが中途半端なアルファ値のまま止まってしまった事。

フラグと配列を使用してこれらの問題を解決。

フラグの使い方のコツがほんの少し掴めたと思います。

前に実装したアウトとインを分けてクロスフェードを実行していた頃よりもレスポンスがよいのでこの一つの関数で纏めたこの処理をエンジンに実装。

この様にまだまだ、エンジンを最適化、高速化する余地はありそう。

これから最適化、高速化を進めゲームエンジンの精度を上げていきます。

バトルパートのエンジン製作もあるので集中して短期間で終わらせるよう頑張ります。

XMLを解析。

クロスフェード命令を示した"cf"という要素名が見つかる。

isCfというクロスフェードのフラグをfalseにする。（isCfがfalseの場合は次のXMLの命令文を読み取る事はできない）

クロスフェード処理を開始。

現在アルファ値が1のMCをフェードアウト。フェードアウトの速度はXMLで指定する。

アルファ値が0になった時に、XMLから情報を取得し、MC内のラベルを移動する。

ラベルを移動してビジュアルが変化したMCをフェードインさせる。

MCを徐々にフェードイン、この速度もXMLから取得する。

MCが1になるとクロスフェードが完了したというフラグを立てる。

これをXMLが複数のMCに対してそれぞれ違う速度のフェードイン、フェードアウトを要求していても
対応できるようにする。

現時点でこの処理は完成していますが、フェードアウトの処理とフェードインの処理の二つに分けています。

このクロスフェードの処理を最適化、高速化させます。

具体的には一つの関数でフェードアウト、フェードインの処理を行います。

現在のinとoutの二つの処理を使った速度と今から作る一つの処理で
行う処理の処理速度を検証し、実行速度が早い方を実装する予定。

AS3を使って製作しているゲーム「神風」はADV+タイピングゲームです。

ADVパートを構成するエンジンは自分が総て自分一から構築しています

ここではADVパートを構成するエンジンを機能別に記述していきます。

現在のADVエンジンの開発目的は、新機能の実装。ゲームエンジンの最適化、高速化です。

現時点ですでにテキストの制御や、キャラクターの表情の変更、BGM、効果音の制御など基本的な機能は実装されています。

しかしまだまだ新機能を実装する余地、高速化する余地はあります。

このカテゴリで実際にやる事は大きく分けて二つです。

● ADVパートの新機能の実装。

● エンジンを高速化、最適化する。

1 ADVゲームを構成するにあたってFlashならではの表現、AS3で可能になった表現を研究していきます。

Flashはアニメーションの表現に長けている事、オンラインで繋がっている事、データベースとの連携が可能な事など様々な強みがあります

AS3を使ったFlashコンテンツはその気になればどんな表現も可能です

既存のADVゲームにはできない様々なADVゲームの表現を突き詰めます

ADVパートを面白くするためのアイディアを考え、それをゲームの機能として実装する事が目的です。

2 エンジンの高速化、最適化。

ゲームはダウンロードの必要がなくブラウザで直接遊べるのが大きな特徴です。

しかしオンラインでそのまま動くので、サーバー状況によってはゲームが途中で重くなったり、止まってしまう可能性があります。

よってゲームを動かすエンジンは極力高速に動作させる必要があります。

無駄な処理は一切省き、ゲームが動作するためのデータ処理を高速化させます。

これからゲームのADVパートを面白くする事を目的に、上記の研究を行っていきます。

ADVエンジンのカテゴリを新設しました。ゲームのADVパートに関わるコードの構成の解説や新機能の実装等を行っていきます。