洗練されたゲームプレイヤーの動きは美しい

 ゲームプレイというのはある種の最適化問題だから、最初は様々な行動を試していたプレイヤーも、慣れてくると自然にパターン化されたいくつかの動きに収束していく。

 そのとき、ゲームに「飽き」が生じ始める。

 パターン化されたゲームはつまらない。それはゲームではなく作業である。プレイヤーは選択肢と、結果に対する適度なランダム性を欲している。それに応えられないゲームはクソゲーだ。

 だが、本当にそうだろうか?

 

 この問題に対する反例として、僕は「NiGHTS into dreams...」を紹介したい。

 NiGHTSは空を飛ぶキャラクターを操作し、空中に浮いたリングをくぐるゲームだ。こう説明すると簡単なように思えるが、敏感なアナログスティックによる操作で、正確な方向動かすのはなかなか難しい。このゲームのポイントは、1秒以内に連続してリングをくぐると得点がアップするということだ。

 

 リングをくぐると楽器のような効果音が鳴る。続けていくつものリングをくぐっていくと、効果音の音程が変化し、まるで音楽を奏でるかのように音がつながっていく。このため、NiGHTSでは「ハイスコアを目指す」ということと「美しく飛ぶ」ということが、まさしく直結しているかのように感じられる。

 リングの配置はあらかじめ決まっており、その配置もほぼ一本道なので、そこには選択もランダム性もほとんどない。にもかかわらず、プレイヤーが飽きなくゲームを遊び続けられるのは、この「美しく飛ぶ」というある種の演技に官能性を感じている、という部分が大きい。

 

 スコア、演出、ゲームデザインといったあらゆる要素が一体となって、プレイヤーに美しい演技を強いている。このとき、僕は感じる。たとえこのゲームに、究極的には一つの最適解が存在するとしても、その最適解を演じる者に僕はなりたい。

 パターン化されたゲームが面白くない、と感じるのなら、もしかすると、そのゲームには美しさが足りないのかもしれない。

いろいろ引っ張って更新したい

数ヶ月前から、メールクライアントとしてSparrowを使っている。Sparrowのメール一覧画面の一番上で、さらにスクロールしようとすると、循環する矢印のアイコンが現れる。このとき、サーバとの通信が行われ、新しいメールがあれば一覧が更新される。

この挙動がどういう起原から生まれたのかはよく分からない。だが、気付けばTwitterFacebookGmailのアプリも、こぞってこのUIを採用している。ただし、iPhoneはともかく、Macのトラックパッド上でこの操作ができるのは、自分の知る限りではSparrowしかない。どうしてFirefoxYoruFukurouでは、この操作ができないんだろうか? Sparrowのこの操作方法は、どうしてこうも自然で、他のソフトでもやりたくなってしまうのだろうか?

思うに、スクロールの終端で再読込するという動作は、「タイムラインのその先をさらに表示したい」というユーザの意図を汲み取っているから、そういう操作になったのだと思う。新しい情報ほど上に並ぶわけだから、更新するときはさらにその上、というのは直感として分かりやすい。

一方で、SafariFirefoxのようなブラウザでは、新しい情報は必ずしも上に来るわけではない。それに、ブラウジングにおいては更新はそれほど多用する操作とはいえない。ウェブページの多くが上下にスクロールすることを前提に作られている以上、これは無駄なトラフィックを有無原因にもなりかねない。

逆に、今使っているのがTwitterクライアントなら、引っ張ったときにその先の情報を表示しようと努力するのが自然なのではないだろうか。Twitterに限らず、時系列データを扱う非同期アプリケーションなら、こうなるのが自然なように思われる。

というわけで、YoruFukurouには「引っ張って更新」機能をぜひ付けて頂きたいのです。よろしくおねがいします。

無機質と有機質の対立「EDGE」

今日はiPhone向けのアクションゲーム「EDGE」を紹介したい。PC版も出ているが、たぶんタッチパネルで遊んだ方が楽しい。

画面をタッチして指をスライドさせると、その方向へ向かって立方体が転がる。立方体は一段だけなら壁をよじ登ることができる。ゴール地点に到達すればクリアだが、色の付いたキューブを回収し、より早くゴールへ着けば高いランクが得られる。

指を少しだけスライドさせると、立方体が辺(edge)で立った状態を作ることができる。edgeは移動する足場などに吸い付くので、これを利用して離れた場所まで移動したり、落下を回避したりできるのが、このゲームの味噌だ。

ゲーム画面を一見すると、無機質でクールな印象を受ける。けれども、実際にプレイすると、まったく逆の感触を得るだろう。立方体がパタパタと転がる様や、edgeでバランスを取ろうとする際の操作感はアナログ的で、ほんのちょっとした操作の迷いがミスに繋がる。なんどもリトライを繰り返して感覚を掴む、古典的なアクションゲームの楽しさがある。

f:id:yosuke-m:20120427014928p:plain

ゴールに到達した立方体はなめらかな曲線状に変化して、空高くのびてゆく。立方体は接地するたびにデジタルに整列されるけれど、edgeで立っている間だけは、アナログ状態を作り出すことができる。アナログになりたい立方体、というストーリーが、このゲームにちょっとした彩りを添えている。

公式サイト / AppStore

スワイプはタッチに勝るのか、Clearを触った

 最近話題の「Clear」で遊んでみた。知らないひとのために簡単に説明すると、Clearとは、シンプルで心地よいUIを積んだTODOリストアプリである。お値段たったの85円。

 Clearの設計思想については、WIRED.jp 一夜にして世界中を席巻したiPhoneアプリ「Clear」の裏側 で明確に語られている。端的にまとめるなら、「タッチスクリーンとボタンUIは相性が悪い」ということだ。

 僕はボタンに対してここまで批判的にはなれないけれど、たしかに、タッチスクリーンのボタンは、リアルなボタンに比べて操作性が悪い。ボタンに触れたかどうかは、ディスプレイを通してしか分からないからだ。だから、フリック入力でブラインドタッチをすることは難しい。

 iPhoneで古典的なゲームを遊んでいるとき、十字ボタンがいつの間にか指の位置からずれていることがよくある。人間の目は常にボタンを見ているわけではないし、画面はしばしば指で隠れる。そんなとき、インタラクションに大きな断絶ができてしまう。

 Clearでは、主要な操作はスワイプだけでできる。Clearを見ていると、この作者は本当にスワイプが大好きなんだなあと思う。慣性のついたスワイプには、不思議な心地よさがあって、これを発明したからiPhoneはこんなに普及したのではないかと思われるくらいだ。スワイプでユーザがフィードバックを見失うことは少ない。画面内の大きな領域が指と一緒にスクロールするからだ。フィードバックの分かりやすさからいえば、スワイプはボタンよりすぐれている。

 でも、多くの人は気付いていると思うけれど、全てのボタンがスワイプで置き換えられるわけではない。例えば状態遷移を伴うアプリ。上下、または左右にのみスワイプできるアプリはよく見るけれど、3つ以上の遷移を表現したかったらどうしたらいいんだろう? UIのレベルの全く異なる階層に移動するときは? モードレスUIは万能ではない。

 それに、Clearは少しズルをしている。スワイプで動作が完了したとき、小気味よい効果音を鳴らしている。音を鳴らしてもいいのなら、ボタンだって結構楽しいよ。だけど、外出先、電車の中とかで音を鳴らすわけにはいかないだろう。Clearはそこをデザインとして割り切っているから、ああいう戦略が取れるだけだ。

 だから、ClearのUIが楽しいのは認めるけれど、それがスタンダードになることはないだろうな、という当たり前の結論に至った。結局、ボタンがうまく行っていないのは、視線誘導の問題に過ぎないのではないか。

UngearsとズーミングUI

 GGJの他の会場で、なんか面白そうなもん作ってねーかなと思って探していたら見つけた。

 Ungearsは歯車をモチーフにしたゲームである。

 プレイヤーが歯車を回転させると、それに伴って、他の歯車も比例して回転する。アンギアーというアクションを使うと、歯車を落下させることができる。これによって、歯車を目的の場所にはめ込んでいくことが、このゲームのクリア条件だ。

 アンギアーする前は、画面の上半分は見えなくなっている。したがって、歯車の落下地点を予測するには、その回転速度から推測するしかない。推測がぴたりとハマったときの快感が、このゲームの醍醐味である。

 全編を通して、フラクタルをモチーフにしたデザインが徹底されているのも、このゲームの特徴だ。一つステージをクリアするごとに、画面は一つの歯車の中に吸い込まれ、そこがまた新たなステージとなる。

 このUIを見ていると、僕はズーミングUIを思い出す。ZUIを意識して作られた実用的なソフトウェアは未だ少ないが、「ズーム」というアニメーションがもたらす快感、無限に奥へと進んでいくことによる全能感といったものは、たしかに存在するように思われる。ステージをクリアした時の達成感が、このアニメーションで一気に満たされる。

 このゲームでは、アンギアーする際に、カメラが一歩引いて全体を映すようになるのも興味深い。アンギアーは落下のシミュレーションをするためのアクションで、プレイヤーはそこで始めて高次の視点を意識できる。アクションの意味と、アニメーションとの一体感が、操作の感能性に大きく貢献している。

snakencircle制作の記録

 

f:id:yosuke-m:20120201140405p:plain

 1月28日、僕は福岡工業大学短期大学部を訪れた。Global Game Jam、通称GGJに参加するためだ。

 Global Game Jamとは、寄せ集めのチームが2日かけてゲームを作るイベントである。1月末に世界中で同時に開催されている。

 30分ほど遅刻して教室にはいると、そこでは、100人以上の開発者たちが、ゲームデザインに関する講義に耳を傾けていた。

 福岡会場の主催である金子さんから、名札が配られた。名札の裏にはばらばらに切られたゲームタイトルの画像が差し込まれている。これがぴったりとそろう相手が、今回一緒にゲームを作る仲間になる、という趣向らしい。

 僕の名札に入っていたのは、ラブプラスの高峰愛花だった(これが金子さんの趣味か……!)他に、3人の人々がラブプラスの画像をもっていた。本来のチームの人数6人に対して、4人しか揃っていないということで、チーム名はラブマイナスに決定した。

・ゲームの核を決める

 4人で会議が始まった。一般的にはブレインストーミングからアイディアを出したりするのだろうが、僕たちは特に形式を決めずに話し合いを始めた。

 今回のGGJのテーマはこれだ。

 

f:id:yosuke-m:20120201120406p:plain

 

「輪廻転生とか、そういうあれですよね」
「ウロボロス」
「無限ループ」

 キーワードをいくつか紙に書き出してみる。お互いにどんなジャンルが作ってみたいのか、意見を交換し合う。アクション、パズル、ボードゲームといった案が上がる。

 と、ここで一つ問題が発覚した。うちのチームは、プログラマーが二人、グラフィッカーが一人、両者の掛け持ちが一人で、サウンドの担当者がいないのだ。

「これは、サウンドがいないという前提で進めたほうがいいかもしれませんね」

 サウンドがなくても成り立つゲームとしては、ボードゲームがある。そこで、僕が直前に出していた「蛇を操作して輪を作り、その中を陣地とする対戦型ゲーム」というアイディアを元に、ボードゲームを考えてみることにした。

「六角形がいいと思う」
 リーダーの出した案はこうだった。プレイヤーは順番に六角形のパネルを並べていく。パネルには蛇の絵が描かれている。それを繋げて、陣地を作る。

「どこが誰の陣地かを、どうやって見た目で示すかが問題ですよね」
「真ん中を取ったら勝ちというのはどうでしょうか?」

 次に出た案はこうだ。ボードの端から蛇が伸びてゆく。ただし、2つのパネルと隣接する場所にしか、自分のパネルは置けない。相手を妨害しながら、最短ルートで中心を目指す。

「これって先手必勝なんじゃないですか?」
「妨害が発生しないことがありえますよね」

 ボードゲーム案はうまくまとまらない。結局、原点に立ち返って、陣取りをデジタルゲームとして作ることになった。

 ここまで、およそ2時間。他のチームより早くまとまったものの、残り26時間で形にしないといけないと考えると、悠長にしている時間はなかった。

・ゲームデザインの細部を決める

 プログラマー間で、ゲームのアイディアをどう実現するか、会議することにした。

「蛇の通った軌跡をパスとして保存して、それを元に、マップチップを塗り替えます」
「それって難しくない?」
 リーダーが口を挟んだ。たしかに、任意のパスを塗りつぶすアルゴリズムは、ちょっと考えたくらいでは思いつかない。
「へびの曲がり方を一定にして、曲がり始めたら必ず円を描くようにしたほうが、簡単に面積を計算できるんじゃない?」

 たしかに、計算はそちらのほうが簡単だ。しかし、このゲームの醍醐味は、より多くの陣地をとろうとすればするほど、敵に妨害されるリスクが高まるという点にある。曲がり方を一定にしてしまうと、それが成り立たなくなる。だが、下手にリスキーなことをして、締め切りに間に合わなくなるのは避けたい。

 僕が口をつぐんだそのとき、もう一人のプログラマーが手を挙げた。
「やりましょう!」
 その勢いに押されて、僕も乗った。
「やりましょう!」
 そうして、リーダーは懐柔されたのだった。

 ちょうどよい時間だったので、お昼を食べるためCoCo壱番屋へと入った。

「操作どうします?」
 僕は聞いた。
「マウスでの操作をイメージしてました」
 と、もう一人のプログラマーは言った。しかし、現実的に考えて、マウスポインタの位置を複数取得する方法はない。ネットワーク対戦を組み込む余裕もない。ジョイパッドを使うのが無難だった。

「スティックで操作するなら、ウエライドでいうところの、赤いマシンでいくか、青いマシンでいくか」
「僕はいつも赤いほうでやってたから青いほうをよくしらない」
「みんなに遊んでもらってから決めたら?」

 CoCo壱のカレーは辛かった。

 帰り道、同じ大学からきていた参加者に会った。彼は、サウンドとして、別のチームに所属していた。今うちのチームサウンドがいないんだよねー、と言ってみたら、彼がサウンドを提供してくれることになった。多謝。

・実装

 部屋に戻ってから、プラットフォームをどうするかという話になった。GGJで3Dゲームを作る場合、Unityの利用が大半を占めるが、2Dについてはこれという選択肢がない。最初は、JavaScriptの使用を検討したが、ジョイパッドの入力を取得するのが難しいという話になり、結局XNAで作ることになった。Subversionの設定や、XNAのインストールをしていたら3時間ほどかかってしまった。

 その間に、チームメンバーが3人増えた。そして、誰もがグラフィッカーだった。後から知った話だが、金子さんは、このチームはゲームと言うよりアプリを開発するんじゃないか、という目論見だったらしい。

 グラフィック斑は、蛇が陣地を奪い合うというよくわからないシチュエーションに困惑していた。たしかに、設定から考えると、今回のようなゲームデザインにはなりにくいだろう。彼らが最初の企画に参加していれば、ゲーム内容はまた違ったものになっただろう。そんなことを考えながら、とりあえず、グラフィック斑には設定を後付けで考えてもらうことにした。加えて、デザインの方向性を指示するコンセプトアートもお願いした。

 一方、プログラマー斑は分業に悩んでいた。僕たちのチームには学生しかおらず、集団開発の経験がほぼなかった。結局、パスとマップチップのシステムはもう一人のプログラマーが組み、そのほかは自分が作ることになったが、この時点でちゃんと設計を固めていれば、もう少しきれいなコードが書けたのかもしれない。

 僕はGUIプログラマーとして、まず、へびが徐々に伸びていく仕組みを作らなければならなかった。そのためには、パーツごとに分割可能なデザインの蛇を用意してもらう必要があった。そのあたりの旨を固めて、デザイナーに伝えた。

 実は僕も彼も、C#による開発の経験はほとんどなかった。リファレンスを眺めながら、なんとかして蛇の操作を作った。その後、ウエライドの赤がいいねという話になり、操作系を作り変えた。この時点で、夕方の8時くらいだっただろうか。

 その直後から、続々と部品が仕上がり始めた。蛇のグラフィックができ、タイトル画面ができ、背景の草むらができた。さらに、パスのシステムが組み込まれた。このシステムが、蛇の交差を検出し、互いの体を切断し合う。BGMもついた。

 しかし、この時点で、一つの問題が浮上してきていた。グラフィックの仕事が少なく、やることがないという声が上がりはじめたのである。しかし、このゲームではもともと必要になる素材はそれほど多くない。プログラマーはかつかつで、他人の仕事に気を配るほどの余裕はなかった。

 今回一番苦戦したのは、やはり塗りつぶしの実装だった。当初、僕たちはパスを徐々に内側にしぼませていくようなアルゴリズムの使用を検討していた。しかし、これはうまくいかなかった。原因は不明だが、まったく意に介さない挙動を示すばかりだった。

 発想を変えることにしたのは、深夜3時を過ぎたころだった。まず、パスをドットの2次元配列に変換し、その、外側を塗りつぶす。外を塗りつぶすということは、すなわち、内側以外を塗りつぶすということだ。後から反転してやれば、内側が出る。外側を確実に塗りつぶすために、マップの上下左右に1pxずつ、プレイヤーの進入できない余白を設ける。そこから塗りつぶしを開始すれば、確実に外側を塗りつぶせる。発想はシンプルだが、深夜の朦朧とした頭ではなかなか出てこなかった。

 実装が終了して、うまく動くことを確認すると、僕たちは床で寝た。ゲームシステムはほとんどできていた。

・最後の日

 朝の時点で、未実装の要素は限られていた。得点の表示と、勝利画面である。その部分の素材をグラフィッカーに依頼し、僕たちはデバッグを始めることにした。

 しかし、これはデバッグにならなかった。やばい。このゲーム面白い。自画自賛しながら何試合も遊んでいた。バグも見つけたが、些細なものばかりだった。

 午前11時ごろには、得点表示も勝利画面も実装が終わっていた。マップ塗りつぶしのバグも直した。最終プレゼンまであと4時間もあった。僕たちは、遊びながら気になる点を改善していった。Ready Goの表示や、虹色のマス(取ると自分のスピードがあがったり、他のプレイヤーの速度が下がったりする)の機能がついたのは、このときである。

・まとめ

f:id:yosuke-m:20120201140337p:plain
※本当は4人対戦までできます

 また、今回制作したゲーム「snakencircle」は、福岡会場のオーディエンスアワードを受賞した。グラフィッカーの方々にうまく仕事を回せなかった等の問題はあったものの、結果としていいゲームができたことは誇っていいと思う。

 GGJの期間中は、まるで2~3時間が普段の一日に相当するかのような、非常に濃密で、かつスピード感のある時間を経験できた。大変楽しかった。

 

追記:GlobalGameJamのサイトからsnakencircleがダウンロードできるようになった。コントローラをたくさんもってないと遊べないけどな!

BigManで遊んだ

f:id:yosuke-m:20120201141036p:plain id:nyaocatさんが公開していたゲーム「BigMan」と「Dangerous World」で遊んだ。どちらもなかなかクオリティが高く、楽しませてもらったのだけど、どちらがより面白いのかと聞かれれば「BigMan」だ。「Dangerous World」の方が明らかに手間暇かかっているので、こういう感想をはっきりと述べるのは多少心苦しいのだけれど。

 

BigMan」は巨人を操作して、迫り来る兵士や爆撃機をひたすら倒していくというゲームだ。敵は無限に出てくるので、必ず巨人は最後に倒れる。グラフィックと音楽が、そんな儚さを強調する。

普通にプレイした場合、巨人はおおよそ6日6晩で死に至るようだ。しかし、兵士から城を守った巨人がここで死に至り、人々の記憶、あるいは記録に残ったという事実はプレイヤーに知らされる。

モティーフからは「ワンダと巨像」の逆をやったという印象を受けるが、プレイ後の余韻はそれとは全く異なる。「BigMan」は「死」にずっと強くフォーカスを合わせているからだ。「BigMan」はそれは現代の先行き不透明な社会の中で、ある種の生きる指針を見いだそうとする若者の姿に強く合致するものがある。

……と、手放しで褒めてみたけれど、もちろんBigManの全てがすぐれているというわけではない。ゲームプレイとしては4つある技のうちのだいたい2つを繰り返し出していればよく、単調さが拭えない。4つの技を生かす場面がそれぞれあり、もう少し考えて技を繰り出すようにすれば、ゲーム性はもっと上がったと思う。

ただ、グラフィックとサウンド、そしてゲームプレイがきちんと一本の軸で結ばれたゲームはなかなかなく、そういう意味で、僕はこの「BigMan」を高く評価する。

最近はインディーズによるゲーム開発もずいぶん洗練されてきており、こういったミニマルでテーマ性の高いゲームが多くリリースされている。そういった作品を今後もこのブログで取り上げていきたい。