ゲーム開発のボタン連打不具合｜非同期処理で二重実行を防ぐ設計

ゲームを遊んでいると、特に意味もなくボタンを何度も押してしまうことがあります。パチンコなどでも似たようなことがありますね。

ロードが長いとき、演出を早く飛ばしたいとき、メニューの反応を待っているとき。ユーザーは、開発者が思っているよりも気軽に連打します。私自身がユーザーとしてゲームをしていたときを振り返っても、手すさびで意味なく連打していたことはよくあります。

ゲーム開発では、この「なんとなく押される操作」が不具合のきっかけになることがあります。特にアクション中の入力ではなく、セーブ、購入、ガチャ、メニュー、シーン遷移のようなUI操作で起きる不具合は、設計段階で見落とされやすい印象があります。

画面上ではただボタンを何度か押しただけに見えても、内部では処理が二重に走っていることがあります。ここを軽く見ると、後から調査しにくい不具合になります。

連打で二重実行が起こる

ボタン連打で起きる不具合の多くは、処理が終わる前に同じ処理がもう一度始まることから発生します。

たとえばセーブボタンを連打した場合、同時にセーブ処理が走ってしまうことがあります。セーブ処理は、プレイヤーの進行状況や所持アイテム、設定、フラグなどを扱います。ここで処理が競合すると、タイミングによってはデータ破損につながる可能性があります。

購入ボタンでも同じようなことが起きます。購入処理が完了する前に、もう一度購入処理が走ると、アイテムが二重に購入されることがあります。ゲーム内通貨や課金に関わる処理では、画面上の見た目だけでなく、サーバー側の状態も確認しないと原因を追いにくくなります。

ガチャでも、通信中や演出中に入力が通ってしまうと、意図せず2回回ってしまうことがあります。ユーザーから見ると「1回押したつもりだったのに、結果が2回分出ている」「演出中に触ったら挙動がおかしくなった」という見え方になります。

シーン遷移でも注意が要ります。画面遷移処理が二重に開始されると、遷移先のロード、破棄、生成が重なります。その結果、フリーズしたように見えたり、戻るボタンが効かなくなったり、想定外の画面に移動したりします。

メニュー画面でも、UI生成処理が重複すると、同じメニューが二重に開くことがあります。見た目としては軽い表示崩れに見えても、裏側ではイベントハンドラが二重登録されている場合もあります。そうなると、次の操作でさらに別の不具合につながります。

非アクションシーンのUIは見落としやすい

連打対策というと、アクションゲームの入力受付やコンボ、回避、攻撃ボタンの話が思い浮かびやすいです。操作感に直結するため、アクション中の入力は比較的よく確認されます。

見落としやすいのは、非アクションシーンのUIです。

ショップ、ガチャ、オプション、セーブ、ロード、ミッション報酬、ログインボーナス、リザルト画面。こうした画面は、開発側から見ると「ボタンを押したら処理するだけ」に見えやすいです。ただ、実際には通信、保存、演出、画面遷移、UI更新が絡みます。

ユーザーは、処理中であることをはっきり理解しているとは限りません。ボタンが押せる見た目のままなら、押してよいものとして扱います。反応が遅いと、もう一度押すこともあります。

そのため、UIは「正しいタイミングで1回だけ押される」前提にしないほうが安全です。全てのシーンで連打される可能性がある、という見方をしておくと、設計時やレビュー時に確認するポイントを揃えやすくなります。

入力中の処理をどう止めるか

よく使われる対策としては、処理中に入力をロックする方法があります。

ボタンを押した時点で入力を受け付けない状態にし、処理が終わったら再び入力できるようにする。画面上もボタンをグレーアウトしたり、ローディング表示を出したりすると、ユーザーにも処理中であることが伝わります。

処理中フラグを持たせて、同じ処理が二重に走らないようにする方法もあります。たとえば購入処理が始まった時点でフラグを立て、完了または失敗したらフラグを戻します。これにより、同じボタンが連打されても、2回目以降の処理を止められます。

ただ、通信ラグや非同期処理が絡むと、フラグ管理だけでは防ぎきれないことがあります。ローカル側では止めているつもりでも、通信の再送、画面遷移、コールバックの順番、エラー時の復帰処理によって、想定外の経路から処理が入ることがあります。

特に課金、購入、ガチャ、報酬付与のように結果が残る処理では、クライアント側の入力制御だけで安心しないほうがよいです。サーバー側でもトランザクション管理を行い、同じ要求が複数回来ても状態が壊れないようにしておく必要があります。

「ボタンを押せなくする」だけではなく、「同じ処理が複数回来ても破綻しないか」を確認するほうが、運用後の問い合わせにも対応しやすくなります。

レビューとテストでのチェックポイント

連打対策は、実装後にまとめて確認するより、仕様やレビューの段階で見ておくほうが進めやすいです。

画面仕様を見るときは、そのボタンが押された後に何が起きるかを確認します。通信が走るのか、セーブするのか、画面遷移するのか、演出を再生するのか。処理が終わるまでに時間がかかるものは、連打されたときの挙動を確認対象に入れておくと安心です。

レビュー時には、処理中フラグの戻し忘れも見たいところです。成功時だけフラグを戻していて、失敗時やキャンセル時に戻していないと、今度はボタンが押せなくなる不具合になります。二重実行を止める処理は、止めることだけでなく、どの条件で再び操作可能にするかまで確認する必要があります。

テストでは、通常操作だけでは見つからないことがあります。1回押して正常に動くことを確認した後、連打、通信遅延、戻る操作、画面切り替え、アプリ中断などを組み合わせると、問題が出る場合があります。

連打不具合は、単にユーザーの操作が荒いから起きるものではありません。押せる状態に見えるUI、処理中でも入力が通る設計、非同期処理の完了順、サーバー側の状態管理が重なって起きます。

そのため、人の操作を責めるより、どの時点で入力を受け付けるのか、どの処理を二重実行させないのか、どこで状態を確定させるのかを見たほうが、次の修正につながります。

確認ポイント

連打で起きる不具合を減らすには、次のような点を確認しておくと判断しやすくなります。

・処理開始後もボタンが押せる状態になっていないか
・通信中、演出中、画面遷移中に入力が通らないか
・購入、ガチャ、報酬付与、セーブなど、結果が残る処理が二重に走らないか
・処理中フラグは、成功時だけでなく失敗時やキャンセル時にも戻っているか
・画面遷移を連打したとき、遷移処理が複数回開始されないか
・UI生成処理が重複して、同じメニューやダイアログが二重に出ないか
・サーバー側で同じ要求が複数回来た場合に、状態が壊れないか
・通信遅延や再送が起きた場合でも、購入や報酬付与の結果が重複しないか

UIは、思った以上に連打されます。

特に非アクションシーンでは、入力の気持ちよさよりも、処理の安全性が後回しになりやすいです。けれど、セーブ、購入、ガチャ、シーン遷移のような処理では、連打されたときの挙動を確認しておくことで、修正範囲を判断しやすくなります。

「このボタンは何度も押されるかもしれない」と見ておくだけでも、レビュー時に確認するポイントは変わります。UIは全てのシーンで連打される前提で設計しておくと、後から原因を追いにくい不具合を減らしやすくなります。

おわりに

日々の発信は、X・Bluesky・Facebookでも行っております。
記事の更新や、開発・採用・マネジメントについての短い投稿はこちらでもご覧いただけます。

X　　　　：https://x.com/itchie_tatsumi
Bluesky　 ：https://bsky.app/profile/itchie-tatsumi.bsky.social
Facebook：https://www.facebook.com/ichino.souta

また、辰巳電子工業SS事業部では、エンジニアが安心して長く働ける環境づくりに取り組んでおります。
案件やキャリア支援、カジュアル面談にご関心のある方は、こちらもご覧ください。

https://www.tatsu-mi-systemsolution.jp/