アカウント名:
パスワード:
例えば、mパターンをnフレームまで先に投機的に実行すると一般化すると、
・ゲームの内部状態は、入力が確定しているkフレーム目までは確定・k+1フレーム目から、k+nフレーム目まで、それぞれ最もありそうなm個の入力候補に対して投機実行・k+nフレーム目の候補として、m^n個の状態をレンダリング、クライアントに送る・クライアントは受け取ったものの内、最も実際の入力に近いk+nフレーム目候補画像を表示・そうこうしているうちに、k+1フレーム目の実際の入力がサーバに届くので、サーバ上でk+1フレーム目も確定
となり、多くの遅延を消したい場合はnを増やし、入力に対する違和感を消したい場合はmを増やすことで、原理的にはいくらでもユーザビリティを上げられますね。まあ、帯域がエラいことになりますけど。
一部の画像は似たり寄ったりになるだろうから、差分で圧縮するとか、カメラワークはユーザのnフレーム前の入力にのみ依存するように設計すると、背景が同様の画像になるから差分圧縮が効きやすくなるとか、他にもゲームデザイン上の工夫の余地もいろいろあって面白そうです。
突き詰めると、プリンスオブペルシャみたいなことになるんでしょうね。キャラにディズニーアニメ的に「自然」な動作をさせようとすると、あらゆる動作に、大げさな予備動作と動作後の拘束時間を入れざるを得ないことを逆手にとって、「もったりした操作感のアクションゲーム」を追求すると言う面白い落としどころでした。
たしか初代のPSOがスティックの入力に対する移動量(歩数)を大きくとることで通信遅延と移動の同期のバランスをとっていたかと。当時は回線が細いのでそうやってモーション一つ一つをもっさりにする事で拘束時間を増やし、遅延を感じさせない(遅延が発生しても破綻し辛い)ゲームデザインになってました。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
何往復ぐらい誤魔化せるんだろう (スコア:1)
例えば、mパターンをnフレームまで先に投機的に実行すると一般化すると、
・ゲームの内部状態は、入力が確定しているkフレーム目までは確定
・k+1フレーム目から、k+nフレーム目まで、それぞれ最もありそうなm個の入力候補に対して投機実行
・k+nフレーム目の候補として、m^n個の状態をレンダリング、クライアントに送る
・クライアントは受け取ったものの内、最も実際の入力に近いk+nフレーム目候補画像を表示
・そうこうしているうちに、k+1フレーム目の実際の入力がサーバに届くので、サーバ上でk+1フレーム目も確定
となり、多くの遅延を消したい場合はnを増やし、入力に対する違和感を消したい場合はmを増やすことで、
原理的にはいくらでもユーザビリティを上げられますね。
まあ、帯域がエラいことになりますけど。
一部の画像は似たり寄ったりになるだろうから、差分で圧縮するとか、
カメラワークはユーザのnフレーム前の入力にのみ依存するように設計すると、背景が同様の画像になるから差分圧縮が効きやすくなるとか、
他にもゲームデザイン上の工夫の余地もいろいろあって面白そうです。
突き詰めると、プリンスオブペルシャみたいなことになるんでしょうね。
キャラにディズニーアニメ的に「自然」な動作をさせようとすると、
あらゆる動作に、大げさな予備動作と動作後の拘束時間を入れざるを得ないことを逆手にとって、
「もったりした操作感のアクションゲーム」を追求すると言う面白い落としどころでした。
Re: (スコア:0)
たしか初代のPSOがスティックの入力に対する移動量(歩数)を大きくとることで通信遅延と移動の同期のバランスをとっていたかと。
当時は回線が細いのでそうやってモーション一つ一つをもっさりにする事で拘束時間を増やし、遅延を感じさせない(遅延が発生しても破綻し辛い)ゲームデザインになってました。