インディーのgamedev-developerになった経緯や、ひざの上での国家開発の特徴

私はプロのソフトウェア開発者ではなく、プログラミングは私の主な仕事とはほとんど関係ありません。 すべてがはるかに悪いです-これは私の趣味です。 アクティビティの変更は非常に便利で、退屈で単調な作業から休憩することができます。また、プロセスと結果を楽しむことができれば、二重に役立ちます。



私にとって、gamedev（ゲーム開発）は常に興味深いものでした。 すべての子供（10代、オタク、自分の子供に代わる人）には、遠く、実際には到達不可能なものではありますが、そのような夢があったと思います。 彼らのほとんどは成長し、現在の問題の重みでそれを安全に忘れており、子供たちが成長して自分自身に似たものを作り始める瞬間までそれを保持する人もいます。 私は2番目のグループに属していたのは幸運（または不運）でした。

背景

gamedev開発者としての私の形成がどのように進んだかについて、長い間話すことができます-それはすべて退屈で、退屈で、面白くありません。 私は以前にやったことに定期的にぶつかり、自分の「自転車」を発明するためにどれだけ野生のエネルギーと忍耐があったかに驚かされることは決してありません。時にはそれらは美しく、理解の危機にworkedしていました。 長年にわたり、経験が積まれ、特定の知識が蓄積され、怠lazがますます進歩しています。 独自のゲームエンジンを構築しようとするさまざまな試みがありました（多かれ少なかれ進行中のHelloWorldsはこれを通過したと思います）。 GAPI （DX7 / 8/9 、後にOpenGL 1.1 / 2.1の下で試みがあった）、プログラミング言語（C ++、C＃）の間のスロー 。 ただし、これは通常、レンダリングとシーングラフの実装を超えるものではありませんでした-自発性は非常に信頼できない同盟国です。 時間が経つにつれて、オープンソースエンジンが試され、さまざまな成功を収めた独自の何かを書くという考えが深まりました。

エンジンの選択

そして偶然unity3dが現れました 。 その時までに私は非常に怠け者であり、C＃のみで何かを書くことに同意しました（Javaとは異なり、それを書くのは素晴らしいことです）。 統合オブジェクトの機能を拡張するためのコンポーネントアプローチのシステムに感銘を受けました。デザイナーの環境と開発者の環境を1つのボトルに簡単に統合することについて言うことはありません。 unity3dの主なものは、速度と、開発者の努力なしに複数のプラットフォームで作業できることです。 はい、小さな適応が必要ですが、他のエンジンでは一般的に暗いです。

チーム

この分野の戦士ではないので、プログラマーは、特に適切な品質で描画する方法がわからない場合、単独で多くのことを行うことはできません。 開発にふさわしい人材を見つけるための試みはたくさんありましたが、大半は参加を共有するための同意なしに（原則としてインディー開発者にはない）お金を必要としました。 そして、ここで私は非常に幸運でした。 おなじみの知り合いを通して、プログラマーを探していて見つけられなかったアーティストが突然現れました。 結果は協力プロセスについてのタンデムであり、その結果は以下に記載されます。

対象プラットフォーム

開発のm笑のテスト場としてAndroidが選ばれました：市場に参入するための小さな価格（現在はgoogleプレイ）、低い参入しきい値、および現在の腺のモバイル市場。

プロジェクト

またはPROEKT、それが何であったか、まだ残っています。 私は、開発のための一時的な計画がなく、役割が原則的に制限されておらず、すべてが毎日ではなく夕方の残りの時間にランダムに行われたことをすぐに言わなければなりません。 怖いように聞こえますが、チーム内の少数の人々、Skypeを介したアクションの迅速な調整、および通常の相互突合せのために機能し、機能します。 私たちは一緒に働いたことがないので、もっとシンプルなものを選ぶことにしました。 その選択は、子供たちのおとぎ話「ジンジャーブレッドマン」にかかっていました。 モバイル機器に関する児童書のキッチンを知らない人にとってはばかげているでしょうが、それは単純で興味深く、仕事上の関係を築くことができるように思えました。

シンプルなおとぎ話の本を作るのは退屈なので、すぐにインタラクティブにすることにしました：子供の仕事は画面上で指をなでることであり、本の仕事は子供に触れて楽しませるフィードバックを与えることでした。 実際、それはプロジェクトのすべての技術的要件でした。

私たちはそれぞれ自分の分野で一定の知識を持っていて、それがどのように、そしてどのように見えるかをすでに想像していました。 アーティストは2Dでしか描くことができませんでした（しかし、彼はそれをうまくやりました）、私たちは議論しませんでしたが、私は彼から得るデータを議論しました。 すべてのアートはもともとCorelDrawで作成され、Flashで部分的にアニメーション化されました（非線形アニメーションが必要な場合）。 出力では、アルファ付きのpngのスプライトの散乱と、アーティストによるとすべてがどのように見えるかを示すプレビュー画像が与えられました。 私はこれらすべてを収集し、復活させ、ユーザーとやり取りする必要がありました。

unity3dは、通常の2dのわずかなヒントのない本格的な3dエンジンであると言わなければなりません。 unity3dのコンポーネント市場（はい、あります）には、スプライトを実装するための4つの主要なシステムがあります。 それらはすべてお金がかかりますが、前に言ったように、私は購入するよりも私のほうがいいでしょう、ある種の挑戦があるでしょう。 すべてのスプライトシステムは単純に実装されます。2つの軸が画面の平面を定義し、3番目の軸がスプライトレイヤーの深度になります。 スプライトは、テクスチャが重畳されたカメラに垂直な平面です。

簡単に聞こえますが、実際には、モバイルデバイスの非常に弱いハードウェアという1つの機能を考慮する必要があります。 drawcall（以下dcと呼びます）（またはdrawindexedprimitives / drawelements、これはすべてレンダリングプロセス中に内部的に変換される）のようなものがあります-各オブジェクトはグラフィックAPIへの個別の呼び出しによって描画されます。 すべてが単純ですが、問題は、デスクトップ上でそのようなレンダリングの数が1000に達し、比較的最新のハードウェアが停止しない場合、モバイルデバイスの場合、この値は20以内に維持する必要があるということです。 ありがたいことに、Unityには自動バッチ処理システムがあります（バッチ-同じ種類のデータで1つの操作を実行し、実際にSIMDのデータを準備します）-unity3dは、材料に応じてジオメトリを個別にソートし（テクスチャブロックの切り替え回数が減少します）、ジオメトリを大きな累積頂点バッファに結合します。その後、それらは材料ごとに一度に描画されます。 その結果、コーンなどのテクスチャが1つあり、このスプライトを伝播する場合、unity3dはこれらすべてのスプライトを1つのDCで最適化します。

2番目の最適化方法は、 テクスチャアトラスの作成です。マテリアルが少ないほど、テクスチャスイッチが少なくなり、DCが少なくなります。 私たちにはたくさんのアートがあり、絶えず変化していました-テクスチャアトラスを生成するユーティリティが書かれており、これはシェル自体の拡張としてunity3dエディター内で行われました。 すべてのアートはシーンに分類され、いくつかのシーンの共通日は別のアトラスに配置されました。 これで、アートを変更するときに、将来のアトラスのコンテンツ（アニメーションのすべてのフェーズを含むすべてのスプライト）を含むフォルダーにユーティリティを設定するだけで、出力でこのテクスチャー内のスプライトの配置を説明する単一のテクスチャ+ファイル（フレーム名、画像内のゾーン座標、アニメーション速度）を取得しました、アニメーションの種類-リニア/フリップフロップなど）。

レンダリング自体は単純でした。すべてのジオメトリは手続き型であり、アニメーションフレームが変更されたときに再生成されました（頂点とテクスチャ座標）。 これらすべてのトリックの結果、本の一部のシーンは4〜5月12日に描かれ、パフォーマンスに影響を与えず（タブレットだけでなくスマートフォンでもうまく機能します）、見栄えがよくなります。

これがすべて開発されている間に、2つの不快な機能が発見されました。

1. 滑らかなグラデーションを使用すると、アーティストの手に勝ちます-DX1 / 5などのハードウェアでサポートされた圧縮形式ではひどいように見えます。 この場合、すべてのテクスチャを本格的な32ビットテクスチャアトラス1k x 1kに変換する必要がありました-RAMとファイルレートにどのように影響するか想像できます。
2. スプライトをスケーリングする場合は、Vector3.one以外のスケールでは自動バッチ処理が機能しないことに注意してください。 これは最適化にとって非常に重要です。サイズが異なり、軸に沿ってミラーリングされるオブジェクトが多数ありました。それらのオブジェクトでは、ジオメトリで追加のベイク処理を行い、スケールを1にリセットする必要がありました。 ダイナミクスの場合、これはコードの重大な複雑さのために機能しませんでした-我慢し、最小限に使用する必要がありました。

さまざまなデバイス

Androidデバイスの動物園全体は私を怖がらせませんでした。 当初、ピクセル精度のおもちゃの実践は、開発者/アーティストにとって悪質で致命的なものとして採用されました-さまざまなdpiおよびアスペクト比のいくつかのグラフィックパッケージを準備する能力はありません。 すべてが1つの標準サイズ（1024x600、横向き）専用に開発されました。 これらのサイズに収まらないものはすべて、自動的にunity3d仮想カメラにスケーリングされ、600仮想ユニットの高さになりました。幅もプロポーションを維持し、ほとんどの場合実際の画面サイズよりも大きく、エッジで切り取られました（私たちに合った-重要なオブジェクトをエッジから遠ざけました） ） 実際には、「Experia P」でアプリケーションをテストできるようになったため、十分な幅の1024ピクセルがなく、端にストライプがありました。 すべての人に適したオプションとして、背景を少し幅を広げることが決定されました（係数1.05）-これは目には見えず、長すぎるスクリーン上のストライプを除去します。

得点

得点はすぐにプロのアナウンサーに命じられた-すべては議論なしで行った。 私はお金（唯一の費用）を費やさなければなりませんでしたが、出力で良い結果を得るには、すぐに少しのドピリバニュでリリースに行き、ソフトウェアの大部分はすでに準備され、テストされました。

出版の準備

すべての開発とテストはunity3d +ビルドで行われ、webplayer用に作成されました。 Android用にビルドするには、必要なプラットフォームがインストールされたAndroid SDKとAndroid用のunity3dライセンスの2つのものが必要です。 Unity3dではAndroidのさまざまなバージョン向けにビルドできます。SDカードに転送できる可能性があるため、2.2がメインバージョンとして選択されました。 出版ライセンスは、プロジェクトから収入を得ていないため、インディーデベロッパーにとって問題になりますが、数か月前に行われた前例のない寛大さのおかげで、私は無料でライセンスの所有者になりました。

転記

出版物にこのような問題があるとは思っていませんでした-彼らが書いているすべての記事で、すべてが迅速かつ無痛で起こると書いています。 実際、Googleには複数のサーバーがあり、その間のデータの同期は非常に遅いです。 つまり アプリケーションデータを編集し、新しいapkを入力して、説明ページで古いテキスト/古い分布を確認し、アプリケーションカテゴリページに移動します-他のものを確認します（複数回編集された場合）。 このAllはすべて約1時間半で1つの形になります。

広告

私たちは原則としてこれをしませんでした-私はいくつかのリソースのためにミニレビュー（実際には、広告の発表）を書いて、これについて落ち着きました。 子ども向けの本、さらにはAndroid、さらにはロシア語の本でさえ、あまり人気のある商品ではないため、大きな利益を待つのは愚かです。 また、人々は原則として支払うことを好みませんし、無料版のアプリケーションのコメントを台無しにして、アプリケーションの評価にマイナスの影響を与える些細な欠陥を見つけることも好きです。 平均価格で有料版のみを作成するという強い意思がありました。 ボードは、トロルから私たちを守る一種の入り口になりました。 これには魔法の効果がありました。4日間で5ポイントと4ポイントで4件のレビューを収集しました。これにより、カテゴリで13位、新しい有料アプリケーションの総合トップで17位になりました。 そして、これは現時点で56部のコピーと5つのコメントで販売されています！ 彼らがどのように評価を検討しているか理解していませんが、私たちはトップにいます。これは喜ばしいことです。

支払いを望まず、PRリソースに怒りを燃やし、破壊して盗むという脅威はありましたが、評価を台無しにしませんでした。

まとめ

ゲーム開発者になるべきですか？ 誰もが自分で決める。 いくつかのプロジェクトで大きな利益を得る方法は絶対にありませんが、絶え間ない仕事と継続的な生産であなたは抜け出すことができます（これらだけがインディーチームではありません）。 さまざまな分野で優れた理論的および実践的なトレーニングを受けていないチームが長続きしないことを確認してください-各参加者は独自の何かを与え、成功するモノリシックソリューションの一部になる必要があります。



Z.Y. ひどい言葉を書かないようにしようとしたので、もしそうなら、それは大多数に明らかでした。