IPA フォント

IPA フォント

各所で話題のフリーで再配布も可能な IPA フォントですが、僕も持ってきて少し使ってみました。噂に違わぬハイ・クオリティに驚き。デフォルトフォントとしてもなんの問題もないくらいの品質です。僕の場合は full screen antialias 環境なので、埋め込みビットマップなどは見てないですけど…。

コメント

かぴのすけ (Tue, 20 Jul 2004 22:34:16)

見た。
非漢字の間隔が開いている割に漢字の方は詰まり過ぎに見受けられる。
つーことで字間がちぐはぐな印象を受ける。字形自体は無難な感じ。

ＩＰＡちうとろくでもないイメージしかないわけだが、この手のデータを配信するのはまあ良いことだ。ＩＰＡの公式サイト見てもまったくわからないけどもな。行政法人は万事こんな感じなわけで。シオシオ。

クリエーテブなことがやりたいんならＩＰＡの未踏ソフトウェア開拓プロジェクトにでも個人的に応募すると良かろう。良くないかもしれんけど。

http://www.ipa.go.jp/jinzai/esp/2004mito2/index.html

あとＴＡＬＫＭＡＮは俺も狙っておる。音声認識は例のScanSoftのやつだろう。ドラスピ。
翻訳系はどこのを使うかがちうもくポインツだな。多国語対応つーこって中間言語通す方式なのだろうな。とすると、精度的には緩い可能性も高げ。無論、一概には言えんがね。

Digitune (Wed, 21 Jul 2004 09:06:56)

> つーことで字間がちぐはぐな印象を受ける。字形自体は無難な感じ。

それは君が MS 系のフォントを見慣れすぎてるせいだとおもうなー。英字系がゆったりとした幅で作られてるのは確かだけど、Windows でも Tehoma とかを常用してるとそれほど違和感ないのではないかと思われる。

> あとＴＡＬＫＭＡＮは俺も狙っておる。

こないだのデモは実際には認識してない仕込み風だったな。なので認識率がどのくらいなのかはまるで分からんが、オペサイレベルだとすると結構ギビシー感じ。シチュエーションを絞ることでどの程度認識率を上げられるのかが肝と見た。

かぴのすけ (Wed, 21 Jul 2004 21:01:26)

なつはなついよー。

> MS 系のフォントを見慣れすぎてるせいだとおもうな

ンにゃ。天使のように純粋なココロで評価したのだぞ。
ちなみにTahomaはかなり英数間隔詰まってるわけだが。

> オペサイレベルだとすると結構ギビシー感じ

八王子訛りだとダメとか。
滑舌良くて平均的な声質の人の方が認識率は高いわけで、その辺割と個人差がある。
音響モデルの立て方、ＨＭＭの学習度合い、探索の深さ、構文モデルなど方式的に
似たようなもんでも辞書のリッチさと調整でかなり変わるんで、まあ明日を信じて
待つべし以下次号てとこですな。ちうこと。

Digitune (Wed, 21 Jul 2004 22:01:30)

> ンにゃ。天使のように純粋なココロで評価したのだぞ。
> ちなみにTahomaはかなり英数間隔詰まってるわけだが。

見てるところが違うのかな？幅ではなく間隔？間隔ってなんだ？文字と文字の間のすき間のこと？ちなみに日本語／英字混在文のサンプルでは、日本語と英語の間には全て半角スペースが入ってる (TeX で卒論書いてた時からの癖だ) んだがそれは関係ない？

文字間隔の設定はそんなに変だとは思わないけど。フォントによって文字間隔が変、という話は、つまりバウンディングボックスに対してグリフが異常に小さく書かれている、とかそういうことになるんじゃないかと思うが (バウンティングボックス同士のスペーシングはフォントの問題じゃなくて実際にレンダリングしている OS やアプリケーション側の設定の問題だ)、さすがにそんな変な作りにはなってない。ごく普通だよ。

で、俺が言っていたのはそういう間隔の話じゃなくて文字自体のデザインの話で、MS 系フォントに比べて今回の IPA (実体はどうも TypeBank のフォントらしいが) や Tehoma は英数字の幅を広く取るようにデザインされてる、という話だった。ワードパッドとかで MS Pゴシックと Tehoma で同じ文章を並べてみるとよく分かるよー。

時間があったらこちらでもサンプルを作ってみるよ。

> 八王子訛りだとダメとか。

他にも「〜にょ！」とか言う人はダメとか。

かぴのすけ (Thu, 22 Jul 2004 00:43:23)

ちなみにツネサーバの TCP つながんないぞ。ポート開けてないんじゃないの？

> 間隔ってなんだ？

http://dictionary.goo.ne.jp/search.php?MT=%B4%D6%B3%D6&kind=&mode=0&jn.x=20&jn.y=8

オペレーターズサイドに関する苦情？はざっと目を通してみたが、ゲエム作る側が認識技術を十分理解してないところで作ったんだろうなと感じた。エンジンの使い方が悪いんじゃないのかね。
まあ、昨今の音声認識と言えども期待してると裏切られるレベルではあるがね。

所詮、音素と音素の並びの解釈に終始してる現行方式では性能の方もたかがしれる。

Digitune (Thu, 22 Jul 2004 00:58:27)

> ちなみにツネサーバの TCP つながんないぞ。ポート開けてないんじゃないの？

あれ、そう？ここのところ sarge への移行で頻繁に reboot してるから、起動してないことも多かったけどそのせいじゃなくて？

ちなみに今は起動しています。

>> 間隔ってなんだ？
>
> http://dictionary.goo.ne.jp/search.php?MT=%B4%D6%B3%D6&kind=&mode=0&jn.x=20&jn.y=8

だからそういう意味じゃないことくらいはわかっとろーが。ヌシがどの部分を指して「間隔」と言っているのかが不明、ということだ。文字自体の幅 (これも文字の「間隔」と言えなくもない) なのか、各文字のバウンディングボックス内のマージンなのか、それともバウンディングボックス間のパディングなのか？

うさ (Thu, 22 Jul 2004 19:19:02)

＞他にも「〜にょ！」とか言う人はダメとか。

おれのことかにょ！！（＞＜）

Digitune (Thu, 22 Jul 2004 21:14:22)

違う違う。例の緑の頭の人とそのフォロワのことだよ。
でも実は書いた後に「あ！」って思ったんだけど、うさどんは「〜ぴょん！」じゃん！大丈夫じゃん！って思った。…って、本質的にはおんなじじゃんね。なはは。すまぬ。

かぴのすけ (Thu, 22 Jul 2004 21:54:19)

> そのせいじゃなくて？

ＵＤＰだと動いたから違う。ＴＣＰの場合、サーバとのコネクトからしてうまくいかない。ウチの環境がフィルタってんのかと思ったが、よその15315サーバとはつながるので当局ではツネ家環境側に問題があると断定した。

> どの部分を指して「間隔」と言っているのかが不明

そのような質問であることはわかってるから安心すれ。
字間と書いてあんじゃん。字と字の間。

> 例の緑の頭の人

http://www.shrek2.com/

こいつそんなしゃべり方だったっけ。

Digitune (Thu, 22 Jul 2004 22:29:40)

> サーバとのコネクトからしてうまくいかない。

どううまくいかないのかを書いてくれないと分からないよ。同梱してる TCPTest クライアントでローカルにつなぐ分には普通につながるんだけどね…。NAT の設定がおかしい？でも connect するならそれもなさそうだしなぁ…。

> 字間と書いてあんじゃん。字と字の間。

上でも書いたけど、バウンディングボックスの設定自体はよくできてると思うから、単に字形を見慣れていないだけだと思うんだがなぁ (その後のサンプルを見てどう？)。
文章とした時の各文字のバランスや濃度の均一性なんかもかなりのレベルだし、こんなフォントがただで使えてしまっていいの？という気もしてしまうわけだが…。

Digitune (Fri, 23 Jul 2004 13:09:03)

NAT 設定は出来てたけど、アクセス制御リストに引っかかってパケット叩き落とされてた＞Reflector への TCP 接続。
一応変更してこちらでは動作確認してみたんだが、これでどうだろう？

かぴのすけ (Fri, 23 Jul 2004 21:57:21)

> どううまくいかないのかを書いてくれないと分からないよ。同梱してる TCPTest ク
> ライアントでローカルにつなぐ分には普通につながるんだけどね…。NAT の設定がお
> かしい？でも connect するならそれもなさそうだしなぁ…。

> 一応変更してこちらでは動作確認してみたんだが、これでどうだろう？

どううまくいかないのかて、コネクトできんと書いてあるやんけ。

今度はちゃんと接続できたぞ。クライアントの方はこれからデバグしてかないと
動かないようだがな。やる気ないんでローカルサーバデバグとかはしてない。

なんでやる気ひくーなのかというと、ツネサーバがデータの同期すらしないので
クラでやることが増えまくってコードの変更点がバリバリ起こっておるから。

ゲムーで使うサーバなら最低限同期化機能は必要だろー。

Digitune (Sat, 24 Jul 2004 08:21:30)

「コネクトからして」を「コネクトしてから」と誤読しとった。紛らわしーっつの！しかしそれでもあいまい過ぎだ。エンジニアなら「SYN を送っても SYN/ACK が戻ってこない」とか、最低でも「一切パケットが戻ってこない」くらいは書くべし。そんなんじゃ技術系 ML に投稿出来ないぞ(笑。

> ゲムーで使うサーバなら最低限同期化機能は必要だろー。

また謎用語を。同期化機能、って何さ？ブロードキャスト／マルチキャストは出来るし、パケットのサーバへの到着順／クライアントへの配送順に関しては厳密に守られているはずだが、それでは機能不足なのか？

Digitune (Sat, 24 Jul 2004 09:15:47)

> パケットのサーバへの到着順／クライアントへの配送順に関しては厳密に守られているはず

嘘だった。ブロードキャストでは保証されない (同じパケットを受け取ることになっている二つのクライアントが順序逆にパケットを受け取る可能性がある、ということ)、マルチキャストでは、クライアント側が宛先リストの順番を厳密に守っている時 (つまり、あるクライアントは 0,1 という宛先リストを使いつつ、別のクライアントが 1,0 といった宛先リストを使わない限り、ということ。常に昇順などと決めていれば大丈夫) のみ保証される。

Digitune (Sat, 24 Jul 2004 09:25:15)

もしかして同期化機能とは、サーバ側に同期ストレージがあってそれへの set/get をクライアントが行う、みたいなことがしたい、ってことか？
ルーム名の時の議論と同じだがそれはレイヤーが違うんだよなー。今回のはあくまでも Reflector であって Server じゃないし…。基本的には peer to peer (server なし) で動作するように作られたクライアントを、NAT を含む Internet 環境でも動作させられるようにするための仕組みだからして。C/S モデルはもう古い、と。

Digitune (Sat, 24 Jul 2004 09:52:52)

つまり、クライアントの挙動としては
1) LAN 上で peer を探す
2) Reflector 上で peer を探す
というような動作になっているとグーで、かつ LAN 上、Reflector 上の peer を上位層では意識せずに扱えるような構造になっているとなおよい。
以前書いたように、サーバ的な動作をさせたいのであれば別途作ってあらかじめチャネルに参加させておけばいい、ってのはそゆこと。LAN の時は自然にそうしてるでしょ？

かぴのすけ (Sat, 24 Jul 2004 17:57:20)

またムキになっていろいろゆってるなー。まあ落ち着きたまえ。

> 紛らわしーっつの！

エンジニャーなら適当にゆってもすらっと読み取れやー。実際ちょっと調べれば
分かったろ。

> 同期化機能、って何さ？

読んで字の如くだべ。言葉自体はあいまいだが文脈でわかろう。

> ルーム名の時の議論と同じだがそれはレイヤーが違うんだよなー。今回のはあくまでも
> Reflector であって Server じゃないし…。基本的には peer to peer (server なし)
> で動作するように作られたクライアントを、NAT を含む Internet 環境でも動作させら
> れるようにするための仕組みだからして。C/S モデルはもう古い、と。

> 以前書いたように、サーバ的な動作をさせたいのであれば別途作ってあらかじめチャネル
> に参加させておけばいい、ってのはそゆこと。LAN の時は自然にそうしてるでしょ？

なんか意味なしトークだな。一言で言えばクラに大部分任せた仕様っつーことで。
今さらスタンスの説明する必要はないぞ。こう作らなきゃいかんてもんでもないし。

リフサバをただのロビーサーバもどきと割り切ってもいいがね。としてもＴＣＰでも
３０秒ぶっち仕様は意味なくね？。

まあとにかくクラを作る側からしたらいろいろ不親切さが目に付く感じがあるな。
リアルタイムなゲークラをあんま作ったことがないのだろう。

Digitune (Sat, 24 Jul 2004 23:09:36)

> エンジニャーなら適当にゆってもすらっと読み取れやー。

何様じゃ(笑。

> 実際ちょっと調べれば分かったろ。

「ちょっと調べる」ための環境を作るのがめんどいんだよ。自分ち以外に Internet にさらりと出ていける環境、ってのはあんまりないので。

> 言葉自体はあいまいだが文脈でわかろう。

わからなすぎる。少しは説明しようとしやがれってんだ。俺ばっかいろいろ言っててバカみたいじゃないか。で、俺の解釈で合ってるの？合ってないの？それすら書かない、ってのは不誠実この上ないぞ。

> なんか意味なしトークだな。一言で言えばクラに大部分任せた仕様っつーことで。
> 今さらスタンスの説明する必要はないぞ。こう作らなきゃいかんてもんでもないし。

Reflector を使うならこう作らなきゃいかんのだよ。つーか作れ。
ごく普通のネットゲーのようにサーバ側をある程度ヘビーに作り込む、ってやり方は、技術的にも面白くないし、大体スケールが資本力に直結してしまって面白くない。ここでやるようなゲリラ的ゲームならば、「中央サーバなんかイラネーんだよゴルア！ビッグブラザーか？あ？」ぐらいの反社会性がなくてはイカン。で、そうはいっても現行のネット環境においてはどうしてもサバ的存在が必要な面、ってのはあるから、現実に対する最小限の妥協として Reflector が存在するのじゃ (そういう意味では、究極的には全クライアントが必要に応じて Reflector となれるような設計とすべし)。基本は p2p。全て草の根。これ以外認めぬ。

> リフサバをただのロビーサーバもどきと割り切ってもいいがね。としてもＴＣＰでも
> ３０秒ぶっち仕様は意味なくね？。

だからだな、ロビーサーバと Reflector はレイヤーが違うといっておろーが。そこんところを理解してないんだとすると今までの話が「意味なしトーク」だというのも頷けるな。意味がないんじゃなくてオヌシが理解出来とらんだけじゃ。

ちなみに TCP でもブッチ仕様、ってのはネットワーク機器的にはごくフツー (巷の NAT box を経由して TCP コネクションはってしばらく放置してみ。大抵の製品ではエントリ消去されていきなり通信不能になるから)。Reflector っは本来 Layer3 とかその辺に存在すべきものなんで、これで OK。たとえ Reflector が Timeout させなくても、途中の NAT box からエントリが消えてしまえば同じことだし。

> まあとにかくクラを作る側からしたらいろいろ不親切さが目に付く感じがあるな。
> リアルタイムなゲークラをあんま作ったことがないのだろう。

既存ゲームのパクりサーバを作りたいわけじゃなかろう。どうせ作るなら全世界に展開可能なくらいのゲークラを作りやがれってんだ。

かぴのすけ (Sun, 25 Jul 2004 20:32:10)

今日はツネサーバ対応クラをちとこってりとテスト。
動くこたー動くんだがなかなか安定しないな。まあ、焼酎飲みつつかなり
てれてれやってるというのもあるが。

通信遅延がすげーあるぞとか言う割には割とスイスイ動いてる。
ちなみに毎秒３０回ぐらいでキー操作を同期して動くブツ。

> 何様じゃ(笑。

それをゆっちゃおしめーよ。

> 「ちょっと調べる」ための環境を作るのがめんどいんだよ。自分ち以外に
> Internet にさらりと出ていける環境、ってのはあんまりないので。

まーそーだろーと思った。bitWarp 加入しれ。

> わからなすぎる。

ンにゃ。解釈は割とニアピンだからわかってなくないぞ。やればできるじゃん。

> Reflector を使うならこう作らなきゃいかんのだよ。

なんでリフサバを基準にしてんだよ。クラ＆サバどっちも含めて一元論的でなく
ても良かろうというこった。

> 基本は p2p。全て草の根。これ以外認めぬ

こうしてバカの壁ができていくわけか・・。
ちなみにバカ壁は読んでみた。かなりつまらん。パラノイアどもがコミュニケ
を大幅に阻害することは太古の昔から当たり前の話なんで。

別にＰ２Ｐでもいいが、そんなもんどーでもいいよ。通信はただの手段であって
目的ではないからな。通信メソッドに重み付け１００％の人はそうでないんだ
ろうが。俺ゃア通信はまったく専門外だし。

> ロビーサーバと Reflector はレイヤーが違う

その話とは関係ない。ロビーもどきとゆっておる。わからなくなるほどの高度な
トークでもねえだろ。

そういうのは今のとこそっちの妄想上システムで、どこのレイヤでも何でもロ
ビーサーバを用意してから言いたまえと。別にそんなもん他にあまりない作り
で作ったとしても何ら偉くもないし。意味なし。

あとネット機器のキープアライブ時間はいいとして、リフサバごときが勝手にや
んじゃねえと思った。時間短いし。ハートビートるのは簡単だが。

> 既存ゲームのパクりサーバを作りたいわけじゃなかろう。どうせ作るなら全世界に
> 展開可能なくらいのゲークラを作りやがれってんだ。

サーバごときは別に全然パクりでいーんだけども。そんな血眼になってやる
もんでもないし。カイレラサーバそのままでもいーんだが、どうかね？。

http://www.kaillera.com/

人の作ったのはなんか作りがうざそうだから自前で作ろうとか思ったんだよね。

問題は完全にゲークラなんだよな。一応、リフサバ対応でプロトコルを隠蔽化した
汎用クライアントエンジンは作ったが。

ゲークラ作りやがれつーんならお手本になんか作って見せてくれ＞ツネちょん

つーわけでシクヨロー。

Digitune (Mon, 26 Jul 2004 08:28:44)

> 別にＰ２Ｐでもいいが、そんなもんどーでもいいよ。通信はただの手段であって
> 目的ではないからな。通信メソッドに重み付け１００％の人はそうでないんだ
> ろうが。俺ゃア通信はまったく専門外だし。

しかし例えば手書き認識にしたって、「ユーザの書き順を学習する」部分に腐れたアルゴリズムが使われてて、使っているうちにレスポンスが急速に悪化する、とかゆーのは非常にダサいわけだ。ネトゲだとしたら「参加者が増えても大丈夫」なことを目指して作ろうとするのは当り前の話ではないのか？「そもそも参加者は高々二人じゃ」というのであれば余計なことを考える必要はないのかもしれないが…。

> そういうのは今のとこそっちの妄想上システムで、どこのレイヤでも何でもロ
> ビーサーバを用意してから言いたまえと。別にそんなもん他にあまりない作り
> で作ったとしても何ら偉くもないし。意味なし。

当初からさんざん言及してる IP Messenger はそういう意味ではロビー的だ。あちらは物理的なネットワークセグメントがルームとして見えるわけだが、Reflector でもまったくチャネル上で同じモデルを作れる。つーかそれを念頭に置いていたわけだ。

IP Messenger は非常に単純なんだがそのわりには良く動くんだよね。

> あとネット機器のキープアライブ時間はいいとして、リフサバごときが勝手にや
> んじゃねえと思った。時間短いし。ハートビートるのは簡単だが。

結局アプリケーションレベルで面倒みないことには切られちゃうのは間違いないんだよ。ネット機器はその辺面倒見てくれないんで。簡単ならいーじゃん。

> カイレラサーバそのままでもいーんだが、どうかね？。

おお。こういうモノがあるのか。「Kaillera enables emulators to play on the Internet.」といってるあたり微妙に怪しゲ。うざそうというのは同意。プログラム的なもんもそうだけど、ライセンス的な問題とかこいつを動かしとくと腐れエミュラー達が大挙して押し寄せてくるようなことになりそうで嫌だ。

> ゲークラ作りやがれつーんならお手本になんか作って見せてくれ＞ツネちょん

ヤダ。暇がない。

かぴのすけ (Mon, 26 Jul 2004 21:56:41)

話題のハバネロカレーを食ってみた。そこそこ辛いさ。
ホット！ホット！

>「参加者が増えても大丈夫」なことを目指して作ろうとする
> のは当り前の話ではないのか？

場合によるな。喩えは意味不明。
ＸＰなんかの基本思想でもあるが「起きてない問題については考えない」
つーのも一つのやり方だ。問題が見えてきてから考えると。

最初から小奇麗にしようとするあまり、ない問題に極度に怯え、木を見て
森を見ず、パラノイアチックな作りに陥ってしまうプロジェクトも数多あ
る。童話世界の倫理に反するが、将来より良いより今より良い方がいいだ
ろう。

まあサーバ環境を提供するのはそっちだからできるだけ負荷を下げたい
とゆーのであれば意味があるので、できるだけそのように取り計らおう。

> 簡単ならいーじゃん。

ソースデバグしててちょっとブレークポイント見てる隙に接続が勝手に切れ
ることが多かったのでちょっとブチ切れたんだよ。勝手に切るような制限を
あまりいろんな層でやるのは意味ないしな。低レベル層から生じる以外の
制約はできるだけ減らすべきなんだろ？。

ちなみにゲークラエンジンは安定したぞＴＣＰ版。キー入力でｎ人対戦する
類のゲムーなら汎用。割とサクサク動く。３０秒ぐらいでゲロるようなくだ
らんポリゲーを作りたい。一般配布する気はさらさらなし。

> うざそうというのは同意。

まーネット関連はやってることがクリアでないと危険度高いからな。
カイレラがエミュをネット対応にできるとゆーのはフレームとキー入力を
同期させる方式でネット対応をまったく考えてないゲームも簡単に対応化
できるから。

ふつーにローカル用に作ったゲエムまでネットで楽しめるというのはなかな
かに面白いチックだ。入力部およびフレーム更新タイミングを完全に仮想化
し、いかなるゲムーもネット対応、とかゲムー専用機もやればいーじゃん。

> ヤダ。暇がない。

貧乏金なし、か。
得体の知れない本読むの減らして作ればいーじゃん。ヒマよりネタが
ないんだろーけども。

Digitune (Tue, 27 Jul 2004 00:34:04)

> ＸＰなんかの基本思想でもあるが「起きてない問題については考えない」
> つーのも一つのやり方だ。問題が見えてきてから考えると。

言いたいことは分かるけど、それも程度問題だよな。問題の具体的な詳細までは見えてなくても、「こっちに進むことは明らか」というような状況なら、少なくともそちらへの展開がしやすいような解法を選択しておくことは間違いじゃない (たとえ話もそういうことが言いたかったわけだ。その時点 (ちょろっとしたテスト時とか) では具体的な問題とまでならなくても、使い続けているうちにそちらへ進むことが明らかなら、きちんと受け止められる構造になっているべきだし、少なくとも受け止めるよう修正しやすいような形にしておきたい、と)。もちろん、途中で方向転換を余儀なくされることも往々にしてあるだろうから、過剰に進むべきではないけれど…。

> 勝手に切るような制限を
> あまりいろんな層でやるのは意味ないしな。低レベル層から生じる以外の
> 制約はできるだけ減らすべきなんだろ？。

ま〜ね。このへんこそリソース的な問題が大きいなぁ。

> ちなみにゲークラエンジンは安定したぞＴＣＰ版。キー入力でｎ人対戦する
> 類のゲムーなら汎用。割とサクサク動く。３０秒ぐらいでゲロるようなくだ
> らんポリゲーを作りたい。

おおナイス。こちらもいまさらだが channel 0 に client 0 という形で常駐する同期ストレージを組み込んでみた。使い方の説明を書く時間がないんだが、かぴのすけならソース読めば使い方も分かるだろう (いつものページからダウンロード出来る zip の中にはいっとる)。今のところボリューム的なリミットを用意してないんであんまりデータを突っ込みすぎないように。

30分くらいで作ってほとんどテストしてないんで、こないだのようなアホなバグがある可能性大。

> 得体の知れない本読むの減らして作ればいーじゃん。

本を読んでいるのは通勤電車の中なので、その時間をプログラミングに転嫁するのは非常に難しい。昔のように必ず座れる状況じゃないし、自分のマシンは自宅で Web Server やってるしね。

> ヒマよりネタがないんだろーけども。

それが正解かも。自分で作りたいゲーム、ってあんまりないんだよね。

かぴのすけ (Tue, 27 Jul 2004 22:54:00)

> 程度問題だよな

当然だろ。
喩えの件は例えば製品化とかいうレベルでは最低限当たり前の話だが、とりあえず実験とか言う場合は必ずしもバウンダリ付ける必要もない。競合学習などもっと本質的な問題があるからな。近いうちの製品化を狙っているなど目に見えた目的があればその時点での問題にはバウンダリなども当然含まれるから結局「ない問題に対処」してるわけではない。まあバウンダリなんぞは最初から付けるのが当然だけどもな。

リフサバの場合は当初の要求仕様たる「メンバ間でリアルタイムに３２ビット値を同期させる」というのとそもそも異なる。設計が多階層でも単階層でも要求を満たせばＯＫだが、リフサバだけでは要求を十分には満たせない。いわば汎用のＤＰマッチングだけ作って認識全般に使えますと言ってるようなもんだ。汎用Ｂ木エンジン作って後レーヤー足せばＤＢシステムになりますと言ってるようなものだ。

あと同期化自体は重くない（むしろ軽い）し、処理も単純だ。レーヤーを重ねると複雑化してスループットも落ちる。最初はそうじゃなかった気もするが、Ｐ２Ｐ指向だっつーんならまーそれも良かろう。が、Ｐ２Ｐ指向だとサーバはまったくつまんないブツに成り下がるな。

別段、サーバ作れともリフサバでは対応ゲーム作れないともゆってないんで大した問題でもないんだが比較的クラが作りづれーよと。

カイレラでも良くあるが、この手のキー入力とフレームを同期化させる類のシステムは、ラグナロみたいに後でキャラワープで合わせるとかいう技が一切使えないので、メンバ間で進み方がずれたまま進むという現象が起こる。

つーわけでＵＤＰで安定して同期できるＰ２Ｐクラ作るのはいろいろと考慮する点が増えて面倒だが、やり方は既にまるっとお見通しだ。しばし待て。

> 同期ストレージを組み込んでみた

見た。汎用ハッシュ表サーバじゃんけ。つまんね。
チャネル０に参加しないと使えないしな。よそのチャネルにもアクセス可能にしてくれ。
あとこのようにサブサーバぶらさげていくとかえって重かろう。専用にガチガチ組み込んだ方がかりぃよ。ジャバだからクラスバイナリ置くと勝手に機能が増えるとかしれ。

このハッシュ表サーバを使ってゲムー作るとするといくつか問題があるな。
・フレームの更新に必要な分の入力が揃った時点でクラにデータを配布する機能が必要。なぜなら揃ったということを即時に判断できるのはサーバだけであり、クラが自分から見に行くのはレスポンス的に良くないから。
・間にリフサバ通すからさらに遅延

まあツネちょんにはいろんな意味で難しいっぽいことがわかってきたから無理して作らなくてもいーぞ。

> その時間をプログラミングに転嫁するのは非常に難しい

脳内で作るんだよ。

Digitune (Wed, 28 Jul 2004 00:15:22)

> 「メンバ間でリアルタイムに３２ビット値を同期させる」というのとそもそも異なる。

そうかなぁ。最初から UDP ブロードキャストするのが一番軽いんじゃないかと思ってるんだが、それじゃダメな理由を教えてくれると助かる。

// そのために Reflector は Internet 上に仮想的なブロードキャストドメイン
// を作るための仕組みなわけで。

> が、Ｐ２Ｐ指向だとサーバはまったくつまんないブツに成り下がるな。

最初からそういってたでしょ。Reflector はゲームサーバじゃないんだよ。

> この手のキー入力とフレームを同期化させる類のシステムは、

つーかこういう仕組みって一般的なの？ゲーム側が 30fps でドライブされてるとして許容される delay が 33ms、これって Internet ではほとんど期待できないレベルのレイテンシだと思うけど…。LAN なら良いけどね。

Internet 上なら 400ms くらいまでの遅延は許容出来るように作らないとダメポじゃないの？ちなみに PIAFS とかだとこのくらいのレイテンシはフツーだぞ。AirH" はどうだ？

> 見た。汎用ハッシュ表サーバじゃんけ。つまんね。

期待してたのはこういうもんじゃないのか。

> あとこのようにサブサーバぶらさげていくとかえって重かろう。

モノリシックカーネル vs マイクロカーネルみたいなもんだな。つーかこういう機能は本来クライアント側が用意すべきものなんだよ。LAN でサーバレスだったら当然そうするでしょ。

> まあツネちょんにはいろんな意味で難しいっぽいことがわかってきたから無理して作らなくてもいーぞ。

失礼な奴だなぁ。確かにこのへんの話はまったくの門外漢だが (キー入力をネット経由でフレーム単位で同期させる、なんてランボーなことをしているとはつゆほども思わなかった。コンシューマサービスとして展開出来る設計じゃないと思うんだが…)、知ってるなら教えてくれてもいーじゃんか。

かぴのすけ (Wed, 28 Jul 2004 21:10:57)

> UDP ブロードキャストするのが一番軽いんじゃないかと

それでダメってこたーないぞ。軽いのはそーだろーし。
ブロキャスよりはどっかで一旦まとめた方が都合がいーんで、そうするとリフサバみたいなもんを通さないでＰ２Ｐの方が都合がいいな。

> 最初からそういってたでしょ。Reflector はゲームサーバじゃないんだよ

だから最初からつまらんとゆっていたわけで。

> これって Internet ではほとんど期待できないレベルのレイテンシだと思うけど…。

なんなら試してみるかね？。夜１０時メセンジャ集合でどうか。
各自ブロキャスでなく、どこかで一旦入力データを束ねると一番遅いやつに合わせて動くよーになる。この場合、遅延はあんまり問題でなく、どっちかというと平均転送速度の方が問題。キーデータなんかたかが知れてるのでダイヤルアップの類でもたぶん問題なく動く。

フレームとキーは完全に同期させるわけじゃなく、ある程度フレームは見込みで泳がす。１００フレのゲームでも１／３０キー入力でほとんど問題ない。１／１５でもいいぐらいだ。

> LAN でサーバレスだったら当然そうするでしょ

それでもどっちかがホストっぽい立場になった方が都合が良いな。まとめ役が必要ってこった。ＭＭＯでどっちがアイテム取ったかとかどっちがとどめさしたか、とかのジャッジ役が必要なのと似たよーなもん。

> 失礼な奴だなぁ。確かにこのへんの話はまったくの門外漢だが

> 知ってるなら教えてくれてもいーじゃんか。

フッフフフフ。
つーか、どーもなんかわかってないっぽいぞこいつというのもなくはないが、ヒマがないとゆっていたので十分な作成時間がなかろうと思って無理しなさんなとゆっておる。短時間ではへぼいものしかできないしな。

前ーにカピサーバとクラのソースを出した気がしたのであれで謎がすべて解けていたものとして話を進めていた。ソースは一応見てたみたいだったし。

カイレラだと一つのサーバでだいたい２０〜３０ぐらいのグループを賄うような運用形態が多くみられるので、確かに商用としてはかなり歩留まりが悪い方だろう。商用ならメンバの引き合せだけして後はＰ２Ｐとすべきなのに異論はない。

カピサーバはＴＣＰ使ってる以外は偶然にもカイレラと同じ仕組みらしい。以下、公式サイトより勝手に一部抜粋。より詳細は公式ペエジを隅々まで読んでみてくれたまえ。ってことで。

----------------------
Peer-to-Peer games do not usually send every single piece of data to each computer. Obviously, that would be too much data to send consistently, and quite a waste of time. So instead, they do something like what Kaillera does, send tiny updates.

In essence, Kaillera just sends keystrokes. The server you connect to is the host. NOT whoever makes the room for the game. Every key you press while playing is sent to the server you connect to and it then routes it back to you and to everyone else. Again, it does not matter who hosts a game, the playing experience on a single server will be the pretty much the same unless one player reconnects to their ISP.

When you press a key while in Kaillera, as stated above, it is sent to the server and sent to everyone else:


- Player 1
/
Server - Player 2
|
- Player 3
---------------------------------------------

Digitune (Thu, 29 Jul 2004 01:38:54)

> 各自ブロキャスでなく、どこかで一旦入力データを束ねると一番遅いやつに合わせて動くよーになる。この場合、遅延はあんまり問題でなく、どっちかというと平均転送速度の方が問題。キーデータなんかたかが知れてるのでダイヤルアップの類でもたぶん問題なく動く。

パケット落ちを考えなければ、各自ブロードキャストだろうとどこかで入力データ束ねようと同じなのではないのかね。全員分の１ターン分の入力が揃ったらそれぞれが勝手に 1tick 進めれば良いのだから。p2p で UDP ブロードキャスト or TCP コネクションをメッシュで張ってもいいし、Reflector を TCP モードで使えばパケット落ちを無視出来るから、結局ゲームサーバなんかいらん、ということにならないか？

> フレームとキーは完全に同期させるわけじゃなく、ある程度フレームは見込みで泳がす。１００フレのゲームでも１／３０キー入力でほとんど問題ない。１／１５でもいいぐらいだ。

つまり、一つのゲームに参加している人のキー入力を誰かがまとめて、全部揃った時点で１ターン分としてみんなに配信、これを可能なかぎり速く行えばいちおう同期が取られた形で全てのゲークラが動作可能、って理解であってる？。いちおうそういうことで話を進める。

しかしたとえそうしたとしてもパケット到着時刻は結局まちまちだから、あんまり無分別に「見込みで泳が」しちゃうと各ゲークラ毎にゲーム展開がまったく違う、という展開にもなりかねない (あるアイテムを別の人が取っちゃったりだとか)。パケット到着 (ブロードキャストの場合は全ゲークラのパケット到着) をトリガにしてゲーム自体を駆動出来れば一番楽だけど、そうするとネットワーク環境がリッチな場合とプアな場合でゲームの進行速度に差が出てしまう。

「何フレーム毎に入力トリガ待ち」というのを環境に合わせて適応可変にする、というのが一つの解だけど、そんなゲーム性の根幹が変化してしまうような変位性を許可しても良いものなのかどうか。なかなか微妙な気がするけど…。

// 始めからかなりプアな環境に合わせて作っておけば (例えば入力は
// 1/5 sec 毎にしか見ない、とか)、少なくとも変化はしないか。ひど
// く操作性の悪いゲームになりそうだけど…。

> それでもどっちかがホストっぽい立場になった方が都合が良いな。まとめ役が必要ってこった。ＭＭＯでどっちがアイテム取ったかとかどっちがとどめさしたか、とかのジャッジ役が必要なのと似たよーなもん。

単一のゲーム世界を共有する以上、そこになんらかの絶対的な基準が必要なのは言うまでもないけど、それが必ずしも「計算機」である必要はないんじゃないの？例えば「ゲーム内絶対時間」のようなものを基準にすれば (時刻合わせは IP Messenger の Entry 処理のように「OK？」「OK！」というメッセージをいっとう最初にゲークラ同士でやりとりすればよい)、入力データをトリガに各ゲークラがそれぞれでまったく同じ世界を構築出来る (GT のリプレイ画面みたいなもん。あれはゲーム中のデータを全て記憶しているわけではなく、tick 単位でのプレイヤー、COM カーの入力データだけを元にして全て再計算して表示していることは有名だよな。または RDBMS のクラスタリングなんかを連想されたし)。MMO が中央サーバを必要とするのは、そこにゲークラにとって未知の同期化されたデータ (例えばサーバ側にしか存在しないアクティビティであるところのモンスター、NPC などの存在) があるからであって、そういったものがない or あらかじめゲークラ側に分配可能なのであれば、本質的には必要ないんだよ。

// モンスターにしたところで完全に決定論的なロジックで
// 動いているのであれば各ゲークラに分散、tick ドリブン
// で動かすことは可能だよね。

> 前ーにカピサーバとクラのソースを出した気がしたのであれで謎がすべて解けていたものとして話を進めていた。

そういう意味では、かぴのすけの考えるカピサーバと Reflector の本質的な差異、って奴が分かっていないんだと思うよ。どうも俺にはそんなに違いがあるとは思えないんだよね。というわけで、いったい何が本質的な差異だと思っているのかを説明してくれるととてもすっきりするんだが…。頼むよ一つ。

> Kaillera の説明文

これってまさに Reflector そのもののようにも思える。

かぴのすけ (Thu, 29 Jul 2004 21:50:18)

タイフーが近づいてるから手短にいくぞ。
詳しくは盆休みにでも話したらー。

> 各自ブロードキャストだろうとどこかで入力データ束ねようと同じなのではないのかね。

似てるが、違う。ホスト役があった方が都合が良い、とゆっておる。ホスト
なしでもそれなりに動作はするだろう。現に今のリフサバ対応版クラはそれなり
に動作している。ＢＣで動くこたー動くだろというならその通り。まったく
違わないというなら違う。

> 結局ゲームサーバなんかいらん、ということにならないか？

ゲームサーバをいらなくできないとはまったくゆったことねえぞ。あった方がクラが
作りやすいっつってるわけだ。

> って理解であってる？。

そこだけ見れば間違いではない。

> あんまり無分別に「見込みで泳が」しちゃうと各ゲークラ毎にゲーム展開が
> まったく違う、という展開にもなりかねない

無分別はダメだろ。萌えるゴミと萌えないゴミぐらいには分けないとな。

> なかなか微妙な気がするけど…。

現にそのようにして快適に動いてるわけだが。
もちろんローカル動作とガチで比べると格段に違うが、単体で見る分にはさほど気にならない。そういうところは人間気にしなきゃほとんど気にならないものらしい。

> 本質的には必要ないんだよ。

場合によるな。結果が同じになりさえすればいい、あるいは通信が理想的に小奇麗に進んでいる、とゆーんであれば必要ない。

> そんなに違いがあるとは思えないんだよね

本質的とかそーいうとこだけならそんなには違わないな。都合の問題だべ。

> 何が本質的な差異だと思っているのかを説明してくれるととてもすっきり
> するんだが…。頼むよ一つ。

うーむ。めんどくせーな。
要するに通信の遅すぎるやつと速すぎるやつがいるってのはこの手のもんの最大のネックで、その辺の問題が束ねるとすっきりなんだよ。そゆこと。

> これってまさに Reflector そのもののようにも思える。

カイレラはトラヒックの増大を気にして作られてるらしーので、来たのをいちいちＢＣるんじゃなくて束ねてるよ。かなりカピサーバに近い。

かぴのすけ (Thu, 29 Jul 2004 22:15:09)

そーいやー今のところの対応クライアントを上げておこーかー。

http://www.h4.dion.ne.jp/~kapisan/viw.lzh
http://www.h4.dion.ne.jp/~kapisan/columns2.lzh

む。しまった。カピサバ版に上書きしちった。
ま、いーか。

Digitune (Fri, 30 Jul 2004 00:14:10)

む、連続コメントは俺の専売特許ではなかったか。

> 要するに通信の遅すぎるやつと速すぎるやつがいるってのはこの手のもんの最大のネックで、その辺の問題が束ねるとすっきりなんだよ。そゆこと。

かぴのいう「束ねるとすっきりする」は、正確には「誰か一人が束ねるとすっきりする」なわけだけど、やっぱり良く分からん。全員が束ねちゃってもいいじゃん、と思うんだよね。通信も片道ですむし。

> 来たのをいちいちＢＣるんじゃなくて束ねてるよ。

全ゲークラが１つの LAN に存在する場合を考えると、いったんサーバで束ねるようにしてしまうとクライアント数 n + 1 のパケットが流れるが、各ゲークラが自分でブロードキャストを拾うようにすれば n だけで済む。この場合はトラフィック的にもサーバなんかないほうがネットワークに優しい。

今の Internet でネットワークが分散してる場合はいったん束ねることに意味もあると思うけど、本来 Multicast で各ゲークラ同士に送り合えばいい、LAN では実際にそういう形で作れるものを、Internet に拡張するためだけにプロトコルチェンジする (しかも専用サーバが必要になる) のは微妙にダサい。現状 Internet 対応する場合は SoftEther みたいな仮想ブリッジを使って各ローカルネットをまとめちゃう、って方が面白いと俺は思い、Reflector はそういった方向での超いい加減な実装なわけだな。

// ちなみに IPv6 なら Internet 上だとしてもマルチキャストモデルが
// 組めるから、トラフィック優しさ的にも楽勝。未来を見ようぜ、ベイベー。
// グローバルマルチキャストがマジで使えるかどうかは微妙な気もするがな。

本来、Reflector の登場シーンってそれほど多くないはずで、たまたま全ゲークラが NAT 下にいる場合だけなんだよね。それ以外なら p2p で通信すればいいし、一つのゲームグループ内の p2p で通信できない組み合わせの経路は他のゲークラに relay してもらえばいい。そこはある種トランスポート層的にゲームプロトコルとは独立して作って、ゲーム側は LAN 同様、全クライアントを p2p で通信可能、というのを前提に作るのが良いと思うんだが…。

// UPnP も結構普及してきて p2p で通信出来ない局面はだんだん減ってきてるらしーぞ。
// そういう意味じゃ、ゲークラも UPnP 対応くらいはデフォルトってことで。

マッチング機能とか不特定多数のクライアントで同期データ共有したい場合 (MMO なんかもこれの一種と言える) はまた別だけどね。Internet でマッチングするには特定の計算機 or システム (それこそ Reflector とか DynamicDNS とか) を経由するしかない。これは本質的にしょうがなし。そうゆー意味で、Reflector の典型的な利用方法としては次のような形を想定しておった (前にも書いたっけ？)。

0. UPnP セットアップが必要ならしとく。
1. Reflector に接続し、Hello をブロードキャスト。新規ゲームグループをマッチング。
2. 相手ゲークラのネットワーク情報を GET。直接通信可能かどうかを確認 (例えば直にパケットを投げてみる)。
3. 直接通信出来る奴らとは直接通信する。ダメな奴は誰かが relay 出来ないかネゴ。それでもダメなら Reflector 経由。
4. アプリ側からは完全に p2p モデルで通信。

このくらいはやっても罰は当たらないと思うんだがなぁ。

Digitune (Fri, 30 Jul 2004 00:14:58)

あいかわらずなげーコメントなんで、もしめんどくさければお盆集会時でもヨロシ。
いい加減長くなってきたからね。

かぴのすけ (Fri, 30 Jul 2004 21:52:32)

たいふーふいた

> む、連続コメントは俺の専売特許ではなかったか。

クラの感想も書きたまえよな。

> やっぱり良く分からん。

わかればいーじゃん。

> 各ゲークラが自分でブロードキャストを拾うようにすれば n だけで済む。
> トラフィック的にもサーバなんかないほうがネットワークに優しい。

サーバでまとめると２ｎで、各クラがＢＣしたらｎ＾２だろ。

> 今の Internet で　〜

> 〜 デフォルトってことで。

この辺のトークはイタタだな。わかってないところでいくら力説しても無駄ちゃん。ぴろーん。

> このくらいはやっても罰は当たらないと思うんだがなぁ。

サーバ負荷を踏まえれば確かに最終的にはＰ２Ｐが良かろう。手っ取り早く動かすには面倒だが。が、ちみの想像してるビューと違ってホスト役は立てる。安定性が決定的に異なるからしてな。

通信経路をネゴるとかなんとかまでやるのはさすがに商用システムとかでやれっつー感じ。なんならやって見せてくれ。ＣＰＰで。クラエンジン作ったらゲエム本体は提供したらー。

あと書き込み後に変なメセージ出るよ。ここ。

Digitune (Sat, 31 Jul 2004 01:49:08)

32件目ー。

> クラの感想も書きたまえよな。

これ Windows 用じゃん。実行環境整えるのがめんどくさいんだよ…。

> サーバでまとめると２ｎで、各クラがＢＣしたらｎ＾２だろ。

おいおい。ツッコミどころを間違えてるぞ。かぴのすべきだった正しいツッコミは、「どうして LAN なんだ YO!」であって、上のようなけんとー違いのものではないだろう。

かぴの言うオーダーは本当のマルチキャスト／ブロードキャストのものではなくて、各クライアントがユニキャストでそれらをエミュレートした場合の値だな。まぁ今の Reflector 実装はそうなっているわけだけど、だからこそわざわざ「LAN なら〜」と断っておる。しっかり読むように。

> この辺のトークはイタタだな。わかってないところでいくら力説しても無駄ちゃん。ぴろーん。

だからさ、俺が分かってないのは既定路線としていいから、それを前提にして議論せいよ。人格批判やメタ議論に逃げるのはあまり性格良いとは言えんな。で結局何が分かってないと言いたいのよ？

> サーバ負荷を踏まえれば確かに最終的にはＰ２Ｐが良かろう。

サーバ負荷というよりも、現在の Internet においてはトラフィックが局所化するのが一番まずいわけだ。そういう意味で、別に趣味の問題とかチャレンジングとかそういうこと抜きにしても極力分散処理させられるよう考えとく必要がある。

> 安定性が決定的に異なるからしてな。

かぴの言う「安定性」ってのが何を指すのかが不明なんだよなぁ。本質的には必要のない SPOF を生むことの方がよっぽどシステムとしての「安定性」を損なうとも言えるわけだが…。

> 通信経路をネゴるとかなんとかまでやるのはさすがに商用システムとかでやれっつー感じ。

まぁメンドーなら別に良いけどね。俺は逆に結構面白い課題かなぁと思ったんで。

> あと書き込み後に変なメセージ出るよ。ここ。

7/22 に書いたでしょ。あんまりちゃんと追求してないが、どうも現行の tDiary が ruby1.6 をターゲットプラットフォームにしてるせいのような気がする。こないだ sarge に上げたタイミングで、我が家 PC の ruby は 1.8.1 になっちゃったからねー。1.6 に戻せばいいんだけどそれはそれで微妙にやな感じ。

Digitune (Sat, 31 Jul 2004 04:37:01)

プレーしてみたぞ。ねみー。

viw は起動できんかった。D3D がうまくないんだってさ。

columns は動いた。でも同じマシンで同時起動するしかないのでゲームにはならんかった。
それは置いておくとして、ゲーム内容に対して通信量がちと多すぎるような気もした。これはかぴが上で書いていたようなアプローチならば致し方なしか。PSBB でコナミが「対戦ぱずるだま」のネットバージョンをテストしてたんだけど、これはもう少し通信量が少なかったような気がする。こっちはまた別の方法を使っていたのかもしれん (このゲームは p2p 対戦だった藻様。NAT 下にいるクライアントは特定のポートを空けない限りゲーム主催者側にはなれなかった。誰かが主催したゲームに参加することは可能)。

かぴのようなアプローチで、かつ p2p でなくいったんサーバで受けて、というやり方では、たとえサーバ側で一度束ねたとしてもトラフィック的にかなり厳しいんじゃなかろうか、という感触だがどう思う？まぁ知合いだけ高々数人で遊ぶ分には困らないだろうけど…。

かぴのすけ (Sun, 01 Aug 2004 02:44:47)

> 正しいツッコミは、「どうして LAN なんだ YO!」

LAN＝ＢＣプロトコルＯＫではないだろＹＯ。「ＢＣプロトコル使った場合〜」と書くべき。
ＬＡＮとかいうキーワードはかぴさんフィルタで自動カット。意味通んねーし。

> 人格批判やメタ議論に逃げるのはあまり性格良いとは言えんな。
> で結局何が分かってないと言いたいのよ？

別に人格批判とメタ議論のどっちでもないじゃん。

分かってない点に関しては７／２９レスで、

「要するに通信の遅すぎるやつと速すぎるやつがいるってのはこの手のもんの最大のネックで、その辺の問題が束ねるとすっきりなんだよ。そゆこと。」

と完璧に答えておる。

にもかかわらず「束ねなくてもいんじゃね？」という内容のトークを長々してるので長々と根拠並べてもダメですよとゆーておる。まあよっぽどうまいことプロトコルを工夫して処理すれば束ねなくても良くなるかもしれんけども、その巧い方法を示すにも至っていない。

ゲークラを作ったことがあればそんなに難しい話でもないんだが、経験ないと分かりづらいかもしれんなー。

と書くと、分からないところが気になってまた長文レスするのだろーが、そういう細かい話は直で言うから時を待つべしだ。紙とペン持って集合。

> 極力分散処理させられるよう考えとく必要がある

ガチガチに考えれば、だな。程度問題。

> 俺は逆に結構面白い課題かなぁと思ったんで。

じゃあ作るってことでー。決定ー。

> プレーしてみたぞ。ねみー。

報告ごくろーさん。つーか、すごい時刻だな。

> D3D がうまくないんだってさ。

特に機能は使ってないんだが、DX9 ランタイムのインストールが必要なのだ。
ウインドーズアプデートで入るはず。

> ゲーム内容に対して通信量がちと多すぎるような気もした

ネットワークに優しくとか一切考えて作ってないからな。ポイントはネット対応化を長簡単に行うところにある。

ウチはコラムスもどきごときはローカル同時起動でもサクサク動いてたよ。
通信量をもっと劇的に減らす方法もあるが、こっちはまだ試してない。

> トラフィック的にかなり厳しいんじゃなかろうか

そいつはレスポンス的にと言うことかね。ＴＣＰでやってるのがそもそもアレなんだが。

Digitune (Sun, 01 Aug 2004 11:55:58)

> LAN＝ＢＣプロトコルＯＫではないだろＹＯ。「ＢＣプロトコル使った場合〜」と書くべき。

その辺は「各ゲークラが自分でブロードキャストを拾う場合うんぬん」あたりで察して欲しかったんだがな。

> 完璧に答えておる。

俺もある状況下においては束ねることの有用性を認めてただろう。でそこから、そういう状況そのものの普遍性や、将来に渡っての位置付けを議論していたわけだ。現状既にリアルに稼働してるネトゲでも、中央集権的サーバを必要とするものは意外に少ないんだよ。それこそ MMO くらい。簡単な MO や VS ならほとんど p2p でやっている。ただそのせいで (対戦ぱずるだまでもそうだったけど) 結局エンドユーザが NAT を意識しないといけない状況ってのがまだ残ってたりして、そういうダサい部分を救うのが Reflector なわけ。トランスポート的状況はサービスとしてはエンドユーザから隠すべき。

> まあよっぽどうまいことプロトコルを工夫して処理すれば束ねなくても良くなるかもしれんけども、

そんな対した工夫はいらないと思うけどね。上でも書いたけど、

・各ゲークラが全ゲークラのパケット到着をチェック
・到着次第イベント発生

でいいじゃん、と。(当然通信部だけは別 thread で動いていることが前提だ YO！。別に単一 thread でうまくやるんでもいいけど)。ここで、「あるターン用のパケットかどうか (ロスト／スキップの検知)」は、なんらかの絶対的な基準がいる、それはゲーム内絶対時間のようなものを使うんじゃないか、と書いたわけ。

> 分からないところが気になってまた長文レスするのだろーが、そういう細かい話は直で言うから時を待つべしだ。紙とペン持って集合。

すでに書いちゃったよ。楽しみにしてるぜ…って、実はお盆の週は会社なんだよね。夜から集合になっちゃうけど許してちょんまげだ。

> DX9 ランタイムのインストールが必要なのだ。 ウインドーズアプデートで入るはず。

DX9 ランタイムは入ってるけど、ビデオボードが NeoMagic だからなー。

> ネットワークに優しくとか一切考えて作ってないからな。ポイントはネット対応化を長簡単に行うところにある。

うむ。双方のタイミングを維持しつつ、簡単に拡張可能とするのは難しい問題だね。どちらかを犠牲に出来れば簡単なんだけど (タイミング無視、または上位層を拡張)。

ぱずるだまプレイ時の相手の動きを見てると、どうも激しくテキトーに動いているように見える (ガコガコしたり急に飛んだりする) ところからして、パケット到着時にキー入力時間 (これは当然ある程度の過去) まで巻戻って再計算をしてるのかもしれないなー、と思った。キー入力からゲームオブジェクトの挙動の再計算だけで画面表示をともなわないなら、かなりの時間分１フレ内で計算可能でしょ。パケットのディレイがまぁ長くて 400ms くらいだとしても、30フレ分も再計算すれば十分。バックバッファも１秒分くらい持ってれば十分かな？

> そいつはレスポンス的にと言うことかね。ＴＣＰでやってるのがそもそもアレなんだが。

そんなちゃんとした感想じゃなくて、無線 LAN の通信ランプが点きっぱなしになっていや〜んな感じ、ってだけ。無線 LAN はパケット送信にともなうオーバーヘッドが大きいんで、ちっこいパケットが山盛り飛ぶと実効帯域が狭まりがちらしーんで。

かぴのすけ (Sun, 01 Aug 2004 20:46:55)

> 俺もある状況下においては束ねることの有用性を認めてただろう。

束ねる＝非Ｐ２Ｐではないんだよ。Ｐ２Ｐ自体は最初から否定してないし、そこは既に（というか最初から）話の本質でない。Ｐ２Ｐの利点を今さら力説するのが既に間違い。リフサバの役割に関しても何度も繰り返さずとも一度書けばじうぶんだ。ク〜ルにゆこ〜ぜベイベ。

> でいいじゃん、と

やってみてうまく行ったらゆってくれ。あんまり厳密に合わせると動きがグデグデになりそうだがね。まとめ役があると適当に合わせるという芸当ができる。それが都合がいいということだ。

> ぱずるだま

落ち物系ゲエムに特化して考えれば、自分のプレー画面はローカル同様に動かし、相手側の状況はそれこそストリーミングビデオでも流すかのようにてきとーに流してればプレーアビリティ上の問題を最小化できる。

> 通信ランプが点きっぱなしになっていや〜んな感じ

そいつは原理上明らかなんで要するに何のホーコクにもなってないな。

かぴのすけ (Wed, 04 Aug 2004 00:05:43)

へんじがない。ただのかいすいよくのようだ。