（　´∀｀）ネットゲー作る技術持っている人？ 2

**喫煙者は臭い** · 02/06/01 12:05

（　´∀｀）この板にいるの？
http://www.hayariki.com/
http://game.2ch.net/test/read.cgi/gamedev/1016812752/l50

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

返事どうもありがとうございます。
舌足らずだったようで

>>通信のrecvとsendはマルチスレッド化するのは当然として
>当然なの？
一人通信障害がでただけで全体をとめるわけにはいきませんし……。
WinのAASyncなどを使う方法もありますが、私の足りない知識での判断では現実的ではないかなと
マルチスレッド化が当然とは思われていないようですが、何か良策をお持ちでしょうか。
教えていただければ幸いです。

>>プレイヤー同士のあたり判定や敵の動作は、全てひとつのスレッドでやるべきでしょうか？
>オブジェクト毎にスレッド立ち上げる気？
そうではなく、広大なマップを管理する時、ある程度の大きさのエリアにわけてスレッド処理させるべきかなと
とりあえずPC1台を想定しているので。
ただエリア同士の接点部分で、どうしても同アドレス同時書き込み（読み込み）が起きそうなので相談を。

ひとつの解決策として、RagnarokOnlineのようにエリアの移動をワープにし
「絶対違う部屋同士干渉しない」とする手もありますね
115さんは広大なマップをお持ちですが、どうやっているのか興味のあるところです

**あぼーん** · NG

あぼーん

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

561じゃないけど。

>>562
＞何か良策をお持ちでしょうか
上のほうにこれに関する議論があったよ。
select()を使うとか、ポーリング＋小さいsleep()とか。

＞ただエリア同士の接点部分で、どうしても同アドレス同時書き込み（読み込み）が起きそうなので相談を。
基本的にスレッド間で共有するデータの読み書きをちゃんと排他制御すれば大丈夫だと思うが。
ロックする粒度を考えないとパフォーマンスががた落ちになると思うけどね。

**名前は開発中のものです。** · 02/11/21 19:33

javaつかってるとかいうオチだったりして

**名前は開発中のものです。** · 02/11/21 19:47

なるほど。IDは変化していますが562です。
使っている言語はC。
上のほうの関する議論というのをこれから読んでみます。

＞基本的にスレッド間で共有するデータの読み書きをちゃんと排他制御すれば大丈夫だと思うが。
＞ロックする粒度を考えないとパフォーマンスががた落ちになると思うけどね。
やっぱりここが問題となります。

今の私の方法だと、プレイヤー分recvスレッドをとり、受け取ったデータを蓄えなければいけません。
蓄え場所への、読み込み書き込み場所が、同時に同じ場所にならないようにするためには、
それぞれの場所を表すポインタ。計２個を見る必要があります。
（無限にメモリーを確保できるならまだしも、
（確保したメモリーを使いまわす必要がありますので
（書き込み終了フラグだけというわけにはいきません

最低限このポインタ２つは排他制御しなければなりません
特に読み込み時はその部屋にいる全てのプレイヤーの行動を、蓄えから読み込む必要があります。
途中でrecvスレッドが蓄えに書き込んでる度に、つっかえつっかえするわけにはいかないのですが……

（～ません。など断定していますが、あくまで私の知識内での断定です）

**あぼーん** · NG

あぼーん

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

蓄えってのはただのメモリブロック？
で、メモリブロックへの書き込み用ポインタと読み出しようポインタがあると？
だとすると、そういう蓄えに直接データを書くというモデルが悪そうだな。

とりあえず
蓄え＝「通信データブロック」のリスト(キュー)
として、
recvスレッドは、データブロックを(蓄えとは関係なく)まず作り完成したら
蓄えリストに追加するというように作れば、排他処理するのは「追加する」
という小さい処理だけになる。
同様にたくわえから読むほうも、リストからはずす処理だけ排他処理するようにする。

排他処理内にループが入ってなければ、ロックによるブロックはそんなに
気にならないと思うが、俺もマルチスレッドは初心者だったり。
まぁ、上みたいな粒度が大きいロックでも1CPUでの実行なら効率変わらないんだけどね。

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

というか、エリアごとにスレッドがあり、
境界線上にいるキャラクタが2つのエリアから同時に参照されるときに
どうするのか？ってことを問題にしてるのかと思った。
戦闘時にプレイヤーと敵キャラが別々のエリアにいるときとか、難しそう。
UOとかでもなんか問題起こってたよね(アレはスレッドじゃなくてサーバだが)。

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

>>568
あ、どうも私の文章はわかりづらいようですね。
それでも読んで答えてくださるとは嬉しい限りです。

recvスレッドで、プレイヤーの１動作分蓄えてます
例えば：
[CM_MOVE, 80, 90]　クライアントメッセージ、キャラ移動80の90に
[CM_ATTACK, 105]　105のオブジェクトに攻撃
などです。

一度のrecvで取得できるとは限りませんから、１動作分recvするまでは蓄え（「通信データブロック」のリスト）には書きません
568さんのおっしゃる通りの方法だと思います

ただ、「リストに追加する」「リストから排除する」を、
メインスレッドはプレイヤーの数だけするわけです。
１命令の間のクリティカルセクション入りが小石とはいえ、
1000人だとしたら最大2000回小石につまづく可能性を考えると、大丈夫なのかなぁと
ひとつの部屋に１０００人いること自体問題かもしれませんが…

>>569
はい、それに関しても私が質問しました。
今はこのレスの上記のように「小石」について考えていますが、
RagnarokOnline式を用いない場合「エリア境界線でのデータ受け渡し」という「大石」な問題がでてきますね…。
とりあえず部屋移動はワープという、ragnarok式で作っています。

(´･ω･｀)115さんすごいなぁ…

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

う…蓄えなんていうからわかりづらくなった気が…
今こんな方法でやっております

・recvスレッド
while(1){
・1動作分のデータをローカル変数に保存
・1動作分「プレイヤー行動リスト」にコピー
}

・メインスレッド
while(1){
for(int i = 0; i < player_num; i++){
・プレイヤーiさんの「プレイヤー行動リスト」から、一つローカル変数にコピー
・その行動について検討
・結果を「プレイヤー行動結果リスト」に書き込み（このプレイヤーを視認できる人全員に送る必要あり）
}
}

・sendスレッド
while(1){
・「プレイヤー行動結果リスト」から、一つローカル変数にコピー
・送る
}

・プレイヤー行動リスト
・プレイヤー行動結果リスト
の部分を排他しなければいけないので結構大変かもしれません

特にsendスレッドは、送らなければならないデータが溜まっているかを常に監視する必要があります。
ｸﾘﾃｨｶﾙｾｸｼｮﾝに入ったり出たりと忙しそう…

**115** · 02/11/21 22:31

私の場合はWSAAsyncで処理してます。
サーバ側のゲーム処理は30fps単位でメッセージループから呼び出しているので
同期問題を気にする部分がほとんどなくて楽です。
＃最初はプラットフォーム依存を少なくしようと思ってスレッドで作ってたのですが
＃楽なもんでもう戻れないです...
sendについては、データをメモリに貯めて、
各フレームの最後にまとめて送信、全部送れなかった場合には
バッファが空いたメッセージがきた時点で残りを送信。という感じです。

マップをエリアで分ける、というのは多分
当たり判定を全ての組み合わせでやるのは負荷が高い、
遠くにいる敵キャラ等のメッセージまで送信すると帯域が足りなくなる。
という理由を考えてのことだと思います。
私の場合には距離が近いかどうかを保持してしていて
当たり判定、送受信は近い距離の場合のみ行っています。

距離が近いか遠いかの判定はキャラ数によって負荷が高くなる可能性がありますが、
必ずしもフレーム単位で行う必要があるわけではなので便利です。
このデータはマトリックスと線形リスト両方で持っていて、
処理に便利な方を使う、というようになっています。

一般的なやり方／適切な方法かどうかはわからないのですが...。

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

>>570
＞ただ、「リストに追加する」「リストから排除する」を、
＞メインスレッドはプレイヤーの数だけするわけです。
プレイヤーごとに排他処理をすれば良い。
つまりリストをプレイヤー分よういして、それぞれに対応するmutexを作って
それぞれの追加/取り出ししょりで対応するmutexを使ってロックする。
送信も同じ。

＞特にsendスレッドは、送らなければならないデータが溜まっているかを常に監視する必要があります。
ポーリングしようとしてる？
シグナル等とメインからsendに伝える方法はいくらでもありそうだけど。

＞「エリア境界線でのデータ受け渡し」という「大石」な問題がでてきますね…。
スレッドならデータは共有されてるわけだから、こういう問題は起きないかと。

>>571
というか、どこをクリティカルセクションに仕様としているか示してくれると議論しやすそう。

**560から色々質問してる人** · 02/11/21 23:07

アドバイスありがとうございます。
115さんのやりかたおもしろいですね。
なるほど近いかどうかを「何フレームかに一度」判定して保持しておくわけですか。
たしかにＭＭＯなら毎フレームシビアにする必要ありませんね。ナイスアイデアです。
そして環境依存の話ですが…。>>573さんの話と絡めてします。

>>573さん
もちろんプレイヤー数分クリティカルセクションを持っています
「余談」
　WindowsではMutexよりダントツにクリティカルセクションのほうが速いようです
　ttp://www-6.ibm.com/jp/developerworks/linux/020118/j_l-rt5.html

＞エリア境界線でのデータ受け渡しによる「大石」
ご指摘の通りです。色々考えているうちに混乱したようです。
１つのマシンな限り、問題ないですね

**560から色々質問してる人** · 02/11/21 23:08

＞どこがクリティカルセクション仕様？
・プレイヤー行動リスト
・プレイヤー行動結果リスト
この二つに読み込み、書き込みするのですが、
それが重ならないようには作ってあります。
具体的には
・256行動分プレイヤーコマンドを保存する変数を配列で確保する
・読み込み場所ポインタ、書き込み場所ポインタを用意する
・読み込むたび、書き込むたびにポインタを一つ加算する
・限界まできたらポインタを配列の最初に
・書き込みしてポインタを加算したとき、読み込みポインタと書き込みポインタが一緒だったら１周して追い越した。エラーとして通信遮断
・↑以外の時、読み込みポインタと書き込みポインタの位置が一緒なら、リストにデータは溜まっていないと判断
こうつくってあるので、
「ポインタをローカル変数にコピーする時だけ排他すればOKです」

つまり、
・プレイヤー行動リスト
・プレイヤー行動結果リスト
を読み書きする寸前にちょびっとということになります
＞ポーリングしようとしてる？
＞シグナル等とメインからsendに伝える方法はいくらでもありそうだけど。
シグナルを調べてみたのですが、これは便利ですね。
ただ私が調べた限りlinuxにおいて同等の機能がありません。(´･ω･｀)
115さんもAASync使っていらっしゃるようですが、なるべくならサーバーはLinuxとしたいところ。
（Linuxの勉強をかねているので）

自分自身にソケットでコネクション張って、recvで待たせ、メインからsendで1バイトのデータを送れば信号代わりにできそうですね！
……(´･ω･｀)

**560から色々質問してる人** · 02/11/21 23:14

＞115さんAASyncについて
つまり115さんはスレッドを使ってない。
ちょっとsockについて詳しく調べたわけではないので恐縮ですが、
回線細い人にsendしたり、回線が実は切れてる人にsendすることによって、全体のパフォーマンスが落ちたりはしないのでしょうか
＊「↑この疑問が出た理由」
＊以前AASyncを使ってファイル送受信ツールを作ったことがあります
＊そのさいためしにsendで大きなデータを送ろうとしたら、そのsendで処理がしばらく止まりました（もちろん送れはしました）
＊非同期設定なのにこのsend。送信し終わるまで待つのかな？？　と疑問に思ったのです

関連して、
・sendで時間をとられると、人数が多くなった時にゲームが一定間隔（FPS20とか）で進まなくなるかなぁ
・AASyncの受信メッセージって、ちゃんと偏らず全員からまんべんなくいただけるのかなぁ
という疑問が生じました

質問ばかりですいません。
なるべく実装結果の報告などで情報提供に努めますのでご容赦ください

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

実は俺もスレッド初心者。
ちょっと同じようなことをやってたもんで。

>>575
＞を読み書きする寸前にちょびっとということになります
問題なさそうに見えるけど、それでも問題でるんだろうか？

＞ただ私が調べた限りlinuxにおいて同等の機能がありません。(´･ω･｀)
pthreadつかってるなら、
pthread_sigmask(how, set, oset)
pthread_kill(thread, signal)
がそれ相当かな。
UNIXのシグナルをスレッド毎に使える仕組み。
select(), pause(), read(), write(), recv()とかなら、シグナル受けると
EINTRでブロックが中断される。

pthread_cond_*でもできそうだけど実はよく知らないｗ
LinuxとWindowsネイティブのこともよく知らなかったり…。

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

こっちみたほうが早いかも。

スレッドプログラミング相談室　その２
http://pc3.2ch.net/test/read.cgi/tech/1037636153/
マルチスレッドプログラミング相談室
http://pc3.2ch.net/test/read.cgi/tech/997345868/
pthread地獄
http://pc.2ch.net/test/read.cgi/unix/1010933537/

**560** · 02/11/22 00:54

ioctlsocket関数を使うことで、recvをスレッドする必要がなくなるかもしれません
FIONREADでrecvに溜まっているデータ量を調べて、１行動分あるならrecvでゲット。

>>561さんはこれのことを知っていたので「当然なの？」ときたのかも
早速実装してテストしておきます

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

hoge

**560** · 02/11/24 01:31

( ´Д｀)ﾉｼ　とりあえず鯖側がうまくいったようです
次はクライアントがんばるぞー

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

がんがれ

**560** · 02/11/25 01:22

クライアントも（歩いてしゃべる程度）できたところで、鯖をもうちょっとMMO向けにしたいと思います。
アドバイスなどあればお願いいたします。
・ワールド鯖　　・ログイン鯖　　・ゲームエリア鯖

「ワールド鯖」（世界の数だけ存在する。UOでいう無限鯖、瑞穂鯖などの単位）
世界中に存在するキャラのデータが入っている。
ゲー鯖、ログイン鯖からLANを通して参照される。
いわゆるセーブデータ領域。
起動した時にHDDから全データを読み込む。
（とりあえず単純にtxtに保存するつもりです。いちいちfopenなんぞしてられない）

「ログイン鯖」（１つだけ存在する予定。複数必要なほど頻繁にアクセスはないと思う）
最初にここへ繋いでもらう。IDとパスを管理。
ワールド鯖からログインしたID用のキャラデータをロードする必要がある。
使うキャラ（１ID３キャラくらいいる？）のいるゲー鯖IP:PORTをクライアントに伝えなければいけないし、
キャラセレの時にもキャラデータは見えるべきです。

「ゲームエリア鯖」（ワールド鯖１つにつき複数。多いほど快適ヽ(´Д｀)ノ）
世界を構成するたくさんのエリア。それら一つ一つをつかさどる鯖です。
クライアントは、自分のいるエリアのゲームエリア鯖と通信をする。
敵動かしたり、PC動かしたりするメインの鯖ですね。
PCがエリア内に現れると、ワールド鯖からデータをロードします。
PCがエリアから抜ける（エリア移動orログアウトする）と、ワールド鯖にデータをセーブします

問題はログイン鯖からゲー鯖への移行時…。
いきなりゲー鯖に繋がれて（ﾁｰﾄされて）も、平気なようにするには…
うまくやらないとラグナロクのようにキャラクターチェンジ現象が起こってしまう
何か良い手を思いつかれるかたいませんでしょうか

**名前は開発中のものです。** · 02/11/25 01:38

チケット管理鯖というのを作って、ログイン時にログイン鯖から
認証情報(アカウントID,時刻,IPアドレス)を送っておくというのはどうかな。
クライアントにはチケットIDを送る。

クライアントはゲー鯖に繋ぐと、最初にチケットIDを送る。
ゲー鯖はチケット鯖にチケットを照会して、
正しいアカウント/時刻/IPアドレスであるかを確認する。
一度使ったチケットは破棄される。

チケット鯖はログイン鯖に同居しても構わないと思う。
参考になりましたらどうぞ。

kerberos認証とかをちょっと勉強してみるといいかもしれないよ。

**New Thread** · 02/11/27 08:22

なるほど

**あぼーん** · NG

あぼーん

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

●演技性人格障害

過度に人の注意を引こうとする障害です。自分が注目されていないと楽しさを感じないので、誇張した表現を用いたりします。
自己演技化するような感じですね。

●反社会性人格障害

社会的な規則を平気で無視し、人を傷つけたり衝動的な暴力を振るったりします。
自分にブレーキをかける事ができないので、周りの人も大変迷惑します。

●分裂病型人格障害

親密な関係で突然不快になったり、認知的または知覚的な歪曲行動の奇妙さが伺える障害です。

話も細かい事にこだわりすぎたり、まわりくどかったりします。家族以外には親しい友人がいなかったりもします。
　

**あぼーん** · NG

あぼーん

**560** · 02/11/28 20:40

思っていた以上に大変です(;´Д｀)
通信部やデータ管理部は最低限作ったものの、
例えばキャラのステータス１つ書き換えただけで、全ての鯖とクライアントを書き換えなきゃいけない
うう、めんどい…

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

鯖同士は独立してたりしないの？

**560** · 02/11/29 23:43

もちろん独立していますが、
ステータスが１つ増えた（体力パラメータを追加した）ら、
クライアントはもちろん、ワールド鯖のセーブデータの型も変わりますし、
ゲーム鯖も体力パラメータを実装

ログイン鯖くらいですかね、変えなくても済むのは（iniファイルでパケットの大きさを設定できるようにしておく）

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

XMLとまでは言わないけど、ある程度拡張可能にしてないと
つらいと思うよ・・・

**560** · 02/11/29 23:56

とりあえず、iniファイル使ってアカウントやキャラを管理しているのですが・・・

キャラのステータス部は変更も多そうですし、ひとつのdat扱いにしたほうが良さそうですね
そうすればdat部に変更があっても、そのサイズをiniで指定するだけで済みます
ワールド鯖はdat部の中身には興味ありませんし、login鯖も同様。
変更があってもクライアントとゲー鯖だけで済みますね

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

通信データの取り扱い部分は、全プログラム共通のソースとかじゃないのかな？

**560** · 02/11/30 12:29

全部の機能を備えたものをつくって、INIファイルで動作を変えたほうが楽な気がしてきました
全部の機能とは、ログイン、ゲーム、データベース鯖のことです

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

最初はそこからでいーんでないの

**560** · 02/11/30 16:30

なんとか軌道にのってきました。
そこでまた相談

まずログイン鯖。これは入口として必須。なるべくずっと同じIP:ポートに存在
IDとパスと使うキャラを渡すと、「あなたはこのIP:PORT鯖からスタートです」と、
自分が前ログアウトした鯖のIP:PORTをくれる

これは良いんですが、マップ移動するとき（別のゲーム鯖に繋ぎなおすとき）、
一旦ゲームから切断して、再びログイン鯖に繋げるべきですかね
もちろんクライアントの機能で、自動で同じIDとパスを送信するのですが

・利点
簡単なシステム

・欠点
ログイン鯖にアクセス集中
IDとPASSが何度も何度もネット上を流れる

**560** · 02/11/30 16:37

もしくは、ゲー鯖にIDPASS認証くらいつけるとか

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

>>597
>>584を読んでないんか？

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

パッチ鯖が無い

**560** · 02/11/30 19:50

>>599
いえ、読んだのですがチケットを盗聴されると
そのチケットでゲー鯖に入られるのは必至。
そうなるとID:PASS認証とあまり変わらないかなと

今のところ「どうしても一回Login鯖通れ！」という理由も見つからず、
ゲー鯖でID:PASS認証。ログイン鯖の代わりにキャラメイキング鯖でも置こうか

とか考えていたのですが、やっぱり同アカウント使用管理はログイン鯖かなぁとか
色々苦悩中。
ゲー鯖から別ゲー鯖、ログイン鯖からゲー鯖に接続を移動する時の認証に困ってるわけですが・・・
私が>>584を理解しかねてるのかもしれません

**560** · 02/11/30 20:00

アイデアとしてこんなのを考えたんですけど、どうでしょう
クライアントをC
元居たゲー鯖（ログイン鯖）をX鯖
移動先のゲー鯖をY鯖とします
ワールド鯖（キャラ管理鯖）をWとします

XとCはコネクト中Y鯖への移動することになった
XはWに、そのキャラが移動中であることを伝え、CにはYへ繋ぐよう命令
CはYに繋ぐ
YはCのキャラをWに問い合わせ、移動中であることを確認。Yは移動PASSを作成してWに送る
Wは移動PASSを書き込み、Yに書き込み完了を伝える
YはCに移動PASSを教える
CはXに移動PASSを教える
XはWに問い合わせて正しいことを確認。WはCは移動完了済みと書き込む
XはCに成功と伝え接続を切る
CはYに成功と伝える
YはWに問い合わせて完了済みと確認
やっとY鯖で遊べます

これでどうでしょう。途中移動PASS等を盗聴されてもOKにしたつもりなんですが、
穴があればご指摘願います。
技術持ってる人スレなのに、相談ばかりで申し訳ありません

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

＞一旦ゲームから切断して、再びログイン鯖に繋げるべきですかね
誰が次の鯖IPとポートを教えるかって問題だよね？
全鯖が同じ機能を持っててINIで動作指定してるってなら、どうせ機能共有してるんだし
前にいた鯖が次の鯖を教えてあげればいいと思うんですが。

＞IDとPASSが何度も何度もネット上を流れる
気になるなら公開鍵暗号とか使えば盗聴対策にはなるよ。

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

＞そうなるとID:PASS認証とあまり変わらないかなと
ゲーム鯖はクライアントのIP＋ポート＋チケットで認証すればそんなに問題は起きない。
Webのクッキーが問題になるのは、IP情報をチェックしてないからだね。
Webの場合はProxy切り替えでアクセスごとにIPが変わる可能性があるから。

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

というか、Kerberosのこと調べてないでしょ？
いいURLしらないけど、↓くらいなら雰囲気は分かるかな？
http://www.computerworld.jp/resource/keyword/back/200010sw.html

**560** · 02/11/30 20:54

>>603-604
なるほど。チケットを盗聴したあげくIPまで一緒というのはそうそう無いことですね
同じLAN内の人の仕業？
次のゲー鯖IPを教えるのは各ゲー鯖に機能を持たせます。
あとは暗号化ですね。

>>605
ありがとうございます。
一応何個か調べたのですが専門的なサイトだったようで(;´Д｀)こんな感じに
ご紹介のサイト見てみようと思います

**560** · 02/11/30 21:49

なるほどすごい技術ですねケルベロス。
これならログイン鯖とターゲット鯖との接続がなくても、保証できそうです。

ただ、今回の私のではログイン鯖とターゲットのゲー鯖との間に、
ワールド鯖を介したつながりがあります。
このあたりを考えて>>602を考えたのがいかがだったでしょうか？

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

クライアントが複数のゲー鯖につながらないように管理できてればOKでしょう。
移動パスとかはいらなさげ。

というか、DB鯖(ワールド鯖)が接続管理もやってることに違和感を覚えるんですが。

**560** · 02/12/02 12:02

お世話になっております。
>>608
DB（ワールド）鯖が接続管理をやっているというのとはちょっと考え方が違います。
DB鯖は「プレイヤーがどんなステータスでゲームを終了したか」を保存しますよね。
その「ステータス」の「現在の接続状況」の項目に「鯖移動中」を保存しているのです。

これはログイン鯖やゲー鯖からの「これこれをセーブしてくれ」という命令に基づくもので、
DB鯖はその内容が何を示しているかについては興味を持ちません。
DB鯖は淡々と頼まれたセーブロードを行い、それが完了したら完了通知を返すだけです

>>602の方法は、あるキャラへのSAVEができるのは絶対に１クライアントであるということを利用しています
わかりやすく書きなおすと
・CはXからYのアドレスをもらう
・YはCからキャラ番号をもらう
・CはYからまず重ならないPASS（通し番号でも可ですね）をもらい、Xに伝える
・XはWにPASSの書き込みをお願いする
・YはPASSがちゃんと書き込まれているのを確認

実際は、W鯖への書き込み・読み込み完了通知をちゃんと待ってから次のアクションを起こします

**610** · 02/12/05 06:30

・CはYからXのアドレスをもらう
・WはYからキャラ番号をもらう
・YはCからまず重ならないPASS（通し番号でも可ですね）をもらい、Xに伝える
・WはXにPASSの書き込みをお願いする
・CはPASSがちゃんと書き込まれているのを確認

これで・・・

**610** · 02/12/05 06:32

まぁXとCはコネクト中Y鯖への移動することになったのでXはWにそのキャラが移動中であることを伝えCにはYへ繋ぐよう命令しCはYに繋ぎYはCのキャラをWに問い合わせ移動中であることを確認しYは移動PASSを作成してWに送る
Wは移動PASSを書き込みYに書き込み完了を伝えYはCに移動PASSを教えCはXに移動PASSを教えXはWに問い合わせて正しいことを確認しWはCは移動完了済みと書き込みXはCに成功と伝え接続を切りCはYに成功と伝えYはWに問い合わせて完了済みと確認すればOK。

同じこといってたらｽﾏｿ

**560** · 02/12/05 13:24

そうですね。同じことかと思います。
最も噛み砕いて言うと
Y「おらC。お前キャラ○○なんやて？本当なら今から俺が言う数字を
　　（Cがキャラ○○であると保証済みである）X鯖を通してデータベースに
　書き込んでみーや。それができたら認めたる」

　と言ってるわけですね

嫌煙 · 02/12/09 09:24

なるほど

**あぼーん** · NG

あぼーん

再開 · 02/12/11 08:48

今日、松浦亜弥秋コンサート、ラスト名古屋公演いってきました。
新曲の、草原の人　が聞けました。
あややの楽曲のジャンルに、また新しいのが加えたような感じがしました。
　あややも、この曲の意味を理解し、表現できるまで成長したのですね。
したがって、衣装が若干、変わっていました。
オレンジ色のふさふさのドレスのやつがなくなっていました。

柴田：（手を挙げて）今回柴田がリードボーカルを担当してるんですが、
　　　　　やっぱりね、切ない中にも彼とのね明るい思い出とか
　　　　　そういうのをイメージして歌ったので、
　　　　　そこらへんにも注目してください。
「今回柴田がリードボーカルを担当」って言ってますけど、柴田以外がシングル
でリードボーカルを担当することなんて、あるんだろうか。「柴田がリードボー
カルを担当していない」６月発売の前曲では、ソロパートの６割柴田だったし。
その前は、あー、何だっけ、「♪愛のボタンを連射連射」、その曲では場違いな
黒のスーツ着てラストフレーズ歌ってました、確か。
　ラストフレーズ→ソロパートの６割→リードボーカル。ドンドンドンと来てま
すよ。でも、もうこれ以上はないと思うんですけど。もう普通の４人組です。

**あぼーん** · NG

あぼーん

**bloom** · 02/12/11 09:21

http://www.agemasukudasai.com/bloom/

**560** · 02/12/11 16:15

保守ご苦労様です

私はというと、データセーブのところで悩んでおります
ゲー鯖とデータベース（以下DB）鯖を１本コネクションをはり、これで全部まかなうつもりだったのですが
ゲー鯖から一気に人が落ちた時にsendバッファをオーバーする危険性に気づきました

かといってプレイヤーの数分だけDB鯖とコネクションを張ると、
DB鯖が人数分（個人ではありえないけど10000人分とか）のコネクションを張る必要があります
確か張れるSocketの数には制限があったはず

だいたい、DBとconnectをするとき非同期にしなければならないという問題点もやっかい
セーブデータも全部ゲー鯖が持ってれば、データの呼び出し書き込みのタイムラグ気にせず作れるのにー

**あぼーん** · NG

あぼーん

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

セーブするのはプレイヤーが落ちたときだけなの？
鯖落ちなんかのときに、セーブデータが矛盾しちゃったりしないのかな。

(sendバッファってどこのバッファだろう…？)

**560** · 02/12/13 09:04

おはようございます
sendバッファとは、winsockの送信バッファのことを指しています
コネクションが切れた時に、プレイヤークラスがDBとコネクションを張っているsockに、
自分のデータをsendすればいいかなと思ったのですが、

セーブデータ量×人数＞送信バッファ

の時にめんどうくさいことになるなと
これは、プレイヤーとのコネクションが切れてもプレイヤークラスがデータを保持しつづけ、
DBとのコネクションを張っているデータセーブロードクラスが読みに行ってあげる　と言う方法で決着しそうです
（送信バッファの空きが分かる関数が欲しいですねぇ…。自分でカウントするしかないか…）

**560** · 02/12/13 09:09

失礼。上の
セーブデータ量×人数＞送信バッファ
は、外部とのケーブル切断や経路腐りなどで一斉に人が落ちた場合です。
普段はそうそうありません

セーブはプレイヤーが落ちた時、プレイヤーが別ゲー鯖へ移動（部屋移動）したときにするつもりです
ゲー鯖が強制終了などした場合は、矛盾が生じる場合はおおいにありえますね
・Aさん、Bさんからアイテムをもらう
・Bさん別部屋に移動（データ保存）
・Aさんのいる部屋が強制終了（データセーブされず）
アイテムが消えてしまいますね。逆に増える場合もあるわけで
これに対応する方法はちょっと思いつきません
まさかアイテム移動なり経験値取得なりあるたびにセーブするわけには…

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

＞アイテムが消えてしまいますね。逆に増える場合もあるわけで
＞これに対応する方法はちょっと思いつきません

クリティカルな(アトミックな)操作は、必ずその場で保存するようにする、のがいいのかな？
たとえば、アイテムトレードなんかは、ダイアログボックスが出てたりして、
多少ラグがあってもかまわないわけですよね。
だから、アイテムトレードが成立した時点で、その情報だけは、そのつどDB鯖に送るとか。
(DBで言うトランザクションをちゃんと考えろってことでしょうか。)

アトミックな操作ってのは、システム的に分離できない操作のことね。
AとBのアイテムトレードなら、
・AがBからアイテムIを受け取る
・BがAにアイテムIを渡す
という動作は、分離できない行為で、それぞれが別々のタイミングでセーブされると、
データが矛盾してしまうタイミングが必ず存在してしまいますよね。
経験値やお金なら、1キャラクタの問題だから、矛盾は起きない、と。

って、現行のMMORPGがどういう処理をしているのかは知らないけど、一般論として。

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

サーバー側にトレード仲介人がいて、そいつが担当するのがいいんじゃないかなあ。
双方の意思を確認して、DBへのトランザクションを開始する、と。

ただ、これをやり始めるとあちこちを再設計しなおす必要があったりするんだなあ。

**火星人** · 02/12/18 08:59

WOWOWアナログ超キャンペーン。
http://hedo.mariansela.com/service/shopping/wow/index_wow.html
http://hedo.msweb.jp/service/shopping/wow/index_wow.html
内容は、”デコーダ無償進呈＋アナログ加入料（３０００円）弊社負担”です。
　ＢＳ放送受信環境下にある方々には、毎月の視聴料のみで、ＷＯＷＯＷ視聴できますので、ご勧誘の促進にもお役に立てることを願っております。
　適用期間は、１月２０日記入済み加入申込書弊社到着分までです。

**あぼーん** · NG

あぼーん

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

http://www.real-unreal.com

**あぼーん** · NG

あぼーん

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

いきなりだけど、素人の質問。
PSOとかはローカルにキャラクターデータを保存してるから（なのかな？）
ゲーム中にさえサーバ間移動とか楽にできたじゃん？
だけとラグナロクとかはサーバごとに別キャラクターをつくんなきゃいけない。
サーバ側でキャラクターを管理してて同じキャラクターがサーバを移動するって
のは技術てきに難しいのかな？

**名前は開発中のものです。** · 02/12/19 04:05

>>629
　単に相手がクライアントかサーバーかの違いだけ。

　UOはシャード間の移動はできないけど、シャード自体は複数のサーバーで構成されてる。
　PSOは部屋主をサーバーにしてデータをやりとりしてる。

　要はシステムデザインとしてそういう仕様にするかどうかだけ。

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

MMORPGでサーバ間移動を無制限に許しちゃうと、経済とかアイテムのバランスが崩れちゃうしね。
技術的ではなくそういうゲームデザイン的な理由からそうなってるんだと思うよ。

**629** · 02/12/20 02:04

>>630
なるほど。よくわかったです。
>>631
つまり技術的には問題ないんすね。

どうもありがとうございました。

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 02/12/20 14:31

age

**あぼーん** · NG

あぼーん

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

sage

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

http://eternal.s19.xrea.com/
ここがいしゅつ？
小規模MMOにスレたってたんだが、
製作者はちゃねらっぽい
キャラ絵とBGMがへぼいけどそこそこできてんじゃないのかな

嫌煙 · 03/01/03 11:22

北方水滸伝で感心したのは、食い物の描写。
魯智深の左腕もうまそうだった。
ほかに、阮家三兄弟のきもを溶かし込んだｽｰﾌﾟで煮込む鍋、
朱貴の店の魚肉入り饅頭、祝家荘の野戦料理、解珍の鹿刺。
随所に食べ物と、それを食うｼｰﾝが出てきて、よだれが出てくる。

おれは楽しみにしているＴＶ番組がひとつもなく
単に灯り代わり、あるいは時報代わりにＴＶをつけているだけ。
でもナンシーの文春での連載は楽しく読ませて頂いていた。
今でも腹を抱えて笑った文章を覚えているのだが
キナシノリタケが一般視聴者を業界風イケテル男に鍛えると
六本木に連れだしてイロイロなイケてる遊びを仕込む。
で、遊び仲間を次々連れてくるが
イチローの兄とか、バブルガムブサザーズの痩せている方とか
どう考えても会って嬉しくは無い人がゾロゾロ。
ナンシーさんもそこを衝いていたけど、
番組を見てないおれでも、その情景が浮かんでニンマリしてしまった。

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

お勧めの本はこちら↓
http://atkinson-web.hp.infoseek.co.jp/atkinson/osusume_book_ryouhou.htm
お勧めのソフトはこちら↓
http://atkinson-web.hp.infoseek.co.jp/atkinson/security_soft_ryouhou.htm

**あぼーん** · NG

あぼーん

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

はい？

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

↑誤爆です、ｽﾏｿ。

>>115さんの、
ttp://www.geocities.co.jp/Playtown-Knight/8949/dev/index.html
ttp://robrob.tripod.co.jp/mmo
どちらにもないんですけど終わっちゃったのですか？
9月ごろ遊ばせていただいて、久しぶりにこのスレ見て
どの位ver.upしてるか楽しみにしてたのですけど・・・

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

>>642
http://robrob.tripod.co.jp/mmo/

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

>>642
http://game3.2ch.net/test/read.cgi/mmominor/1036747427/
小規模MMOにもスレできてるぞ

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

age
http://hayari.tripod.co.jp/

**あぼーん** · NG

あぼーん

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

ない！
やるならやれ

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

すっごいやん

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

煽り　荒らし　コピペ荒らし
家ゲー板　家ゲー攻略板　ＰＣゲー攻略板　ゲーハー板潰し
これで・・・・・・
やっと半分ってところだよ・・・・
もうワカったろう
滅茶苦茶にヤラれたンだよ　メチャクチャに
現在ゲーム関連板は、絶望的な状況下を懸命に死と戦っている
今、我々のなすべきこと
それは、専用ブラウザを使い、状況を傍観することか？
俺たちは、教育集団でもなければ宗教団体でもない
俺たちゃよォ・・・・・・・
２ちゃんねらーだッッッッ
戦う団体なんだぜェッッ
荒らしを２ちゃんねる１００の板に配布しろッッ
２ちゃんねらー３００万の手で、必ず探し出せッッ
２ちゃんねらーは、後ろを見せんッッ
ゲーム関連板の無念を晴らすッッ
いいかァ！！！

**あぼーん** · NG

あぼーん

**416** ◆quHoSW/FCI · 03/02/20 13:35

　今、なんとなく考えてるのは、空域(地形)を処理する鯖を中心に、親が接続して、
さらに子が接続。それ、MXやんというツッコミはおいといて、親は戦艦クラスを
指揮して、子は言わば戦闘機な。
　親がネットから切断されると子も巻き込むけど、それはPSOと同じ仕様で、子の
一つが親になることで維持できるようにと。

　主鯖は親鯖の判定に徹して、子同士の判定はそれぞれの親鯖が判定することで、
処理を分散させようかと。

　ゲーム内容は単純。自分の旗本艦を守りつつ、相手の旗本艦を撃墜すればok。
宇宙物にするかWW物にするかは未定。

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

親が、自分の空域から出たら旗艦の指揮権を失う、とどまったら相手の空域まで
行けない、というジレンマを楽しむゲームですか？

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

親同士が戦闘空域に入ったら子は相手の親に繋ぎ替えて攻撃とかすればいいのか？
あー、あれだ。SFでもWWでもなくて、ウイルスモノにすれば良い。
親鯖を守るワクチンや敵鯖をクラックするウィルスを操作する。

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

>>653
Terrariumみたいですな。
あれのAIじゃなくて人が操作するやつ？

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

そだね。ハッカーが電脳世界でなんかやってるｶﾝｼﾞ。
まぁ、設定なんざどうでもいいんだけどさ。

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

>>651
βテスターが必要だったらいつでも協力するんでガンガッテください

**416** ◆quHoSW/FCI · 03/02/22 01:47

>>652
>>653
　親鯖にぶら下がった子の判定は、原則親鯖が処理するってだけの話では
ありますがー。ゲーム上で異なる親鯖の戦闘機が交戦した場合は、

a親←─→b親
↑　　　　　　↑
↓　　　　　　↓
a子　　　　　b子

という繋がりになりますな。

　区域単位で管理して、子であっても未管理区域に進入したら、そいつが親になる
のも面白そう。

　つまりは個人で強力な鯖はなかなか立てれないから、非力な鯖(PC)でも
それなりに動くモノを考えているわけです。

>>655
　ハッカー戦も面白そうなんやけど(攻撃経路が変わってラグ差で負けたとか)、
攻撃方法のビジュアル化がなかなか難しいなぁ。攻殻機動隊2の描写もけっこう
単調になってるし。

>>656
　ありがとー。

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

>>657
そういうことね…。

そうすると、親同士の戦闘が1対1なら問題ないけど、
多対多になると、親同士の通信が問題だね。
ここにP2Pの(ブロードキャスト)ネットワークを使おうってこと？

というか、この方法だとラグが馬鹿でかそう。
リアルタイムには向かんと予想。

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

親Aの子aと親Bの子bのやり取りが面倒臭そう。

**416** ◆quHoSW/FCI · 03/02/24 03:42

　あー、空間単位の処理判定は、「プリテン前銀行(要はユーザーが一ヶ所に
集中したときの負荷)」の問題があったんや。強力な鯖でないと無理やから不採用。

>>658
　親同士の通信量問題は、アプリケーション・プロトコルの低バイト化や圧縮と、
判定処理の頻度を下げる方法があるやね。
　「a子─a親─b子」としたり「a子─b子」にするような経路の短縮化もありだけど、
IPがより多くにさらけ出される状況は、あんまり好かんやろしなぁ。

　ラグは・・・ADSL以上だと平均0.2秒以下(TCP)だったか。56Kが平均0.5秒だから
もっと速かったかな。ラグが大きいときは、判定範囲を広げるのが楽なんだが、
スタートレックみたく、本体判定じゃなくてEフィールドだと判定が広く取れる。

>>659
　全体を見ると
「a子─a親─b親─b子」やけど、実際には
「a親─a子」「a親─b親」「b親─b子」のパターンの組み合わせなんよ。
　ぶっちゃけ、時間軸を無視した独立スレッドにしても可。

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

>>660
＞親同士の通信量問題は、アプリケーション・プロトコルの低バイト化や圧縮と、
そうじゃなくて、同じ場所に親が20サーバくらい集まってきたら？って言う話。
20サーバがそれぞれ他の19サーバと通信するの？

（ ´∀｀）ネットゲー作る技術持っている人？ 2

（　´∀｀）ネットゲー作る技術持っている人？ 2