現時点では、ブラウザベースのゲームを開発しており、最も近いクローズド、オープン、アルファおよびベータテストに汗をかいて準備しています。 この点で、ユーザー側で最も便利なバグ修正システムを作成する必要があります。 技術フェーズの参加者であるというプレイヤーからの繰り返しの警告にもかかわらず、忍耐力を試すべきではないことに留意してください。 「プロジェクトを改善する」ための条件を作成しない場合、誰もがあなたの困難に唾を吐き、あなたが自分で知っている関連プロジェクトのスレッドに行きます-「遊び、愛、支払い」。
意識のあるユーザーは、簡単にバグを確認したり、外部に開かれている何らかのバグトラッカーを開いたり、タスクを正しく設定したりできるように思えます。 理論的に-それはできます。 実際には-最後の段落の終わりを参照してください。 ちなみに、このアプローチは、プロジェクトに対する最初のネガの蓄積に関連付けられることがよくあります。アルファテスターを募集することも広告費用の価値があり、聴衆は収集を開始し、テストを求められる製品に出くわしますが、そのための条件を作成しません-結果として、コストの増加広告、プロジェクトに関する一般的な背景など。
しかし、ラムに戻ります。 バグ。
条件は何ですか？
- ブラウザープロジェクト、戦略。
- テクノロジー-Flash + PHP;
- 内部バグトラッカーはRedmineです。
必要なもの
- プレーヤーごとにすばやくカジュアルなバグレポートを整理します。
- プレーヤーがバグの説明をテキストで提供する能力。
- プレイヤーがスクリーンスクリーンをアタッチする能力
- プレーヤーがエラーの視覚的表現と見なすものを画面上に直接マークする能力、または単に画面の中央に3文字（もちろん「BAG」という単語）を書く能力。
- ワンクリックですべての重要な情報を開発者に送信するプレーヤーの能力。
- 開発者がタスクを適切にredmineに配置し、マーカーによるバグの主要なグループ化を実装し、可能であれば、バグを正確に誰に送信すべきかを決定する必要があります（再度、マーカーによってガイドされます）。
プレーヤーはどのように見えますか？
ユーザーはゲームに参加しており、できればゲームプレイを楽しんでいます。 それから突然、彼は間違いに気づきました。 さて、ストア内のアイコンが「飛んだ」としましょう。 これは些細なことのようで、プレーヤーが明らかにthisなレポートサービスのどのスレッドにこれを怠るのか明らかになります（「プレイは一般的に邪魔をせず、開発者はおそらく知っています」）。 レポートの遅延しきい値を下げるには、ユーザーはF12を押すだけです。 その後、現在の画面の上部に次の画像が表示されます。再起動や反転はありません。
図1
上の写真からわかるように、プレイヤーがバグレポートモードであることを知らせるツールチップがプレイヤーの都市の上に表示されました。 以下は、コメントを入力し、画面上部のメモと記録のマーカーの色、キャンセルボタン、[送信]ボタンを選択できる最小限のフォームです。明らかに、それを許可した怠慢な開発者にバグレポートを送信します。
次に、プレーヤーには、次のタブで開く完成したエラーフォームが表示されます。
図2
これにより、プレーヤーはレポートに対する懸念を終了し、タブを閉じて、中断したところからゲームを続行できます。
開発者はどのように見えますか？
少しの実装について説明しますが、同時に最終プロセスが開発者にどのように提示されるかに注意してください。
だから：
- クライアントはサーバーに完全に「接続」されています。つまり、 サーバーがどのデータを送信するか、その正確性について約2400の場所をチェックインします。 どこかに一貫性がない場合、エラーが生成されます。 この状況の簡単な例：ユニットを雇った後、1000ゴールドが残り、1001が残ります。
- エラーには、エラーコードとエラー位置のハッシュで構成される一意のトークンがあります。 例：サーバーメソッドの応答の有効性を確認し、100500メソッドを確認できます。これが検証されない場合、これはエラーコードであり、エラーが発生したデータセットに固有のハッシュが割り当てられます。ゲームの特定の場所には独自のマーカーがあります。
- クライアントがエラーを生成した場合、またはゲーム内でテスターが視覚的なカントを見ただけの場合、F12を押すと、そのようなフォームが図1のように表示されます。
- このフォームで「送信」が押されると、クライアントは次のものを含むアーカイブを作成します：スクリーンショット（プレーヤーから「落書き」がある場合—それらと一緒に）、テスターのコメントを含むファイル、エラーログ（ある場合）、エラーコード（あった場合）、渦のログ（エラーにつながる可能性があります）
- このアーカイブはリポジトリにあり、サーバーで解凍され、詳細で便利なエラーレポートの形式でhttpリンク経由でユーザーに表示されます（図2を参照）。
- 最後に、最も便利なのは、このシステムのサーバーがRedmineでタスクを作成し、エラーマーカーによって繰り返しタスクを追跡し、プロジェクトマネージャーに割り当てて、プロデューサーと主要な開発者をスーパーバイザーのサーバーとクライアントに配置することです。
- プレーヤーのレポートへのリンクがタスクに添付されています。
Readmineのタスクは次のようになっています。
図3
必要に応じて、必要に応じて、システムをいくつかの方向に拡張および改善できます。 たとえば、オブザーバーにPMやプロデューサーを追加して、バグを直接リードに直接送信するためのかなり客観的な（90％の確率でtrue）基準を導入する。
それで十分ですか？
...好奇心reader盛な読者が尋ねます。 ユーザーエラーコレクションの整理に便利-はい。 時間が経つにつれて、システムはパン、チップで成長し、機能的に拡張すると確信しています。 プロジェクトチームを増やす場合は、上記の選択基準を導入する必要があります。
もちろん、正しいロギングを忘れないでください。 多くの場合、エラーに添付されたログは、ユーザーからのすべてのスクリーンショットやメモよりもはるかに便利です。 もちろん、このシステムは、テストのどの段階でも実装する必要があります。資料はそれについてではありませんが、これらの概要を簡単に説明します。
- ログのアカウンティング用のゲーム内システムがあります。 ゲームサーバーは、各ユーザーのくしゃみを特別な形式（エラーを含む）でテキストファイルに書き込みます。 これらのログは統計サーバーによって収集され、さまざまな基準（たとえば、最も一般的なエラー）ごとにグループ化されて表示され、ログ内のシーケンスなどでユーザーがエラーになった方法を確認できます。
- ゲームクライアント（自動）からバグを受信するシステムがあり、サーバーサービス（ハングする可能性がある）ではなく、httpリクエストを介した別のスクリプトを介して、ログがなく、クライアントでそのようなエラーが発生したことをサーバーに単に通知しますログおよび統計サーバー。
おわりに
実装されているシステムの利便性に関する最初のテストはすでに進行中です。プレイヤーはバグを報告し、グループ化は繰り返しを排除するのに役立ちます。 前述のように、このアプローチは唯一のものではなく、ユニークまたは普遍的です。 彼は「私たちのために働いているそのような人」です-私たちはその作成の理由とアメニティに関するおおよその意見を共有しています。 もちろん、プログラマーは、統計サーバー、KMam上のログを調べて、重要なレポートなどのフォーラムを検索する必要があります。 しかし、プレイヤー自身のためにこのすべてのアクションを大幅に簡素化できます。 読者がプロジェクトの資料から利益を得られることを願っています。