「てんしのおしごと」体験版をリリースしました!!
プログラマの吉田です。
もう本当に年末ですがみなさまいかがおすごしでしょうか？ちゃんと仕事は納まりましたか？
さて、本日は重大発表をさせていただきます!!
といいつつタイトルになっておりますが次回作「てんしのおしごと」の体験版を GooglePlay でリリースしました!!
GooglePlay のシステムの更新には時間がかかりますが本日12/28中には表示されると思います。
体験版では様々な理由により Android 版のみの対応となりますが、本番リリース時は iOS、 Android の両対応を行いますのでその際は iPhone の方もよろしくお願いします。
まず先に言っておきますが「まじょのおしごと」の機能追加は今後も続けますのでご安心ください。
実を言いますとおけやからのクリスマスのプレゼントとして24日にリリースする予定ではありました。
様々な困難からそれはかなわなかったのですが、なんとか年内にリリースできました。
これは僕ではなく上野の努力の賜物です。労いの言葉をいただけるなら上野のほうにお願いします。
まじょと同様に「てんしのおしごと」に関しても機能を追加して、正式版のリリースを目指す予定です。
正式版がいつぐらいかの明言はいつもどおり避けさせていただきますが、春には出したいなという構想はあります。
「てんしのおしごと」ではいくつかのチャレンジをしております。
一例をあげますと今回は完全オフラインでプレイ可能にしました。
地下鉄で移動することが多い方や電波の弱いところにお住まいの方でも楽しんでいただけると思います。
その他いくつかのチャレンジを盛り込んでいますが、機会があればそのあたりも公開したく思います。
今後も「おしごとシリーズ」として「まじょ」「てんし」そしてその先も様々な展開を予定しております。
売上はそれほど伸びていない現状それなりに苦しくはありますが、なんとか楽しいゲームを皆様に届けたいと思っておりますので応援いただけると幸いです。
進捗報告
プログラマの吉田です。
ブログの更新が滞っていて申し訳ありませんという話を毎度しているような気がしますが、ちゃんと活動はしています。
まじょごとでは特殊召喚(仮)がなんとなく動きました。
出来れば年内にリリースしたいとは思っていますが確約はしかねます。
なにせ人手不足なので...。
まじょのおしごとに集中しろよという話かもしれませんが、次回作候補の一つのにんぎょのおしごとはこんな感じになっています。
アイコンなどはありものをとりあえず使ってやってるだけなので見た目はだいぶ変わる予定です。
静止画なのでこれを見ただけでは伝わらないと思います。
何をやったかというと前まで並べて置いているだけだったアイコンをいろいろ動くようにしてみました。
そうしたら逃げるやつを追いかけてやるみたいな心理が働き少し面白くなりました。
ゲーム制作にとって企画がとても重要な事は十分承知していますが、
企画ありきじゃない作りながらいろいろ考えるスタイルも良いものです。
しかしもう今年も1ヶ月を切ったのですね。早いものです。
なんとか今年は乗り切れそうですが、来年はどうでしょう？
がんばるしかもはや無いので必死にがんばって面白いゲームを届けたいと思いますので今後もよろしくお願いします。
失敗したらこうなった
CTOの吉田です。
まじょのおしごとのほうは高負荷対策がだいぶ出来まして最終テストの最中です。来週中にリリース出来る予定ですのでお待ち下さい。
また資金難を避けるため最近は資金稼ぎの外部の仕事も少しやっておりましてわりと忙しくしています。
まじょごとの高負荷対策を優先させているため機能追加が停滞しておりまして、そちらの方の話はありませんので、たまには与太話でもさせていただきます。
前作のデルタオーケストラを作り、今回はまじょのおしごとを作り、そして次回作の構想を練ったり外注仕事をこなしていますが本当に数多くの失敗をしてきたなと実感しております。
デルタオーケストラはブラウザゲームとしてはスペックが合わないものを作ってしまいました。まじょのおしごとは負荷を考えずに機能追加をした結果破綻し、現在絶賛作り直し作業に追われています。またそれ以外にも細かく書くとキリがありません。
しかしそれらを経た結果「今持っている技術で何かをするのではなく、喜んでもらえるもために必要な事は身に付ければいい、リソースも調達してくればいい。」という原則にたどり着きました。言葉にするとシンプルで似たような事は昔からいろいろな所で言われていることだと思いますが、身に沁みて理解できたのは経験を経たからです。
そして経験を通してやってはいけないこと、やるべきことも見えてきました。今後作っていくものは様々な反省が生きた作品になっていくことは間違いありません。
失敗はいろいろ重ねてきましたが一応まだ会社も存続しています(ジリ貧ではありますが)。
まじょのおしごとが良い作品であることは確信しておりまして、イベントを打てるところまで作りこんだらいかに皆様に知っていただくかを考えるフェーズになるのだと思います。
現時点でまじょごとの作り直しもほぼほぼ出来て、またあらたに機能追加をいろいろしてもっと魅力的なコンテンツにしていきます。また次回作もご期待ください。 今後もおけやの動向にご注目ください(生暖かく見守ってください)。
次回作を思案中
プログラマの吉田です。
最近技術の話が続いたのでたまには企画の話をします。
現在次回作の構想を僕も上野も考えています。僕はインタフェースからゲームを考えるようにしていまして僕が考える次回作はタップを連続でやって楽しいゲームにしようと思っています。
そこで週末にとりあえずいくつかのアイコンを表示してタップすると数字が増えるモックを作ってみました。
これを上野に見せたところ非常に的確なアドバイスがもらえました。 今のところ僕が作ったものには勝利条件も敗北条件もありません。 まずはここから考えろというアドバイスをいただきました。
勝利条件があるとまじょごとのようなステージをクリアしていく形になりますし、 ゲームオーバーの条件がある場合テトリスのようなミスをするまではずっとやり続けられるゲームになります。
またどのようにやると上手くプレイ出来るのかも提示出来るようにしたほうが良いというアドバイスももらいました。 例えばパット見一番少ないアイコンをまず消していっぱい連続してタップ出来るほうが有利になるのか不利になるのかはちゃんと設計してあげないといけないとのことでした。
ゲームを企画したことがある人から言わせるとそんなもの常識でしょうが、そうではない僕にとっては非常に新鮮な話でした。
ゲーム作りのノウハウというのは意外と世に出回っていないのでこんな企画未満のところも公開してみました。 もっといろいろ話をしたのですが録音でもしときゃよかったと思うぐらいです。
まじょのおしごとの機能追加や改善が第一なので費やせる時間は少ないですが次回作もがんばります。 まずはまじょのおしごとをよろしくお願いします。
draw call を減らした話
「何をもたついているんだ?」
「もういっぱいなんだ..」
「何がいっぱいなんだよ？」
「絵だよ png が... Sprite がいっぱいで...」
「こういう時は頭を冷やそう。一つずつ確固撃破するから大変なんだ。まとめてパッっとやっちゃえばいいんだよ。」
プログラマの吉田です。
季節の変わり目ですがみなさま体調はいかがでしょうか？
今回はまじょのおしごとで draw call を減らしているお話をします。
スマホアプリでは GPU というハードウェアを使用して画面を描画しています。 GPU は描画をする時に draw call というものを発行します。 グラフィックの処理というの重たい処理なのでこの draw call をいかに減らすかによってゲームが速度的に快適に動くかどうかが決まります。
cocos2d-x で draw call を減らすために
- SpriteSheet を使ってシーン毎に画像をまとめる
- 可変ではない Text は 画像に差し替える
- 独自のレンダリングを行う UIText などの Node の global Z order を変える
- bitmap フォントを使う
を行いました。するとホーム画面で 119 発行していた draw call が 3 にまで減りました。 多少処理を止めている部分があるのでもう少し増えるとは思いますが劇的な改善過ぎて僕達も驚きました。
具体的にはバトルの画面で「可変ではない Text を画像に差し替える」例をご紹介します。
Xcode の debug ナビゲーターでは「実機デバッグを行っている場合」に「FPS」の解析が出来ます。
上のように1、2、3とクリックすると
このように GPU が何をやっているのかを解析できます。 ここでは draw call が 60回行われています。 これの glDrawElements で何を描画しているのかを検証します。 上のスクリーンショットだとまず背景や各パーツを1度に描画しています。 その次の glDrawElements に移ると下のようになっていました。
このスクリーンショットでは敵魔法陣の「Next↑」という Text を描画していました。
cocos2d-x の ver 3.0 以降 では画像の描画は同一の Texture に Pack している限りなるべく同時に描画するように renderer が改善されました。 しかしながら画像と画像の間に Text などがあると順番に描画してしまうため余分に draw call がかかります。
この 「Next↑」というのは特に変更することは無いので imagemagick を使い 画像にしてしまって差し替えてみます。
$ convert -font ~/project/oke-ya/zeron-ui/WitchProject/cocosstudio/fonts/APJapanesefontT.ttf -pointsize 32 -background none -fill "#FF8844" label:"Next↑" next.png
というコマンドで next.png を生成し cocosstudio の CSI で pack します。
そしてさきほど Text だった ものを画像と差し替えます。
そして再度 Xcode で解析をすると下のように一度に描画してくれるパーツが増えました。
そして draw call が 57 になりました。 これでバトルの時の動きがもっさりしていたというのも改善出来ました。
ゲーム開発者からすると知ってて当然という内容だとは思います。 しかしながらどのような事でもやり始めたころは初心者です。初心者は様々なところに躓くものです。躓いた結果残念なバージョンをリリースしてしまった事に対しては非常に申し訳ありませんでした。しかしながらこのように日々改善するよう努力をしております。またこのようにそのノウハウを公開することで今後ゲームを開発しようという方の助けになれたならば幸いです。cocos2d-x のレンダリングについては cocos2d-x ユーザーしかうれしくありませんが、 Xcode で GPU のレンダリングのデバッグが出来るというのは全ての iOS 開発者が知っていたら便利な事です。
このようにスマホゲーム開発のノウハウもいろいろ貯まってきました。ですので今後もっと良いものが作れると思います。具体的にどうという明言は避けておきますが、今後にもご期待ください。
画像を圧縮するのです。キャッシュを削除するのです。
プログラマの吉田です。
まじょごとブログのほうからブログを書けというプレッシャーを感じましたので心を改めてブログを書かせていただきます。
プログラマな悩みとして発信出来る情報がマニアックになってしまうというのもあるのですが、ゲーム製作の裏側ではそういう葛藤もあるのかと思ってください。
この度 まじょのおしごとの 1.5.3 をリリースさせていただきましたが、1.5.0 で大変出来の悪い状態でリリースをしてしまったため、開いた瞬間に落ちる人が続出してしまい、しっかりDAUも落ちて非常に申し訳ありませんでした。出来の悪いバージョンをリリースするとユーザーが離れていくという事が身に沁みてわかりました。何事も体験してみて成長するものですね。
さてそれをどう改善したのかというお話を今回はさせていただきます。
スマートフォンのゲーム開発でいちばんメモリを使うのは画像です。 ですのでまじょごとの1.5.2 や 1.5.3 では画像の最適化を行いました。 具体的に何を行ったかというと画像のフォーマットを Android では etc1 に、 iOSでは pvr.ccz に変更しました。 png や jpg などと比べてあまり馴染みの無い形式だと思います。
png 形式は iOS でも Android でも使えて非常に便利な画像形式なのですが、 png を使用すると画像サイズの倍以上のメモリを消費してしまいます。これは 画像を描画するハードウェアであるところの GPU の特性です。GPU にもいろいろな種類があるのですが、GPUの支援を受けることができる圧縮方式があり、それが iOS では pvr.ccz であり Android では etc1 です。
詳しく知りたい方は iOS と Android 両方公式のドキュメントがあるのでそちらを参照してください。
Using texturetool to Compress Textures
pvr.ccz への変換は texturetool、 etc1 への変換は etc1tool という公式のツールもあるのですが、 今回は TexturePacker というツールを使用しました。
TexturePacker - Create Sprite Sheets for your game!
TexturePacker を採用した理由はわざわざそれぞれに最適化したオプションを渡さなくてもわりとしっかりやってくれるからです。
TexturePacker は css sprite なども作成出来ますので、web開発者の方も頭にいれておくと良いかもしれません。
画像の圧縮に加えて画像キャッシュの削除も各所に入れました。
cocos2d-x は画像を一度読み込むとメモリ上にキャッシュしておき、二回目移行はその処理を省略して高速になってうれしいように出来ています。ですが、例えばタイトルの画像など、一度見終わってしまったらしばらく見ないであろう画像までキャッシュされてしまうとメモリを無駄に消費してしまうことになります。1.5.2 で部分的に1.5.3 でさらに多くの場面でキャッシュを削除するようにしました。
こういったことを行った結果 iOS では バトルの画面で500MB を超えている時もあったメモリ利用量が 250MB 程度になりました。pvr.ccz よりかは圧縮率が悪いので Android ではもう少し食っていると思います。
また先日不具合の報告でバトルの時に敵のおばけがちゃんと魔法陣のところまで出ないという報告をいただきましたが、おそらくキャッシュを削除してしまったがための画像の再読み込みに時間がかかってるとかで起きているんじゃないかと予想しています。「なうろーでぃんぐ」の時にキャッシュを消して直後に必要な画像を再読み込みすればいけるんじゃないかと予想していますが、僕の予想は外れる事が多いのが特徴なのでがんばって直そうと思います。
そんな感じで今後はちょこちょこ不具合を直しつつ、また新しい機能の追加をやっていくのでご期待ください。
スマホのゲーム開発は初めてでして知っていれば避けられた地雷をがんがん踏みながら進んでおります。 ノウハウもいろいろたまりましたので今後はもっと良くなっていくと思います。 圧倒的成長とは地雷を踏みまくることで為せるものですね。
まじょのおしごとだけではご飯を食べられない状態が続いておりますので、次回作の検討もしています。こちらもご期待ください。 本当に食べるのに困った場合はまたクラウドファンディングでもしますのでその際は是非是非ご協力お願いします。
不具合との戦い
プログラマの吉田です。
まじょのおしごとのリリースノートなどは「まじょごと」ブログに載せておりますのでそちらをご覧いただくとして
こちらのブログではその裏側のお話をさせていただきます。
いきなり謝罪から始めますがver 1.5 以降不具合が続きまして非常に申し訳ありません。現在その対応をがんばっていますので、そのあたりのお話をさせていただきます。
まじょのおしごとはそもそも二人で開発していることもあり「負荷や速度はさておき、実装を急ぐ」「嬉しいほうの悲鳴になりそうな事の対応は行わない」という方針でやってきていたのがここで破綻した感じです。何が起こってどういう対策を行っているかをお話させていただきます。
サーバーが落ちた
ちょうどこないだの日曜日 9/27 のことです。サーバーが落ちましてゲームが出来なくなりました。まじょごとは AWS で ELB + appサーバー2台 + RDS(multi AZ) という構成で動いています。 その app サーバーのうち1台が out of memory になりました。out of memory というのは単純にメモリが足りなくなったということです。 2台あるので1台落ちても1台ががんばってる間に復旧させればいいやと思っていたのですが、ここで問題が一つありまして、監視システムの設定が失敗していてどちらか1台だけ落ちてもアラートが飛びませんでした。こうして発見が遅れ、遅れてる間も1台のサーバーはがんばっていたのですが、1台だけではまかなく事が難しかったようで 502 エラーを頻発していました。最終的にプレイヤーの方に連絡のメールをいただいてから復旧作業となり、影響が大きくなった事は非常に反省するところです。
この障害に対する対策としては監視設定を見直し、もう少し細かい監視を行うようにしたうえで2台構成であった app サーバーを1台追加して3台としました。これでだいぶ余力が出来ましたのでまだしばらく大丈夫です。また app サーバーについては将来的には Docker に移行したいななどの構想もあります。
アプリが落ちる
ver 1.5.0 移行アプリが落ちてしまう方が増えています。こちらについても 1.5.0 でハードモードを追加し、おばけやステージが増えてしまったため、使用メモリが増加し特にメモリをあまり多く積んでいない Android 端末の方には引き続きご迷惑をおかけしておりまして非常に申し訳ありません。
こちらについても現在対策を行っております。具体的に言いますと 複数の画像を1枚の画像に連結し、使用する時に範囲指定して取り出して使う SpriteSheet という最適化技法がありまして、これを行っております。ゲームの画像の描画や演算を行う GPU というハードウェアがスマートフォンや各種ゲーム機には積んでいます。GPU は2の累乗サイズでメモリを確保するため、例えば 50x50 の画像が2枚あったばあい、64x64 の領域を2つ確保するので 64x128 の領域が使われ 14x28 28x50 14x100 の領域が余ることになります。もし余ったサイズに納まるサイズのアイコンがあった場合それらを結合して1枚の画像として扱ったほうがメモリの利用に無駄がなくなりますし、1度のメモリ確保で済むため時間的にも有利となります。こういった細かい最適化処理をいろいろ施しています。
またローディング中に画像をメモリに載せる処理を行っている間「なうろーでぃんぐ」の文字の点滅が止まってしまい、固まったように見えてしまうところも処理を Thread で(バックグラウンドで)行うようにして点滅が止まらないようにしました。さらに画像サイズそのものの見直しも行っておりトータルで使用するそもそものメモリ量も減らすようにしました。10月のなるべく早い時期にこの最適化を行ったバージョンをリリースすべく作業を行っております。
最適化が必要になった
いろいろな処理を速くしたり、使用するメモリ量やディスク量を削減するためにプログラムに手を入れることを「最適化」といいますが、プログラミングの最適化に対する格言として「最適化は(なるべく)するな」というのがあります。最適化というのは大抵の場合人ではなく機械のほうに合わせるようにプログラムを書くようになるため可読性が落ちたり汎用性が落ちたりするため現実的な時間で処理が行えているのであれば最適化はしないほうが良いということです。また最適化というのはそのスコア(処理時間やメモリ量の削減)が目に見えてわかってしまうためプログラマにとっては楽しいものです。しかしながら別にそこが遅くても問題無い箇所を0.01秒速くするために3日使うようなことをするのは無駄ですね。そういうことをしてはいけないということです。
この格言に私も従っていたのですがついに最適化が必要になったという点で感慨深いです。私の予想では年内は大丈夫だろうと予想していたのですが、予想以上に遊んでいただいている方も多いし追加ステージの要望も多く結果的に機能追加をがんばった結果最適化が必要になりました。これは本当に嬉しい悲鳴です。
ここで上げたこと以外にも不具合のご報告をいただいており、そちらの対応も進めています。次に出すバージョンはもっと安定して遊べるバージョンになる予定です。その先にはさらなる機能追加やステージの追加も予定しておりますので楽しみにお待ちいただければと思います。
がんばっているなんて事実に価値は無くアウトプットにのみ価値があるというのは私自身そのように考えております。しかしながらたまにはがんばっているところも記録としてこのように残しておきたいな気持ちもあります。いろいろ怒涛の日々を過ごしておりますが「まじょのおしごと」を皆様に提供出来ていることそのものが今の私のモチベーションです。不具合で不快な思いをさせてしまい非常に申し訳ありません。しっかり対策を取らせていただきますので今後も「まじょのおしごと」よろしくお願いします。
