最初の計画によれば、次のものが計画されていました：最小限のグラフィックス、最小限のUI、および最小限に抑えることができるすべてのものは、Match-3と同じ数の市場にある今日のカジュアルゲームのスタイルであったはずです。 その結果、私たちの目標は次のとおりでした。丸いチップは、所定の形状で接続され、スワイプで4方向に移動します。 すでにCubicityをプレイしたことのある人は、私たちがこのタスクから遠く離れていないことを知っていますが、2人だけで構成されるチームのように、残りの部分でかなり大きな飛躍を遂げました。
読者の一人が、ここで成功した迅速なゲーム開発の秘密を見つけることを期待しているなら、秘密がないことを知っておく必要があります。 ここでは、素晴らしい経験や知識は共有しません。ここでは、小さな会社の1つのプロジェクトの歴史のみを説明します。 成功したかどうか、まだわからない。 しかし、多くの人にとって、読者は開発者自身からの過去からのメッセージです。
Cubicityの作成の歴史に戻ると、主にUnityのみに取り組んでおり、自尊心のあるUnity開発者の標準セットは次のとおりです。Newtonsoft.json、Zenject、Cinemachine、Dotweenなど。上記のように、ゲームの最初のプロトタイプはキューブ、パンケーキ。 ゲームを多様化し、プレイヤーを魅了する方法を1週間考えた後、素晴らしいアイデアが生まれました。立方体または丸いキャラクターのアセットストアを見てください。 まあ、それは始まった、キャラクターのいくつかのパックはためらうことなく購入されました。 同じ状況は、キャラクターが移動しているブロックでも発生しました。 彼らはまた、約30の新しいグッズのリストから新しいゲームプレイ要素のリストを作成し、ブロック/矢印のリダイレクト、エレベーター、テレポートなどの中立なものがスタートのために選択されました。 彼らは残りを新しいレベルに任せ、一度に1つずつ30-35レベルに導入することにしました。
正直なところ、最初にこれほど多くのレベルを実行するようになった理由を思い出せませんが、95レベルが最初のリリースになりました。 実際、多くのことを後悔しています。 どうしてごめんなさい？ しかし、ゲームは未加工であり、多くのことが変化しているためです。 95レベルのそれぞれに移動して変更を加えることで、「グラウンドホッグデイ」を頻繁に摂取する必要がありました。 すべてのレベルで2か月の連続稼働が必要でした。 これらはすでに100％完成したレベルではありませんでしたが、非常に近いレベルでした。 生産的な日には、10レベルを頭から紙に移動してからシーンに移動するのは難しくありませんでした。 しかし、カリフォルニア州出身のヘンク・ムーディがクリエイティブな危機に直面していると感じる日がありましたが、すべてが乾燥していると思いますが、新しい日と新しいアイデアが生まれます。
視覚コンポーネントについて話すと、すべてがやや複雑になります。 ほとんどのゲームのように、レンダリングはネイティブよりも低い解像度のオフスクリーンサーフェスに対して実行され、メインサーフェスを照らしますが、UIは解像度を変更せずに明瞭さと読みやすさのために描画されます。 したがって、私たちは両方の世界の最高のものを手に入れます-ぼやけたUIではなく、ゲームであまりにも大食いのレンダリングではありません。 スムージングのために、2x MSAA + FXAAが実験的に選択されました。これは、最小限のリソースで最高の画像を提供するものです。 論理的なゲームには1秒あたり60フレームは必要ないと判断したため、ホイールを再発明せず、フレーム制限を30fpsに設定することにしました（言うまでもなく、コンソールでも通常これを行います）。 フレーム制限を設定すると、エネルギー消費だけでなく、電話の加熱にもプラスの効果があります。これにより、電話の過熱による速歩が防止されます。
難しい決定が私たちよりも先にあり、これらがフィニッシュポイントです。 レベルを開始するたびに、プレイヤーが使用できるキャラクターからキャラクターがランダムに選択されるため、キャラクターのフィギュアのサムネイルを描画するのは問題です。 あなたはそれを信じていないかもしれませんが、最も長く解決され、後で遅れるのはまさにこの問題でした。 フィニッシュのキューブは、そのような不気味なアイデアのようには見えなかったので、紙の絵はレベルを超え、全員を自分の場所に連れて行ってくれました。 その後、キューブの代わりに同じキャラクターを使用することが決定されましたが、小さいキャラクターはより良くなりましたが、それは私たちだけです。 数日後、これらのキャラクターが展開されて強調され、誰が誰であるかが明らかになりましたが、それでも満足のいくものではありませんでした。 最終バージョンは、1か月後に試行錯誤によって採用され、さらに数週間かけて仕上げのアイコンを作成しました。 さようなら夏、またお会いしましょう！
私たちの謙虚な意見では、雲の外観は非常に快適であることが判明しました。 しかし実際には、これは最も単純で、それほど汚くないハックです。 彼らがクラウドを追加することに決めたとき、最初の考えは360ビデオの背景を作ることでした。 モバイルプラットフォームでは、LTEでのダウンロードのサイズ制限にゲームを適合させることが望ましいため、このアプローチは報われていません。 ビデオが破片を引き裂くために与えられた圧縮ジャッカルよりも少し良く見えるようにするために、彼は10-15 MBを割り当てる必要があり、クラウドでのゲーム内の夜間レベルの存在と組み合わせて、大きすぎます（Androidでのゲームの最終ビルド全体では61 MBかかります）。 2番目の欲求は、クラウド用のシステムを作成することでした。開発者としては魅力的でしたが、できるだけ早くゲームを終了したい人には適していませんでした。 解決策は、雲のテクスチャを作成し、粒子の寿命が無限で、全体で限られた数の粒子のシステムを作成するという形で提供されました。 その後、ランダムな回転とともに2つの定数の間にランダムなサイズを追加しました。 結果は満足のいくものでした-私たちの空はきれいな雲で満たされ、雲を見たときに泣きたくはありませんでした。
ゲーム（モバイル版）の影は完全にクワッドで構成されており、モバイル版に実際の影を追加したくなかったため、単純に手動で配置されます。 その理由の1つは、OpenGLES 2.0を搭載したモバイルプラットフォームでのソフトシャドウの欠如と、もちろん弱いデバイスでのパフォーマンスの低下です。
前述のように、スムージングには2x MSAA + FXAAを使用しましたが、それだけではありません！ また、AmplifyColorが後処理プロセスに追加されました。これは、あなたのお金のための優れた資産であり、後処理にさまざまなLut-sを使用できます。 適切なlutを使用すると、画像が良くなります。 開発プロセス中に、標準的な統一後処理スタックを含むさまざまなアプローチを試みましたが、ビルドではシェーダーとオプションが非常に多く使用されるため、おとぎ話やペンでは説明できませんでした。 いくつかの解決策は非常に美しいものでしたが、最初の新鮮さではない電話では非常に貧弱に働きました（誰もが少なくとも「普通の」電話を持っていると思うなら、あなたは間違っています。あなたのDOOMは電子レンジに入れないというコメントであなたに不平を言います）。
ゲームのバランスは常に容易ではありません。今でも、レベルが複雑すぎるか、難しいレベルが頻繁に落ちるかなどの考えが浮かんできます。 左足でバランスが取れるようになったので、プレーヤーを簡単にするツール（Go Back、Bomb、Ice Block、Teleport）を導入することにしました。そうです、それは私たちにとってではなく、将来のプレーヤーのためだけに生きやすくなりました。 さらに作業とバグがあります。
ゲームメニュー、長所、極限までの神経に到達し、創造的な性質がブレーキをかけました。隠れることはありません。他のゲームに触発されなければなりませんでした。 そして今、「朝、カメが出てきました！」 翌朝は正しくありませんでしたが、以前に作成されたレイアウトのUIの準備ができました。
スタイリッシュでファッショナブルな若者への欲求も、私たちを迂回しませんでした。 クラウドベースの保存を追加することにしましたが、一般的には後悔しませんでした。 これは、プラットフォームが異なるとクラウドストレージのプロバイダーが異なるため、最も簡単なタスクではありませんでした。 Steamでは、モバイル、GooglePlay、およびGameRoom用のSteamworksです。 そのため、ストレージシステムを統合して、目的のプラットフォームを代替できるようにしなければなりませんでした。 そもそも、これらの目的でEasyMobileを使用することにしましたが、悲しいかな、遅かれ早かれこの考えを捨てました。 プラグイン自体は優れており、膨大な数の機能を備えていますが、ネイティブクラウドストレージでの作業の詳細はあまり好きではありませんでした。 その結果、Firebase Realtime DatabaseとFacebook経由の認証が選択の対象となりました。 要するに、私はそれを機能させるために地獄の7つの輪を通過しなければなりませんでした（そしてこれはプログラミングの問題ではなく、アプリケーションの100,500の場所で、Facebook、Firebaseなどで行う必要がある100,500の設定で）。 また、データベースにはトラフィック制限があり、それを保存するために、作成するたびにGUIDを作成し、データベースとデバイスの両方に記録します。 したがって、デバイスとクラウドのGUIDが同じであることがわかった場合、クラウドからすべてのデータを読み取る必要はありませんが、データのローカルコピーを使用できます。 その結果、同期が追加されましたが、...私たちにとって最も奇妙なバグの1つは、場合によってはFirebaseデータベースの明らかな動作でした。 Jsonを使用しているため、状態を保存するためにクラスをシリアル化しますが、Firebaseが多少奇妙に動作することがあります。
辞書オブジェクトを作成するためにFirebaseを渡すと、たとえば次のようになります。
var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, new SlotState() }, { 2, new SlotState() };
データベースから読み取ると、Jsonオブジェクトではなく、Json配列が取得されます（何？）
まあ、もちろん、どこでもリストを使用し、問題は発生しませんよね？ しかし、そこにありました。
Firebaseに書き込む場合：
var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, new SlotState() }, { 100500, new SlotState() };
または：
var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, null }, { 2, new SlotState() };
データベースから読み込むと、キーと値を持つJsonオブジェクトが取得されます。
開発者のロジックをある程度理解することは可能ですが、しばらくするとバグが発生する可能性があります（上記のGUIDが保存のために追加されたことを覚えていますか？その結果、比較的頻繁にエントリを含むデータベースからのまれな読み取り）。
リリースはいつですか？ この質問は最も頻繁に聞かれました。 しかし、この日に備えて徹底的に準備する必要がありました。 市場のリストを作成し、リリース日を選択し、主要な販売を避け、かなりのニュアンスを避けます。そのため、リリースは少なくとも2か月間移動しました。 ある記事のアドバイスを聞いた後、リリースに火曜日と水曜日を選びました。 w3bsit3-dns.comで正確なレビューを注文し、いくつかのフォーラムにゲームに関するニュースを投稿し、特定のInstagram（もちろん有料）のソーシャルネットワークを爆破することにしました。 このすべてがうまくいったので、このストーリーの後半で学習しますが、それは後でのみです。
最後に何がありますか？ 簡単なゲームを作成することは必ずしも高速ではありません。 また、ゲームの作成に予想される時間枠に5を掛ける必要がある可能性があります。慣れていない領域で実際的なアドバイスをしてくれる人を集めてください。 ゲームだけでなく何かを作成するには多くのエネルギーが必要なので、あらゆる機会にリラックスしてください。 スローソーセージになり、プロジェクトの開始時にあまり役に立たないのは良くありません。 まあ、お金、お金を探して、あなたはそれが必要になります。 そして、私たちから、あなたの注意、幸運に感謝し、次の記事でお会いしましょう。