TwitterBootstrapとかhaxeでゲーム作ったときのメモ
こないだ公開したやつの技術的な話。前提として、何万人にも使ってもらうサービスを完成させるというよりは、そこに至るまでの企画の種を他のデザイナと議論するために一旦公開する、ぐらいの温度感です。
配布
- 永続化したいデータはある
- けど、一人プレイで完結させるためサーバ持ちたくない
- ので、ネイティブアプリ
UI周り
- 激しい演出とかアニメーションは無いからcocos2dxとかunityとかを使うほどでもない
- マップとか戦闘シーンを描画するのにenchant.js、特にavatar.enchant.js使うと楽
- 全体のレイアウトは特に変わったことはしないので普通にTwitter Bootstrap
その他、候補にあったものとしては
- widget.enchant.js入れて全部enchant.jsで書く
余計なことせず全部canvasでやってしまうとそれはそれでスッキリするものの、細かいレイアウトの調整とかシーン管理とか全部手動でやらないといけなくてわりと大変。
- AppFramework
モバイルっぽいUI作るセットが一式揃ってて楽な感じあるものの、ちょっと枠から出たことしようとすると結構大変。あと使ってる人があんまいないのか、情報が少ない。
- おとなしくネイティブで書く
特にクロスプラットフォームにこだわったわけでもなく、仮にそうだとしても大した量じゃないので普通に書いても良かったものの、Twitter Bootstrapだと
<div class="progress progress-striped active">
て書いただけでアニメーションするゲージが出てきたりするのがとても楽。この楽さでネイティブUI組み立てれるのがあればそっちを考えたかも。
エンジン
UIとかデータIOとは別の、対戦の純粋な計算処理は結構複雑になる & そこをどんどん拡張していきたいみたいなのがあって、そこだけちょっと固めに書きたかった。
- altJSでhaxeとかがTypeScript型付きで良い
- ポケモンとかを想像すれば、ある程度は抽象化できても汚いswitch地獄避けられない気がするのでenumが良いらしいhaxe
- あと、追々サーバーとかクライアントネイティブとかで同じロジックを動かすかもしれないことを思えばhaxeは魅力的
その他
- 色々と生で書くのはツライのでslim, sass, coffee
- をmiddlemanでビルド
- Gruntでも同じことができるものの、Gruntfile結構書かないといけないので、今回やることの枠を出ないならほぼ何も設定しないで良いmiddleman
- シーン切り替えも普通にページ遷移使うし他に激しいこともしないので、BackboneとかAngularでなくKnockout
やってみて思ったこと
- 結局データ大して保存しなかったので全部localStorageに寄せてブラウザアプリにすれば良かった
- haxeは手触りかなり良かったものの、constとかfinalとかimmutableを保証するのがinlineくらいしか無くて唯一そこだけ残念
- LLVMとかEmscriptenを思えばC++で書くのも一考の余地ありかも
- OSとか端末の違いでfastclickが上手くいかなかったり細かい挙動が違ったり、たかがこの規模でもWebViewの問題はきっちり表面化した
- ここから品質上げてくならサーバ書いてクライアントはネイティブとかcocos