2008年11月30日

ドールズイングラム製作中

doll2008_1129b.jpgdoll2008_1129a.jpg

という訳でドールズイングラムを冬コミに出せるように頑張って作りこんでいます。色々とアピールポイントを書きたいけど、それよりもプレス締め切りまでは少しでもクオリティ上げに専念したいので紹介は12月中ごろに。体験版も公開できるといいな。
先行版から主に大きく変わったのはマリオ1的後戻りできない横スクロールだったのが上下左右に自由にスクロールするようになったことです。これで8ビットから16ビット世代的な雰囲気になったかも。
しかし狸野のデザインするマップ配置は鬼のように難しく後半ステージとかこれクリアできるのか?って思いつつ何度もプレイしてパターンを覚えちゃったりしてます。
でも参考に昔のゲームやってみたけど、ロックマンとかめっちゃくちゃ難しいよね。あれデザインした人は鬼か?鬼なのか?あれに比べるとドールズなんてゆとりゲームです。

ドールズイングラム
C75 二日目月曜日西地区 "よ" ブロック 24a
posted by 鶴 at 00:47| Comment(0) | TrackBack(0) | 同人ゲーム

2008年11月09日

c++でメッセージ送信

ゲーム中に発生するイベントを、発生した場所から処理するオブジェクトへ伝えるために、c++では基本的にメンバ関数を使う。
だが、単純な構造の時は全然問題ないのだが、システムが複雑になってくると自機やステージみたいな重要なオブジェクトへのアクセス種類が増えてしまい、その結果インターフェースとしてのメンバ関数も増えてしまうことが良くある。
設計の教科書だとこういう場合は、ひとつのオブジェクトに処理を手中させずに処理ごとにクラスを分けるべきと書いてあるかもしれない。ただ素人じゃないので簡単に分割できるような処理だったら最初から別クラスで設計してあるだろう。そうでないものを無理やり分けてしまうとオブジェクト間の依存率が高いものになってしまい逆に全体の複雑さが増してしまう。そういう問題を解決するためのデザインパターンは……

っていうお堅い話じゃなくて、メンバ関数が多いなら入り口を一つにまとめちゃえば?ってのが今回思いついたアイディア。
もうイベント毎に新しいメンバ関数を追加するのは懲り懲りにゃ、基底にメッセージを受け取るインターフェースを一つ作っておくから今後はそこにお願い。

class Object {
public:
virtual void message(string s){
throw runtime_error("message失敗");
}
};


こんな感じ?後はメッセージの内容を継承先で動的に解析して処理しちゃえばいいのです。今時のC++は正規表現も使えるし……と思ったけどせめて解析を楽にするために関数名と引数ぐらいは分けておくか(あと引数を参照に)
virtual void message(const string& function, const vector<string>& arguments){...

なんかすべてのメッセージをこれで処理できそうな気がしてきた。それってどこかで見たことあるような……Smalltalkみたいなオブジェクト指向の原点に近いのか?

とは言え、さすがにすべてをこれで処理しちゃうと何がなんだか分からなくなりそうなので、ゲーム中におきるイベントや通信系イベント、Windowsメッセージみたいに用途を決めて使えば多少はコードがスッキリしないだろうか?と願いつつ、成功するのか微妙な結果に終わるのかはまた今度。
posted by 鶴 at 04:53| Comment(0) | TrackBack(0) | プログラム系