Xbox360「ミラーズエッジ」


このレビューはWillVii株式会社が運営する
国内最大級家電・ゲームレビューサイト「みんぽす」から
商品を無償でお借りして掲載しています。
本レビュー掲載によるブロガーへの報酬の支払いは一切ありません。
レビューの内容につきましてはみんぽすやメーカーからの関与なく
完全に中立な立場で書いています。
（唯一事実誤認があった場合のみ修正を行います）
商品無償貸し出しサービス「モノフェローズ」に関する詳細はこちら。

難易度ノーマル、クリア。

FPS視点でありながらシューティングではなく
ビルの屋上や壁などを飛び移りながら駆け抜けるゲーム。
その斬新な企画で発売前から評判だったし、
こういった実験作が登場するのは非常に評価したいが、
懸念されていた遊びにくさが現実となってしまった。

ジャンプはLBボタン、しゃがみはLトリガーに割り当てられていて
変わった配置にも思えるが、要するにボタンの並びと
移動方向が一致していると考えればよい。
走っている最中にLトリガーを引けばスライディングするし、
壁に向かって走りながらLBボタンを押せば
壁にジャンプしてそのまま走る（ウォールラン）。

さて、こういったジャンルであれば
自分のキャラクターが確認できる
背後カメラ（TPS視点）になるのが一般的。
というのも、第三者からの景色で確認しないと
主人公と飛び移る足場の距離感や、
正確な踏み切りのタイミングがつかみにくいからだ。

今作はFPS視点なので、
そのあたりの動かしにくさが顕著に出ており、
ある場所から飛び移ろうとしたらジャンプするのが早すぎたり、
自分が思っていたより足場が遠かったり、
手すりに近づいたときにうまくつかめなかったりというミスが
頻発する。

もともと舞台の大半がビルの屋上や、建物内の高い階層なので
そういったミスはそのまま落下死につながり、
直前のチェックポイントから再開することになる。
本来であればそういったミスが起こらないよう、
行動を起こす前に地形や足場を入念に確認するのだが、
それを妨げるのがこのゲームの最も悪である「敵の存在」だ。

かなりの場面において主人公を追う複数の敵がおり、
しかも銃器を装備していて容赦なく連射してくる。
立ち止まっていてはすぐに蜂の巣になるので
とにかく走る必要があるが、走っていても運が悪いと
結構な連続ダメージを喰らうため、
ひたすら敵から離れるよう進み続けなければならない。

しかし、初見のステージでいきなり敵に遭遇したとしても
どういったルートで進めばいいか知らないため
なんとなくそれっぽい方向へ進み、
迷ったり落下したりしながら試行錯誤するしかない。
この間、しょっちゅう敵の銃弾を喰らって
ゲームオーバーになるため
初回プレイで感じる理不尽さは尋常ではない。

敵と戦闘するにしても主人公は丸腰のため、
パンチやキックで何度も攻撃してダウンさせるか、
敵が銃で殴ってきたわずかなタイミングで
Yボタンを押して武器をもぎ取るしかない。
しかし、主人公はとにかく打たれ弱くできており、
敵に銃で２回殴られただけでゲームオーバーになる。
つまり２回以内に武器を奪うボタン押しに成功させるしかないが、
敵が複数の場合、その間も別の敵から銃撃を受ける。

敵の銃弾はかなりの距離から届くのだが、
主人公は格闘戦しかできないので原則として逃走ばかりになる。
しかし非常に死にやすいため、特に後半のチャプターは
ルートを間違えてモタモタして死亡、飛び移るのに失敗して死亡、
敵との戦闘に負けて死亡という、
ひたすらトライ＆エラーな内容になる。
このイライラには何度も投げ出したくなった。

グラフィックは非常に美しく、
一般のリアリティ表現と違って壁や柱が原色で塗りつぶされ
次にたどるべきルートをぼんやりと示してくれる。
このデザインは非常にクールで、
次々とうまく飛び移れたときは相当にカッコいい。

ルートに関連する部品が原色で塗られるといっても
何も考えなくていいほどクッキリしたヒントにもならないため、
探索したり観察してルートを開拓していく必要がある。

さらに、どのあたりに目的地があるのかを確認するために
Bボタンを押すとその方角にカメラが向く仕様になっている。
しかし、このBボタンも意外と曲者で
敵から大急ぎで逃げているとき、
ゴールがどちらの方向か知るために
うっかり走りながらBボタンを押すとカメラの向きが変わってしまうので
主人公が急旋回して今までと違った方向に進んでしまう。
高くて足場の悪いところを走っていた場合、これで即死する。
（しかし、たいていの場合、
　立ち止まって調べるほどの余裕もない）

とにかく敵さえいないか、せめて格闘戦のみの戦闘であれば
もう少し理不尽なストレスを感じずに
プレイすることができたと思う。
銃弾がひっきりなしに飛んでくるだけに
ルート探索や飛び移りアクションがどんどん雑になってしまい、
「なんだかよくわからないけど無理やり進むことができた」
「今回は運がよかったから銃弾に当たらずに済んだ」
のような、いい加減なプレイ感になってしまう。

やっていることは「プリンス・オブ・ペルシャ」と似たようなことなのに
それと比べて達成感や気持ちよさが大きく違った。
やはり、こういったアクションに
FPS視点は向かないというのを再認識させられた。

家に帰ってからこの時間まで
ずっとプログラムしてるなんて久しぶり。

今日一日悩んで調べて試したことは
イマイチ使い物にならないことがわかった。
結局、あらかじめ用意された機能より
自分で作ってしまった方が遥かに思い通りに動いた。

懐かしくも「るろうに剣心」の再放送をやっているなぁ、と
毎週録画で自動予約していたら実は平日毎日の放送だった。

第１回放送から１週間ぶりに観たら
知らないうちに仲間が増えてみんなでごはん食べてた。

アルファベットを紹介するだけの立体絵本

１文字ごとにアイデアが利いてて良い。オシャレ。

お年玉年賀ハガキ 当選番号チェックサイト

昔も紹介したことあるけど、毎年便利に使っているサイト。
今後も忘れないように
この時期になるたびリンクを張っていこう。自分のために。

ひき肉をこねたときの脂で
手が永遠にヌルヌルするのはなんとかならないものか。

ハンバーグとか大好きだけど
あのヌルヌル（手の皮がもう一枚あるような）は嫌い。

数年前に電波時計に出会って以来、
テレビの時報と１秒もズレない正確さにホレこみ
腕時計から掛け時計、目覚まし時計まで
すべてを電波時計に換えてきた私だが。

結婚して新居に移ると鉄筋構造なのか
部屋の中で電波が入らないという衝撃の事実。

電波圏外で生活してみてわかったのだが、
もともと手動で調節するクォーツ時計と違って
毎日電波で時刻修正する前提の電波時計が
電波を受けない場合、やたらと精度が悪い。
一日に１秒ズレる程度の精度でも
また電波で修正されるから問題がないのだろう。

そんな時計が電波圏外なわけだから
部屋中の電波時計が好き勝手な時刻を刻んでいる始末。

どうにか解決法がないかと以前にも書いたが、
無線によって親機と子機の時刻を一致させるような時計しかなく
それだと今までの電波時計を
すべて置き換えないといけないわけで。

ということでいい加減イライラしていた正月、
ふと調べていると「電波時計ブースター」なるものがあると。
ブースターと言えばテレビなどでも
弱い電波を増幅して強い信号に変える機械だが、
これは電波時計版のブースターらしい。

理屈としてはブースターを多少でも電波の入るところに起き、
そのブースターが他の電波時計へ電波を飛ばす、と。
ブースターが飛ばす電波は
一般の電波時計が欲しがる信号そのままなので
今までの時計をそのまま利用できる。

しかもブースター自身が電波を受信していないときでも
時計への電波を発信することができるらしい。
つまりは、ブースターの時計を自由に変更して電波を飛ばせば
一斉に周囲の電波時計の時間を変化させることが可能という、
殺人事件のトリックにでも使えそうな機能まで。
（本来は地下の工場など、
　広くて電波圏外の場所にある複数の時計を調節するためにある。）

２万３千円もする機械だったが、
新たな電波時計を買ったと思うことにして購入。

早速、ブースターの時刻を調節してリビングで電波発動。
次々に時刻調節していく複数の時計。まさにポルターガイスト。

平和が訪れた。

ここ数日は創作意欲ビンビンです。

ここまで来たらもう何がなんでも完成させるしかない。
とりあえず妻にテストプレイしてもらったことで
ずいぶんいろんな改善点が洗い出せたので
ここ３日ほどでかなり直った。

わー。説明書づくりに２時間もかかった。
その後にタイトル画面を即興で作成。

サンプルステージを作る過程でいろいろバグも見つかったけど
とりあえずザクッと直して、Ver.1.00完成。

今晩、Vectorに登録申請を出します。おそらく近日中には公開。

完成を確信した前回のプチメタ更新直後、
先輩たちの手によって即座にＡ級バグ発生。

そこから２時間ほどかけて修正とテストプレイ。
妻にもサンプルステージをプレイしてもらってさらに調整。

Vectorへの登録作業も完了しました。
あとはVectorの処理待ち。来週には公開できるといいな。

Vectorに作品登録申請をした翌日になって
エラー落ちする致命的なバグ発覚（お約束）。
なんでこんなバグが昨日まで出現しなかったんだろう（お約束）。

かなり複雑な内部構成をしているだけに、
Ver.1.00とは言いながらもβバージョンという気持ちで見てください。

今回の新作ソフトはやや変わった内容なので、
短時間で内容を紹介する動画を作ってみました。



この動画作成だけで要２時間。初めて字幕を挿入してみました。
その関係でYouTubeの「高画質で表示する」で
高画質バージョンで見た方が見やすいです。

物理ギミックパズル「あそぶつり」。
来週あたりに公開されるはずです。お楽しみに。

妻と二人して風邪でダウン。

頭の上半分が熱い。
ひたすら寝てました。

ブックオフのタメシ買いセット（少年コミック）、
５作品×３冊すべて読了。

School Rumble（スクールランブル）
東京アンダーグラウンド
こわしや我聞
I’ll（アイル）
コロッケ！

ヒットは意外にも「コロッケ！」。個々の感想はリンク先へ。

３冊ずつとはいえ、いろんな作品を次々読んでいくのは結構大変。
でも７７７円にしたらかなりの時間が潰せた。

今年（というか去年）のM-1グランプリがあんまりなデキだったので
２００１年から２００６年までのDVDをひたすら妻と観ている。

コンビのネタが終わるたびに、
「これは良かった」「このネタはパンチがなさすぎ」などと
勝手なことを二人で言い合いながら観るのが楽しい。

２００４年のアンタッチャブル、
２００５年のブラックマヨネーズ、
２００６年のチュートリアルの流れは最高のデキ。
どの優勝者もまさに王者といった感じ。売れるのがわかる。
それだけに２００７年以降は勢い不足を感じるなぁ。

新作「あそぶつり」の経緯　その１

まだ一般公開されていませんが、今回の
物理エンジンを使った作品「あそぶつり」に至るまでは
いろいろな問題にぶつかりました。

そもそも海外の実験プログラムや市販ゲームから
「物理エンジン」という言葉を聞くようになり、
いろいろなデモ動画とかを見ては
その動きの良さに憧れた。
さらにXbox360を遊んでいると、
実際に物理エンジンが働いている様子が
自分のプレイの上でも感じることができた。

そんな中、実際に自分でもチャレンジしてみようと思ったのが
去年の冬休み、３月。

それまで「物理エンジンを使っている」ということは読み取れても
それが一体どういう行為なのか実感が湧いてなかったわけだけど、
一般のゲームプログラムが

　プログラム上でキャラクタの座標の初期値を設定
　　　　　　　↓
　キー操作やＡＩ・重力によって
　キャラクターの座標をその都度、加減算。
　　　　　　　↓
　その座標に合わせてキャラ画像を表示

という流れなのに対して、物理エンジンを使うプログラムは

　プログラム上以外に物理エンジンの方にも３Ｄ世界を作り、
　プログラム上で出したいキャラの位置と
　形・大きさ・質量を物理エンジンに登録。
　　　　　　　↓
　物理エンジン側の時間を進める
　　　　　　　↓
　物理エンジンの世界では衝突や重力によって
　キャラの位置や向きに変化が生じる
　　　　　　　↓
　その位置と向きの情報を取り出して
　プログラム上のキャラの位置と向きに反映。
　　　　　　　↓
　プログラム側で物を投げたり移動させたり消したりしたい場合は
　その都度、物理エンジンの世界にて
　キャラに対応する物体を同様に処理する。

という流れになる。
今までプログラムが主導だった部分が
ちょこちょこ物理エンジン主導になったり、
と言いつつもやっぱりプログラム主導だったりと
最初はかなり戸惑った。

そのあたりで作れるようになったのが、
物理エンジンを使ったデモ（２００８年４月）。



これができただけでもかなりの達成感があった。つづく。

新作「あそぶつり」の経緯　その２

物理エンジンの支配する「物理世界」に作れる物体は
直方体や球、円柱などといった、ごく単純な形が中心となる。
複雑になればなるほど計算の負荷が増すからだ。

つまりゲーム画面上でライフル銃が転がっていたとしても
物理世界では細長い円柱と平たい直方体を組み合わせた
立体物だったりする。

逆に言えば、ゲーム中のドラム缶（円柱）や木箱（直方体）や
リンゴ（球）のような単純な形そのままのものはずいぶん楽だ。

さて、物理エンジンがある程度使えるようになると
ドミノ倒しみたいなものはすぐ作れるだろうと思った。
物理世界に直方体を並べ、ボールか何かをぶつけて
ドミノを押せば次々衝突して倒れていくはずだ。

が、これが実はうまくいかない。



ドミノが倒れて次のドミノにぶつかったとき、
倒れかけているドミノは立っているドミノに押される形になるので
接地している方の面が滑って、その場に倒れてしまうのだ。

そこで物体同士が衝突したときの摩擦を高めてみると
今度はドミノがまったく倒れなくなった。



ドミノが地面を滑ることはないものの、
次のドミノとの接触面の滑りが悪くなって
つっかえ棒のようにガッチリとドミノが支えられてしまう。

つまり、摩擦を強くしても弱くしてもドミノは倒れない。
日常生活で簡単にできるドミノ倒しでも
物理世界ではバカ正直すぎて理想通りにならないのだ。

ちゃんとしたドミノ倒しを完成させるためには
どの物体同士の衝突かを見極めて
摩擦係数を変化させる必要がある。



こうすればドミノは次のドミノの表面を
スムーズに滑りながら倒れつつ、
接地している面は滑らずに「前へ」倒れてくれる。

そうして完成したのがドミノ倒しデモ（２００８年４月）。



このぐらいまでなら学生でも触れるようになると思う。
物が衝突し、崩れ落ちるさまが表現できるので
「物理エンジンを利用している」という感触は手に入れられる。

しかしこの先の領域に進むには
自分の理想通りの動きをさせるために物理エンジンのプログラムを
細かく改造できる腕が必要になってくる。つづく。

新作「あそぶつり」の経緯　その３

２００８年４月あたりに物理エンジンを触り始めたものの、
そこから仕事が忙しくなって、
次にちゃんと研究が始められたのが夏休み。２００８年８月。

最初、物理エンジンにあらかじめ用意されている処理で
「物体に力を与える処理」と
「物体に速度を設定する処理」の違いがわからなかった。
どちらを使っても物体が移動するからだ。

ここで質量の概念を理解しなければいけなかった。
ここまで物理を意識にするのは高校以来。

質量は重さと混同しやすいが、
重さというものは重力があってこその話。
重いボウリングの玉と軽いサッカーボールでは
同じような大きさでも重さが異なる。
しかし、無重力に持っていけば両方とも０kgである。

では無重力の中ではボウリングの玉もサッカーボールも
同じ動きをするかというと、
やはりボウリングの玉を動かす方が力が必要になるわけだ。
質量が大きいものは動かしにくく、
また、動いている物体は質量が大きい方が
強い力を持っていることになる。

さて、物理エンジンの「物体に速度を設定する処理」を使って
物体の移動速度を時速１００km/hに設定すれば
どれだけ質量の大きい物体でも小さい物体でも
次の瞬間に１００km/hになっている。

しかし「物体に力を与える処理」を使って
物体に１００の力を加えた場合、
質量が大きくて動かしにくい物体はそれほど速度が上がらず、
質量の小さい物体は一気に加速する。ここに違いがある。

ゲーム中で重い砲弾も軽い砲弾も同じ軌道で飛ばしたければ
力を加える処理ではなく
速度を設定する処理を使わなければいけない。
力を加える処理を使ってしまうと重い砲弾がほとんど飛ばなくなるし、
重い砲弾を軽い砲弾と同じように飛ばすために
与える力をどれぐらい増やせばいいのか調整しにくいからだ。

しかし、ゲーム中に風が吹いて物体が吹き飛ばされるような処理では
速度を設定する処理ではなく力を与える処理を使う。
速度を設定する処理を使うと軽い物も重い物も
まったく同じ速さで吹き飛ばされて不自然だからだ。

この違いがわかったとき、
なぜ２つの処理が用意されているかがスパッと理解できた。
（物体の回転に関しても
「角速度」と「トルク」と呼ばれる同様の違いがある）

このあたりを踏まえつつ、いろいろな実験を踏まえて
作った物理エンジンのプログラムが以下の動画（初公開）。



ある一点から一定の距離内にいる物体に対して
ある瞬間に中心から外向きの力を与えると
爆発させたように見せられる。

同じ理屈を使って一定方向に継続的に弱い力を与え続けると
風が吹いたように見せられる。

銃口の位置から発射した直線に最も近くで当たった物体に
当たった位置を基点として力を与えると
銃弾に当たって弾いたように見せられる。

同じ理屈で画面中央の照準にどの物体が合わさっているか算出し、
その物体に対して自機の方向へ力を与えると
物体を吸い寄せているように見せられる。
（Xbox360の「バイオショック」に影響を受けた）

そういった様々な表現を実験した。

物理エンジンの物理世界の状態を一時保存し、
物体が崩れ落ちる直前にリセットする処理も作った。
これで物理世界の状態をファイルにセーブ・ロードできるようになった。

エディット機能も作った。
物理エンジンの世界を一時的に停止して、
マウスで狙ったところに自由に物体を置けるようになった。

夏休み中の１ヶ月ほどでかなりの研究が進み、
いろいろなものが作れそうな予感がした。

が、ずっと気になっていた問題点があった。つづく。

新作「あそぶつり」の経緯　その４

３Ｄ空間に自由に物を置けるエディット機能が付き、
物理エンジンの働く中で物を置いたり投げたり崩したり
いろいろできるソフトはほぼ完成した。
この時点での開発コードネームは「物理エンジンで遊ぼう」。

画面の中で物理的な現象が繰り広げられるのは
眺めているだけで楽しいので
「誰でも物理エンジンを体感できるソフト」にする予定だった。
しかし、それだけではただの実験ソフトなので、
例えば積み上げられた物体の上にプレゼントの箱が置いてあり、
物を崩してプレゼントを地面に着地させればゴール、のような
何かゲーム的な要素を入れようかと思いついた。

ただ、このとき常に感じていた問題が、操作がややこしいこと。
「わかりやすくて直感的な操作＝マウス操作」なのだが、
マウスは前後左右という平面上しか動かせない。
縦と横という２軸の移動量しかわからないのだ。

なのに、３Ｄ空間内をキャラクターが移動するためには
前後左右に加えて上下という３軸方向があり、
さらに見ている向きを上下左右に変える操作も必要になる。



しかも物体を置いたり手に取ったり回転させたりするなら
マウスだけでは足らず、キーボードのキーまで併用することになる。

３Ｄ空間の中を歩き、落ちている立方体をつかんで
別の立方体の上にピッタリ置く、という操作だけでも
かなり難しいし、コツが必要になるのだ。
いくつもの物体をきちんと高く積み上げることを考えると
上下の移動はジャンプのような挙動ではなく、
静止したまま上下にアップダウンできる仕様でなければならない。

ゲームコントローラーなどは直感的な操作に特化しており
こういった面ではかなり優秀なのだが、
マウスでできる操作というのは極端に少ない。
右親指で２つのボタンを同時押ししたり、
左親指でスティックを倒しながら人差し指でＬボタンを押す、などという
市販ゲームでよくあるような芸当は真似できないのだ。

さんざん悩んだあげく、
「３Ｄ表示ではあるけれど、２Ｄとして動くようにしよう」
と大きな変更を決断した（２００８年９月）。
DSの「Newスーパーマリオブラザーズ」でもあったが、
３Ｄモデルを使ってはいるが、画面に対して上下左右しか移動せず
操作に関しては古いゲームと同じ２Ｄ操作なのだ。

これなら画面に対して前後方向（Ｚ軸）に関する操作を
無視することができ、かなり簡略化される。
それに合わせて物体の回転も
正面に対して右回り左回り（Ｚ軸回転）のみに限定する。

今まで勉強した物理エンジンは３Ｄ用なので、
物理世界の動きを毎回チェックし、前後方向にズレた物体や
手前・奥に対して回転した物体を逐一修正する、という方法を取った。
前後に崩れかけた物体を即座に整列させているのでかなり強引だ。



今まで使っていた物体は球やカプセル型だが、
前後に倒れることがなくなった今回の改造によって不自然になったので、
円柱を横倒しにしたような見た目に変更した。



３Ｄ空間を映すカメラは前方を真っ直ぐ見るだけに固定し、
向きを変える操作も必要なくなった。

これでずいぶん方向性が決まった。

そんなときPS3で発売された「リトルビッグプラネット」という
物理エンジンを使ったゲームの動画を観ると
同様に上下左右の移動が中心となっていた。
おそらく操作性を追求した結果、
同様にＺ軸を捨てる判断をしたのではないだろうか。
惜しむらくはこのゲームの発売前に完成しきれなかったこと。

方向性がいよいよ決まり、あとは完成まで突き進む。つづく。

新作「あそぶつり」の経緯　その５

３Ｄ表示ではあるけど２Ｄ操作ということが決定すると
一気に完成形がイメージできて作業が進んだ。

もともと、映画「バック・トゥ・ザ・フューチャー」の
オープニングに出てくる妙なモーニングマシンが大好きで
ボールが転がったりドミノが倒れる動作が次のアイテムに伝わり、
いろいろな結果を引き起こすギミックには昔から憧れていた。

高校１年生の文化祭では教室中にドミノ倒しを作った。

２年生の文化祭では理科室を借り切って
教室中にそういったギミックを張り巡らせるイベントを
クラス全体で企画した。
最初に人の手で押したドミノが重りを落とし、ボールを転がし、
最終的には花火に着火した。
一日数度しかない開催時間（その都度全部を復帰させる）には
理科室の廊下側の窓に観客がひしめき、かなりの人気を呼んだ。

クラスのみんなにも強烈な思い出になったようで、
３年生のときも同じ企画をやった。

最近ではNHKの「ピタゴラスイッチ」という番組に出てくる
ピタゴラ装置がまさにそれで、
高校のときの熱気を思い出した。

日常生活でこういったギミックを作ろうすると
かなりの物と手間と広さが必要な上に、
後片付けも大変だし、一回きりしか実行できない。

こういうのが手軽に体験できるソフトを作れれば、と思っていた。
物理エンジンに出会うまでは
２Ｄ画像のみでも作れるんじゃないかと思案していた。
シーソーやバネや風船やドミノというアイテムをあらかじめ用意しておき、
マウスでドラッグして好きなように配置できるソフト。
スタートとゴールの方法だけ決めておいて
たくさんのアイテムを絡めてゴール条件を満たした方が得点が高く、
その得点を貯めて新たなアイテムをアンロックするような。

ただ、アイテム同士のアクションをあらかじめ決めておく必要があり、
アイテムごとに判定を作る莫大な労力がかかる割には
動かしたときの結果が予想の範囲を越えないので
面白味に欠けるという想像がついた。
こういうギミックは
「まさかこの品物がこんな動きをするなんて」
というところに感激するものだ。

そんな想いと体得した物理エンジンプログラムが結びついた。
物理エンジンで動いているキャラクターは
あくまで物理現象に従っているだけなので、
開発者の予測を越えるギミックを作ることも可能となる。
あとはそれを使いやすい操作方法で提供するだけで
いろいろなステージを作れる無限の可能性がある。

となれば、より面白そうなギミックを作れるよう
ソフト側で手配してあげればいいのだ。つづく。

新作「あそぶつり」の経緯　その６

いろいろなギミックを作ることを考えると
個々の物体が自由落下するだけでは弱い。

そこでまずはジョイントを導入することにした。
２つの物体をつなぐ「関節」の機能である。
この処理そのものは物理エンジンに備わっているが
実際に導入してみると様々な問題にぶつかった。

今作「あそぶつり」ではアクションボタンを押すまでは
あくまでツールとして自由に物体を配置できる仕様になっており、
物理エンジンは作動していない。物理現象も起こらない。



たとえばジョイントでつながった物体をつかんで移動した場合、
ジョイントでつながっているもう片方を移動しないでいると
物理エンジンを作動させた瞬間に
２つの物体がすごい勢いで引き合う現象が起こる。

いわば腕と胴体がゴムひもでつながった人形の
腕だけを大きく引っ張っているのと同じなわけだ。
物理エンジンが作動するまでは胴体も腕も
マウスで動かしただけ引っ張っていけるが、
物理エンジンが作動した途端、
「ジョイントでつながっているから離れない」という物理現象が働き
離れていた物体たちがギュッと引き合ってしまう。

となると、物体を移動する際は
ジョイントでつながっている側の物体も含めて
ごっそり移動させる必要がある。

そのためには、その物体にジョイントがあるのかどうか、
あるならあるでいくつのジョイントがあって
どの物体とつながっているのかという情報を
きちんと管理していないと実現できない。
これが相当にややこしい。
プログラムで言う「再帰処理」も必須になる。

物体を回転させる場合も同様で
独立した物体を回転させる場合は物体の中心で回転するが、
それがジョイントで別の物体とつながっている場合、
物体を回転させることでジョイント部が離れてしまう。
そうならないように、
ジョイントでつながっている物体を回転させる場合は
ジョイント部を支点として回転するよう処理しなければいけない。
これもなかなかにややこしい。

さらに別のパターン。



物体Ａと物体Ｂがジョイントでつながっており、
物体Ｂと物体Ｃもジョイントでつながっている。
ちなみにＣは空中に固定されているので移動も回転もしない。

本来、物体同士が衝突するとめり込まないように反発するが、
ＢとＣはジョイントでつながれているので
衝突反応も起こらないようになっている。
どれとどれがジョイントでつながっているかを調べる処理も
物理エンジンには用意されている。



さて、こういった物体の場合、物体Ｂはジョイント部を支点として
回転できるギミックになる。
こういったギミックは今回のソフトにとって必須だろう。

しかし、最初これがうまくいかなかった。
物体Ａと物体Ｃが衝突してしまうのだ。



ジョイントで直接つながっているＡとＢ同士、
ＢとＣ同士は衝突しないものの、
物体Ｂを介して結果的につながっているＡとＣは
直接ジョイントでつながっているわけではないため
物理エンジンに用意されている
「両者がジョイントでつながっているか調べる処理」では
チェックできないのだ。
このままだと物体Ｂが少し回転しただけで止まってしまう。

そこで、ある物体からジョイントを通じてつながっている物体を
次々とたどっていき、
塊となっている物体すべてを同じグループと認識して、
その中では衝突判定が起こらないようにしないといけない。
これも相当にややこしい。

このあたり、物理エンジンを使っていたとしても
結局プログラマ自身の腕と対応力がかなり要求される。
世間で「物理エンジン」の評判が騒がれるようになって以来、
物理エンジンさえ使えば
楽々とリアルな物理現象が再現できる、という妙な誤解がありすぎる。

「物理エンジンを使っているならできて当然」というわけではなく
今までにもあったプログラミングの難しさに加えて
物理エンジン自身の制限にも挟まれることになり、
うまくいかなくて悩んだり解決法が見い出せない苦労を強烈に味わう。

教え子の中にも「流行りの物理エンジンを使ってみたい」的な
ミーハーな気持ちで興味を示す学生がいるだろうが、
やればやるほど地獄を味わうのが物理エンジンだと思う。
毎日のように壁にぶつかり、挫折しそうになる状況を
自分で解決できる力と覚悟がないなら手を出さない方が無難だ。

そのあたりはプロの開発者たちも知っているだろうから
ただ個々の物体が衝突している程度では
それほどの評価は得られないだろう。
そこから先の世界にこそプログラマのレベルが問われるのだ。

つづく。

新作「あそぶつり」の経緯　その７

最後に導入したのが「モーター」だ。
ジョイントが成功したとはいえ、
自由落下による重力のみを動力としたギミックだと
作れるものが限られてくる。

幸いにもモーターを設定する処理は
物理エンジンに用意されていた。
しかし、実際に使ってみると２つの問題があった。

ひとつは物理エンジンの用意するモーターが
ジョイントに対して回転力を与える機能だったこと。



ジョイントでつながった２つの物体に対して
ジョイントが回転しているように処理されるわけだが、
この場合、どちらの物体が回転しているのかがハッキリしなくなる。



あくまでジョイントが回転しているという概念ため、
２つの物体が逆回りする運動をする。
たとえばＡの物体が右回りをしているとき、
同時にＢの物体は左回りをする。

ということは、直方体にタイヤがついたような一輪車を作って
それが前進するようにタイヤを回したくても
車体である直方体も逆回りしてしまう。

さらには、ひとりで勝手に転がっていくタイヤような
他の物体とジョイントでつながっていない物を作りたくても
ジョイントに装着するという前提があるため実現できないのだ。

もうひとつの問題はモーターのパワーが弱いこと。

ギミックを作るために使うことを考えると
リアルな計算を踏まえて力不足で回転しないようなモーターよりも
設定した方向にガムシャラに回転する方が面白い。
自動車のような物体に長方形のタイヤを付けても
強引に跳ねながら進むぐらいのパワーがある方が楽しいのだ。

が、物理エンジンに用意されているモーターは
つながっている物体の質量次第ですぐに出力不足になる。
出力を設定する数値に
極端に大きなものを設定するとエラー落ちするため、
ものすごくデリケートなモーターだった。

ロボット開発のシミュレーションをする場合なら
複数のギアを間に噛まして最終的な出力を上げるのだろうが
ギミックを楽しむソフトでそんなややこしいことはやってられない。

丸２日ほど悩んだものの、結局モーター機能を使うのを諦め、
物体の角速度（回る速さ）を設定する処理で
どんな大きな物体であっても設定した速さで回転するようにした。
内部的には物理エンジンのモーター機能は使っていないが
ユーザーがイメージしやすいよう、「モーター」と呼ぶことにした。

モーターが完成すると俄然、ギミック作りが面白くなった。
今後まだまだいろんな機能を追加していきたいが、
単純な形の物体にジョイントとモーターが加わるだけで
利用の仕方にかなり応用が効くことになった。

そして先日公開した「あそぶつり」紹介の動画。



長きに渡って書いてきたあそぶつりの経緯だが、
それを踏まえて観てもらうと
様々な機能が試行錯誤の上に出来上がっていることがわかると思う。

次でまとめ。つづく。

新作「あそぶつり」の経緯　その８

あそぶつり開発は今まで作ったソフトの中で
一番大変だったように思う。

最初にフリーで使える物理エンジンとして何を使おうか悩んだが、
「PhysX（フィジックス）」は開発者だけでなく
そのソフトをプレイする人のパソコンにも
新たなファイルをインストールしてもらわないといけないため
最終的にフリーソフトとして配布するのが目的の私には
どうにも合わなかった。

ただでさえDirectXがインストールされていないとダメなのに
そういった要インストールファイルが増えて
「手軽に遊ぶ」という路線から外れるのが嫌だった。

そこで「ODE」を使うことに決めた。
これはゲームの実行ファイルと同じフォルダに
dllファイルが入っているだけで動作するため、
ユーザーにとっては別のサイトから何かをダウンロードして
インスートルするような手間がいらないからだ。

さて、ODEを使うことが決まってから大変だったのは
圧倒的な情報不足。
ODE物理エンジンの資料がとにかく限られているのと
仕様を理解しても思い通りの結果にならない部分。
必要な処理をどうやったら実現できるのか
情報集めと試行錯誤の連続だった。

その都度、いろいろな処理をネットで検索したが、
物理エンジンを利用した者として非常に有益な情報が多く、
一番お世話になったサイトと言えるのがbambooflow @Wikiだ。

関数資料として綺麗にまとまっていて
関数の仕様を知りたいときにWiki内検索して
書式と利用法を学ぶのに大いに役立った。
ODEを勉強したい人はブックマークしておくことを強くオススメする。

もうひとつ重宝したのが
「簡単！実践！ロボットシミュレーション」の書籍。

後半はほとんどロボットに関する内容なので不要だったが、
前半部分は関数資料として活用したり、
知らなかった機能に気づくことができた。
前述のWikiの方が広く調べる場合は役立つが、
そこで踏み込めていない部分まで載っている情報があった。

物理エンジンを扱えるようになると
誰しも考えることが同じなのか、
２００８年中に似たようなブラウザソフトを
ちょくちょく見かける機会があった。

それと同じことしかできないなら存在意義はないので
クライアントソフトということでの描画処理の速さ・滑らかさ、
日本人ユーザーへのとっつきやすさ、
グラフィックソフトのような多機能系ソフトの複雑さは排除して
なるべく手軽さを大切にしたポジションなどで
勝負できればいいな、と思う。

あとはユーザーによる自作ステージがどこまで生まれるかが心配だが、
ソフトの使いやすさに関しては全力を注いだつもりだ。

ソフト名称は「ピタゴラスイッチ」をもじって
「アルキメデスイッチ」とかにしてもよかったのだが、
語呂も悪いので「遊ぶ＋物理」で「あそぶつり」になった。
カッコつけて英語にしたりするよりも親しみやすいだろうし。

処理が複雑なだけにまだ不具合が眠っている可能性があるが、
毎年１本はソフトを作る、という自分の目標が達成できて
ちょっとホッとできた。

おわり。