jgame.js 2.1リリースと、3.0について
一昨日jgame.jsの2.1をリリースした。
http://sourceforge.jp/projects/jgame-js/news/24369
jgame.jsってのはニュースにも書いてるけど、まあTypeScriptのHTML5（というかCanvas）用ゲームエンジンすわ。
TypeScriptで書かれたenchant.js類似エンジンって言えばシンプルか。
ほんとは3.0を名乗れるようになるまでリリースいらんかなと思ってたんだけど、githubと違ってsourceforgeはリポジトリから最新を取得するよりリリースからダウンロードってパターンが多そうだったのと、ちょっと修正項目が多くなってきたので途中リリースを一つ挿んだ。
今日はそのリリースについてのノートと、3.0についての話。
2.1の変更内容
変更内容全部貼ろうかと思ったけど、ちょっと多いので要所だけ。
一つ目はjsdocコメントの追加。ドキュメントは相変わらず無いけど、コメントはつけた。
目的は「jsdocのためのコメント追加」というより、エディタにおけるコメント表示。
例えばPlayGroundは今こうなっているんだけど、
http://jgame-js.sourceforge.jp/playground/normal.html
Ctrl+Shiftでコメント表示が出来るようになっている。Visual Studioではもうちょい綺麗に出る。
PlayGroundを基にjgforceのjgame.jsエンジンも構築していくので、jgforceのために書いた感じだけどね。
まあ前も書いたと思うけど俺はソースコード中のコメントが嫌いなので*1、コメント付きコードになって俺の好みから少しずれたけど、TypeScriptがサポートするのはjsdocだけだったので長いものに巻かれた。
ちなみに、jsdocのTypeScript版はまだ無いので、APIドキュメントの更新は偉い人待ち。自分でやるつもりはあんまりない。
あとTriggerをhandle(1) -> handle(2) -> handle(3) -> remove(1)ってすると、handle順が3 -> 2になるとか致命的なのがあったのでその修正と、反省してTriggerのテストプログラム追加したりとか。
grunt使えよと我ながら思いつつも、おべんきょ兼ねてnode.jsでビルド用バッチ処理書いてそれ同梱したりとか。
こいつがjgame.jsファイルにはコメントが無くて、jgame.d.tsにはコメントがあるとかをやってる。
あとはLayer継承したクラスを使えるようにしたりとか。
これはcocos2d見てたらLayer継承が普通だったので、おーなるほどとこっちにも実装した。
後付けだからメソッド名がcreateLayerなのに、その第二引数にLayerのインスタンス渡すとcreateせず使うだけという奇妙な実装になってしまったが。
他まあ細かいバグ修正。
とりあえずパッと見ではd.tsにコメントが付いたので、Visual StudioやPlayGroundではコメントが出るようになったのが大きいかなと。
コメントはだーっと書いたから、あんまり文書のクォリティは高くないけどな。
3.0について
今後のjgame.jsはぼちぼち運用していきながら、3.0に向けていじっていきたいところがある。
元々、jgame.jsはユーザ目線で考えるとTypeScriptライブラリではなくJavaScriptライブラリであるべきかなと思っていた。だからサンプルとかも全部JavaScript。
なんだけど、JavaScriptライブラリなんてもう一杯あるんだから、その分野は他の人に任せてTypeScriptに専念しようかなと。
例えば、argumentsを使っている箇所を全撤廃するなど。
合わせて、今までオーバーロード使ってなくて、こういう風にanyがちょこちょこ出てたんだけど、オーバーロード解禁してなるべく減らす。もしかしたら絶滅させるかも。
resizeTo(size:number, time:number, easing?:any, easing2?:any) {
全体的にTypeScriptからの利用を前提にカスタマイズするということ。
jgforceのエディタが実用レベルになりそうだから、TypeScript前提でいいんじゃないかなとね。
box2dモジュールのように既存オブジェクトに後付けで別機能をアタッチするのがTypeScriptではやりにくいので、そこだけ扱い悩み中だけど、基本方針はTypeScriptライブラリって事で進める方向に舵を切る。
それから、ECMAScript5向けにして、プロパティの利用を解禁しようかなと。
jgame.jsは原則として速度重視なんで、フィールド直接操ればすむものをわざわざラップしたりはしないって方針に変化はないんだけど、こういうのがどうしてもあんだよね。
export class Line extends E { clip: boolean; setClip(value:boolean) { this.clip = value; if (this.clip) this.disableTransform = true; else delete this.disableTransform; }
さすがにこれはプロパティにした方がいいかなと。
プロパティ化は副作用があるので賛否両論だとは思うけど、いじっちゃいけないフィールドってのはさすがにどうよと。上の例だとclipフィールドいじったら確実にバグるわけだけど、フィールドを全部publicにしようという指針のため隠せない。
のでプロパティ化+プロパティで内部的に使っているフラグ値だけはprivate解禁にしようかなと。
3.0の予定は大体そんな感じ。
jgame.jsについてもうちょっとこうすればいいのになぁと思っている人がいる場合、一応いくつかこういう理由と予定があるということで、参考になれば。
ちなみに気になってる事としてもう一つ、Triggerのジェネリクス化があるんだけど、これはもうちょい様子見る。
ジェネリクスにすればイベントハンドラの型が安全になってよりいいけど、正直イベントハンドラの型がhandler(param?:any)でもあんま困んないし、むしろ派生クラスでイベントパラメータ変える時は便利ですらあるので、本当にGenericsがベストなんかどうなのかと。
mixinとawaitが入るとTypeScriptで予定されていた機能が一通り出揃うと思うけど、今のTypeScriptのスピード感的に一年くらいかかりそうだし、別にその後再検討すりゃいいんじゃねーのという感じ。
jgame.jsの位置付け
コメント書けとか、セッターゲッター用意しろとか、アクセス修飾子ちゃんと使えとか、色々流儀がある中で、ふと見てみればjgame.jsは俺のエゴとTypeScriptの都合を詰め合わせた面白ソースになってる気がする。
例えばフィールドが全部publicなTypeScriptライブラリなんて、俺以外やらんだろ。
pixi.jsやcocos2d-html5を見ながら思ったんだけど、正直全部のゲームエンジンに勝とうとか考えるのは間違いかなと。
WebGLを前提にしたフレームワークはやっぱパーティクルやリアルタイム画像変形が速いと思うし、それと同レベルの実装をする工数かけるならそのフレームワーク直接使えばいいでしょ。
ただどんなフレームワークであっても設計指針自体が気にいらないところはあるんで、その点jgame.jsは設計指針的に、特にTriggerによるイベント駆動とTypeScriptの相性がよくて気にいっているのと、いくらでも直せるのでjgforce向けにはjgame.jsを第一にやっていきたいなと。
ということで、もうしばらくちゃんと保守する。
TypeScriptに興味ある人は気が向いたら使ってみてくださいっつーことで、よろしくです。
