--- title: 日本人有志による意見書 2019年1月 tags: Robocraft, 2019Q1 robots: noindex, nofollow lang: ja --- # 日本人有志による意見書 2019年1月 この意見書は日本人プレイヤーの間で一定のコンセンサスが得られている一つの主張についての論考(項番1)、およびいくつかの分析・考察(項番2~11)で構成されています。よって、極めて長文になることを予めお断りしておきます。 本稿の趣旨への賛同を表明した122名の日本人プレイヤーのうち、プレイヤー名の掲載を希望した113名の署名を末尾に添付します。 1. カジュアルなゲームに回帰せよ 2. いかにしてMMRは失敗したか 3. 小隊は現状に資するのか 4. 続・BA2.0に関する考察 5. 通信ラグに関する指摘 6. UIに関する指摘 7. プレイヤーフィードバックに関する指摘 8. デバッグ・サポートデスク体制に関する指摘 9. プレイヤーとの情報共有に関する指摘 10. 初心者に対するサポートの不足 11. ゲームの不安定さに関する指摘 [English Version](https://hackmd.io/s/SJc9zFPQ4) --- ## はじめに ![](https://i.imgur.com/zxHI4xw.png) [original size](https://i.imgur.com/zxHI4xw.png) MMR導入以降の一連のチャレンジは失敗でした。一度として人口が長期の上昇トレンドに転じることはなく、Steam上の平均プレイヤー数はMMR導入から今日までに約7割減少しました。 プレイヤー一人の影響力(≒責任)を強め、AIM力・操縦技能・状況判断といったプレイヤースキルの重要性を高める「e-Sports化」の試みは、システムの不備・人口・プレイヤーの嗜好といった様々な事情が複雑に絡み合った結果にせよ、とにかく、受け入れられなかったということです。 それがハッキリした今、少なくともe-Sports化のために導入された全ての要素は、完全かつ徹底的に清算する必要があるはずです。 他方、ゲーム性以外にも、日本人コミュニティにおいて頻繁に俎上に載る問題がいくつか存在しており、普段言語の壁で隔絶されている日本人コミュニティの認識を共有する観点から、これらを網羅的に取り上げます。 --- ## 1. カジュアルなゲームに回帰せよ InfinityアップデートにおいてMMR(レーティング)が廃止されたことで、我々はFJが「損切り」する覚悟を決めたものと考えていました。なぜなら、レーティングなしに競技性を高めることは不可能だからです。 しかし、なぜかレーティングだけが削除され、それ以外の競技性を高めるために導入された要素・変更がことごとく放置されています。 なぜAIM力への依存が強いままなのですか? なぜスピードブーストがそのままなのですか? なぜ試合参加人数が5vs5のままなのですか? なぜマップが狭いままなのですか? (これは最近のことですが)なぜTTKを短くしたのですか? レーティングが正常に機能する前提のルールのままレーティングだけが削除されたら、状況が悪化するのは火を見るよりも明らかです。 ![](https://i.imgur.com/VPU3Wlw.png) [original size](https://i.imgur.com/VPU3Wlw.png) 我々にはFJがビジョン――Robocraftを誰のためのどんなゲームにしたいのか――を見失っているように思えます。「ガチ勢のための競技性の高いRobocraft」は失敗したのです。このまま座して死を待つつもりでなければ、早急に方針を転換する必要があります。 我々は元に戻すしかないと考えています。 Eliminationしかなかった時代に現在の10倍以上のプレイヤーを擁していた事実は、カジュアルなゲームとしてのポテンシャルの高さを証明しています。今は一手一手が「詰み」に直結する危機的な局面であり、少しでも可能性の高い選択肢があるのなら、それを選ばない手はありません。 当時よりパーツの種類は大幅に増え、グラフィックも向上し、ゲームの安定性も多少はマシになりました。グランドデザインが正しく再定義されさえすれば、Robocraftが往年の輝きを取り戻せると我々は信じています。 [「2014年のRobocraftに戻せという声に応えている」というMarkの発言](https://twitter.com/MarkDJammer/status/1075491757943599106)が本当なのであれば、少なくとも試合参加人数が5vs5のままということはあり得ません。[F=ma](https://twitter.com/MarkDJammer/status/1082741079282253825)や[カウンターピック](https://twitter.com/MarkDJammer/status/1082741723800002561)のような新たなチャレンジは、状況が落ち着いてから着手するべきです。 ### プレイヤースキルの影響度を下げろ MMRの廃止によりマッチングはランダムマッチに戻りました。 ランダムマッチでは同じ試合にあらゆるプレイヤースキルのプレイヤーが放り込まれます。Robocraftではプレイヤースキルに機体の性能差が加わるため、プレイヤー個々の戦力には極めて大きな上下差があります。当然ながら、プレイヤースキルの高いプレイヤーほどゲームへの理解が深く使用する機体も洗練されている傾向にあります。 ランダムマッチを採用しカジュアルなゲームを指向するのであれば、プレイヤースキルの高いプレイヤーも低いプレイヤーも楽しめる仕様でなければなりません。プレイヤースキルの影響が大きい場合、プレイヤースキルの低いプレイヤーは高いプレイヤーに一方的に負け続けることになります。 現時点ではe-Sports化のために導入された要素が残っており、カジュアルなゲームとしてはプレイヤースキルの影響が大きすぎます。 #### 機動性を下げろ 機体の速度が上がれば上がるほど、動きが機敏になればなるほど攻撃を当てるのに高いAIM力が求められるため、プレイヤースキルの影響が大きくなります。 少なくとも青天井で加算される現状のスピードブーストは見直される必要があります。以前存在した収穫逓減は解決法の一つです。MMR実装後に行われたホバーやホイールの速度増加も必要に応じて再調整する必要があるかも知れません。 今後実装が予定されているF=maでは、軽量な機体の挙動を現在より機敏にするのではなく、重量のある機体の挙動を現在より鈍重にするべきです。もちろん、デメリットに見合う調整は加える前提です。 参考までに、スピードブースト実装前の高速な機体の代表例として、BA1.0(8vs8)時代末期に一世を風靡したメガホバテスラの最高速度はOC1で約270mph、OC15で約350mphでした。この時点でforumでは後述する通信ラグに起因する「ラグテスラ」のことが嘆かれていました。 現状では270mphは標準的なホバー機の速度であり、スラテスやプラズマ羽機といった実用に足る最も高速な機体に至っては500mph以上です。(現在は単位がkphですが値は共通です) 恐らく、機動性は相互作用の観点から最も影響力の高いパラメータです。 プレイヤー一人がカバーできる範囲・有効射程や弾速の違いによる武器の相対的な強弱・AIM力への依存度・EMPやMortar等のエリアエフェクトの優位性・DSM等の設置物の有効性・BLMの利用価値・誘導武器の優位性・試合時間に占める各種行動の割合・通信ラグの影響等々、ありとあらゆる要素に影響を与えます。 機動性をスピードブースト実装以前かそれ以下の水準に下げない限り、2016年以前の体験を取り戻すことはまず不可能と思われます。 #### 試合参加人数を増やせ 試合参加人数が少なければ少ないほど総戦力に占めるプレイヤー一人の割合が増加し、少数の強いor弱いプレイヤーが試合の趨勢を決めてしまう事態を引き起こします。少数の極端に強いor弱いプレイヤーが存在する試合はランダムマッチでは日常的に発生します。 また、試合参加人数が少ないと試合中に発生する個別の戦闘に参加するプレイヤーの組み合わせも少なくなり、単調になります。例えば両チームから3人ずつ参加する戦闘が発生した場合、プレイヤーの組み合わせは5vs5では100通り、8vs8では3136通りです。4人ずつの場合は5vs5では25通り、8vs8では4900通りです。 発生する戦闘のパターンが限られている場合、全体として劣勢なチームは局所的な優勢を得ることもできず終始押されっぱなしになります。同じ負け試合でも、一方的になぶられ続けるのと一矢報いる場面があるのとではプレイヤーの感じ方は違ってくるはずです。 試合参加人数が少ないことによる単調さは、プレイヤー同士が連携して様々な戦術を行使することができれば問題ではなくなります。ただし、プレイヤー同士が連携するにはそれぞれのプレイヤーに相応の知識と経験が必要であり、ランダムマッチのカジュアルなゲームにそれを期待することは難しいと言えます。 なお、人口減少のペースを考慮すると、恐らく今が試合参加人数を増やす最後のチャンスです。これ以上プレイヤーが減ると試すことすらできなくなるでしょう。 ソロリーグコンペの経験から、6vs6に増やした程度ではあまり変化を感じられないことも付け加えておきます。 #### マップを広げろ 試合参加人数が多くマップが広いとランダム性の高い局地戦が発生することはBA1.0(8vs8)が証明しています。 局地戦に参加するプレイヤーとその数、また機体の組み合わせのバリーションが豊富だと、局地戦の優劣は全体の優劣との相関が弱くなる傾向にあり、負け試合でも一方的に負け続ける展開にはなりづらくなります。 例え試合参加人数が多くてもマップが狭いと全体として優勢な側が即座に増援を送り込めるため、上記のような効果は期待できません。 なお、機体の速度が上がることは実質的にマップが狭くなることと同義です。 #### TTKを延ばせ 今やプレイヤーが自分で機体をクラフトする対人ゲームは珍しくありませんが、機体の構造をこのディテールで作り込めるゲームは恐らく未だにRobocraftだけです。 TTKが短くなるにつれて、武器やムーブメントの冗長設計、構造によるダメージコントロール等、Robocraftならではの高度なクラフト要素はその効果を発揮する機会を失います。趣向を凝らした造形やカラーリングも、人目に触れる暇もなく蒸発してしまいます。 残念なことに、RoboPassアップデートを境にTTKは今までになく短くなってしまいました。 TTKが長い場合、プレイヤーはただそこに存在しているだけで相手の時間を奪うことができます。これはプレイヤースキルの低いプレイヤーの貢献度を底上げします。 また、今回我々が提案している施策は相互作用の観点から長いTTKを要求します。 速度を下げると試合時間に占める移動時間の比率が増え、マップが広くなるとその傾向が助長されます。特にリスポーン後の移動時間が大幅に延びますが、これを放置して移動時間の比率が大きくなりすぎると戦闘の楽しさが損なわれます。 これを解決するにはリスポーン以外の方法で素早く戦線に復帰する機会を増やす必要がありますが、自動回復を使うにせよナノを使うにせよ戦闘地帯から安全地帯まで撤退できる必要があり、そのためには長いTTKが必須となります。 一方でリスポーン間隔の短いBA2.0ではTTKが長すぎると戦闘が泥沼化しますし、どうバランスを取るかはゲームデザイナーの腕の見せ所と言えるでしょう。 #### カウンターピックの導入には慎重を期すべき 機体の相性はプレイヤースキルの差や機体の能力差を覆すことがありますが、カウンターピックはその機会を奪います。 何度も述べているようにRobocraftでは機体はプレイヤーが作るものであり、機体選択の影響度は予め用意されたキャラクターないし機体を使用するゲームより圧倒的に高くなります。 Robocraftにカウンターピックが導入された場合、最もその恩恵を受けるのは、メタ環境と試合の状況を見極めることができ、多種多様な高性能機体を所持しており、かつそれらをいずれも高いレベルで使用できるプレイヤーです。つまり強いプレイヤーほどより強くなるということです。 ### 多様性こそがRobocraftの楽しさの源泉である ランダムマッチで勝敗はほとんど運任せ(強いプレイヤーが味方になるかどうか&編成が敵に対して有利かどうか)、動きは鈍重で、マップは少なく、サーバも不安定。それでも2016年以前のRobocraftを今より楽しかったと感じるプレイヤーが多いのはなぜでしょうか。 - プレイヤーが一から作成する圧倒的なバリエーションの機体 - 様々な種類の機体が許容されるルール - 大人数のランダムマッチ - しばしば書き換わるパーツの相互バランス これらの相乗効果によって指数関数的に増大した「体験の多彩さ」こそがその源泉だったのではないか、と我々は考えます。 その点では、RoboPassアップデートで跡形もなく消え去ってしまった[「ALL WEAPONS VIABLE (全ての武器に利用価値を与える)」コンセプト](https://web.archive.org/web/20171128170142/https://robocraftgame.com/epic-loot-0-13-1540/)は優れた施策だったように思います。(プラズマだけは一度もうまく行きませんでしたが) 我々は凡百のTPSの劣化コピーなど望んでいません。Robocraftにしかできないことをしてください。 --- ## 2. いかにしてMMRは失敗したか MMRは限定的には機能したものの、全体としては機能不全だったと我々は認識しており、その原因を以下のように分析しています。 - 機体の性能には設計次第で大きな差が生じるため、個々のプレイヤーの戦力は使用する機体次第で大きく変化するが、その変化はレートには反映されないため、レートと戦力は必ずしも一致しない - このことはレートの正確性に根本的な問題があることを示している - 例えば強い機体で高いレートを得たプレイヤーが弱い機体に乗った場合、レートはプレイヤーの戦力より高くなってしまう - マッチメイカーが機体を参照しない - 機体には性能の差だけではなく、果たせる役割にも違いがある - ところがマッチメイカーが機体の性能も役割も一切顧みないため、参加者の機体選択という「運」が勝敗を多く左右するようになった - これによりレートの正確性が下がり、負のスパイラルが完成する - プレイヤー不足 - プレイヤーが少なすぎてレートの近いプレイヤーのみではマッチングを成立させられなかった - 特に高レートにおいて顕著で、高レートのプレイヤーを増やすために低レートでのMMR増加量を上げるという本末転倒な調整が行われる始末だった - こうした無理な対症療法によってシステムの設計が歪なものになりレートの正確性を押し下げた - 2017年3月に行われたソロリーグコンペではコンペ終盤になってもMMRに2000近く差があるプレイヤーが同じ試合に放り込まれる事態に陥った - 試合に参加するプレイヤーの実力にばらつきがある場合、強いプレイヤーの行動によって勝敗が決まりがちになり、弱いプレイヤーのレートが本人の能力とは無関係に上下することでレートの正確性が下がる - これら複合的な要因により、「味方の実力がレートより高いかどうか」「機体編成の相性がよいかどうか」という運に勝敗が左右されることになった - 勝敗を決する主たる要素が運であれば当然レートはプレイヤーの実力を正確に反映しない - 結果的に、精度が低すぎて公平なマッチングを提供するには至らなかった - 辛うじて初心者と熟練者を分離することはできていたが、それが限界だった --- ## 3. 小隊は現状に資するのか 5人小隊が非プレミアムプレイヤーにも開放された2016年10月当時、BA1.0(8vs8)どころかElimination(10vs10)においてさえ、小隊のアンバランスな参加は不公平だという声がありました。 その後2016年12月に小隊同士を優先してマッチさせるシステムが導入されましたが、人口減少に伴い「強い小隊が同時に活動している他の小隊を絶滅させる機能」と成り果て、廃止されました。 小隊で出撃しても大半の試合で相手に小隊が含まれない今、強い小隊が絶滅させるのは誰なのでしょうか。 試合の勝敗は原則として「味方のプレイヤーが強いかどうか」と「機体の組み合わせが有利かどうか」で決まります。小隊はこれらの変数に強く作用するため、勝利を目的とした小隊は極めて強力です。特に現在の5人小隊は1チームをまるごと占有できるため、同格のソロプレイヤーに対してはほぼ無敵です。 人口を増加に転じさせるためには、既存のマジョリティであるソロプレイヤーの流失を防ぐことと、新規プレイヤーの定着が重要です。 小隊機能はこうした現状に資するのでしょうか。前提条件を設けずに検討する必要があるように思います。 |小隊人数上限|試合参加人数|チームにおける構成比| |---|---|---:| |3人|ELI(10vs10)|30%| |3人|BA1.0(8vs8)|37.5%| |5人|ELI(10vs10), BA2.0(10vs10)|50%| |5人|BA1.0(8vs8)|62.5%| |5人|BA2.0(5vs5), TDM(5vs5)|100%| ※2016年10月より前は非プレミアムプレイヤーは小隊人数上限が3人だった --- ## 4. 続・BA2.0(5vs5)に関する考察 2017年8月、私を含む日本人の有志は「BA2.0(5vs5)に否定的な見解を示す文書([日本語版](https://hackmd.io/s/S1A9AXeP-)/[英語版](https://hackmd.io/s/ryNcdMeDb))」を旧フォーラムに投稿しました。 [旧フォーラムをアーカイブ化するという話](https://forums.freejamgames.com/showthread.php?213-Anyone-know-where-all-the-content-on-the-old-forums-went&p=966&viewfull=1#post966)が忘れ去られているため参照できませんが、これには趣旨に同意する八十余名の日本人プレイヤーの署名が添えられていました。 この文書の論旨を一言で表すと、BA2.0(5vs5)は「単調で退屈」というものです。 その後今日までに多くの変化がありましたが、基本的に「単調で退屈」という結論に変わりはありません。ただし、いくつか補足したい点があります。 ### Robocraft World Cupで得られた知見 BA2.0(5vs5)が単調で退屈なのは変数が少ないからに他なりません。少人数で機体のバリエーションに乏しくマップも狭く戦闘はCPの周辺でしか発生しない。 ところが、これに「プレイヤー同士の連携」が加わると話は変わってきます。 日頃から戦術について検討を行っているような強力なチーム同士の試合では、プレイヤーは状況に応じて素早く適切な戦術を選択し、味方と連携してこれを正確に実行する必要があり、BA2.0(5vs5)であっても単調や退屈とはかけ離れた白熱した試合が展開されます。これはRCWC上位チームの試合を見れば一目瞭然です。 問題は、そのような状況は、RCWCのような5人小隊同士のカスタムマッチか、それに準じる状況でなければ発生しないという点です。 同席した野良同士がなんとなく雰囲気で行う連携は、バリエーションの点でも複雑さの点でも遠く及びません。例えレーティングが存在し正常に機能していたとしても、その境地に達することができるのは最上位のほんの一握りだけでしょう。 ### Big Battle Arena BRAWLで得られた知見 2018年2月にBRAWLで行われたBA2.0(10vs10)は興味深い体験でした。 なぜなら、通常のBA2.0(5vs5)との違いが試合参加人数とマップだけであるにも関わらず、プレイ感覚がBA2.0(5vs5)よりもBA1.0(8vs8)やElimination(10vs10)に近かったからです。 そして何より、我々の見聞きした範囲では「楽しかった」という声が多く聞かれました。 ![](https://i.imgur.com/uIIiL1I.png) [original tweet](https://twitter.com/nefilm_rc/status/979291817752461312) 日本人に限らずそう感じたプレイヤーは少なくなかったようです。 - [I didn't expect 10v10 BA to be more popular than 10v10 Elim. - Cluly](https://twitter.com/_ClulY_/status/960147481312014336) 当時BA2.0(5vs5)とBA2.0(10vs10)の差異を分析したメモが残っています。 1. 人が多いので周囲の面子が入れ替わる 1. 飽和状態なのであらゆる場所で戦闘が発生する 1. 戦力差があっても局所的な優劣はその場の人数差次第であり流動的 1. 全員の行動を把握するのは困難なので貢献度の低い特定のプレイヤーへのヘイトが溜まりにくい 1. 編成の振れ幅が大きいので特化機体に運用の余地がある 1. 味方運次第では野良でもガチ小隊を含む相手に勝てることがある 1. タケノコがほぼ確実に割れるので見かけ上大差がつきにくい(※これはマップの特性) 1. 戦っているだけで楽しいので勝敗がそれほど気にならない この時の経験から、BA2.0(5vs5)の単調さや退屈さは、その多くが5vs5という試合参加人数の少なさに端を発するものであり、BA2.0のルール自体との関連性はそれほど高くないのではないか、という知見を得ることができました。 --- ## 5. 通信ラグに関する指摘 前提として以下の点を理解しておく必要があります。 - 処理と通信に起因する遅延により、自分の行動は周囲に遅れて伝わり、周囲の行動は自分に遅れて伝わる - 攻撃の命中は攻撃したプレイヤーのクライアントで判定される - 遅延の量はプレイヤー個々のpingに大きく左右される - 全世界共通のサーバを使用するのであれば少なくとも経路だけで往復500ミリ秒程度の遅延を織り込んでおく必要がある この通信ラグによる描画の遅延は以下のような不条理を引き起こします。 - 離れているor見えない敵のTeslaやShotgunに当たる - 敵の攻撃が障害物を貫通する - 避けたはずの弾に当たる ![](https://i.imgur.com/PaLL605.png) 1. 自分の位置 2. 相手の位置 3. 相手の画面上の自分の位置 4. 通信ラグが大きいほど・機体が高速なほど位置のズレは大きくなる 機体の速度が速ければ速いほど、単発攻撃力の高い武器の攻撃力が高ければ高いほど、この不条理の影響は強くなりプレイヤーに不公平感を与えることになります。 これらは機体速度と武器の単発攻撃力を検討する際に考慮するべき事柄であると認識される必要があるでしょう。 ### 貫通の発生機序 図を交えて説明します。 ![](https://i.imgur.com/NuC6GxK.png) [original size](https://i.imgur.com/NuC6GxK.png) 1. Aが障害物の陰から出る 2. Bは発見から500ms後にAを攻撃する 3. Aは障害物から出て1000ms後に再び障害物の陰に隠れる 遅延が300msの場合にAのタイムラインで(2)と(3)の順序が逆転しているのがいわゆる貫通と呼ばれる現象です。 Bのタイムラインで起きていることは遅延に関わらず一定ですが、Aの画面では遅延が300msの場合のみ障害物に隠れた後にBの攻撃がヒットしたように見えます。このように、遅延が大きいほど貫通が発生しやすくなります。 遅延はサーバ及びAとBそれぞれの処理とネットワークの通過にかかる時間の合計であり、AとBどちらのpingが高くても結果は同じです。 pingの高いプレイヤーは常に遅延が大きくなるため、自分の攻撃が貫通しやすく、かつ敵からの攻撃も貫通しやすいと言えます。 お互いが認識しているかそれに準じる状況のプレイヤー同士の戦闘では、遅延はお互いに等しく影響するため、pingの大小による有利不利はほとんどありません。 ### 奇襲時のアドバンテージ ![](https://i.imgur.com/gOjDDan.png) [original size](https://i.imgur.com/gOjDDan.png) 1. BがAに気付かれずに接近し攻撃する 2. Aは攻撃を受けた400ms後に回避運動を始める 3. Aは回避運動の開始から300ms後にBに反撃する 奇襲が成立する場合、遅延が大きければ大きいほど、奇襲する側のタイムラインにおいて相手が無抵抗な時間が延びます。図の例では奇襲されたAが全く同じ対処をしているにも関わらず、Bのタイムラインにおいて無防備な時間に200msの差が生じています。 前項と同様に、AとBどちらのpingが高くても結果は同じであり、pingの高いプレイヤーは奇襲する場合は有利で、奇襲される場合は不利と言えます。 通常、攻守は常に入れ替わるため、pingの大小による局所的な有利不利はほぼ相殺されます。 ただし例外として、常に高速で移動している等、奇襲を受ける可能性の少ない機体についてはpingが大きいプレイヤーの方が有利です。特に相手が無抵抗な時間を最大限に活用できるDPSの高い武器では顕著です。 --- ## 6. UIに関する指摘 Infinityアップデートで導入されたUIには明確な瑕疵が少なくとも3点存在します。 ### スケーリング Infinityアップデート以降、表示面積に対するUIの比率が常に一定のままスケーリングするようになったため、特に大画面ディスプレイにおいてUIのサイズが過剰になっています。 スマートフォンやタブレット、ラップトップ等、物理的なサイズに強い制約のあるデバイスと異なり、デスクトップでは解像度が高くなるとディスプレイのサイズも大きくなる傾向があるのはUIデザインにおいては常識です。 表示デバイスのバリエーションが増えた現在では、単一の表示形式で全ての環境に完璧に対応するのは不可能に近いでしょう。スケーリングをオプションで任意に選択できる形が最善と思われます。 #### 比較 23.8インチ・フルHD(1920x1080)を100%とした場合のUIのサイズの比率を以下に示します。 ![](https://i.imgur.com/n7FGtrp.png) [original size](https://i.imgur.com/n7FGtrp.png) - サイズ固定(Infinityアップデート以前) - 極端にドットピッチの小さいディスプレイではUIが小さすぎる - 比率固定(Infinityアップデート以降) - 30インチを超えるディスプレイではUIが大きすぎる - 大画面のディスプレイはそのメリットを全く生かせない ### インベントリ 従来のUIではフルHD(1920x1080)で編集画面のインベントリに約100種類のパーツを同時に表示できました。パーツ1個あたり表示面積は今より小さかったものの、24インチフルHD及びそれに準じるドットピッチのディスプレイにおいて小さすぎるということは全くありませんでした。(極端にドットピッチの小さいディスプレイでの視認性の低さはインベントリに限った話ではなく別の問題です) パーツが十分に揃っていない駆け出しのプレイヤーを除けば、インベントリにおける個々のパーツの位置は事実上固定されているに等しく、熟練したプレイヤーであれば使用頻度の高いパーツは探すまでもなく選択することができました。 ![FullHD/before Infinity](https://i.imgur.com/9nm60QY.png) Infinityアップデート以降はあらゆる解像度で1画面につき30種類固定になったことで、多くの場面で選択時にスクロールを要するようになり、目的のパーツに辿り着くまでに必要な手間(操作や視線移動)が格段に増えています。 ![FullHD/after Infinity](https://i.imgur.com/NhlMpgF.png) 現在のインベントリの使用感はクラフトへの集中を阻害する劣悪なものであり、使用には強いストレスを伴います。 ### CRF 従来のCRFではフィルタのインターフェースと検索結果が同時に完全な状態で表示され、かついずれも常に操作可能でした。 ところが新しいCRFではフィルタのインターフェースが分離し、フィルタ条件の変更はフィルタパネルを開いた状態でしか行えず、逆に検索結果の参照と操作はフィルタパネルを閉じていないと行えなくなりました(フィルタパネル表示中の検索結果は暗転している上に一部が隠れています)。更に検索結果に検索条件のインジケータが用意されていないため、フィルタパネルを開かなければ検索条件を確認することができません。これは明らかに改悪です。 [現在のCRFが仮の姿であり、Infinityアップデート以前の形に戻した上で改良する計画](https://steamcommunity.com/games/301520/announcements/detail/1729840463393938236)であることは承知していますが、これまでに何度(※)も約束を反故にされてきたため、敢えて挙げています。可及的速やかに計画が実行されることを望みます。 ※カスタムゲームの多くの要素, クランリーダーボード, レーダー/ジャマー/レシーバーのコスメ等 --- ## 7. プレイヤーフィードバックに関する指摘 プレイヤースキル・ゲームの理解度・趣味嗜好等によって個々の感じ方は異なるため、プレイヤーフィードバックには必ずバイアスがかかります。 そもそも、プレイヤーフィードバックはプレイヤーフィードバックであるが故に、「運営に意見を述べる属性のプレイヤー」という一部の意見に過ぎません。 果たして初心者やカジュアルプレイヤーは積極的に運営に意見を述べるでしょうか。ルールや武器バランスについての詳細な議論ができるでしょうか。 逆のパターンにノイジーマイノリティがありますが、こちらは説明するまでもないでしょう。 属性が極端に異なるプレイヤーのフィードバックは相反する内容になることもあります。例えばフォーラムでいつも元気に囀っている「ドローン死ね死ね合唱団」は、ガチ勢がドローンに見向きもしない時期であっても鳴き止むことはありませんでした。 プレイヤーフィードバックは発言者の属性を考慮し、ゲームのビジョンに照らして優先度の評価と取捨選択を行う必要があります。様々なベクトルを持った意見を場当たり的に採用しても右往左往するだけで前進しません。 プレイヤーフィードバックは参考にすべき情報の一部であって全てにはなり得ません。 --- ## 8. デバッグ・サポートデスク体制に関する指摘 ゲーム開発にバグはつきものですが、その抑制と対策においてFJの取り組みは不十分に感じます。 ### デバッグ不足 以前からアップデートには必ずと言っていいほどバグが含まれていますが、検証するまでもなく一見してバグとわかるものが少なくなく、デバッグ体制に問題があると思われます。 最も顕著な例として[2018年4月5日のReconnectアップデート](https://steamcommunity.com/games/301520/announcements/detail/1675777608240318302)で発生したバグを挙げます。これらのバグは同時に発生しました。(このアップデートはその後ロールバックされました) - Reconnect機能に致命的な不具合 - 全ての試合のチャットが混線 - スラスターのスピードブーストが倍増(他のムーブメントにも疑いあり) - フュージョンシールドの回復・持続ダメージ効果が消失 - 破壊されたローターが機能し続ける - 追加された「T-Rex Cosmetic Mask」を表示するとログイン不能に また、後述するパッチノートの不正確な記述と相まって、プレイヤーが仕様なのかバグなのか判断できないケースも散見されます。 ### サポート人員の数と質の不足 サポートリクエストのIDから逆算すると1週間に150件以上のサポートリクエストが新規に追加されていますが、2019年1月現在、フォーラムMODの言によれば[サポートリクエストへの対応は一人だけで行っている](https://forums.freejamgames.com/showthread.php?1373-Freejam-Support-is-ignoring-us)ようです。 ![](https://i.imgur.com/9o5k6cc.jpg) また、サポートチームのゲームへの理解が浅く、報告の内容がすぐには理解されないケースが見られます。 キャパシティをオーバーしているのか、ワークフローに問題があるからなのか、課題が未解決のまま数ヶ月間放置されることもあります。 - 新しいStrutのCPU対重量比が種類によってバラバラになっているという報告に対し、CPUに基づいていてMassの値は正確だとの返信があり、こちらの追加の質問への回答も曖昧だった - パッチノートに記載されている[スピードブーストの20%削減](https://steamcommunity.com/games/301520/announcements/detail/2521351362636161003)が反映されていないという報告に対し、どのパッチノートに書いてあるのか教えてほしいという返信があった - 十数個のバグをまとめて報告した際に、直後の返信では1個のバグにのみ言及し、残りの対応は2ヶ月空いた後だった ※本項に記述した状況は2019年1月末の時点である程度改善されています(2019年2月5日追記) ### プレイヤーの協力を仰ぐなら最低限の義務を果たせ これらの事情から、ただでさえキャパシティが小さいことに加えて、プレイヤーとサポートチームの間、およびサポートチームと開発チームとの間で余計なやりとりが増えて効率が低下し、本来ならデバッグで判明しているはずのバグに関する報告がそれに追い打ちをかける、という悪循環が起きているように感じます。 [プレイヤーにバグレポートへの協力を促す](https://robocraftgame.com/devblog/infinity-update-out-now/)のであれば、少なくとも、プレイヤーが手間暇かけて行った検証や報告が顧みられることなく放置される状況は改善するべきです。 - デバッグの質を上げる - ゲームの仕様とアップデート内容を把握しているスタッフをサポートチームに加えるか、サポートチームと密に連携できるようにする - サポートリクエストを長期間放置しない - 人員不足なのであれば何らかの形で対策する --- ## 9. プレイヤーとの情報共有に関する指摘 ### 信頼性に欠けるニュース配信 アップデート内容・メンテナンス日時・障害の発生や経過といった情報の素早く正確な周知が重要なことは、ゲームに限らずあらゆるオンラインサービスにおいて共通の常識です。 元々Freejamはプレイヤーとの情報共有に積極的とは言えませんでしたが、2018年11月下旬頃からは特にその傾向が顕著になったように感じます。 現在、Robocraftのニュース配信には主に公式サイト・Steam・Discord・Twitterの四つのチャンネルが利用されていますが、一貫性を持って運用されているとは言いがたい状況です。 以下に例を挙げます。 - 2018年12月21日のメンテナンスは当日に公式Discordサーバでのみ告知されたため、事前に情報を得られなかったプレイヤーの混乱を招きました。機体編集中にサーバがシャットダウンすると保存されていない変更が失われることは周知の通りです。 - AIをBA/TDMの戦闘に参加させる機能が実装されたアップデートでは、当初[リリースノート](https://steamcommunity.com/games/301520/announcements/detail/1729840463423633241)にその旨が記載されていませんでした。「AI-controlled robots will fill empty seats if players are queuing for battle for an extended period of time」の行は後から追記されたものです。 - 究極は[CEOのTwitterでのみ告知されたレーザーとレールの弾速増加の一件](https://twitter.com/MarkDJammer/status/1082916745545953280)です。未だに他のチャンネルでは言及されていません。 ### サイレントアップデートとマスクデータ 上記以外に、事前事後共にアナウンスの行われない完全なサイレントアップデートも複数回行われています。 オンラインゲームではゲームデザインの都合から意図的に変更点のアナウンスを行わないケースがありますが、Robocraftの場合は普段のアナウンスが杜撰なため、意図的に行われているのかただのミスなのか判別できないという問題があります。 仮に意図的にアナウンスを行わないケースがあったとすれば、下記のように問題が山積している状況において、プレイヤーに与える情報を制限することに合理的な理由があるとは思えません。 - 公開非公開を問わず仕様通りに実装されているとは限らない - ゲーム内の表記が正確とは限らない - リリースノートの正確性に問題がある - 頻繁に新しいバグが発生する - 修正されたバグも度々復活する - 開発側のリソースが足りずプレイヤーにフィードバックやバグレポートへの協力を呼びかけている 有り体に言えば、ゲームの完成度がサイレントアップデートを選択肢に加える段階に至っていないということです。 「集弾率」「弾速」「射程」といったマスクデータについても同様で、武器バランスについてプレイヤーから詳細なフィードバックを得たいのであれば、パラメータは極力オープンにするべきです。 それを抜きにしても、クラフトゲームにおいてパーツのパラメータや動作の仕様を隠すことはあまり歓迎されないように思います。 また、別の問題として、マスクデータの解析には多かれ少なかれ検証が必要であり、有利不利に関わるマスクデータの存在はプレイヤー間の格差を拡げる方向に作用します。 ### 日本人のニュース配信チャンネルの利用傾向 本稿の執筆に先立ち、日本人プレイヤーのコミュニティであるRJPW-Discordと[Twitter](https://twitter.com/LEoREo_2247/status/1086161464115621888)において、以下のようなアンケートを日本語で実施しました。 > 「Robocraftの公式ニュースはAとBそれぞれとBそれぞれ以下の2つならどちらの方をよく確認しますか?」 > - A: > 1. 公式Discordサーバー > 2. 公式Twitterアカウント > - B: > 1. 公式サイト > 2. Steamニュース 結果は以下の通りです。 ![](https://imgur.com/XN6wkSb.png) 2019年1月現在、公式Discordサーバのメンバー数と公式Twitterアカウントのフォロワー数には6倍程度の開きがありますので、この結果に驚きはありません。 最近ではアップデート情報などのニュースの配信はSteamがメインになっており、公式サイトへの掲載が遅れる傾向にありますが、少なくとも日本人の間では、Steamより公式サイトの方がよく見られているようです。 --- ## 10. 初心者に対するサポートの不足 クラフト要素を持つゲームの代表ジャンルであるサンドボックスにおいては、プレイ開始直後の右も左も分からない感覚は重要な体験の一つですが、Robocraftは対人ゲームであるが故に、基礎的な学習は素早く終わらせる必要があると考えます。 なぜなら、対人ゲームにおいて習熟度が低いとは「勝てない」ということだからです。勝てない期間があまりに長く続くようでは、ゲーム本来の体験に辿り着く前にプレイヤーのモチベーションが尽きてしまいます。 機体を自分で作成するという時点で、予め用意されたキャラクターや機体を使用するゲームと比べて圧倒的に複雑です。しかも課題解決型のゲームのようにただその機能を果たせばよい訳ではなく、他のプレイヤーの作成した機体との競争に曝されるため、最適化が求められます。CRFで機体を購入するにしても、機体の良し悪しを見極めるには相応の知識が必要です。 設計次第で機体の操作性が大きく変化することも加味すれば、総合的に見て初心者を脱するまでのハードルは非常に高いと言えるでしょう。 にも関わらず、Robocraftの公式な初心者に対するサポートは、戦闘と編集モードの極一部をカバーする不完全なゲーム内チュートリアルしかありません。 復活したTier制についても、現状の低TierはAIだらけで、かつAIの動きが洗練されていないため、他のプレイヤーの機体や動きを見る、対人戦の場数を踏むといった「学習」が以前のようには捗りません。 プレイヤー数が危機的な水準にある今、新規プレイヤーの獲得と定着はなによりも重要な課題のはずです。 なお、YouTuberがチュートリアルの提供を申し出た例(出典:2018年2月2日のRobostream)があるように、FJ内で解決できないのであれば協力するにやぶさかでないというプレイヤーは少なくないはずです。 --- ## 11.ゲームの不安定さに関する指摘 この場で言及する必要を感じないほど頻出の話題ではありますが、未だにサーバやクライアントの不安定さがゲーム体験を毀損する原因として重くのしかかっています。 不安定であるが故に途中抜けのペナルティを重くできず、そのことが安易な途中抜けを誘発する悪循環が何年にも渡って放置されています。 試合を離脱したプレイヤーが自動で降伏投票にNoを投じる(タイムアウトする)仕様を改める、長いスパンで途中抜けの回数をカウントして常習者に警告する等、ネットコードの改善以外にもできることがあるはずです。 --- ## 署名(アルファベット順) 13turn 2yen 3D-Lobster airou1117 akidukikaede AKUSIROYO allbeknow Aluna_jp amatukitune AmatouNuko anni_yuuki Aoi_nasuko Apalis aquostarne Armorplate AuroraPrincess ayaginu Blackpit camaro3510 Cubeeat daiki0911 damegi0424 DANSHAKUIMO DespotsThunderclap detokiko fix0110 Flare105 fromage frozen_merman funny_guy64 ginchan1003 harinertype hennessy hideka hinokapan Hoelderlin hora_man Hosi IAIA IGN000 KageStyles Kamiki_HiyoKo kanabaka Karumaverse KATAYAKI koa0202 kokekoruto konn41 kuma8014pc LEoREo_2247 lightacenoah madscience494 mahiyu majyan.w MIKUSUABENO misosiru misosoup_of_NASU MofuMomi mondou0621 nagachan naito456454545 nakkaryo-n nanashimo nanazaki Nefilm NelBayasi NeoNuc2001 NNMGK_ nobu_chan123 nomiya NORISIO Northfox002 NOVAD omiwatari1.3billion OnigiriAlga orisaEX pcunwa Popusu0730 r_3001 remika remurinsuko robo_713 ryo10987 satori9999 Shimadius shunohara SnowmenSLT Stormbot0922 sugisan885 suzuryu syunto_8810 takemuraryouma takoyakiteraria3 task_tasuku tatari131 Thermite626 tome0702 tomoyoung2 tukudaniorizinaru tukuetoisu ukyakya uribou1031 vcore98 whiteface whiteface097 xXkentixyanXx yamikara yasahu yootako yudaisuraimu yuto4423 zoqsa0409 zuiho_619 --- 著者: Nefilm, LEoREo_2247, omiwatari1.3billion, shunohara 謝辞: cerasus, kimoikoala 英語翻訳: LEoREo_2247, yamikara --- # 変更履歴 - Rev.1 (2019-01-24) - Rev.2 (2019-01-25) - 過去の仕様に関する不正確な記述の削除 - 速度の単位に関する注釈を追記 - TTKに関連したナノと自動回復に対する言及の抽象化 - Rev.3 (2019-01-25) - 機動性の影響に関する記述を補強 - 見出しレベルを調整 - Rev.4 (2019-01-28) - 項番1にSteam同時接続者数グラフを追加 - Rev.5 (2019-02-07) - 「はじめに」を追加 - 項番1の「はじめに」と重複する内容を整理 - 項番5に解説を追加 - 署名を追加