npm i
npm run dev

running localhost:8080

エントリーポイントとなるクラス。初期化とメインループによって構成されている。

• Update 毎フレームこの処理が実行される。パイプラインは以下の様になっている
  • EventManager.Update(); 登録されているグローバルイベント(後述)があれば実行する。
  • Game.state.getState().Update(); 現在の state における Update 処理を実行する。
  • Drawer.Renderer.render(Drawer.Stage); ゲーム中の全スプライトを描画する。
  • Audio.Update();
  • Timer.Update();

ゲーム中の UI を除く物体について管理するクラス。

• add / remove リストに追加/除外

• find(name) 指定した name を持つ entity の参照を配列で取得する。

player,enemy などゲーム中の物体。UI は別系統で管理されており、含まれない。 ECS に近い設計をしているが、component,system は明確には存在しない。

• name

• floor � 自身の床にあたる entity があればその参照を追加する。

• collider 衝突形状を指定する。現状 box しか使われていないが、サイズによって形状は異なる。

• AIList 挙動を追加するリスト

• Update() 毎フレームの更新処理。

「特定の箇所に行くとイベントが発生する」を実現する。これは透明な entity であるが、プレイヤーと衝突するとイベントを発行し自身が消滅する。一定の広さを持つ領域に eventTrigger を貼りたい場合は大量に設置するのだが、この時イベント発行が重複しないように、一度発行したものと同じ種類の eventTrigger は non active になる。

「壁にぶつかると跳ね返る」「近づくと攻撃体制になる」など、共通して用いられる挙動を分離したもの。 entity の AIList に追加することによって、entity は AI に追加された挙動を逐次 update する。

形状情報 collider を持つ entity 同士の衝突判定、応答を行う。 衝突応答関数は衝突したかどうかの真偽値、めり込み距離、法線などをもつCollisionInfoを返す。 衝突応答は本来 entity の更新とは別のフローでバッファリングして行われるべきだが、同じフローで逐次的に実行しているためバグっている。

AtomicDesign に近い形を採用している atoms は最小単位の UI , molecules は少しまとまった UI , pages はその画面全体の UI を指す

• constructor(pos,text,type) type は常にMESを指定していて、形骸化している

• ChangeText(text) テキストの表示内容を変更する。この関数にはバグが有り、なぜか座標が初期化される副作用を持っている。

自身に登録したローカルイベントを実行する。

現在一部の UI で試験的に導入しているシステムで、CSS,DOM に相当する JSON を記述すると UI 木が展開されて配置されるようになっている。しかし描画順を制御できない問題があり、実運用には至っていない。

EntityManager の UI 版。

• Clean() すべての UI を削除する
• CleanBack() **フェードインエフェクトを除く、**全ての UI を削除する。画面遷移時の幕の裏で UI を更新する用途の為。
• find(name) 指定した name を持つ UI を取得する。

UI アニメーションのように「ある時点から始まり、一定の時間実行され終了する」ような処理はコルーチンで記述するのが便利である。 現在イベントにはグローバルイベントとローカルイベントの 2 種類が存在する。

• グローバルイベント EventManager に Event を追加することによりメインループ内で処理される。 多くのイベントはこれ。

• ローカルイベント entity がイベントを持ち、自身の update によってイベントを処理する。

ゲームの持つ大域状態はSceneと呼ばれ、Scene はStateMachineによって管理される。 Scene が定義するものは初期化処理、入力処理、メインループの組である。 StateMachine は Scene の集合によって作られ、「現在の Scene」を保持しており、transit(scene)によって現在の状態を更新する。

• find(name) 状態集合の中から指定した name を持つ Scene を取得する。name は一意的でなければならない。

描画は PIXI.JS v4 である。(2020/1/8 現在) update と draw は別フローになっており、entity に紐付いてる sprite があればそれを描画する。 実は現在カメラを使っておらずレンダラが直接フォーカスする機能しかないため、entity としてのカメラを作る予定。

PIXI.js には sprite に親子関係をもたせる機能があるが、親の座標変換が子に適用される仕様となっており、サイズ(拡大率)を独立して指定したい需要には不向きである。そのため entity が親子関係を持ち、sprite は entity とは分離して記述される。

entity.layer に指定するレイヤー名によって指定されたレイヤーに描画される。 レイヤーは 7 種類ほどあり、レイヤーごとに拡大率やスクロール速度が微妙に異なる。

z 座標によって指定するのが望ましいが、現在はレイヤーの指定順によってのみ決定づけられる。 同じレイヤー間の描画順序は entity の登録順であるため、現状制御することは困難。

PIXI の提供する機能を使用している。uniform 変数の送信なども可能。

リソースは src/resource/以下

一枚の画像に複数の entity のアニメーションを書き、プログラム上で対応付を行うスプライトシート方式を採用している。大本となるスプライトシート、スプライトシート上の位置とリソース名を対応付けた JSON ファイル、リソース名から texture を作成する Art クラスから構成されている。 〇〇 pattern のようなファイルがスプライトシートに対応する。

マップデータは外部ツール tiled によって json 形式で作成する。json をパースし entity を配置することによってステージを作成する。

• 壁面自動対応 壁面は壁チップと呼ばれる特殊なチップを使用している。このチップは連続する壁チップが一塊の大きな壁となるように壁タイルをうまく自動で対応付けるものである。

文字はすべて画像。現在 1 種類のフォントしか扱えず、文字色や大きさを変更することはできない。 フォント名はかわせみゴシックかさいはてゴシックのどっちかにしようと思っている。

webAudioAPI をラップした Audio クラスで読み込みと再生を行う。再生時にボリュームとピッチを指定することができる。 状態として現在再生中のBGM名を持っている。 使用してはいないがローパスフィルタもある

• PlayBGM(name) name で指定した BGM を再生する。name に 0 を指定すると StopBGM()を実行する
• StopBGM() 現在 BGM が再生中であれば、 BGM を停止する。

• isKeyClicked(key) key が「押された瞬間のフレーム」だけ true を返す。
• isKeyPressed(key) key が押された瞬間のフレームに true を返し、その後しばらくの間 false を返し、続いて断続的に true を返す。 これは名前は知らないが、長押しを扱う入力インターフェースでよく見られる挙動である。

頻繁に使う数学系関数やキーコードの定数などを定義している。利便性を考慮し module ではなく直接 global に置いてある。

Param クラスに分離している

一回のメインループを時間の 1 単位とし、離散的な時間として扱う。 スローモーションを実装するため、連続的な時間も保持している

util のisDebugModeを true にするとデバッグモードになる。 Debug クラスの debugOption モジュールにオプションを記載する。(スコア 5000 点、全武器入手、攻撃力 5000 など)

煩雑な手続きを置く場所

• Pool

オブジェクトプールの実装であるが、実はボトルネックではないため実質廃止。 一部の Entity がまだ pool で管理されているため、統一したい

• distanceField

画像から距離場を作ってステージ生成したかったときの、試験的導入技術の名残