  |
はてなキーワード: 原子時計とは
——————————————————————————————
告
5/15
「科学哲学第二」のレポートは、5/31 までに１号館１階の浅川の レターボックスに提出すること。
——————————————————————————————
告
6/3
期限を過ぎて提出されたレポートは、いかなる理由があろうとも 受けつけません。
締切を過ぎてもまだ私のレターボックスに「科 学哲学第二」のレポートを入れる者が居ますが、5/31 の午後 5:00 以降に投函されたレポートは全て破棄しました。
——————————————————————————————
告
6/4
「5/31 まで」と書いたら「5/31 の午後 5:00 まで」の意味です。
こんなことは社会常識です。
——————————————————————————————
告
6/5
他の教官が午後 12:00 まで受けつけていても、関係ありません。
反例を幾つ挙げようと、定量的に述べなければ意味がありません。
——————————————————————————————
告
6/8
なぜその熱意を使い、もっと早くにレポートを作成しないのか理 解に苦しみますが、とりあえず午後 12:00 まで受けつける教官が 過半数であることは理解しました。
よって、6/15 の午後 12:00 まで「科学哲学第二」のレポート提出期限を延長します。
——————————————————————————————
告
6/10
「6/15 午後 12:00 まで」ではなく「6/16 に浅川がレターボック スを開けるまで」ではないか、との意見がありましたが、これら は全く違います。必ず 6/15 中に提出するように。
——————————————————————————————
告
6/12
私のレターボックスに猫の死骸を入れたのは誰ですか。
——————————————————————————————
告
6/13
「私がレターボックスを開けた瞬間に波動関数が収束し、内部状 態が定まるので、レターボックスを開けるまではレポートが提出 されたかどうか分からない」と主張したいことは分かりました。
今回は、提出場所を１号館３０２の浅川研究室前のレポート提出 用ボックスにします。
この箱は、6/15 午後 12:00 にシュレッダー へと自動的に切り換わるので、シュレーディンガーの猫の問題は発生しません。
——————————————————————————————
告
6/16
いいかげんにしなさい。午後 12:00 は「グリニッジ標準時」では なく「日本標準時」です。
普段は日本時間で生活しているくせに、レポート提出時だけグリ ニッジ時間を求めるなど言語道断です。
——————————————————————————————
告
6/18
信じ難いことですが、「科学哲学第二」を受講する学生の過半数 がグリニッジ標準時で生活していることが分かりました。
夜型にも程があるとは思いますが、とりあえずレポートの提出は6/30 の午後 12:00 GMT まで待ちます。
——————————————————————————————
告
6/22
時間の連続性についての疑義は受けつけません。どうやらベルグソン の時間論を曲解している者がいるようですが、主観的時間がどうあれ、 7/1 の後に 6/30 が来ることはありません。
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
「それで、確かに君は 6/30 中にレポートを提出したというんだね？」
「ええ、ギリギリでした」
「だが、君のレポートは私の手元には無い。君は時間を間違えたのではないかな？」
「いいえ、日に 0.1 秒も狂わない、正確な電波時計を使っていますから。
先生のレポートボックスこそ、時刻を間違えたんじゃないですか？」
「冗談だろう。GPS 補正で ±5 ミリ秒の精度で合わせてある」
「それで、24:00 GMT ちょうどにシュレッダーに切り換わるわけですね？」
「そうだ」
「うーーん。あ、そうだ。多分うるう秒の差ですね」
「うるう秒？」
これは太陽の公転周期から計算する平均太陽時と違い、原子時計によって
計られることになっています。この協定世界時と実際の天文時刻との
差を縮めるため、12/31 や 6/30 などの午後 24:00:00 に、閏年の2月29日
と同様の 1 秒を挿入することがあるんです。いやあ、このうるう秒の
間に僕はレポートを提出して、先生のシュレッダーが動作したんですね。
絵描きとtwitterの裁判記録はなかなかコンテンツ力高いと思う
私が描きました！いいえそれは私です！で裁判になったのがあるんだけど、
電子署名ってタイムスタンプも含まれるんだけど、「電子署名が本当に日時を証明してるか」について議論が進んでる
PCて時間変えられるじゃん？だからいつの発言かってのは簡単に捏造できるのね
だからタイムスタンプは自分のPCでないどこかのサーバーから拾ったタイムスタンプであるのが重要って話になってるのね
で、日本では電子署名のタイムスタンプに対して公的に責任を負う業務をやってる企業があるんだけど、
絵描きって法人各持たないフリーランスだからこういったtoBが拒否られるわけ、無職同等だから
そこで絵師はこれ使えないからそもそも妥当性を問うこと自体間違ってるよね？となった
一方絵師はそこで同じアルゴリズム使ってるOpen実装のPoC使ったら妥当だよね？ってことで
確かに業務の責任範囲が変わった所で認定事業者もOpen実装も
RFCに定義されたtsa使ってて第三者検討によって担保できるでしょとなったんだけど
原子時計の概念持ち出してこれと合ってるのはどうやって証明するんですかってなってる
どっかの得体のしれないサーバーから持ってきたタイムスタンプと認定事業者のタイムスタンプとどちらが証拠能力高いんですか？と
同じアルゴリズムなんだから証拠能力かんけーねーよという絵師と
法的妥当性を国が認めたものとそうでないものとの違いは何なんですかという被告と
物体が認識できるのが光の反射だというのと、どんな状況下でも一緒（のはずだ）ってことから光速を最大値として不変、単位の一メートルとかみたいに設定した結果の副産物が
光速に達すると物体が伸びる ＝ Ａの地点で見える物体（光の反射）とＢの地点でみえる物体（光の反射）が計測するところでほぼおんなじのが見える
手をすばやくうごかすと伸びて見える（でも実際眼の問題だからのびてはない）がまじで伸びてる（物体の反応として光より早いものがないからその時点ではあるのと同じ）
一秒間に３億フレームくらい撮影できるカメラがあったら光速で移動する物体の伸びてない写真がとれる（光子がカメラに到達しないから撮れないけどね）
物体の移動で増す質量も無限大になる 速いボールが遅いボールより痛いのと同じ
光速に達すると時間が遅くなる ＝ 光の速度で移動すると光子が到達しない
光の速度が不変なのに光子が飛んでこない、ってそれ時間とまってるやんって事
でも後からくる光子が追いつかないだけで前の光子はどんどんくる（質量無限大なので観測はできないけどね）
100年前の遠く離れた星の光がいまになって届く（劣化せず直進してくる）で計測の時点だけをみれば100年のズレだけど、100年前のビデオを発掘して再生したら
100年前の様子がみれるけどそれは100年たった後での話
100年時間がとまってたわけじゃない 100年間は100年前に終わっていて 100年後は100年間保存された映像をみてるだけ
質量のあるものがこの移動ができたら100年のズレが発生できるけど質量に耐えられる物質がないから実質時間は 光の映像が届くのとは別に
実際光速で物質が移動できる環境とか現象ができたら止まるかもしれんね
光の速度に近くなっていくと青方偏移とか赤方偏移とかするのは光のなかでも波長の長さがあって
いつもは点にしかみえないすばやいチーターをスローモーションで撮影すると、鼻先から髭、耳、足、しっぽ、とみえるようになるみたいな感じ
観測点が１つの時間の点の１コマから、スローモーションという秒間３００コマにふやす（３００速度増す）とみえるようになる
地球の公転で速度差のある地表と宇宙空間では時間がずれるのでは
加速してる窓から加速してるのをみるとその差が小さくなる、その２つを観測してるところからみればずれが出る
ということで原子時計でズレがでてすごいって話になってるけど、
そもそもその時間の測定が物質の変化で測っていて同じ周期だということが基準 光速みたいなもの
物質の状態変化がもし 重力で空間の長さが変わっていたら 長さが違うのでその距離を移動したり存在するものの変化の速度がかわる
重力で光が曲げられたり、減速させられた場合「時間が遅くなったり早くなったり」するはず
超重力空間で光子もにげられないところに圧縮されてるモノがあったとしたら、その光子の像とおなじ状態のものがそこにあったら「時間はとまってる」と言えるかもしれんね
光子が何なのかよくわからんのと、重力って粒子なのか空間なのかわからん というか空間もあるものだとしてしか認識できず長さもなにでできてるかもわかってない
空間を圧縮するとかいってもそこにある粒子とか素子の話で 重力をもしコントロールできたら空間自体が縮むのでそこを通れ（第三者からみて）ばワープできる（ワープしてる本人は距離かわってない）
光速が不変ならね
光速よりも速く移動ができれば 空間を必要時間以下で移動ができることになる（けれども計算上時間を逆行することになる）
どうかな
多分地球の時刻系が元になっているんだろうけど、地球はまともには管理されてないっぽいし
原子時計を使った秒のカウントだと、時点を基準とした秒のカウントからどんどんずれていきそう
ナレーションとか登場人物の会話を聞いていると、宇宙標準時みたいなある気がするんだけど、
どうやって決めてるんだろ？
宇宙歴と帝国歴があるから、それぞれの勢力のローカルタイムがあるとは思うが
「少し前までは宇宙歴と帝国歴の差は309年でしたが、最近は310年の差があります」
みたいな
地球に合わせて自転をコントロールするのはさすがに難しいだろうなぁ
それぞれの首都星の時刻を基準として、各惑星にローカルタイムがあるような気がする。なんとなく
原作読むかな
男性の低い声で各地の雨量や各市町村の避難所の場所が伝えられる。雨量が読み上げられる。波の高さ。風速。台風の進路。
「過去、水害時に自宅で亡くなった人の半数は、1階で亡くなっています。今夜はどうぞ2階でお休みください」
淡々と伝えられる書面上の事実の中に、ときおり強い指向性をもった言葉が折り込まれる。ラジオの前のわたしに話しかけている。そう感じる。
過去に人間がこのように死んでいる。だからあなたはそうならぬよう気をつけてほしい。
BGMはない。不安を紛らわす笑いもない。聞こえるのはただ雨と風の強さを示すさまざまな情報と、真摯にこちらを向いて語られる命の危険。
窓の外に目をやる。路面は濡れている。雨が降ったらしい。稲光は見えるが、雷鳴はない。台風の猛威からは遠く、ただ明日の朝は涼しいだろうと考える。
雨が降るたびわたしは、世界が水に沈めばよいと思う。子供の頃から心に描く風景がある。山中のログハウス。暖色の明かりが照らす寝床のそばには小窓がある。雨が打ちつけ、もう何年も止まない。温かいコーヒーを飲んで、わたしはその風景をずっと眺めている。
何かが壊れることに一片の爽快感を覚えない人はいないと思う。悲しい、驚いた、そのもっと奥の純粋なところに、気持ちいい、がある。
本来、自然現象による破壊に悲劇はない。ただし、人間が暮らしている場合はそれに立ち向かわざるを得ない人がおり、それが悲劇を生む。わたしは何も人が死んだり傷付いたりするのが楽しいわけではない。ただ、悪意ない、食い止めようのない力で何かが壊れるのが気持ちいいだけなのだ。
世界が終わっていく時もNHKはきっと放送をしてくれる。緩やかに、あらがいようのない現象によって、私たちは死んでいく。朽ちる大陸、沈む島々、燃える海、狂っていく原子時計、ひび割れる空気、それらをきっと、よく見知った言葉で平易に、淡々と伝えてくれる。終わりが近いことを感じながら眠りにつく。きっと安らかで、わくわくする。
Windowsでどん。
w32tm /monitor /computers:ntp.jst.mfeed.ad.jp,time.cloudflare.com,ntp.nict.jp,time.google.com,ntp.ring.gr.jp,time.windows.com,time.nist.gov /ipprotocol:4 /nowarn
※調査したPCはntp.jst.mfeed.ad.jpを参照しています。
ICMP: 11ms 遅延
NTP: +0.0014266s ローカル コンピューターの時刻からのオフセット
階層: 2
NICTをソースとするStratum 2のパブリックNTP。
ICMP: 11ms 遅延
NTP: -0.0073322s ローカル コンピューターの時刻からのオフセット
階層: 3
CDNのCloudflareが提供しているNTP。
遅延が少ないのは、東京と大阪にそれぞれサーバがあるかららしい。
ICMP: 10ms 遅延
NTP: +0.0011621s ローカル コンピューターの時刻からのオフセット
階層: 1
日本標準時をソースとするStratum 1のパブリックNTP。
ただし、一時間辺り20回までにしときと注意書きがFAQにある。
ICMP: 38ms 遅延
NTP: -0.0013263s ローカル コンピューターの時刻からのオフセット
階層: 1
Googleが公開しているNTP。ソースは原子時計とのこと。Stratum 1。
ICMP: エラー IP_REQ_TIMED_OUT - 次の時間内に応答がない 1000ms
NTP: エラー ERROR_TIMEOUT - 1000 ミリ秒内にサーバーからの応答がない
福岡大学のNTPを救うために立ち上がった人々によって立ち上げられたNTP。
生きてる？
ICMP: エラー IP_REQ_TIMED_OUT - 次の時間内に応答がない 1000ms
NTP: +0.0003482s ローカル コンピューターの時刻からのオフセット
階層: 3
エラーが出るけど、値は悪くない？
ICMP: エラー IP_REQ_TIMED_OUT - 次の時間内に応答がない 1000ms
NTP: +0.0037770s ローカル コンピューターの時刻からのオフセット
階層: 1
UTC(NIST)をソースとするStratum 1のNTP。
アメリカは遠いよね。うん。
やっぱり途中で切れたので続きから
違います。
そうです。
はい。Stadia Games and Entertainmentの組織を発表しました。これは我々の1stパーティのスタジオです。
はい。
Googleは開発者に対し全てのツールを支援しています。Stadia向けの開発は彼らにとって別のターゲットにしか過ぎません。Visual Studioを用いる既存のツールや彼らが用いるツールの全てと共に、彼らのワークフローに統合されます。従ってStadia向けの開発はPlayStationやXbox向けの開発と同じくらい簡単です。
我々はUnrealもサポートします。UnityがStadiaをサポートします。予想される多種多用な業界標準のツールとミドルウェアが準備されます。
とても良い質問です。我々はユーザに対し彼等のインフラの中で何が起こっているかをできる限り理解できるよう支援する必要があります。また我々はゲーマーに対し最適な体験を得られるようなチューニングを行うことが可能な情報に対し投資を行うだけでなく、我々自身の技術を用いて最良のパフォーマンスを実現するつもりです。Googleの技術の多くがインターネット網の基盤であることを思い出して下さい。我々はDCからの情報がどのようにユーザに届くかを良く理解しております。できる限りの最適化を行うつもりです。
その通りです。それこそが我々のプラットフォームの根本的な差別化ポイントです。既存のゲームカタログを持つデベロッパにとってStadiaは簡単で親しみ易いものです。我々はできる限り摩擦なくゲームの移植を行えるようにします。なぜならゲーマーは好きなゲームを遊びたいですし、彼らの愛するキャラクター、ストーリー、世界を楽しみたいのです。しかし我々はまた開発者に未来を描く新しいキャンバスをも提供します。ゲームを高速に配布し、プレーヤーと新しい手段で、特にYoutubeにて繋げます。そして開発者が持つアイデアを実現するための前例の無い技術を提供します。
解決されたと同時に緩和されています。まずデータセンターに対しより多くの人々がより良い経験を得られるようにするための投資が行われました。また圧縮アルゴリズムについては我々に抜本的な先進性が存在します。Googleは圧縮アルゴリズム標準仕様の先駆者でありこの点がストリーミングの将来をより確実にします。残念なことですがGoogleでも制御できない点が光の速さです。そのためこの点が常に要因となります。しかし常に理解しなければならないこととして、我々は常にエッジ(終端)にもインフラを構築していることが挙げられます。Googleの中心にある巨大なデータセンタだけではありません。我々はできる限りエンドユーザの側にインフラを構築しています。それによって歴史上の幾つかの問題は回避することが可能です。さらにまだ率直な、あまり洗練されていないProject Streamのストリーマーでも信じられない結果を出しています。さらに我々はサービスリリース時に1080p60を超える品質を実現できるだけの根本的な改善を行いました。我々は8Kに至るでしょう。
圧縮にネットワークです。我々はGoogleがインフラに投入した数々の改善点に依っています。BBR、QUIC、WebRTCを基盤としてその上に構築がなされました。だからIPパケットの低レイテンシでの配信だけでなく、送信元へのフィードバックも行うことが可能です。ですのであなたが仰るZenimaxが使用した技術なら、彼らはここでも利用することが可能です。彼らは彼らのゲームの最適化を行うことができるでしょう。我々はフレーム毎のレイテンシを予測が可能で彼らにそれに合わせて調整を行わせることができます。
我々は改善を続けます。Streamは最初のバージョンです。我々は性能向上のために調査を行っており、レイテンシに適応していきます。リリース時にはより良くなっているでしょう。
確かにそのとおりです。そしてそれこそがGoogleが何年もかけて開発してきたスキルであり、抜本的なスケールする能力です。我々がどうやって実現しているのか、何をしてきたかについては今日は詳細にはお話ししません。しかしGMailやMap、Youtubeが同時に利用可能であるためと同じ基本的な技術のいくつかが我々が依るものです。
我々は競合他社が何をしているかは存じておりません。
我々の第一世代システムに導入されるGPUは10Tflops以上の性能があり、さらにスケールアップします
AMDです。
情報を公開したくない訳ではないのですが、このプラットフォームが進化することのほうがより重要です。そしてこの進化がユーザと開発者の双方に対しシームレスに行われることを確認して頂きたいのです。そして進化は常に継続し、誰もが常に最新で最高の物を手に入れます。
開発者にもこのように考えて欲しいのです。もちろん完全には抽象化されていません。特にゲームの開発者にとっては。しかし我々はそれでもこのプラットフォームが常に進化していると考えて欲しいのです。速さや容量、リソースには制限されていないのだと。
シェーダコンパイラのツールをいくつか開発しました。これらは開発を楽にするでしょう。しかし現在のGPUはとても優れており開発者が既にVulkanに親しんでいれば、例えばid Softwareさんは既に全てVulkanに移行していますが、そのような開発者の方々には既存のゲームをStadiaに移植するのはとても簡単です。Doom Eternalが4K、60フレームで動いでいるのは既にご覧になったと思います。非常に素晴しい状態です。これこそが我々にとって重要な証明ポイントです。FPSはグラフィックとプレイアビリティの双方で要求が高いゲームです。 従ってこれは我々のプラットフォームの強力な証拠であり、idさんにも講演して頂きます。
x86で2.7GHzで動作しています。開発者にとり慣れのあるものです。開発全体を通して、CPUは制約となる要因ではありません。我々は全てのタイトルを動作するに十分なCPUを提供します。
沢山です。
しかしサーバ級のCPUです。Stadiaはこれまでのコンソールと違いパッケージングに制約を受けません。熱対策の問題も異なります。コンソールとはサイズやパッケージングの動機が異なります。データセンタの中でそれはとても汚なく見えるかもしれません。一方でとても帯域幅が高いメモリが使用可能で、とても高速なペタバイト級のローカルストレージも使用可能です。ご家庭のコンシューマデバイスよりも数百倍は速い物です。
パートナーには彼らが話せる時点で彼らの計画を教えてくれるよう伝えています。Stadiaをこの世界で最も偉大なゲームの開発者達に説明することにはとても興奮します。Stadiaは、開発コードではYetiと呼ばれていましたが、Stadiaのビジョンを説明すると、開発者のリアクションは「これは私が期待したものそのものだ。これはまさに我々の次のゲームのためのビジョンそのものだ。elastic computingの考え、次世代レベルのマルチプレーヤー環境、ゲームを観ることと遊ぶことの境をあやふやにし1つの体験にすること」と話されます。
イノベーションの1つの領域として、最初のほうで述べましたが、マルチプレーヤー環境において、単純にパケットを複数のプレーヤーにリダイレクすることから、原子時計レベルでのコンシステンシーを全ての状態遷移において定期的にクライアント間で更新する真のシミュレーションへの移行が挙げられます。これにより開発者はこれまでには不可能だった分散された物理シミュレーションを得ることができます。これだけでもゲーム設計のイノベーションに対し大きく寄与します。このため多くの開発者が、大袈裟でなしに、実際にとても感動的なリアクションを我々のプレゼンに対して返して下さっています。
これこそがゲーム業界の素晴しい点です。技術が常に創造性を刺激し、ゲームに対しより大きな聴衆を作り、そのことがプレーヤーと開発者に対しより大きな機会を作ってきました。エコシステムが進化し、正の方向に回り続けるなら、それはゲームを遊ぶことにとって良いことです。
3台のGPSが一緒に実行されるデモを行っています。私は上限が無いとは申しません。しかし我々は技術上の限界を上げています。そしてStadiaは静的なプラットフォームではありません。このプラットフォームは5年や6年の間、レベルが変わらない訳ではありません。開発者とプレーヤーの要求に従い、成長し、進化するプラットフォームです。なぜならStadiaはデータセンタの中に構築されています。進化させるのは我々にとって簡単なことです。
CPU/GPU/メモリ帯域幅の変更にはいくつかの自然な段階があります。これは家庭の物理な小売の端末よりももっとスムースでより継続的な進化です。しかし、より重要なことは基盤データセンタ網とそれに含まれるネットワーク技術への投資です。この2つが一致して行われることが重要でどちらか1つではダメなのです。
それは我々も既に行っています。Googleが既に20年以上、行っていることです。我々が依って立つまた別の巨人の肩です。
我々はStreamをさらに強化させています。従ってユーザはこの制約が全体のスタックに対する改善と最適化、また特に時間によって緩和されることを期待するでしょう。我々はその期待の上を行きます。
私は具体的な数値についてはコメントしません。しかし当然低くなります。
インターネットの接続環境はStadiaをリリースする市場では全体的に上昇機運が見られます。つまりこのパフォーマンス特性はますます多くのユーザが利用可能になります。
さらに繰り返しになりますが、BBRを初めとする我々の技術があります。さらに覚えておいて頂きたいのは我々のネットワークに対する理解はそのままではありません。それらもまた時と共に改善されていきます。Youtubeはマクロと
Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事。
---
タイミングの問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleはデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部からの技術的観点からの技術統合を行ってきました。他社でもその視点は存在していますがGoogleにはその点に固有のアドバンテージが存在します。
その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています。開発者は制限の無い計算資源が利用でき、何よりもマルチプレーヤーをサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化が必要でした。我々のプラットフォームではクライアントもサーバも同じアーキテクチャの下にあります。これまではクライアントとサーバの間のpingに支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一のインスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞のヘッドラインを飾ることが可能な技術です。
両方です。
ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中のデータセンタ間を接続しています。米国の西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシが予測可能でそれに従い設計を行うことができます。
StadiaはYoutubeの技術と深く結びついていますが、実際には一歩引いています。今日のゲーム業界を考えてみて下さい。2つの世界が共存しています。1つはゲームをプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeでゲームを毎日見ています。2018年には述べで500億時間がゲームを視聴するのに費されています。時間と人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。
つまり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザが他人を楽しませる場所です。
だから我々のブランドはStadiaといいます。これはスタジアムの複数形です。スタジアムはスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したかを意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。
その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fps、HDRとサラウンドをサポートしました。さらに開発者が必要なインフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDRで画像を送信することが可能です。だからあなたのゲーム体験の思い出は常に最高の状態になります。
プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogleは4Kでストリームします
共有が友達だけか、世界中に公開かも自由に選択可能です。Googleはユーザに制御を明け渡します。もしユーザがYoutubeで公開すれば誰でもリンクをクリックすることでそのゲームを遊ぶことができます。
そう。そしてこれはマルチプレーヤーゲームのロビーの新しい形となります。Youtubeのクリエイターなら誰でもがファンやチャンネルのsubscriberを自分のゲームへと誘うことができます。生主として、Youtubeのクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。
Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初のサービス立ち上げから全ての画面への対応を行います。TV、PC、ラップトップ、タブレットに携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。
我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りからも解放したいのです。パフォーマンスに優れ、リンクをクリックすればゲームは5秒以内に開始されます。ダウンロードもなく、パッチもなく、インストールも必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップでChromeブラウザを使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラが動作します。そして、もちろん、我々自身のコントローラも開発中です。
コントローラを自作する理由にはいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術に採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続でDC内のゲームに直接接続することです。ローカルのデバイスとは接続しません。
その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。
そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術とマイクを用います。ユーザの選択により、ユーザはプラットフォームとゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaがマルチプレーヤーゲームを指定した友人と共に直ぐに開始します。
我々はゲーマーを可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーがゲームを起動したら直ぐに友人とゲームを開始したいと考えています。ゲーマーはUIに時間を費したくは無いのです。
誰かが言ったことですが、現在のコンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム機自体の更新や、ゲームの更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeにシェアできます。
Youtubeが観られるならどこでもStadiaは動きます。
Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます。画像はNetflixやYoutubeから直接受け取ります。Stadiaの場合、StadiaコントローラからChromecastへとこのゲームのインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画のストリームを受け取ります。クライアントはとてもシンプルです。行うのはネットワーク接続、ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力はコントローラが扱います。ビデオと音声とネットワーク接続はChromecastの基本動作で全て既に組込まれています。
そうです。とても良く出来ています。WiFiに繋ぐだけです。コントローラにはWiFiのIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手にChromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができます。デジタルパッドでUIを操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができます。Chromecastは5W位下です。Micro-USBで給電可能です。典型的なコンソールは100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画の再生だけです。従ってAssassin's CreedやDoomや他の重いゲームがあなたのスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホで10時間でも遊べます。
今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からはYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。
サービス開始時から提供されるサードパーティによる解決手段をサポートしています。他にもアイデアがあります。しかし今は話せません。
良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術を提供していました。StadiaはLinuxベースです。グラフィックAPIはVulkanです。開発企業はクラウドにインスタンスを作成しますので、開発キットも今ではクラウドにあります。しかしクラウドだけでなく、開発社のプライベートなDCでも、机上のPCでも可能です。
もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブがゲーム開発での標準となるでしょう。
デベロッパーやパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要なツールや技術について考えていると思います。しかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営に必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています。
米国では全ての必要な場所に展開が終わっています。Project Streamの試験に必要な環境は2018年末には整いました。我々はGoogle社内で、Google社員を対象に2017年の始めから2年間の間、プライベートなテストを行ってきました。2019年には米、加、西欧、英にて Permalink | 記事への反応(1) | 06:10
