何もしていませんが、チームを構築しています
しないで
野望、野望、そして再び野心-これがインディーチーム内での仕事を妨げるものです...それを信じないか、これは純粋に主観的な経験だと思いますか？ さて、Halt and Catch Fireシリーズを見てください。 しかし、野心は問題の半分です-プロ意識ではなく怠が仕事を完了します。
悲しいかな、あなたが何もしないまで-これはあなたについてのものであり、あなたが見つけようとしている人たちについてのものではありません。 はい、あなたは同じを見つけるでしょう）
チーム内の2人の野心的な人々はすでに混雑しており、開発よりも多くの時間を費やすことを明確に理解する必要があります。 これは、プロジェクトについて話し合うべきではないという意味ではありません-重要なのは、その方法です。
チームを探す前に、あなたは何をしたいのか、ゲームについてのアイデアを持っている必要があります。 ゲームの名前、ジャンル、ゲームプレイサイクルで構成されます。 そして、それは紙の上にあるべきです。 名前がない場合は、後で表示されるようです。すべては問題ありませんが、おそらくゲームを理解していないでしょう。 私はそのようなプロジェクトに連絡することはありません-それは時間の無駄です。 ジャンルを理解していないと、ゲームにすべてを押し込みたいという事実につながり、面白いことになります。 ゲームプレイサイクルは、ゲームデザインの有用な用語の1つです。勉強してオプションを考え出すことはできません。 そして、もちろん、ディズドコフはありません-この段階ではまだそれを持てません。 今、あなたはあなたが望むものについて漠然とした考えを持っています（あなたにはそれは明らかなように思えるかもしれません-しかし、これはそうではないことを理解する方が良いです）。
チームと話し始めます。 95％が熱心にパートナーを探して削除されたことは周知の事実です。 パートナーの候補者と声で話すことは決してありません。おしゃべりに無駄な時間が無駄になります。 そもそも、あなたが誰と取引をしているのかを知り、彼だけが興味を持っているならそれは何の違いもないということを理解してください。これもまたあなたの時間です。
妥当性は、最初の交渉の最も重要な基準です。他者のために決定することはありません。何をすべきかを言うことも、期限を設定することもしないでください。 そのような人々はすぐにディレクターと見なされ、プロフェッショナリズムに応じて、チームは多少なりとも耐えます。
興味のある人は自分でそれを行い、何が起こったのかを示すために手紙を書きます。 意見を述べる機会を人々に与え、意見の相違がある場合に会話のトーンを上げないでください。 あなたは十分に早く理解するか、紛争のために人が主張している、または彼が提供することを彼が引き受ける。 それをあなたができないというルールにしなさい-それがどうあるべきかを決めるのはあなたのためではない。 その結果、本当に何かをしている人と一緒に仕事をしてください。 しかし、ここでは多くがチームの役割に依存しています。
これは非常に学術的なアプローチであり、ゲームデザイナーがゲームを考案し、プログラマーがエンコードし、アーティストが描きます。 それはすべて、その分野の専門家に依存しています。
理想的には、ゲームデザイナーの仕事は、プログラマーとアーティストの仕事が始まるところで終了します。 プログラマーやアーティストよりも優れた経験を持つゲームデザイナー（おそらくおとぎ話でしか発生しませんが、それでも）である場合にのみ、作品を配布し、タスクを設定し、プログラマーやアーティストが何をする必要があるかを説明できます。 そのような野望はないが、設定された条件で働くことができるゲームデザイナーを見つけてください。 彼の仕事は、アイデアを変更するのではなく、詳細にすることです。
アーティスト/ 3Dモデラーについては、これが最初のゲームである場合、まったく必要ありません。既製のモデルを使用してください。これで十分であるか、灰色のプロトタイプである正方形のプロトタイプを作成できます。 代わりに、レベルデザイナーが必要になります。
プログラマーに関する限り、主な基準は、javascriptに問題がない人を見つけ、他のコードを操作し、開発の一部としてそれを使用することです。
あなたはチームについて多くのことを話すことができます、時々それはあなたを引き下げるか、または広範囲に思われるが、あなたは内陸に行きたいです。 しかし、チームにあなたと協力する機会を与えてください。専門家との協力が無駄になったことは一度もありません。彼らのビジョンを評価してみてください。 何かを決定する場合、議論しないでください-他のオプションを評価するために一週間歩いてください。 オプションについて議論するときに、相手が妥協しないことがわかった場合、非専門家と協力できますか？ しかし、あなたはそれが必要ですか？ ただし、いずれにしても、少なくとも週に1回は、バージョン管理とバックアップをすべて記録してください。
プロジェクトのぼんやりとしたビジョンでの売上高
これがあなたの最初のプロジェクトであるか、またはスタッフの離職、呪いでチームでまだ働いておらず、これが紙ではなく現実的にどのように行われるか理解していない場合、99％でプロジェクトの薄暗いビジョンに問題があります それ以外のことはできません。
熱意が消え、人が配置されると、彼は何か他のものに夢中になり、別のプロジェクトを始めることができます。 ちなみに、これがスタッフの離職の2番目の理由です。一般化されていなくても、最初は前述のとおりです。 そのため、ドキュメントで修正せず、コメントを付けず、声を出さないでください。プロジェクトはアーティファクトを残さず、希望する場合でも1年以内に戻ることはできません。 そして、それはあなたがプロジェクトの明確なビジョンを持っていないことを意味します）
開発プロセス中、プロジェクトの明確なビジョンは不可能だと言いましたか？ はい すぐにではなく、通常は開発プロセスから離れたときに経験があり、おそらくあなたがプレイしたゲーム、映画/本、または良いセックスの影響下にある場合、あなたに来るのはこのビジョンです
そしてその前に、一度にすべてに取り組むことなく、完成したパーツ/タスクを実装して、修正し、修正してから、あなたがしていることを構造化してください。
このプロジェクトの明確なビジョンはどういう意味ですか？ これはプロジェクトの見た目ではなく、このプロジェクトがプレーヤー/ユーザーの見た目であると考える方法です。
これは、G。Buchのオブジェクトプログラミングの1つの原則によって最もよく説明されています。
十分性、完全性、および原始性の概念。 十分性とは、論理的で効果的な動作の実装に必要なすべてのものがクラスまたはモジュールに存在することを意味します。 つまり、コンポーネントは完全に使用可能でなければなりません。 たとえば、セットクラス（セット）を考えます。 このクラスのセットから要素を削除する操作は明らかに必要ですが、このクラスに要素を追加する操作を含めないのは間違いです。 十分な要件の違反は、抽象化を使用してクライアントが作成されるとすぐに検出されます。 完全性とは、抽象化のすべての特性のクラスのインターフェースに存在することを意味します。 十分性という考え方は、インターフェースに対する要求を最小限に抑え、完全性という考え方は、抽象化のすべての側面を網羅しています。 完全性は、ユーザーと対話するためのすべてを保証するインターフェイスを持つクラスまたはモジュールによって特徴付けられます。 完全性は主観的な要素であり、開発者はしばしばそれを悪用します。
プロジェクトの明確なビジョンについて話すときは、各要素の実装方法を理解し、これがさらなる開発中に拡張を必要としないことを理解しながら、1つの精神表現でその完全性を確認する必要があります。 その後、プロジェクトが完了したと言えます。 これは決して起こらないと言うことができ、常にプロジェクトを開発する必要があります。 いいえ、私はあなたに言います、そして実際、私たちの開発者は抽象化を定義し、それらを意味で満たしています。 選択した抽象化の美しさと完全性を管理できれば、プロジェクトと完成したゲームの明確なビジョンが得られます。