ノーコードゲーム開発:パーティゲームが1年で完成

ゲーム開発経験のない3人の友人が、コードの代わりにビジュアルスクリプティングを使用して、1年未満でマルチプレイヤーパーティゲームをリリースしました。彼らは、ゲーム開発への最大の障壁は技術スキルではなく、スコープクリープであることを実証しています。

3人の友人が1年でパーティゲームを開発・公開—コード一行も書かずに — theAIcatchup

Key Takeaways

  • Unreal Blueprintsのようなビジュアルスクリプティングツールは非プログラマーが実際のゲームをリリースできるようにしますが、プログラマーのように考える必要があります。
  • 容赦のないスコープ管理と非コア業務(3Dアセット、アニメーション)の外部委託は、技術的力量よりもインディプロジェクト完

「何もわからない状態」から「ゲームがSteamでリリースされた」までの間に、3人の開発者はインディゲームコミュニティが聞くべき事実を証明しました。ビデオゲームを作るのにプログラマーである必要はないということです。必要なのは審美眼、焦点、そして自分の創作物を切り捨てる規律だけです。

1年前、この3人の友人は、一緒に何か作りたいという漠然とした考えだけを持って席に着きました。彼らはコードを書けるのか分かりませんでした。どのエンジンを使うべきか分かりませんでした。どのジャンルを作りたいのかさえ分かりませんでした。彼らが持っていたのは、それを系統立てて解決しようとする意思だけです。

非プログラマーの3人が実際にゲームをリリースした方法

最初の決定は、当時の彼らが気付いていた以上に重要でした。彼らはパーティゲーム市場を調べ、隙間を見つけ(驚くほど質の高いパーティゲームが少ないニッチでした)、その分野にコミットすることにしました。その後、Unreal EngineとそのビジュアルスクリプティングツールであるBlueprintsを選びました—本質的には、テキストを入力する代わりにロジックを描画するものです。

なぜUnreal Engineなのか?彼らは選択肢を評価しました。Godotはその時点では未熟すぎました。Unityはちょうど物議を醸す実行時手数料モデルを発表していたため、彼らは敬遠しました。UnrealのBlueprintsシステムは、C++を学ぶことなく実際のゲームロジックを構築できることを意味していました。それはタイムラインに数ヶ月を追加していたはずです。

「Blueprintsはオブジェクト指向言語を使用した視覚的なコーディングですが、私たちの生活が楽になり、C++を学ぶ必要がありませんでした。」

彼らは25種類の異なるミニゲームコンセプトを試しました。15個をリリースしました。選別プロセスは容赦ないものでした—すべてのアイデアが良かったわけではなく、すべての良いアイデアがタイムラインと彼らのスキルレベルに合致したわけではありませんでした。

本当の教訓(そしてほとんどのインディプロジェクトが失敗する理由)

このストーリーが興味深くなるのは成功の部分ではありません。彼らがほぼつまずきかけた方法の図書館です。

Unreal Engineは獣です。これほど機能が豊富で、これほど有能で、可能性に満ちているため、アマチュアにとって積極的に危険です。これら3人の開発者は、リリースにたどり着くことのない詳細の調整や、最終的に削除したシステムの構築に何日も無駄にしたことを認めています。それが強力なツールの隠れたコスト—あなたが持っていない問題を解決するようにあなたを誘い込みます。

マルチプレイヤー同期の問題は現実でした。8プレイヤーのネットワークは簡単ではありません。彼らはトレードオフを行い、必要に応じて野心を縮小し、機能するものを手に入れました。それは専門家らしいやり方です。

しかし、彼らを失敗したインディプロジェクトの墓地から区別するのはこの部分です。彼らは自分たちの中核的な能力ではなかったことを外部委託しました。彼らの誰も3Dモデリングができませんでした。だからマーケットプレイスからアセットを購入しました。アニメーションを購入しました。彼らはアーティストになろうとしませんでした。彼らは彼らが構築していたものに焦点を当てていました—ゲームデザイン、ロジック、フローです。

これが重要な理由(そしてそれが何でないのか)

ゲーム開発で静かな革命が起きており、それは最も太い予算を持つスタジオによって主導されていません。C++を学ぶのに6ヶ月を費やすことを拒否する人々によって主導されています。楽しいものを作ることができた時に。

UE5のBlueprintsシステム(およびそれに類似したツール—GodotのビジュアルスクリプティングやConstruct、FlowCanvas)は、参入障壁を大幅に低下させました。しかし、障壁を低くすることは、障壁を取り除くことと同じではありません。この3人の開発者は、依然としてゲームデザインを理解する必要がありました。彼らはリリースする必要がありました。彼らはGitリポジトリ地獄に対処する必要がありました(彼らはUnrealでGitを使うのは拷問だったことを認めており、代わりにPerforceを推奨しています)。彼らは著作権ライセンスを尊重し、モチベーションが低下したときにコミュニケーションを維持する必要がありました。

彼らが行わなかったこと:C++構文を学ぶこと。メモリ管理を学ぶこと。午前2時にポインタ演算をデバッグすること。

それはとても重要です。

トンネルビジョンの問題(そしてそれを回避する方法)

これらがプログラマーではないと言ったことを覚えていますか?彼らはまた副業でこれをやっていました。3人全員に日中の仕事がありました。その制約—その美しく、残酷な制約—は、ベンチャーキャピタルで資金を得たスタジオが通常持つ方法では、彼らを規律を持つように強制しました。

彼らはDiscordを非同期通信に使用しました。彼らはタスクを小さなチャンクに分割しました。誰かが暗くなり、チームが同意しなかった完成した機能で戻ってきたとき、彼らは壊れた仕事をリリースする代わりに進路修正しました。彼らは虚栄心メトリクスの代わりに、述べられたロードマップに対して進捗を測定しました。

最大のインディゲーム墓地は、完璧なテックスタックと恐ろしいプロジェクト管理を持つプロジェクトでいっぱいです。

これが実際に教えてくれること

誇大広告を取り除くと、2つのことが目立ちます。

最初に:ツール選択はあなたが思うほど重要ではありませんが、実行はあなたが思うよりも重要です。 これらの開発者はUnreal Engineを選びました。これはパーティゲームにとって客観的にやり過ぎです。よりシンプルなエンジンで十分だったかもしれません。しかし、彼らは市場を知っていました。彼らは何を構築したいのかを知っていました。そして彼らはその機能に迷うのではなく、ツールの学習曲線に適応しました。

次に:ノーコード革命は本物ですが、それは魔法ではありません。 Unreal Engineのビジュアルスクリプティングは、プログラマーのように考える必要があります。あなたはまだロジックツリーを構築しており、状態を管理し、動作をデバッグしています。あなたはキーボードの代わりにマウスでそれを行っているだけです。スキルは同じです;インターフェイスは異なります。

実際に彼らをリリースに導いたのは何ですか?容赦のないスコープ管理。アセットを構築する代わりに購入することへの意欲。明確なコミュニケーション。コミュニティに助言を求めるタイミングを知ること。そして、おそらく最も重要なこと:同じことを望み、それが正しく得られるまで反復することをいとわない3人のチーム。

リリースについての退屈で誠実な真実

彼らはQAテストを自動化しました。それは派手ではありません。誰もそれについってツイートしません。しかし、8プレイヤーのマルチプレイヤーゲームを副業として構築している場合、自動テストは「完成した」と「完成していて、実際に機能している」の違いです。

また、ライセンス上の悪夢についても言及しています—すべての3Dアセット、すべてのサウンド、すべての音楽の条項を読み取り、彼らが誤って著作権を侵害していないことを確認してください。官僚主義。退屈。本質的。

それが、ほとんどの人がゲームをリリースしない理由です。エンジンを学ぶことができないからではありません。それが楽しさをやめ、仕事になるとき彼らが辞めるからです。


🧬 関連するインサイト

頻繁に質問される事柄

本当にコードなしでゲームを作ることはできますか? はい、Unreal のBlueprintsのようなビジュアルスクリプティングツールを使用すれば。しかし、あなたはまだロジックのように考える必要があり、システムを理解し、問題をデバッグする必要があります。それは「コーディング不要」ではなく、「構文不要」です。難しい部分はゲームデザインとリリースの規律であり、構文ではありません。

初心者はどのゲームエンジンを選ぶべきですか? Blueprintsを使用したUnreal Engineは、複雑さと学習曲線を気にしなければ機能します。Godotはより軽量で完全オープンソースです。Constructは本当に初心者向けです。誠実な答え:1つを選んで、切り替える前に小さなゲームを完成させることにコミットしてください。

インディゲームをリリースするのに実際にどのくらいの時間がかかりますか? この3人は明確なスコープで副業として1年かかりました(パーティゲーム、限定的なミニゲーム、購入したアセット)。あなたのタイムラインはスコープ、チームスキル、そしてどれほど容赦なくあなたが機能クリープを殺すかに完全に依存しています。最も一般的な間違い:両方を過小評価すること。

James Kowalski
Written by

Investigative tech reporter focused on AI ethics, regulation, and societal impact.

Worth sharing?

Get the best AI stories of the week in your inbox — no noise, no spam.

Originally reported by Dev.to