2017年6月12日月曜日

Screepsゲームレビュー

Screeps とは、 creep と呼ばれるユニットをスクリプトで動かし、資源を集め領地を拡張する非常にマニアックな戦略ゲームです。ブラウザでプレイできますが Steam 版もあります。
ジャンルとしてはMMORTS、日本語で無理に言うと「大規模マルチプレイヤーリアルタイム戦略ゲーム」ということになりましょうか。



特徴的なのは、プレイヤーはスクリプト言語でプログラムを書くことでユニットを制御するという点で、オフラインであってもサーバ上でプログラムが実行され続けます。他のプレイヤーも同じ世界でプレイしており、コーディングスキルの優劣で競争ができます。

日本人のプレイヤーは極めて少なそうなので、ガラにもなくレビューなどを書いてみたいと思います。





チュートリアル


チュートリアルは3人のデベロッパーで作っているにしてはよくできており、それほどプログラミング経験がなくても進めるようになっています。登録も必要ないので、どのような雰囲気のゲームか味わってみたいという人にも気軽に試せるようになっています。

基本的なことは一通りカバーしていますが、本番のゲームになると、チュートリアルとは違い、ルームが複数あり、ほかのプレイヤーからの脅威にもさらされるので、自力でプログラミングに関することを調べたり解決する能力が求められます。


コーディング


プログラムは JavaScript で書きます。ブラウザ組み込みのエディタがあり、シンプルなAIならばブラウザだけでも十分プレイできます。しかしある程度進んでくるとローカルでエディタを使ってコーディングを行い、サーバにアップロードしたり、バージョン管理したりしたくなってきます。これは grunt-screeps を使えば可能です。ローカルでコンパイルすれば、 TypeScript や CoffeeScript といった、 JavaScript にコンパイルされる2次言語も使えます。

実行環境は Node.js 6 であり、 EcmaScript 6 の新しい機能一部が使えます

また、スクリプトの実行時間に上限があり、処理に時間のかかるスクリプトは途中で打ち切られてしまいます。このためアルゴリズムの最適化のインセンティブが働きます。


Creep


Creep は制御するユニットの基本単位です。ボディーパーツの組み合わせによって能力やコストが変わります。資源採取に特化したものや、防衛・攻撃能力を強化したもの、自他を回復するヒーラーなどさまざまな役割があり得ますが、どのようにボディーパーツを割り振って役割を与えるかはすべてプレイヤーにかかっています。


しかし、すべての creep は1500tick(ゲーム内時間、約1時間)すると消滅してしまうので、余分な creep を作るとそれだけ資源を浪費することになり、効率も重要になります。


Room


ゲーム世界は room と呼ばれる小単位に分かれています。今のところ 200x200=40000 個の room がありますが、プレイヤー数が増すにしたがって数は増えていきます。一つの room は一人のプレイヤーが所有でき、 50x50 の square に分かれています。できるだけ多くの room を支配し、邪魔な他プレイヤーを排除し、領域を拡大していくことがゲームの目的となります。


資源


基本となる資源は energy で、 room ごとに1か所か2か所採掘でき、 creep によって採掘と回収を行います。 Energy を使って新しい creep を生産したり、建造物を増やしたり、防衛タワーの補充を行います。

他にもミネラルと呼ばれる種類の資源があります。これにはH,O,L,K,Z,U,Xと種類があり、化合反応によってUH2Oなどの化合物にすると creep へのボーナス効果が付与されるものです。


外交・コミュニティ


他のプレイヤーとはプライベートメッセージや Slack を使ってコミュニケーションが取れます。

外交・同盟システムは組み込まれていないので、個別に交渉する必要がありますし(基本的に英語です)、同盟相手を攻撃しないことはプレイヤーのコーディングで実装する必要があります。

マーケットの仕組みがあり、ミネラルの種類ごとに買い注文・売り注文を出しておくことができ、オフラインでも自動で決済されます。注文の登録も自分で書いたプログラムから自動で行えますので、余ってきた資源は安く売りに出すといった戦略をAIに組み込むことも可能です。

プレイヤーベースはスクリプトを書けなくてはいけないためか子供じみた人は少なく落ち着いています。技術的な討論もされることが多く、他のプレイヤーは基本的に敵であるにも関わらずノウハウの共有には積極的です。



第一印象


最初に連想したのは、カルネージハートというゲームでした。これは電子ブロック風のフローダイアグラムを作ることによって戦闘用ロボットを制御するというゲームで、スクリプト言語を記述するわけではありませんが、ロジックの組み立て方がプレイヤーのスキルとして評価される点が共通していると感じたわけです。

ただ、ラーニングカーブは急勾配のように感じます。チュートリアルを終えた後はワンルームのシミュレータか実戦のサーバでプレイすることになりますが、実戦では初心者向け防護壁が3日ほど守ってくれるだけで、防護壁が崩れた後はベテランプレイヤーが容赦なく攻撃してきます。運が良ければ周囲のプレイヤーと同盟を結んで生き延びられますが、多くの初心者が潰されてリスポーンすることになります。


問題点


しばらくプレイしていると何か物足りない感じがしてきます。


  • ゲーム力学が単純すぎる。基本となる資源が energy のみであり、 energy の潤沢なベテランプレイヤーに対する突破口がない。
  • ミネラルは creep に対するボーナスを可能にするが、複雑なサプライチェインを維持するコストが割に合うかは微妙である。
  • コーディングの多くがパスファインディングであり、戦略を考えるというよりも単調なデバッグ作業になりがちである。
  • 焦点がいかに効率的に energy を集めるかという点にあるので、どのプレイヤーも似たような最適化に落ち着きがちである。
  • Room の地形は固定的であり、移動コストの多い「沼」にまみれた room を選んでしまうと恒久的にペナルティを負う。
  • Power や Nuker といったバランスチェンジャーも徐々に追加されているが、やはり「後付け」感があり、基本国力やプレイ時間の優劣を巻き返せるものではない。



全体的にアルゴリズムよりも持っている資産によって優劣が決まるゲーム性になっており、優れたスクリプトを書くことを目的としたゲームとしてはなんだかもやっとします。



どんなゲームだったらよかったのか


個人的には、せっかくコードを書くことでコンペティションになっているので、もっと独創性を誘発するようなゲームデザインにしてほしかったです。たとえば資源については基本的なものを2種類にして、どちらかが足りないと特定のユニットが作れないようになっていれば、両方をバランスよく採取するための工夫が必要になりますし、敵対プレイヤーに対して不足しているほうの資源の採取を妨害することで、国力に勝る敵に逆転のチャンスが生まれるかもしれません。

現状では強敵への対抗策は攻め込んだ時の状況の変化にAIが適応できないバグに期待する程度のことしかありませんが、敵AIに対するハッキングができたら面白いかもしれません。

ミネラルはアップデートでマーケットにて他のプレイヤーと取引できるようになりましたが、需要と供給のギャップで利益を出すなどといったデザインにはなっていません。これは取引可能範囲が基地からの距離で決まっており、基地は簡単には動かせないので、取引相手がおおむね固定されてしまうことによります。一定間隔に存在するポータルを使えば遠くに資源を運ぶこともできますが、ポータルのつながる先はランダムで一時的なものですし、ポータル自体が中級以上のプレイヤーでないとアクセスは難しい稀少度です。ここらへんは Eve Online の経済システムが新規プレイヤーにもそれなりに活用できる点などと比較するとあまりにもお粗末です。

せっかくAIが取引をするので、もっとダイナミックな取引があってもよいと思うのです。たとえば新興のプレイヤーが株式を発行し、ほかのプレイヤーからスタートアップの資金や資源を得ることができ、成長すれば出資側に高い配当が返されるということになれば、AIには成長株を見極めて出資する先見の明が必要とされますし、現実世界のデイトレーダーのロジックを応用する猛者が出てきたりするかもしれません。株運用だけで資源採掘を全くしないプレイスタイルも可能になるわけで、多様性はさらに増します。



基本的なゲームデザインの話になりますが、開発言語に JavaScript を選んだことについても疑問を感じざるを得ません。 JavaScript は Node.js でも使われているように非同期&イベントドリブンなプログラミングには非常に向いていますが、このゲームのAIというのは実のところそれほどイベントドリブンではありません。

「敵に遭遇した」とか「資源が底をついた」といったイベントに応答する形ならイベントドリブンですが、このゲームでのプログラムはそういった形ではなく、毎 tick (ゲーム内時間の最小単位)呼び出されるコールバックで creep ごとの行動を毎回指示するものです。このためタスク管理・スケジューリングは自前のマネージャを作って管理せざるを得ず、AIにやりたいことをやらせようとすると、ちょっとしたことでもえらく難儀します。

ここで同じリアルタイムストラテジーとしてどうしても思い出してしまうのは Starcraft (初代)のマップエディタに組み込まれていた Trigger というプログラミング環境です。これは「ユニットが特定の位置に入った」などのイベントを引き金(trigger)にして何らかの処理を実行する仕組みで、テキストでのコーディングをしないで済むにもかかわらず、驚くほど多くのことができました。

最大の問題は tick をまたいで情報を引き継ぐにはすべてを JSON にシリアライズしなくてはならないという制約で、 coroutine が使えません。これはサーバ上のゲーム状態の永続化のために必要なことですが、これがあればどれだけコーディングが楽しくなったかを思うと、ゲームデザイン上、優先すべきことだったのではないかと思います。

JavaScript を使う利点としては、


  • 膨大なユーザーベースからプレイヤーを集められる
  • クライアントサイドのみでシミュレーションとチュートリアルができる
  • Web系の仕事をしている人は、仕事上のスキルアップにもつながる
  • サーバーサイドは Node.js で培った技術の応用でスケールアップできる

ということぐらいですが、ゲームである以上、面白さを犠牲にしてまで追求すべき利点ではないと個人的には思います。



総評


率直に言って、あまり楽しくないです。
アイデアは良かったのですが、実装がいまいちな感じです。
これに触発されて、面白く、かつ成長の糧になるゲームがどこかで開発されることを祈っています。


0 件のコメント:

コメントを投稿