2009年10月09日

ブロック破壊

block.jpg
手榴弾作る前にまず破壊できるオブジェクトを作らないと。
てなわけで壊れる壁を作ってみる。ただ壊れるだけじゃつまらないのでバラバラの破片に分解して擬似物理演算で飛び散らせる。一個のブロックにつき16個の破片を生成。大量に破壊したときに心配だけど、別に破片同士に当たり判定があるわけじゃないので大丈夫っしょ。
posted by 鶴 at 02:06| Comment(0) | TrackBack(0) | 同人ゲーム

2009年10月01日

狸野氏が描いた(催促?)漫画

turu.jpg
うわぁこの肩書きはハンカチ王子とかハイパーメディアクリエイター並にこっ恥ずかしい。
でもこの恥ずかしさがバネになったのか変なモチベーションが沸いてきたぞ。
ちょっくらスーパーテクニックで手榴弾のコードをサクッとハックしてみるか。
posted by 鶴 at 18:55| Comment(0) | TrackBack(0) | 同人ゲーム

2009年07月12日

アクセラ納車

axera3.jpg
ついにアクセラ納車。いやもうなんていうかカッコイイ。
足回りもしっかりしていて加速も軽やか、運転していて楽しい車である。
i‐stopについてはオマケ程度にしか考えてなかったので興味はそれほどでも。赤信号のイライラが軽減されるのはいいが、変なタイミングでi‐stopがかかってしまうと逆にストレスが溜まってしまうのでOFFにしちゃうことも。

まだまだ乗り始めなのでこの車の魅力は現在徐々に模索中。
ハンドルを握ればZoom-Zoom! Mazda AXELA!

posted by 鶴 at 00:00| Comment(0) | TrackBack(1) | 日記

2009年07月01日

アクセラ買っちゃった

axela2.jpg
もう数週間前の話になるのですが新型アクセラスポーツ20S買っちゃいました。今は納車待ちです。
簡単に言うけど買うまでにはそれはもう十分な下調べをして、グレードからメーカーオプション、ショップオプションのすべてを頭に入れていたので、アクセラに関してはもうディーラーの人よりも詳しくなっていました。人生で初めて買う車なので失敗はしたくなかったもので。
心配していたファニーフェイスの画期的なデザインですが実際に見てみると写真以上にカッコよくて、今では初代アクセラが地味に思えるほどです。
ちなみに色はセレスチアルブルーマイカ(通称ドラえもん)ボディタイプはハッチバックにしました。セダンもちょっとカッコイイかなと思ったのですが、ウチの彼女の頭の中ではセダン=おっさん臭いの構図が出来上がってるらしく泣く泣くハッチバックを選択するはめに……いや泣いてなんかないもん。
posted by 鶴 at 01:25| Comment(0) | TrackBack(0) | 日記

2009年03月05日

アクセラたん欲しい

「わたくし今までFF(前輪駆動)車というものを馬鹿にしてました」そう語る彼の口調は穏やかだが、その眼は新しい玩具を発見した子供のように輝き放っていた。

清く正しいクルマというものはFR(後輪駆動)でありFFスポーツカーなんてものは製造コストを下げただけのまがい物にすぎない……と。確かにゲーム等では特徴を誇張するためかオーバーステア傾向が強く、実際に昔のFF車や軽自動車に乗っていると曲がり辛いという認識は持っていました。
だが、去年の奥州旅行の時、レンタカーでアテンザ(FF)を運転させてもらったときにその考えは180度ターンすることになったのです。実際に運転してみると、えっこれがFF?というくらいよく曲がる車でした。
日本のメーカーがFFを主流にするようになって20年以上。FRは一部のピュアなスポーツのみ許されるものになってしまい、値段の格差もより広がってしまって、大衆スポーツカーの終焉を嘆く声が聞こえていた中、日本のメーカーがFFの弱点をそのまま放って置いたわけではないのだなーとハンドルをもちながらしみじみ感じてしまいました。
そう認識するようになると今まで眼中になかったようなクルマに目が行くようになってくるわけで、視界を広げてみるとアクセラというアテンザより小柄にもかかわらずスポーティなモデルのクルマに惹かれてまいました。このクルマ調べれば調べるほど思ったとおりの評価で、低中回転での加速、ハンドリング、車体等などがバランスがよく完成されており、ロードスターのようなライトウェイトスポーツとは別のピュアなスポーツコンパクトとしての位置付けマツダの中で確立しているのだと思いました。
もっともアクセラがこの位置で成長し続けていられたのは日本ではなくて海外での評価、そして北米の若者の間でのスポーツコンパクトの人気のおかげであることを忘れてはいけないでしょう。ありがとうアメリカ人。君たちのおかげで日本でこのジャンルの技術が失われずに育ったことを感謝しています。
だが現在、アメリカ発の不況円高の影響で輸出に頼ったスポーツコンパクトの開発も危ぶまれる状況に陥っています。今こそ日本国内でもFFスポーツに注目し、昔のような大衆スポーツ文化を新たな形で花開かせるべきではないでしょうか。
……以上マツダ広報のように語る単なるマツダファンからでした。

それはそうと割と本気でアクセラが欲しい今日この頃ですが、もうすぐフルモデルチェンジすることになっていて2代目アクセラの姿がいろいろ公開されているではありませんか。
axela.jpg
でも新しいデザインが斬新すぎてどうもこのファニーフェイスなフロントマスクが賛否両論なのである。しかし何度も見ていると見慣れてきて、動画でもそれほど違和感なく走っているのを見ていると急いで現行モデルを買ったほうがいいのか、しばらく2代目が販売されるのを待つのがいいのか迷ってしまう、良い意味で微妙な次期なのです。
posted by 鶴 at 18:33| Comment(0) | TrackBack(0) | 日記

2009年02月06日

変数の初期化ミス

昨年末にリリースしたドールズイングラムですが、ユーザーからの報告で時々上下スクロールしなくなるというバグが発生していました。原因を調査しようにもウチのデバック環境ではまったく再現しなかったのでほとほと困り果てていたのですが、このたびやっと原因が分かって1.02の修正パッチを出すことができました。

そこで、反省と今後の対処も踏まえて原因を振り返ってみます。

問題の箇所はスクロールの状態を示すメンバ変数でした。これを設計した段階ではコンストラクタ時に必ずA,B,Cのいずれかの状態に設定され問題なく動作していたのですが、後の機能拡張時に初期化処理をコンストラクタではなく、専用の初期化関数のなかでやるように設計を変更したのです。こうすることによってスタート時や再スタート時、コンティニュー時等どの開始時にも同じ箇所で初期化できるのでコード的には良いリファクタリングだったのですが……。
その代りに内部で条件分岐しながら初期化処理を行わなければならないという複雑さがプラスされてしまったのです。

ちなみにC言語は未初期化の変数の中身は何が入っているか分からないというのが仕様なので必ず自分で初期化するのが常識です。しかしそのための初期化関数がいろんな箇所から呼ばれる場合、例えば偶然にもたまたま「初期済み」という状態がその変数に入っていたとしたら……。

はい、今回のバグの原因はその偶然でした。

それでもちゃんとリファクタリング時にチェックして正常に処理することは確認していたのですが、そのテストがデバックモードだったので本番のリリースモードでのコンパイルとは少し条件が違ってしまったのです。
再現性が低いのとデバッガー使用時にはまったく再現しなかったので原因を見つけるのが困難でした。

このバグの対処方法は、コンストラクタ初期化子で「未初期化」という状態を入れておくことで解決しました。今後この手のバグが起きないようにするには、すべてのメンバ変数を必ずコンストラクタ初期化子で一回初期化しておくという方法で解決できます。
しかし、これだと二回初期化することになってしまい、コードも2箇所に書かなければいけないというのはエレガントではない気もします。
でも、次期C++仕様(C++0x)ではメンバ変数の初期化を
int state = 0;
のように宣言時に書けるのでこれならば、スマートのまま今回のようなバグを未然に防ぐことができそうです。

つか早くC++0x実装のコンパイルでコードを書きたい……。
posted by 鶴 at 05:29| Comment(0) | TrackBack(0) | プログラム系

2008年12月30日

C75冬コミお疲れ様と今後の展望

冬コミお疲れ様でした。
今回のドールズイングラムは主催ではなかったのですが、プログラマーとして腕試しができて面白かったです。ただ、せっかく横スクロールのゲームシステムを構築できてスキルも多少はあがったのに、これで終わりにするにはまだまだ物足りないという気持ちがあり、ドールズの今後の展望をコミケ後に狸野氏とわいわい盛り上がっていました。

まず方向性としてジャンプアクション系に進むのか、それともシューティング分を増やすのかで分かれました。

ジャンプアクション系はスーパーマリオやソニック的にステージの変化を増やしたり、ジャンプ(≒重力)で楽しさを演出したいという考えです。これは一見地味ですが、重力や物理演算的なギミックを追求したり、広いステージを縦横無尽に駆け回ることができれば内容的には楽しくなるのではないかと思います。また、2Dの箱庭的な世界を作るという意味では作る側も結構楽しいものです。

シューティング系はステージのギミックより攻撃のギミックを主体に置くことです。ガンスターヒーローズ、魂斗羅、メタルスラッグのような方向です。個人的にはあまり好きなジャンルではないのですが、ゲームを派手にできるという利点もあり、パリティの時には派手な演出を評価いただいていたので、実はもっとも得意とするジャンルなのではないかと勝手に自負しております。

さてどちらの方向に行けばいいのやら。単純に両方やれば良いじゃんとも思いますが、中途半端な方向性はゲームの面白さにつながらないのが弱点。
posted by 鶴 at 00:00| Comment(0) | TrackBack(0) | 同人ゲーム

2008年12月16日

マスターアップしました

もう数日前になりますがホントぎりぎりまで頑張って無事マスターアップしました。それでもまだまだやり残した感はありますが、その気持ちは次回作への活力にしたいと思います。

それはともかく完成したので早速体験版をWEBで公開したいのですが、全19面のうち最初の面だけだと簡単すぎて淡白なゲームと思われちゃいそうということで、体験版オリジナルの面を3面+ボスで作ることになりました。早速敏腕ゲームデザイナーの狸野から草稿のMAPがとどいたのでテストプレイしてみたがこれがまた難しい!!
体験版なのにこの難易度だと逆にユーザー離れを起こすのではないかと心配しながら、それでもなんとか1−3まで進めたのはいいのですが、どうしても最後のゴール手前のジャンプで天井に頭をぶつけて池ポチャしてしまうのでした。
doll2008_1216.jpg
クリアできるのかと疑問に思いつつもあと少しで対岸に届きそうなので、これは元メガドライバーでカイの冒険(ムズイ)やサンドラの冒険(超ムズイ)もクリアしたことのある私に対する挑戦と受け取り何度もトライしたのですがどうしてもあと数ドットのところで落ちてしまうのでした。そもそもココに来るまでが大変なのに……。
結局、課長の有野状態で1時間以上この面をトライしつづけてついにリタイア、敗北宣言をしました。

鶴 の発言:
 クリアできませんでしたorz
狸野 の発言:
 体験版?
鶴 の発言:
 Trial-3の最後何度やってもダメだめだった
狸野 の発言:
 バッチファイル作ったらちょっとマップ調整しよう。Trial-3ってなんだっけ
鶴 の発言:
 ぎりぎり端でジャンプしないとゴールにとどかないトコ
狸野 の発言:
 ちょっとみてみよう

狸野 の発言:
 フイタw これ無理だ
鶴 の発言:
 ちょwwwwwwww!1時間かえせ!!!
posted by 鶴 at 00:00| Comment(0) | TrackBack(0) | 同人ゲーム

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) | プログラム系