爆発的なGameDev。 私のゲームの物語

最後に、彼らはモバイルプラットフォームの開発者の軍隊に参加し、このトピックにどのように着手したかについての記事をここに書きました。 Unity3dエンジンがゲームを記述するために選択されたことをすぐに書きますので、人々が私が説明しようとしていることを理解します。

アイデアについて

ストーリーの最も興味深い部分は、元のアイデアが最終的な実装と完全に一致しなかったことです。 なんで？ はい、すべてが簡単です。 最初は、チューリングマシンを使用してパズルを作成するというアイデアがありました。



より明確にするために、例を作成します。 腹が立つ怒っている鳥が少しいると想像してください。 ゲームの仕組みは単純で、鳥を捕まえて豚に向けて走らせます。 そして、ここにチューリングマシンを取り付けます。 たとえば、画面の下部には、アクションの順序を反映するメニューがあります。 鳥を放つだけでなく、アクションのキューに、どの速さで、どの角度で打つかを記述します。 この場合、すべてのアクションが正しく完了すると、レベルが完了します。







もちろん、私のプロジェクトでは邪悪な鳥はいませんでした。ポイントは正しい順序で箱に火をつけることでしたが、今は違いはありません。 最終的に、プロジェクトはゲームと実装の両方にとって複雑すぎると判断しました。 その時までに、私はたった1か月だけエンジンで作業し、特定のボックスに正確に分配された火災をなんとかしていたが、チューリングマシン自体に問題があった。



その後、ある時点で、フルーツスライスでリプレイし、その後、団結し、四方から飛び出したばかりの箱を作りました。 一般的に、私は約10分間この写真を見ました...



そのため、最終的なアイデアが形成されました。



ただし、ゲームの純粋なクローンを作成するだけでは、それを宣伝するのに十分ではないことは誰もが知っています。 果物をゲームに追加するというアイデアは、スーツケースが現れてすぐに緊急便で送られました。 箱を半分に切るというアイデアもそこに送られました。 爆発が必要でした！ 明るい写真はユーザーを引き付けるはずです。 しかし、箱を爆破してポイントを獲得するというアイデアは、少なくとも理想に達していないと考えられていました。 ゲームを本当に面白くするためには、ボックスが爆発した後に何かが起こらなければなりません。 さらに、時々イベントが発生したり、風が吹いたり、重力が消えたりした場合は興味深いでしょう。



これらすべてのことを考えて、私はノートを手に取り、ゲームの概念をスケッチしようとする時だと判断しました。



ここで、上で書いたすべてを実装するためのオプションを検討します。

ゲームについて

開発された最初のコンセプトは次のようになりました。







爆発する可能性のある箱を飛ばすだけで、簡単なことはありません ただし、これについて考えるのは愚かなことです。



ゲームの次のバージョンは次のようになりました。







ボックスはマルチカラーになりました。 すでにもっと面白かったです。 さらに、特定のボックスの爆発後に発生した効果によって決定される色のために、それらは多色になりました。



たとえば、黄色のボックスが爆発した後、静止した球体が表示されました（上のスクリーンショットで確認できます）。 それに関する他のオブジェクトを壊すとき、プレーヤーはボーナスを受け取りました。 青いボックスが爆発した後、球体も現れましたが、現在はホーミングし、何かに当たった場合、プレーヤーにペナルティが与えられます（獲得した合計ポイント数が減ります）。



そのようなチップを追加することでゲームがより面白くなりました。これは、ユーザーが無頓着にボックスを壊すのをやめ、最初にどのボックスを壊すかを選択できるようにしたことです。



それで、私は徐々に新しいアイデアを開発し始めました。 時間に応じて発生した後のイベントが現れました。 たとえば、風が吹き始めてすべての箱を吹き始めた、または冷たい風が吹き始めたので、すべての箱が吹き付けられ、さらに凍りました。そのため、テクスチャが氷の地殻に変わり、現在飛んでいる箱を特定するのが難しくなりました。



スキルツリー。



スキルツリーは後で追加されました。 画面は次のとおりです。







スキルツリー画面は、ゲームの最新ビルドの1つで、以前とは異なって表示されていました。

私の謙虚な意見では、スキルツリーのあるゲームは、スキルツリーのないゲームよりも長生きします。

一般的に、ゲームプレイは非常に独創的です。 ゲームの名前はよりシンプルであることが判明しました。 たとえば、ゲームフルーツスライスがあります。 どうすればいいですか？ もちろん、果物を切る！ 画面上のすべてを爆破する必要がある私のゲームがあります。 そのため、Explode It！という名前です。



アイデアが完成したら、実装されたときに生じた興味深いポイントに進みましょう。

プロジェクトの技術的な部分

技術的な側面の説明に進む前に、これが私の最初のゲームであり、たくさんの株があるので、ご存知のように建設的な批判を歓迎します。



ゲームはUnityで作成されました。 私の意見では、この選択は、最高ではないにしても、最高の選択肢の1つです。 このエンジンには非常に多くの利点があります。 学ぶのは簡単で、クロスプラットフォームであり、エンジンにはフォーラム、アセットストアなどを含む巨大な作業エコシステムがあります。



まあ、そして最も重要なこと-それは無料です。 今、私が知る限り、アンリアルエンジン4やソース2なども無料で提供されていますが、このトピックに精通し始めたとき、これらのエンジンはまだリリースされていないため、選択は明らかでした。

UI

Unityの標準UIは好きではありません。 遅い、いくつかのオプション、画面の側面へのバインドなし（今、私が知る限り、あります）。 その主な問題はOnGUI関数で、これはフレームごとに数回起動する可能性があり、モバイルデバイスでは受け入れられません。



ここに1つのポイントがあります、私はUnityバージョン4.5.4でプロジェクトを書きました、このバージョンでは画面の異なる側面に結び付けられたインターフェースがありませんでした（そして、新しいバージョンに切り替えるとクレイジーなバグがあり、ベータテストでした）ためらうことなく、標準UIの代替品を探し始めました。 それで、NGUIを見つけました。

NGUI

NGUIの原則は次のとおりです。すべてのGUI要素は、独自のマテリアルを持ち、パフォーマンスを犠牲にすることなく携帯電話でも簡単にレンダリングされる単純なオブジェクトです。 ここで1つのことが起こります。ボタンを押すなどのイベントを処理するために個々の機能を表示する必要があります。

NGUIが支払った。 Assetstoreで購入する場合、最新バージョンの価格は95ドルで、Unityバージョン4.5.5以降が必要です。 しかし、求める者は常に見つけます。 NGUIは無料で、さらに公式ウェブサイトで無料で配布されています。リンクはこちらです： www.tasharen.com/forum/index.php ? topic=526.0 Unity公式フォーラム： forum.unity3d.com/threads/nguiでも見つけることができます。 -free-edition.124032



投稿の最後に、1つの重要な詳細が記載されています。 NGUI 2は、NGUI 3のリリース時に2013年9月に非推奨になりました。これは過去のバージョンであり、3番目のバージョンには最新の機能がありません。 さらに、サポートが不足しています。 このバージョンの商用利用には別の制限があります。 Unity Freeの商用利用の条件に該当します。 組織の総収益が100,000ドルを超えない場合（前会計年度の結果に基づく）、Unityの無料版は商用利用のライセンスを取得できません。



ネタバレの下で英語の原文を読む：





よくある質問（ライセンスとアクティベーション ）へのリンクUnity： unity3d.com/unity/faq



一般に、このバージョンを引き続き使用できます。



このUIシステムの主な利点は、画面のさまざまな側面にバインドできることです。これにより、機能的なインターフェイスを作成できます。 さらに、すべてのインターフェイスオブジェクトが1つのアトラスに含まれています。 Atlasは、インターフェイスのすべての要素を含む非常に大きなテクスチャです。 たとえば、フォント、ボタン、アイコン、その他すべてのテクスチャ。 モバイルデバイスでは、最適化のためにそのようなテクスチャのサイズを2048/2048に制限することが望ましいです。



一般に、今はNGUIのすべての機能について説明するつもりはありません。ハブ（特に初心者向け）に関するすばらしい記事があり、その機能のいくつかについては既に説明しています。リンク： habrahabr.ru/post/211536



NGUIで記述されたインターフェイスの例：

更新とコルーチン

プロジェクトの開発中に発生した別の質問は、時間を効果的に計算する方法です。 以前は更新機能でこれを行っていましたが、1つの問題があります。 この機能はフレームごとにトリガーされます。 ゲームに60 fpsがある場合、毎秒60回起動します。 電話機の場合、これらの機能のいくつかをステージ上に配置すると、パフォーマンスが大幅に低下します。 この関数の呼び出し回数を減らすか、関数を別のオプションに置き換えることをお勧めします。

この問題を解決する良い例はコルーチンです。



たとえば、ゲームプレイのあるシーンがあり、ゲームを終了するか新しいシーン（タイマーなど）をロードするまで、毎秒発生する何らかのアクションが必要です。



これを行うには2つの方法があります。



Update関数を使用して、Time.deltatimeの値で時間をカウントする変数をインクリメントする必要があります。

float currentTimer = 0; void Update() { currentTimer += Time.deltaTime; if (currentTimer >= 1){ //  currentTimer = 0; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目の例。 コルーチンとWaitForSeconds関数を使用すると、異なる方法でそれを行うことができます。 2番目のケースでは、現在の時刻を常に確認するために条件ブロックを作成する必要さえありません。



例：

 IEnumerator Example() { while(true){ yield return new WaitForSeconds(1); //  } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

画面解像度

Androidがデバイス動物園であることは秘密ではありません。 これは、多くの面白い瞬間であり、あまり面白くない瞬間を意味します。 そのようなポイントの1つは、画面の解像度です。



IOですべてが多かれ少なかれ明確であれば、Androidで疑問が生じます。



最初は、ゲームの視覚部分全体が16:10の解像度に調整されました。



一般的に利用可能な解像度については、ここでAndroidプラットフォームで使用されている画面解像度の概算（！）表を見ることができます： geektimes.ru/post/169141



タブレットの画面解像度の表は次のとおりです。







電話用の画面解像度の表：







すべてのテストの後、唯一の問題は4：3の解像度の修正でした。



状況全体を修正する方法がいくつかありました。

• すべての画面比率については、画像をそのままにしておきます。 コード内の画像は変更せず、エディターで修正してください。 比率ごとに個別のアセンブリを実行し、写真の元のサイズを変更する必要があるスクリプトの束を記述する時間がない場合の通常の解決策。
  
  この方法の利点：スクリプトを作成する必要がなく、異なる比率で複数のアセンブリを実行する必要がありません。 純粋な時間の節約。
  
  1つの欠点があります。 全体の画面を4：3の比率で画面に合わせると仮定します（通常、画面が横向きのこの比率の画面では画面の端からはみ出します）が成功したと仮定します。 同時に、16：10のアスペクト比のゲームは通常通りに見え、16：9では側面の未使用領域が発音されます。
• 比率に応じて写真のサイズを変更します。 これは、スキルツリーを担当するシーンで行いました。 しかし、一般に、時間が不足している場合、この方法は最適とは思えません。 変更する必要があるものが多すぎます。 個々のテクスチャだけでなく、テキスト自体（画面からクロールされたもの）なども含まれます。
• カメラのサイズを変更します。 景品をキャッチすることを明確に目指している人の方法。 カメラの幅（右側の未使用領域に興味がありました）だけでなく、カメラの高さも論理的に変化するため、ほとんど役に立ちません。 また、NGUIを使用していて、スクロールメニューを担当するIUDraggablePanelスクリプトがシーンにある場合、これは役に立ちません。

一般に、最初のオプションを使用したとすぐに言いますが、このような結果が得られました。

4：3





3：2





5：3





16：9





16:10





上記の写真からわかるように、4：3の解像度では、メニューはほぼ画面全体を占めますが、たとえば16：9の解像度では、側面の未使用領域が表示されます。



2番目のオプションはスキルツリーではあまり役に立たず、最初はスクロール可能なメニューがボタンの下にあり、後でレベルがロードされたときに編集を開始しました。



それにもかかわらず、私は自分のレベルで問題に対処したと信じています。

テスター

それらは必要です...さらに、それらは必須です。 プログラマーが疑わない多くの問題については、テスターが彼に言います。



たとえば、最初はゲームが複雑であることが判明したこと、アニメーションが長すぎること、ボタンを数回作動させること、指を押したままにすること、特定の条件下でスキルが機能しないことなどを知りませんでした。

要するに、テスト後にゲームがどのように変化したかについて、いくつかの例を示します。



スキルツリーのデザインはほぼ完全に変更されました（カットの下）。 ところで、ゲーム内でフォントが完全に変更されました。



古いバージョン：







新しいオプション：







同じ色のボックスがさまざまな幾何学的オブジェクトに変更されました。 ところで、ここに興味深い点があります。色に加えて、オブジェクトで何か他のもの、たとえば幾何学的な形状が変化した場合、人は状況をよりよく理解します。 面白かったのは、 元々は純粋な色で十分でした。



古いバージョン：







新しいオプション：







それはすべて興味深い技術的なポイントです。 もちろん、最適化プロセスについても記述できますが、最適化プロセスについては非常に長い間記述します。この記事は単純に膨大なものになります。 紳士の皆さんが読みたいと思うなら、このトピックに関する記事を後で書きます。



すべてが計画どおりに進んだ場合、後でプロジェクトのプロモーションに関する情報を共有し、出版と分析の機能について説明します。多くの人にとって興味深いと思います。



それだけです。記事を読んでくれてありがとう。