タスクシステムでつまずいています...

[じゃじゃかぶ]

タスクシステムの概念はなんとなぁく理解できたのですがどうクラス分けして使えばいいのかイマイチ分かりません......
普通どのようにクラス設計するのが一般的でしょうか？
ゲームの進行によって実行するタスクを差し替えたりするのはどこで行うんですか...?

[ookami]

過去ログですが参考になりますでしょうか？
http://dixq.net/forum/viewtopic.php?f=3&t=8414

[kino]

私のやり方はオブジェクト指向が一般的ではなかった時代の考えなので
じゃじゃかぶさんの参考になるかわかりませんが・・

タスクスケジューラーみたいな時間がきたら処理をするクラスを作って
STGだと自機制御　得点管理　敵出現制御　タイトル画面　テキスト　音楽　背景
などを待機フレームと処理内容を書いて配列化したもの用意して
順番に処理していきます

タスクスケジューラークラスは開始処理のみです
特に背景や敵などは常に動いているので
その処理は別プログラムで平行処理します
テキストなども一定時間過ぎれば消えるので平行処理してました

同じ処理が続いたり
ボスなどの終了時間が未定なものもあるので
処理の内容にifやloopなども入れていました

マルチタスクのようにいろんな処理が平行処理されるイメージです

昔は処理をテーブル化して順番に開始処理するプログラムを書いてました
メモリ節約のためバイト単位ですね＾＾；

コード:

#define START() 0,0,0,0
#define TXTPUT(sys_c,num)	,sys_c%256,sys_c/256,1,num
#define ZONE(sys_c,num)		,sys_c%256,sys_c/256,2,num
#define MUSPLAY(sys_c,num)	,sys_c%256,sys_c/256,3,num
#define TEKI(sys_c,num,x,ax,y,ay) ,sys_c%256,sys_c/256,6,num,x,ax,y,ay
#define DEF(sys_c,num)		,sys_c%256,sys_c/256,8,num

char SKJ_DAT[] = {
　	START()
	TXTPUT(0,C_SPACE)
	MUSPLAY(0,0)
	MUSPLAY(100,1)//100フレーム待ってから処理
	TXTPUT(10,C_START)
// 1stage
	MUSPLAY(100,2)//100フレーム待ってから処理
	ZONE(0,1)		//1stage背景スタート	
	TEKI(100,  0,  0, 64,  8, 64)//100フレーム待ってから敵出現
}

[naohiro19]

Boost.TypeErasureを使う方法もあります。

サンプルプログラム（コンソール版）
http://d.hatena.ne.jp/osyo-manga/20120815/1344956524

[じゃじゃかぶ]

>>ookamiさん
見た感じタスクシステムの存在意義自体危ういものになってるんですかね＾＾；

>>kinoさん
実際の各タスクをクラスとして持っておきそれらを統括して実行するようなクラスを作って毎フレームその中のタスクを列挙した関数を呼ぶというような感じですか。。？

>>naohiro19さん
こんなものもあるんですね！調べてみます！

[softya（ソフト屋)]

ISLeさんがタスクシステムのブログを書いていたのを思い出したので貼っておきます。
「ISLeのビデオゲーム工房: #タスクライブラリ」
http://isle.cocolog-nifty.com/blog/cat2 ... index.html

タスクシステム派の人ではないので私は多くは語れません。

[kino]

＞実際の各タスクをクラスとして持っておきそれらを統括して実行するようなクラスを作って毎フレームその中の
＞タスクを列挙した関数を呼ぶというような感じですか。。？
はい、大体そんな感じです＾＾

[じゃじゃかぶ]

>> softya（ソフト屋)さん
ありがとうございます！
ちなみにsoftya（ソフト屋)さんは他にどのような組み方をしておられるのですか？
実は別にタスクシステムにこだわっているわけではなくてもっと良い方法があるなら是非聞かせて欲しいです！

>> kinoさん
さきほどmapを使って手探りで実装してみたのですが毎回newしては終わったらdeleteするという設計にしてしまった
おかげで例えばプレイヤーの座標とかが保持されず毎度初期化されるというアホみたいな失敗をしてしまいました。。笑
これは必要になったらnewして要らなくなるまで持ち続ける仕組みを設けるべきですか？
それともプレイヤークラスとプレイヤーのタスククラスは別に作っておくべきなんですか？

[kino]

＞タスクシステムにこだわっているわけではなくてもっと良い方法があるなら是非聞かせて欲しいです！
横から入ってすいません＾＾；
ここは「タスクシステムも良い方法と思うのですがもしよければ他の方法も知りたいです」
と書いて欲しいと個人的には思いました＾＾；

＞これは必要になったらnewして要らなくなるまで持ち続ける仕組みを設けるべきですか？
＞それともプレイヤークラスとプレイヤーのタスククラスは別に作っておくべきなんですか？
すいませんそのへんはなんとも言えないです
というのもクラスとかない時代だったのですべてグローバル変数で管理していました＾＾；
使わなくなった配列部分は先頭に０などを入れて再利用できるようにしていました

[softya（ソフト屋)]

タスクシステムをどう使うか、この点が大事です。
向いているもの物あれば、向いていないものもあります。
オセロゲームにタスクシステムを使おうって人はそういないと思います。
私はタスクシステム至上主義ではありません。
でもタスクシステムが有用な場面も多々あります。部分的に使うのも良いと思います。
つまり適材適所なので、作るものの仕様という前提がないと語れない話ではあります。

[ISLe()]

ソースファイル(翻訳)単位であろうが、クラス単位であろうが、あるいはラムダ式であったとしても、構造化のパターンはすべて共通です。
#マルチに具現化できるかどうかとかの違いはありますが。

どのように分類し組み合わせるかといった点で、ゲームだからといって特別なものはありません。
同様に生存期間をどのように管理するかといった点で、ゲームだからといって特別なものはありません。

デザインパターンのように便利だと思う仕組みをまとめたものをタスクシステムと呼んでいるに過ぎません。
クラスを使わなければいけないものでもないし、スマートポインタを使わなければいけないものでもありません。
どのような技術を導入するかというのはシステムが使いやすいか使いやすくないかでしかありません。

生存期間が思ったようにならないというのは単に設計(分類と組み合わせ)が悪いというだけです。
どのようにクラス設計するのが良いかとか、ゲーム進行によってタスクの生成・破棄を行うのはどこか、というのも設計の話です。


共通の構造化パターン(いわゆるオブジェクト)を入れ子にして、ピラミッド構造を作る。
上位のオブジェクトが下位のオブジェクトを管理する。
下位のオブジェクトは挙動に必要な情報を上位のオブジェクトに問い合わせる。
といったところが設計の王道かと思います。
過去にも同じような話題のトピックがいくつもあったかと。

構造化パターンはタスクに限定されずプログラムのあらゆる部分に共通して存在します。
生存期間の管理というのはプログラミングそのものと言えるのではないでしょうかね。