🚵🏽 ✉️ 🎥 キャンバスアニメーションのオブジェクトのモデリング 👌🏾 🔅 🖲️

高速でシンプルなAPI、ブラウザのサポートがCanvasを魅力的なものにしています。しかし、よくあることですが、単純さは弱点でもあります。たとえば、長方形、円、線を描画したり、画像をぶら下げたりできます。しかし、この単純なベースで有用なコンテンツを開発することは、もう少し難しいタスクです。

画像-キャンバスの力

ゲーム開発の例では、ゲームオブジェクトのアニメーションと制御へのアプローチが示されています。

Canvasでゲームを開発しようとする動機は、次の2つの例でした。

例は実例ですが、数分ボールを落とし、半ダースのネットを引き裂いた後、興奮は消えました。陰謀、目的、意味はありません。最終的には楽しいですが、面白くありません。

はじめに

Canvasの操作については、 CanvasのHTMLページの公開で説明されています。一般に、アーキテクチャと開発ツールを含むまったく同じアプローチがここで適用されました。

FF（Windows、Linux Mint）、CR、およびIE（Windows）で互換性がテストされました。利用可能なガジェットのチェックもありましたが、結果はあまりありませんでした（詳細は最後にあります）。

GitHubコード：
アーケード
スポット
数十
Tetr

GitHubのデモ（オフラインモード）：
アーケード
スポット
数十
Tetr

ゲームはモデル管理です

ゲームは、ゲームモデル、モデル管理機能、モデル表示機能で構成されています。ゲームの究極の本質は、モデルを変更することです。

モデルはゲームオブジェクトで構成されます。基本的なプリミティブからのオブジェクト：長方形、円、線。

モデルとモデルのダイナミクスを提供する機能は、モデルの表示方法について何も知りません。 Canvas機能は、レンダリング時のモデルの静的状態を表示する方法のみを知っています。レンダリングプロセス中、モデルの変更は許可されません。幸いなことに、これに従う必要はありません（シングルスレッドのイベントループによって提供されます）。

Canvas APIはネイティブであるため、高速であり、多数の基本的なプリミティブをリアルタイムで表示できます。したがって、単純なオブジェクトの数（数十または数百）はCanvasにとってそれほど重要ではありません。ただし、JavaScriptで実装された複雑な計算オブジェクトは避けるべきです。同じことは、モデル変更アルゴリズムの実装に帰することができます。より簡単でネイティブであればあるほど（この場合はよりネイティブで、この場合はCanvas APIが考慮されます）、より優れています。ゲームのアイデアに従って、複雑なおよび/または時間のかかる計算アルゴリズムを実装する必要がある場合、そのような目的のために、Webワーカーを使用できます（ここでは考慮しません）。

モデルの設計は、最初から慎重に行う必要があります。開発プロセス中にモデルを大幅に変更する必要がある場合、コントロールと表示コードの再作業が必要になります。

モデル開発

テトリスは、アプローチをテストするための良いデモを作成しました（ここでは、私は最初とはほど遠いです）。

モデルコンセプト：

色の付いた細胞で構成されるブロックはウェルに落ち、共通のプールに入ります。いっぱいになったプールの行が削除されます。井戸がいっぱいになり、新しいブロック用の空きスペースがなくなると、ゲームは終了します。
ブロックは回転および水平方向に移動できます。回転と移動は、井戸の空きスペースでのみ可能です。ブロックが回転し、ウェルプールがいっぱいになると、セルの色が保持されます。
基本オブジェクトはセルです。セルのサイズはピクセル単位です。このサイズは、Canvasでのすべてのレンダリングの基準となる主なベースです。
ウェルは、セルで構成される仮想グリッドです。ブロックおよびプール管理-ウェル内のセルの列番号と行の変更。

ウェルとセルサイズの説明：

APELSERG.CONFIG.SET.CellSize = 20; //      APELSERG.CONFIG.SET.WellColumn = 5; //      APELSERG.CONFIG.SET.WellRow = 20; //

基本オブジェクト（セル）：

 APELSERG.MODEL.Cell = function (cellRow, cellCol, cellColor) { this.Row = cellRow; //     this.Col = cellCol; //     this.Color = cellColor; //  }

オブジェクト（ブロック）：

 APELSERG.MODEL.Block = function (blockType) { this.type = blockType; //     this.idx = 0; //     ( ) this.cells = [[], [], [], []]; //     }

ブロックモデルの冗長性は見えますが、これにより、2つのタスクが解決されます。1。すべての状態を持つブロックが一度に形成されます（ブロックをさらに管理するのは簡単です）。 2.ブロックを回転しても、セルの色は保持されます。

ブロックはゲームモードで作成されます。

 APELSERG.MODEL.GetNewBlock = function() { var newBlock = APELSERG.CONFIG.PROC.NextBlock; //       APELSERG.CONFIG.PROC.NextBlock = APELSERG.MODEL.GetBlock(); //   -   if (!APELSERG.MODEL.CheckBlockCross(newBlock)) { // ,     APELSERG.CONFIG.PROC.GameStop = true; //   window.clearTimeout(APELSERG.CONFIG.PROC.TimeoutID); //   APELSERG.CONFIG.SetResult(); //   } return newBlock; }

新しいブロック：

 APELSERG.MODEL.GetBlock = function() { var blockType = APELSERG.MODEL.GetBlockType(); //     var newBlock = new APELSERG.MODEL.Block(blockType); //     var newColor = ""; //   var baseRow = 1; var baseCol = Math.round(APELSERG.CONFIG.SET.WellColumn / 2); switch (blockType) { case 101: //-- [1] newColor = APELSERG.MODEL.GetCellColor(); newBlock.cells[0][0] = new APELSERG.MODEL.Cell(baseRow, baseCol, newColor); newBlock.cells[1][0] = new APELSERG.MODEL.Cell(baseRow, baseCol, newColor); newBlock.cells[2][0] = new APELSERG.MODEL.Cell(baseRow, baseCol, newColor); newBlock.cells[3][0] = new APELSERG.MODEL.Cell(baseRow, baseCol, newColor); break; //

ここで、任意の構成のブロックを追加できます。主なことは、新しい型をブロックに割り当て、この型をAPELSERG.MODEL.GetBlockType（）関数の配列に追加することです。

モデル管理

管理は一般的な方法でキーボードから行われます。

 window.addEventListener('keydown', function (event) { ... }

ブロックは（window.requestAnimationFrameではなく）タイマーによって分類されます。 APELSERG.CONFIG.SET.LevelTick配列には、現在のレベルの期間の値が格納されます。

 APELSERG.MAIN.Animation = function (makeStep) { if (makeStep) { APELSERG.MODEL.BlockShift('DOWN'); //     -       } APELSERG.CANVA.WellRewrite(APELSERG.CONFIG.PROC.CellPool); if (!APELSERG.CONFIG.PROC.GameStop && !APELSERG.CONFIG.PROC.GamePause) { APELSERG.MAIN.RequestAnimationFrame(function () { APELSERG.MAIN.Animation(true); }); } } APELSERG.MAIN.RequestAnimationFrame = function (callback) { if (APELSERG.CONFIG.PROC.FastDownFlag) { //    DOWN APELSERG.CONFIG.PROC.TimeoutID = window.setTimeout(callback, 10); } else { APELSERG.CONFIG.PROC.TimeoutID = window.setTimeout(callback, APELSERG.CONFIG.SET.LevelTick[APELSERG.CONFIG.SET.Level]); } }

ブロックが特定の方向に移動または回転できるかどうかを確認するために、仮想ブロックが作成され、条件がチェックされます。検証条件が満たされると、実際のブロックは新しい場所に移動されます。検証機能：

 APELSERG.MODEL.CheckBlockCross = function(block) { var canShift = true; //--    //-- for (var n = 0 in block.cells[block.idx]) { if (block.cells[block.idx][n].Col < 1 || block.cells[block.idx][n].Col > APELSERG.CONFIG.SET.WellColumn || block.cells[block.idx][n].Row < 1 || block.cells[block.idx][n].Row > APELSERG.CONFIG.SET.WellRow) { canShift = false; break; } } //--    //-- if (canShift) { for (var n = 0 in block.cells[block.idx]) { for (var q = 0 in APELSERG.CONFIG.PROC.CellPool) { var cell = APELSERG.CONFIG.PROC.CellPool[q]; if (block.cells[block.idx][n].Col == cell.Col && block.cells[block.idx][n].Row == cell.Row) { canShift = false; break; } } if (!canShift) { break; } } } return canShift; }

ブロックオフセットは、セル番号の単純な計算によって発生します。

 APELSERG.MODEL.ShiftBlockColumn = function(block, num) { for (var x = 0 in block.cells) { for (var n = 0 in block.cells[x]) { block.cells[x][n].Col = block.cells[x][n].Col + num; } } }

底に達すると、APELSERG.MODEL.DropBlockToPool（）関数を使用して、ブロックのセルがウェルプールに移動されます。この場合、ポイントが付与されます。

実装された機能ですが、私の意見では、あまり成功していませんでした（設定にはありません）：

APELSERG.CONFIG.PROC.FastDownFlag = false。 trueに設定すると、落下は瞬時ではなく、視覚化されます。
APELSERG.CONFIG.SET.ShowFullRow = false。 trueに設定すると、塗りつぶされた行が削除前に表示されます。
APELSERG.CONFIG.SET.SlideToFloor = false。 trueに設定されている場合、リセット後のブロックは床を横切って「スライド」し、タイマーの目盛りだけでプールに移動します。

キャンバスのレンダリング

APELSERG.CANVA.WellRewrite（）関数は、Canvasでモデルをレンダリングします。それは非常にシンプルで、よく文書化されています。彼女が行うことは、キャンバスをクリアし、モデルプリミティブを順次レンダリングすることだけです。

ユーザーインターフェース

設定、結果、ヘルプ

モデルが実現した後、全体的なゲームでは復活したモデルでは不十分であることが明らかになりました。そこで、UIモジュールが登場しました。

APELSERG.UI。設定、結果、およびヘルプへのインターフェイスを提供します。
APELSERG.LANG。ローカライズを容易にするため。

これは典型的な動的DOMであり、おそらく最も成功したものではありません（コードは単純なので、説明しません）。

ローカルストレージ

ゲームへの関心を維持するには、設定、結果を保存する必要があり、場合によってはオフラインモードが便利です。ストレージには、localStorageが使用されます。技術的には、すべてが標準的な方法で実装されていますが、グローバルオブジェクトAPELSERG.CONFIG.SETおよびAPELSERG.CONFIG.RESULTとの接続をトレースすると便利です。

いくつかのメモ：

各ドメインは独自のlocalStorageを使用します。
localStorage.clear（）は慎重に使用してください-現在のドメインのすべてのlocalStorageをクリアします。

設定は2つのオブジェクトに保存されます。

CONFIG.SET-アプリケーションの起動時に適用される静的設定（localStorageに保存）。
CONFIG.PROC-アプリケーションの操作中に適用される動的設定（localStorageには保存されません）。

ストレージの名前は一意である必要があり、いくつかの静的変数の組み合わせから形成されます。

 APELSERG.CONFIG.SET.Version = "0-1-0" APELSERG.CONFIG.SET.LocalStorageName = "APELSERG-ArcadPlain"; APELSERG.CONFIG.GetLocalStorageConfigName = function () { return APELSERG.CONFIG.SET.LocalStorageName + "-Config-" + APELSERG.CONFIG.SET.Version; }

設定は変更されると保存されます。これは単純に行われます（別の関数がプルされない場合でも）。 APELSERG.UI.ApplySettings（）関数（UIモジュール）に、次の2行が追加されます。

 var configName = APELSERG.CONFIG.GetLocalStorageConfigName(); localStorage[configName] = JSON.stringify(APELSERG.CONFIG.SET);

アプリケーションが起動すると、localStorageに保存されている構成の存在が確認され、構成が保存されている場合は復元されます。

 APELSERG.CONFIG.GetConfigOnLoad = function () { if (APELSERG.CONFIG.PROC.LoadFromWeb) { var configName = APELSERG.CONFIG.GetLocalStorageConfigName(); if (localStorage[configName] !== undefined) { APELSERG.CONFIG.SET = JSON.parse(localStorage[configName]); } } }

LocalStorageが空であるか、まったく使用されていない可能性があります。 LocalStorageは空です：1.最初の起動時。 2.保存されていない場合。 3.クリーニングされている場合。多くの場合、主に開発プロセス中に構成をクリアする必要があります。たとえば、構成が変更されました-変数が追加または削除され、アプリケーションは、古い構成オブジェクトがストレージから復元されるため、変更が表示されないかのように動作し続けます。

アプリケーションがローカルディスクから起動された場合、ローカルストレージは無効になります。これは、ブラウザーがこのモードをあまりサポートしていないためです。ただし、アプリケーションの残りの機能は保持されます。ローカルディスクからの起動は、起動時に制御されます。

 window.location.protocol == "file:" ? APELSERG.CONFIG.PROC.LoadFromWeb = false : APELSERG.CONFIG.PROC.LoadFromWeb = true;

結果はAPELSERG.CONFIG.RESULTに保存されます。機能的には、結果の保存は設定の保存と同じです。

オフライン作業

オフラインモード（アプリケーションキャッシュまたはAppCache）を使用すると、インターネットがオフの場合でもWebアプリケーションでの作業を継続できます。一般に、さまざまなオフライン条件の設定は非常に複雑になる可能性があります。しかし、私たちの場合、これは最も簡単な手順の1つです。

オフラインモード用のマニフェストファイル（game_arcad_plain.appcache.txt）を準備する必要があります。

キャッシュマニフェスト
 ＃Ver 0.1.0
 ＃001
 game_tetr_plain.htm
 game_tetr_plain_canva.js
 game_tetr_plain_config.js
 game_tetr_plain_lang.js
 game_tetr_plain_main.js
 game_tetr_plain_model.js
 game_tetr_plain_model_blocks.js
 game_tetr_plain_ui.js

WebページのHTML要素にこのファイルへのリンクを追加する必要があります。

 <html manifest="game_arcad_plain.appcache.txt">

拡張子が「txt」の薄い瞬間。 MIMEタイプtext / cache-manifestの拡張子appcacheまたはmanifestが推奨されます。これは、 ~~遅延で~~好奇心が強いため、デモで行われます。

サーバーの主導でクライアントにファイルをリロードするには、「＃001」が必要です。サーバー上のファイルが更新された場合、マニフェストファイルが変更されるまでクライアントに到達しません。そして、その中で何を変更できますか？ -「＃002」に関するコメント。

その他のゲーム

最初のゲームが開発された後、残りのゲームはモデルに刻印されました。コードの約80％は同じままで、変更は主にモデルのみに関係していました（モデルと制御コードがより単純になりました）。したがって、いくつかのニュアンスを除いて、これらのゲームを個別に説明するのは意味がありません。

これらのゲームには常に移動するオブジェクト（ボール）があるため、アニメーションはwindow.requestAnimationFrameで行われます。
時間間隔の変化によるものではなく、XとYに沿った座標の増分の変化によるボールの動きは遅く/速くなります。時間間隔は測定されません（ただし、良い方法では必要です）。
リバウンドは、直径を考慮して、ボールの中心から計算されます。加速度と方向はランダムに選択されます。逆の動きでは、ボールはラケットを見えません。ブロック/ラケットの厚さは、ボールのサイズよりも薄くすることはできません。さもないと、高速では貫通が発生する可能性があります。

簡単なテストの概要

どちらが良いですか：

キャンバスアニメーションは簡単です。このモデルにより、Canvasの操作がさらに簡単になります。
ローカルストレージとバッテリー寿命は使いやすいです。

あまり良くない：

Canvasはタッチスクリーンの親友ではありません。アプリケーションがタッチスクリーンに応答しても、すべて同じように、20インチディスプレイでのマウスクリックの動作と、スマートフォンの画面で指を突くときの動作は異なります。したがって、デモゲームは主にデスクトップシステムでの使用を目的としており、コントロールはキーボードに焦点を合わせています。ポジティブなことは、比較的シンプルで機能するデスクトップアプリケーションがあれば、さらに適応を進めることができるということです。
キャンバスは、定期的に少し遅れます。戦うためのメカニズムはありません。

便利なリンク

HTML5 Canvas
HTML5ローカルストレージ
HTML5アプリケーションキャッシュ

キャンバスアニメーションのオブジェクトのモデリング