読みました。
私は、普段は業務アプリを作る人間で、ゲーム開発に携わったことはありません。
ただ、昔からゲームは好きでやっていましたし、今もPS4でゲームをやっています。まあ、ドラクエXはやったことないのですが。
そんな人間が読んだ感想です。
構成（目次）
転載します。
第1章 ドラゴンクエストXとは何か ── ドラゴンクエストかオンラインゲームか
第2章 開発・運営体制 ── ドラゴンクエストXを支える人々
第3章 アーキテクチャ ── クロスプラットフォームMMORPGの基本構成
第4章 開発と検証 ── 並走する追加と保守のサイクル
第6章 ゲームクライアントグラフィックス ── 魅力的な絵を描画する工夫
第7章 ゲームサーバプロセス ── 機能ごとに分離して負荷分散
第8章 キャラクター移動 ── 移動干渉による押し合いへの挑戦
第9章 ゲームDB ── ワールド間の自由移動を実現する一元管理
第10章 ゲーム連動サービス ── ゲーム内とつなげるための工夫と力技
第11章 運営と運用 ── リリースしてからが本番!
第12章 不正行為との闘い ── いたちごっこ覚悟で継続対応
感想（技術者視点）
先述の通り、ドラクエXをプレイしていないので、ゲームの感想について語れません。
ここは、業務アプリを作っている技術者の視点、というところで感想を書いてみます。
言語
やっぱりC++
特に性能が課題となる場合は、やっぱりC++になるんだな、という印象です。
パフォーマンスが課題になる部分や、エンジンになる共通部分は、とにかく作りこむ必要があるのは理解できます。
Lua
私は使ったことないのですが、ゲーム業界ではメジャーだそうです。単体実行可能なスクリプト言語とのことです。
ちょっとググった感じ、C++の関数を呼び出せるらしいので、親和性が高いのだろうと思いました。
また、ゲームの体験（心地よさ）等にかかわる部分は、スクリプトで試行錯誤しながら作るほうが向いているとのことで、そのような部分でLuaを使っているそうです。
試行錯誤が必要な部分は簡単に書けるようにする。これは業務アプリの開発でも必要な考え方な気がします。試行錯誤するたびにいちいちコンパイルしているとイライラしますし。
運用ツール
Visual StudioでC#を使って、運用ツールを作っているそうです。
ここは、開発の手軽さがウリだそうです。GUIをさっと作る、使用環境を限る*1、しかも見た目にこだわらないなら、C#は本当に生産性が良いです。C++のライブラリも呼べますし、良い選択だなと思いました。
オンラインゲームだと、サーバーの設定値を変えるとか、コンテンツの公開時間を決めるとか、その他いろいろな作業が発生するので、運用ツールにも使いやすさと開発生産性が必要そうです。
メモリ
ゲーム開発ではメモリをどうやって節約するか、という戦い？があるとは聞いていました。
この記事で、MOTHER開発時のメモリについて書いてあって、ほー、と思いながら読んでいたものです。
ほぼ日刊イトイ新聞 - あの人の、『MOTHER』の気持ち。
ドラクエXは、複数のプラットフォームでプレイできるので、最もメモリが少ない環境*2に合わせざるを得ず、業務アプリのように湯水のよう*3に使えないと、考慮事項が増えて大変だろうなぁと感じます。
普段の開発でも一応メモリは気にしますが、処理速度や遅延等に課題が出てから考えることが多いです。
クライアントで動作するプログラム等は解析されるのを前提にする
プログラムですが、その気になれば解析が可能です。また、画像や文章等のリソースも、ゲームのバイナリから拾うことが不可能ではないです。
そうなると、解析されることを前提にするのですが、業務アプリならせいぜいプログラムを難読化する程度になります。
ドラクエXの場合、致命的なネタバレを避けるために、そもそもクライアントモジュールの中にネタバレワードが含まれないよう、開発ソース等を定期的にクローリングする仕組みがあるそうです。
ソースの静的監視ツールの、カバレッジ等以外の使われ方、初めて聞きました。ゲームにおいてネタバレは致命的ですもんね。
KHⅢでも、シークレットエンディングは後日配信にするとか聞いているので、ネタバレ配慮は必要なんでしょうね。すぐネットで拡散しますし。
サーバー構成
これは一番勉強になりました。
マルチスレッド、使わないそうです。１プロセス１スレッドにしたうえで、マルチプロセスにして、プロセス間通信にしている、と。
たしかに、マルチスレッドの挙動を理解するのに、人間の頭脳では手に負えない、みたいな記述をよく見ます。実際そうだろうと思います。
でも、それだと負荷分散とか生産性犠牲になるのでは？と思いましたが、それについてもきちんと答えが書かれていました。
私のような素人では思いつきもしないような感じで、複数プロセスを動かしたり、それらを連携させたり、このプロセスが死ぬとゲームが止まる！みたいなプロセスがあったり、という感想です。
この仕組みは、これまでの積み重ね*4や多くの人の知恵が合わさって生まれたものなんだろうな、と思います。
データベース
Oracle Extdataと、キーバリューストアとしてKyoto Tycoonを使用しているとのことです。
RDBは、KVSに比べると全体的に遅いので、やはり極力書き込まないようにしているそうです。とはいえ整合性は必要なので定期的に書いたり、巻き戻りが起こってもよいデータを定義して、そこの障害は（障害を起こさない努力は全力で行いつつ）許容する方針をとっているとのことです。
これは、業務アプリでいうとSLAみたいなもので、しっかりと取り決めが必要な点だと感じました。
設計でもそうで、「この観点で問題ないため、当機能については○○を許容する」みたいなことはよくあります。
私の想像では、RDBとKVSの組み合わせを見ると、CQRS*5かな？と思ってしまいます。つまり、KVS側はキャッシュのような扱いで、パフォーマンス向上のために存在するようなアーキテクチャかと思いました。
ドラクエXでは、KVSのみに保持している情報もあることから、CQRSでの恩恵を享受しつつ、データストアとしても利用する、という方針のようです。
外部アプリは別方式
ドラクエXのゲーム部分は、上記のようなアーキテクチャですが、「目覚めし冒険者の広場」というWebアプリでは全く異なるアーキテクチャになっているそうです。
必要に応じてゲーム部分と連携するものの、データも独自に保持、DBも別、必要に応じてAWSも使う。ゲームとは別物として構築されているみたいです。まあWebだし、と言ってしまえばそれまでですが。
連携する部分を明確にするのは、ドメイン駆動設計を見ているようです。面白いです。
運用面
本書の中で、強く印象に残った言葉は、
リリースしてからが本番
というものです。
オンライン要素が無いなら、今でこそパッチを配布するとかあるものの、基本はしっかり作って終わりです。
でも、コンテンツ継続を考えるなら、追加機能は必要、常に機能改善して満足感を上げる、のような、長く遊んでもらえる仕掛けが必要です。
そう考えると、リリースがスタートラインだよな、と思いました。これは私も肝に銘じる必要があります。作って終わりではないからこそ、柔軟な設計で作れるように、そして、改善し続けられるシステムを作らなければと思います。
感想（ゲームプレイヤー視点）
これはただの感想です。
オンラインゲームはそんなにやらない私ですが、ゲームそのものの仕組みはエンジニアとしても興味があります。
ゲームをやるとき、やりごたえみたいなものを感じるときは、プレイヤーに創意工夫する余地があるときだと思います。
技術を磨けばクリアできる、ちょっと鍛えればクリアできそうというバランスが必要です。そういうのは、たぶんある程度プログラムとしての基盤ができた後、パラメータ調整やステージの内容を変えたりして行う調整していくものだと思います。
アイテムを定義するだけでも、アイテムが持ちうる効果をプログラムで作る。そのあと個々のアイテムの強さを設定。どこで手に入るかを決定。協力だけど手に入る確率を下げる。
こんな感じで多くの工程を踏んで、ゲームはできるんだなと思います。
プログラミングできればゲームは作れる、というわけでもないのが、本当に難しいと思います。
まあ、プログラミングできるのはすごく大事ですけども。やっぱりそれだけじゃないと、改めて認識しました。
おわりに
本書を読んでいて、よく出てくる言葉の中で好きだったのが、
プログラマーの努力で実現した
というものです。
技術的に困難だったり、どうしても実現したい機能があるとき、すごく難しいときにプログラマーがなんとか解決する。そういう積み重ねで面白いゲームや世の中のシステムが存在するのだと感じることができました。
また、ゲームのアーキテクチャについて書かれている本書ですが、この仕組みは一人の天才がすべて作り上げたわけではないのだと、強く感じました。
これまでの積み重ねや努力、新しい技術等、いろいろな要素が組み合わさってできているのだと思います。
そういうものの一端に触れられて、読んでよかったなと思っています。おおげさかもしれないですが、ゲームも人間の英知の結晶だと思います。世の中の技術はすべからくそうですが。
まあ、ゲーム開発に携わっていないSEの感想と思っていただけたら幸いです。個人的には良い勉強になりました。
