スポンサーサイト

--/--/--
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
comment (-) @ スポンサー広告

今作っているゲームがようやくひと区切り

2015/08/11
今作っているゲームがようやくひと区切りつこうとしています。

まるまる一ヶ月かかりましたが、おもえば、まるまる一ヶ月ほぼずっとゲームを作ったのは、
大学生時代以来かもしれません。

こんなにも時間を要したのは、分からないことでつまづくのは仕方ないとして、
それを除けば、とにもかくにもmacと、XCODEが重いせいです。

私はwindowsの方では、未だに15年以上前のDELPHIを使っていますが、
数万行のコードを書いても、1秒かからずコンパイルしてくれます。

しかしXCODEは、1000行も超えれば、あくびが出るくらいには遅くなります。

そして今回も、前回に続いて解決できなかったことが残りました。


・まず、アプリ名のローカライズが今回もうまくいかなかったこと。

 これだけやって上手くいかないのは、きっと私が大きな見落としをしているからでしょう。
 しかし、上手くいかないので諦めました。
 info.Plistで直接bundle display nameに日本語で書いて、英語は無視しています。


・コンパイルが遅い。

 今回はいくつにもファイルを分散することで、少しでも軽さを維持しようと努めてみました。
 分散は結構効果があったと思います。
 コーディング中の重さも軽減されるようです。
 しかし、それでもやっぱり遅いです。
 あと思いつく対策と言えば、コンパイルせずにコードを書く時間を長くさせることでしょうか。
 それはあんまり性に合わないので、無理かもしれません。
 これがAPPLEの限界なんだろうと思って、諦めるしかないかもしれません。


・また、今回はiPhoneアプリ2作目でしたが、今回で初めて挑戦したことと、
 それに併せて、その中で解決できずに残った問題点を羅列しておきます。


・アプリ内課金

 実装には苦労しました。
 ネットに、Swiftによる分かりやすい情報がほとんどないのが辛かったです。
 多くの書籍も頼りましたが、ネットとあまり変わりません。
 そして、sandboxでのテストは最後まで上手くいきませんでした。
 今回、リジェクト可能性が一番高いのがここだと思います。

・横向き

 横向きは、縦向きよりずっとゲームの幅が広がるような印象でした。
 今の時代の人間は、縦の空間認識より、横の空間認識の方が得意であることに起因するかもしれません。
 しかし、横向きだと、HOMEボタンを押した時に、画面のアスペクトが一瞬変になります。
 これはSpriteKitの何かの設定のせいだと思うのですが、これに関する情報はネットでは見つかりませんでした。
 大した問題ではないのですが、ちょっと気になります。

・ネットランキング

 意外に簡単に実装できた方だとは思います。
 しかし、一番悩んだのは、エンコードタイプです。
 どうも、アプリ側は、ネットから受け取るHTMLを、自分なりにそのコードを解析して、エンコードタイプを判別しているような節が見受けられ、それに悩まされました。
 というのも、HTMLの一番上の数行の文字列を変えるだけで、UTF-8と判断されたり、ASCIIコードでしかデコードできなかったりと、不安定だったからです。
 まあこれは普通のブラウザも似たような挙動をするので、仕方ないかもしれませんが。

・フリックやスクロール

 全て自前で作りましたが、絶妙な感覚を得るまでに微調整が大変でした。
 フレームワークを利用した方が早いのでしょうが。

・UIはほとんど自作

 UIKitの一番面倒そうなのは、個人的にはリストです。
 デリゲートを使うセル更新とか大嫌いです。
 だから今回は自分でSpriteKitだけで作りました。

 しかし、まあ重い重い。
 数百行のリストを作るだけで、単純に数千nodeを作成するわけですが、とにかく重くなります。
 特に作成時が重いです。
 表示に関しては、一画面内に表示されるnodeが少なければ軽くなるようなので、
 一画面内に収まるリスト項目が少なければ、そこそこ軽くなります。
 しかし、作成は重いので、頻繁に全体を更新するのは苦しいです。
 けれど、UIでやるより多分ずっと楽にいろんなことを実装できたと思います。

・ビットマップフォント

 結構悩まされました。
 ビットマップフォントで作った「 」スペースのせいで、レイアウトが崩れたりして、それに悩みました。
 「 」スペースの指定は、自分でfntファイルを開き、その大きさを自分で手打ちして調節することで解決させました。


・サウンド関連

 前回同様にSpriteKitで鳴らしましたが、
 どうもSpriteKitで鳴らすと、重い時などに音が鳴らないことがあるようです。

 ここは絶対に重くなるというような所で、鳴るタイミングは少々ずれてもいいという場面では、
断片的にAVAudioを使用しました。


・タッチノードに困らされた。
 タッチの検出は、TouchBeganを用いて、タッチされたNodeを検索することで行っていましたが、
 ここに一つの問題が。

 どうもタッチされたNodeを検索するやり方では、
 当然かもしれませんが、Nodeが重なっている場合だと、最前面のNodeのみが検出されます。
 普段はそれでも問題ないかもしれませんが、
 例えば、半透明の煙のエフェクトなんかを手前に描画していたりすると、問題が露呈します。
 その時検出されるのは、煙の向こう側のキャラクターではなく、煙だからです。

 タッチ位置だけを取得して、あとは自分で処理するのがよいでしょうね。


・配列

 今回一番エラーが出たのが、配列でした。
 indexがオーバーしている、というやつです。
 最近の言語の多くは、可変配列のようですが、それがこの問題の根本です。

 最初に配列の最大値を決めて、そのあとは、その中で自分でやりくりする、というやり方なら、この問題は発生しにくくなりますが、可変配列は、最大値が可変するので、それで何度もつまづかされました。

 もちろんこれは人間側のミスですし、想定外の問題がエラーとなって見つけやすいという利点もあるので、悪いというわけではありません。 
 悪いのはそのたびに必要なコンパイルの遅さです。


・クラス

 今回はクラスをたくさん使いました。
 きっと多くの人には当たり前のようなクラスですが、
 私の場合、クラスを使わないと、ファイルを分散しづらかった、というのが動機でした。

 でもやはり、クラスを多様することで、不可解な挙動の温床が多々生まれ、その原因究明に
 頻繁に時間を割かれました。
 
 前回作ったゲームは、ほとんどの動作を一本化した自分のルーチンの中だけで回して作りましたが、
 他人から見たら大変見づらいコードではあると思いますが、このやり方だと、何か新たしいことをやる際に、
 すぐに導入できるのが利点です。
 全ての挙動と変数は、一つの中で保持・管理しているので、自分の頭のメモリはたくさん使いますが、
 コードの中では自由度がたかいです。
 クラスをまたぐことはないので、そういった境界を気にせずにすむのが良いです。

 逆にクラスを多様すると、クラスをまたぐための処理のせいで、そこで問題が発生することが私の場合はよくあります。
 これは私がクラスを完全に理解していないからだとは思いますが。
 今後はもう少しこの変を改善したいところではあります。


・リアルタイム描画

 SpriteKitは、その名のとおりスプライトを使用しますが、
 私はこのスプライトというのが、あまり好きではありません。
 重いし、一度描画してしまうと、描画レベルでの変更が利きづらいからです。
 ドット単位で描画を制御したい人にとっては、そういう描画を想定するメソッドが不在だと、悲しくなります。
 ただSpriteKitでも、
 SpriteをaddChildし、1フレーム後には、再びremoveして新たに描画したものをaddChildという風に繰り返せば、
 リアルタイム描画のようにはなりますが、
 なんかすごい、無駄なことをしているような気になります。

 結局、コードもルーチンも描画も、全て自分で一元化して把握管理したいのが、私の性格のようなので、
 そこが単に時代にあっていないだけなのでしょうけども。


関連記事
comment (0) @ エラー
[iPhoneゲーム申請] 2作目を申請。 | [Swift] SpriteKit SKSceneからpresentViewControllerを使う方法

comment

コメントを送る。

URL:
Comment:
Pass:
Secret: 管理者にだけ表示を許可する
 
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。