MMORPG 作成

◆dqOqxR1c · 01/11/06 19:00

MMORPG 作成 I
　http://natto.2ch.net/netgame/kako/1001/10012/1001227519.html
MMORPG 作成 II
　http://game.2ch.net/test/read.cgi/netgame/1002000791/l50

プロジェクトページ
　http://freeweb2.kakiko.com/mmorpg/

**名無しさん＠お腹いっぱい。** · 01/11/07 22:07

>>32=>>39=>>43＝＞45=>>49

**名無しさん＠お腹いっぱい。** · 01/11/07 22:07

>>50
そうだけど、なにか？

**名無しさん＠お腹いっぱい。** · 01/11/07 22:08

>>32=>>39=>>43＝＞45>=>>49!=>>51

51 · 01/11/07 22:09

漏れは別人ですが何か？

**名無しさん＠お腹いっぱい。** · 01/11/07 22:10

>>51=>>53

**名無しさん＠お腹いっぱい。** · 01/11/07 22:11

板違いのスレです。
放置で。

**名無しさん＠お腹いっぱい。** · 01/11/07 22:17

MMOは[M]まじ[M]みじかい[O]お○ん○んの略ですか？

**名無しさん＠お腹いっぱい。** · 01/11/07 22:22

>>56
そうです。
わかったら宿題終わらせないさい。

**名無しさん＠お腹いっぱい。** · 01/11/07 22:31

ないさい。

**名無しさん＠お腹いっぱい。** · 01/11/07 22:48

　　　　　　　　　／■＼　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　（　´∀｀）＜　宿題終わったよ。
　　　　　　　＿φ＿__⊂)__ ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　／旦／三／／|
　　　　　　　　|￣￣￣￣￣|　 |
　　　　　　　　|熊本みかん|／

**名無しさん＠お腹いっぱい。** · 01/11/07 22:50

みじめな>>59

**名無しさん＠お腹いっぱい。** · 01/11/07 23:36

>>31
あと、P2Pだとチートの問題をどうするかだよね。
DiabloとかAoEみたいな少人数でやるやつならプレーヤ間の関係が薄いから、
あいつチーターだ！で終わりになるけど、
MMOだとゲームバランスが崩れちゃうし。

例えば、あるPeerが自分の管理してる地域にアイテムやらお金やらを大量出現させ、
ウハウハ！とかやられて、そのステータスをたのPeerにもってっちゃったら？

よっぽど強力な認証システム(それも完璧なのは無理だから「信用」ベースの認証システム)を
作んないといけないんじゃないかな?

ということで、鯖間で同期ができて、(信頼できる)有志何人かがサーバを運営するといったような
C/S型がいいとおもわれる。
多分鯖1台だと100人規模もむつかしいんじゃ？

61 · 01/11/07 23:45

>>31
って、セキュリティが心配とか書いてあった。鬱。

まぁ、P2PでもOKかもしれないセキュリティシステム、プロトコルなんかを考えるのも
おもしろいかな？ということで。

32 · 01/11/08 00:03

おお、なんか粘着になってる

>>62
だから、P2PでどうやってMMOを実装するんだ？
単純に実装すると、(n*n-1)/2の勢いでコネクションの本数が増えていくぞ？

**名無しさん＠お腹いっぱい。** · 01/11/08 00:54

ここ削除依頼でてるよ。

**61=62** · 01/11/08 01:22

>>63
いちおうC/Sの方がいいと思われ派なんだが、

全Peerが、他のPeer全部とコネクション結ぶなんてことがあるわけないじゃない。
もうちょっとP2Pを勉強したほうがいいと思われ。
俺も完全に分かってるわけじゃないけど。

で、どう実現するかというと(実証してないけど)、
近くにいるプレーヤー同士が集まってそのうちの1つのPeerをサーバとして
他のプレーヤーが接続する。ここまではC/Sモデル。
で、
・自分に一番近いサーバ(プレーヤグループ)はどこか
・どのプレーヤー同士を同まとめるか
・どのPeerをサーバとするか
などをP2Pのプロトコル(Gnutellaとかで使われてるようなやつ)で決める。
というのが現実的かなぁ？と妄想してみた。

このときにサーバとなるやつが不正したらどうするのさ！ってのが>>61

あと、P2Pだと全体としてのパケット量が増えるってのはそのとおり。
でも、１つのサーバにかかる負荷は減る。
で、全Peerをサーバ候補にできるようにして、かつサーバが今のADSLくらいの帯域で動くようにできれば
有志に頼らなくてもできるかも、ってのがP2Pの利点。

長くてごめん。

**61=62** · 01/11/08 01:26

というか、>>65みたいなアイデアをどっかの会社がライブラリとして?つくったってのを
2年位前のPlayOnline誌でみたおぼえがあるんだけど、その後とか知ってる人いない?
PlayOnlineは全部捨てちゃったので確認もできないです。

**名無しさん＠お腹いっぱい。** · 01/11/08 01:33

削除されるそうなので続くなら以下でどうぞ。
http://game.2ch.net/test/read.cgi/netgame/1005145338/

**名無しさん＠お腹いっぱい。** · 01/11/08 01:38

>>67
迷惑ですので、こちらで引き取ってください

**名無しさん＠お腹いっぱい。** · 01/11/08 02:10

ちょっとソレるけど、ＮＰのモンスターの類い、湧いて出る所を
プレイヤーには見せたくないと思う。
いつ、どこへ、どうスマートに配置する？

**名無しさん＠お腹いっぱい。** · 01/11/08 06:29

>>69
木とかの障害物の中。
この前いきなり沸いてきてﾋﾞｸｰﾘしたよ。
すまそ、ただの体験談。

**名無しさん＠お腹いっぱい。** · 01/11/08 06:31

＞７０
そうでしたか。
やはり、死角からニュっと出すのが一般的なんですかねー。
他に方法を御存じの方います？

**名無しさん＠お腹いっぱい。** · 01/11/08 07:04

今考えた
プレイヤーキャラが絶対これないところに出現させてから誘導
モーフィングつかっていつのまにか登場
マウスカーソルの裏にひっついて登場
保護色にしてわからないように登場
全プレイヤーの視覚外から登場
たまごがでてきてうまれて登場
やっぱり適当にいきなり登場

あとはまかせた

**名無しさん＠お腹いっぱい。** · 01/11/08 10:46

まずプレーヤーがいないところを探してポップさせるってのが基本
(2Dならそんなに重くないね)で、それが出来ない場合、
・同じマップにいたプレーヤーにはそのモンスターを見せない
(戦闘が起こったり、近づきすぎたりしたらしょうがないので見せる)
・込み合わないように人数制限する
・込み合わないようにマップを超広大にする

3Dのときはどうしよう?

**名無しさん＠お腹いっぱい。** · 01/11/08 11:02

>3Dのときはどうしよう?

プレイヤーの背後に出現

**名無しさん＠お腹いっぱい。** · 01/11/08 11:48

ワルキューレの冒険みたいに割り切ったヤツのほうが好きだったり。

**名無しさん＠お腹いっぱい。** · 01/11/08 12:43

敵の種類にもよるが、
地面の穴から出現とか
空から舞い降りてくるとか
いう表現方法もある

**名無しさん＠お腹いっぱい。** · 01/11/08 13:34

なかなか削除されないﾅｰ

**名無しさん＠お腹いっぱい。** · 01/11/08 15:03

>>75
煙とともに登場。
古典的かつ自然。
プレイヤーも納得、開発者もニコニコですな。

**名無しさん＠お腹いっぱい。** · 01/11/08 15:07

なんか、削除せんでも良くない？
結構まだノウハウができてない分野だと思うんだよね。
スレを乗っ取った気分で、オンライン系の技術のハナシ続けてみては？

**名無しさん＠お腹いっぱい。** · 01/11/08 15:09

C/Sを前提で。基本的な質問ですまん。
敵の発生ってのは鯖が管理するのか？
それともクライアントが発生させたのを鯖に送り
それを他の端末に配信するのか？

登場シーンに凝ると、ラグが発生しそうで恐いな
何もなしで突然現れるのもなんだが。

**名無しさん＠お腹いっぱい。** · 01/11/08 15:14

「～が、ドコソコに出現したよという意味を持った」メッセージを
送る事に、なぜ通信コストが関係あるのかにゃ？（笑）
シーンがどうとか、グラフィックがどうとか、まったく関係ないでしょ

**名無しさん＠お腹いっぱい。** · 01/11/08 15:17

>81
確かにそりゃそうだ（ｗ

80 · 01/11/08 15:19

「どこそこの出現した」のメッセージをクライアントが受け取ってから
出現描写するわけだろ？
鯖上ではすでに敵として発生しているものが、
端末上ではまだ出現してないって状態が生じる。
また、端末のスペックが異なれば、こっちの端末では出現してるが
自分の端末ではまだ敵として現れていないって状態になる。
その辺の整合性が取れなくなったらMMORPGとしていまいちだろ。

まさか出現完了したメッセージを鯖に送り返して全部揃ってから
初めて敵として認識できるようにするのか？（無茶）

**名無しさん＠お腹いっぱい。** · 01/11/08 15:22

昔、Iwango対応ゲームがフリーソフトで出てたけどどうやってつくるの？
8人までしか参加できなくても途中参加ＯＫで出入りが結構あれば
おもしろいものつくれるんじゃないかと思って…。

81 · 01/11/08 15:25

＞８０
それは、すべてに言えることですね。
サーバとクライアントの時間軸を整合させる事は、このハナシ
以前に当たり前、かつ永遠のテーマかと。
つまり、出現に時間がかかったらダメで、速ければＯＫって
わけにはいかないの。
１秒ならダメで、０．２秒ならＯＫなのじゃないよね。
マシンスペックとか、そういう伸縮しうる条件を、すべて
飲み込んだ同期方法が必要になります。ハイ。

**名無しさん＠お腹いっぱい。** · 01/11/08 15:27

正直、ＩＳＤＮ以下の回線を対象からはずしてもいいですか？

80 · 01/11/08 15:30

で、その同期を取るうえで、モンスの出現の表現が凝れば凝るほど
（出現表現に限らずエフェクトが派手になればなるほど）
同期を取る方法はより難解になるのではって言いたかったんだが。
完全同期を取ったとして、敵一体が現れるたびに２秒も３秒も待たされたんじゃ
ゲームとして成り立たないだろ。

↑エフェクトが派手ってのは見た目の派手さじゃなく
エフェクトに使用される時間が長いって思ってくれ

８１ · 01/11/08 15:37

もひとつ面白いハナシ。
全プレイヤーの条件（マシンスペックを吸収するため）にするために、
たとえば一定時間にエントリーしうるメッセージを制限する方法を考えて
みたりします。（例題として）
その場合、たとえば１００人いたら、１００人のプレイヤーのメッセージ
をすべて受け取ってからでないと、サーバは結論を出せない事になります。
（意味通じるか不安。御存じの既存MMOに置き換えて想像してね）
その後、現状の評価を行った後、サーバが全プレイヤーに状況を送り
返すとします。
●全クライアントの（乗り遅れは無効）エントリーを待つ
●サーバによる評価、行動の適用
●全クライアントへ結果返信
この後ようやく、クライアントはその「回」の描画を開始できる
事になります。
次の送信は、さらにこの後です。
エライ時間かかっちゃうよね、これでは。
もっと言うと、サーバのＣＰＵが使われずに待ちになってる時間、
サーバの回線が使われていない時間、つまり無駄も多いよね。

RPGに限らず、通信コストやサーバの計算時間を「一滴も」無駄に
したくないMMOの場合、時間軸を中心にそえた設計をしていないと、
トンデモプログラムになる事請け合い。

87 · 01/11/08 15:40

出現時刻と、エフェクトの所用時間、つまり活動可能な時間を
当然クライアントは知っている（データを持たせてある）はず
だろうから、何の問題もないです

**名無しさん＠お腹いっぱい。** · 01/11/08 15:40

どのタイミングで出現しますよ、ってメッセージを送れば良いんじゃないの？
同期の確保されたタイマーを用いて。

81 · 01/11/08 15:41

失礼、８７って書いちゃった８１ですゴメンナサイ　↑８９のレス

**名無しさん＠お腹いっぱい。** · 01/11/08 15:42

UOや最近評判のDAoCでは、
サーバー・クライアント間は完全に同期取れてるのかな？
やっぱりその辺は特許物の技術で公にはされないんだろなぁ

80 · 01/11/08 15:47

なるほど、「いついつにどこそこに出現する」ってメッセージを送っておいて
仮に描画が３秒なら、「いついつ」の３秒前に描画を始めておいて、
その描画とは非同期に「いついつ」に敵を出現させればいいのか。
（グラフィックの性能が異なれば描画時間には誤差があるから
　非同期出現の方がいいよな？）
それなら派手なエフェクトもＯＫだな。理解したよ、thx!

81 · 01/11/08 15:48

１度しか遊んだ事ないですが、どうも同期はパーフェクトではない
ように感じました。クライアントによって速度さがあるようですし。＜ＵＯ

実は、自分自身もこの同期方法をテーマにしばらく作業していたもので、
他のプログラマの皆さんが、どのあたりまでこの分野に対して
考察が進んでいるのか、とても興味があります。

**名無しさん＠お腹いっぱい。** · 01/11/08 15:51

特許がとられていれば、逆に公開されているって事ですね。
そのかわり、タダでは使えない。

**名無しさん＠お腹いっぱい。** · 01/11/08 15:57

>>87
グラフィックやエフェクト表示、表現のことと、ゲームの内部モデルのことは、
切り離して考えたほうが良いでしょう。

「モンスの出現の表現」がいくら凝ってたって、やっぱりクライアントに送る情報は、
モンスが出現したよってだけでしょ？
サーバがエフェクト制御をしたってしょうがない。
クライアントは、(決められた出現エフェクト時間ないなら)いくらでも凝った処理を
すればいい。でもそれはネットワークの負荷とは無関係。

>>80
で、MMOってのは、ゲームに関する「表示」以外の処理は全部サーバでやるのが基本。
だから、サーバの中では全ては同期している(当たり前だが)。
クライアントは、サーバからの情報をもとに表示するだけ。
問題は、同時刻に入力されたプレイヤーの操作が、同時刻にサーバで処理される
わけじゃないことと、サーバで処理された結果が、同時刻にクライアントに表示
されるわけじゃないこと。

バランスを取らないと、プレイヤー間で不公平が起きる
(アクション性が強いものほど)。
でも、「入力→サーバ処理→表示」をきっちり同期させると、
カクカクになっちゃう。
このへんにうまく見せるための技術が必要なんだと思う。
Quake→Quake Worldでどう変わったかとか参考になるかも(古いか)。
(ってことが言いたかったんだったら重複ごめん)

あと、クライアントでゲームの処理(移動やアタリ判定、モンスター出現も)をすると、
セキュリティバイオレーションの元になるので、やっちゃだめだと思う。

81 · 01/11/08 16:07

>80
つまりは、クライアントは入力用のリモコンであり、描画用の
ブラウザでしかない、という感じです。
ただ、サーバ側で無駄な分岐に落ちにくくするために、一応
のメッセージチェックなんぞはしてたりもします。

>96
>「入力→サーバ処理→表示」をきっちり同期させると、
> カクカクになっちゃう。
まさにおっしゃる通りです。
これのどうねじ伏せるか、私もこの話がしたい（笑）
C>S+S>Cこの時間を最小にしつつ、なおかつサーバの処理時間を
無駄にせず、接続可能なクライアント数を最大へ近付ける事は、
可能か否か。もちろん、全クライアントの認識するシーン（状況）
は統一されていなくてはなりません。
無理かな？（笑）

80 · 01/11/08 16:23

＞つまりは、クライアントは入力用のリモコンであり、描画用の
＞ブラウザでしかない、という感じです
その辺は理解してるつもりです。
描画によるタイムラグの対応を考えてただけで。
どっかにクライアント上で処理するとか書いたっけな？（汗）

>「入力→サーバ処理→表示」をきっちり同期させると、
> カクカクになっちゃう。
どんなに最少時間で戻ってきても「待ち」があれば
どうしてもぎこちなくなるので、
敵に攻撃をする例でいくと、
入力してサーバ処理した結果が帰ってくる間に
攻撃のモーション描画をしてごまかすしかないのかなと。
(剣を降り下ろすとか魔法エフェクトとか）

MMORPGでアクションがオーバーなのはその所為もあると思ってるんだけど・・・

＞可能か否か。もちろん、全クライアントの認識するシーン（状況）
＞は統一されていなくてはなりません。
サーバーは入力を受け取ったらまず真っ先に他のクライアントにそれを配信、
当たり判定等を行って、結果を再配信って感じですかね。
完全に統一は非常に難しいような・・・

ゲームに興味無くていいから、通信技術の専門家を引っ張ってきたい所ですね。（笑）

96 · 01/11/08 16:35

>>88 >>97-98
もう少し考察を進めて、本当に同期が必要なのかを考えたほうが
いいのかも。

たとえば、プレイヤーは複数の画面を同時に見ているわけじゃないので、
他のプレイヤーと全く同じ状況が表示されているかどうかってのは、
プレイヤーにとって関係ないことである。
一方で、サーバはそれ自体で閉じていて、内部データも(1台なので)
完全に同期している(当然)。

で、上から、
(1) プレイヤーの画面に反映された他のプレイヤーは、別に自分と
同期している必要はない。
たとえば、他のプレイヤーの行動がたとえ数秒前の入力だとしても、
そいつが自分に関係ないならべつに関係ない。
(2) サーバに入力されたプレイヤーの入力がたとえばらばらな時間に
実際に操作されたものだとしても、サーバは、それを同時刻に行われた
操作として処理しても問題ない。(内部データは破綻しない。)

ということで、別に同期を取る必要はない、
ということになるんじゃないかな。
もしくは、同期を取る対象に優先順位をつけるとか。

つまり、プレイヤー個々の画面で矛盾のない(少ない)がめんが
表示できればいいんじゃないかな？と。
(もちろん不公平が起きてしまう可能性もあるがマクロで見れば、
問題ないと思う)。

96 · 01/11/08 16:38

で、これでもまだ問題があって、
プレイヤーが入力した操作が、サーバ経由でクライアントに届き
反映されるまでのタイムラグがあるってこと。
操作が1秒後に反映されるようじゃ、操作感を大幅に損なうからね。
(Pingが200くらいあってサーバで処理することを考えると、
そのくらいはいくと思う。)

で、適当に考えてみたのは、
クライアントは、プレイヤーの入力をサーバに送りつつ、
実際にはサーバの行う移動処理を仮に行って即時表示し、
他のプレーヤの行動予測も(適当に)おこなって先行表示する必要がある。

いまあるMMORPGは多分ここら辺のレベルじゃないかと思う。
もちろん、上に挙げた個々の方法がどのように実現されているかが、
技術力なんだけども。

と、こういうのは動かな？
こういうの議論する機会ってないので、他人の意見は貴重っす。

超長くてごめん。

**名無しさん＠お腹いっぱい。** · 01/11/08 16:41

１体の敵に複数のプレイヤーが攻撃してるような状況で
＞他のプレイヤーと全く同じ状況が表示されているかどうかってのは、
＞プレイヤーにとって関係ないことである。
は言えないと思う。
まして一人が回復系で誰かのHPが減ったら即回復しなくちゃいけないってような状況の時に
クライアント間で同期が取れてないのはゲームとして大きな欠陥になると思うんだが。

**101** · 01/11/08 16:47

>>100
今の既存のゲームは確かにそんな感じだろうね。
おかげでラグ死する事も多いし。

だからこそ、より正確に同期を取るにはどういった方法があるか、
どういう技術が必要かを考えなきゃいけないってことで。

っていっても、自分でこれっていう方法がすぐに思い付くもんじゃないんだが...

**名無しさん＠お腹いっぱい。** · 01/11/08 16:47

ときにこのスレ、削除依頼が出たままになってますが……。
http://teri.2ch.net/test/read.cgi/saku/1005049593/
いい流れになってるようなので、取り消したほうがいいかも知れません。

**名無しさん＠お腹いっぱい。** · 01/11/08 16:56

いや、ホント面白いですよねー。
このスレの元々の出発を見てましたけど（オンラインゲーム板）
正直言って、描画がどうとか、戦闘システムがどうしたか的な
事よりも、先に議論して解決せねばならないのはこっちの話
ですから。

まったくおっしゃる通りで、全プレイヤーの統一見解である
「事実は１つ、サーバが知っている」わけでして、私が話した事は、
あくまでも見た目に関した話題なのかもしれません。
とはいえ、内輪でテストしてますと、
「あれ、今隣に居なかった？」「あ、今来たよ」なんていう
チャット内会話が発生いしたもので、こりゃ無視もできんぞと思った
次第です。少なくとも、同期の「可能性を探る」？って感じで
よろしいでしょうか？（笑）

先行して描画（見込み描画と自分は呼んでました）一度やってみた
んですが、イエスともノーとも言いにくい感じでしたね。
自己キャラの場合、サーバの最終回答を待つまでもなく、クライアント
側で結果が予測しうる行動（歩行など）があるのでウマイ具合でした
が、問題は他キャラでした。
これもまた、移動などの「その後が予測しうる」行動ならば、まあ
アリかもしれないとは思いますが、予測が外れた際に「オット戻ろう」
的な動作が目立ちました。（意味通じますよね）

全クライアントのC>S S>Cの時間サイクルが、無視できるほど小さい単位
であれば、難しく考える必要はないわけですが、実情ではまだ程遠い
ですからねえ。

こうやって話してると、すごいアイディアが出るのではとひそかに期待。

81 · 01/11/08 16:58

たびたびスマンです。８１です↑

**名無しさん＠お腹いっぱい。** · 01/11/08 17:08

＞「あれ、今隣に居なかった？」「あ、今来たよ」なんていう
＞チャット内会話が発生いしたもので、こりゃ無視もできんぞと思った
あるMMORPGのテストやってるんだが、
こういうのが多くて非常にいらいらするんだわ。

そこのは他のプレイヤーにたいする描画が無いと
他の端末にその情報が配信されない仕組みになっているらしく、
それはそれでコストを下げる方法の一つだと思うんだが、
ただ移動しただけではその情報を配信してないらしい。
いままで横にいたキャラが突然マップの端の敵と戦闘しだしたりしてな。
新しくLOGINしてきたり、そのマップに新たに入ってきた人には、
今までいた人間は魔法を自分にかけたり、敵と戦闘したりと、
描画が発生する行為を行わないと姿が見られない。

確かにコストを下げる方法の１手段ではあるんだが、
やっぱりプレイヤーとしてはこうゆうのは願い下げだな。

**名無し3mm方眼** · 01/11/08 17:26

ラグにより発生した怪現象を本当に怪現象として扱う、
むしろ怪現象をガンガン出していく
（停止したキャラが急にモンスターになるなど）ホラー系MMORPGが
できないかなって考えた事があります。

そもそも自分が見てるものと他人が見てるものが同じかどうか、
人間には分からん、と開き直ることもありだと思うです。

**また長い96** · 01/11/08 17:34

>>104
おぅ。
もう実装されてるわけですね。すごいなぁ。

とりあえず議論の前提をば。
・完全同期は物理的に不可能(光速度の限界(笑)、IP的にも)。
・通信のレイテンシが許容範囲内(数ms～十数ms)になることは多分無い。
→通信インフラはレイテンシよりスループット(帯域)を高める方向で成長してる。
・自分自身の見込み描画は必須(無いとイラつくから)。
こんな感じで良いでしょうかね？
通信インフラについては多分あってると思います。

で、すでに示されてる方法だとどうしてもラグる。
てことで解決の方向性としては、
(1) カクカクでも完全同期。カクカクしてもかまわないようなゲームにする。
(2) ラグって破綻した表示をなんとかごまかすことに全力を注ぐ。

(1)は別なゲームになっちゃうんで、(2)だよなぁと。
これくらいしか思いつかん。
(1)だったらターン制にするという究極の解があるけど。

とりあえずいろいろアイデア。

＞これもまた、移動などの「その後が予測しうる」行動ならば、まあ
＞アリかもしれないとは思いますが、予測が外れた際に「オット戻ろう」
＞的な動作が目立ちました。（意味通じますよね）
外れてもワープさせずに外れた位置から歩かせて復帰させる。
(ひどい時はしょうがないのでワープさせる)。
予測移動の時は、あまり先まで進ませないとか
(サーバから位置情報が来たら急いでそこまで歩かせる)。

戦闘なんかは特に同期が必要なんだけど、相手の行動を見る、
つまり、「自分→サーバ→相手→サーバ→自分」
とかまってたら動考えても間に合わないので、
相手の行動をみて何かするのではなく、相手のステータスを見て(回復とか)
させる。また、戦闘のペースも出来る限り遅くする。
ステータス見るだけなら、「サーバ→自分」なのですばやい判断も可能そう。
ダメージ計算するのはサーバだから、最新情報持ってるのはサーバだしね。
UOなんかこれだよね。

あとは、移動経路を(UOみたいに到着地点をマウスで指定させて)
どこ経由でどこまで行きたいとか指定させて、
方向転換する時は、サーバで同期できた場所から方向転換させる。
(つまり、方向転換したくても、その場ですぐには出来ない。)
って、うまく説明できない。もう少し考えてみます。

とまぁ、こんな感じで、あとは、パラメータ調整で
うまく見せられないでしょうかね?

81 · 01/11/08 17:54

具体的なんでハズカシイですが（笑）、「おっと戻ろう」の際には、
現実で、町中で人とぶつかりそうになった事ありますよね？
そのとき、オットという感じで、後ろに後ずさるような動作で
行ってました。
現在は、納得がいかなくなったので、まったく別のアプローチ
をとってます。（オット戻ろうは捨てました）

実装はですが、一応済んでます。（自分なりの現在の解答で）
人が居ないので、少人数でのテストしか出来ないのですが、
状況の整合性はとれてます。
しかしながら、まだノウハウについての王道的を知らないので、
他ではどういった攻め方をしているのかが興味津々なわけです（笑）

まだ、数百人レベルのテストは行ってないのでどういう結果が出るのか
恐ろしいですが、１クライアントにつきc>sが2～3バイト、
s>cが平均して2～300バイト位でしょうかねえ。
もちろん、後者は新規に視野内へ入ったオブジェクト数で増減します。

**名無しさん＠お腹いっぱい。** · 01/11/08 17:55

概ね賛同。
解決の方向性に
(3) ラグを前提にしたゲームを作成する
を。>>106-107 みたいな奴ね
もっとも実際に107みたいなのを作ろうとしたら、
相当な企画力（世界創造力？）が必要だろうけど。

移動に関してはそんなに問題ならないような気がするな。
MMORPGはどっちに移動するって入力ではなく、
どこそこに移動するって入力がほとんどだろ。
あるクライアントが移動地点を指定した時に、
そのクライアントでは移動を開始するわけだが、
そこへの到着時刻も一緒に鯖に送って、
鯖はその時刻を他のクライアントに送信。
受け取ったほうは指定された時間に着くように描画すれば
到着した時点では同期は取れる。
歩くスピードがちょっと早くなるだけ。
方向転換した時もその時点からの移動でそれ程問題にならないだろ。
転換した場所が厳密に必要な場合は少ないと思う。
（って書いたが、何等かのトラップ等があってその場所を通るとまずいってのが
他のプレイヤーに判ってる場合は「するりと通り抜ける」事になるか）

問題は戦闘時だよなぁ・・・
殴ろうとした敵が既に仲間によって死んでたっとかいうのはどうにかしたいよなぁ。

81 · 01/11/08 17:55

王道的＞王道的方法

**名無しさん＠お腹いっぱい。** · 01/11/08 17:58

>81
移動の指定方法は？
読むかぎりだと移動方向指定に思えるんだが。

96 · 01/11/08 18:08

あと細かいことだけど、ネットワークドライバやライブラリ内の
パケットバッファ長がどのくらいあるのかとか考えたほうがよさそう。
全力で送信してるとキューに送信待ちが一杯溜まって
レイテンシの原因になるから。

送信キューは自分が管理して、キューに溜まっちゃいそうだったら
適当に間引くとかの処理が必要かな?
実は、MMOの場合ラグの問題より通信量の問題のほうが大切かも
とか思ってたり。
クライアントが受け取る量じゃなくて、サーバが送信する量のほうね。

96 · 01/11/08 18:11

>>113
レイテンシ増大の原因になるから。

そうでもないと、隣にいた人がいつのまにかいないとかいう
大きいラグは生まれないように思う。
(1秒で画面の端から端まで歩けるようなスピードだったら別だけど)

**名無しさん＠お腹いっぱい。** · 01/11/08 18:12

とりあえず>>1の関連スレとは関係無いよってことにして、
向こうからの厨房流出を防ごう。

81 · 01/11/08 18:59

ご推察通り、移動方向指定型です。ただし、プレイヤーから見ると、
移動目標指定方式に見えるよう、最終的にはもっていく予定です。
つまり、移動目標座標をクリックすると、そこへ最短で到達しうる
「第一歩目の歩行方向」をクライアントが決定し、サーバへ送る
感じでしょうか。

設計初期には、移動目標を指定し、それ以上のメッセージ
送信は行わない方がローコストであろうと思い、そういう設計で
進めたのですが、上記のようにオブジェクト同士のすり抜けの
問題や、その他の整合性を優先するために、毎サイクル必ず１つ
のメッセージを送る方法をとりました。
（整合性においてはパーフェクトです）
これは一見とても無駄な通信ですが、実はそれほど状況は悪化
しなかったようです。C>Sは、メッセージの大きさが小さいですからね。
（UDPですので、エラーチェックもメッセージキュー的な物も
　自前でゴリゴリ書いてます）

問題は、やはりS>Cでして、サーバ側の回線が「使われていない」時間
があるのが、もっとも無駄だと考えます。
たとえば、ゲームを一定のサイクルで割ったとします。先ほども書きましたが、
１　C>S×人数分
　　↓
２　実質的な処理×人数分
　　↓
３　S>C×人数分
という流れですと「３」の時間のみ、回線がフルに使われるだけで、
残りの時間、回線がヒマな状態になってしまいます。
しかも、全クライアントは、自分から見えない範囲の者たちの
エントリーも待たねばなりません宿命に（笑）
これですと、プレイヤーはボタンを押してから、これらの長い行程を
へて、ようやく画面内が更新されるわけですから、とてつもなく
かったるいですよねー。
しかし、もしプレイヤー人数が少なければどうでしょう？
それならば、かなりあっという間にサーバからの返事が期待できます。

この手のゲームには千人なりのプレイヤーがアクセスする物が多いので、
そうはいかないのように見えますが、実は視野内にいるプレイヤー
は、それほど多くないはずです。これが自分の方法のヒントでした。

81 · 01/11/08 23:15

あれ？　スレが止まってしまった（笑）
私、なんか変な事書いてしまったんだろうか？
もしそうならゴメンなさい。

◆nJ0ZN2yQ · 01/11/08 23:51

どうも、お話の途中に失礼いたします。
削除依頼出した者です。

依頼出した本人が顔を出してどうなるわけでも
ないんですが、何か質問あったら謹んで承ります。

**名無しさん＠お腹いっぱい。** · 01/11/08 23:58

質問
HSPつかってオンラインゲームつくろうとおもうんですがサーバがいわゆるブロードバンド回線
（up128k,down10M)だと何人ぐらい同時参加できますか？
もちろんやり方によってだいぶ変わるでしょうけど。
ウルティマ風のものを考えてます。

◆nJ0ZN2yQ · 01/11/09 00:21

TCPでC/S型のゲームで、かつそれがクライアント側のスペック
という前提なら問題なくいける。

・・・って俺に振ったのかな。ごめんな。

**名無しさん＠お腹いっぱい。** · 01/11/09 00:31

>>120
一応◆nJ0ZN2yQさんに振ったつもりだけどいろんな人の話も聞いてみたかったり。

えーっと個人でゲームつくって自分のパソコンをサーバにしたいです。
up128k,down10Mってのは自分のパソコンのスペックです。
自分のパソコン->インターネット 128k
インターネット ->自分のパソコン 10M

動きの激しいエイジオブエンパイアが８人同時できるのでそれよりは多くできるかなと思ってます。

**名無しさん＠お腹いっぱい。** · 01/11/09 00:32

UP 128kだと大量の接続は不可能
規模にもよるけど、4~5client位じゃない？

**名無しさん＠お腹いっぱい。** · 01/11/09 00:37

なるほどそういえばディアブロがそのくらいですね。
エイジオブエンパイアってディアブロより動いてるキャラクタ多いのに接続人数多いけど
単純に技術力の差？それともＭＭＯＲＰＧのほうが不利な点あるのかな。

◆nJ0ZN2yQ · 01/11/09 00:39

＞TCPでC/S型

これ、TCPと限定したのは特に意味ないです。
単にそれしか組んだことないからであります（アホ

**名無しさん＠お腹いっぱい。** · 01/11/09 01:05

>>124
意味がなくても限定してくれると理解しやすい。

素人考えですまんがサーバをたてるかわりにＩＲＣをつかわせてもらうってのはどう？

**名無しさん＠お腹いっぱい。** · 01/11/09 01:36

>>100

長すぎ

しねぼけ

**名無しさん＠お腹いっぱい。** · 01/11/09 04:30

nバイト/パケット
mパケット/秒
同報クライアントl/ゲーム
n*m*l<16KB=128kbps
あとは適当にバランスとりなよ

**名無しさん＠お腹いっぱい。** · 01/11/09 04:34

うむ。急にレベル下がって気がしてならなひ。

96 · 01/11/09 05:53

>>116
手を動かしていない身としては、もう何も言えることがなくなってしまった。
あとは、小手先で対処するしかないんじゃないかなぁ？
なんか、劇的なアイデアはないですかね？
俺もちょろっと簡単に実装してみるかな。問題点が分かるようになるかも。

>>110
で、またアイデアだけど、
戦闘時のみP2Pみたいにパーティーだけでプレイヤー同士コネクションを張り合って
サーバを経由することによるレイテンシを抑えるってのはどうかな。
つまり、画面に反映させるデータは、
(1) 自分の入力(最速)
(2) パーティープレイヤー直接コネクションからのデータ
(3) サーバ経由のデータ(最遅)
という感じで。
パーティー内だけで、見込み内部処理＋見込み描画を行う感じかな?
まぁ、エンカウント制にするのも一つの解かもしれんが(Enixのがそれだっけ?)。

あー、でも、クライアント同士で動的にコネクション張るのは、NAT環境だと設定しないと無理か。

**名無しさん＠お腹いっぱい。** · 01/11/09 06:13

しつもんー

３Ｄでクライアント作る場合、サーバにはどうやって可視範囲教えるんですかね
２Ｄだと"自分は必ず画面の中心"と仮定すれば、自分の座標送るだけでOKですけど
（いや、送らんでも自動的にわかるか・・・）

まぁ３Ｄもプレイヤーの向きから視界はわりだせますけど、
例えばプレイヤーが壁に直面してる場合、他のプレイヤー見えるわけないんだから
情報やりとりするだけ回線の無駄ですよね？
だからといってサーバ上でプレイヤー毎にＺバッファとか処理してたら
べらぼうなマシンスペック必要そうだし・・・
じゃあクライアント側で処理してから、と思っても、
"そこに他のプレイヤーがいる"って情報受け取ってないと
"そのプレイヤーは走査する必要なし"って判断できないですよね？

EQとかAOとか、３ＤのMMOはプレイしたことないんですが
その辺どうやって処理してるかわかりますか？

**名無しさん＠お腹いっぱい。** · 01/11/09 06:46

>>130
＞情報やりとりするだけ回線の無駄ですよね？
別に無駄でも我慢できる範囲内ならかまわないんじゃないかな。
3Dのやつってマップすごい広いから、視界にはいるやつって2Dのゲームより少ない
ような気がする。

真面目にやるなら(どうしてもキャラクタが直接見えるか検査したいなら)、
BSPとかのアルゴリズムで検査範囲を限定して、その中にいるキャラクタに対して
前に壁があるかどうかを(キャラクタへの線と壁の交差判定するなどして)検査する
って手順が一番単純(でふるい)方法じゃないかな。?

でもこれ、サーバでやる必要ないんだよね。サーバではもっと大雑把でいいと思う。
メタルギアみたいに視界に入ったかどうかをAIが判定するなら別だけど。

**112** · 01/11/09 09:34

８１さんへ
質問しといてすまん。
うちのところ１８時以降はプロキシ制限引っ掛かるんで書き込めないんだ。

なるほどね、メッセージだけは常時流しつづけて置くのか。
しかしそれだと同じ場所に数十人とかいると辛そうだな。
最近はプレイヤーが一ヶ所に溜まる傾向があるみたいだし。

**名無しさん＠お腹いっぱい。** · 01/11/09 10:16

おまえらまずQuakeのコードを読め。

**名無しさん＠お腹いっぱい。** · 01/11/09 11:24

>>133
こいつだけは100年経っても読めないね

**名無しさん＠お腹いっぱい。** · 01/11/09 11:38

>>133
読むならUOX3のほうがいいとおもわれ。とマジレス。
http://uox3.sourceforge.net/

**名無しさん＠お腹いっぱい。** · 01/11/09 12:03

なにこれ？

**名無しさん＠お腹いっぱい。** · 01/11/09 15:24

ソニコンがMMORPGの会社つくってるね。
どうなん？
ttp://village.infoweb.ne.jp/~tsuyozou/prof0110.htm
(10/24の日記参照)

**長文御免８１** · 01/11/09 15:55

>132
ええ、私も最初、そう思ってたんです。
でも、これはC>Sのハナシなんで、例えば視野範囲に何人居ようと実は
関係なくて、常に１サイクルで
（総クライアント数*メッセージ）で済むわけです。これは増減しません。
また、UDPの場合、相手のオンラインのチェックを自前で行うので、
一定のサイクルでのC>Sは欠かせませんので、これにも利用してます。
（一定時間、C>Sが無ければ、そのクライアントは落し、次のプレイヤー
のために、その座席を空席にします。）

やってみた感想では、（結果はまだこれからの実績次第でしょうけど）
やはり大量の情報を流さねばならないのは、
「新規に視野に入ってきた時の最大瞬間風速時」なんですよね。
人種であったり、何を着て、何の武器を持っているか等、外観の
情報を含んだメッセージを送らねばなりません。
しかし、視野に入った後であれば、１オブジェクトの行動は１バイトくらいで
（行動の種類によっては２５６では足りないかな。）
クライアントに現状を通知できます。

方法１
「アナタから見て、～座標にいるクライアントは、今回～をした」
という感じで、既知のオブジェクトを示す座標とその行動コマンドを
１セットとして人数分で送る方法。
視野内の人数が少なければ、総量は小さくなりますが、視野内に大量に
オブジェクトがある場合、座標情報が足を引っ張ります。
＝（座標情報＋行動）*人数
新規で視野に入った際に、固有のＩＤを振っておけば、座標ではなく
＝（ＩＤ＋行動）*人数
と読み替えても良いです。

方法２
オブジェクトの有無を問わず、視野座標すべてを羅列して行動メッセージを
並べて送る。これはとても無駄使いです。誰も居ない座標でも１ボックス
使ってしまいますので。
ただ、良い点が一つだけありまして、視野内のプレイヤー数に関わらず、
つねに情報量が増減しません。
＝（視野範囲数*行動）

方法３
そこでちょっと改良。
羅列されたボックスの内、誰もいない座標は圧縮しちゃいます。
圧縮方法は後で考えるとして、こうする事で、視野内満員を最大数として
人数に応じて、可変的に小さく潰れてくれるメッセージになります。
＝（圧縮された視野範囲数*行動）

にゃ ◆G4ogTrNQ · 01/11/09 16:07

>138

瞬間最大風速をおさえるのに

視野にはいってきた瞬間に大量におくらずに
距離に応じて少しずつおくるのはどう?
表示も不確定部分は不確定に表示すればかえってリアルかも

わかっている範囲でレンダリングする
こんなかんじになるかな

視野にはいったとき:なにかいるというのがわかる
少し近づいた:にんげんらしい。赤い服をきている
もっとちかずく:武器はモーニングスターだ。
さらに近づく:鼻毛がみえる

とかいうぐあいに

はずしてたらごめん

81 · 01/11/09 19:29

>139
曖昧がゆるされる距離、システム、構造（どう呼んだら良いか）であれば、
そういうのもアリかもしれないですねー。
その場合、やはりここまでの距離に入ったら、すべて確定せねばならない
等の条件付け、それを全うする仕組みも必要になりますが。

ようするに、知らずに済む事は、必要になるまでＣに教える必要はないと。
まーこれはゲームのシステムにも依存しますが、そういう感じでしょうかね？

**名無しさん＠お腹いっぱい。** · 01/11/09 21:21

>>137
ソニーはVerantあるのに・・・

81 · 01/11/10 03:23

ウェブサーバソフト（のイージーなヤツ）組んだヒトに、ちょっと
相談してみたら、かなり解決しました。
常に無駄なくサーバのＣＰＵと回線を使うための設計というのは、
ゲームに限らずサーバ系では当たり前の話題だったので、話してて
けっこう頭の中が整理できました。
コレ系の実装やってる方も、お互い頑張りませう。

**名無しさん＠お腹いっぱい。** · 01/11/10 03:31

26 ：名も無き冒険者：01/11/10 03:24 ID:7siwu0/F
別に構わないよ、終わっても。技術話は向こうで出来るから。
正直ゲーム自体が完成するなんて考えてなかっただろ、抜けた人間も
板違いでし辛かった技術話は、向こうでなら遠慮なく名無しで出来る。
ただ一つ言うなら、粘着はネトゲ板内だけにしときなよ＜煽り
向こうのスレで初期にすまじろうネタを書いた人がいるけどさ･･･
故にこのスレの存続をｷﾎﾞﾝﾇ。無くなって向こうに流れてこられても困るYO!
ゲーハー板住人のABCネタやら出川ネタに対抗したいのなら、もう何も言わないよ

･･･34期を名乗った奴、名乗った以上頑張ってネタを維持しろよな。応援するぞ

01/11/10 08:19

おめでとうございます。

とうとう完成しましたね。
早速、私も先ほどプレイしてきました。

　システムの話ばかり出ていたので、グラフィックには
あまりこだわらないのかと思っていたら、すごいじゃないですか！
まずオープニングアニメに度肝を抜かれました。綺麗であるばかり
でなく、短いアニメの中でゲームの世界観がはっきりと伝わって
きました。
　今後追加マップ＆シナリオの予定もあるそうですね。
すごくたのしみにしています。

こういったBBSで集まった仲間でMMORPGができるなんて
夢のようです。
まだ私にはみなさんのような知識も経験もありませんが
努力して何とかついてゆけるようになりたいと決意しました。

次回は是非わたしも微力ながら協力させていただきたいと思って
おります。

**名無しさん＠お腹いっぱい。** · 01/11/10 08:59

142=元スレの26

81 · 01/11/10 12:01

143は私にはサッパリ意味不明ですし、
144の文章も、何を言わんとしているのか分かりませんが、
私はこの板が出来てから、初めて書き込みしたのですが？
（ちゃんと出来んのか？と思いながらロムってました）
元スレで進んでいた？企画とも一切無関係です。
単に、スレの内容として今後多くの人が興味を持つであろう
ノウハウの話ができると思い、会話に参加したのですが。
大切なノウハウを明かさないために、実装の話を出す人が
少ないのか、それとも本当に誰にも経験がないのか、
正直言って判断がつきかねてました。まさか？
例の元スレが気になるなら、どなたかSCについての
スレを新たに立ててはいかが？
作ろう系の人間なのかそうでないのかは、喋ってる
内容読めば、ある程度分かるでしょ。
分かんないならソレでもいいですけど。

**名無しさん＠お腹いっぱい。** · 01/11/10 12:10

>>146
http://game.2ch.net/test/read.cgi/netgame/1005145338/
このスレで煽られたからだけでしょう。
放置するのが吉。

８１ · 01/11/10 12:18

ご指摘いただいて感謝です。>147
こっちが出来てから、向こうはまったく見てなかったので
気が付きませんでした。
ちょっと閉口ぎみのプンプンレスしちゃってゴメンなさい（笑）

**名無しさん＠お腹いっぱい。** · 01/11/10 13:12

マルチキャストって使えないのかなあ？
IPv6の本読んでたら、マルチキャストでマルチプレイヤーゲーム
(本にはシミュレーションと書いてあったよ!)で情報送信するときの
輻輳制御がどうこうとかかいてあって、それに対応するための技術が
IPv6に云々と…。

マルチキャストだとサーバがプレイヤー数ｘプレイヤー数のオーダーの
情報を送信しなくてもいいから、結構大域的に楽になるかも。
プロトコルうまく作れば、サーバレスなMMORPGなんてのもできるかな?

しかし作ったとしても実験できる場所がないというのがなんとも…。