リワードがスコアだけとはなんという古めかしいゲームじゃ

昨日ゲームのリスク／リワードのうちリスクの話だけ (http://d.hatena.ne.jp/ABA/20141017#p1)したけど、リワードの話はしなかった。いやしなかったというか、私が最近作ってるミニゲームにおけるリワードは「スコアが入る」以外なにも無いので、しようがなかったというか。

最近のゲームだとそもそもスコアという概念が無いので、別の形でプレイヤーに報いるリワードがあるのが普通だ。アンロックされるキャラクタやステージだったり、プレイヤーを強化できる経験値やカードだったり、あと実績やメダルも。

ゲームそのものは昔ながらの作りでも、これら近代的なリワードを入れることで現代に通用するゲームにすることができる。最近遊んだゲームの中で、これにとても成功しているなあと思ったのは、LUFTRAUSERS。

LUFTRAUSERSはゲーム自体は「これタイムパイロットじゃん」という古典的全方位シューティングなのだが、コンボ中に8つのボートを倒せ！とかいうチャレンジをクリアしていくごとに、自機の武器、機体、エンジンのパーツがいろいろともらえる。死ぬ時に大爆発する機体とか、海面に突っ込んでもダメージが無いエンジンとか、一風変わったパーツをカスタマイズして組み合わせると、ノーマル自機とはかなり違った遊び方ができるようになっている。

ゲーム本体にいろんなチャレンジと、アンロックされるパーツを組み合わせるという作りにすれば、ゲーム本体は昔ながらの古典的な内容でも今風なゲームにすることができるので、みなさんなるべくそういうふうにゲームを作りましょう。

と言ってもこれ作るの面倒なんだよな。適切なチャレンジを設定する、組み合わせて面白いパーツを作りこむ、両方ともそれなりに手間がかかる。あと、チャレンジを閲覧したりパーツをカスタマイズするUIを作るのもおっくうだ。チャレンジが設定できるだけのゲームの幅を持たせるのも難しい。

でも少しは現代風なゲームにしたいと思ったら、プロトタイピングにおいてもこういったアンロックされるなにかも含んだ遊び心地まで確認できることが必要だろうし、ミニゲームにもなんらかのチャンレンジ＆アンロックの仕組みが入っているのが理想なのかもしれん。これらをうまいこと手抜きして作れる方策を考えたいね。

ミニゲームに適切なリスクとリワードにはどんな種類があるかね

ゲームにおけるリスクとリワード、つまりプレイヤーがリスクを取るとリワードが得られるという仕組みは、ゲームの面白さを増すのに重要と言われている。

Risk/reward is a system established by the arcade generation that rewards the player for taking a risk that goes beyond what they are asked to do normally.

'arcade generation'とあるように、リスク／リワードはアーケードゲームによって確立されたものなので、現代のゲームにおいても必須かどうかは分からんが、アーケードライクなミニゲームにおいてはあったほうが望ましい。特にゲーム序盤が簡単で徐々に難しくなるタイプのゲームにおいては、序盤の簡単な時にプレイヤーがリスクを取れるようになってないと、やることが無くなってとても暇なゲームになってしまう。

So the first and most obvious aspect of r/r in Pacman is the blue ghost multiplier. When the player eats a power pellet the four ghosts chasing you become edible for a small amount of time and attempt to avoid you. Eating said ghosts will result in score points and with each ghost eaten after the first that score is multiplied.

The risk here of course is the fact that the ghosts will turn back to normal very quickly, so eating them becomes a race against the clock, if you're too close to one when they become normal you usually die.

代表的なのはパックマンでパワーエサを食べたあとに青点滅しているゴーストをぎりぎりまで食いにいく場面。パワーエサの効力が切れてゴーストが反転して食われるかもがリスク、切れる前に食ってしまえば1600点がリワード。

こういったリスクのバリエーションを色々と揃えておくと、ゲームに彩りを加えるのに役立つ。なので自分で今まで作ったゲームを眺めて、リスクの種類を整理してみたいと思った。自作ゲームだとリワードは「点が入る」くらいしか作ってないので、それはまた別に考えないと。

ボーナスアイテムを取りに行く

例えばこれで使っているボーナスアイテム。

上からくる黄色いボーナスアイテムを取るとボーナススコアが入る。足場がないところにボーナスが現れたりしたら無理して足場を作って取りに行かないといけない。また、アイテムを逃さずに取り続けるとスコアが+100→+200→...→+1000と増えるので、逃さないようにしたほうがお得。バトルガレッガの勲章と似たような感じ。

これとかガレッガ勲章そのもの。

ボーナスアイテムはあらゆるゲームに簡単に導入できる上にリスク／リワードも分かりやすいのでとても便利だが、それ故に安易に頼ってしまいがち。

敵に近づく

パックマンの例は思いっきりこれ。バリエーションとして、敵の近くに長時間いるとスコアが増す、という実現方法もあるよ。

これはミサイルに長い時間追っかけられると点が上がるようにした。

これは敵の背後を長時間取るとボーナス。

うまく使えばゲームにヒリヒリ感を与えるのにとても役立つが、プレイヤーのフラストレーションと表裏一体なので加減が重要。サイヴァリアの、敵弾の真横ギリギリでレバーをぐるぐる回すというとんでもないリスクに、一定時間無敵を与えるというとんでもないリワードを与えるとかが、ある意味理想型。

敵を意図的に増やす

次々に出現する敵をすぐには倒さずに、多数出現させてから倒すとボーナススコアというタイプ。敵が増えることはもちろん危険に直結する。

敵をまとめて誘爆させると高得点、とかがよくある。

「まとめて倒すと高得点！」は昔のアーケードのインストカードに書いてある代表的文句であった。

死に近づく何かを貯める

敵を増やすの類型。

での大きく囲おうとする行為とか、

での数字パネルを積み上げる行為とか。

ゲームスピードを上げる

アクセルを踏み続けるとスコアが入るというチキンレースタイプ。速度が上がると制御が効かなくなって危なくなるのは現実と同じ。

ゲームスピード上昇はゲーム＆ウォッチ時代からの伝統的な難度上昇手段だが、それをプレイヤーに意図的にやらせるという方式。

リスク低減に役立たない何かをする

という分類名が正しいのかよく分からんが、破壊不能な敵弾を撃つなど、やったところで別に自分が安全になるわけではない行為に点をあげること。

有名なジェミニ誘導。

同色の敵のみを撃つ

赤、青、黄色の敵の、同色3つを続けて撃つとボーナス点。

シルバーガンじゃん。

このタイプのリスクは「シルバーガンじゃん」か「斑鳩じゃん」と言われるのがリスク。

とりあえずこんくらいの種類が思いついた。あんまりバリエーションないな。まあ「死に近づく何かを貯める」とかいうのは、それをリスクと言うのだ、というレベルでちょっとざっくりすぎる感じはする。こういったゲーム向けリスク種別をまとめている記事があったら読んでみたいのだが、どっかのゲームデザイン教科書にはあったりするのかしらん。

HTML5ミニゲーム作り向けライブラリMGL.COFFEEを作った

またゲームエンジンを作っているのか、きみは。

前にHaxeでFlashのミニゲームというかプロトタイプを作るためにmgl (https://github.com/abagames/mgl)というゲームエンジンというかライブラリを作っていたが、そのCoffeeScript版を作った。CoffeeScriptのやたら短いコード記述ができるのが好きなので。

作るものがきっちり決まっていれば1時間以内、漠然としたアイデアからでも3時間以内に、いちおうタイトルとスコアと音が付いたゲームが作れる、ということが目標。その分グラフィックスやら音やらは最低限でしょぼいが。

メソッドチェインと短縮記法を使うと、例えば上方向へのスピード0.05、サイズ0.05のパーティクル20個を、以下の短い記述で出せる。

@np
	.w 0, 90
	.s .05
	.sz .05
	.n 20

可読性は最悪である。

ドラムパターンと音色を適当に自動生成するので、とにかく何でも音が付けばいいやという場合は、

Sound.sd 4321
@drums = []
@drums.push G.ns.d().dp() for i in [1..4]
d.pp for d in @drums

でBGMは鳴るし、

Spring.bs = @ns.v(4).d()
Spring.bs.p

で効果音代わりのドラムがクォンタイズされて鳴る。安直である。ランダムシードの4321を適当な値に変えれば出る音はいろいろ変わる。

あとはキャラクタのグラフィックスを自動生成できればさらに手抜きができるのだが、あまりいい方法を思いついてない。ロールシャッハ的な適当な左右対称キャラなら作れそうだが、それだけでは使い勝手は良くなさそう。今はごく少数の四角の組み合わせをキャラにしているが、とりあえずこれでしのぐか。

一週間に一つミニゲームを作り続けるのに役立つひどいゲームをかろうじてましなゲームにする力

最近一週間で一つゲームを作るってのにチャレンジしてるよ、という記事をちょいちょい見かける。

ゲームはアイデアだけでは面白いかどうかわからないので、できる限りすぐに遊べる状態に持っていくのが大切。他の人が遊べるようにすればフィードバックがもらえる。そういった取り組みができるよう、毎週一つゲームを作ってリリースするチャレンジをするのがいいよという話。

推奨することとして、ゲームは良かろうが悪かろうがWebサイトでリリースしてコメントをもらう、一度リリースしたものはもういじらない、毎週全く違うものを作るようにする、作って分かったことを日記に残す、ということが挙げられている。

上の記事を受けて、実際に14週に渡ってゲームを作った人の記事。作ったもの、うまくいったところ、うまくいかなかったところ、学んだことが、各週について書いてある。

HTML5のゲームを8週に渡って作った人の、どうやれば短時間でゲームを作り続けられるかのコツ。とてもゲームと呼べないものでいいからとにかく小さく作れ、作りたいものに応じた適切なフレームワークを選べ、音やグラフィックスを作るツールや素材サイトを見つけろ、アニメーションやエフェクトなどでゲームをジューシーに'jucify'しろ、完成直前に友達や家族にテストプレイしてもらえ、あたりがコツらしい。

私も最近2ヶ月で9個ミニゲーム作った。

一週間に一つとか決めてないので、リリースペースは適当です。あと各ゲームを作って分かったこととか全然まとめてません。そろそろ力尽きそう。

一つ分かったことは、一週間に一つとかいうペースで作るんだと、ある程度作ったところで「これはひどいクソゲーだなあ」ということに気づいても、それをまるごと捨てて別のものを作るのは時間的に難しいということ。なので目の前にあるひどいゲームを、なんとかかろうじて遊ぶことはできる程度にはましなゲームに仕立てる能力があると、とても役に立つ。

一つ例を挙げると、2月に作ったSUM10というゲームとCALC +-*/というゲーム、最初に作った時は一つのゲームだった。SUM10みたいなフィールドに、1〜10の数字と+-*/の四則演算が置いてあって、フィールド上のカーソルが動くとそれら数字と四則演算がCALC +-*/のようにスタックに積み上げられ、ヒューレットパッカードの計算機よろしく逆ポーランド記法で計算され、その数字が10の整数倍になると点が入る、というゲームだった。

作って遊んで分かったのだが、このゲームは死ぬほど難しい。適切な数値と演算を限られたフィールド上から揃えることが不可能に近く、それをリアルタイムにこなすなんて並の人間には無理っぽく、ひどいクソゲーだった。

なので2つのゲームに分けた。片方は最初から数値だけがスタックに積み上げられており、四則演算だけをプレイヤーが入力して目標の数字にするCALC +-*/、もう一つは数字が敷き詰められたフィールド上をカーソルを動かして足した数が10の整数倍になると点が入るSUM10。こうすることで、それぞれのゲームに難しさが分散されて、かろうじて遊べる形になった。

難しすぎる1つのゲームをそこそこ難しい2つのゲームに分けて遊べるようにする、ってのは後段の泥縄処理としてはかなり美味しい話で、そんなにうまいこといくことはまれだ。だけど、それ以外にも、スコアリングルールを変えるとか、敵と自分をひっくり返すとか、操作対象のキャラを変えるとか、キャラの数をやたらと増やすとか、そういったことをすることで、ゲームの備えるギミックはそのままでかろうじて遊べるゲームになることはままある。

短時間でミニゲームを作ってると、そういった最後の悪あがき力も鍛えられるという点は、想定していなかった利点ではある。自作ゲームを味見して、ちょっとしたフレーバーを加えることでゲームの味を調える、土壇場のゲーム調整能力は、ミニゲーム制作にとっては重要なポイントであるかも。

2013年作ったゲーム遊んだゲーム

ちょうど20個なので例年の30個ペースには届いとらん。

その代わりに今年はオレオレゲームエンジンとかDSLとか作った。

ってその代わりとか言えたもんじゃないぞ。「ゲームエンジンを作るなゲームを作れ」を合言葉に邁進しないと、ゲームは永遠に完成しないのだ。

遊んで面白かったゲームは、あんまり遊べてないが、

と思ったら数だけはまあまあ遊んでるな。といってもほとんどコンシューマー機ゲームがなくて、ブラウザ上で遊べるかスチームに置いといてもらわないと面倒で遊ばないという体たらくではある。来年も色々作って色々遊んでいきたい。

ミニゲームのステージを自動生成した時の難易度調整はどうする？

最近はよくて10分遊んでもらえれば上出来みたいなミニゲーム作っているが、それでも数回は繰り返し遊んでもらえるくらいのリプレイアビリティは欲しい。でも面倒な作り込みはしたくない。

と考えた結果、ステージは無限に自動生成、1ステージは10秒くらい、残機無し即死だけどリトライし放題、クリアステージ数はブラウザに保存してコンティニュー可、という作りにしている。ステージをどこまで進められるか、というくらいのリプレイアビリティは得られるといいな、というもくろみ。

自動生成されるステージは面が進むたびに少しずつ難しくならないとハリが無い。かといって単に線形に難しくなっていくとメリハリが無い。それなりの波がありながらも確実に難しくなっていくステージをどうやったら作れるかなあということを考えていて、今のところ下のグラフを使っている。

difficulty graph

横軸はrandom()の0〜1の出目で、縦軸が難度（0が簡単で1が難しい）。ステージ開始前にrandom()を振ってその出目に対応する難度をそのステージの難度として採用する。

このグラフの難度は

Math.pow(random(), 100 / (stage + 1))

で求まっていて、ステージ数が少ないうちは難度の低い下方向に張り付き、ステージ数が進むと上へ膨らむようになっている。なので、先のステージになると、より高い難度が設定されやすくなる、けどたまにrandom()の機嫌によってはそのステージ数にしてはやたら簡単だったり難しくなったりする。

あとステージ全体の難しさが一つの難度で決まるのも楽しくないので、

  • 敵の数
  • 敵が弾を撃つ頻度
  • 弾のスピード

とかのいくつかのパラメタに対してそれぞれrandom()を振って上の式を当てはめた難度を設定する。そうするとあるステージでは敵の数はやたら多いけど弾はあまり撃たないとか、敵は一人しかいないんだけどやたら速い弾をやたら撃つ、とかいうバリエーションが得られる。

後半面になると全てのパラメタが難度1に張り付きがちになるので、全般的に難しい面が連続するようになる。でも難度自体は1が上限なので、単に線形に難度を上げていくよりはリミッタがかかる。

ていう具合にすると、まあ納得できる形で理不尽に難しくなっていくので、そこそこ気に入ってます。最終的には全てのパラメタが難度1に張り付いてカンストするので、無限に難しくなるのは実現できないし、その1に張り付いた難度設定をどの程度にすればいいの、ってところの調整が難しいのが難点。難易度曲線を考えるのは好きなので、またいろいろ考えたい。

ゲームは一日一時間半！

遊ぶ方じゃなくて作る方ね。

31個のゲームを31日で作った人のブログ記事。

They were all made in less than 3 hours (most of them in less than 90 minutes).

ゲームメカニズムに注力して、見た目や音は重視してないとはいえ、ほとんどのゲームを90分以内に作ったというのは偉業だ。

実際90分でゲームを一つ、それもコンスタントに作るってのは、可能なんだろうか。おっさんになると90分くらいでも集中するのが厳しくなるので、例えば90分を3つのパートに分けて考えると、

  • Step1: ゲームの基本ルールを作る（30分）
  • Step2: レベルデザイン、難度設計（30分）
  • Step3: テスト、バランス調整、エフェクト、サウンド（30分）

くらいの配分かなあ。それぞれのステップを具体的に考えてみる。

  • Step1: ゲームの基本ルールを作る（30分）

自機が動くとか、敵が出るとか、ショット撃って敵を倒すとか、そういう基本的な動き、メカニズムを作る。この部分に今までのゲームとちょっと違うギミックが無いと、あまりに平凡なゲームになるので、なにか新しいものを入れたい。となると、30分以内という時間制限はかなり厳しい。

レベルデザインと言っても30分ではまともに作れるわけないので、実際は難度曲線に基づく敵出現パターンの自動生成みたいなアプローチになりがち。適切なレベルを自動生成するってのはそんなに簡単じゃない。となると、30分以内という時間制限はかなり厳しい。

  • Step3: テスト、バランス調整、エフェクト、サウンド（30分）

ここでStep2の実装が適切かのテスト、バランス調整を経た後に、パーティクルとかのエフェクトや効果音などを入れるという多大な作業を一気に行う必要がある。となると、30分以内という時間制限はかなり厳しい。

結論：厳しい。

実際はこれらステップの前に、

  • Step0: 30分でルールが、30分でレベルデザインができるゲームを思いつく（任意分）

ってのがあって、ここがうまくこなせるかというのがキモなのだがそうそう思いつかない。

いや、例えば全方位からくる敵を避けるだけとかいうベタなゲームくらいならすぐ作れるけどね、とか思って、

今コレ作ったら57分かかった。コードはたった123行しか無いのに。やっぱりStep1がどんだけ単純でも、Step2の難度設計とか、Step3のバランス調整とかをちょっとでもやろうとすると、それなりに時間がかかってしまうもんだね。

  • Step1: ゲームの基本ルールを作る（15分）
  • Step2: レベルデザイン、難度設計（30分）
  • Step3: テスト、バランス調整、エフェクト、サウンド（45分）

くらいのバランスで、基本ルールを極めてシンプルにしないと、90分で完成するゲームは難しいのかもしらん。