０、ステージエディタプロジェクトについて

　このたびBaseCrossではステージエディタを作成することにしました。
　ステージエディタと一言で言いましても、いろいろな考え方があるかと思います。
　GUIによるゲーム開発が主流になる昨今では、単なるステージエディタ（ステージの初期位置などを設定できるエディタ）がどのくらい必然性があるのかはわかりませんが、BaseCrossでは、現在のところ、ひたすらコードを書くしか、ゲーム作成の方法がありません。
　教育上の側面からは、それはそれで重要なのかもしれませんが、学生たちが実習のたびにオブジェクトの配置に手間取っている姿を見ますと、やはり、オブジェクトの配置くらいは何らかの方法でGUI化する必要があるだろうと考えた次第です。

　GUI化すると、決まって要望が上がるのがスクリプト（コード）を記述できるとよいといったものです。
　現在主流となっているUNITYやUnreal Engineは確かにそのような統合環境で制作します。
　実際のところ、プロの開発現場でもそのような統合環境での開発がほとんどで、コードをひたすら書くような現場もないと聞きます。
　これから作成するステージエディタがいったいどの方向を目指すのかは、実のところ、私もわかりません。
　教育上の側面を残しながら、それでもできるだけ便利なフレームワークを考えた場合、目指す場所をUNITYやUnreal Engineと同じ方向を向くのもベストとも思えません（とても追いつけるものではないと思いますし）。

　そこで、BaseCrossでは、ステージエディタの制作過程をできるだけオープンに、そして、途中の状態をステップとして残しながら制作を進めていこうと考えました。
　もちろんBaseCrossはGitHubに公開されていますから、コミットをさかのぼれば途中の状態を確認できます。
　しかしそれらはステップとして残されたものではなく、あくまで細かな実装の履歴です。
　Gitのコミットではなく、ある程度実装が済んだ状態のステップとして残すことで、例えばその状態から独自のステージエディタやゲーム作成ツールを、書けるような形をとろうと考えました。
　つまり、オリジナルな開発環境をどの状態からでも記述できるようにする、という形です。

　具体的には、以下のような方法で実装を進めていきたいと思います。 
１、各ステップごとにその状態のサンプルを公開する
２、最新のステップは更新される可能性がある（Gitのコミット）
３、各ステップが実装できたときにドキュメントを記述する
　このような形なので、ドキュメントに記述があるステップが、いわゆる公開された安定な状態となります。
　ですから、独自のエディタを作成したい場合はそのステップから実装を進められます。またそのことにより、BaseCross側のその後の実装を見比べることにより、自分の実装との違いを研究あるいか確認することができます。

　ちょっとややこしいですが、次項では最初のステップであるステージディタの雛形を紹介したいと思います。

　これから長い戦いがはじまります。なにかお気づきの点があればfacebookにでもお寄せください。