これは何？†
- 「この記法で幸せになっている人が誰も居ない」とまで言われている、surfaces.txtの記法、いわゆるSERIKO文法。これを少しでもマシにしてみよう。
- 最小限の変更で最大限の効果を
- 小さく生んで大きく育てる。大きすぎる変更で立ち消えさせない。段階的改善で確実に。
改善案その1†
- 各サーフィス用で共通の記述をすることが多いが、コピー＆ペーストする以外に共通化する方法がない。
- 共通箇所に変更があると、コピペしなおしになる
- コピペしなおしは、やり忘れミスを起こしやすい
- エディタの一括置換だと、誤爆置換の可能性がある（偶然同じ表記が他でありうる）
打ち手†
- サーフィス定義に「基底-継承」の関係を導入してみよう。
- プログラマ向け説明：サーフィス定義をクラスと見なし、継承で共通部分を一括表記しよう。
- Webデザインの出来る人向け説明：スタイルシートを.cssファイルで全ファイル共通部分を書き、各htmlファイルで上書き変更したり追加したりするように、共通定義用サーフィス定義とこれを踏まえて上書き・追記できるようにしよう。
- 継承を指定すると、surfaceYYYの定義は、継承元として指定したsurfaceXXXの定義がコピーされた状態になる。
- surfaceYYYの定義に、animation、element、collision等で継承元のサーフィスと異なる部分や追加したい部分を書くと、surfaceXXXの定義に上書き定義or追記した状態になる。
- この例の前提条件
- \0はサーフィス0からサーフィス9を使用する。
- キャラクタの姿勢はサーフィス0から9までほとんど変化せず、表情のみ違う。
- 表情サーフィスは、surface0000.pngにelement合成することで実現している。
- 表情サーフィスファイルは、face0.png～face9.pngである。
- 当たり判定領域は、位置・名前共に全サーフィスで共通である。
- サーフィス9にのみ当たり判定領域「Hand」がある
surface0
{
element0,overlay,surface0000.png,0,0
element1,overlay,face0.png,90,90
collision0,73,42,170,77,Head
collision1,96,97,150,146,Face
collision2,86,179,163,216,Bust
}
surface1 : inherit surface0
{
element1,overlay,face1.png
}
surface2 : inherit surface0
{
element1,overlay,face2.png
}
surface3 : inherit surface0
{
element1,overlay,face3.png
}
surface4 : inherit surface0
{
element1,overlay,face4.png
}
surface5 : inherit surface0
{
element1,overlay,face5.png
}
surface6 : inherit surface0
{
element1,overlay,face6.png
}
surface7 : inherit surface0
{
element1,overlay,face7.png
}
surface8 : inherit surface0
{
element1,overlay,face8.png
}
surface9 : inherit surface0
{
element1,overlay,face9.png
collision3,170,220,214,240,Hand
}
- ゴーストで運用する際は使用しないが、共通記述のためだけに存在するサーフィス番号といったものがあってもよい。
- 「このサーフィスだけ、継承元のサーフィスから当たり判定領域を削りたい」といった要求が考えられる。
- 当分は「削るような定義は継承元サーフィスに書かず、各サーフィスで個別定義」といった運用で対応。
- 今後、記述量削減の上ではキーワード「undef」を定め、定義の無効化が出来ることが望ましいだろう。
例：
surface11 : inherit surface10
{
undef,collision3
// surface10に存在する当たり判定領域3を、surface11中では無効にした
}
以下の項は、主にプログラマが読むことを想定している。
- 継承サーフィスの継承、多重継承やMix-inは必要か？
surface200 : inherit surface100,surface50
{
// surface100とsurface50の両方の定義を継承。多重継承 or Mix-inの例。
}
surface30 : inherit surface0
{
// surface0を継承
}
surface40 : inherit surface30
{
// surface0を継承したsurface30を更に継承する例。
}
- private/publicは必要か？undefの必要性ともリンクする。
surface1000
{
element0,overlay,base.png,0,0
private:
element1,overlay,element1000-1.png,100,100
element2,overlay,element1000-2.png,100,200
// element1～2はprivate属性で、継承先からは見えない
public:
collision0,170,220,214,240,Head
// collision0はpublic属性で、継承先から見える
}
surface1010 : inherit surface1000
{
// surface1000を継承しているが、element1～2は合成されない
undef,element1
undef,element2
// private/publicが無い場合、element1～2を外すのにundefが必要
}
コメント†
- 難点としてはsurfaces.txtのIDのミス（おなじID重複）が常態化しているところですね。…間違うなと言っても無茶なのでいっそのこと関係なしにしたいです。 -- ぽな@ばぐとら
改善案その2†
- アニメーションや着替えを多用するサーフィス定義では、surfaces.txtのファイルサイズが非常に大きくなる。
- 大きな定義ファイルは、メンテナンス時にどこに何が書いてあるのかが分かりにくい。
打ち手†
- ファイルのインクルード機能を付けよう
- プログラマ向け説明：C言語の「#include」、各種言語の「import」機能を導入する。
- 一般向け説明：surfaces.txtの指定行に、別のファイルの内容が差し込まれているものと見なす機能を導入する。
定義と解説†
- 「%incude(FILENAME)」という行があると、その行にFILENAMEという名前のファイルの内容が差し込まれたのと同じ動作をする。
- common.txtの内容
collision0,73,42,170,77,Head
collision1,96,97,150,146,Face
collision2,86,179,163,216,Bust
- surfaces.txtの内容(部分)
surface100
{
element0,overlay,surface000.png,0,0
element1,overlay,element100.png,90,90
%include(common.txt)
}
surface102
{
element0,overlay,surface000.png,0,0
element1,overlay,element101.png,80,80
%include(common.txt)
}
- 「%」を、プリプロセッサ機能に関わる機能の共通頭文字として確保する。
- プリプロセッサ機能は、本体によるsurfaces.txt構文解析の前に全て処理するものとする。
コメント†
|
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
