オンラインゲーム：ハウツー、または女の子プログラマーと私が議論した方法
小規模な開発チームがどのように成功したかについて多くの話がありました。 そして、これらの開発がどのように失敗したかについてさらに詳しく説明します。 しかし、ここでは、私の経験に基づいて、オンラインゲーム開発プロセスの進化について具体的にお話したいと思います。 事前に予約します。これは、大規模なオンラインゲームを開発した最初の経験です。
すべてが非常に興味深く始まった。 友人のウェブプログラマーと、誰がウェブプロジェクトをより速く、より良いものにするかについて議論するのは不正確でした。 あまりスプレーせず、あまり時間を使わないために、1週間だけを与えることに決め、マルチプレイヤーゲームを開発します！
この期間の終わりに、プロジェクトは私たちの共通の友達である「評価委員会」に引き渡されました。 そして...私のプロジェクトは勝ちませんでした。 そして、その時点で最も攻撃的だったのは、紛争の状況に応じて、対戦相手のゲーム開発を支援するためにもう1週間の労働時間を割り当てなければならなかったように思われました。 しかし、引数は引数です！
開始しました
共同開発の始めには何がありましたか？ はい、ほとんど何もありません！ 頭の中の概念と少しのソースコード。 さらに、2人の「チーム」。 プログラミングはマリーナによって行われました。 ユーザーインターフェイスの開発を開始しました。
私の「奴隷制」の週は非常に速くて面白かったです。 バグが修正され、いくつかの新しい機能が実装されました。 これで1週間が終わり、手を洗うことができましたが、...このプロジェクトは非常に興味深いことが判明し、開発を続けることにしました。
主なインストールは、できるだけ早く最初の実行可能なバージョンを作成することでした。 締め切りは再び厳しく選ばれました：1ヶ月。 これは、私たちが自由時間にのみゲームに参加し、市内のさまざまな場所にいて、ICQとSkypeでのみ通信しているという事実によるものです。
1週間-コンセプト
まず、コンセプト全体を紙に提示することから始めることにしました。 これは、将来的に大きな間違いから私たちを救った。
コンセプトはどのようなものでしたか？ おそらく、私たちだけが意味を見ることができるフレーズと文のセット（「大声で考えた」）。 しかし、それにもかかわらず、その中のすべての主要なポイントが述べられ、プロジェクトの開発の可能性が置かれました。 これで最初の週が終わりました。
2週間-作業開始、最初のミス
私はこのプロジェクトに取り組みたいと思って働きました。 更新されたファイルは、多くの場合、石鹸とICQを介してスローされます。 古いバージョンのコードとpsd-shkiとグラフィックが削除され、対応しました。まるで夜が費やされていないかのようです。
各家には独自のサーバーが構成されており、そこで作業が行われました。 なぜこの仕事の原則が選ばれたのですか？ すべてが非常に簡単です-自分自身に設定された期限は非常に厳しいですが、私は多くのことをしたかったので、共有サーバーと他の作業の同期を設定するように思われたので、無駄に時間を無駄にしないことに決めました。 私の頭には一つしかありませんでした：「あと3週間しか残っていません...そこにいないときに過ごす時間もあります。」
しかし、今週の終わりには、すぐにやるべきこととして、私たちはすべてをやり遂げることに決めました。
3週間-転覆とリファクタリング
Subversionをインストールし、プロジェクトをその中に保存することで、私たちの生活は非常に容易になりました。 今、私は蓄積の合併に多くの時間を費やす必要はありませんでした。 プロジェクトの最新バージョンを確認する機会が常にありました。 そして、最も重要なことは、以前のバージョンにロールバックする機会があったことです。 これもまた、後になって、「私たちの命を救った」。 振り返ってみると、バージョン管理システムがなければ何ができるのだろうか。
また、残された時間がますます少なくなっているという事実にもかかわらず、強い意思決定の1つはリファクタリングでした。
たとえば、最初は、ゲームマップはナビゲーション矢印を使用して（個別に）制御され、ゲームワールドの一部は大きなステップで断片的に表示されました。
後に、そのようなアプローチは放棄され、マウスでつかんでマップをドラッグすることになりました（ドラッグアンドドロップ）。 同時に、この関数を担当するコードをリファクタリングするにはあまりにも面倒でした。 これにより、機能が1つのタスクを対象とし、その役割を十分に果たし、他のタスクでさまざまな「ドピル」を獲得し始め、同時にエラーが発生するという事実に至りました。 結果として生じる混乱の中で、最も基本的な変更を行うには、多くのコードを修正する必要がありました。
そして、このコードがほぼ完全に書き直された後、大幅に多くのタスクを実行しながら、70％小さくなりました。
4週間-最初の行
残りの週では、期限が切れる前に、彼らは望んだほぼすべてを完了しました。 時間がなく、どこかでやり過ぎた。 しかし、特定の機能の実装に関する決定は直感的なレベルで行われたという事実にもかかわらず、ほとんどの場合、選択は正しいものであることが判明しました。 最初のテスターは、導入された変更を高く評価しました。
クローズドテストでは、すべてが完全に行われたわけではなく、オンラインゲームは人に見せられる状態よりも生であることが示されました。 インターフェースはほとんどなく、ゲームプレイの管理は非常に難しく、直感的ではありませんでした。 しかし同時に、大きな開発の可能性が見え、テスターはゲームプレイを気に入っていました。 したがって、そこで停止しないことが決定されました。
5〜7週間-チューリストと多くの仕事
要望とバグレポートを収集し、それらのソートと優先順位付けを開始しました。 これはすべてブレインストーミング形式で行われ、すべての結論はステッカーに記録されました。 このプロセス全体が週末にかかってしまいました。 その結果、たくさんのステッカーができました。 アジャイル開発のイデオロギー家は、ボードを取り、それをエリアに分割し、そこにすべてを掛ける必要があると言います。 しかし、このオプションは私たちには適していない-私たちは街のさまざまな場所で働いていたので、リアルタイムでタスクの完了を確認したかった。
最初に、彼らは共同作業を支援することになっている専門のオンラインサービスに頼りました。 多くのことを試してみましたが、それらはすべて私たちに合わないと確信していました。 機能で過飽和状態になった人もいれば、逆に何かが足りなかった人もいれば、支払われた人もいました。
最終的に、Googledocsを支持してサービスを放棄しました。 目的の列の強調表示を調整することにより、非常に便利なtodoリストが得られました。
これが主な仕事が沸騰し始めた場所です。 タスクは積極的に閉じられました。 今、進歩が見られ、興奮が現れました。 これにより、開発速度が著しく向上しました。
この段階で、1つのイデオロギーの間違いに遭遇しました。いくつかの大きな未指定のタスクを作成しました。
それらの1つには、「すべてのダイアログボックスを元に戻す」という文言がありました。 今、このタスクの定式化は私たちにとっては野生のようであり、タスクのようには見えませんが、すべてが異なっていました。 このあいまいな表現のために、タスクは1か月半の間閉じられませんでした。
タスクをサブタスクに分割するのが正しいでしょう。 たとえば、「ランキングの表を作成する」、「設定のボタンを定型化する」、「プレイヤーのinfaのインベントリを作成する」など。 また、ゲームインターフェースの仕様では、元のタスクを完了したタスクのリストに送信することはできません（新しいダイアログボックスがうらやましい規則性で表示されました）。
また、テスターの簡単な手で、特定の機能の実装に関する多くの新しいリクエストを受け取りました。 作品の始まりと、紙に概説された単一のコンセプトがあったのは無駄ではなかったという事実を思い出しました。 概念からの強い逸脱を否定することにしました。 この難しくないルールに従って、確立された時間枠内に留まる機会を与え、ゲームプレイの整合性を失わないようにしました。
今月は無駄ではありませんでした-多くのことが確定しました。 テストはすでに成功しており、著しく大きな成功を収めています。
8週目-パレット原則、多くの結果
おそらくすでに聞いたことがある80/20ルールについて話すべきではないと思います。 この問題にどのように遭遇し、どのように結果の20％を不快に戦ったかをお話しします。
この時点で、テスターはチャット、さまざまなゲームの地形、およびすべてのゲームアクションの開始と終了に関する通知を要求しました。
チャット ここではすべてが簡単です。 80/20-2つのフェーズに作業を分割することが決定されました。 最初は、メッセージを送信できる通常のチャットが行われました。 シンプルで高速：40行のサーバーコードと1ダースのクライアントコード。 プライベートメッセージやプライベートメッセージ、禁止など。 後で延期されました。
ゲームの風景。 長い間、私たちはこのタスクを引き受けました。 ああ、どうしてそれを取りたくなかったのでしょう！ それは役に立たない機能だと思った。 しかし、私たちは納得し、しぶしぶ座って、数時間でそれをしました。 ここで、私たちは非常に間違っていることに気付きました-その効果は、何よりも私たちの期待でした。 あなたは自分がそれが「前」にどのように見えたのか、そして「後」にどれほどそれが目に快適になったかを比較することができます。
アラート。 どれだけ考えても、急いでそれを行う方法を理解できませんでした。 それを試して、コード全体を調べて、プレーヤーのアクションが彼に何をしたかを伝えているかどうかを再確認してください。 もちろん、ここでは、コードを書いたときにこれを行わなかったことを私たち自身が責めていました。 しかし、この仕事を長い箱で延期する以外に何も残っていませんでした。
今週の結果、有用な80％を実装し、残りの20％は後で延期されました。
第9週-パレット原則、ほとんど結果なし
週の初めは困難でした。 タスクは結果の20％に含まれていました。 しかし、私たちにできること...そして、予想外の、しかし非常に楽しい発見をしました。 私たちのタスクは、2人の開発者の間で均等に分割され、重複することはありませんでした。 これにより、作業の邪魔にならずにタスクの実装を完了することができました。
この経験も考慮に入れました。 将来的には、次のように行動しました。結果の80％に関連するタスクを実装し、交差する最大の機能をキャプチャしようとしました。 そして将来、彼らは「退屈な」週を組織し、全員がパートナーを邪魔することなく、開始されたタスクを完了しました。
10-13週間-多くの厄介なバグ
リリースのプロジェクトを準備します。 見つけるのが困難で、めったに現れないエラーの山、元のコンセプトの小さな欠陥。 一般的に、準備のために計画された4日間の代わりに、3週間停滞しました。 多くのコードが書き直されましたが、これは作業の最初の数週間から残っており、「クランチ」で常にひねられていました。 この段階で、事実上リファクタリングが行われなかったことが呪われました。
次に、回帰エラーにより、自動化されたテストを作成することで作業が非常に簡単になることが明らかになりました。 しかし、これは次のステップです。
結論：
1）プロジェクトに100行を超えるコードが含まれる場合-策定されたコンセプトを用意します。 コードが1000行を超える場合-コンセプトが書かれている。
2）概念を変えることを恐れないでください、しかしそれを乱用しないでください。 すべてをそのままにしておくと、「ストリームに入らない」リスクがあります。 そうしないと、プロジェクトを終了できません。
3）プロジェクトが100行のコードに収まると考える場合でも、バージョン管理システムの使用を怠らないでください。
4）リファクタリングを恐れないでください。たとえ製品が明日完成し、サポートを必要としないように思えてもです。
5）大きなタスクをより小さく、具体的なタスクに分割します。 彼らはより面白く、より生産的です。
6）回帰テストを書くことを忘れないでください。
7）プログラミングについてさえ女の子と議論しないでください。 特に、彼らからのプログラマーが悪いと思われる場合:)
生き返った。
そして最後に、職場のプログラマー:)
All Articles