インタラクティブなビデオとそれが食べられるもの

6か月前、1杯のコーヒーを飲みながら、プログラマー、監督、ゲームデザイナーが映画が退屈になりつつあるという事実について友好的な会話をしました。 「はい、特殊効果はよりクールになり、Dの量は大きくなっていますが、これは誰にとっても少し驚きです。 人々はプロットに追いつきます。 さて、いつか私たちが制御できる映画を見ることを想像してみてください？」

「ジョン・コナーを殺します。」

「そして、私はニワトコのスティックを投げ出して悪い魔法使いにならないでしょう。」

「そして、くちばしではなく両親を救うために、ポッターの代わりにポッターのフライホイールを使用していました。」







そして、彼らが言うように、それは始まりました...



先週、Habrazhitelに、ゲーム作成の技術的側面について学ぶのが面白いかどうかを尋ねました。 これで、作業の成果を提示し、どのような困難に遭遇し、どのように苦労し、どのような結果を得たかを説明する準備が整いました。



デモおよび製品版へのリンクは、記事の最後にあります。



目的 ：インタラクティブなビデオを設計する（言い換えると、ビデオで大雨と質量効果の実験を行う）



私たちはあなたの質問にすぐに答えます：「なぜビデオに？ ゲーム環境と完全な行動の自由を設定してみませんか？」



そのようなゲームは既に存在し、高品質のビデオほど存在感を高めるものは何もないという結論に達しました。また、テクスチャーにとらわれることはありません。 私たちはウェブ上で実行することにしましたが、DVDや他のgamedevチャームで製品をリリースする問題に直面することはありません。 さらに、ほとんどの場合、今日のインターネット接続の品質により、予備ダウンロードなしでフルHDビデオを視聴できます。



MVPを作成するために、いくつかのストーリーラインをブロックしないことを決め、行き止まりのある特定のチェックポイントに分割された1つのストーリーラインのパスに沿って進みました。



経営陣と働く



これらはすべてパブリックにアクセス可能であり、ブラウザーで機能する必要があるため、 JavaScriptを選択しました（「JavaScriptのみ、ハードコアのみ！」©プログラマー）。



大雨でのアクション（ストレス）シーンの管理と同様に、QTEコントロールモデルが選択されました。特定の時点で、押す必要があるボタン/一連のボタンがポップアップします。 なんとか押して-まあ、時間がなかった-彼の健康/自尊心の一部を失った。 正常性レベルが0に低下すると、最も近いチェックポイントで行き止まりトラックへの移行が発生します。



デスクトップおよびコンソールゲームからゲームインターフェイスの要素を借用することが決定されました。 その結果、主人公のアバター、彼の感情、思考、脈拍、健康状態が得られます。



多くのカスタムアイテムを表示する必要に直面しました。



このケースでhtmlを使用すると、 DOMに大きな負荷がかかり 、その更新ごとにすべてのオブジェクトの再構築と再描画が発生し、遅かれ早かれ、コンピューターリソースに遭遇します。



出力ツールを変更してCanvasを使用することが決定されました。これにより、必要なときにカスタム処理を行い、それらを再描画できます。 現時点では、1つのキャンバスに、まれにしか更新されない静的要素と、非常に頻繁に更新される要素が多数あるという事実に直面しています。 また、頻繁な要素を再描画する場合、重い要素を再描画できます。 将来的には、2つのキャンバスを上げる（頻繁に変更し、めったに変更しない）か、HTMLで行うようにめったに変更しない（DOMの負荷は最小限になる）と考えています。



使用するコントロールは次のとおりです。

1）マウススクロール-ビデオでのメインキャラクターの実行を正式に担当します。 マウスホイールを2.5秒間回転させないと、健康/自尊心がすぐに低下し始めます。

2）キーを押すと、ビデオのメインキャラクターの一部のアクションが行われます（コントロールモデルは、典型的なシューティングゲームに似ています：WASD-方向、E-アクション、スペース-ジャンプなど）

•誤って押された/押されていないキー-健康のレベルを奪います。 ボタンを押すと特定の時間が与えられます

•一連のキーを入力します

•個々のフレーズと文章の入力







キーストロークについては、すべての人々の反応が異なることに言及する価値があります。



解決策 ：キーを押すまでの時間遅延に関する統計を収集します（キーが表示された瞬間から押す瞬間まで）。 次のキーを表示する必要があるたびに、このユーザーの平均リードで表示します。 その結果、ユーザーはアクションを実行する必要があるほぼその瞬間にキーを押します。 このアプローチの最初のキーは何も解決せず、リードを初期化するのに役立ちます（ほとんどのサッパーのように：最初のフィールドは決して私のものになることはできません）。 しかし、さらなる制御が快適になるように、このキーを押す必要があります。 この機能では、キーの重量を入力する必要がありました。 そして、最初のビデオシーケンスの最初の一連のキーには最大の重みがあります（キーを誤って押す/押さないと、すぐにヘルスレベルがゼロにリセットされます。この場合、ユーザーを不快な遅延コントロールで再生させるよりも行き止まりにさせてリプレイする方が簡単です）。 当然、制御モデルはキーボードの言語レイアウトに依存しません。イベントは文字ではなくキーを想定しています。



将来的には、所定のパスに沿ってマウスを移動することでコントロールを拡張し、いくつかのオブジェクトと対話する機能も追加する予定です（たとえば、フレームがスローモーションになり、数秒でフレームに表示されているオブジェクトからオブジェクトを選択する必要があります）。



特定の時点で特定のイベントを呼び出すことにより、制御モデル全体がビデオに重畳されます。



ビデオで作業する



ブラウザーを使用する場合、いくつかの制限がありました。たとえば、Google Chromeでは、同時に10個のビデオファイルをプリロードできます（最初のMVPでもこの制限に適合しませんでした）。 Safariは同じWebキットであるため、その動作は非常に似ています。 Firefoxの場合、状況は似ていました。 私は別の解決策を探す必要がありました



オプション1 ストーリーのプールと行き止まりのビデオトラックがあります。 ユーザーが現在のストーリートラックを操作している間、次のストーリーとデッドロックがバックグラウンドでプリロードされます。 彼がチェックポイントに到達すると（現在のビデオの最後から数分の一）、ユーザーのプレイがどれだけクールかを確認し、現在のトラックの終わりを示すか、ストーリーでさらに開始します。 不要になったものはすべて削除されます。







合計 ：1つのファイルが再生され、2つのファイルがプリロードされます。 以前のものは削除されました。



長所 ：フレームを簡単に同期します（現在のトラックの最後のフレームが次のストーリーとデッドロックブランチの始まりである場合、ビデオの制作レベルで行われます）



短所 ：あるトラックから別のトラックへの移行時の軽いフリーズ。



オプション2 1つの長いストーリートラックと行き止まりのプール。 チェックポイントは、デッドエンドブランチへの移行が実行される特定のタイミングで設定されます。 最も近い行き止まりは、バックグラウンドでプリロードされます。







合計 ：1が再生され、1がプリロードで再生されます。 以前のデッドロックのみが削除されます。



長所 ：ユーザーがストーリーラインに沿って移動してもフリーズしません。



短所 ：移行フレームを行き止まりに同期させることはほとんど不可能です。ビデオファイル内の位置が変更されるイベントは一定の間隔で発生するためです。 その結果、行き止まりへの移行は、目的のフレームからではなく、フリーズからも始まります。



オプション3 ：移行時間で同期された1つのファイル内のすべてのビデオトラック（一度に1つの大きなファイルで、すべてのビデオが並行して再生されます）。 WebGLを使用すると、このファイルの一部を内部の特定のビデオファイルと同じサイズで表示できます。 それは恐ろしく、一見不合理に思えますが、それでも近い将来に試してみたいと思います。







長所 ：理論的には、フリーズフリーモデル：ビデオから別の部分への移行は1つの描画フレームであり、60 fpsでは1/60秒です。



短所 ：結果ファイルのサイズはまだ明確ではなく、ブラウザがどのように応答するかは不明です。

サウンドがどのように機能するかという問題が発生します。おそらく、その同期について思い起こさなければならないでしょう。 上記のオプションでは、音声はビデオトラックに縫い付けられています。



3つのアプローチすべての主なマイナス点 ：ユーザーが現在のプロットトラックの開始時に重大なエラーを犯した場合、ヘルスがゼロのユーザーはプロットに沿って最も近いチェックポイントに移動し続けます。



解決策 ：ストーリーラインをできるだけ時間をかけて削減し、完全なアクションまたは不完全なアクションの「推測」が即座に行われるようにします。 現時点では、一部のトラックのタイミングは約5秒です。 約1000人のフォーカスグループでテストした後の1つのプロットビデオトラックの最適なタイミングは15〜20秒でした。



はい、これを見て、「 ビデオコントロールのような臭いはありません 。 プルする最大値は擬似コントロールです。」



本当にそうです。 どんなに努力しても、ビデオ制御の完全な自由の問題はありません。 映画館の場合、私たちの意見では、絶対的な制御の自由は必要ありません。 あなたが朝食、そば、オートミールの主人公に与える違いは何ですか？ スニーカーまたはスニーカーを着用してください。 管理者は、プロットのコースに影響を与える可能性のある主要なアクションを理解しています。多くのアクションが存在する必要があり、それらは非常に動的でなければなりません。 わずかな追跡、戦い、銃撃戦、対話フレーズの選択-言葉で言うと、 ハードコア 、手にジョイスティックだけがあります。 メロドラマの管理は、このアプローチではありません。



その結果、ビデオを扱うオプション1が選択されました。



生産から生産の観点から、最も困難な部分は場所から場所への英雄の「テレポート」と場所といくつかのコンピューターグラフィックスを隠すことでした。 5分間のクリップの取り付けジョイントの数は20以上でした。サウンドには特別な注意が払われました。すべてのガサガサが現場で記録されました。 並列オーディオトラックの数は100以上です。



少しのサーバー履歴



最初は、所有しているハードウェアを使用してWeb上で実行しようとし、スライドショーを見ました。 予想される負荷を考えると、大量のビデオを適切なチャネルで配信するように設計されたコンテンツサーバーを持つという疑問が生じました。 さらに、 CDNのトラフィックは最も安く、ビデオはユーザーに最も近い物理サーバーからユーザーにロードされます。 その結果、すべての統計はCDNの下に置かれ、サイト、スクリプト、および統計は別のサーバーの下で機能します。



生産



これは、意志力、不屈の精神、人間の身体的および心理的能力の限界のテストでした。 撮影のために1週間が確保されました。 現時点では、スクリプトの作成、ロケーションスカウト、追加コンテンツの検索、自分自身の撮影が含まれていました。 平均して、撮影日は18〜20時間続きました。



ところで、主人公の歩数計はこの量のデータを消化せずに死亡しました。 主人公の5倍の距離を走ったRuntasticプロデューサーは、1週間で91 kmの走行距離を示しました。



シンプルなシーンもあれば、巨大な準備が必要なシーンもあり、異なる日に断片的に撮影されました。 一部のシーンは、 再生せずに盲目的に書き込まれました。 たとえば、Kasperskyのステージでは5分しかありませんでした。6つのフレームが存在することを期待して続けて、利用可能なフレームから最適なフレームを選択します。 天候は5つのコペックをもたらしました。イントロの撮影には、適切な飛行条件が必要でした。 その結果、彼らは6日目の撮影日に彼らを待っていました。 stageき火が座るまで、ステージにはわずか20分しかありませんでした。 その結果、彼は座って撮影を終えました。 また、最後のシーンでヘリコプターの問題が待っていました。 シナリオによると、トンの金属構造物に囲まれた限られたスペースのある時点で、5機のヘリコプターが飛行することになっていた。 センサーが夢中になり、ヘリコプターが左右に投げられました。 そして、このシーンの撮影のために、テストを考慮して20分間もありました（最大のヘキサコプターは離陸ごとに1つのバッテリーを植え付け、その間に、小さなヘリコプターをその気流と共に散らしました）。 幸いなことに、パイロットのエースは舵取り役でした（ロボット工学に従事しているイノポリス大学の学生）



テスターは楽園に行こう



このビデオは悪夢の中で彼らを悩ませます。 彼らは群衆の中の男が何を着ているかを知っており、フレームの中で最後から2番目の列の左にあるオレンジ色の梨の椅子に1:55分で座っています（見ないでください：青いTシャツと青いズボン）。 彼らは、ドアがいくつ開いているか、主人公が歩んだ数、脈がどのように変化したかなどを知っています。 リプレイの数は、2週間でマークを3,000回超えました。これは、約250時間の視聴とゲームプレイです。 キーの出現の瞬間は、小数点以下3桁の精度で設定されました。 1つのイベントのタイミングが一瞬ずれると、次の一連のボタンが破損する可能性があります。 したがって、制御モデルのテストには多くの注意が払われました。 要するに、テスターは、自尊心の単一の単位を失うことなく、このゲームに合格することができます...片手で...目隠し...



イノポリス大学



イノポリス大学の開発を支援し、それらの実現に貢献してくれたことに感謝します。 それ以前は、ネットワークに投稿されず、ローカルホストのみに存在し、ウィングで待機していた2つの製品がありました。 未来大学でのプレゼンテーションの後、新製品のアイデアが生まれました。 その結果、gamedev、ビデオ制作、プログラミング、映画を横断することで、IT大学のチームが、世界の誰もこれまでになかったほどエキサイティングな選択を示すのを支援しました。



近い将来



TypeScriptは 、 JavaScriptでは利用できず、後者の松葉杖を介して実装されるオブジェクトとクラスをサポートしているため、 TypeScriptにリファクタリングおよびリライトする予定です。さらに、パフォーマンスの点で高いコードを取得します。



モバイルブラウザとタッチスクリーンコントロールオプションで起動を検討する。



現在、約40分のタイミングでパイロットを準備しています。いくつかのストーリー展開とさまざまな「グッズ」があります。 遠い将来の計画では、ビデオを360で書き込み、製品をvrメガネに適合させるカメラをテストします。



そして、ここに約束されたリンクがあります



デモ版 （私たちは実際に殺されそうになった。勇敢な警察は本当の誘wasが起こっていると思った。午前4時に色のついたコンベア上のビジネススーツを着た4人の武装した道化師への反応は速かった。幸運なことに、20分の議論の後、カザン警察IT Parkのスタートアップに反応しました）。 この提携に基づいて、 現在のフルレングスプロジェクトを開発しています。



Be IT Heroは、 イノポリス大学向けに開発された製品版です。 未来の都市のどこにいても、そのような技術を立ち上げようとしていますか？



ご清聴ありがとうございました！