タスクシステムって駄目なの？

以下の２ｃｈスレッドの話題。

【タスクシステム総合スレ part2】
tp://pc11.2ch.net/test/read.cgi/gamedev/1196711513/

なんだかこのスレを読んでると

• タスクシステム信者 → 素人ダサ！


• タスクシステムを否定するもの → タスク以外のやり方選ぶ俺様すげーｗ

って感じで相変わらず2chらしいｗ

昔から2chのゲ製技版は俺様気質のやつが多くてなぜか気分が悪くなるのですよ。

だからあんまり読まないんだけど久しぶりに読み漁ってしまった。面白かったーｗ。

とりあえずPACというアーキテクチャ知らなかったorz。勉強になったよｗ。

で、このスレだけ読んでるともうタスクシステムは使われてないという向きが多いけどどうなんだろ？

俺が働き始めた頃の10年前から普通にタスクってシステムはあったけどそのころはCがメインだったからな。

C++がメイン（と思われる）今の現場ではやっぱり古いのか。

Cで組む場合、リストのなかに関数ポインタおいてワーク領域に構造体あてはめて状態もってという仕組みなわけだけど、C++でこの仕組みをそのまま持ってくるのはどうかと思う。Taskクラスを基底クラスとした場合にnewをオーバーロードして固定で領域確保して派生クラスにキャストして…。さすがにこれはオブジェクト指向に反した、なんだか気持ち悪い実装なのでもっといい方法が欲しいよね。ただどうすればいいのかわからんがｗ

Gemsとか読んだり海外のサイト漁ったりしてると、C++とかで組む場合、Taskという言葉を使わずにGameObjectとかGameEnttiyとかActorとかが多い（海外だからあたりまえか。本来Taskはスレッドみたいにコンテキスト切り替える仕組みなわけだし）。それに習ってか最近のゲームシステムではタスクではなくて別名が多いとか？（2ch情報)。実際どんなシステムなんだろう？最近はスクリプトで実装部を組むことが多いみたいだから、この辺にGameObjectの実装を組み込んでいくのかな？Luaとか流行ってるみたいだけど、コルーチンとかがあって並列っぽい処理ができるとのこと。面白ろそうだ！

俺も一応ochaglという自前フレームワークつくってるけどオブジェクト指向でまじめにゲームのフレームワーク組むのはこれが初めてだからなんかいまいちなんだよなｗ。一応Taskクラスも実装してるけど、ゲームをひとつも完成させてないから使い勝手がいいのか悪いのか全然わからねーｗ。ライブリが完成しないからゲームができないという、まさに目的と手段が入れ替わった状態ｗ。とりあえず簡単なヘボシューでも作るか…。まずはTaskクラスの名前をEntityにしようｗｗｗ。

それにしても、最近のモダンなタスクシステムがどうなってるのか知りたくなってきた！なんかいいソースないかな～。ゲーム業界もオープンソース化しようよｗ

剛体デモ(Applet対応)

アプレットに対応してみた。一応JavaWebStartも利用してる。

なぜかテクスチャロードに時間がかかり、一瞬フリーズしたか？と思った頃に起動する。

アプレットを起動

やはりjoglつかってアプレットは無謀かw。

いずれにしろjavaでゲーム作るモチベーションが急激に下がってきた今日この頃。

FlexでPapervision3Dでもいじるか。もしくはレンダラ自前で書くのもおもしろいかも。

ochaglをflexに移植してみるか。。。

剛体デモ(キーマッピングバグ修正)

キーボードのマッピングが重複すると、片方のマッピングが聞かなくなる不具合を修正。

これで、カメラ操作ができるようになった。ついでに注視点が固定だったのを常にプレーヤを見続けるように修正。

これで３Ｄ酔いが体験できるよｗ。

デモを起動する

今までは、ロジックごとにInputActionのインスタンスを生成していた。

これだと、同じキーに対して複数のInputActionが生成されてしまい無駄である。

また、ひとつのキーに対してひとつのInputActionしかマッピングできないため、

同じキーに対して複数のアクションを設定した場合、片方のアクションしか設定されない。

コレを防ぐために以下のように修正した。

1. ひとつのキーに対して、通常、トリガ、リピートの3種類のInputActionをInputManager内に保持するようにした。


2. InputActionの生成には、InputManagerのファクトリメソッドを使用するようにした。


3. これにより、既に存在するInputActionがファクトリメソッドで要求された場合、既存のインスタンスを返せるようになった。

剛体デモ（すり抜け防止）

前回のやりのこした項目の内、あたり判定のすり抜けに対応した。

デモを起動する

以下のロジックで実現

1. １フレーム前の位置を保存しておく


2. 現フレームの位置かつ前フレームの位置が両方とも平面の裏のときは、衝突なし。


3. 現フレームの位置かつ前フレームの位置が両方とも平面の表のときは、いままでどおりアテハン処理。


4. ここがキモだがｗ、１フレーム前の位置が表、現フレームが裏のときは衝突してるので（速度が半径を超えている！）アテハン処理続行

というわけでとりあえず摺りぬけが発生しなくなりました。

厳密に言うと、辺に対してと頂点に対しても同様の処理をしなくてはいけないんだけど面倒だからいいやｗ。

剛体デモ（障害物追加）

ひっさしぶりに趣味プロ。サイトもリニューアル中。ＣＳＳメンドクセー。

当たり判定のバグを修正したついでに背景に障害物を配置。

あと、カメラをＶキーで切り替えられるようにした。

デモを起動する

うーん、すり抜けが発生するのをどうにかしたい。しかも重すぎ。

キーマッピングで同じキーを複数マッピングできないバグも発覚。

Java5対応とかカリングとかオブジェクトのプーリングとか見直すべきところてんこ盛りだよな。

ま、いろいろやんなきゃいけないことあるけど次の興味は直方体ですよ＾＾。

なんとなくソースもアップ。

しばらくプログラムしてなかったからMavenでjarファイル作る方法忘れてしまった。。。

mvn packege

アニメーション処理追加

アニメーション処理の基礎となるクラスおよびそのサブクラスを追加

• Interpolate.java


• InterpolateStep.java


• InterpolateLinear.java

今回のクラス追加によって２Dデモの爆発アニメーションを追加した。

（半透明で徐々にフェードさせたほうがよいな。）

ただし、まだInterplateLinearクラスのテストがまだ。

テクスチャロード時や画面がとまるのでロードのタイミングを見直す必要がある。

また、ガベコレなどでもよく止まるので全体のつくり自体を再考する必要有り。

２D処理

今日もJAVAでゲームプログラミングですよ。

ウシ！

天気いいのにねぇ。

スケートはもうちょっと体調回復してからだな。

作成中のライブラリの話。

２D処理をどうしようか悩み中。

とりあえず、３Dでの行列処理をそのまま２D側に落とす処理で進める予定。

問題はカメラが必要か？ってとこだな。そこまでシステム化する必要あるか？

今までの２Dプログラムとはまったく違った考えで作らなくてはいけなくなるかも。

しかし３Dに慣れればこっちのほうがよいか。

あとは、スプライトの基準点をどう持つか。

現状は真ん中が（０，０）の座標系でやってる。

左上で出したいときは専用のメソッド呼び出す方式。

これでいいのだろうか？悩むな～。

でも２D処理はメインで使わんし、これでいいか。