moth.log

Debug版FlashPlayerの関数呼び出しの重さについて

かねてから私は考えていました。
AS3の関数呼び出しは、重いのではないでしょうか？
AS3は気軽にgetterとかsetterの関数を使っていいような言語なのでしょうか？

というわけで、検証用にwonderflってみたのがこちらです。

関数呼び出しは重く、入れ子の関数は更に重い | wonderfl build flash online
http://wonderfl.net/code/616f81c36e13d5611f7f60849a0cc27205829584

確かに関数の呼び出しは重い気がします。
手元の環境では関数を呼び出すだけでループ速度が数分の１以下になりました。
Adobeはさっさとinline関数を実現してください。

と思った。
・・・手元の環境？
微妙な怪しさを判明させるブログ記事に当たったのはちょうどその頃でした。

Debug 版 Flash Player の罠【閃光的網站・弛緩複合体 -Review Division-】
http://aquioux.blog48.fc2.com/blog-entry-650.html

Continue reading Debug版FlashPlayerの関数呼び出しの重さについて…

蚕蛾総合集積所はいい加減ユーザーフレンドリーになるべきだと思った

ある日のこと、今日もアクセス数大した事ないなと思ってXREAの管理画面を覗いた｜・ミ。
そこには定常的に1G/日を超えているアクセスログがあった。
・・・あれ？

というわけで急遽サイトトップのゲーム説明にサムネっぽいものを追加しました。
でっち上げなので、サムネというよりはタイトルロゴの方が多いような気がしても
細かい事は気にしてはいけません。｜・ミとの約束だよ！

そもそも自分が止めても見れる絵にあまり力を入れてないせいで、
スクリーンショットが全然見栄えしない。
自分はゲームさえ作れれば他はなんでもいいやと思ってる性質なので、
まず絵が微妙。
確かにグラフィックなんてゲームにおいては記号に過ぎないという解釈もあるが、
それでもふらりやって来た観客にとってアピールしないというのは
とっても損をしている気がする。
それからWebデザインも捨てている。
ゲームさえ作れればいいのでHTMLとかCSSとかどうでもいいやとか考えてたら
間違いなく潜在的な観客を逃している。
それどころか、自分の致命的な欠点があまりにあからさますぎて
Web上の名刺的な役割を全然果たしていない。

まあ、だからこその読めないサイト名と読めないハンドル名なんですがね。
サイトなんてどうでもいい、作品で有名になるんだ！ってのが僕の夢です。
おわり。

蛇足：
当初は転送量対策のためのサイト微調整だったはずなのですが、
サムネっぽいものを追加した結果、転送量は更に増える見通しです。
今後も何か微調整しなきゃいけないかも。

今作っている何か 2009年3月

いろいろなものが同時進行しすぎて面白いです。
ちなみに全部AS3です。

• MML再生ライブラリ

既にFlMMLとかSiOPMとかの先駆者がいるジャンルです。
FlMML - http://coderepos.org/share/wiki/FlMML
SiOPM - http://www.libspark.org/wiki/keim/SiOPM
レトロ音色の忠実な再現とかお手軽さとかは他の人にすでにやられているので、
そういう後ろ向きな機能はばっさりと割り切った方針になっています。
既存のMMLライブラリはゲームで使うのはなかなか厳しかったので、
ゲームでも使いやすいような機能をたくさん盛り込んでいます。
目指せFlash界のピストンコラージュ。

現状：リアルタイム再生とWAV書き出しができるようになりました。
目標：リアルタイム再生とWAV書き出しとSoundクラスの生成ができるようにしたいです。

実は作りかけのものが既にどこかにうpされてるのですが、
もはや原形をとどめていないので
新生版をどのような形で公開しようか考え中です。

• GUIライブラリ

既にFlexとかAbstractUIとかの先駆者がいるジャンルです。
AbstractUI - http://wiki.libspark.org/wiki/AbstractUI
AbstractUIの思想（ロジックとビューを分ける）には共感できたのですが、
ロジッククラスのプロパティになってる謎のインタフェースがキモかったので
何らかのユーザー操作によるビューの表示の変更は全てロジックとビューの間に
デコレータを噛ませることによって実現しようと思い立ったわけです。
なんか副作用でAS3のstrictな型指定が一部失われてしまいましたが
現時点で既にそのデメリットを打ち消すだけの凄まじい柔軟さを醸し出してます。
どんなライブラリに仕上がるか今からわくわくです。

現状：GridっぽいものとかScrollBarっぽいものとかContainerっぽいものができました。
目標：Alertを出したいです。

自前のフレームワークを作らずにFlexの枠組みでユーザインタフェースを作る事も
検討はしましたが、Flexのソースコードを開いて行数確認して諦めました。
皆さんの flex_sdk_3/frameworks/projects/framework/src 辺りに入ってます。

• ソケット通信プロトコル

既にGPSSとかdangoとかの先駆者がいるジャンルです。
GPSS - http://gpss.wda.jp/
dango - http://dango-net.org/
既存のFlash間リモート通信ライブラリは単純なメッセージ交換を実現しますが
、
細粒度なデータ同期が行える事がそのうち必要になりそうだったので
いっその事ソケット通信プロトコルから考える事にしました。
通信プロトコルは完全実装が超めんどくさいほどの超多機能になる事が予想されるので、
サーバ側とクライアント側の余計なプログラムを書かなくていいように
サーバ（設定はXMLファイルで行う）＋ASライブラリで１セットを前提とすると思います。
全て予定です。設計段階ですが、まだプロトコルとして成立してません。

現状：LocalConnection経由でActionScriptのスタブサーバに接続します。
目標：サーバはJavaで書きたいです。

現時点での仮設計にいくつかの致命的な問題を抱えています。
具体的には、細粒度なデータ同期を行うためにデータに名前を割り当てるのですが、
クライアントへの名前の割り当て方法や名前のやり取りの手段が全くもって未定です。
果たして形になるのでしょうか？

• FGF用のゲーム

ひどいゲームを作っています。
GUIライブラリを試しに使ってみたらモックアップの制作が進む進む。
これはひょっとしたらFGFに間に合うのではないでしょうか？

内容の予告とかは自分で何を作ってるのか把握できたら書きます。

• カードゲーム

GUIライブラリとかソケット通信プロトコルとかを作ってる
真の理由のうちの一つ。

何か思い出してはいけない過去を思い出された方もいらっしゃるようですが
皆さんの期待に応えるかどうかはさておき、今度は丁寧にやります。
今回の私はちゃんと仕様を削る事を覚えました。

一見情報を小出しにしてるように見えますが、
実は本当にまだ全然出来てないのでこれ以上の何かを書きようがありません。
だいたい出来ているのはMML再生ライブラリくらいなので、
おそらくそれかFGFのゲームが一番最初に公開されると思います。

さあモックアップを３日で作るソフトを作る作業に戻るんだ

ブログの更新状況をPHPでサイトトップに載せてみた

わあい！

驚愕のサイトリニュやりかけでサイト更新。地道にリニューアル作業中です。

いつもActionScriptばかりやってたので、たまにはPHPも書いてみることにしました。
とはいってもXMLの解析自体はKeith Devensさんの PHP XML Library任せだったのでだいぶ楽でした。

実際やる事と言ったら（今回はWordPressのAtomを読み込んでます）

$rss_xml_data = file_get_contents("http://www.kaikoga.net/m/feed/atom");
$rss = XML_unserialize($rss_xml_data);
$entry = $rss['feed']['entry'];

これでフィードのエントリ一覧がPHPのハッシュで取れるので
あとは適当にHTMLタグを補って整形して表示するだけ。
便利な世の中です。

なお、ブログを書くとトップページが更新されるようになったのだが、
これはブログを書く頻度を上げるための措置である事は言うまでもない。

脳筋戦隊　スクロールRPG

あけましておめでとうございます。
半年ぶりですが生きてました！

作品制作がはかどらなくてストレスが貯まっていたので
頭の悪いゲームを作ってしまいました。

ゲームバランスなどはそれなりに配慮したんですが、
何も考えずにひたすら前に進めるテンポの良さを最重視したので
ヒットストップとかノックバックとか実装しなかったよ！
手抜きだよ！

あれから英語だったテキストを全部日本語訳して
ソースに仕込んどいたんですが、
やっぱり英語の方が雰囲気が出ますね。
日本語で表示してみて後悔した瞬間でした。

私がフラッシュゲーム制作に転向してからもう４年にもなりますが、
当時からフラッシュゲーム制作者の情報集めは難しいままでした。
どうしてもフラッシュ系とAS系の狭間になっちゃって
どっちのコミュニティでも話したい事話せない／通じないかもな感じでした。
やはりフラッシュゲームとしてのコミュニティは必要なんでしょうか？
誰も考えないならば、誰かが考えなければならない問題だと思います。

あと、去年は制作のペースの不安定さが露見した感じがしたので
今年はスキル向上の年として視野を広げていきたいと思います。
そんなこんなで、今年の寡作ぶりは去年以上になる危険性がありますが
もともと制作ペースが遅い人なんだという事で
まったり付き合っていただければ幸いです。

そろそろサイトリニュの時期のような気もしますが
サイトリニュの環境が整うまで少しだけ待とうかと思います。
蚕蛾総合集積所の20102009年にご期待下さい。

ゲームエンジンの手直し

今作ってるゲームはとってもCUIなゲームです。
世の中には優れたCUIゲームが数多く出回っています。
しかし、CUIってのは基本的にユーザーのとっつきが非常に悪いです。
もったいないですね。

というわけで、今回はユーザーに優しいCUIを目指したいと思います。
例えばこんな風に、出せる情報は小出しにしてどんどん出して行く。
CUIは画面が情報量不足になりがちなので、気持ち詰め込みすぎな感じで。

コマンド選択時にコマンドの簡単な説明のほかに、
使用者、消費MPとだいたいの効果量を確認する事ができます。
更に『?』キーで全画面ヘルプを呼び出す事によって
コマンドの詳細な効果も確認する事ができるので、
何をしてるのかよく分からないまま死ぬということはなさそうですね！
（以上の記述は実装予定の機能を含みます）

スクリーンショット１枚だと分かりにくいけど
実際に動かしてみると分かりやすさが段違い・・・なはず

CUIは全ての情報を同時に画面上に表示する余裕がないです。
余裕はないですが、逆に必要な情報だけを画面に出すようにチューンできる
（あるいは、そうせざるを得ない）ので、予想以上にUIの勉強になってます。
実際に作り込んでみると、UIのちょっとした変更は
全てプログラムのちょっとした変更で行えるようになるので
いろいろ試してみる手軽さってのはあると思います。

Flashで適当にムービークリップ並べる方がはるかに楽ですが。

今日は奮発して画像をもう一枚公開。

CUIとは思えない美麗なグラフィックですね。
それでは。

長らく放置されていましたが

ネタが出来たので、そろそろここを有効活用しようかと思います。
当分はMonardry（Armakitchen）の制作進行状況に使いたいと思います。
イベントに出す事もないと思うので、遠慮なく制作状況公開で進めたいと思います。
主に制作中の個人的なメモとして使って、ネタが切れたらその時はその時で。

Continue reading 長らく放置されていましたが…