こんにちはHabra！



この記事は、StalinGradゲームエンジンに関する一連の記事の続きです。 前回の記事ではDHTMLをレイプしましたが、この記事ではアーキテクチャとプロトタイプをレイプします。



実際にはコードはないので、Web開発者でない場合は、アーキテクチャとOOPについて読むことができます。 そしてまだはい-HTML5については何もありません。DHTMLハードコアのみです:)







すぐに短いデモ：

例1-パラレルワールド

例2-異なるカメラからの1つの世界

例3-ボット

例4-ナンカット、クラウド、ポータルガン

作業ロジック

どういうわけか私は男がバーを回って別の人と話すようなクエストを書きたかった。 そして、このバーのイベントと人はランダムに生成され、プレーヤーの前に新しいゴールが現れるたびに。



このjavascriptの実行方法は？ ほとんどの場合、これは次のようになります。画面と、画面の一方の端からもう一方の端に移動するキャラクターがあります。







実装は非常に簡単です。 しかし、バーが画面よりも大きい場合はどうでしょうか？ 次に、このスキームを考え出すことができます。画面があります-これはポジショニング付きのDIV1です。 この内部には別のDIV2があり、DIV1よりも大きく、相対的な親によって配置されます。 DIV2-これは私たちのレベルです。 バー内のすべての人とオブジェクトはDIV2内にあり、その左端から配置されます。



スキームの実装は基本的に簡単ですが、必須ではありません。 これは絶対に間違ったアプローチです。 バーに1000個のオブジェクトがある場合はどうなりますか？ 私たちは、時間の経過とともに苦しむことができる非スケーラブルな基盤を得ます。



私は2Dゲームの作り方に関する情報を探し始め、HTML5ゲームに関するHabrの記事をたくさん読みました。 残念ながら、私が読んだすべての発見された記事では、単一のアルゴリズムやアーキテクチャへの参照はありませんでした-ワンタイムゲームのスクリプトだけです。 この事実は私を悲しませました、そして、私は職場の人に彼らがどう思うか尋ねました。 私の同僚であるVitaliy Nikitinは、「Secrets of Game Development in macromedia Flash MX」（Jobe Makar著）という本を読むことを勧めました。 これはすべてこれから始まりました。







本は素晴らしいことが判明しました。 Flashに関するすべての点をスキップすると、アルゴリズムとロジックについて多くを学ぶことができます。 少なくとも私にとって、ゲーム開発者のエンジンと経験について何も知らない人として、この本はただの啓示でした。



知識が得られると、ゲームのアイデアが広がり、先進国でゲームを書くという切望がありました。 最初に、すでに市販されているJavaScriptのゲームエンジンを調べました。 私は多くの人が通常のドキュメントを持っていなかったという事実に注意を引きました。 ハードコアオプション-も見つかりません。 しかし、ジョブマカーとイグロストロイの経験の論理に従って、ハードコアのレベルは法外なものにすることができます。



何が欲しかった？ マリオ、キャラバンを殺す/強姦する/奪うことができるようになります。 なすべきこと：

• 天気を追加
• テレポートする能力
• ガントリーガン
• 重力銃
• 一般的に、多くの異なる銃とナイフ
• 交通機関で旅行する可能性
• 輸送の燃料が限られており、燃料を補給できるように
• 天気
• 昼と夜
• ナルコとアルコの旅
• Minecraftのようにビルドできるように
• 各プレイヤーのカルマ
• そして他の多くの楽しさと面白いもの。

そしてそれは特徴的です-リスト全体がすでに実装されており、現時点ではさらに多くのチップを追加して実装したいという要望があります。



ある時点で、ゲームを書くことができないことに気付きました。 このことはどんどん大きくなっていますが、論理的な終わりはありません。 それから、すべてを説明し、インターネットに掲載して、誰が興味を持っているかを確認することにしました。 ドキュメントの書き始め-多くのことがうまく機能していないことに気付きました。 はい、APIは単純化できますし、そうすべきです。 しかし、本質と主なアイデアに戻りましょう。



ゲームは3つのオブジェクトで構成されます。



最初のオブジェクトは、アクションが発生する世界です。 世界にオブジェクトを配置したり削除したりできます。 次に、世界はすべての衝突、力、およびイベントを監視します。 また、オブジェクトに追加の影響を与えることもできます（たとえば、重力の設定）。



2番目のオブジェクトは、まさにこの世界にいるキャラクターです。 そしてここでは、これが生き物である必要はまったくありません。 それは箱、樽、壁、弾丸、あらゆる石、または何か他のものでありえます。



第三に、カメラ。 世界を見るにはカメラが必要です 前の2つのオブジェクトは排他的にマットです。 抽象化され、決して感じられません。







これらの3つのオブジェクトは何を提供しますか 膨大な数の平行世界を作成し、 異なる場所から 1つの世界を見て、多くのキャラクターを1つの世界に押し込む能力。







異なる世界の創造はどのような問題を解決しますか？ コードをサーバーに転送し、ネットワーク経由でゲームモードを完了できます。 実際、世界は配列であり、それを提供するいくつかのメソッドです。 DOMでは機能しません。つまり、DOMがどこにあるかは関係ありません。 さらに、世界を生成することにより、同時に存在する並行世界を持つゲームを作成できます。



さまざまな世界とカルマを持ち、生活をゼロにした後、キャラクターをメインの世界から世界の「楽園」または世界の「地獄」に移動し、非線形プロットを作成できます。 また、 世界は並行して存在します。ある世界のキャラクターが別の世界にテレポートし、そこで戦争を開始するイベントの発展の可能性があります。



上記のアーキテクチャは、最も純粋な形式のOOPです。 したがって、エンジンの中核は、プロトタイプ上のプロトタイプ、ユビキタスなカプセル化、およびモジュール性です。 この形式で考え始めると、ゲームのアーキテクチャはまったく異なる観点からのものであるように思われ、多くの追加の質問が発生します。



拡張性



男がいて、マシンガンを拾って車に乗り込みます。 別の男がバズーカから彼を撃ちます。 誰が何で死ぬのでしょうか？ 彼らはどうやって死ぬのでしょうか？

• ロケットが車まで飛んで、衝突が発生します。 再帰は、囲まれたオブジェクトの検索（これらの乗客からの乗客と物の検索）を通過し、車内のすべてのオブジェクトが破棄されます。 その後、マシン自体が破壊されます。 この回路が最初に思い浮かびます。
• ロケットが車まで飛んで、衝突が発生します。 温度/損傷ゾーンが増加します。 すべてのオブジェクトが破損しています。 オブジェクトに与えられたダメージよりもオブジェクトが強い場合、オブジェクトは世界に残ります。 このスキームはより論理的に思われ、スケーリングの可能性がより多くあります（たとえば、損傷ゾーンを拡大して爆発波を得ることができます）。
• スキーム2、ネストされたオブジェクトの場合のみ、ネストの程度が考慮されます。 オブジェクトがネストされているほど、保護されていることがわかります。
• スキーム2、車の追加の燃料損傷のみが考慮されます。 ロケットによる損傷+車の燃料爆発による損傷をもたらします。 このようなスキームはより現実的です。

天気はどうですか？



天気はバックグラウンドで回転しているものです。 プレーヤーに影響しますか？ 風のあるゾーンは重力のあるゾーンであると言うことはできますか？ セーリングプロパティを異なるオブジェクトに設定し、それらに風力を掛けるべきですか？ 経路に障害物（壁など）が付いている風を止める方法、もし重力であれば、壁は明らかにそれを止めませんか？



これらの質問のそれぞれに対する正しい答えは、長期的には非常に有益です。 ソリューションは可能な限りシンプルで普遍的である必要があり、そのベースに基づいて、さらにいくつかのソリューションを実装したり、以前は考えもしなかった機能を追加したりすることができます。



たとえば、武器はタイプと機能に分類されます。 既製の方法と機能を使用して、構築モードに基づいて、弾薬と砲弾を発射する機能が追加されました。 実際、キャラクターの前にレンガではなく発射体を構築し、発射体の初期速度を設定します。







カメラのサイズ（画像が表示される画面のサイズ、つまり世界の表示領域ではない）を設定できるという事実に基づいて、ズーム機能は非常に簡単に実装されました。 別の変数mdashへのタイマーのリンク。 停止/開始ボタンをカメラに追加して、ワールドのレンダリングを停止できるようにしました。

世界のオブジェクトをデザインします

ワールドに追加されるオブジェクトには、必要な標準プロパティが必要です。 例：座標、サイズ、ID、クラスとタイプ、レンダリング方法。 これらはいわゆる標準プロパティであり、絶対にすべてのオブジェクトがそれらを持っています。 さらに、オブジェクトのクラスとタイプに応じて、追加のプロパティとメソッドがそれにかかっています。



例：

• 背景は何も取得しません、なぜなら 彼は他に何も必要としません。 誰も背景と対話しません。
• キャラクターは、物理パラメーター（質量、加速度、強度など）、バックパック（空の配列、後で物のIDを追加できます）、生体の特性（脳の種類、生命、評価、カルマなど）およびなど
• 車はキャラクターとほぼ同じプロパティとメソッドのセットを受け取りますが、車両の特別な特性（燃料供給、燃料消費、乗客収容量など）もあります

同じプロパティとプロトタイプを持つ膨大な数のオブジェクトを作成するために、エンジン内にオブジェクトのファクトリーがあります。 タイプに応じて、各オブジェクトには一連の構成があります。 次に、2つの配列があります。プロパティの配列とプロトタイプの配列です（実際、これらは配列ではなくオブジェクトでもありますが、これはすでにJavaScriptのOOPの一部です）。







オブジェクトを作成すると、（構成によると）ファクトリはそのプロパティパッケージとプロトタイプパッケージを継承します。 工場のようなものがあります。 これは、任意のオブジェクトをアセンブルし、プロパティとプロトタイプのセットを与えます。

武器を設計します

火の種類に応じて、武器は3つのタイプに分けられました。



影響を受けた領域で。







射撃範囲に応じて、キャラクターの前に敗北ゾーンが作成されます。 次は、影響を受けたエリアに落ちたすべてのオブジェクトです。 それらから、キャラクターに最も近いオブジェクトが選択されます。 被害者が見つかると、武器の種類に応じて被害を受けます。



同様のアルゴリズムはピックを使用します。 ここに例を見ることができます



発射物オブジェクトの作成。







キャラクターの前に、発射物のオブジェクトが作成され、重力の効果が無効になります。 発射物は飛ぶとオブジェクトとの衝突をチェックします。 彼がキャラクターに出会うと、発射体は消え、キャラクターは損傷を受けます。



同様のアルゴリズムは銃を使用します。 ここに例を見ることができます。



空き容量チェックあり。







これは、構築モードに必要な特殊なタイプの撮影です。 撮影時、素材のブロックが作成され、キャラクターを配置できる空きスペースが検索されます。



同様のアルゴリズムが構築に使用されます。 ここに例を見ることができます



近接武器の作り方



ここではすべてがシンプルです-すべての剣、ナイフ、ピックは最初の原則に従って動作します（敗北ゾーンを使用）



速くて遅い武器を作る方法



連射武器は第一原理に従って機能し、すぐにダメージを与えます。 遅い武器（ロケットなど）-2番目に、シェルの衝突が待ち受けています。



重力銃の作り方



射撃は最初のタイプに従って行われますが、すべてのオブジェクトにダメージを与える代わりに、追加の加速が適用されます。 その方向は、撮影モードによって異なります（自分に向かって、または自分から）。



重力銃の例はこちらにあります。







ポータルガンの作り方



ブロックの構築と同じ方法で-第三の原理に。 違いは1つだけです。銃は、作成されたポータルを2番目に作成されたポータルにバインドするために、作成されたポータルへのリンクを保持します。



ポータルガンの例はこちらにあります。



ポータルガンをアップグレードする方法



なぜなら 2つの異なる世界の間にポータルを投げることができます。その犠牲者を別の世界、またはマップの反対側に投げる銃を作成できます。 ポータルガンではなく、テレポートガンになります

カメラの実装方法

カメラオブジェクトはどのような問題を解決しますか？ なぜなら Canvasはどこでも動作しません（電子書籍でゲームをポンピングする見込みはまだ私を引き付けます）。私はレイアウトを使用して世界を描くことができるカメラを作ることにしました。 あなたが言う中毒？ おそらく、しかしそれはどこでも動作します。 現時点では、カメラは背景付きの画像とdivを描画できます。 必要に応じてすべてをキャンバスに変換することは問題ではありません。 必要なことは、いくつかのレンダリング関数を書き直すことだけです（実際、ただの楽しみのために、一般的にテキストレンダリングを行うことができます）。 私の友人は、キャンバスなしではすべてがハングするだろうと絶えず言っていました。 シェーダー...何とか...何とか...何とか... HTML5 ...など -しかし、それは判明しませんでした。 当初、カメラは確かにハングしていましたが、そのたびに問題はその中にではなく、世界の計算アルゴリズムにありました。







仕事の同僚に仕事の計画を見せたとき、彼はカメラがすぐに全世界を描き、DOM要素を永久に作成したり削除したりしないようにすべきだと言った。 これは完全に誤解です。 世界には40個のオブジェクトがあると仮定します。つまり、40個のDOM要素を操作する必要があります。 さて、大丈夫、これはそれほど多くなく、ブラウザはブレーキなしでそれらを表示することができます。 そして、私たちが世界に千のオブジェクトを持っているとしたら？ このロジックに従って、1000個のDOM要素を作成し、ブレーキをかける必要があります（ただし、画面上には、現在は収まらないため、まだ30個しかありません）。



カメラは世界のオブジェクトです。 寸法と座標があり、他のオブジェクトとそれ自体の衝突を常に探しています。 それに遭遇した人は誰でも目に見えるオブジェクトの配列に入り、ディスプレイ上に作成されます。 オブジェクトがカメラのスコープを超えると、その表現は破壊されます。



現在、世界は写真とdivの2つの方法でレンダリングされています。 どちらの方法でも、レイアウト全体が配置される親divの形式の単一の表示が適切です。 将来的には、キャンバスを介してさらにレンダリングを追加できますが、現時点では特別な必要性は見当たりません。 さらに興味深いタスクがあります。



もう一つの興味深い点。 ゲームのレンダリングはすべてmdashであるため、 それはレイアウトであり、タイプセッターは（経験が浅い場合でも）CSSファイルを簡単に修正して写真を置き換えることができるため、オブジェクトの外観がまったく異なります。 たとえば、 ニットの世界を作成できます（比較のために、 通常の ）。



画像とdivの選択方法は？



まあ、それは状況に依存します。



大きな画面と非常に長いオブジェクトがある場合は、背景のあるdiv（たとえば、レンガの壁）で描画する必要があります。 見栄えがよく、DOM要素は1つだけです（ディスプレイ上のDOM要素が少ないほど、レンダリングの速度が遅くなります）。



小さな画面またはアニメーションのあるオブジェクトがある場合は、imgを使用して描画する必要があります。 画像のアドレスを変更することで、アニメーションを再作成できます。さらに、圧縮された画像は適切に見えます。



画面上のすべての要素は厳密にパーセントで設定されているため、画面はゴムであり、どのような形でもどこでも引っ張ります。 表示領域の比率、画面のアスペクト比など。 カメラオブジェクトの作成時に設定できます（ドキュメントを参照）。



また、カメラはそれ自体が独立したオブジェクトであり、世界のキャラクターに関連付けられていないことも理解する必要があります。 ただし、各カメラには、世界の別のオブジェクト（キャラクターに限らず、レンガに取り付けることもできます）にバインドするバインドメソッドがあります。 このようなオブジェクトインターフェイスを使用すると、異なるプレイヤー間でカメラの切り替えを簡単に実装できます（カウンターストライクで相手を見たことがあります。



カメラオブジェクト自体にどのような利点がありますか？







明らかに、固定アスペクト比でフルスクリーンでdivを取得できます。 カメラを主な目的で使用する必要はありません。このオブジェクトは、古いゲームを復元するのに役立ちます（たとえば、バックギャモン用に完全に正方形のボードを任意のアスペクト比で取得するため）

エンジンの使い方

このゲームエンジンは、次の2つの方法で使用できます。

• それに基づいて新しいゲームを作る
• 共通モジュールを使用して古いゲームを復元する

新しいゲームを作成するには、4つの主要なコンポーネントが必要です。

• 世界。 すべてのオブジェクトは世界にあり、プロットは開発中です。 ワールドは、オブジェクトの衝突とアクションを監視します。 世界はすべての物理学を支配しています。
• カメラ。 カメラはあなたに世界を見せたり、キャラクターを追います。 カメラのおかげで、私たちは世界で何が起こっているのかを知ることができます。
• キャラクター。 キャラクターは、私たちが世界に置くオブジェクトの1つです。 また、周囲、敵、武器などを世界に追加します。
• ジョイスティック。 キャラクターをコントロールするには、ジョイスティックをそれに付ける必要があります。 ジョイスティックをコンピューターに渡すと、彼はキャラクターを制御できるようになります。

なぜなら いわゆる「工場」で上記のすべてのコンポーネントを取得すると、無制限の数量でそれらを作成できます。 たとえば、交差しない3つのワールドを作成できます。 または、1つの世界に向けて5人のカメラが異なるキャラクターの目を通して見ることができます。



ただし、いくつかの制限があります。たとえば、オブジェクトは1つのワールドにしか配置できません。そうしないと、オブジェクトの動作が不十分になります（異なる世界のイベントに応答します）。

エンジンの一般的なスキーム

スキームの説明

• カーネルは、一般的な機能（DOM要素のクラスの作成/削除/置換、IDの生成、イベントの割り当てなど）を含むファイルです。
• 世界の工場-すべてが起こる世界を作ります
• Camera Factory-世界で何が起こっているかを示すカメラを作成します
• Object Factory-ワールドに追加されるキャラクター/アイテム/武器/環境を作成します。 また、ファクトリはオブジェクトを復元できますが、その詳細については以下をご覧ください。
• オブジェクトの構成-オブジェクトファクトリには非常に多くの設定があるため、その一部は別のファイルに移動されます。 すべての設定が行われないのはなぜですか？ すべてのオブジェクトの基本設定を壊したり変更したりすると、オブジェクトが無効になり、ワールドがそれらを自分自身に追加しないためです。
• さらに、工場で作成されたものはすべて単一のレジストリに分類されます。 オブジェクト間のリンクを削除するために必要です。 誰かが誰かを必要とする場合-彼はレジストリから被害者を求め、彼のIDを示します。 そのため、たとえば、キャラクターは物のIDのみをバッグに保存し、物自体は必要に応じてレジストリから取得します。
• 次は、特定のファクトリオブジェクトで動作するモジュールのグループです。 たとえば、世界の場合：
• 天気-天気の設定を処理します
• マップ処理-指定されたパラメーターに従ってマップを作成します。 マップエディターでこのようなパラメーターの文字列を取得できます。
• ワールド内のオブジェクト（もの/キャラクター/障害物）：
• Mission Manager-キャラクターと彼のミッションを監視します。 ミッションが正常に完了すると、任意のアクションを実行できます。
• 評価-世界中のプレイヤーの評価を行います。
• クラン-クランに関連するすべてのことを担当します。 クランをプレイヤーに追加したり、クランのリストを発行したりできます。
• Bag Factory-キャラクターのものと連携できるオブジェクトを作成します。
• Joystick Factory-キャラクター用のコントローラーを作成します。
• Brain-キャラクターを制御します。 そこにキャラクターを投げると、彼のためにジョイスティックが作成され、彼の脳のタイプに応じて、コンピューターがそれを制御します。

ロードおよび保存モジュールもあります。 保存されると、ワールド内のオブジェクトの配列をJSONに変換し、ロードされると、ファクトリー内のすべてのオブジェクトを復元し、レジストリを更新します。



なぜなら 私は数日以内に記事を書きました-論理的な矛盾があるかもしれませんので、そうでない場合は申し訳ありません。 ここでもう少し調べることができます。 次の記事では、ゲーム開発に必要なリソースだけでなく、APIを解析するためのより多くの練習を行います。



また、これらの仲間の仕事に慣れることをお勧めします。

BEM： 「ファイルシステムの編成」および「作成の歴史」

CSSフレームワークに関するVadim Makeevのスピーチ

アンドレイ・コロトコフのチャンネルで 、普通の男性がどのように建築を見たのか

チェリャビンスクでのミーシャ・ダヴィドフによるスピーチ

Job Makarの本「Macromedia Flash MXのゲーム開発の秘密」

ミシャ・カディコフによる一連の記事 「レベル設計。 理論と実践」



UPD：エフェクトのハブのためにデモのあるサイトが鈍り始め、アニメーションがロードされない場合があります（ロード制限を超えています）。 これはバグではなく、機能です:)次の記事の料金プランを変更します。