ロシアA(AA)の物語-1つの例のindi gamedev





カットの下には、関心のある人々のグループが2年間でAAAレベルのインディープロジェクトを作成した方法(彼らの意見では)



ここで私は完全に時代遅れであり、腐った肉、かびの生えたチーズ、甘やかされた人々、そしてugい行為でゲーム愛好家を引き付ける腐敗に耐えられません。 私にとって、本、映画、絵画のいずれであっても、深く感じられた自然、美しい女性、勇敢な男性がいなければ、どんな芸術作品も存在しません...



I.エフレーモフ、カミソリの刃




参加する代わりに



友達と時間を過ごすときは何をしますか? ボードゲーム? スポーツ? フィルター付きの写真を一般的なフィードにアップロードする必要がある革新的なスタートアップを作成しますか? 私の友人と私はこれをすべて経験しました、私は誰も前にやったことのない、新しい、新鮮なものが欲しかったです(ハッサーのジョーク以外)。 ゲーム開発者は、誰もが望んでいたまったく新しいものであることがわかりました。



定期的にゲームをプレイしたのは1人だけで、彼はLegion TDと呼ばれるWarcraft 3の人気マップについて残りの人に話しました。 もちろん、DotAとの強力な類推は機能しました。ゲームはWarcraftのマップとしても始まりましたが、その後、独立した製品に変換され、非常に成功しました。 Legionでは、同様の状況が非常に人気のあるマップであり、ファンサイトとトーナメントがありますが、2003年に作成されたゲームのマップを今でもプレイしています。 独立したプレーは単に成功する運命にあるようです。



オリジナルゲームのゲームプレイを含むYouTubeビデオ。



その頃までに、私は急速に成長している会社で経験を積んでいました。そこでは現代のアジャイルプラクティスが積極的に適用され、私たちのプロジェクトにそれらを投影することを提案しました。 週の繰り返しでゲームに取り組み、週の初めに現在の繰り返しのタスクを設定し、最後にデモを実施することに同意しました。 デモとして、ゲームの形式を選択しました。ゲームをプレイし、反復中に追加された新しい機能を使用する必要があります。 したがって、私たちは常にゲームを動作状態に維持し、さらに自分の目で進歩を見ます。



そのため、2015年1月にゲームの開発を開始しました。



ゲームの仕組みについて少し



ゲームにはかなり珍しいジャンルがあります-マルチプレイヤータワーディフェンス。



競技場は、西部と東部の2つの部分で構成されています。 西側のチーム(最低1人のプレイヤー)は東側と対戦します。 それらの間にはアリーナがあります(詳細は後ほど):



画像

競技場



一方は4つのスロットで構成されています(つまり、最大4x4ゲームが可能です)。 各プレイヤーは自分のスロットに防御側ユニットを構築し、ゴール側からユニットを攻撃します(赤でマーク):



画像

ゲームサイドカード



ゲームはフェーズで構成され、構築フェーズから始まります。



画像

建設段階



構築フェーズが終了すると、波が表示され、ユニットが自動的に戦闘します(ここではプレイヤーは関与しません):



画像

波の位相



波の破裂ユニットは、キング(キングスロット)への最短ルートに進みます。 プレイヤー1が反撃できず(「漏出」)、プレイヤー2が敗北した場合、そのユニットは王にテレポートして保護します。



画像

波ユニットが入った王のスロット



特徴は、プレイヤーが防御ユニットを構築できるだけでなく、攻撃ユニットを敵に送信できることです。 そして、ここであなたは自分自身を守り、敵を攻撃するために資源のバランスをとらなければなりません。 これにより、多くの戦略が発生します(打たれた道を離れて遅波を待ち、リソースを蓄積し、敵を一度に破壊するなど)-このため、プレイヤーはプレイするギルドを選択します(ギルドはプレイヤーが購入できるクリーチャーのセットを決定します)



最初の期間



分割しました。2つはサーバーを引き継ぎ、2つはクライアントを引き継ぎました。 毎週ゲームをプレイする必要があるため、最小限の動作バージョンをできるだけ早く組み立てる必要がありました。 私たちはPythonでサーバーを書き始め、その上でプリミティブなコンソールクライアントを作りました:



画像

最初のゲームクライアント。 ゲームの世界の状態は、上記の辞書の形で表示され、以下は構築されたユニット(文字Q)です。





このコンソールクライアントでサーバーの最初の機能をテストしましたが、すぐに通常のグラフィカルクライアントに集中する必要があるという結論に至りました。 Unityで構築し、モデルにはUnity Asset Storeの無料アセットを使用しました。



画像

Unityのグラフィカルゲームクライアントの最初のバージョン



そのようなクライアントは、はるかに細かいグリッドでユニットを構築し、さまざまな状態(攻撃、歩行)を観察し、それらが正しく移動するかどうかを確認することを既に許可していました。



最後に、Habréのコメントで、インターフェイスデザイナーに会いました。インターフェイスデザイナーはプロジェクトに興味があり、ゲームインターフェイスのデザインを実践することにしました。



それで、開発の最初の数ヶ月が過ぎました。



第二期



デザイナーは有名になり、すぐに新しいインターフェイス(「ダッシュボード」、後で呼ばれる)を描きました。



画像

ゲームインターフェースの2番目のバージョン



私たちは、このようなインターフェイスで、ギャグせずにゲームをテストするのに十分であると判断し、ゲームクリーチャーの外観を調査し始めました。 私たちの誰もゲームグラフィックスのデザインの経験がなかったので、スケッチから始めました。 ここでは、デザイナーだけでなく、友人、知人、そして一般的に国内のインディーズgamedevに参加したいすべての人も参加しました。



画像 画像 画像

最初のキャラクタースケッチ:鎧のゴブリン、オーク、ゴブリンのメカニック。



Warfactoryと呼ばれる最初のギルドのスケッチを記録し、クリーチャーモデルを取得する方法について考え始めました。 その時までに、私たちはすでに狭いサークルで広く知られており、プロジェクトに参加することに興味を持っていたウクライナの3DモデラーであるOlegから連絡がありました。 彼は最初のモデルの作成も始め、6人がチームに加わりました。



image22 image11 image04

独自の最初の3Dユニットの1つはプレートです。 それはまだゲームで私のお気に入りのユニットの一つです。



画像15 image25 image21

オークブルーザープロセス



独自のグラフィックス、ユニット、マップの開発に積極的に取り組み始めました。 Unity Asset Storeの無料モデルはそれほど高品質ではなかったため、数か月で独自のグラフィックを作成できると判断しました。



画像

その当時のゲームのスクリーンショット。 ゲームにはすでに独自のインターフェイスが追加されており、左側にはまさに「プレート」があります。



スクリーンショットは、最も気取らない(他のすべてに加えて)長方形の灰色の壁を持つ平らな緑のカードであることを示しています。 私たちは、レベル設計と美しい地図の作成に時間を割くことに決めました。



image00 画像27 画像23 image05 image02 image08

マップオブジェクトの作業のいくつかの要素



マップの作業を進めたところ、問題は人的資源の不足であるという結論に達しました。 テーマグループに叫び、チームに参加することに興味を持っている人、テクスチャデザイナー、モデラー、アニメーターをすぐに見つけました。 このように、チームは6人から12人に成長しましたが、一度にいくつかの領域で作業を開始しました。 同時に、いくつかのユニットがスケッチされ、マップと新しいギルド(Order of Dragon)が設計されました。



第三期



これは、プロジェクトで最もアクティブな作業の期間です。 週に一度チーム全体を呼び出し、サーバー、クライアント、スケッチ、モデル、テクスチャにタスクのブロックを割り当て、先週の結果をノックダウンし、会議の最後にゲームをプレイしました。 徐々に、私たち自身のグラフィックスがクライアントに現れ、これがさらに動機付けられました。



また、最初のインターフェイスは何の役にも立たないことに同意し、インターフェイスの2番目のバージョンを作成しました。



画像

マップとゲームモデルの開発に積極的に取り組んでいたときのゲームの外観



長い間引きずられていた地図での作業、元々は2か月という名前の期間はほぼ1年の作業でした。 その結果、私たちは他のすべての作業を中止し、マップを最終状態に仕上げることを強く意思決定しました。



画像

しばらくの間最終状態と考えていたカードの外観



画像

ゲーム側の外観(エディターからの表示)



2016年の春に、約束のクローズドベータテストを開始し、最初のプレーヤーを招待しました(合計ではほとんど確認されませんでした)。 クローズドベータ版のために準備したビデオは次のとおりです。





最初のクローズドベータテストのために私たちが準備したビデオ。



第4期



目に見える結果のない長く単調な仕事は疲れる。 2016年の夏頃、生産性が低下し、チームが疲れていて明確な目標が必要であることが明らかになりました。 そのような目標として、Greenlightの立ち上げを選択して、コミュニティにゲームを見せ、ベータテストを実行してもらうようにしました。 当初、11月にGreenlightを開始する予定でしたが、グラフィックス、プロモーションビデオ、小さな修正の準備が非常に遅れたため、今だけ緑色のライトに行きます。



Greenlightについては、マップの視覚コンポーネントをさらに改良し、2つのギルド(WarfactoryとOrder of Dragon)を完全に完成させ、特別なビデオも用意しました(Greenlightのページでもご覧いただけます)。





Greenlightの立ち上げのために特別に準備したビデオ



ゲームの最新のスクリーンショットを見て、現在の外観を印象付けることをお勧めします(特に元の外観と比較して)。



画像10 画像19 image29 画像18

ゲームの新鮮なスクリーンショット



ツールについて少し



当初から、スクラムを順守し、すべての基本的な手順に従いました。バックログを作成し、反復計画を実行し、反復の最後に、デモと回顧展を作成しました。



私たちはTrelloを役員として採用しましたが、しばらくの間、幸福は際限がありませんでした。 しかし、チームの成長に伴い、チームのすべてのメンバーがチケットを最新の状態に保つ準備ができているわけではなく、「作業中」および「準備完了」のタスクを上回ることが判明しました。 しばらくの間、私は彼らのためにそれをしようとしましたが、それはひどく非効率的であるように見えました。



まず、Trelloの代わりに、チームフォーラムを試しました。 毎週反復計画が発行され、その週の終わりに、どのタスクが実行され、どの遅延が発生したかを確認しました。 このスキームはTrelloよりも単純であり、保守がはるかに簡単ですが、誰が彼のタスクの実行を遅らせているか、会議を欠席しているかを追跡することは困難です。



3つ目のツールは、Googleドキュメントの表です



画像

6月から11月までの期間のテーブルのスクリーンショット



このようなテーブルにより、完了したタスクと失敗したタスク(黒でマーク)を追跡できます。 黄色のタスクは遅れてマークされました。 テーブル列のカラーマーキング-開発のさまざまな方向(サーバー、クライアント、UI、グラフィックス)。 テーブルをざっと見るだけで、どの方向が横滑りしているのか、どのチームが締め切りに間に合わないのか、反対に誰が責任を持ってアプローチするのかを知ることができます。 このフォーマットが最も成功しました。 ケーキのチェリーとして-ファイルの履歴がエラーを追跡し、誰が「ポイントを勝ち取ったか」を自分自身で見つけるために変更されます(複数のチームメンバーがテーブルの編集にアクセスできます)。



おわりに



私の話では、多くの興味深い点が省略されています。ネットワークインタラクションとどのように戦い、最終的にどのように実装したかです。 サーバーのパフォーマンスを求めて戦い、PythonからGoに完全に書き直した方法、クライアントを最適化してグラフィック効果を追加した方法。 これについては、今後の記事で説明できます。 それまでの間、ベータ版に登録してフィードバックを残し、Greenlightページで投票してください!



All Articles