旅の雲 2014年03月

2014-03-22

次のゲーム

　次のゲームの仕様がだいぶ決まりました。
　The Marshalを基礎として、今回はプレイヤーの立場をもっとずっと落として、キャラクターたちの性格設定を細かくする事にしました。The Marshalのときはプレイヤーの立場が元帥でしたが、今回は道場長？　です。登場するキャラクターは道場に通う道場生や、その他の旅人・冒険者たち。
　キャラクターはたくさんの技能や性格を持ちます。誰にどんな技能訓練を行なうか。誰と誰でPTを組ませて遠征に出かけさせるか。そのあたりを試行錯誤して楽しむゲームになる予定です。
　The Marshalが基礎になっているため、プレイヤーが望む最善の組み合わせが実現できるとは限りませんが。キャラクター同士にも相性があり、一緒のPTにしておくと道場をやめてしまうかもしれません。キャラ自身に希望する訓練内容があり、させたい訓練は怠けるかもしれません。師範と相性が悪い場合もやる気がなくなったりするでしょう。

　今まで作ってきたゲームと比べると、まだ一般向けのような気がしますが、そうは言ってもやっぱりだいぶマニアックだと思います。

スポンサーサイト

2014-03-23

The Marshal 1.04

　The Marshalをアップデートしました。
　ずいぶん久しぶりのアプデになりますが、一体何を変更したのか？

　きっかけは次のゲームです。現在構想中のゲームも、The Marshalと同じようにユーザーが画像を登録できるようにする予定です。そこで、どんな風に表示されるんだったかとThe Marshalを使って確認してみたのです。すると、なんかぎざぎざが目立つ。パブリックドメインの写真とかはあまり気にならなかったのですが、イラストとかだとずいぶん変わるんですね。
　そういうわけで描画設定をバイリニアに変更しました。ぼやけるという問題もあるようですが、このゲームに関しては縮小表示を滑らかにする恩恵の方が大きいと思いますので、たぶん前の方がいいという苦情は来ないでしょう。来ないといいなぁ…。

2014-03-25

あらゆるデータに触りたいクラスを作るとき

　今回はプログラムの話。
　私はいままで力技でゲームを作ってきました。シングルトン使いまくりで、設計とか考えずに、とりあえず動けばいい。そういうやり方を続けてきたわけですが、そろそろもう少し見通しのいいコードにしたい。そこでクラスを細分化し、どのクラスがどのクラスを知っていればいいのかを考えてみました。
　しかし、どうしても流れからはみ出たいクラスがいます。エラーメッセージ表示クラスとかデバッグクラスは、どう考えてもどこか特定の部署に属するようなものじゃないのでシングルトンでいいとしましょう。問題はイベントとセーブ＆ロードクラスです。こいつらはあらゆる箇所から呼び出されるようなクラスではないものの、あらゆるデータに干渉する可能性があります。
　いままでは、データの方をシングルトンクラスとして開放してました。これはこれで楽です。どうせ一人でプログラムしてるわけですから、自分の中で約束事を守ってさえいれば問題ありません。が、やっぱりお行儀が悪い。あらゆるデータがどこからでも干渉されるというのは、やっぱりちょっと流れを追うのに手間取ります。
　そこで考えたのがこの形。

class Data{
private:
　std::vector< Character* > characterlist;
};

class DataHolder{
protected:
　static Data* p_data;
public:
　static void SetData(Data*);
};

class Event : public DataHolder{
};

　Dataクラスみたいなものはたくさんあります。これはキャラクターのリストを保管してますが、マップを保管してるだとか、日付や所持金などを保管してるクラスもあるでしょう。そういったデータクラスをDataHolderクラスに登録しておきます。
　ただしDataHolderクラスにはpublicのSet関数はありますがGet関数はありません。よって、どこからでもSetはできるけどGetはできないわけです。これにより、Setされた各Dataクラスのポインタを利用できるのは、DataHolderクラスか、その継承クラスに限定されます。DataHolderクラスはインスタンスを作りませんので、実際は継承クラスしかDataクラスを利用しないわけです。
　イベントやセーブ＆ロードなど、どうしてもゲーム中に存在するあらゆるデータへのアクセス権限がほしい、しかしデータの方を一般開放するのはまずい、という問題は解決できたはず。イベントは無数に作りますが、DataHolderクラスの変数はみんなstaticだからいくら作ってもメモリ使わないしね。

　で、私はDataHolderクラスはモノステートかと思ってたんですが、違うんですね。モノステートはインスタンスの生成を封じてあります。すると、このクラスはなんと呼ぶんでしょうか。特に名前がないのかもしれませんが。
　これがOOP的視点から見てどうなのかは知りません。少なくとも、いままでよりはましだと思います。だからとりあえず、ちゃんと動いてくれてる間はこれでよしとします。
　もしこれが当たり前の、どこにでもある一般的なやり方だったらすみません。あと、大きな問題を持っているとか、もっといいやり方があったら教えていただけると助かります。すぐにはやり方を変えられませんが、次の改良時期に助かると思います。

2014-03-28

次のゲーム

　次のゲームの仕様を少しずつ詰めています。
　キャラクターに必要そうな技能を書き出してみたところ、現在25種類。性格は37種類になってます。キャラクター同士で勝手にけんかしたり仲良くなったり、犯罪者になってみたり、さまざまなイベントを発生させるためにかなり細かく性格を用意しています。すべての性格をうまく活かせるかが問題ですが。
　来月中には戦闘システムの大部分を仕上げたいところです。キャラクターのイベントにどう対処していくかがゲームの中核であるのは間違いありませんが、ゲームの目的、プレイヤーの判断の成否を判断するのはやはり戦闘です。まぁ、プレイヤーがすることはPT編成ですので、あまり複雑な戦闘システムにはならないと思いますが。あんまり複雑にしても、関与できませんしね。