タスクシステム総合スレ part3

**名前は開発中のものです。** · 2008/11/09(日) 11:51:40

タスクシステムについての議論、相談、質問、雑談などのスレです

part2 http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/

**名前は開発中のものです。** · 2008/12/12(金) 01:51:42

半年程うだうだやってようやくタスクシステム卒業できた気がする俺からのヒント。
これでこのスレからも卒業だ！

1. ハードに近い下のレイヤはイベントハンドラ使うけど、
　上のレイヤではイベントハンドラは（自分からは）使わない。

　上のレイヤではvoid enter_frame(void)、void display(void)のようなタイミング通知の意味しかない関数
　（C++ならメソッド）を用意しておいて、イベントハンドラからはそれを呼ぶだけに留める。
　データの受け渡しはあくまでも上主導で。
　下主導で上へとアクションかけるのは処理実行タイミング通知（関数呼び出し）だけ。
　入力データは下のレイヤでバッファリングしておいて上のレイヤが下に参照しに行く。相互参照を避けるため。
　タイミング通知の関数のタスクシステムとの違いは、それらの関数がプログラム中にただ一つずつしか存在しないこと。
　関数呼び出しされた側では、その関数内で１フレーム分の処理を手続き型言語丸出しで書いてＯＫ。
　例えばif文、switch文も関数呼び出しも他のインスタンスのメソッド呼び出しも自由自在だし、がんがん引数渡し可能。
　ゲームオブジェクト種別ごとに別の配列用意したりとかも普通にできるようになる。
　ウィンドウプログラムに入る前のC入門書のノリで普通にプログラム書ける。
（続く）

**名前は開発中のものです。** · 2008/12/12(金) 01:52:20

（続き）
2.ゲームプロジェクトとは別にライブラリプロジェクト作る。Visual C++ 2008 Express Editionでもライブラリ用のプロジェクト簡単に作れる。
　１つのプロジェクトで既にきれいに分けれていると思っててもプロジェクト分けると切れてなかったことに気づく。結構重要。
　ライブラリ化はよくある普通の部品化レベルでよい。
　フレームワーク作りはまだ止めとけ。部品化だけで十分役立つ。というかタスクシステム卒業したら部品化できる範囲が急激に広がるのでそれだけで十分手一杯になれる。

ハード触る処理とゲーム処理をごちゃまぜに一つの方式で扱おうとしてるといつまでもタスクシステムから逃れられないと思う。
ハードは割り込みあるから本質的にイベント駆動だけど、
ゲーム処理までそれに合わせる必要はない。手続き型言語丸出しでバッチ処理的にべた書き（1フレーム刻みだけど）できるし、そうすべき。
楽。チョー楽。
プログラム入門したての頃の楽しい感覚が蘇ってくるよ、べた書き。すいすい進むし、出来ることの幅がすごく広がる。

#プログラム構造の文献はCで完結するような原始的な領域の本が分かりやすくていいよ。組み込みとかの。SESSAME WGのとか。