MMORPG 作成 - 暇つぶし2ch

MMORPG 作成 ..

67:名無しさん＠お腹いっぱい。
01/11/08 01:33
削除されるそうなので続くなら以下でどうぞ。
ｽﾚﾘﾝｸ(netgame板)

68:名無しさん＠お腹いっぱい。
01/11/08 01:38
>>67
迷惑ですので、こちらで引き取ってください

69:名無しさん＠お腹いっぱい。
01/11/08 02:10 PAYRb3Kt
ちょっとソレるけど、ＮＰのモンスターの類い、湧いて出る所を
プレイヤーには見せたくないと思う。
いつ、どこへ、どうスマートに配置する？

70:名無しさん＠お腹いっぱい。
01/11/08 06:29
>>69
木とかの障害物の中。
この前いきなり沸いてきてﾋﾞｸｰﾘしたよ。
すまそ、ただの体験談。

71:名無しさん＠お腹いっぱい。
01/11/08 06:31 PAYRb3Kt
＞７０
そうでしたか。
やはり、死角からニュっと出すのが一般的なんですかねー。
他に方法を御存じの方います？

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

あとはまかせた

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

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

74:名無しさん＠お腹いっぱい。
01/11/08 11:02
>3Dのときはどうしよう?

プレイヤーの背後に出現

75:名無しさん＠お腹いっぱい。
01/11/08 11:48
ワルキューレの冒険みたいに割り切ったヤツのほうが好きだったり。

76:名無しさん＠お腹いっぱい。
01/11/08 12:43
敵の種類にもよるが、
地面の穴から出現とか
空から舞い降りてくるとか
いう表現方法もある

77:名無しさん＠お腹いっぱい。
01/11/08 13:34
なかなか削除されないﾅｰ

78:名無しさん＠お腹いっぱい。
01/11/08 15:03
>>75
煙とともに登場。
古典的かつ自然。
プレイヤーも納得、開発者もニコニコですな。

79:名無しさん＠お腹いっぱい。
01/11/08 15:07 PAYRb3Kt
なんか、削除せんでも良くない？
結構まだノウハウができてない分野だと思うんだよね。
スレを乗っ取った気分で、オンライン系の技術のハナシ続けてみては？

80:名無しさん＠お腹いっぱい。
01/11/08 15:09
C/Sを前提で。基本的な質問ですまん。
敵の発生ってのは鯖が管理するのか？
それともクライアントが発生させたのを鯖に送り
それを他の端末に配信するのか？

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

81:名無しさん＠お腹いっぱい。
01/11/08 15:14 PAYRb3Kt
「～が、ドコソコに出現したよという意味を持った」メッセージを
送る事に、なぜ通信コストが関係あるのかにゃ？（笑）
シーンがどうとか、グラフィックがどうとか、まったく関係ないでしょ

82:名無しさん＠お腹いっぱい。
01/11/08 15:17
>81
確かにそりゃそうだ（ｗ

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

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

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

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

86:名無しさん＠お腹いっぱい。
01/11/08 15:27
正直、ＩＳＤＮ以下の回線を対象からはずしてもいいですか？

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

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

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

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

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

90:名無しさん＠お腹いっぱい。
01/11/08 15:40
どのタイミングで出現しますよ、ってメッセージを送れば良いんじゃないの？
同期の確保されたタイマーを用いて。

91:81
01/11/08 15:41 PAYRb3Kt
失礼、８７って書いちゃった８１ですゴメンナサイ　↑８９のレス

92:名無しさん＠お腹いっぱい。
01/11/08 15:42
UOや最近評判のDAoCでは、
サーバー・クライアント間は完全に同期取れてるのかな？
やっぱりその辺は特許物の技術で公にはされないんだろなぁ

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

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

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

95:名無しさん＠お腹いっぱい。
01/11/08 15:51 PAYRb3Kt
特許がとられていれば、逆に公開されているって事ですね。
そのかわり、タダでは使えない。

96:名無しさん＠お腹いっぱい。
01/11/08 15:57
>>87
グラフィックやエフェクト表示、表現のことと、ゲームの内部モデルのことは、
切り離して考えたほうが良いでしょう。

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

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

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

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

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

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

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

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

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

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

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

99:96
01/11/08 16:35
>>88 >>97-98
もう少し考察を進めて、本当に同期が必要なのかを考えたほうが
いいのかも。

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

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

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

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

100:96
01/11/08 16:38

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

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

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

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

超長くてごめん。

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

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

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

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

103:名無しさん＠お腹いっぱい。
01/11/08 16:47
ときにこのスレ、削除依頼が出たままになってますが……。
ｽﾚﾘﾝｸ(saku板)
いい流れになってるようなので、取り消したほうがいいかも知れません。

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

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

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

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

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

105:81
01/11/08 16:58 PAYRb3Kt
たびたびスマンです。８１です↑

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

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

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

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

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

108:また長い96
01/11/08 17:34
>>104
おぅ。
もう実装されてるわけですね。すごいなぁ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

111:81
01/11/08 17:55 PAYRb3Kt
王道的＞王道的方法

112:名無しさん＠お腹いっぱい。
01/11/08 17:58
>81
移動の指定方法は？
読むかぎりだと移動方向指定に思えるんだが。

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

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

114:96
01/11/08 18:11
>>113
レイテンシ増大の原因になるから。

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

115:名無しさん＠お腹いっぱい。
01/11/08 18:12
とりあえず>>1の関連スレとは関係無いよってことにして、
向こうからの厨房流出を防ごう。

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

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

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

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

117:81
01/11/08 23:15
あれ？　スレが止まってしまった（笑）
私、なんか変な事書いてしまったんだろうか？
もしそうならゴメンなさい。

118: ◆nJ0ZN2yQ
01/11/08 23:51 Vadnjr8h
どうも、お話の途中に失礼いたします。
削除依頼出した者です。

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

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

120: ◆nJ0ZN2yQ
01/11/09 00:21 sv0/eLyU
TCPでC/S型のゲームで、かつそれがクライアント側のスペック
という前提なら問題なくいける。

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

121:名無しさん＠お腹いっぱい。
01/11/09 00:31
>>120
一応◆nJ0ZN2yQさんに振ったつもりだけどいろんな人の話も聞いてみたかったり。

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

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

122:名無しさん＠お腹いっぱい。
01/11/09 00:32
UP 128kだと大量の接続は不可能
規模にもよるけど、4~5client位じゃない？

123:名無しさん＠お腹いっぱい。
01/11/09 00:37
なるほどそういえばディアブロがそのくらいですね。
エイジオブエンパイアってディアブロより動いてるキャラクタ多いのに接続人数多いけど
単純に技術力の差？それともＭＭＯＲＰＧのほうが不利な点あるのかな。

124: ◆nJ0ZN2yQ
01/11/09 00:39
＞TCPでC/S型

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

125:名無しさん＠お腹いっぱい。
01/11/09 01:05
>>124
意味がなくても限定してくれると理解しやすい。

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

126:名無しさん＠お腹いっぱい。
01/11/09 01:36
>>100

長すぎ

しねぼけ

127:名無しさん＠お腹いっぱい。
01/11/09 04:30 dacJo87I
nバイト/パケット
mパケット/秒
同報クライアントl/ゲーム
n*m*l<16KB=128kbps
あとは適当にバランスとりなよ

128:名無しさん＠お腹いっぱい。
01/11/09 04:34
うむ。急にレベル下がって気がしてならなひ。

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

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

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

130:名無しさん＠お腹いっぱい。
01/11/09 06:13
しつもんー

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

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

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

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

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

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

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

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

133:名無しさん＠お腹いっぱい。
01/11/09 10:16 CQSia2MS
おまえらまずQuakeのコードを読め。

134:名無しさん＠お腹いっぱい。
01/11/09 11:24
>>133
こいつだけは100年経っても読めないね

135:名無しさん＠お腹いっぱい。
01/11/09 11:38
>>133
読むならUOX3のほうがいいとおもわれ。とマジレス。
URLﾘﾝｸ(uox3.sourceforge.net)

136:名無しさん＠お腹いっぱい。
01/11/09 12:03
なにこれ？

137:名無しさん＠お腹いっぱい。
01/11/09 15:24
ソニコンがMMORPGの会社つくってるね。
どうなん？
URLﾘﾝｸ(village.infoweb.ne.jp)
(10/24の日記参照)

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

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

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

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

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

139:にゃ ◆G4ogTrNQ
01/11/09 16:07
>138

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

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

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

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

とかいうぐあいに

はずしてたらごめん

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

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

141:名無しさん＠お腹いっぱい。
01/11/09 21:21
>>137
ソニーはVerantあるのに・・・

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

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

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

144:　
01/11/10 08:19 SHEbIHwT
おめでとうございます。

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

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

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

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

145:名無しさん＠お腹いっぱい。
01/11/10 08:59
142=元スレの26

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

147:名無しさん＠お腹いっぱい。
01/11/10 12:10
>>146
ｽﾚﾘﾝｸ(netgame板)
このスレで煽られたからだけでしょう。
放置するのが吉。

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

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

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

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

150: ◆nJ0ZN2yQ
01/11/10 13:40 4D9AJIxk

えーっと、以前にチラっと書き込んだ者です。質問を承ると書いたのですが
どうも意味を勘違いされたようなので、改めて書き込みます。
質問を承ると申し上げたのは、削除依頼を出した事に関する話です。

既にご存知の方も多いでしょうが、削除依頼は撤回されています。
ですが、これが根本的な問題解決にはなっていないということを留意して
いただきたいのであります。

なぜなら、私を含めて削除依頼をする人間というのはただの一般住人ですので、
依頼する場合、その客観性を保つためにはローカルルールに則る以外に方法が
ないからであります。ローカルルールスレにて削除の正当性の主張が相次ぐと
例えそのスレが有意義で素晴らしいものであろうと不利な状況に追い込まれます。
2chの中ではこうした欠陥を抱えたシステムが運用されてるんだという事実だけは
承知しておいてください。

例えば、当スレをローカルルールに機械的に照らせば、削除依頼対象になって
しまうという点を私は今でも強く憂いてます。当スレの元板のスレから流れを追い
常駐煽りの存在にも気付きました。ローカルルールスレにも少なからず干渉が
入っているんじゃないかと思います。

151:名無しさん＠お腹いっぱい。
01/11/10 14:06
>>150
ええと、削除されたらログをどこかにアップして新スレをたてるって姿勢はだめですか？
(推奨されない行為なのは分かってますが。)
話の流れが途切れちゃうのはいやなので。

あと、
＞常駐煽りの存在にも気付きました
>>143-145のことをいってるなら、これは一時的なものだと思いますが？
このスレは、>>70前後から急激に正常化してるとおもってますんで、厨房スレには
そんなに簡単にはならないと思います。
むしろ新たに建てるほうが厨房を呼び込む元になるように思えたり。

152:(補足) ◆nJ0ZN2yQ
01/11/10 14:10 4D9AJIxk
ここ最近のローカルルールスレの中から
幾つかの建設的な意見が見られたので、参考までに載せておきます。

＞210 ：名無しさん＠お腹いっぱい。：01/11/08 18:16 ID:???
＞　MMORPG作成スレは技術話だけで制作は毛頭考えてませんってスタイルにして起てなおしたら？
＞　MMORPG等の制作技術スレとかで。

＞211 ：名無しさん＠お腹いっぱい。：01/11/08 18:18 ID:???
＞　ネットゲー制作総合とかそんな感じ？

＞215 ：名無しさん＠お腹いっぱい。：01/11/08 18:47 ID:73eNO2yb
＞　＞MMORPGの人へ
＞　ローカルルールに則ってもらえれば問題は無いから安心して良い。
＞　だから、210の提案を受け入れることを薦める。
＞　惰性で現在のスレを使い続けるのはたぶん難しいと思うぞ。

153:名無しさん＠お腹いっぱい。
01/11/10 14:10 lDT42030
話題として、大変に興味深いスレッドだと思うのですが、
ローカルルールのスレッドを読みましても、未だ新たに
立て直した方が良いとの声がありますし、どなたか、
やっていただけませんか？
私？私はスレ立てた事ありませんので１には不適格（笑）

154:名無しさん＠お腹いっぱい。
01/11/10 14:19
アサッテで的外れな書き込みを増やさないため、思いっきり
専門的なタイトルにしてみたり。
MMOに限らず、S>C、P2P、通信技術、同期。
正直いって、それ以外のネタはオンライン系でない作業と
共通した話題ですし。
あ、立て直しに１票ってワケではなく、もし立て直すなら、
という意味です。ハイ。

155: ◆nJ0ZN2yQ
01/11/10 14:28 4D9AJIxk
＞>>150
＞ええと、削除されたらログをどこかにアップして新スレをたてるって姿勢はだめですか？

とりあえず削除は撤回しましたので、当座は削除の心配はないでしょう。
私見ですが、この先このスレの削除依頼が出したとしても。削除人さんは
このスレを削除しないように思います。あくまでも私見ですが・・・。

で、もし仮に新スレを立てた場合には、このスレの保全が必要になりますので
ローカルルールスレにも書きましたが、『スレストップ依頼』という方法を
使ってみるといいかもしれません。新たに書き込めなくなるというだけですので
dat落ち後には過去ログ倉庫にきちんと保存されます。
失うものは何もないというわけです。

＞話の流れが途切れちゃうのはいやなので。

同感です。

156: ◆nJ0ZN2yQ
01/11/10 14:40 4D9AJIxk
また、アプリ開発プロジェクトとして当スレを存続させる方法しては
■自主製作ゲーム：開発状況報告スレ■
ｽﾚﾘﾝｸ(gamedev板)

に報告して、住人の支持を取り付けるという方法が有効かもしれません。
アプリの現物が既に存在し、ちゃんとしてるプロジェクトだということを
住人に周知させるわけです。板設立当初のゴタゴタでこのスレが先に立って
しまったという不幸を差し引いても、筋を通せば十分に受け入れられる内容
だと私は思います。　　　　

157:名無しさん＠お腹いっぱい。
01/11/10 14:47
チョットいいですか？
ここって、まだ元スレの「企画系」の人って来てるんですか？
どうも現状が把握できてません。
個人的にはそういうのとは無関係に、早く安心して実のある
議論がしたいです。

158:名無しさん＠お腹いっぱい。
01/11/10 14:53
>>157
どうでしょう？
私は前スレは傍観者立場だったので・・・
たとえ「企画系」の方が来られてるとしても、
このスレでその企画を続ける気は無いのでは。
企画自体は実質上前スレの後半に
消滅してるように思えますので。

159:８１
01/11/10 14:54
元スレのように「ある特定の企画、作ろう系」を引きずって続けるか、
それとも、スッパリ縁を切って、純粋に通信技術の話をコアに
続けるか、皆さんはどっちが良いですか？

民主主義。私は後者に１票。

160: ◆nJ0ZN2yQ
01/11/10 14:58 4D9AJIxk
すみません。訂正。
元板で展開されていたプロジェクトの引越しはローカルルールで
認められてないという点をすっかり忘却してました。
>>156の内容には確証が持てません。申し訳ないです。

161:名無しさん＠お腹いっぱい。
01/11/10 15:23
>>159
通信技術系に限らずもう少し広げてもいいと思うけど、
企画はすっぱり捨てるに1票。

もともと、スレタイトルにも>>1にも企画なんて書いてないし(>>2には書いてあるけど)、
元スレとは切れてるわけだからこのまま続けて問題なさげ。

MMORPG作成技術の「技術」が省略されたというつもりで、続行ｷﾎﾞﾝ

162:161
01/11/10 15:39
>>161
書き忘れた。
ゲームバランスや、世界構築などの話題は、
MMORPGのゲームバランスを考える
ｽﾚﾘﾝｸ(ghard板)
が適当だと思われる。
結構真面目にやってるみたいだし。

最終的には、誰かが、このスレの成果とゲームバランススレの成果をつかって
MMORPG作って開発状況報告スレに逝くのが理想だが、
そんなやつはいないと思われ。

163:名無しさん＠お腹いっぱい。
01/11/10 16:24
統一見解がはっきりすつまで、このスレに書き続けましょうか。

ゲームバランスの話が出ましたけど、これも実はＭＭＯもしくは
オンラインのゲームにおいて重要なテーマだったりしますね。
ここしばらく、開発側は、コンピュター＜＞プレイヤーのバランス
を注意せねばならなかったものが、古き良き時代に戻って、
プレイヤー＜＞プレイヤーのバランスを考えねばならないですから。
バランスに関して、ゲームクリエーターズバイブル？だっけ
にも類似したテーマが取り上げられておりました。

164:名無しさん＠お腹いっぱい。
01/11/10 21:27 3YCQs4do
＞統一見解がはっきりすつまで

　　　　　　　　　　　　　　　　　　　　　　　　すつ

165:名無しさん＠お腹いっぱい。
01/11/10 22:29
はっきりすつまで

166:名無しさん＠お腹いっぱい。
01/11/10 23:36
UDPをサポートしないプロバって、どの位あるんだろうか？

167:名無しさん＠お腹いっぱい。
01/11/11 01:43
プロバイダの設定の問題もある程度あるだろうが、NAT を採用しているような
SOHO や CATV も多いので、それらでも UDP は使えない可能性がある。

CATV やダイアルアップルータはそこそこ利用者があり、無視できない程度の
量ではないかと思うんだが、どうだろうか？

168:名無しさん＠お腹いっぱい。
01/11/11 01:45 WiBbteJU
ＣＡＴＶは無視できないかもしれない、はっきりすつまで断定は出来ない。

はっきりすつまでは断定できない。

はっきりすつまで

すつまで

169:名無しさん＠お腹いっぱい。
01/11/11 02:27
やっぱそうかー。CATVねー。
いまさらTCPに切り替えるわけにもイカンしなー。
ちょっと考えよう。
レスありがとう。>167

170:名無しさん＠お腹いっぱい。
01/11/11 02:33
PSOだって動かないんだから、といって許してもらう。
＞　UDPをサポートしていない所

171:169
01/11/11 05:32
一仕事終えてきました。こんな時間。
そっかー。ＰＳＯも駄目なんですか。そりゃー心強い（笑）

172:170
01/11/11 05:45
PSOダメっていうのは、記憶で書いているので本当に
言い訳に使うなら、確認してね（笑）

確かCITYから先はUDPが使えないとダメだったと思うけど、
誰か、フォロープリーズ。

173:名無しさん＠お腹いっぱい。
01/11/11 12:51 TZbrGtZW
PSOはTCPとUDPと両方つかえるっす
UDPが使えればそっち優先

174:名無しさん＠お腹いっぱい。
01/11/11 22:40 pGntQRjO
うーん。止まったな。上げてみたり。

175:名無しさん＠お腹いっぱい。
01/11/12 00:16
おわったスレ上げてみても・・・

176:名無しさん＠お腹いっぱい。
01/11/12 02:58
以後はこちらへ。
ｽﾚﾘﾝｸ(gamedev板)l50

177:名無しさん＠お腹いっぱい。
01/11/12 15:05
＞１７６
向こうのオンラインソフトって、オンライン配付のソフト、
の意味だろ。ははははは
でもま、この方面に明るいヤツ少ないみたいだし、下がっても
いいか。

178:名無しさん＠お腹いっぱい。
01/11/12 15:29
>>172
PSOはたしか、
・Path MTU Discoveryがうまく働かなくて、
・TCPのmssが大きいままになって、
・サーバからのでっかいパケットがDCに届かなくて、
エラーになってる、ってことだったような記憶。
Path MTU Discovery Blackholeとかいうらしい。
だから、UDPとは関係ないかも。
あと、PSOはUDP使えなくても、TCPだけでゲームできるそうです。

最近の(NAT)ルータは結構賢くて、UDPでも宛先を類推して
フォーワーディングしてくれます。
だから、UDPでも問題無いんじゃないかな。

UDPの欠点は、NAT接続されてるネットワーク内で、一人しかできない
ことじゃないですかね？(コネクションレスだから)
でも、EQとかUDPつかっててもNAT内でマルチクライアントでも出来てるような気がする。
どうやってやってるんだろ?

179:名無しさん＠お腹いっぱい。
01/11/12 20:30
>>177
hahahahaha

180:名無しさん＠お腹いっぱい。
01/11/13 04:30
UDPでもお互いが「アドレスとポート」で共通認識を持っていれば、
NATも通しなのでは？
サーバーが「アドレス共通のポート違い」を別クライアントと扱えばいけるはずだけど。

…でもＥＱ鯖はチート対策で、ポートずらしの技を使うらしい（藁
NAT越しだと、ときどき
　ＥＱ鯖からポートアタック＝クライアントから見るとコネロス、
ってなことが。

181:名無しさん＠お腹いっぱい。
01/11/13 05:56
そもそも、チート可能な設計って、どんなモンすかねえ？（笑）

182:名無しさん＠お腹いっぱい。
01/11/13 08:41
>>180
そっか、最初にTCPコネクションでUDPのポートをネゴっといて、
改めてUDPつなぎにいけば問題ないわけだね(ランダムでもOKか)。
ポートずらしもクライアントが自発的にずらすだけならNATでも問題ないのにね。
というか、NATにやさしくない設計だな。

183:名無しさん＠お腹いっぱい。
01/11/13 19:11
グチりに来ました。
圧縮後の１回の通信サイズが、最大長を超えてしまう可能性が
０ではなくなってしまいました。うーん。
（ほんの微々たる可能性でも無視できないのがツライ）
面倒だけど、これから分割送信、受診後再結合のルーチン
書いてきます。だるい。

184:名無しさん＠お腹いっぱい。
01/11/13 22:55 8OnMgFjd
いったいどうしてこうなっているのかわからないんだがどうせおれはふだんみんなにいわれるようなや
つだったとしてもおれのほんしょうのなかにあるひどいうつとうしいぶぶんがおおきくひどくひとのま
えにねきだしにされててなんだはししかとおもわせるようなきたいっぷりをごひろうさせていることが
おおいんだけどまぁかずおにすればよくわかってくれてたほうでひとによるととてもはんざつにあつか
うこともあってそういうときおれはかいがらのなかをそうぞうしながらああまきがいのようにおくひだ
のえろてぃっくなやつなんだがそういうひわいなにげばしょをとくにつよくいしきするのがつねなんだ
よだってどうかんがえたっておれのげんじつのじんせいのなかでまったくきかいがないようなものだけ
がおれをたいへんにあんしんさせるんだよそれはふつうのひとにだってていどはちがうかもしれないが
だいたいはおなじなんじゃないかな？

次ページ