良い一日 私の名前はイリヤで、完璧主義者です。
ほとんどのスタートアップの主な問題の1つは、彼らが決してスタートアップにならないということです。彼らは単に最初のプロジェクトを完了することができません。 一部のフリーランサーも同様の困難を経験しています。彼らはプロジェクトを時間通りに完了するとは限りません。
これらの問題には、一般的にかなり些細な解決策があります。 しかし、コードの理想性をあえて放棄する人はいません。完成したプロジェクトを取得する代わりに、通常は夢のプロジェクトを作成します。
1か月前、1.5人のデザイナーと1人半のコーダーで構成されるチームが、高速ゲーム開発の地域チャンピオンシップで1位になりました。 開発には48時間しかかかりませんでした。 完全にコーヒーと神経で構成される2日間は、競争のプロジェクトの中で最も完成したものになりました。 私は自分自身で何をしなければならなかったか、そして人々に見せることを怖がらないであろう完璧なコードを書くという私の願望をあなたに話します。
リモートで言えば、競争ゲームは小さなプロジェクトであると想定されていましたが、1つまたは2つのパッチと準備段階での長期的なサポートはありませんでした。 このようなプロジェクトを評価するための2つの主な基準は、論理的な完全性とトピックへの関連性です。 多くは競争の条件に依存していました。 すぐに予約します。その条件に応じて、ライセンスの問題がすべてパフォーマーにあることを条件に、言語、フレームワーク、エンジン、アートを選択することができました。 ルールの複雑なバージョンもあり、1人が競争に参加し、最後にすべてのソースを提供する必要がありましたが、主催者はそれらを拒否しました。 いずれにせよ、私はエンジンのない純粋なActionScriptを選択しました。
TKなしで動作します。 準備段階
競争は金曜日の夜の8時に始まりました。 その瞬間から、基本的なデザインの空白を描き、基本的なコードモジュールを記述し、ゲームコンセプトを思いつくために、すでに何かを始めることができました。 しかし、ゲームのテーマは、すべてのチームが午前中にのみ受け取り、すべてに共通であり、事前に不明です。 当初、25の可能なトピックの配列のみが知られていましたが、そのうちの8つの投票で、土曜日の午前中に、誰にとっても非常に予期していなかった「進化」が選ばれました。 ここで最初の問題が現れ、それを解決して、ガウジングの波をつかみ、ゲームを時間内に終わらせることができました。
金曜日の夕方、25のトピックのうち20のトピックに適したゲームエンジンに費やしました。 次の日までに、あらゆるトピック用に既製のエンジンを単純にカスタマイズできることを期待して、非常に異なる瞬間を逃しました。 トピックが説明されていない5つのトピックに含まれていることを知ったとき、準備作業の結果は単純に破棄する必要がありました。 実際、この準備段階は、私たちが何をするかを正確にすでに知っているが、何をするかまだわかっていないため、非常に重要であり、常に全員と一緒です。 フリーランサー-注文を受けたが、顧客が参照条件に急いでいなかったとき。 ソフトウェアの生産をストリームで行っている企業には、注文から自由時間をすべて成長させて販売するカーネルがあります。 インディーズ-設計ドキュメントがまだ検証されておらず、彼の手が少なくとも何かを書くためにすでにかゆみを持っている瞬間。 この時点で、すべてのプロジェクトに共通することを行うのが最善です。 たとえば、すべてのゲームでタイマーが必要です-タイマーをユニバーサルにし、ミリメートルに調整し、便利な開始で必要なメソッドを呼び出します。 またはメインメニュー。 またはプリローダー/インストーラー。 デザイナーでも、同じメインメニューのテンプレートをいくつか作成して、インターフェイスの概要を説明できます。 初日の8時間にキーボードとマウスからのメッセージ用のエンジンを作成すると、役に立たないことが判明したキャラクターの運動エンジンを磨くことができたので、私は多くの神経を節約しました。
ガウジングの波、または計画を中止して実行を開始するときです。
土曜日の朝、デザイナーと私はオフィスに来て、予想外のトピックに合ったゲームを緊急に思いついた。 ここで余談をして、チームが「 誰が気にするの？ 」、無料の検閲翻訳では、「だれが気にしているのですか？」 プロジェクトボードに立って、頭の中で何も考えずにそれを見ました。 特に2日間で構築された分岐プロットの複雑なゲームが必要なのは誰ですか？」 純粋なファンの上に構築された、原始的なゲームプレイで非常にシンプルなゲームを作ることが決定されました。 ゲームの本質は退屈な神であると宣言されました。退屈した神は、実際の進化論に反論することを決めました。 デザイナーは座って、アートと色のガイドラインの例を探しました（これが何を意味するのかわかりません）。そして、デザインドキュメントを書きました。
最初、ディスコには1つの文しかありませんでした。「これは神のスリッパで進化の法則に違反することに関するゲームです。」 2日間にわたって、dzdockには新しい機能が追加されましたが、最初のステートメントに矛盾するものはありませんでした。 このような処方の美しさは、数時間にわたって詳細を熟考することなくすぐに作業を開始できることです。 「どうすればいいのか」という質問に対して明確な答えが得られます。「正確にどうやってやるのか」などの慣習に煩わされることはありません。 少なくとも初めて「どのように？」のような質問がなければ最良の選択肢です。 タスクがあり、定式化され、指定されていませんが、少しずつすでに実現できます。 設計文書の完成についてチームと議論するとき、私は詳細に焦点を合わせませんでした。 このドキュメントに追加する必要があるものはすべて、「何？」という質問に答えました。 デザイナーから「インターフェイス要素の色はどうあるべきか」と尋ねられた場合、私は単に「ベストを尽くす」と答えました。 自分に質問をした場合：モンスターはどのように互いに戦うべきか、どのようにコードの残りの部分と通信するべきか-私は「どうにかして、うまくいったら」と答えました。 言うまでもなく、アーキテクチャ計画の問題は提起さえされていませんでしたか？
この分離の理由は非常に簡単です。 コードがどれほど完璧であっても、どれだけ標準に準拠していても、そしてそれが実装する複雑なプログラミングパターンが何であれ、エンドユーザーはそれらを見ることはありません 。 ユーザーにとっては、プログラムがクラッシュせず、速度が低下しないことが重要です。 メインワークフローのプロセスでユーザーが1つの例外をキャッチしなかった場合、ユーザーが一気にゲームに合格した場合、ユーザーは第3レベルでテクスチャーに失敗したこと、または敵が何らかの方法で第5の方法で彼を攻撃したことを覚えていません。 実際、ユーザーの手を取り、製品の興味深い場所をすべて見せ、問題を引き起こす可能性のある場所を慎重に回避する必要があります。 逆もまた真です。ユーザーが最もよく使用する可能性のあるコードの部分に焦点を当てることが最善です。
無理しないで
ただし、狂信は、仕様を無視するような有用な開発方法であっても有害です。 少し貴重な時間を費やすべきボトルネックがいくつかあります。 たとえば、単調な作業が先行している場合、特にそうする必要がない場合。 チームの設計者を半減させるという問題を説明するには、少し余談をして、Flashでのグラフィックスプログラミングの本質を説明する必要があります。
当初、フラッシュはさまざまなアニメーションを再生し、簡単に制御できるように設計されていました。 3番目のバージョンのActionScriptは、非常にオブジェクト指向のイベント駆動型言語ですが、以前のFlashアプリケーションでは、クラスと一般的に個別のファイルを使用する人はほとんどいませんでした。 通常、すべてのコードは、一部のユーザーアクション、内部タイマー、またはサーバーとの通信ではなく、特定のアニメーションフレームへの入り口によって呼び出されます。 Flash開発者には、独自の歴史的なショートカットである「フレーム内のコード」もあります。これは通常、初心者向けエンコーダの動作を意味します。 フレーム内のコード自体と、いわゆる「マウスを使ったプログラミング」の原則は、通常、気付いたエラーを修正することが非常に難しくなるという事実につながります。 このエラーが一般的であり、一度に複数のアニメーションに存在する場合、エラー修正時間は正比例して増加します。 検索と置換を行うことはできません。各アニメーションに手動で移動して、手動で修正する必要があります。
私たちのゲームでは、それぞれ4つのアクションを持つ39種類のモンスターのアニメーションを実装することが当初計画されていました。 アニメーションの開始と停止は、ゲーム内イベントの発生時にコードによって作成されます。 アニメーターには、これらすべてのアニメーションに対応するテンプレートがすぐに提供されなかったという事実により、プレーヤーにとって軽微だが非常に顕著なエラーが半分以上のアニメーションに忍び込んできました。 私はすべてを一緒に修正しなければならず、多くの時間が費やされ、デザイナーは口論し、そのうちの一人は仕事を続けることを拒否しました。
解決するに値するもう1つのポイントは、コードの個々のブロックの開始と終了のインターフェイスです。 複数のプログラマーがいるチームにとって、このルールはさらに重要になります。 チャレンジと完了の明確で強力な橋渡しを、それぞれの責任ゾーンの境界を越えて行う必要があります。 厳密に言えば、特定の条件下では、2番目のプログラマーが長い時間を経て古いコードに戻ったときに唯一のプログラマーになることができます。 したがって、最初の呼び出しからコードブロックの作業を終了する予定がない場合は、そのようなインターフェイスの存在に注意することをお勧めします。
完了、リリースパス
開発期間が終わり、プロジェクトが最初のリリースになると、計画されているすべての機能が最初のリリースに入ることができないという考えを受け入れることができれば非常に便利です。 契約条件が早ければ早いほど、フィッシュリストのカットを早く始めることができます。 自分で設計文書を作成した場合、それを単純にするのは簡単です。すべての未実現機能を取得し、「これはプロジェクトになります...」という最初の文に合わせてください。 機能が論理的に接続されていない場合、後悔することなく破棄できます。 実装リストがまだかなり長い場合は、プロジェクト自体の機能の重要性に注意を払わずに、実行速度の優先度で並べ替えます。 機能が非常に重要であったとしても、リリース前に考えるのは遅すぎます。 さらに、見逃すほど重要になります-パッチの早期リリースに対する意欲が高まります。 たとえば、武器の兵器庫は私たちのゲームからあまり後悔することなく捨てられました。そのアニメーションは長い間デザイナーに描かれなければならず、ゲーム内の音楽の不足という問題の優先度は2つの追加のスライドショーのエンディングを追加するために大幅に削減されました。
時間がほとんど残っていない場合、ほとんどの重大ではないバグに注意を払うことさえできません。プログラムのメインワークフローを壊すバグのみを修正する必要があります。 たとえば、ゲームの最初のリリースでは、モンスターの戦いの無限のバグがあり、スリッパでヒットした瞬間に関係を整理しました。 しかし、私はまだ、モンスターの死に関するメッセージを2回送信することで、エラーを削除する時間がありますが、プロセッサの負荷は大幅に増加します。 繰り返しますが、このようなバグを完全に無視する必要はありません。最初のパッチに転送する方が良いでしょう。 私のコンピューターサイエンスの先生が言ったように、1つよりもプログラムに10個のエラーがある方が良い場合があります。 特に、これらの10個が構文で、1個が「プログラムが機能しない」場合です。 最初のタイプのプロジェクトは長い間お金を稼いでおり、それをサポートとパッチの発行に費やす余裕があり、誰も2番目のものを使用しません。
リリース後。 パッチとリファクタリング
そして今、この瞬間がついに来ました。 プロジェクトをリリースしました。 これとこれだけが主なものです。 おめでとうございます、追いつくかどうかは関係ありません。 完成したプロジェクトがあります。 少しバグがあり、計画より少しシンプルですが、準備ができています。 これで、レース後に時間をかけてリラックスし、最終的にリファクタリングを開始できます。 すぐに、すぐに座って、コードを自分に接続して、それを維持しやすくするための最善の方法を考えることができます。 プロジェクトが開発段階からサポート段階に移行したことに気付いた場合、プロジェクトでの作業がはるかに簡単になります。 逃したリリースのリストを見ると、あなたの偉大さの前にバグが実行され、ほんの少しの助けで未実現の機能自体が適切な場所に落ちます。 この間ずっと、あなたはあなた自身のたわごとに耐えて掘り下げ、手を打って、コードをその場所に緊急に置きたいと思ったときに停止しました：今、あなたはそれを買う余裕があり、最終的にパッチに進むことができます。
そして、あなたはすでに次のプロジェクトを行う方法を知っています。
PS： 1か月前にこのテキストを公開したかったのです。 しかし、OLD48の受賞者と賞の発表直後に、素晴らしいAnnieOmskが私に近づき、 HappyDev'12カンファレンスでの開発中に直面しなければならなかった困難について話すように申し出ました。 私が望んでいたのはどこかに落ちてすぐに眠りにつくことだったので、彼女を拒否することはできませんでした。 次の3週間、私はひどく心配しました。私にとって大勢の聴衆の前で行って話す価値があるかどうか分かりませんでした（これが私の最初の経験です）。 しかし、最終的にはすべてがうまくいったので、このレポートを書くための追加の動機が与えられたことを嬉しく思います。
PPS： 誰かがゲームをプレイしたい場合： リンクをたどります。 誰かが本当に興味があるなら：次のリンクで私のプレゼンテーションへのスライドを見つけることができます