1read 100read
2011年10月1期ゲ製作技術MMOのサーバ(ハード)の構成ってどうなってるの? TOP カテ一覧 スレ一覧 削除依頼
・ 次のスレ
スタッフロールの是非について考える会
【夏休み】Gems3 翻訳会【特別企画】
【本命】遂に俺がゲーム制作を始めるが【登場】
■知識なにも無し、0からゲーム作り■


MMOのサーバ(ハード)の構成ってどうなってるの?


1 :02/08/22 〜 最終レス :10/08/06
MMORPG(2000〜4000人くらいの規模)のサーバの
ハード構成ってどんなんだろうか?そのスペックは?
また、PCサーバ1台でさばけるユーザー数は
何人くらいまでなんだろうか?(帯域は潤沢として)
MMOだと1PCではマルチスレッドやマルチプロセスでも
1000くらいが限界?なのだろうか?
また、サーバハードを複数に分けると(PC500人で1さーばX8とか)
だと同期をとると同じLAN内でも遅延発生しまくりの予感・・・
目標はリネージュくらいの規模のMMOを想定しています。
知識者、経験者、そのほかだれでもいいから知っていること
かきこんで!!!!

2 :
リネージュはKIMUCHIサーバー

3 :

4 :
なんでこの板はすぐに終了させたがるのか?

5 :
みなさまアンケートにご協力下さい。
既にプロ市民と隣国の組織票にやられ短時間のうちに差がついて
しまいますた。
清き一票をお願いすます
今回愛媛で「新しい歴史教科書をつくる会」の教科書が採用されたことについて
http://clickanketo.com/cgi-bin/q.cgi?q0001172911

6 :
1です。
linux2.2系の場合プロセス数の上限が512だったような・・・
SUNやBSDではもっと多くできるのかな?
プロセス数の上限が接続できるユーザーの1サーバあたりの
上限と考えてもいいのだろうか?

7 :
>>4
意味も理解してないのに「つまんねーこと聞くな。こんなもん終了だ」というスタイルを取るのがカッコいいと思ってる馬鹿がいるんだろう。

8 :
>>6
>1です。
> linux2.2系の場合プロセス数の上限が512だったような・・・
> SUNやBSDではもっと多くできるのかな?
> プロセス数の上限が接続できるユーザーの1サーバあたりの
> 上限と考えてもいいのだろうか?
>
こんなんあるけどつかえる?
http://www.nxhack.tarumi.kobe.jp/linux_kernel_tuning.html

9 :
1です。
もし、複数のサーバでそれぞれユーザーをさばいていたり
NPCを別のサーバでさばくと
、隣のサーバまでは当然TCPで接続となる。
と、たとえば全ユーザーの検索とか
いろいろとTCPのオーバーヘッドが大きくなりそうなので
たとえ100B-TX のLAN接続でも、同期を取るのが
たいへんそうだ・・・

10 :
>8さん
1です。
なるほど、こうやってぎりぎりいっぱいまで
チューニングして、1台のPCサーバで5000人くらいまで
さばくんですか・・・
参考にしてみます。ほかにも情報お持ちの方、
または、実際に稼動している、もしくは開発中のMMOでサーバ構成を
ご存知の方、タレコミPlz!

11 :

12 :
終了厨の夏

13 :
夏厨風月

14 :
回線問題はあまり深刻でないと思うよ。
どうせ人そんなに来ないだろうし、来てからで(・∀・)イイ
ユーザーがゲーム中にサーバー間を移動しないならば、バンバン分散させるのが楽。
東風荘やPSOがこれに当たる。個々のゲームサーバは個別に起動/終了させられる
ようにしておくと管理が楽。ロビーサーバは結局必要。
そうでないMMOなモノを作るとなると、カナーリ大変。下手に分散させると
サーバー間の同期問題でる。Ultima Onlineなんかはうまくやってるほうだけど
それでも時々おかしなことが起こる。
データストアも頭が痛い。単純に考えるとDBにストアすることになるだろう。
どのタイミングで保存するか、どれだけのデータを保存するか、いつロードするか、
ワールド全体が保存の対象か、ユーザーごとに保存するのか、異常終了からの
復帰時に行うべき処理、ナドナド。

15 :
どちらかというと適応予測とかハズレの場合のリカバリについて詳しい
のがあるとうれしかったり。

16 :
そりゃスレ違いっぽい

17 :
>>1が何の知識も無く関連URLすら張らず努力の跡が全くみられず結局単発質問スレになっている
その後に付くのは終了AAと実際に組んだこともないのに想像だけで知ったかするだけの回答者
これを糞スレという

18 :
実際のサーバー構成ってどんなだろうな...

19 :
>>17
正直同じ穴の狢

20 :
他はムジナだが19のみムジナの糞。

21 :
1です。
>14
UOみたいなタイプでサーバーを複数分散させると
地獄を見るのは・・・・先月実験しますた。
やはり、サーバ単騎で1ワールドがべすとかなぁ?
データのストアはユーザーログイン時に
HDDベースのDB(オラクルやmysql等)で読み込んで
稼動中はメモリベースの自作DBを使います。
で、サーバを立ち上げる前、落とす前、
ユーザーがログインする前、後で
HDDベースのDBにアクセス
それ以外はメモリベースでまかないます。
HDDベースのDBでゲーム中もストア等のためにDBアクセスを
すると、とてもUOやリネージュみたいなスピードは
出ませんでした。

22 :
1です。
とりあえずターゲットはリネージュを目標に
作成中。

23 :
17=20が悔しがってる?

24 :

25 :
終了バカ

26 :
>>21
さんこふにどうふぞ。
スクウェアの「PlayOnline」のサーバー構成が判明
http://www.4gamer.net/news/history/2002.04/20020426223627detail.html

27 :
>>21
ちなみに初期のUOのさぁヴぁは
:Pentium Pro 200MHz×4
:メモリ2G程度
:HD何十〜何百GB位
のマシンが6台だったそうな。

28 :
>>24 ここはまじめな板だから消えてくれない?
   コピペのネタレスはやめてくれないか?

29 :
1です。
>28 あらしは放置の方向で。
>26 参考になりました。何かの記事で■のFF11では
サーバ1500台とのことは聞いていたけど
内訳がこうだったのね・・・、1500で3つのワールドで
1ワールド500台、でも直接フロントエンドを支えるのは
クラスタリングサーバだね。お金がいくらあっても足りない
構成ですな。(うちの会社では到底実現できません)
>27 参考になりました。
せいぜい初期のUOくらいの構成で開発がんばりたいです。(藁)

30 :
1です。
リネージュやガディウスやラグナロックの
サーバ構成ご存知の方いません?

31 :
関係ないけど なんで韓国にこだわるんス?

32 :
1です。
べつに韓国にだわっていないのだけど・・・
開発のモデルが、ガディウスやリネージュみたいな
2Dであることと、企画書の段階でお手本ゲームに
韓国ゲームが多用されていたからかな?
開発がわからしてもUOやFF11よりも
韓国産のほうがこじんまりしていて、参考になりそうだからです。
じっさいにサーバ構成がこじんまりしているかどうかはわからないのですが。

33 :
MMOじゃないけどね。
PSOのできるまで
http://akiba.ascii24.com/akiba/game/interview/2002/02/24/633792-000.html

34 :
>>1がんばってください。

35 :

36 :
1です。
>33 かなり参考になりました。MMOではないけどなるほどと思いました。
PSOみたいに低予算サーバ(ハイエンドサーバでなくて通常PCで)
の挑戦ですので、PSOとかと同じ状態です。
もっともMMOなのでかなり大変ですが・・・
>34 ありがとうございます。がんばります!

37 :
1です。
現在、設計では認証サーバが1台、ワールドサーバXワールド数、
DBサーバが1台、HTTPサーバ(アナウンス用)が1台の構成予定です。

38 :
ふとおもったんだけど、
プレイヤーがワールドにつながったら3つぐらいのサーバーに
同時につなげて、サーバー間のラグをなるべく平均化するって手
使えないかな?
こうすればたとえ1つのサーバーが処理重くても
残りの2つのサーバーのどちらかが早ければ言い訳で
全体的に処理を分散できる。

39 :
1です。
>38
いいかんがえだと思うけど・・
サーバのミラーリングは可能だけど
ラグる時はその搬送経路上のどっかでらぐるので
3台あっても3台とも同じところでラグる罠。
もっとも、ネットワーク上でぜんぜん違う3台(アメリカと日本と韓国とか)
で3台あれば少しは有効か?
でも費用かかりそう(メンテナンスめんどくさそう)

40 :
>>39
経路でのラグは、まぁ仕方ないとして、
キャラクタデータは、別途サーバー(DB?)を設けた方がよいのでは?
ワールドが5つあったとして、キャラデータさえ外部に出ていれば、
プレイヤーは空いてるサーバーにログインするとおもうのだけれど、
如何なのもか?

41 :
「空いてる」の定義にもよると思ワレ
PSO系だとそれで無問題
UO系だとそれは無意味

42 :
>>41
たしかにたしかに。
「空いてる」とは、UOで言うところの「シャードが別」

43 :
>>42
補足。
キャラデータの入ってるキャラサーバー1つに対して、
複数のワールドサーバーが同時に頻繁にアクセスする
ってことではなくて、ログイン時、ログオフ時にサクセス
するといふいみでふ。
そいえば、クロスゲートはキャラデータが他サーバー間で
共有されてる?
回線切断して、再び接続すると、どんなに遠い場所に行ってても、
街まで直帰というのを聞いたことがある・・・。

44 :
>>43
> ってことではなくて、ログイン時、ログオフ時にサクセス
サクセスしちゃいかんのぉ。
自分で読み返してワラタ。
(アクセス)

45 :
初心者的質問ですまんが・・・。
複数PCで作業を分散するのって特別なOSが必要ですか?
通常1PCに2CPU乗ってるのは対応OSならばできるけど、
複数PCに作業を分散させるとかだとどうなるんだろう。
と、いうかそもそもそんなことしてないのかな・・・。
素朴な疑問・・。

46 :
>>45
一昔前、業務システム方面なんだけど、分散志向が流行ったらしい。
まあ案の定言葉が踊ってただけなんだけどね。目的/効果/リスクを
ハッキリさせないと分散しても意味がない。
OSのサポートがあったりなかったりするけど
・高レベルのサポート(ミドルウェアともいう)に全部のせる
・低レベルのサポートを使って残りは自前でくみ上げる(DCOM/CORBA/RMI/RPC/etc)
・全部自前、といってもsocketぐらいは使わせてくれ・・・
の方法があると思う。
一番上のは役に立ちそうで実は役に立たないことが多い。
二番目は分散の構成がスッキリしていれば楽ができ、小回りも効くだろう。
三番目は自前主義の人たちが好むんだが、それなりのパワーと知識がないと
最下層を作ってるうちに時間切れになるね。つうかなった。笑い。
このへんはソフトウェアの設計の根幹にあたる部分だから判断が難しい。
(業務系ならともかく)特にこれといった定石があるわけでもないだろうし。

47 :
1です。
>40-43
キャラクターデータのサーバ(=認証サーバ)1台にして
ワールドに振り分ける(=ワールド間の移動可能)にしたいところです。
もっとも、RMTを黙認否認と同様に社内で議論がまとまりません。
新しいワールドの追加によるゲームの活性化が狙えないから・・・だとか。
>45-46
複数サーバは比較的時間の余裕のあるビジネスアプリ(MMOみたいにシビアでない)
場合、擬似クラスタリングDBとか経験あります。
ビジネスの場合46の1,2,3すべて可能ですが、MMOの場合・・・使えそうなのが
ないよなあ・・・TCPのオーバーヘッド大きすぎ。

48 :
完成したら問題にならない範囲でスペックとか実装方法とか教えてくれるとうれシーナー。

49 :
この人に聞いてみれば?
http://game.2ch.net/test/read.cgi/gamedev/1022900734/75

50 :
久しぶりに1です。
開発は順調に進んでいます。
社内での合意を得れればここで、簡単なサーバ構成や、プログラム構成を
書き込んでみたいです。
まだ、タイトルはいえないのですが合意が得れればタイトルも発表したいです。
いえるのは純和風のMMORPG・・ってことです。

51 :
製品についてはあんまりしゃべらずに
構成だけをチョロチョロ言ってもらえると嬉しいよ

52 :
>>50
一発でわかりそうな気が・・・っていうかまだその段階なのか!?

53 :
わかーた!信長の野望オンラインだね(・∀・)

54 :
1です。
うちは光●ではありません。(藁)
零細企業です。

55 :
1番のりって
このスレ立てたやつはどこだ(W

56 :
まさかと思うがUCってオチは無いよな?

57 :
UCは純和風MMORPGになるのか疑問だな?

58 :
>>57
だが、どう考えても日本人が生み出し日本で育った日本の文化だし・・・

59 :
ひさしぶりに1です。
>56-58
UCってなに?

60 :
>>59
これかな
http://game.2ch.net/test/read.cgi/netgame/1027119494/

61 :
1です。
みてきました、UC。
一技術者としては、UCの製作さんの苦労も・・・わからんでもないので
ノーコメント。
一個人としては・・・はなはだ疑問。(苦笑)
だって実尺実時間なんて・・・16万人同時プレイ?
サーバ資源食いまくりでとてもかかった費用ペイできそうに
ないし。。。
ほんとにダミープロジェクトかって、疑いの声があがるのも
わからないでもない・・・・
おいらのところは12分の1の時間の流れ・(1日=2時間)
で1万X1万マスの2000人PCで5000NPC(モンスターも含む)
ってところが精一杯、(これよりすくなくなるかもしれんが・・)
16万人はすごすぎ・・というか、そんなことが実現できるクラスタサーバ
っていくらお金かかるか検討もつかないです。

62 :
1です。
久しぶりのカキコ。
製作順調です。

63 :

64 :
1です。
通常にLinuxでさくさく作成しています。
今はクライアントの作成に入りました。

65 :

66 :

67 :

68 :
>>1
もう少し詳しい情報出してくれよう

69 :

70 :

71 :
            o
            /  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ /
           /   このスレは無事に  /
           /  終了いたしました    /
          / ありがとうございました  /
          /                /
         /   モララーより      /
         / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄/
  ∧_∧  /                /∧_∧
 ( ・∀・) /                /(・∀・ )
 (    )つ               ⊂(    )
 | | |                   | | |
 (__)_)                  (_(__)

72 :
1です。
セレロン1.7GHzで1GByteメモリで
帯域さえあれば十分2000人くらいのユーザーはさばけますな。

73 :
            o
            /  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ /
           /   このスレは無事に  /
           /  終了いたしました    /
          / ありがとうございました  /
          /                /
         /    ギコ猫より      /
         / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ∧_∧  /
 (  ゚Д゚) /
 (    )つ
 | | |
 (__)_)

74 :
age

75 :
>>1
最近、どうですか?大分経ってますが。

76 :
これもMMOスレか

77 :
足跡。

78 :
専門家でないので、間違っているかもしれんが、
100BASE-TXのLANカードでざっくり試算してみる。
100Mビット/秒なら10Mバイト/秒ってとこだろ
ゆったりしたRPGでアクション系ではないとしても
最低でも秒間10回ほどはデータをもらいたいとこだ。
すると1コマに1Mバイトしか使えない。
1回当たりのデータを1KBとすると1000人ぶん。
無論、無駄なく通信が衝突せずの場合。
いいとこ50%のパフォーマンスがでたら万々歳だろ。
1KB×10Hzで500人ってとこかねぇ。
こりゃぁデータ量を如何に減らすかを考えたほうが良さそうだ。
とはいえ100Mbitの帯域を確保するなんて個人じゃまずムリ。
ADSLで出てる速度って基地局の近くでもなきゃ。
普通は2〜3M程度でてりゃいいほうだろ(10〜15人分?)。
個人でやるならゲーム会社とは違った手法を考える必要があるね。

79 :
キャラの位置情報だけのやり取りなら結構な人数はさばけそうだ。
少人数用のお手軽アクション系でも作ったほうが楽しげかも。

80 :
>最低でも秒間10回ほどはデータをもらいたいとこだ。
別に定期的にデータを送らないといけないわけでもないでしょ。
キーフレームアニメは、毎tickの座標を持っているわけではない、という感じ。

81 :
頻繁に送るデータを極力減らすべし。
マップの単位を256*256にぐらいにしとけば、
1キャラあたり「ID、X、Y、向き」で5バイトくらいになる
256人分送っても1280byteだよ。

82 :
>>78
 変更データのみ送信…が原則。
 移動データに関しては、内部はマス単位にしてコスト稼ぐのが定石でそ。で、秒間何マス動くゲームになるのかと。
 あと、逐一絶対座標を送信するんじゃなくて、移動終了座標のみ送信して鯖判定で衝突停止が起こったら、新規の終了座標を送り返すと。これすると巻き戻りが見られるけど。
 ADSLを鯖にするときは上りの帯域で計算(512〜1M、実質200K?)。
 クライアントとして下りなら、自分の場合(ADSL8M)、基地局から3km+ノイズ64dbで2.6Mというところ。
 実はチャットデータが意外にコスト高。範囲限定ならともかく広域&全域チャットだと…。
 んで、200人以上の接続になってくると、帯域よりモデムやルーターの性能が引っかかってくるんじゃないかと予想してます。

83 :
細かいデータの送信が主になるから、
参考にするスループット値は、bpsのほうじゃなくて、pps(Packet per Second)のほうなんだよね。
でも、ppsがスペックとして出てるルータなんかほとんど無いのが現状?

84 :
結局はゲームのデザインにより同時に更新されるデータ量が異なり、
なんとも言えんということだなw
1画面に何百人も存在して、それが同時に移動するなんてまず滅多にないこと。
更新データが多いようなら重要度の高い順に送って、
ゆっくりとつじつま合わせしてけってこった。
大人数チャットがそれなりに動けばどうにかなる。
とりあえず、たたき台を作って実際の送信データが何がどれくらい
必要かを調べてから煮詰めるしかない。

85 :
>1画面に何百人も存在して、それが同時に移動するなんてまず滅多にないこと。
画面内じゃなくて全体の人数多くなると、
実は送信よりゲーム内の処理のほうが大変になったりして(予想)

86 :
>>85
素人さんでつか?

87 :
>>85
 ユーザーの人数もそうだけど、MODの数やMAPの広さも内部処理の負担増になります。ほとんどのコストはソートが占めてくるんじゃないかな。
 でも、こういう内部処理の負担は、ソートなら区画分けして分母を減らすとか(でも一定数を越えると分母を減らすコストが…)、サーバースペックの増強、または複数のサーバーで処理を分担するという方法で対処できます。
 ところがルーター問題になってくると、自前のルーターをいい物に変えても、一番近くの経路である他人のルーターがギブアップする恐れが出てきます。
 単なる帯域問題なら耐えるルーターがほとんどですが、何百何千の相手先最適経由リストを上手く処理できるルーターとなると…。
 幹線に直結できる企業なら問題ないですけど、個人だとどうしても末尾に接続ですしね。
 送受信頻度が比較的高いFPSとかを見てますと、それよりも頻度が低いRPGで光回線なら100人規模は余裕っぽく。200人クラスは個人では前人未到でやってみないとわかりませんね。
 今製作中のMORPGはとりあえずそのクラスを目指してます。
 

88 :
>>61
 で、1さん(企業)が携わっているMMPRGの規模が書かれてるね。純和風のネトゲ、順調でしょうか。
 それにならって、製作中のMORPGの規模を書いてみたり。
 時間の流れは1/60で実時間24分がゲーム内の1日に相当します。
 MAPの広さは回線と鯖の規模により、128×128、256×256、512×512、1024×1024から選択。PHIのように個人で鯖を立て、各MAPが行き来できる仕様。ただし、PHIのように鯖官が好きにリソースをいじることはできません。
 ユーザーキャラは32から512キャラ(128キャラ以上で障害が出そうな悪寒)。MAPにMODに相当する成長システムがあるので、MOdとの戦闘は禁断のエンカウント方式になる予定です。自前のCPUでさばけたらMODにするかも。
 ちなみに私のPCはDuron 1.1GHzで512MByte。今年中にマザボ変えて底上げする予定です。回線はADSL8M、光がやってくる気配がありません(涙

89 :
MODってMOBの間違い…?

90 :
>>89
 はひMOBでし。FPSのやりすぎかもしれません。
 今、データの種類とその管理方法から呼び出しコストがどれぐらいになるか、大雑把に計算しながら飽きたらドット打ちしてまふ。
 とにかく検索範囲を小さめに設計すればMOBを徘徊させれそうな予感。
 問題は、MAPが変動性なので、見える範囲のデータを常にやりとりして同期を保たないといけないこと。でも変動率はそんなに高くないので、90%近くは無駄な送受信になるのではないかと。
 やはしサムチェックで変化のある無しを検査して2回の送受信を必要とするか、それとも接触可能範囲だけ毎時送受信してその他は帯域が余ってたらにするか…。

91 :
> とにかく検索範囲を小さめに設計すればMOBを徘徊させれそうな予感。
MOBは、4分木(3Dなら8分木)とかで管理するのが吉(移動して境界をまたいだら
木に振りなおす)。どう考えても更新より参照の方が頻度多いからね。
> やはしサムチェックで変化のある無しを検査して2回の送受信を必要とするか、それとも接触可能範囲だけ毎時送受信してその他は帯域が余ってたらにするか…。
「あるクライアントと最後に同期した時間」をサーバ側で各クライアントごとに
持っていればOKじゃないかな?マップはある程度の大きさのエリアごとに区分して。
んで、クライアントがそのエリアに侵入したら(進入しそうになったら?)差分を送信
するということで。そうすると、全エリア更新履歴を持たないといけないんだけどね。
これなら、通信も最新かチェック(往復)→差分送信という1往復半じゃなくて、
送るだけですむ。
全ユーザ分持つのがつらいなら、オンラインクライアントの分だけでもいいし。
1000ユーザx1000エリアx4バイトなら管理領域1Mバイトくらい?
で、クライアントがそのエリアに入ったときに、そのエリアのデータを何時分まで
持ってるかを、まず同期しなければいけないんだけど、接続時に全部同期するか、
「最初の」エリア進入時に動的に同期するか、サーバデータベースにとっておく
かは好き好きで。
「時間」は、「更新シリアル番号」でもいいかも。

92 :
というか、微妙にスレ違いsage

93 :
>>1
まじでどうなったのかなぁ
気になる。

94 :
MMOのプログラムって、
20fps位で動くfieldmasterとかのメインスレッドに、
各プレイヤーの別スレッドがリクエストを投げる形でできてるのかな?
鯖構成以前にその辺からわかりません。

95 :
fieldmasterって俺用語?

96 :
>>95
うん。

97 :
ADSLだと上り1M程度だからテストするにもキツイよね?

98 :
やはり、鯖側のソフトウェアはOSが入ってい状態でDOSモードなんかで動かすんでしょうか?
それともLinuxサーバー上で動かすんでしょうか?

99 :
>94
とんできたリクエストを待ち行列にいれておいて
スレッドが空いたらリクエストを処理させるスレッドを作って処理させるとかかな?
別に1000人ログインしているからといって常に1000スレッド回しておく必要もないし
全体の時間進行による変化は別スレッドかな
それも1000人いても基本的には1スレッドでいいでしょ

100read 1read
1read 100read
TOP カテ一覧 スレ一覧 削除依頼
・ 次のスレ
スタッフロールの是非について考える会
【夏休み】Gems3 翻訳会【特別企画】
【本命】遂に俺がゲーム制作を始めるが【登場】
■知識なにも無し、0からゲーム作り■