さい は て の こと う バグ。 【剣盾s5最終667位 最終日最高187位】枯受生花ドヒドキレイハナサイクル

催告(さいこく)とは

さい は て の こと う バグ

こんにちは、さいです。 ゲームのリリースが間近に迫り、ゲームの開発が一通り終了して、バグを洗い出す期間のことを、デバッグ期間と呼びます テスト期間・QA期間と呼ぶところもあります。 デバッグ専任のQAエンジニアや、あるいはソフトウェアエンジニア向けのプログラムデバッグの記事はネット上にあるものの、ゲーム開発がはじめての人向けや、プログラマー以外の人向けの記事はなかったので、まとめます。 前提 本記事では、以下の前提で書かれています。 デバッグとはゲームを自由にプレイすることではない デバッグについてよく勘違いされがちなのは、デバッグとは「自由にプレイしてみて、それの結果出たバグを報告する」ということではないことです。 "あらゆるパターンをプレイ"してみて、それの結果出たバグを報告するということです。 このためデバッグ作業というのは、細かい条件が違うだけの、同じプレイを何度も繰り返す作業になります。 めちゃつまらないです。 地道です。 でもこれは仕方ないことなのです。 覚悟を持ってやっていくことが大切です。 プログラマーだけの仕事ではない プログラマーはデバッグ期間に限らず、開発中にもよくデバッグをします。 よってデバッグはプログラマーだけの仕事だと勘違いされがちですが、そうではありません。 なぜかというと、ゲーム全体をデバッグするには大量の人手が必要であり、プログラマーだけではその人手をカバーすることが難しいからです。 前述の通り、デバッグは細かい条件が違うだけの、同じプレイを何度も繰り返す作業になります。 とにかくプレイする項目が多いです。 またプログラマーは、発見したデバッグを修正する作業もあります。 これはプログラマーにしかできません。 効率的なチーム内での分業のためにも、デバッグは外部のテスターや、チーム全員で行い、プログラマーはバグの修正に専念するのがオススメです。 なお同人やインディーゲーム開発で、デバッグ知識についてもっとも詳しいのはおそらくプログラマーであるはずです。 チームメンバーのデバッグ作業についてはプログラマーが主導し、またサポートしてあげるのが良いと思います。 デバッグ作業の具体的な内容 1. プレイヤー目線で一通りまずゲームを一通りクリアする まずゲームを通常プレイしてみて、進行不能バグがないことを確認します。 進行不能バグがあると、デバッグできない箇所が発生してデバッグ作業が止まるので、まずはそれを潰します。 実装した内容を一通り確認する サウンド、セリフ、アニメーション、イラスト、スクリプト etc.. ゲームに組み込んだアセットを一通りゲーム上で確認します。 アセットの製作者が、実際にゲーム上でアセットを確認の担当をするのが良いでしょう。 これによって、アセットの組み込み忘れや、特定のアセット再生時のバグを一通り潰します。 どのようなパターンを網羅すべきか、非プログラマーにはイメージが付きづらいので、プログラマーが主導して、どのようなパターンを網羅すべきか、内容を決めると良いと思います。 負荷テスト ゲームを72時間起動しつづける、アイテムを可能な限り最大獲得してみる、といったことを行い、ゲームがクラッシュしないことを確認します。 それらの修正が一通り終わったら、デバッグ作業者が、思いついたことを手当たり次第に実施しましょう。 意図せぬ問題がないかを確認します。 デバッグ期間の最終日などに行うと良いでしょう。 役割 以降の説明のために、デバッグの際には3つの役割があるんだよ〜ってことを解説しておきます。 報告者:ゲームをデバッグし、それを修正する人へ報告する人。 チケット管理する人:報告されたバグを、適切な修正者へ渡す人。 修正者:報告されたバグを修正する人。 チケット管理する人は1人でそれ以外は1人の場合もあれば複数の場合もあります。 それぞれが役割を兼務することもあります。 チケット管理ツールを用意する デバッグを報告する人と、それを修正する人のコミュニケーションを円滑にするためにも、チケット管理ツールを利用することをオススメします。 チケット管理ツールは、JIRAやRedmine、Trelloや Google Spread Sheet など、チームメンバーが使いやすいものを選定しましょう。 チケット管理ツールを導入しないと、報告したバグの修正漏れが発生したり、報告内容の粒度が人によって異なるため、修正作業が困難になったりという事態が発生します。 チケットには以下を書くのがオススメです。 ・チケットのステータス 完了/未完了/見送り/仕様通り/重複辺りがあると便利 未完了:チケットの初期状態。 報告者が記載 完了:チケットのバグの修正が完了したこと。 修正者が記載 見送り:バグではあるが、対応できないので修正しない。 修正者が記載 仕様通り:バグではないので修正いない。 修正者が記載。 重複:他の人も報告してたので、チケット一本化のため記載。 チケット管理者が記載。 ・担当者 そのチケットの修正を担当する人は誰か。 チケット管理者が記載。 ・画面キャプチャ バグが発生した際のゲーム画面のキャプチャ 文字で書くより何倍もバグの情報がプログラマーに伝わるので、 チケットを起票する際は、画面キャプチャを含めることをオススメします。 むしろ画面キャプチャを必須にしてもいいくらい チケットの報告者が記載します。 ・起票日 実は別の修正によって、既にチケットが解決している可能性があります。 起票日があれば、バグが既に直ってたということが証明できるので、起票日を記入しておくと便利です。 チケットの報告者が記載します。 ・ゲームのバージョン これも起票日と同様に、既にチケットが解決していた場合に、そのバージョンのバグが既に直ってたということが証明できます。 チケットの報告者が記載します。 ・優先度 あまりにもチケットが多い場合に、どれから修正するかの優先度を書きます。 チケット管理者が記載します。 ・バグの内容 バグの内容は以下のフォーマットに沿って書くことを薦めます。 気づいたことはまず報告することが大事 デバッグをする際に、報告したほうが良いのか悪いのか迷うときがあります。 一番良くないのは、「これは報告する意味はないだろう」と勝手にジャッジしてしまい、実は重大なバグであることが見過ごされることです。 これはバグなのではと思ったことは積極的に報告しましょう。 それが実はバグでなくとも、報告された側は見送ることや、仕様通りとして修正しないことができます。 それは無意味な報告ではなく、意味のある報告なのです。 バグが修正されたことは必ずゲームで確認する バグを修正したにもかかわらず、誰も修正されたことを確認しないことが往々にしてあります。 このせいで、修正したつもりが実は直ってなかったり、あるいは別のバグを引き起こしている事態になったりします。 バグを修正したあとは、修正を担当したプログラマーでもバグを報告した人でもいいので、必ずバグが修正されたことをゲーム上で確認しましょう。 加えて、プログラマーはエンバグを防ぐため、プログラムの修正後は、影響範囲も確認しましょう。 発生手順はちゃんと書こう エンジニアがバグの再現方法がわからないため、デバッグ自体の修正より、再現に時間がかかることがよくあります。 単純にコミュニケーションミスであることの方が多いため、発生手順が想像付く場合は、起票者は詳細に書きましょう。 エンジニアはバグの内容を見るだけでは、どうしてそのバグが発生したかはわかりません。 エラーメッセージが出た場合も、必ずエラーメッセージをコピペするかキャプチャして貼りましょう。 エンジニアにとって原因特定のための極めて貴重な資料です。 テスト終盤は、見送りを検討しよう エンバグでバグが増えるくらいなら、些細なバグは修正を見送ることも検討しましょう。 FAQ Q. どこまで細かくデバッグすればいいですか? A. デバッグ作業とは「ゲームのバグを0にすること」です。 文字通り 0 が目標です。 まずは可能な限り細かくデバッグしまくるといいと思います。 おそらく、デバッグが期間内に終わらないことが見えてくると思います。 そのときに、どこを妥協してデバッグしないかを検討して進めるのが良いと思います。 仕様かバグかわからない A. 報告します。 バグを仕様だとして見逃してしまうのが一番良くないので、バグとしてチケットを起票し、チケット管理者の判断に任せるのが一番良いです。 要望や改善点は書くべきか A. 書かないほうがいいです。 デバッグ期間はバグを取る期間であり、要望や改善といったことは、デバッグ期間より前にやるべきです。 他の人が同一チケットを報告しているかもしれない... 気にせず起票しましょう。 内容が重複していればチケット管理者が重複している分を区別してチケットをクローズしてくれます。

次の

ザロクバグを使って最果ての孤島などにテレポート【ポケモンエメラルド】

さい は て の こと う バグ

【Cギア通信切断時にフリーズするバグ】 で通信した後に通信を切断すると画面がフリーズすることがある。 このとき全く操作できなくなってしまうため、一度リセットしないとゲームに戻れない。 【13番道路のキャモメに配達物を届けるイベントでフリーズするバグ】 のキャモメに配達物を届けるイベントにおいて、13ばんどうろに大雨が降っているときに配達物を届けると、キャモメが飛んで行くときに画面が暗転してフリーズしてしまう。 この場合も全く操作できなくなってしまうため、リセットしないとゲームに戻れない。 【ソウリュウシティジムで脱出できなくなるバグ】 内の3匹の竜の通路において、真ん中の竜の尻尾から「なみのり」ができてしまう。 一度「なみのり」で外に出てしまうと、元の通路には戻れず移動もできなくなるためリセットするしかない。 この状態でレポートをしてしまった場合は、セーブデータを消して最初からやり直すしかないようだ。 サポートセンターに連絡してみるという手もある。 【チャンピオンロードの坂を滑り降りるときに脱出できなくなるバグ】 で坂を滑り降りるときに、主人公の姿が消えて動かすことができなくなることがある。 リセットすればゲームに戻れるが、レポートしてしまった場合はセーブデータを消して最初からやり直すしかない。 手持ちに「そらをとぶ」を使えるポケモンがいる場合は、「そらをとぶ」で抜け出すことができる。 【ドリームワールドできのみが植えられないバグ】 のはたけできのみが埋まっていない穴に植えようとすると、「既にきのみが埋まっています。 別のはたけを選択してください。 」というメッセージが出ることがある。 その状態で再び植えられなかった畑に植えようとすると、きのみの個数が変わることがある。 きのみは増えることも減ることもある。 きのみを植えることに失敗すると、強制的にホームに戻される。 しばらく時間をおくと直って植えられるようになる。 【ドリームワールドでポケモンをねかしつけていないバグ】 ゲームシンクでポケモンを1体眠らせてからドリームワールドに行くと、「ポケモンをねかしつけていません」というメッセージが表示され、眠らせていないことになっている場合がある。 寝かしつけた直後はグローバルリンクのサーバーで処理が行われている。 混雑するとドリームワールドへの反映が遅れるため起こる現象。 【ドリームワールドで残り時間が増えるバグ】 ドリームワールドを一時間経たない内に中断してグローバルリンクトップページに戻る。 原因は不明。 【その他ドリームワールドのバグ】• ドリームワールドを終了しているのにポケモンを起こすことができない。 ハイリンクにどうぐを送っているのに、送っていないことになっている。 ポケモンと仲良くなっているのに、仲良くなっていないことになっていてハイリンクに連れて行くことができない。 ポケモンAでドリームワールドを遊び、Aをゲームシンクで起こす。 次にポケモンBを寝かしつけてドリームワールドに入ると、なぜかAが現れることがある。 【おいうちバグ】 プラチナ・ハートゴールド・ソウルシルバーでは天候変化中に「おいうち」を使うとバグが起きたが、ブラック・ホワイトでは改善された。 【細かいバグ】 わざマシン67「かたきうち」のディスクの色が本来のノーマルタイプの色 白 ではなくあくタイプの色 水色 になっている。 【バグだと勘違いしやすい仕様】 「ミラクルシューターをオンにしてトリプルバトルを行ったとき、最後の1匹になってからげんきのかけらを使うと入れ替えるしか選択できなくなりバトルが進まなくなる」、「ダブルバトル、トリプルバトルで2匹同時にひん死になると入れ替えるしか選択できなくなりバトルが進まなくなる」。 ひん死になったポケモンも選択しなければいけないところが勘違いしやすい。 データ集•

次の

Windows10のシステムホントの「さいとう」の「さい」に注意

さい は て の こと う バグ

こんにちは、さいです。 ゲームのリリースが間近に迫り、ゲームの開発が一通り終了して、バグを洗い出す期間のことを、デバッグ期間と呼びます テスト期間・QA期間と呼ぶところもあります。 デバッグ専任のQAエンジニアや、あるいはソフトウェアエンジニア向けのプログラムデバッグの記事はネット上にあるものの、ゲーム開発がはじめての人向けや、プログラマー以外の人向けの記事はなかったので、まとめます。 前提 本記事では、以下の前提で書かれています。 デバッグとはゲームを自由にプレイすることではない デバッグについてよく勘違いされがちなのは、デバッグとは「自由にプレイしてみて、それの結果出たバグを報告する」ということではないことです。 "あらゆるパターンをプレイ"してみて、それの結果出たバグを報告するということです。 このためデバッグ作業というのは、細かい条件が違うだけの、同じプレイを何度も繰り返す作業になります。 めちゃつまらないです。 地道です。 でもこれは仕方ないことなのです。 覚悟を持ってやっていくことが大切です。 プログラマーだけの仕事ではない プログラマーはデバッグ期間に限らず、開発中にもよくデバッグをします。 よってデバッグはプログラマーだけの仕事だと勘違いされがちですが、そうではありません。 なぜかというと、ゲーム全体をデバッグするには大量の人手が必要であり、プログラマーだけではその人手をカバーすることが難しいからです。 前述の通り、デバッグは細かい条件が違うだけの、同じプレイを何度も繰り返す作業になります。 とにかくプレイする項目が多いです。 またプログラマーは、発見したデバッグを修正する作業もあります。 これはプログラマーにしかできません。 効率的なチーム内での分業のためにも、デバッグは外部のテスターや、チーム全員で行い、プログラマーはバグの修正に専念するのがオススメです。 なお同人やインディーゲーム開発で、デバッグ知識についてもっとも詳しいのはおそらくプログラマーであるはずです。 チームメンバーのデバッグ作業についてはプログラマーが主導し、またサポートしてあげるのが良いと思います。 デバッグ作業の具体的な内容 1. プレイヤー目線で一通りまずゲームを一通りクリアする まずゲームを通常プレイしてみて、進行不能バグがないことを確認します。 進行不能バグがあると、デバッグできない箇所が発生してデバッグ作業が止まるので、まずはそれを潰します。 実装した内容を一通り確認する サウンド、セリフ、アニメーション、イラスト、スクリプト etc.. ゲームに組み込んだアセットを一通りゲーム上で確認します。 アセットの製作者が、実際にゲーム上でアセットを確認の担当をするのが良いでしょう。 これによって、アセットの組み込み忘れや、特定のアセット再生時のバグを一通り潰します。 どのようなパターンを網羅すべきか、非プログラマーにはイメージが付きづらいので、プログラマーが主導して、どのようなパターンを網羅すべきか、内容を決めると良いと思います。 負荷テスト ゲームを72時間起動しつづける、アイテムを可能な限り最大獲得してみる、といったことを行い、ゲームがクラッシュしないことを確認します。 それらの修正が一通り終わったら、デバッグ作業者が、思いついたことを手当たり次第に実施しましょう。 意図せぬ問題がないかを確認します。 デバッグ期間の最終日などに行うと良いでしょう。 役割 以降の説明のために、デバッグの際には3つの役割があるんだよ〜ってことを解説しておきます。 報告者:ゲームをデバッグし、それを修正する人へ報告する人。 チケット管理する人:報告されたバグを、適切な修正者へ渡す人。 修正者:報告されたバグを修正する人。 チケット管理する人は1人でそれ以外は1人の場合もあれば複数の場合もあります。 それぞれが役割を兼務することもあります。 チケット管理ツールを用意する デバッグを報告する人と、それを修正する人のコミュニケーションを円滑にするためにも、チケット管理ツールを利用することをオススメします。 チケット管理ツールは、JIRAやRedmine、Trelloや Google Spread Sheet など、チームメンバーが使いやすいものを選定しましょう。 チケット管理ツールを導入しないと、報告したバグの修正漏れが発生したり、報告内容の粒度が人によって異なるため、修正作業が困難になったりという事態が発生します。 チケットには以下を書くのがオススメです。 ・チケットのステータス 完了/未完了/見送り/仕様通り/重複辺りがあると便利 未完了:チケットの初期状態。 報告者が記載 完了:チケットのバグの修正が完了したこと。 修正者が記載 見送り:バグではあるが、対応できないので修正しない。 修正者が記載 仕様通り:バグではないので修正いない。 修正者が記載。 重複:他の人も報告してたので、チケット一本化のため記載。 チケット管理者が記載。 ・担当者 そのチケットの修正を担当する人は誰か。 チケット管理者が記載。 ・画面キャプチャ バグが発生した際のゲーム画面のキャプチャ 文字で書くより何倍もバグの情報がプログラマーに伝わるので、 チケットを起票する際は、画面キャプチャを含めることをオススメします。 むしろ画面キャプチャを必須にしてもいいくらい チケットの報告者が記載します。 ・起票日 実は別の修正によって、既にチケットが解決している可能性があります。 起票日があれば、バグが既に直ってたということが証明できるので、起票日を記入しておくと便利です。 チケットの報告者が記載します。 ・ゲームのバージョン これも起票日と同様に、既にチケットが解決していた場合に、そのバージョンのバグが既に直ってたということが証明できます。 チケットの報告者が記載します。 ・優先度 あまりにもチケットが多い場合に、どれから修正するかの優先度を書きます。 チケット管理者が記載します。 ・バグの内容 バグの内容は以下のフォーマットに沿って書くことを薦めます。 気づいたことはまず報告することが大事 デバッグをする際に、報告したほうが良いのか悪いのか迷うときがあります。 一番良くないのは、「これは報告する意味はないだろう」と勝手にジャッジしてしまい、実は重大なバグであることが見過ごされることです。 これはバグなのではと思ったことは積極的に報告しましょう。 それが実はバグでなくとも、報告された側は見送ることや、仕様通りとして修正しないことができます。 それは無意味な報告ではなく、意味のある報告なのです。 バグが修正されたことは必ずゲームで確認する バグを修正したにもかかわらず、誰も修正されたことを確認しないことが往々にしてあります。 このせいで、修正したつもりが実は直ってなかったり、あるいは別のバグを引き起こしている事態になったりします。 バグを修正したあとは、修正を担当したプログラマーでもバグを報告した人でもいいので、必ずバグが修正されたことをゲーム上で確認しましょう。 加えて、プログラマーはエンバグを防ぐため、プログラムの修正後は、影響範囲も確認しましょう。 発生手順はちゃんと書こう エンジニアがバグの再現方法がわからないため、デバッグ自体の修正より、再現に時間がかかることがよくあります。 単純にコミュニケーションミスであることの方が多いため、発生手順が想像付く場合は、起票者は詳細に書きましょう。 エンジニアはバグの内容を見るだけでは、どうしてそのバグが発生したかはわかりません。 エラーメッセージが出た場合も、必ずエラーメッセージをコピペするかキャプチャして貼りましょう。 エンジニアにとって原因特定のための極めて貴重な資料です。 テスト終盤は、見送りを検討しよう エンバグでバグが増えるくらいなら、些細なバグは修正を見送ることも検討しましょう。 FAQ Q. どこまで細かくデバッグすればいいですか? A. デバッグ作業とは「ゲームのバグを0にすること」です。 文字通り 0 が目標です。 まずは可能な限り細かくデバッグしまくるといいと思います。 おそらく、デバッグが期間内に終わらないことが見えてくると思います。 そのときに、どこを妥協してデバッグしないかを検討して進めるのが良いと思います。 仕様かバグかわからない A. 報告します。 バグを仕様だとして見逃してしまうのが一番良くないので、バグとしてチケットを起票し、チケット管理者の判断に任せるのが一番良いです。 要望や改善点は書くべきか A. 書かないほうがいいです。 デバッグ期間はバグを取る期間であり、要望や改善といったことは、デバッグ期間より前にやるべきです。 他の人が同一チケットを報告しているかもしれない... 気にせず起票しましょう。 内容が重複していればチケット管理者が重複している分を区別してチケットをクローズしてくれます。

次の