MMOのサーバ（ハード）の構成ってどうなってるの？

**名前は開発中のものです。** · 02/08/22 16:34

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

**名前は開発中のものです。** · 02/08/22 16:46

みなさまアンケートにご協力下さい。

既にプロ市民と隣国の組織票にやられ短時間のうちに差がついて
しまいますた。
清き一票をお願いすます

今回愛媛で「新しい歴史教科書をつくる会」の教科書が採用されたことについて
http://clickanketo.com/cgi-bin/q.cgi?q0001172911

**名前は開発中のものです。** · 02/08/22 16:47

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

**名前は開発中のものです。** · 02/08/22 16:51

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

**名前は開発中のものです。** · 02/08/22 16:52

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

こんなんあるけどつかえる？
http://www.nxhack.tarumi.kobe.jp/linux_kernel_tuning.html

**名前は開発中のものです。** · 02/08/22 16:55

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

**名前は開発中のものです。** · 02/08/22 17:00

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

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 02/08/22 20:47

終了厨の夏

**名前は開発中のものです。** · 02/08/22 22:59

夏厨風月

**名前は開発中のものです。** · 02/08/22 23:43

回線問題はあまり深刻でないと思うよ。
どうせ人そんなに来ないだろうし、来てからで（・∀・）イイ

ユーザーがゲーム中にサーバー間を移動しないならば、バンバン分散させるのが楽。
東風荘やPSOがこれに当たる。個々のゲームサーバは個別に起動/終了させられる
ようにしておくと管理が楽。ロビーサーバは結局必要。

そうでないＭＭＯなモノを作るとなると、カナーリ大変。下手に分散させると
サーバー間の同期問題で死ねる。Ultima Onlineなんかはうまくやってるほうだけど
それでも時々おかしなことが起こる。

データストアも頭が痛い。単純に考えるとDBにストアすることになるだろう。
どのタイミングで保存するか、どれだけのデータを保存するか、いつロードするか、
ワールド全体が保存の対象か、ユーザーごとに保存するのか、異常終了からの
復帰時に行うべき処理、ナドナド。

**名前は開発中のものです。** · 02/08/22 23:45

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

**名前は開発中のものです。** · 02/08/22 23:51

そりゃスレ違いっぽい

**名前は開発中のものです。** · 02/08/22 23:58

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

**名前は開発中のものです。** · 02/08/23 00:09

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

**名前は開発中のものです。** · 02/08/23 00:14

>>17
正直同じ穴の狢

**名前は開発中のものです。** · 02/08/23 00:57

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

**名前は開発中のものです。** · 02/08/23 01:04

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

**名前は開発中のものです。** · 02/08/23 01:05

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

**名前は開発中のものです。** · 02/08/23 01:07

17=20が悔しがってる？

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 02/08/23 08:21

終了バカ

**名前は開発中のものです。** · 02/08/23 09:35

>>21
さんこふにどうふぞ。

スクウェアの「PlayOnline」のサーバー構成が判明
http://www.4gamer.net/news/history/2002.04/20020426223627detail.html

**名前は開発中のものです。** · 02/08/23 09:44

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

**名前は開発中のものです。** · 02/08/23 10:06

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

**名前は開発中のものです。** · 02/08/23 11:20

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

**名前は開発中のものです。** · 02/08/23 11:22

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

**名前は開発中のものです。** · 02/08/23 11:24

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

**名前は開発中のものです。** · 02/08/23 11:30

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

**名前は開発中のものです。** · 02/08/23 12:11

MMOじゃないけどね。

PSOのできるまで
http://akiba.ascii24.com/akiba/game/interview/2002/02/24/633792-000.html

**ASDF** · 02/08/23 12:11

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

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 02/08/23 23:03

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

**名前は開発中のものです。** · 02/08/23 23:05

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

**名前は開発中のものです。** · 02/08/23 23:57

ふとおもったんだけど、
プレイヤーがワールドにつながったら３つぐらいのサーバーに
同時につなげて、サーバー間のラグをなるべく平均化するって手
使えないかな？

こうすればたとえ１つのサーバーが処理重くても
残りの２つのサーバーのどちらかが早ければ言い訳で
全体的に処理を分散できる。

**名前は開発中のものです。** · 02/08/24 00:08

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

**名前は開発中のものです。** · 02/08/24 00:39

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

**名前は開発中のものです。** · 02/08/24 00:41

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

**名前は開発中のものです。** · 02/08/24 00:52

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

**名前は開発中のものです。** · 02/08/24 01:30

>>42
補足。
キャラデータの入ってるキャラサーバー１つに対して、
複数のワールドサーバーが同時に頻繁にアクセスする
ってことではなくて、ログイン時、ログオフ時にサクセス
するといふいみでふ。

そいえば、クロスゲートはキャラデータが他サーバー間で
共有されてる？
回線切断して、再び接続すると、どんなに遠い場所に行ってても、
街まで直帰というのを聞いたことがある･･･。

**名前は開発中のものです。** · 02/08/24 01:42

>>43
> ってことではなくて、ログイン時、ログオフ時にサクセス

サクセスしちゃいかんのぉ。
自分で読み返してワラタ。
（アクセス）

**名前は開発中のものです。** · 02/08/24 01:53

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

**名前は開発中のものです。** · 02/08/24 02:36

>>45
一昔前、業務システム方面なんだけど、分散志向が流行ったらしい。
まあ案の定言葉が踊ってただけなんだけどね。目的/効果/リスクを
ハッキリさせないと分散しても意味がない。

OSのサポートがあったりなかったりするけど
・高レベルのサポート(ミドルウェアともいう)に全部のせる
・低レベルのサポートを使って残りは自前でくみ上げる(DCOM/CORBA/RMI/RPC/etc)
・全部自前、といってもsocketぐらいは使わせてくれ・・・
の方法があると思う。

一番上のは役に立ちそうで実は役に立たないことが多い。
二番目は分散の構成がスッキリしていれば楽ができ、小回りも効くだろう。
三番目は自前主義の人たちが好むんだが、それなりのパワーと知識がないと
最下層を作ってるうちに時間切れになるね。つうかなった。笑い。

このへんはソフトウェアの設計の根幹にあたる部分だから判断が難しい。
(業務系ならともかく)特にこれといった定石があるわけでもないだろうし。

**名前は開発中のものです。** · 02/08/24 19:55

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

**名前は開発中のものです。** · 02/08/25 12:03

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

**名前は開発中のものです。** · 02/08/25 13:10

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

**名前は開発中のものです。** · 02/09/02 23:37

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

**名前は開発中のものです。** · 02/09/02 23:46

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

**名前は開発中のものです。** · 02/09/03 00:38

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

**名前は開発中のものです。** · 02/09/03 12:12

わかーた！信長の野望オンラインだね（・∀・）

**名前は開発中のものです。** · 02/09/03 18:45

１です。
うちは光●ではありません。（藁）
零細企業です。

**2get** · 02/09/03 22:11

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

**名前は開発中のものです。** · 02/09/03 23:20

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

**名前は開発中のものです。** · 02/09/04 06:15

UCは純和風MMORPGになるのか疑問だな？

**名前は開発中のものです。** · 02/09/04 07:09

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

**名前は開発中のものです。** · 02/09/08 22:29

ひさしぶりに１です。
＞56-58
UCってなに？

**名前は開発中のものです。** · 02/09/09 13:49

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

**名前は開発中のものです。** · 02/09/09 21:29

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

**名前は開発中のものです。** · 02/09/18 23:33

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

**あぼーん** · NG

あぼーん

１ · 02/12/04 23:10

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

**あぼーん** · NG

あぼーん

**あぼーん** · NG

あぼーん

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 02/12/08 15:51

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

**あぼーん** · NG

あぼーん

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 02/12/09 23:30

　　　　　　　　　　　　ｏ
　　　　　　　　　　　 /　￣￣￣￣￣￣￣￣￣￣ /
　　　　　　　　　　　/　　　このスレは無事に　　/
　　　　　　　　　　 /　　終了いたしました　　　 /
　　　　　　　　　　/　ありがとうございました　 /
　　　　　　　　　 /　　　　　　　　　　　　　　　　/
　　　　　　　　　/　　　モララーより　　　　　 /
　　　　　　　　 /￣￣￣￣￣￣￣￣￣￣￣/
　 ∧＿∧　　/　　　　　　　　　　　　　　　　/∧＿∧
　（　･∀･）　/　　　　　　　　　　　　　　　　/（･∀･　）
　（　　　　）つ　　　　　　　　　　　　　　　⊂（　　　　）
　｜｜｜　　　　　　　　　　　　　　　　　　｜｜｜
　（_＿）＿）　　　　　　　　　　　　　　　　　　（＿（＿_）

１ · 02/12/16 23:58

1です。
セレロン１．７GHｚで１GByteメモリで
帯域さえあれば十分２０００人くらいのユーザーはさばけますな。

**名前は開発中のものです。** · 02/12/17 01:48

　　　　　　　　　　　　ｏ
　　　　　　　　　　　 /　￣￣￣￣￣￣￣￣￣￣ /
　　　　　　　　　　　/　　　このスレは無事に　　/
　　　　　　　　　　 /　　終了いたしました　　　 /
　　　　　　　　　　/　ありがとうございました　 /
　　　　　　　　　 /　　　　　　　　　　　　　　　　/
　　　　　　　　　/　　　　ギコ猫より　　　　　 /
　　　　　　　　 /￣￣￣￣￣￣￣￣￣￣￣
　 ∧＿∧　　/
　（　　ﾟДﾟ）　/
　（　　　　）つ
　｜｜｜
　（_＿）＿）

**名前は開発中のものです。** · 03/01/30 04:04

age

**名前は開発中のものです。** · 03/07/09 04:59

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

**名前は開発中のものです。** · 03/09/19 22:56

これもMMOスレか

**名前は開発中のものです。** · 03/09/29 12:16

足跡。

**名前は開発中のものです。** · 03/10/02 23:00

専門家でないので、間違っているかもしれんが、
100BASE-TXのLANカードでざっくり試算してみる。

100Mビット/秒なら10Mバイト/秒ってとこだろ
ゆったりしたＲＰＧでアクション系ではないとしても
最低でも秒間10回ほどはデータをもらいたいとこだ。

すると１コマに1Mバイトしか使えない。
１回当たりのデータを１KBとすると1000人ぶん。
無論、無駄なく通信が衝突せずの場合。
いいとこ５０％のパフォーマンスがでたら万々歳だろ。

1KB×10Hzで500人ってとこかねぇ。
こりゃぁデータ量を如何に減らすかを考えたほうが良さそうだ。
とはいえ100Mbitの帯域を確保するなんて個人じゃまずムリ。

ＡＤＳＬで出てる速度って基地局の近くでもなきゃ。
普通は２～３Ｍ程度でてりゃいいほうだろ（10～15人分？）。
個人でやるならゲーム会社とは違った手法を考える必要があるね。

**名前は開発中のものです。** · 03/10/02 23:02

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

**名前は開発中のものです。** · 03/10/03 00:34

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

**名前は開発中のものです。** · 03/10/03 17:29

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

**416** ◆quHoSW/FCI · 03/10/03 20:49

>>78
　変更データのみ送信…が原則。

　移動データに関しては、内部はマス単位にしてコスト稼ぐのが定石でそ。で、秒間何マス動くゲームになるのかと。
　あと、逐一絶対座標を送信するんじゃなくて、移動終了座標のみ送信して鯖判定で衝突停止が起こったら、新規の終了座標を送り返すと。これすると巻き戻りが見られるけど。

　ADSLを鯖にするときは上りの帯域で計算(512～1M、実質200K?)。
　クライアントとして下りなら、自分の場合(ADSL8M)、基地局から3km+ノイズ64dbで2.6Mというところ。

　実はチャットデータが意外にコスト高。範囲限定ならともかく広域&全域チャットだと…。

　んで、200人以上の接続になってくると、帯域よりモデムやルーターの性能が引っかかってくるんじゃないかと予想してます。

**名前は開発中のものです。** · 03/10/03 22:30

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

**名前は開発中のものです。** · 03/10/04 05:16

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

**名前は開発中のものです。** · 03/10/04 10:45

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

**名前は開発中のものです。** · 03/10/05 02:41

>>85
素人さんでつか？

**416** ◆quHoSW/FCI · 03/10/05 03:56

>>85
　ユーザーの人数もそうだけど、MODの数やMAPの広さも内部処理の負担増になります。ほとんどのコストはソートが占めてくるんじゃないかな。
　でも、こういう内部処理の負担は、ソートなら区画分けして分母を減らすとか(でも一定数を越えると分母を減らすコストが…)、サーバースペックの増強、または複数のサーバーで処理を分担するという方法で対処できます。

　ところがルーター問題になってくると、自前のルーターをいい物に変えても、一番近くの経路である他人のルーターがギブアップする恐れが出てきます。
　単なる帯域問題なら耐えるルーターがほとんどですが、何百何千の相手先最適経由リストを上手く処理できるルーターとなると…。
　幹線に直結できる企業なら問題ないですけど、個人だとどうしても末尾に接続ですしね。

　送受信頻度が比較的高いFPSとかを見てますと、それよりも頻度が低いRPGで光回線なら100人規模は余裕っぽく。200人クラスは個人では前人未到でやってみないとわかりませんね。
　今製作中のMORPGはとりあえずそのクラスを目指してます。
　

**416** ◆quHoSW/FCI · 03/10/05 04:20

>>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、光がやってくる気配がありません(涙

**名前は開発中のものです。** · 03/10/05 10:36

MODってMOBの間違い…？

**416** ◆quHoSW/FCI · 03/10/07 02:32

>>89
　はひMOBでし。FPSのやりすぎかもしれません。

　今、データの種類とその管理方法から呼び出しコストがどれぐらいになるか、大雑把に計算しながら飽きたらドット打ちしてまふ。
　とにかく検索範囲を小さめに設計すればMOBを徘徊させれそうな予感。

　問題は、MAPが変動性なので、見える範囲のデータを常にやりとりして同期を保たないといけないこと。でも変動率はそんなに高くないので、90%近くは無駄な送受信になるのではないかと。
　やはしサムチェックで変化のある無しを検査して2回の送受信を必要とするか、それとも接触可能範囲だけ毎時送受信してその他は帯域が余ってたらにするか…。

**名前は開発中のものです。** · 03/10/07 10:24

＞　とにかく検索範囲を小さめに設計すればMOBを徘徊させれそうな予感。
MOBは、4分木(3Dなら8分木)とかで管理するのが吉(移動して境界をまたいだら
木に振りなおす)。どう考えても更新より参照の方が頻度多いからね。

＞　やはしサムチェックで変化のある無しを検査して2回の送受信を必要とするか、それとも接触可能範囲だけ毎時送受信してその他は帯域が余ってたらにするか…。

「あるクライアントと最後に同期した時間」をサーバ側で各クライアントごとに
持っていればOKじゃないかな？マップはある程度の大きさのエリアごとに区分して。
んで、クライアントがそのエリアに侵入したら(進入しそうになったら?)差分を送信
するということで。そうすると、全エリア更新履歴を持たないといけないんだけどね。

これなら、通信も最新かチェック(往復)→差分送信という1往復半じゃなくて、
送るだけですむ。

全ユーザ分持つのがつらいなら、オンラインクライアントの分だけでもいいし。
1000ユーザx1000エリアx4バイトなら管理領域1Mバイトくらい？

で、クライアントがそのエリアに入ったときに、そのエリアのデータを何時分まで
持ってるかを、まず同期しなければいけないんだけど、接続時に全部同期するか、
「最初の」エリア進入時に動的に同期するか、サーバデータベースにとっておく
かは好き好きで。

「時間」は、「更新シリアル番号」でもいいかも。

**名前は開発中のものです。** · 03/10/07 10:25

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

**名前は開発中のものです。** · 03/10/10 01:21

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

**名前は開発中のものです。** · 03/10/21 13:42

MMOのプログラムって、
20fps位で動くfieldmasterとかのメインスレッドに、
各プレイヤーの別スレッドがリクエストを投げる形でできてるのかな？

鯖構成以前にその辺からわかりません。

**名前は開発中のものです。** · 03/10/22 00:39

fieldmasterって俺用語？

**名前は開発中のものです。** · 03/10/23 12:34

>>95
うん。

**名前は開発中のものです。** · 04/06/17 14:18

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

◆DeUsmjHgh2 · 04/08/28 19:18

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

**名前は開発中のものです。** · 04/08/29 00:45

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

**名前は開発中のものです。** · 04/08/29 14:29

>>1
同期って何で必要なんだっけ？
画面に映ってる他プレーヤの動作と、聞こえるチャットくらいじゃない？
これは１サーバ内でやってしまえばいいんじゃないかなー
つまり、１サーバ１エリア。
そうすれば、サーバ間の同期は、プレーヤがエリアを移ったときだけでいいということに。

**名前は開発中のものです。** · 04/08/29 15:11

>>100
満遍なくすべてのエリアにユーザがいると上手く働くんだけどね。
実際はイベントがあるマップや効率の良い狩場等に集中してしまうわけで。

**名前は開発中のものです。** · 04/08/29 15:33

ユーザ密度が高いところは、エリアを狭くすればいいのでは？

最悪、処理能力を超えそうな場合は、
「人が多すぎてエリアに入れないー」って表示するのは、苦しいかなｗ

**名前は開発中のものです。** · 04/08/29 15:42

>>102
確かにそうだな。
突発的なイベントには対応できないがある程度予想できていれば、
エリアを狭くするという手で対応できるな。

**名前は開発中のものです。** · 04/08/29 16:11

>>98
多分、ＢＩＯＳにサーバプログラム入れるのが最高だろうな。処理能力。