プラグイン集

無料ブログはココログ
2021年11月
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

サンプルJS

  • ユーロバカ一代の締切
    ・・・初期化中・・・

« 著作権の本 | トップページ | 著作権法の本パート2 »

2014年6月 5日 (木)

オンラインゲームを支える技術~壮大なプレイ空間の舞台裏~

「無数の同時接続×ミリ秒のレイテンシをいかにして両立させるか」につられました。ネットワーク関係の本を3冊読んで、総仕上げのつもりでそのうち買おうと思ってて、古本でも高いから手を出さなかったが、高くて仕方ない内容だわ。
ちなみに、図書館にあった。意外に近くにある物なのね。

第0章は、今までのネットワークプログラミングのおさらい。

第1章、歴史。筆者書くこと分からなかったんだな。愚者は己、賢者は歴史の人には悪いが、歴史はカサ増し程度にしか思えない。vi、emacsがなぜそういう操作になったのかの背景なんかわかったところでソフトは完成しない。

第2章、やっとはじまった、オンラインゲームソフトの理論とか概念とか。ソースは書けないが理屈好きにはたまらない内容となっている。

第3章、第2章の掘り下げ、主流のクライアント・サーバーモデルとP2Pモデルが登場し、ネットワーク遅延(レイテンシー)の都合で、同期をとるのは非常に困難だよ。非同期に出来ないか考えてみなさいと、これまた理屈好きには、楽しい内容となっている。

第4章、クライアント・サーバーモデルの代表MMOを題材にゲームの制作と行きたいところだが、大部分をコーディング以外の上流工程の説明に取られている。頭が大容量の理屈好きにはいいが、頭の容量足りないと爆発する。2,3章みたいに止まり木となる部分が少ないし、横断要素が増える。
最後の方で、一瞬コードらしきものが出てくるが、CやJAVAが分からない人を配慮してかコーディングは非常に薄っぺらい内容(無いよう)になっている。
ソフト書くことよりも、よっぽどデータ設計やDBの構築や帯域圧縮がよほど大変と作者は言いたいのだろう。
プログラミング理論の話だと、なぜ、「データ構造とアルゴリズム」というタイトルか。それは、データ構造が決まればアルゴリズムは自ずと決定するからだと散々聞かされたし。
最後に、絵や音は別売となっておりますの免罪符。ただそれだと悔しいのか作図なら上手だと一言追加している。たしかにこの人の作図は上手だ。

第5章、P2PモデルのMO(多人数じゃないけど、複数人オンライン)のゲーム制作。
これは残念な事に、前の章でクライアント・サーバーは、オンラインの中でも真逆のことやるから、頭から順序立てて考えないとダメだよと言うようなことを書いといて、実際の記述は、MMOとの差分。ページ数を減らすのに貢献はしそうだが、ちゃんと書くべきだった。
1章の歴史捨てて、6章として4章と5章の差分(MMOとMOの実装の違い)を書くべきだった。
逆を返せば、4章ごときで止まり木が要るような⑨にレイテンシー要求の大きなP2P MO、全体全通信プログラム実装なんて出来るわけがないと言いたいのだろうか。
じゃぁ、あえて言わせてもらおう、作者はライブラリに依存しないと言いつつ自作”ライブラリ”VCEに依存しているじゃないか。ミドルウエア無いとゲームなんか作れないと言っているようなものだ。事実はそうなんだろう。ログインログアウト実装するだけでもかなり時間かかったし。
5章後半のNAT越え、ここはもっと聞きたいね。6章とからめて独立した章にしていいと思う。

6章、ゲーム本体以外にもこまごまとした周辺ソフト。PCだって、ディスプレイ・キーボード・マウス・LANケーブルなど要るでしょう?そいう言う奴。
まずは、ソフト制作パッケージのおすすめSteamだと課金とかまで含めてかなり便利とか。
マッチングロビーとか、チャットとか、ゲーム本体とは確かに関係性は薄いけど、無いと困るこの辺の実装解説も欲しいね。
そうそう、忘れがちなブラックリストやNGワード集とかの実装もね。ロビーはソーシャルだから、こいつ絶対に嫌って言うの出るし。
とある鯖の直接メッセージで罵詈雑言送りまくってくる姉ちゃんまだプレイしてるのかな?w
アップデート時のアクセス急増のラウンドロビンとかのノウハウも書こうよBitTorrent使うとか、どんだけトレント好きなんですかね?
ランキング、言われてみれば自分の位置±10って取ったことないな。大体TOP50とかだし。

7章、インフラ、プロならデータセンターってお話ですね。1台で何とかするとか無理ですよね。同人でデータセンター使えるほど稼ぎ出すってすごいってレベルより、恐ろしいってレベルだと思う。そして、オンラインのピークは最初から3か月って寿命短いな。
サーバーデプロイ(サーバーにファイルをアップロードする、データを展開して使えるようにする作業)ももっと書くことあるだろう。
死活監視はゲーム本体は自分でやって、DBやマシンはデータセンターにやらせようか。逆じゃね?少なくともゲーム本体の死活は自分たちでやらなければならない。(独自の物だから)
運用ページもっとかけるだろ。ゲームの信頼性はいかに安全かつ快適に長時間運営できたかで決まるんだから。(自分の鯖のランキングの経験から)

8章、マネジメントはもしドラのドラッガー先生に聞いてね。
仕方ないか、人間関係はプログラミングやサーバー回すことにさらに関係が薄いし。運営の人間関係もオンラインゲームの安定度に影響あると言えばあるが。
最後はお金の話で、締める。開発は金だよ兄貴と言うわけですな。ゲームと同じやんw

まぁ、ゲーム完成できないから何とでもいうんだけどね。(どっからかしゃしゃり出てきて、テキトーなこと抜かす近所のおばさん状態。)

書かれている内容で、違和感ある項目もそこそこあるな。思いついた順に。

「地理的に近い所にサーバーを。」これは違うな。東京都八王子市と東京都町田市(どちらも横浜線のすぐそば)で対戦やった時にラグかった。筆者の考えをそのまま言うなら、”横浜線沿い数駅の近所じゃん”となり、レイテンシーなんか一桁msのオーダーになるはずだ。
だが、実際の経路は、東京都町田市→神奈川県相模原市→神奈川県横浜市→東京都千代田区→東京都江東区→東京都新宿区→東京都立川市→東京都八王子市とネットワーク経路を通る、いわば大回りでゲーム対戦していた。これラグい。
鉄道で言えば、横浜線で横浜行く、京浜東北線で有楽町に行く、東京メトロ有楽町線で新木場に行く、新木場から京葉線・中央線周りで新宿に行く、新宿から中央線特急で立川に行く、立川から各停で八王子行くと言っているようなものだ。
分かりやすさ優先で作者は、「地理的に近い」と言ったのだと思う(思いたい、そいういう意図でないなら⑨)が、正しくは、ネットワーク的に近く(帯域が広く、レイテンシーが小さい)ところにサーバーだと思う。もちろん光の速度は秒速30万キロだから物理回線長も短いに越したことはないが。

ネットワークトポロジにトーラスがないのも不満。HPC畑としては。メッシュの端と端(上下・左右)が繋がったモデルで、端へのアクセス速度をかなり速めることができる。

フルメッシュって何事かと思ったら単純にA2A(オール・ツー・オール:全体全通信)のことだった。
同様にスターもだれかが、ホストって意味だし。
CPUセントリック→CPUバウンド(CPUに律速される)
ストレージセントリック→ディスクバウンド(IOに律速される)
しかし、人間て同じものに別名付けるの好きだね。

この本の構造も脚注による依存だらけ(xxはyy見てねと言うもの自分で書かない)でLinuxのソフトみたいだ。xx関数はyyライブラリにあるから自力で何とかしてねって所がとくに。

(2014年6月7日追記)
そうだ、この作者は通信レイテンシーについては覚えてるけど、内部のレイテンシーについては忘れている。CPUに命令出して次のサイクルで結果をポーンと返してくれるわけじゃないから。CPUは、
フェッチ(データの読み込み)→デコード(命令とデータの分解と解釈)→エグゼック(実行)→メム(メモリアドレスの計算)→WB(ライトバック)
の5サイクルを消費する。Intel系のチートCPUなら実行中にメモリアドレスを別の計算機で計算しちゃうから4サイクルで書き込めるけど。
メモリに書かない命令でも、3命令は消費する。3クロックのレイテンシーが発生する。これを筆者は忘れている。通信に比べたら微々たるもので書かなかったのかもしれないが。HPC屋から言わせてもらえば、これを忘れるなんてありえない。詳細はIntelの開発PDFへ

ついでにメモリもレイテンシーがある。アドレス入れて次のサイクルではい読めたとはならない。ガチゲーマーの人がメモリ選ぶときにCL=10とか気にしている人が居るが、まさにそれ。例の通り10であれば、アドレス情報入れて10サイクル待たないと、結果が出てこない事を示す。このサイクルはCPUのサイクルとは違いもっと低速で動いている。DDR数字-<ここ>とかPC数字-<ここ>の<ここ>に示した部分の数字で動く。CPUよりずっと低速だけどな。
CPUよりずっと遅いということが大事で、CPU4GHzで、DDR3-1600(1.6GHz(実際は800MHzだが倍速処理できるので、1.6GHzと表記する))だとアクセスだけで、2.5(CPU)サイクル(片道)を待つ。往復5(CPU)サイクルだから、5命令分の時間を失うことになる。ちょうど、命令突っ込んで出てくるぐらいの時間だな。だが、10(メモリ)サイクル待つことになるから、CPUは25サイクル待つ。往復分を合計して30(CPU)サイクルの待ちになる。1度のメモリアクセスで30サイクルが失われる。4G中30サイクルならやはり微々たるものと言うのだろうが、16msで時間が無いと書いてる割には悠長だ。ゲームのデータが1回のメモリアクセスで取ってこれるわけがない、簡単に300サイクルは失うだろう。ちなみに、32GBメモリの場合、Core i7 4790Kでも25.6GBの帯域しかないので、32GBのメモリ全体にアクセスするには軽く1秒は掛かる。16msなんて間に合いっこないな。

最適化の観点から言えば、良く考えてデータの配置や容量を決めましょうと言うことだ。

後なんだっけ。思い出したら書く。

繰り返しになるけど、理屈好きにはたまらない本でした。
オンライン化したいゲーム(電車でDなんだけど)があるから読んでみたのだが、章ごとに書いた、その辺の知識が無いならオンラインソフトは無理の通り、自分にゲーム、ましてやオンラインなんて出来るわけがないと悟るには十分であった。車輪の再発明は輪にならず、上手く車が転がらない。まさにその通りで、結局人様に使われ信頼性のあるライブラリやフレームワーク、ミドルウエアが無ければ、オンラインゲームなんて作れない。もはやそういう個人で扱うには規模が大きすぎるところまで行ってしまった。(そのうちダウンサイジングで個人の所まで戻って来るとは思うけどね。より簡単に扱えるようになって。)

書籍データ:
WEB+DB PRESS plusシリーズ
オンラインゲームを支える技術
―壮大なプレイ空間の舞台裏
技術評論社
2011年3月24日発売
中嶋謙互 著
A5判/624ページ
定価(本体2,880円+税)
ISBN 978-4-7741-4580-8

やっと読み終わった。2周目。

« 著作権の本 | トップページ | 著作権法の本パート2 »

書籍・雑誌」カテゴリの記事

プログラミング」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック


この記事へのトラックバック一覧です: オンラインゲームを支える技術~壮大なプレイ空間の舞台裏~:

« 著作権の本 | トップページ | 著作権法の本パート2 »