NaNのTragicomedy行為：JSでゲームを作成し、Steamでリリースした方法

「エカは目に見えません」とあなたは言います、「あなたのゲームはトップ100にないので、安全ではありません。」 同じことが当てはまります。 しかし、Protolife開発の1年間で、将来の潜在的なigrodelovと共有できる経験を積んでいます。 業界のベテランは、自分には何も面白いことはないと思う。 しかし、少なくとも心から楽しんでください。

それはどんなゲームですか？ そして、私たちは誰ですか？

私たちは3人（ GRaAL 、 A333 、 icxon ）のチームであり、Volcanic Giraffeと呼ばれる運命の意志により、何の意図もありません。 私たちは長い間一緒に仕事をし、3人はLudum Dare （週末のゲームライティングコンペティション）に参加し、Protolifeと呼ばれる工芸品の1つをリリースすることを決めました。



要するに、これは珍しいタワーディフェンスであり、ヒーローカーソルを動かして、絶えず成長している赤いバイオマスに対するブロックのディフェンスを構築する必要があります。

ドラフト記事のコメントから：

icxon ：最初にゲームプレイについて少し書く必要があります。 そして、西洋ワサビが何が起こっているかを理解するスクリーンショット

より詳細にペイントする場合、ゲームの内容は次のとおりです。

1. 一連のレベルがあり、各レベルにはベースとアバター（ロボットビルダー）があります。
2. レベルの一部は、それ自体から大量のMobを吐き出す赤い成長しているバイオマスで満たされています。
3. もちろん、Mobはベースまで走り、それを粉砕しようとします。 そして、私たちは塔から防御を構築していますが、それを実行させていません。

「しかし、ここでそんなに珍しいことは何ですか？」とあなたは尋ねます。 そして、ほとんどのタワーディフェンスとの主な違いは次のとおりです。

1. 建設ロボットをキーから直接制御します。 レベルについて手動で急いで、すべてを構築/修復する時間が必要です。
2. ロボットにできることは、青いブロックを組み立てて解体することだけです。 そのようなブロックの1つは何の役にも立ちませんが、特定のパターンに従ってレイアウトされたいくつかのブロックは有用な構造に変わります。 テンプレートの例：
   
   

• パターン1：シンプルな銃
• パターン2：壁
• テンプレート3：AAガン。 ここでは黄色の結晶も使用する必要があります
• テンプレート4：機関銃

そして、ゲームは次のようになります。実行、構築、答えの取得、迅速な修復。 ゲーム開発プロセスを直接視覚化できます。







しかし、そのようなゲームはすぐにはうまくいきませんでした。 2017年4月に戻ったLudum Dare 38では、次のようになりました。







スケジュールの違いに注意を払わなければ、それほど変わっていないようです。 すでにLDバージョンには、カーソルビルダー、ブロックからの塔の建設、赤いバイオマスとの対立がありました。 これが機能し、人々が気に入ったため、これを残しました。



しかし、実際には、1平方ピクセルあたりのグラフォニウムの濃度以外にも多くの変化がありました。 1年の道のりで、ゲームプレイ、技術、組織、マーケティングなど、さまざまな決定を下す必要がありました。 成功したものとそうでないものがありました。



そのような決定についてお話したいと思います。



すぐに予約します-おそらくいくつかの記事があるでしょう。 掘り始めるとたくさんの材料が出てきます。 この記事の最後に、簡単な調査があります-どのトピックがあなたにとって最も興味深いでしょうか。 まあ、ゲーム自体へのリンクも。

創造の退屈な物語。

このゲームがどのように考えられているかに興味を持っている人はいないと思うので、ネタバレの下で削除します。

完全な実装のためのゲームの選択

よくあることですが、3人全員で考えたことがありますが、本格的なゲームを作成するときです。 多くの場合、この段階では、ある種の概念が「夢のゲーム」のように頭から取られ、作業が行われています。 そして、観客の希望を推測するのはどれほど幸運か。



Ludum Dareに小さな「ポートフォリオ」が存在するため、タスクは少し簡素化されました。 人々が異なるゲームにどのように反応するかを見て、比較することができました。 Protolifeは最大の反応を示し、独創性と興味深いゲームプレイで賞賛されました-これはグラフィックスのレベルがゼロで、4レベルしかありません！



さらに、itch.ioは、私たちのクラフトを公開する決定を下すのに役立ちました。 結局のところ、ウェブゲームをプレイするためにitch.ioにアクセスする人がいます。 タワーディフェンスのジャンルが好きな人もいれば、5〜10人が入ってくる（そしてまだ入ってくる！）その古いプロトライフを毎日プレイするために。





^{Steamでのゲームのリリース前の呼び出しの統計}



これは私たちの最初のマーケティング調査だったと言えます。 私たちは、「非標準のタワーディフェンス」が発動できると考え、決定しました。 タワーの防御はそれほど多くありませんが、その多くは2滴の水に似ており、その中でも際立っています。



将来を見ると、戦術は報われたと言えます。



求められていないヒント＃1：盲目的に行動しないでください。 あなたの頭の中の理想的な「夢のゲーム」は誰も必要としないかもしれません。 あらゆる種類のジャムに参加しない場合は、ゲームプレイ（！）プロトタイプをスケッチして自分自身、友人、知人でテストすることは常に意味があります。



カウンター評議会：半数の人々が「夢のゲーム」をプレイすることを恐れていない場合、誰が気にしますか？ やれ！ たぶん幸運です。

エンジン：最良のソリューションではない

Phaser.jsエンジンのLudum Dareでバージョンを作成しました。 私たちはそれをよく知っていて、javascriptをよく知っています。ウェブゲームはより多くのフィードバックを得ます。それは非常に便利で習得しやすいです。おとぎ話であり、エンジンではありません。



そして、私たちは重要な質問に直面しました：エンジンを変更するか、すべてをそのままにするか？



質問は複雑でした。 当時、私たちは誰も他のエンジンを知りませんでした。 勉強に時間を費やすことは良いことですが、すべての熱意を失う可能性がありました。 それから-何をする？ Javascript-C ++ / Java / C＃エンジンを使用するために私たちが知っている唯一の言語-は、開発者の半分を即座に失うことを意味します。 また、当時のUnityレベルのエンジンは、「シンプルな2Dゲーム」には扱いにくいと思われました。



そして、すでにゲームがあります。 グラフェンを更新し、レベルを完了するために残っている-それだけです。 数か月間働きます。 そして、勉強し、書き直します...



一般的に、Phaser.jsにとどまることにしました。 さらに悪いことに、同じコードベースにとどまることにしました。 Ludum Dareプロトタイプの上にゲームを構築します。

ドラフト記事のコメントから

a333 ：申し訳ありませんが、エッフェル塔の代わりに松葉杖でその写真を持っていませんでした」

未承諾のヒント＃2：絶対にやらない！ これは、プロトタイプの再利用の場合に特に当てはまります。 ジャムのコードは、将来の開発を考慮せずに、常に迅速かつダーティに記述されます。 松葉杖があり、松葉杖があります。今、あなたはあなたがすぐにレガシーコードを書いていることを理解し、すぐにそれに苦しみ始めます。 プロトタイプを注意深く読んでから、/ dev / nullに焼き付けて書き直し、すでに完全でクリーンな状態にしなければなりません。



反対評議会：しかし、心理学の特性を考慮に入れてください。 数週間の遅延で「クールダウン」するのに十分です。 まったく実行しないよりも、貧弱なアーキテクチャでゲームを作成する方が適切です。

ドラフト記事のコメントから：

A333 ：私はこのオプションに非常に興味があります。 私の知る限り、時間とヒューズが重要な役割を果たすため、これがほとんどのゲームのやり方です。 新しいエンジンですべてをきれいに書き換える機会があれば-でも、これはいつもそうとは限りません。 速くて汚いものを書き、初期のプロトタイプを展開し、コードの一部をコピーして貼り付け、zabagoをリリースすることを恐れないでください。

実際、Phaser.jsの問題は何ですか？

• ご想像のとおり、このエンジンはWebベースです。 SteamでWebゲームをリリースする方法を知っていますか？ そうです、nw.jsまたはElectronを使用してChromeとともに提供します。 このアプローチの欠点を説明する必要はないと思います。
  
  
• javascriptのパフォーマンスは確かに非常に優れていますが、ネイティブコードはより高速に実行され、一致するものを節約できます。
  
  
• 非常に弱いレンダリングコントロール。 Phaser自体がすべてをレンダリングし、全体的に非常にうまく機能しますが、プロセスに参加したり、webGLで何かをしたい場合があります。 残念ながら、Phaserで許可されるのは、フラグメントシェーダーを画面全体に適用するか、画面上の個別のスプライトに適用することと、適度に適用することだけです。 頂点シェーダーを使用することはまったく許可されておらず（また、実際に頂点を使用することもできません）、ゲームでの多くの決定がはるかに簡単になります。
  
  
• 画面上の多数のスプライト（アクティブオブジェクト）の問題。 さらに、「多数」は数百万ではなく数千です。 そして、「アクティブなオブジェクト」は、アニメーションのない嘘の石にさえなります。 ティックごとに、Phaserはすべてのオブジェクトを通過し、独自の特別なフェイザーマジックを実行して、ゲームロジックから時間を消去します。
  
  

途中でこれらの問題の多くを解決しましたが、最後まで解決しなかったものもありました。 他のエンジンでの経験なしに判断することは困難ですが、他のエンジンは何千ものゲームオブジェクトを地獄のようなトリックなしで処理できるように思えます。 しかし、私は間違っている可能性があります。

スタイルの戦争

ゲームのオリジナルバージョンの「オリジナルデザイン」をまだ覚えていますか？









もちろん、それは独自の魅力を持っていますが、深刻な製品には適していませんでした。 はい、そして私たちのアーティストは出張から戻ったばかりで、彼は怠idleに座っていましたか？



彼は座りませんでした、可能なデザインのいくつかのスケッチを作りました。 歴史は2つのスタイルの椅子を保存しており、その間に1つは選択をしなければなりませんでした。



候補1：ミニマルなデザイン。 実際には-同じ「ピクセル」、より同情的です。 すべてが明るく対照的です。 それはまともに見えますが、たとえば、しっかりしています。 このようなゲームは、携帯電話やVKontakteでテトリスとアルカノイドの間のどこかでよく見えるという意味で。 しかし、迅速かつ安価に。









候補2：現実的、幻想的、過酷。 ここでは、特定のストーリー、コンテキストをすでに見ることができます。 予想外に、コントラストは色だけでなく形でも機能します-私たちの建物はより秩序があり、正方形で、敵の建物-丸く、不規則な形です。







これは、私たちが非常に長い間heしたことを意味するものではありません。 どの「スクリーンショット」をもっとプレイしたいかを想像しましたが、最初の候補者は単に生き残るチャンスがありませんでした。 プロットのために何が得られるのか、何が起こっているのか、何が起こっているのか、私たちには分かりませんでしたが、オプション2を選択しました。



もちろん、比較するものは何もありませんが、これは良い選択肢だったようです。 はい、最初のオプションをより早く完了し、パフォーマンスとグラフィックスへの要求が少なくなり、おそらく携帯電話に移植することさえ可能になったでしょう。



しかし、2番目のオプションをプレイしたかったのです。



そのため、微生物とペトリ皿は、遠い惑星、ロボット、そして神秘的な外来生物に置き換えられました。



未承諾の陳腐なアドバイス3：自分がやりたいことをやりましょう。



カウンターアドバイス：住宅ローンが3つあり、他に仕事がない場合、売れ行きの良いことをしていることを誰も責めることはありませんが、目と手を石鹸で洗う必要があります。

身をかがめるバイオマス、潜んでいるワーム

色と形のコントラストについて言及しましたが、そのスケッチと最終バージョンを比較すると、コントラストが強まるだけです。 比較-建物の正方形、敵の丸い建物、赤い塊の全体的な丸さ。









ちなみに、ゲーム内のほとんどすべてのものと同様に、ゲームロジック内のどこかにある赤いマスは、ブロックと同じようにグリッドに収まります。 しかし、彼女は同時に混fromとしており、まるで自分がネットから解けたように見えます。



バイオマスの外観をデバッグしたデモがまだあります。 そこですべてが次のように配置されます。条件付きの「正方形」が取られ、異なるサイズの円で可能な限り密に満たされます。 以下はそのような詰め物の例です。 ゲーム自体では、塗りつぶしの密度が高くなります（したがって、読みにくくなります）。







円の間には線があります-接続。 バイオマスがいくつかの細胞に成長する必要がある場合、必要な細胞と交差する適切な円が選択され、線に沿って成長が発生します。









動きの様子は次のとおりです。

ドラフト記事のコメントから：

icxon ：このデモを初めて見たときは笑

ゲーム自体では、すべてが同じように機能しますが、サイズ、色、速度はすべて、見た目が良くなるようにアーティストによって調整されています。









ああ、私はまさにそのような決定がどこから来たのか、議論の段階がどうなったのか、候補者が流されたのかを伝えるのを忘れていたようです...



しかし、いや、私は忘れていません。 ありませんでした。 最初は、LDバージョンのようにすべてを行う予定でした。 正方形による成長。 ある夜、私は退屈し、このデモをスケッチして練習しました。 そして、みんなが行った。 彼らはそうしました。



求められていないヒント＃4：計画、計画、しかし新しいことに挑戦することを恐れないでください。 直感はあなたにいくつかの良い決定を伝えることができます。



カウンターアドバイス：リリース日を既に設定し、パブリッシャーと契約を結んでいる場合-おそらく実験しないでください。

バイオマスアニメーション

上のgifで、バイオマスのアイドルアニメーションに気付くことができます-静止しているときでさえ、それは激しく「呼吸」し、赤い芽が開いたり閉じたりしているように見えます。 理想的な世界では、これらは円で同じパターンに配置されたアニメーションでアーティストによって慎重に描かれたスプライトです。 現実には、これらはPhaser.jsで処理できない数千のゲームオブジェクトになります。 これはすでに実証済みの事実です。LudumDareのバージョンでは、バイオマスがマップの少なくとも半分を満たしたときに、すでに地獄のようなブレーキに遭遇しました。そこではアイドルアニメーションもありませんでした。



シェーダーが助けになり、GPU上でスピンし、プロセッサーを占有しません。 さらに良いことに、このシェーダーが本当にシンプルな場合、ビデオカードをあまりロードしません。



シェーダーは何とどのように描画するかを何らかの方法で伝える必要があります。 シェーダーに情報を転送する方法は何ですか：

• シェーダーコード自体のハードコード。 私たちの場合、それは適合しませんが、一般的にこのオプションは考慮に値する場合があります。
  
  
• 均一変数を介して（これらは画像内のどのピクセルでも同じ変数です）
  
  
• 可変変数（2つの頂点間で補間される変数）を介して
  
  
• テクスチャを通して（値を色でエンコードする）
  
  

方法3は有用かもしれませんが、Phaser.jsの場合は利用できません。 ユニフォームをあまり通過しません（たとえば、半径のあるすべての円の配列はユニフォームに適合しません-制限があります）。 テクスチャは残ります。



トリックは次のとおりです。最初に1つの状態（閉じた芽）を青で描画します。









次に、2番目の状態（開いた芽）は赤です。









それらを一緒に追加すると、紫色の混乱が発生します。









一方、シェーダーはテクスチャを確認し、現在の時刻を確認し、一定の期間で「青」状態、次に「赤」状態がスムーズに流れることを示します。 さて、それ自体で目的のカラーパレットを適用します。 次のようになります。

ドラフト記事のコメントから：

a333 ：ああ、これがこのb *** i f *** aの仕組みです

icxon ： 動作の仕組みがまだ分​​からないのでいい

同じですが、長方形の例があります：



テクスチャー：







最終アニメーション：







テクスチャは、成長/崩壊するときにのみ更新され、残りの時間はGPUのみのアニメーションが機能します。

プレイヤーのケア

開発プロセスでは、初めてゲームを見るプレイヤーを忘れないようにしました。 それは見た目ほど単純ではありません-しばらくすると目がぼやけてしまい、開発者として既に知っている明白なすべてを検討し始めます。



これを理解したので、最初のベータテストはリリースの8か月前にすでに実行されました。最初の10レベルとコンテンツの40〜50％が準備できた直後です。 このベータテストでは、優れたレベルのデザインフィードバックが得られました。次回フィードバックについて説明します。 同時に、私たちは自分自身がいくつかのポイントについて良い予測をしていることを学びました。



状況：保護する必要があるプレイヤーの基地があります-その破壊はミッションの失敗につながります。 プレイヤーは常に基地を監視していません-彼はロボットのアバターを見ています。 そして彼は常に監視しています-ゲームのペースは非常に速く、立ち上がって熟考する時間はあまりありません。 その結果、テスターである私たちは、背後にいる敵に気づかずに基地を爆撃することがありました。



解決策：最初に、地図の半分を通る同心円でベースの損傷を示します。









第二に、ベースが著しく損傷している場合、それは独立して反撃し、敵を一掃します。 これにより、問題に対するプレーヤーの注意が引き付けられ、アクションを実行する時間が与えられます。









状況：典型的なタワーディフェンスのように、敵はbeatられた道をたどります。 ただし、このルートは常に推測されるとは限りません。 そして、ルートを理解することは、防御を成功させるために非常に重要です。一部の塔は非常に近くで撃ち、あまりに近くの塔は次の波によって破壊されます。



解決策：敵を殺した後に採血します。 しばらくすると、明確なトレースが地面に表示され、焦点を合わせることができます。









質問：しかし、実際には、なぜbeatられたトラックですか？ A *を実装できませんか？



回答：何回も実装しました:)正直に敵のAIを試しました。 道路を探しているスマートワームと、弾丸を避けるスライムがありました。 プレイすることが不可能になりました。 プレーヤーは効果的な防御を構築できず、その仕組みを見て満足できませんでした。 ゲームの喜びは激減しました。 これは、「賢い」敵が悪いという意味ではありません。 選ばれたメカニックだけのために-私たちの建物が静止しているとき-そのような敵は適合しませんでした。 「スマートな敵」の場合、ロボットにマシンガンを装備するか、タワーに脚が必要です。 そして、これは完全に異なるゲームです-人々がLDとitchioで好きなものではありません。

ドラフト記事のコメントから：

icxon ：しかし、まだスライムがあります。 そして彼らはまだかわす

GRaAL ：ちょっとしたフィクションを考える

^{彼らは本当にありますが、元のバージョンよりもはるかに怠doに避けます}



状況：敵には長距離銃（迫撃砲）があり、プレイヤーの視界外にある可能性があります。 当初、ほとんどすべてのフィールドが戦争の霧の後ろに隠れていたため、敵の砲弾の到着は気付かれず、暗闇から飛び出し、すぐにダメージを与えました。 プレイヤーがその瞬間を反対方向に見ていると、何が起こったのか理解できないかもしれません。



解決策：飛行霧が戦争の霧の上に見えます。 これにより、プレイヤーは脅威に気づき、行動を起こすことができます。









シェルといえば。 gameplay-UXの問題から注意をそらしましょう。

衝突処理

移動オブジェクトのLDバージョンには、それほど多くはありませんでした-常に12個の弾丸と12個のワームがありました。 これはゲームでは十分ではありませんでした。 挑戦を感じるためには、対戦相手の数を増やす必要があり、同時にプレイヤーに対抗するための速射武器を与える必要がありました。 ゲームでは、この状況は珍しくありません：









すべてのゲームオブジェクトについて、衝突を考慮する必要があります。 弾丸はワームにクラッシュし、ワームはブロックにクラッシュし、それらはすべて画面上で-時には数百になります。 そして、銃は射程内でターゲットを選択する必要があります。 LDバージョンで、適切な敵を探してすべての敵を反復処理する余裕がある場合、ここですでに速度が低下し始めていました。



一般に、この問題には解決策がありますが、このテーマに関する記事をよく目にしました（ここにその1つがあります ）。 画面に論理グリッドがあり、ほとんどのアクティブオブジェクトのサイズが2x2ゲームセルを超えないため、このグリッドを使用して衝突を判断することにしました。



各セルには、そのセル内にあるオブジェクトのリストがあります。 全体として正確に1つのセルを占有し、どこにも移動しない静的オブジェクト（ブロックや石など）があります。 また、グリッドに沿って移動し、あるセルから別のセルに「流れる」動的なものもあります。









なぜなら オブジェクトは2つのセルの境界のどこかに配置できますが（中心は明らかに1つだけの中にあります）、衝突を考慮すると、すべての隣接セルが検査されます。 つまり 座標X、Yで弾丸を取り、セル（X、Y）、（X + 1、Y）、（X-1、Y）、（X、Y + 1）、（X、Y -1）。 弾丸が相互作用できるオブジェクトがある場合、それらのそれぞれについて、形状とサイズに基づいて正確に衝突が計算されます。



2回起きないように、同じグリッドを使用してタワーごとにターゲットを選択します。 作成後、タワーは特定のグリッドセルに「サブスクライブ」します。 射撃できるものがケージに入ると、タワーは通知を受け取ります（通常は射撃後）。 したがって、千人の敵が塔から明らかに遠く離れてcreepい出れば、塔は彼らまでの距離を数える時間を無駄にしません。









マップが大きい場合、グリッド内のセルも多くなり、すべての更新とチェックに時間がかかり始めます。 また、いくつかのセルのサイズの建物/ユニットがある場合、問題が発生します。それらの場合、周囲のセルをさらにチェックする必要があります。



これらの瞬間を平準化するために、16x16の大きなセルを細かいメッシュの上に置きます。 彼女にとってはすべてが同じであると考えられており、オブジェクトの周囲のいくつかのセルの半径に何もない場合や衝突をチェックできない場合に、状況をすばやく選別するために使用されます。

約束のリンクと調査

記事はすでに十分な長さであり、ノートブックのトピックのリストは4分の1減少しました。次の記事で知りたいことは何ですか？いくつかのポイントに投票できます。



さて、突然それがどのように行われたのか、それがなぜ行われたのかについての具体的な質問がある場合は、コメントに書いてください。思い出すと答えます:)



ゲームへのリンク：

• Protolife：itch.ioのLudum Dareのバージョン（無料）。
  
  
• Protolife：Steamのリリースバージョン（有料、すみません）。
  
  

ご清聴ありがとうございました。