開発にもの申す

[Urthr]

パッチ適用によって突然遊び方の変更を余儀なくされてしらけてしまう問題は、レギュレーションを固定する期間を設定する事で軽減できませんか？

例えば、毎年4月から12月はレギュレーションの変更を行わず、その間に課題として上がったものは翌年のレギュレーションとして4月までに告知とテストを完了しておく。

オンラインゲームは消費型のサービスと異なり、複数のプレイヤーに遊び場を提供するインフラとしての側面があります。

一般的な例ではスポーツのシリーズやトーナメントに近く、これらにおいては公平性を重んじるので大会開催中のルール変更、レギュレーション変更は原則として行われません。

今回のパッチで被害を受けてしまったプレイヤーは、高校野球に例えて言うなら、甲子園を目前にして金属バットが禁止され、ホームランで勝ち上がって来た高校が甲子園に行けなくなった、と言うような、プレイヤーも観客もしらけてしまうような事象が起きていたのだと想像します。

長くff11というサービスを提供し続けるために時代に即したレギュレーションの変更は必要だと思いますが、プレイヤーに公平性を提供するという観点から、レギュレーションを固定する期間の設定と、変更する場合は事前にプレイヤー側で準備できるための時間と情報の提供があると良いと思います。

[Liang]

ここ、大事な個所かと。

スレを立てた身としては、ここでの発言は開発側へのエール、
ときどきあちこちのスレッドでみかける「がんばれ！」「しっかりせい！」といった応援、叱咤のひと言でもよいと考えております。

単刀直入に言って認識が甘いと申し上げざるを得ません。
たった一言罵声のような不満が書き込まれるのにも相応の理由、背景、原因があります。
書くならば、そう言った背景も書け、というのには同意できます。
罵声は許さず、擁護や応援だけは許されるのは、同じ金額を払っている顧客の扱いとしては不公平です。
目につくと不快だからと言って、消せばその不満が無くなる訳ではありません。
余計に不満が大きくなるだけというのはスクウェア・エニックスの他のゲームやサービスでも言及し尽くされている事です。

ビッグデータと言いましてツイッターなどのSNS、ソーシャルメディアと呼ばれる媒体から多数の個人の
感想を分析し、それを商品やサービスに役立てるのは現在では当たり前の事になっています。
ただの「※個人の感想です」で済まされる事ばかりではなくなっています。
一般的な企業はどんなひどい意見でも参考に値するものは吟味し、以降の開発に役立てるのが普通です。
何故ならばお金を払う顧客と顧客のニーズがなければ商品の開発もサービスの継続も出来ないからです。
1個人の意見だろうと、書き込むには相応に内容を考える時間、書き込む時間など金銭ではない
コストがかかっています。建設的な意見を書き込むのだってただではないのです。
一般プレイヤーはご存じないでしょうが、こうすればいいなど仕様や問題点を提案する事にしても、
普通は開発内の要件定義、レビューで行われる事であり、場合によっては外部企業に委託するなど
本来金銭的コストがかかるものです。
プレイヤーに議論をさせてトンビが油揚げをさらうようなやり方はどうかと思います。

相当プレイヤー人口が減っていますが、全員がフォーラムで意見を言う訳ではありません。
必ずしも特定の層の意見を代弁しているとは限りませんが、近い意見を持ったプレイヤー達が
フォーラムでの対応に不満を大きく感じた場合、何も言わずに去っていくプレイヤーが多数います。
アドゥリン直後のFF14新生時にサーバの半数ぐらいやめていったのがそういう人々です。
私はダラダラと続けている方ですが、そろそろ見切りを付けようかと考えている層になります。
FF15でも話題になりましたが、プロセス改善、品質意識を重要視し、当たり前のように実践すると
いうのはゲーム業界のみならず、新興・大企業問わず日本のIT関連企業全てに言える事です。
特にスクウェア・エニックスのような業界を代表する企業の一挙手一投足は、同業他社全てが注視しています。
品質管理業務に身を置く者として提言させていただきます。

[Nikkiame]

開発の方々は、当然このスレッドにも目を通していらっしゃると思います。
意見、要望、不満、疑問、すでにさまざま出てきていますが、
こちらへの個別の返信や回答は不要と考えていただければというのが、私の個人的なお願いであります。

理由は、外部的要素を極力なくし、各自が思うままに発言できる自由を確保するためです。
そして、できるだけ良い形でこのスレッドを存続できればという希望からです。
だって、ひとつくらい、ユーザーから一方的に不平不満をぶつけられるスレッドがあってもいいじゃないですか、ねぇ？

また、今、開発側に求められるのは弁明ではなく無言実行でありましょう。
なので、こちらに書き込まれた内容で「これは！」と思えるものがありましたら、
ぜひに取り上げていただきたい。以上です。

[Pamta]

不具合報告とかで挙げるといきなり仕様とかに入れられるものとか
色々ありますけど、仕様と言われればそれまでですが

「仕様そのものがおかしくないですか？」

ってことが多すぎる気がします

まぁ自分が過去に投稿した分だと
上位BC「笑み曲ぐ夢魔と」でフェイス呼んで入ると
フェイスだけ最下層に落ちることがあったこととかなんですけど・・・

あと最近からくり士で１０年くらい放置しててやっと修正入った不具合がなんかあったみたいですけど
そこまで放置してたらもうそういう仕様としてそのままでいい気がします

なんでもかんでも最初開発が設定した状態と異なったら絶対直さないと気が済まないんでしょうか？


洗剤とかで当社比２０％増しとかで勝手に増量されたものに変わるのは嬉しいけど
糖分が想定より多く入ってたから減糖しましたっていう缶コーヒーあったら別商品だと思う・・・

[Iride]

トランキルハートもユーザーからの指摘で把握してる仕様と違ってたと気付かれた様子ですね。
風魔法の効果のときもそうでしたよね？
こんなことが度々あるなかで「これは仕様です」て言われても疑念を持ちます。

大丈夫ですか？

[erio]

トランキルハートもユーザーからの指摘で把握してる仕様と違ってたと気付かれた様子ですね。
風魔法の効果のときもそうでしたよね？
こんなことが度々あるなかで「これは仕様です」て言われても疑念を持ちます。

大丈夫ですか？

フォーラム担当者がポストしたものを仕様を理解している人が正しく表記されているかチェックする仕組みがないんでしょうかねえ？？
チェックしてたらこれ違うよ？って即分かりそうなものですが…。

ゲームの根幹の仕様が本当に分かってる人はフォーラムにノータッチなのでしょうか？
誰がどういう責任において情報管理されているのかちょっと不思議です。

[Liang]

不具合報告とかで挙げるといきなり仕様とかに入れられるものとか
色々ありますけど、仕様と言われればそれまでですが

「仕様そのものがおかしくないですか？」

ユーザー「ちゃんとテストしてるの？」
開発「テストした。問題ない」

の食い違いの大半はここにあると思います。ソフトウェア開発は一般的に

　要件定義　→ 設計 → コーディング(単体テスト含) → 結合テスト →　システムテスト → リリース
※単体テスト：プログラム内の個別機能のテスト
　結合テスト：プログラムの個別機能を統合してからのテスト
　システムテスト：OSやハード環境など変えての全機能のテスト、計画に応じて非機能テストを追加

という形を取ります。要件定義というのは要するにどのようなゲームにするかアイデアを出す工程です。
それに基づいてプログラムでどのように実現するか論理的な設計を行います。
この時点で最終的にどのような動きになるのはかほぼ決定します。
勿論ほぼ机上での計算式上の話になりますから、実際動かしてみないと分からない問題も多々あります。
ですが、↑のようにシステムテストというのは遥かに後の工程になります。つまり後の工程で起こった
問題の修正による手戻りが発生するのは金銭的にも時間的にもかなりのリスクになるのです。
これが一度決めた仕様を簡単に戻したくない要因の一つになります。
また、テストと言うのは機能テスト(仕様通りに実装されているか、想定外の動作をしないか)と
非機能テスト(機能以外のプログラムそのものの性能、セキュリティ、使用感(ユーザビリティ)etc)で
テスト内容が大きく異なります。つまり、

ユーザー「ちゃんと(ゲームバランスやPTジョブ構成やジョブ性能などまで含めて非機能)テスト(も)してるの？」
開発「(全機能テストと6人程度で簡単に行えるプレイまでは)テストした。問題ない」

こういう認識のズレがあるのです。
上流工程で仕様についてシミュレートしてみたり厳密に場合分けしてDPSなど計算していないので、過去に
オーラやブラッディナイオのリゲイン実装して使ってみたら異常に強かったのでやっぱり直します、と
なった事があったと思います。
机上の静的解析で分からない、想像しにくい部分は、非機能テストで行って実際の使用感を見るしかないのです。
また今回の風水魔法の話で言うと、例えば計算順序が少し間違っていた、()をくくる位置が間違っていた、
風水+効果を入れる場所が間違っていた、これらはコーディングでのバグ混入になるわけですが、新しい
装備やアビリティなどで計算式が複雑になると、単体テストやそれ以降のテストで少々値を変えても変化
がない事があります。
境界値分析や同値分割が正しく行えていないと本来テストするべき値を見逃している事もあります。
(計算式が間違っているのに、たまたまテストした値で正しい場合と同じ結果が出る事は良くあります)
過去にもステータスが減衰するエチュードや特定の管楽器で歌った場合のマーチのバグもおそらくこの類でしょう。

スクウェア・エニックスさんはスマートフォンゲームも開発してらっしゃいますから、こういったウォーター
フォール型開発プロセスだけでなく、頻繁な仕様変更や機能追加に対応できるようにアジャイル開発
も取り入れてるのじゃないかと思うのですが、サーバダウンや通信不具合や各オブジェクトの表示には
かなり気を使ってる印象を受ける(そちらの不具合はサービス初期以降あまり出ていない)ものの、
ゲーム内のバトルバランスやジョブのロールの面白さなどに関してはかなり大雑把で、あまり深く追及
されていないように見えます。

フォーラム担当者がポストしたものを仕様を理解している人が正しく表記されているかチェックする仕組みがないんでしょうかねえ？？
チェックしてたらこれ違うよ？って即分かりそうなものですが…。

ゲームの根幹の仕様が本当に分かってる人はフォーラムにノータッチなのでしょうか？
誰がどういう責任において情報管理されているのかちょっと不思議です。

上にも書いたような何段階かの開発工程があり、その中でも担当者が分担して行っていますから
意思疎通が不可欠になるのですが、往々にしておざなりになりがちです。
ソースは更新しても仕様書は更新していない、仕様設計者とコーディング担当者の認識が違う、
担当者が変わって引継ぎが確実に行えていない、任せてあるから他の担当者の事は知らない、
担当者が設計・コーディング・テストでのミスに気付かず、第三者が確認・指摘するレビューを行っていない
IT開発においてよくある話ですｗこういう事が起こらないように構成管理とかコミュニケーション
マネジメントを行うのですが、どうもゲームのプレイ環境そのものには力を割いているが、ゲーム
内の戦闘システムやアイテム・ジョブ・アビリティのプロパティにはややいい加減、という印象を受けます。
昔と違って、ミッションやイベントよりもノートリアスモンスターとの戦闘、装備やアイテム取得が
中心になり、ゲーム内でも重きを置くべき部分が変わってきています。
その辺りも不具合に気付かない、誤認識する原因になっているのではないでしょうか。

[Draupnir]

スミマセン、長いので略。

バージョンアップは毎月事。
その一般的な開発方法を用いた場合に、量にも左右されると思いますが、
それだけの工程を1月以内に終わらせるには1つの工程につき・・・4日ぐらい？
私にはIT業界云々という難しいことはわからないですが、
その一般的な開発法相は日数的に考えても・・・と読んでいて思いました。


今回のバージョンアップをするにあたり、
開発さんから「モンスターとの戦力差が現状と乖離しすぎないバランス」という旨が。
私も勘違いしていましたが、後日の補足が乖離の～発言時にあれば、
ユーザーの受け取り方はまた違ったと思います、日本語は難しいですね。。。

そして、「しっかりと戦えることを確認した」という旨がありましたが、
1回遊んでみればすぐにわかるような不具合が過去に何度かあったと思います。
一度、もぎヴァナでざっくりとでいいので、テストについてお話が聞ければなぁと。

[Liang]

バージョンアップは毎月事。
その一般的な開発方法を用いた場合に、量にも左右されると思いますが、
それだけの工程を1月以内に終わらせるには1つの工程につき・・・4日ぐらい？
私にはIT業界云々という難しいことはわからないですが、
その一般的な開発法相は日数的に考えても・・・と読んでいて思いました。

全てにおいてこの工程にしたがっているとは思いません。
アンバスケードなんかそうですがアドゥリン以降のバトルコンテンツはミーブルバローズと同じコンテンツ生成
システムを使用して作っていると思いますので、コーディングはほぼ行われずスクリプトレベルで
開発可能なもの(モンスターやエリアを選んで適当なパラメータを設定するだけのもの)でしょう。
その分、要件定義＋仕様決定からテストまでの流れは比較的早いと思います。

風水魔法のバグはエルゴンウェポン追加やマジックバーストの仕様変更の2014/6頃入ったものと推察されます。
何故そこで気付かなかったのかというとその頃のプレイヤーの戦術の主流は震天マジックバースト中心ではなかったからです。
またアルヨルで魔命魔攻が大きく上がる装備が実装され、ベガリーで精霊やMBが重視されるようになるのは2015/3頃になります。
そしてお馴染みのメジャーアップデート終了宣言ですね。要するに、潜在的にバグはあったのにそれほど使われていないから
プレイヤーも開発も気付いてなかっただけなのです(これもソフト開発ではよくある話です)。
そして開発終了宣言とほぼ同時のベガリーにおいて風水がいる際のMBが異常に強い事が判明し、アルヨルでの獣強化
も合わせて(先に弱体化されたのは獣の方でしたが)その後のエスカで主流の戦術になっていきます。
その中でも風水が妙に強い事に違和感を感じたユーザーが散々指摘してきたのに、直したのはアキュメンとフェンドだけ(2016/4のこと)。
魔法攻撃のダメージを算出する根幹に作用しているのに、よく吟味しないまま実質2年半余り放置してきた訳ですから、
いくら毎月のアップデートが～開発の負担が～と言われても、こんなSランク不具合をよく放置したまま開発できたなぁと
いうのが正直な感想です。確かに会社の方針もあるし、時期も悪かったとは思いますが。

ですが、テストと言うのは組み合わせがいくらでもあるので全てやろうとすると無限に時間をかける事になります。
それではきりがないので技術的に適切に間引いて尚且つテストの質を落とさないようにする必要がありますが、それが出来ていない。
今回の魔命の話で言えば、CLによって正比例して必要値が増えますから装備や支援ではほぼ固定値で上限も決まって
いるので、ある一定レベルから要求魔命値に追いつこうと思っても追いつけない。
CL???は単純にCL155～CL160と推察される(※あくまで個人的な体感です、数値による根拠はありません)上に、
個別に補正がかけられてる可能性があるので今回のような事態になっていると思われます。
それが「高コンテンツレベルの一部のモンスターの難度が高くなっている」件。
確かに私も色々試行錯誤して震天MB戦術でも勝てない事はない事は確認していますが、難易度という点では
Normalが突然Very Hardになったぐらいの違いは体感できるので、正直「乖離しすぎない・・・？」という印象しかありません。
個人的にも「たかがテストｗ」「テスター風情がなんか言っとるわｗ」「人が作ったものにケチをつけるな！」という自信たっぷりの
プログラマーを見た事がありますので、これに懲りてテストの重要性と品質に意識を向けてもらえれば良いと思います。
FF11に限った話ではありませんし、むしろ手抜き耐震建築のようにミッションクリティカルなシステムじゃなくて
よかったと思います。

[gerotaru]

RMTと不正ツールだけしっかり取り締まって頂ければ十分に思います。
開発さん運営さん、どうかよろしくお願いします。