ゲーム開発。 ナプキンのアイデアからキックスターターキャンペーンへの道

こんにちは。 私の名前はアンドレイ・ブラセンコです。 私はウクライナのハリコフ市に住んでいます。 私は専門職によるソフトウェア開発者です。 ApexTechのCIOとして働いています。 私たちのゲーム「Demolition Lander」の作成についてお話したいと思います。



開始するには、最後に何が起こったのかを示す小さなトレーラーをご覧ください（ゲームのフレームは50秒から始まります）。

アイデアの誕生

私の頭の中にこだわったアイデアほど悪いものはありません。 最初は意識の奥にあるだけで、潜伏期間が過ぎると行動を促します。 そのため、エンタープライズで約7年間働いた後、ゲーム業界で自分自身を試してゲームを作成したいと固く決心しました。

この決定の瞬間から多くの時間が経ちましたが、ある日、なんとなく予想外にアイデアが具体的なアウトラインを獲得しました。

昼食時に、友人のSasha（ApexTechのCEO）と私は、以前はどのようなゲームだったのか、それぞれのゲームが好きだったのかについて話しました。 両方とも、Atariの古典的なゲーム、Lunar Landerを思い出しました。 議論の過程で、私はナプキンに2つのエンジンを搭載した船を描き始めましたが、たまたまこれらの同じエンジンは対称ではなく、異なる方向を向いていました。 かろうじて知覚できる笑顔が私たちの顔にちらつきました。 -ここにある！ 2つのエンジンを搭載した船を備えたLunar Landerのメカニックは、別々のジョイスティックで制御されます。 「大ヒット！」



将来、この概念は破壊可能なレベルとアクションの要素で大きくなりましたが、それについては後で詳しく説明します。





最初の船

最初のプロトタイプ。 マルチプラットフォーム。 エンジンの選択。 最初の誤解

会社がこのプロジェクトに青信号を与えることを決めたという事実から始める価値がありますが、私だけが人々から選ばれました。



モバイルデバイス向けのゲームを作成する予定だったので、当然のことながら、オリジナルのマルチプラットフォームについて考えました。 ゲームエンジンは、cocos2dおよびUnityバリエーションから選択されました。 このエンジンは3Dに適しているため、長い議論の末、Unityを拒否しました。2Dでの作業には曲がりがあります。 さらに、私はcocos2dを少し経験しましたが、彼の好意により選択が行われました。

最初のプロトタイプは、cocos2d Javascriptに基づいて構築されました。 このテクノロジーの利点は次のとおりです。

• Javascriptコード
• 同じコードが、html5をサポートするブラウザーを含む、ほぼすべてのプラットフォームで機能します

短所はそれほど重要ではないことが判明しました：

• エンジンの開発者がどのように保証しても、ネイティブオプションと比較して動作が遅い
• プラットフォーム固有の機能の実装はかなり混乱し、曲がっています

つまり、本格的なゲームの場合は、コードのすべての重い部分とプラットフォームに依存する部分（同じGame Centerまたはアプリ内購入）をネイティブに実装する必要があります。 Javascriptバインディングを介してそれらをストレッチし、一般的なJavascriptコードで使用します。 このプロセスは迅速でも快適でもありません。





最初のプロトタイプ



このレーキにヒットしたため、ポジションが修正されました。 これまでのところ、iOS専用のバージョンをcocos2d-iphoneで作成することにしました。 名前にもかかわらず、このエンジンは、iPhoneとiOSを実行している他のAppleデバイスの両方でうまく機能します。



物理学は、Chipmunk 2Dを使用して実装し始めました。 質問する人もいます-なぜBox2Dを使わないのですか 答えは簡単です。最初のプロトタイプを作成した時点で、cocos2dのJavascriptバインディングはChipmunkに対してのみ実装されていました。 ネイティブcocos2d-iphoneに切り替えるとき、私たちはそのままにしておくことにしましたが、将来は後悔しませんでした。

ゲームプレイ 彼はそこにいますか？

開発の数週間が経過しました。 プロトタイプの準備ができました。 ゲームの仕組みが準備できました。 すべてが飛ぶ、エンジンが回転する、レベルが大きい。 もう少し増えたようで、App Storeでレイアウトすることができます。 しかし、このゲームをプレイするのは退屈です。 そして、これは一つのことを意味します-ゲームにはゲームプレイがありません。

その時に実装されたゲームの仕組みの要素は次のとおりです。

• 給油のために着陸する必要がある平らな地上ステーションの束と高レベル
• 船には2つのエンジンが装備されており、1つのジョイスティックで同時に制御することも、2つのジョイスティックで別々に制御することもできます
• ゲームの目標は、破壊することなく最後まで飛行することです

ブレーンストーミングセッションの後、次の要素が計画されました。

• あらゆる点で船をポンピング
• アップグレードを購入して新しい遠方の惑星に飛ぶことができるエネルギーのある球体
• 船の修理ボックス
• 地下洞窟
• 洞窟の燃料缶
• 破壊可能な水平面
• 船の武器-爆弾
• 危険ゾーン-時間が経つにつれて船が損傷を受けるゾーン
• パッシブおよびアクティブトラップ-地雷および対空設置
• 洞窟の奥深くに隠された各レベルのアーティファクトに固有
• ゲームの目標は古い

新しい機能を承認したため、チームを4人に拡大することが決定されました。

レベル寸法

私はいつも、制限や負荷なしで動き回る大きなスペースがあるゲームに魅了されてきました。これをDemolition Landerに実装しようとしました。 ゲームのレベルは巨大です。 レベル全体を描画すると、サイズ65 536 x 16 384の画像が得られます。これは制限ではありません。パフォーマンスをあまり損なうことなく、65 536 x 65 536に増やすことができますが、ゲームプロセスは定期的な調査を伴う地上の水平飛行として見られます地下の洞窟。

ゲームのレベルは、次の要素で構成されています。

• レベルマスク-サイズ2048 x 512のレリーフのグレースケールテクスチャ（重ね合わせると32倍に増加）
• 土壌テクスチャ、エッジ、エッジパターン、およびテクスチャを使用して、すべてのテクスチャをストレッチマスク上のオーバーレイと混合
• 空と星のテクスチャを持つタイルマップ

レベルマスク





土壌テクスチャ、エッジ、エッジパターン、およびすべてのテクスチャの混合





空のタイル地図





その結果、レベルが描画されます



レベルレンダリングアルゴリズムは2つの部分で構成されています-空のレイヤーを読み込み、そこから視差を作成します。 地面のテクスチャをロードし、これらのテクスチャをオーバーレイするシェーダーを初期化します。

地球の破壊可能な表面の実装

ゲームの最も壮観な機能の1つは、実装に非常に責任あるアプローチを必要としました。 表面の破壊は、レベルおよびグラフィックディスプレイの物理的なボディの境界と同期して、迅速に発生する必要があります。

地球の物理的な境界を作成および更新するために、Chipmunk 2D Pro機能を使用しました。これは、レベルレリーフマスクのテクスチャをスキャンし、境界線を含むタイルのセットを作成します。 その後、船がレベルに沿って移動すると、ラインのある近くのタイルが再カウントされ、古いタイルがメモリからアンロードされます。

変形自体は、適切な場所でマスクのテクスチャを変更し、物理的な境界を持つタイルを再計算するという形で実行されます。 グラフィカルに、変形は次のフレームをレンダリングするときに即座に表示されます-これは、物理エンジンとアースシェーダーの両方が同じマスクを使用するという事実の結果です。





物理デバッグ層が有効

ゲームの準備はできていますか？ -いいえ

魅力的なゲームメカニクスを備えた完全に機能するゲームを手にすることで、App Storeはこれまで以上に近づいているようです。 しかし、Test1、Test2という名前のレベルと、正気なデザインのない1つの長方形の船は、他の何かを物語っています。 設計とコンテンツの時間です。



コンテンツの作成自体。 船の種類、その名前、特性、惑星名、各レベルでのゲーム内のお金の量-すべては次のブレーンストーミングセッションのセッションで決定されました。

しかし、設計により、彼らはフリーランサーを雇うことにしました。 はい、フリーランサーだけでなく、傑出したポートフォリオ、優れた英語、一見常識があるインドの市民です。 人々は突然だまされています。 時々人は単に連絡を取り合っていなかったという事実から始まり、図面の不快な品質で終わり、私たちが彼から得たい基本的なものを誤解しています。 同時に、人間の行動のモデルは一貫性の点で驚くべきものでした-「OK、先生。 問題ありません。 完了します。」



死んだ週の後、彼らはフリーランサーと別れ、継続的にチームのデザイナーを探し始めました。

デザイナーを見つけることは、デザインの何かを理解している人にとっては簡単です。 私たちはそうではありませんでした。 送信されたポートフォリオによって判断されます。 気に入った-招待、人を見た。 そのため、あるユニークな「クリエーター」に出会った。 彼のポートフォリオはすばらしく、さまざまなスタイルの美しい高品質の図面、フリーハンドスケッチ、3Dモデルが多数ありました。 彼らは明らかに適切な人を招待し、話しました。 夕方、同僚が候補者の絵の1つへのリンクを全員に送信します。 絵は彼のものではありません。 ポートフォリオの残りの80％のように。 道徳-人は嘘をついており、Google Imagesは見栄えが良い。



その結果、彼らはまだ割り当てられたタスクに非常にうまく対処し、私たちのチームの不可欠な一部となったデザイナーを見つけました。





対空マウントとブラックホール





爆風

最適化とメモリリーク

さらに数ヶ月が経過しました。 デザインとコンテンツの準備ができました。 実際のレベルでは、ゲームは遅くなり始め、長期間使用すると定期的にクラッシュしました。 メモリリークの検索とパフォーマンスの最適化を開始しました。

メモリリークの中で最も苦労したのは、ブロックとARCと組み合わせたブロックの使用でした。 2番目は、オブジェクトのグラフの不適切な構築です。つまり、互いに含まれるオブジェクトへの強いリンクです（複数のネストされたオブジェクトを介しても）。

パフォーマンスの最適化は、船の視野と爆弾の到達範囲内のオブジェクトのみを描画およびカウントするという1つの原則に基づいています。

結果。 準備-90％

開発の半年。 ほぼ終了したゲーム。 自己資金調達の可能性の終わり。

残りから：

• いくつかの惑星/レベルの芸術
• 音と音楽の洗練
• 古いAppleデバイスの最適化
• テストと再テスト

計画から：

• マルチプレイヤー
• より多くの武器
• より多くの惑星とレベル
• モバイルプラットフォーム、Ouya、PCおよびMAC用のポート

より良くできること

1つは、開発のタイミングについて空想することではありません。 最初の期待は、数か月に投資することでした。

次に、すぐにチームでデザイナーを探し、開発全体と並行してその一部を開始します。 これにより多くの時間を節約できます。 フリーランサーもいません。

さて、3番目-最初のプロトタイプから現在の状態まで、興味のあるすべての人にゲームを見せるべきでした。 これにより、プロジェクトがKickstarterでリリースされるまでに、解体着陸船について「知識があり」「話している」一定のベースが集まっていたでしょう。

キックスターターキャンペーン

Kickstarterキャンペーンは別の記事に値します。機会があれば、間違いなく執筆します。

要するに、資金調達を成功させるための基本的な要因は、ファン層、クリエイターの認知度、および/または製品の認知度です。

現在、Demolition Landerの資金を調達する2番目のキャンペーンを開始しました。 最初のものは、PR戦略が失敗したためキャンセルする必要がありました。



2番目に何が起こるかは明らかではありませんが、不穏な傾向があります。