Сyto：レベルエディターの作成、iPhoneおよびその他のユーティリティへの適応

こんにちは、Habr！ iOSゲームの開発における実践的な経験をゼロから共有し続けています。 この場合、開発を開始したときに想像できる以上の落とし穴がありました。 締め切りの混乱、出版社とAppleの不自然な（一見した）要件、曲がった無料エンジン...これは、時間とエネルギーを費やさなければならないことのほんの一部です。



前回の記事では、エンジンの選択と、どのように高品質の写真を実現し、主人公の弾性シェルの自然な挙動について話しました。 以下では、レベルエディターについて説明し、冷酷にあなたの頭脳を許容可能なサイズに縮小する方法と、ミニチュアiPhone画面にゲームを適応させる方法についての非常に熱いトピックに触れます。 そして最後に、1年前に左腎臓を提供するためのさらに便利なヒントを紹介します。
注意、カットの下にたくさんの写真！

この記事では、開発の技術的な詳細を正確に説明しているため、開発者がどこから来たのか、アイデアがどのように進化したのか、パブリッシャーのアドバイスを評価する価値があるのか​​を知りたい場合は、iphones.ruのDev Storyを読んでください。


Cytoの最初のゲームプレイ動画の1つ。 リリースバージョンと比較- クリック

レベルデザインを楽しくする方法

ゲームのレベルを作成するときが来たとき、このプロセスには非現実的に長い時間がかかることがわかりました。 すべての変更はレベルファイルで盲目的に行われ、何が起こったかを確認するために、プロジェクトを完全に再コンパイルする必要がありました。 多かれ少なかれ正気なレベルを組み立てるのに半日かかりました。 レベルの作成に多くの時間と労力を費やすか、ビジュアルエディタの作成に少し時間を割いて、レベルデザインの問題を忘れるという選択肢がありました。 選択は明らかでした。 ただし、当然、所要時間は計画の2倍でした。 予想した2倍の時間を費やして、ブラックジャックと売春婦でレベルエディターを構築しました。



編集機能を既存の機能に組み込むことは、別のエンターテイメントであることが判明しました。 どのゲームを作成する場合でも、早い段階でゲームオブジェクトを編集、保存、およびロードする機能を必ず含めてください。この機能がより柔軟になればなるほど、より良い結果が得られます。 ちなみに、デバッグコンソールも追加していませんが、問題はありません。 レベルエディタで作業を整理する方法は、特定のプロジェクトによって異なります。 私たちにとって最も便利なアプローチは、iPadでレベルを直接編集することでした。 文字通り1回タップするだけで、「新しく収集した」レベルをすぐにプレイできます。



非常にシンプルなワークフローを使用することにしました：



レベルデータベースはFTPサーバーに保存され、すべてのデバイスはそれと同期され、データベースのローカルコピーを保存します。 レベルでの作業が完了したら、サーバーにアップロードできます。 これにより、複数のレベル設計者がプロセスに同時に参加することが可能になります。また、たとえば飛行機に乗っているなど、インターネットが存在しないレベルで冷静に作業することができ（場合もあります）、ネットワークが表示されたら、単に作業結果をサーバーにアップロードできます。

すべてのレベルが準備できたら、サーバーから手動で引き出してプロジェクトに追加します。ビルドの承認済みレベルは常に編集済みのレベルとは別個であるため、誤って完成したレベルを変更する可能性がなくなります。



ところで、エディターによってレベルファイルに直接縫い付けられる場所の小さなプレビューは、不可欠なものであることが判明しました。 それらがなければ、数百のレベルを整理することは単に不可能です。

作成と編集の利便性に多くの注意を払いました。 Level Editorは、内部開発ツールというよりも、App Storeのアプリケーションに似ていることが判明しました。 完成したレベルの作成は、プレイするのと同じくらい楽しいものでした。

ゲームを5回トリミングする

予期せぬ驚きが、開発の終わりに私たちを待っていました。 出版社のChillingoと協力し始めたとき、彼らは「 fit in 50MB 」 アイテムの重要性を強調しました。 App Storeのトップゲームのほとんどが50メートル未満であることも不思議ではありません。 これに関する正確な統計はありませんが、iOSの最小サポートバージョンよりもアプリケーションのサイズがはるかに重要である可能性があります。



以前、携帯電話ネットワークの制限については知っていましたが、十分な注意を払っていませんでした。 その時までに、Cytoビルドは150MBを超えていました。 アプリケーションのサイズを3倍削減する必要がありました！ 「これは非現実的です...価値はありません...」と考え、サイズの最適化を開始しました。 それほど簡単ではありませんでしたが、かなりリアルであることがわかりました。

アプリケーションのさまざまなリソースによるサイズ分布を調査した結果、ゲームオブジェクトのアニメーションを含む巨大なアトラスが最大の場所を占めていることがわかりました。 各レベルパックの世界を独自のグラフィック要素と色でユニークにしたかったのです。 世界ごとに独自のセル、背景、ポータルが描かれました-各パックには完全にオリジナルのアートがありました。



一部の場所では、スプライトの色を設定しようとしました（cocos2dにはそのような機能があります）。 ひどかった。 ココナッツが組み込まれたオブジェクトの再描画は良くありませんでした。 Photoshopの場合と同じ効果を実現したかったため、細部を失うことなく画像の色相を完全に変更できます。



HSVカラーモデルを適用するには十分であることが判明し、すべてが適切に配置されました。 これらすべての色の操作をシェーダーで直接実行することは可能ですが（Cytoは以前にcocos2d 2.0に移行していたため）、これはデバイスに一定の余分な負荷がかかることを意味します。 ゲーム中にオブジェクトの色を動的に変更する必要がなかったため、テクスチャのロード時にテクスチャの色を直接変更することが決定されました。



少しグーグルで、RGBからHSVに変換するための既製のソリューションをいくつか見つけました 。たとえば、 ここにあります 。 これをテストケースにねじ込んだ結果、これがまさに私たちが望んでいたものであることがわかりました。 その結果、各パックに必要な色が美しく置き換えられ、デザイナーは結果に非常に満足しています。

それにもかかわらず、すべてのパックに1組の基本オブジェクトを使用しても、必要なサイズを維持できませんでした。 すべて同じように、オブジェクトの個別のアニメーションを備えた巨大なアトラスがありました。これは、各世界で一意でなければなりません。



最も効果的なアプローチは、オブジェクト全体のフレームごとのアニメーションを、これらのオブジェクトの個々の要素のプログラムされたアニメーションで置き換えることでしたが、ハードコードでこれを行う必要がありました。 しかし、その結果、これらのアニメーションのダイナミズムと活気の形でボーナスも得られました-事実上、それらに周期性はなく、すべてが所定の制限内でランダムに動きます。 さらに、いくつかの小さな要素で構成されたオブジェクトは、単一のスプライトで描画された同様のオブジェクトよりもスケーリングがはるかに優れています。


これは、最適化の前後のアトラスの外観です。

私が行かなければならなかったもう一つのトリックは、メニューとレベルの背景です。 実際、それらはすべて、かなり小さな解像度で作られており、SDスクリーン専用であり、@ 2x画像はありません。 実際には、ココナッツのテクスチャーはフィルター処理されているため、非常に美しく、最も重要なのは自由に青くなるように拡大されています。 主なことは、ソースを適切に準備して、すでに最小限のブラーがあり、シャープな線がないようにすることです。そうしないと、青ではなくぼやけた正方形の画像が得られます。



一部のテクスチャについて、ソフトウェアブラーを追加しました。 テクスチャをロードする段階で、再描画と同様に発生します。 AWTextureFilterを基礎として使用しました 。

その結果、私たちは独自のスプライトを手に入れました。これは再描画と青塗りが可能であり、その作業は1行のみに制限されています。
CCSpriteExtended *myAwesomeSprite = [CCSpriteExtended spriteWithFile:@"image.png" hueShift:120.0 saturationMult:2.0 valueMult:1.0 blurSize:4];



最後のステップは残っていました-すでにかなり「より薄い」ゲームリソースを最適化することです。 繰り返しますが、長い間検索する必要はありませんでした。 ImageAlphaとImageOptimのペアで動作する2つの無料ユーティリティに出会いました 。 彼らの仕事の結果は単純に素晴らしいです！ 場合によっては、画質をほとんど損なうことなく、ファイルサイズを80〜90％削減できます。

これらすべてのトリックの後、ビルドが150メガバイトから30メガバイトに削減されたことを知って驚きました。 5回！ 不可能なことは何もありませんし、車輪を再発明する意味もありません。検索エンジン内の1つのリクエストのみが私たちを分離するソリューションを正しく適用する必要があります。

iPhone画面の適応

Cytoは主にiPad用のゲームです。 もちろん、iPhoneでプレイすることもできますし、iPhoneのバージョンを好む人もいますが、私たちの意見では、感じ方は私たちが望むものとは少し異なります。 これは依然として最大の相互作用を必要とするゲームであり、iPhone 5のわずかに拡大された画面でさえ、iPadでプレイすることで得られる感覚の半分を与えません。

それにもかかわらず、私はゲームを小さな画面に適応させるために一生懸命努力しなければなりませんでした。 最初に追加されたのは、カメラのズームです。 プレーヤーは、シーンを少し近づけて、より正確に照準を合わせることができます。 ズームレベルを何度も試す必要がありました。 最初は、アートが許す限りカメラを最大限に近づけることを可能にしたかった。 結局のところ、非常に見栄えは良かったものの、多くの不便さを除いてプレーヤーに何も追加しませんでした。したがって、彼らはズームを可能な限り制限することにしました。

一般的な状況から切り離して何かを実行したり評価したりすることはできません。結果全体を確認する必要があります。 何かが非常に独創的であるように見えても、全体的な結果の少なくとも一部を台無しにしているとしても、それは安全に捨てられなければなりません。 特に慎重に、これはゲームプレイの問題でアプローチする必要があります。 ゲームプレイをより良くしない要素がそれのごく一部を悪化させる場合、これは決して残されるべきではありません。

小さな画面でいくつかのレベルを確認した後、iPadからiPhoneにレベルを上げて減らすことができないことがすぐに明らかになりました。 緊急にレベルを調整する必要がありました。 両方のプラットフォームのレベルは同じように見えますが、よく見ると詳細が異なります。

iPhoneのレベルは、iPadのエディターで作成されました。 実際のレベルサイズに対応するフレームをiPhone画面に表示する機能を追加しました。 さらに、iPhone 5の解像度と古いデバイスの同じレベルがすぐに調整されました。



すぐにiPadで、iPhoneの新しいレベルをプレイしてみることができます。スクリーンショットでわかるように、iPadの写真はiPhoneの写真と変わりません。 ただし、最大の難しさは、同じレベルをほぼ1.5倍小さいスペースに詰めることだけではありませんでした。 写真は同じように見えますが、タブレットでのゲームプレイは電話でのプレイとは根本的に異なり、プレーヤーは指でその場所のほぼ4分の1を覆います。

その結果、iPhoneバージョンのゲームは非常に「プレイ可能」であることが判明しましたが、私たちの理解では理想からはほど遠いものでした。 ところで、驚いたのは、Cytoをプレイするデバイスの分布の統計です。iPadプラットフォームに焦点を合わせましたが、iPhoneの数はiPadの数を20パーセント超えています。 どうやら、これはアプリケーションが普遍的であり、市場に出回っているiPhoneの数がiPadを大きく上回るという事実の影響を受けているようです。

おわりに

結論に移りましょう。 上記のすべてを要約すると、開発期間全体にわたって学んだ主なことは、プロジェクトの成功の主な要素はアイデアではなく実装であるということです。 一般的な信念に反して、ゲームデザイナーがプロジェクトを作成したときにどのようなインスピレーションを受けたかは関係ありません。 主なものは、彼が最終的にプレーヤーを見せることができたということです。 また、アイデアがどれほど重要で素晴らしいものであっても、ゲームプレイを改善しなければ、費用はかかりません。 一方、誰もが最も一般的に使用している要素でさえ、ゲームプレイの改善に役立つ場合は、それをゲームに適用してください。

さらに、初心者の開発者（および1年前の私たち）は、次のことをアドバイスしたいと思います。

• ゲームプレイをゲームの世界、プロットなどに添付しようとしないでください。 したがって、あなたは自分自身を狭い境界に追い込み、ゲームに穴を掘ります。そこから抜け出すことは非常に困難です。 正方形、円、三角形のプロトタイプを再生することが面白い場合は、先に進むことができます。 ゲームメカニクスの可能な限り多くの異なるオプションを考え出します。 優れたゲームプレイがあれば、ほぼすべてのプロットを実行できます。 それどころか、それは非常に困難です。 Cytoでは、既製のゲームワールド、キャラクター、プロットの形式のレーキが点在し、間違った方向に進みました。 そして、それは私たちにとって素晴らしい教訓でした。
• 強みと締め切りを現実的に評価します。 私たちは数ヶ月でゲームを作ることを計画し、さらに数倍を費やしました。 私たちは幸運で、プロジェクトを完了することができました。 そして、残念なことに、ほとんどのスタートアップにとって、彼らの強さを再評価することは失敗に等しい。 自分に正直になって、あなたの計画を終わらせることができるかどうか自問してください？
• デザインパターンは優れていますが、万能薬ではありません。 そして、パターンのためのパターンはまったく良くありません。 結局のところ、ゲームでは実際にそれらを適用する場所はまったくなく、構造があまりにも具体的です。 不適切なパターンをだまして、すでに複雑なコードを作成するよりも、事前に機能を考え直し、ささいなことすべてを考慮に入れておくと、はるかに簡単になります。 そして、はい、誰もコードに関するコメントをキャンセルしませんでした。
• ツールを使用して、ワークフローを整理しやすくします。 バグトラッカー、Wiki、タスクリスト、アジャイル/スクラム-これらはすべて、より効果的になるのに役立ちますが、それが本当に役立ち、適合することを条件としています。 誰かがあなたにそれらをアドバイスしたからとか、最新の傾向に従うようにという理由だけで、これらのツールを使用しないでください。 試してみてください！