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/06 21:01

>>15
すまじろう ◆VCNmScuI って付けて見ろよ、カタリｸﾝ（藁

◆dqOqxR1c · 01/11/06 21:19

とりあえずまじめな話しようや

AKAKE memo
| クライアントと接続したままサーバーを終了させるとサーバーの再起動が出来なくなる。
| bind(2) で0未満が返ってきて「: Address already in use」と表示されている。

setsockopt で REUSEADDR を true にしましょう.

| setsocketopt(2)でSO_REUSEADDRを指定することで回避できるという情報をみつけたけて試してみたけど
| 完全には解決できなかった。もしかしたら、失敗する可能性があるときだけ設定するんじゃなくて
| 常に設定する必要があるんだろうか？これはまだ試していない。

いや、「REUSEADDR を true にしていないソケット」に対して bind() しなおせないんだってば。

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

　　　　　　∧ ∧　／￣￣￣￣￣￣￣￣￣￣￣￣￣
～′￣￣( ﾟДﾟ)＜　IDがFFだからレスしといてやる
　UU￣￣　U U　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿

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

>>18
いろんなスレでくり返してるようなので、通報いたしました。

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

MMOってメタルマックスオンラインの略ですか？

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

>>20 萌え

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

>>萌え萌えお姉さんの略

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

つまんねー

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

　　　　　　∧ ∧　／￣￣￣￣￣￣￣￣￣￣￣￣￣
～′￣￣( ﾟДﾟ)＜　逝って良し！
　UU￣￣　U U　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿

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

>>3
ネットワークゲーム、特にMMORPGにおいては、
サーバー・クライアント間の情報送受信や
多数あるクライアント間での情報通信など
通常のローカルのものとは異なる技術が必要となります。
特定のMMORPGを作ると言う事ではなく、作品を作りながら、
それらの技術的な問題点を検討するスレとして
この板でやらしていただくわけにはいかないでしょうか？

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

>>25
一人でやってろ

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

殺伐としてるなぁ

>>26みたいなやる気も能力もセンスも無いやつは放っておいて、
やる気のあるやつで進めましょう矢。製作でも技術的な話出てくるだろ。
いちいち板を分割してやるのはムダ。

ム板に2chブラウザスレとかあるじゃん

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

まあ、ネットワークゲームがらみの技術交換につかってもいいんじゃないの？

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

進めましょう矢。

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

申し訳ありませんが、ここは技術のための板であって
制作のための板ではないのです。
ローカルルール候補でもその方向となっています。
ご理解のほどよろしくお願いします。

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

ピアツーピアとクライアントサーバどっちがいい？
もちろんクライアントサーバといいたいけどそんなに人数抱え込むサーバたてられない。
ピアツーピアにしてもセキュリティがちょっと心配。（同期できるかもわからんし）

マジェスティ風、個人で制作、５０人未満同時プレイでやるにはどっち？

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

ピアツーピアだと、トータルで流れるパケット量が多くなるから、
C/Sモデルがいいよ。

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

http://game.2ch.net/test/read.cgi/gamedev/1005037249/92

◆dqOqxR1c · 01/11/07 20:07

>>30
ローカルルール候補、というかもう張り出されてるローカルルールでは、
議論があって、形ができたらプロジェクト用のスレッドを立てることに
なっている。

ここは >>1 に書いたようなスレッドで議論があり、その結果として立て
られたプロジェクトのためのスレッドなので、そういった面では問題なし。

>>33
あたしが何かやったわけじゃないがα版はアップされてるし、稼動テスト
とかも過去にやってるわけですよ、ここは。

っと、ただの煽り馬鹿にマジレスしてみたり。

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

で、ここの＞＞1はなにができるんだ？
＞＞33の言う通りじゃないのか？

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

>>34
いいや違う。
それは新しい企画で、
かつここの板の雑談スレで議論され認可されたもののみだ。
勝手なことをされては迷惑です。

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

>>34
勝手な解釈ｶｺｲｲ！

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

>>31=>>32

32 · 01/11/07 20:59

>>38
違うけど。

Proxyパターンとか勉強しな。
50人でPeer-to-peerだと、トンデモないことになるよ。
数が増えれば、指数関数的にパケット量が増加する。

2～3が限度でしょ。
Diablo2とかAoCとかもホスト立てるようになってるしね。
コレも一応C/S型

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

>>32=>>39

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

>>40
ヤベェ。ツボに入った。

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

放置で。

32 · 01/11/07 21:39

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

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

>>32=>>39=>>43

32 · 01/11/07 21:55

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

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

>>44
柳の下にはもういない。妻乱。調子に乗るな。

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

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

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

つーか>>1のスレから粘着来てるしウザすぎ
きっとスレ削除されたら落ち込んで自殺するよｗ

32 · 01/11/07 22:05

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

**名無しさん＠お腹いっぱい。** · 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の関連スレとは関係無いよってことにして、
向こうからの厨房流出を防ごう。