Bakeryのプロジェクトをリファクタする

ゴール

  • BakeryはModdableなサンドボックスゲームである
  • ゲームルールは確定ではないが、現状Rogue亜種になることを想定している
  • ユーザーはゲーム内の組み込みエディタでシナリオを作成してシェアできる
  • エディタはインゲーム中に常に動作させることができる
  • ユーザーは作成したシナリオとアセットをパッケージングして可搬させることができる
  • ユーザーはSchemeで記述されたスクリプトで自由にBakery自体を拡張できる, SchemeのREPLはユーザーに公開されている, プラットフォーム向けにコンパイルされたプログラムもロード可能でなければならない
  • Bakeryにはユーザーは自由にアセットを追加し、ゲームを停止させることなく組み込みのエディタで使用可能でなければならない, アセットが欠落した場合でもユーザーは安全にゲームを進行できるようにハンドリングされる
  • Bakery自体はオープンソースのプロジェクトである
  • (optional) Bakeryに参加しているユーザーがシナリオをシェアするために十分なコミュニティツールを準備するかもしれない

方向性決め

  • baseの部分はglfw, alureなどのAPIラップに近い状態に止める, 上位の処理はScheme側で実装する
  • Bakeryは根本からreactive programmingするために設計を考え直す
  • APIはElmをベースに設計する, Bakeryはアプリなのでユーザーが直接触ることは少ないがGUIベースでレベル設計をする際にreactiveな考え方が基礎になるようになる
  • プロジェクトの進行管理を行う, とりあえずtrelloを使ってみる予定

リアクティブに求めること

  • データフローの可視化, ステートマシンベースのエンジンだと時点計算状況は確認できるがデータフローは視認できないのでボトルネック(大量のデータが集中している処理)が判別が難しい
  • 作用元の明確化, 代入を前提とした手続き的な構文だとデータセルに対して作用元を特定することが困難になりやすい

リアクティブで考えること

  • 自動再計算, 再計算のコストは高いためスケジューラはアプリケーション側に任せてもよいかもしれない
  • 出力(Graphics, Audio), ElmはElement型によって出力を記述するが、同じ方向性で良いだろうか

上位層

  • リアルタイムが要求されるゲームを考えていないため、効率よりも拡張性を重視して実装する
  • サンドボックスだが、デフォルトの範囲で作成できる方向性には制限を設ける, Little Big PlanetやProject Sparkのようなものである
  • プラットフォームはPCのみに絞る, Rogue亜種で考えているため、キーボード操作が前提になる