知財求人 - 知財ポータルサイト「IP Force」
特開2024-75657ゲームプログラム、ゲームシステム、ゲーム装置、およびゲーム処理方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024075657
(43)【公開日】2024-06-04
(54)【発明の名称】ゲームプログラム、ゲームシステム、ゲーム装置、およびゲーム処理方法
(51)【国際特許分類】
A63F 13/428 20140101AFI20240528BHJP
A63F 13/211 20140101ALI20240528BHJP
A63F 13/44 20140101ALI20240528BHJP
A63F 13/55 20140101ALI20240528BHJP
A63F 13/812 20140101ALI20240528BHJP
A63F 13/56 20140101ALI20240528BHJP
G06F 3/01 20060101ALI20240528BHJP
【ＦＩ】
A63F13/428
A63F13/211
A63F13/44
A63F13/55
A63F13/812 D
A63F13/56
G06F3/01 570
G06F3/01 510
【審査請求】未請求
【請求項の数】19
【出願形態】ＯＬ
(21)【出願番号】P 2024041495
(22)【出願日】2024-03-15
(62)【分割の表示】P 2022056480の分割
【原出願日】2022-03-30
(71)【出願人】
【識別番号】000233778
【氏名又は名称】任天堂株式会社
(74)【代理人】
【識別番号】110001276
【氏名又は名称】弁理士法人小笠原特許事務所
(74)【代理人】
【識別番号】100130269
【弁理士】
【氏名又は名称】石原 盛規
(72)【発明者】
【氏名】伊庭 啓介
(72)【発明者】
【氏名】大坪 大剛
(57)【要約】
【課題】振り入力に係る操作装置の振り方（振り方向）の判定精度を向上できるゲームプログラム、ゲームシステム、ゲーム装置、およびゲーム処理方法を提供すること。
【解決手段】慣性センサを備える操作装置から取得した操作データに基づいて、操作装置への振り入力が行われたか否かを判定する。それぞれが複数の振り方向のうちいずれか１つに対応付けられる複数の教師データに基づいて生成され、操作装置が当該複数の振り方向のうちどの振り方向に振られたかを判定するための学習済みモデルを管理する。振り入力が行われた期間において取得した操作データを学習済みモデルに入力し、当該入力に応じた当該学習済モデルからの出力に基づいて操作装置が振られた振り方向を判定し、当該振り方向に基づいてゲーム処理を実行する。
【選択図】図１６
【解決手段】慣性センサを備える操作装置から取得した操作データに基づいて、操作装置への振り入力が行われたか否かを判定する。それぞれが複数の振り方向のうちいずれか１つに対応付けられる複数の教師データに基づいて生成され、操作装置が当該複数の振り方向のうちどの振り方向に振られたかを判定するための学習済みモデルを管理する。振り入力が行われた期間において取得した操作データを学習済みモデルに入力し、当該入力に応じた当該学習済モデルからの出力に基づいて操作装置が振られた振り方向を判定し、当該振り方向に基づいてゲーム処理を実行する。
【選択図】図１６
【特許請求の範囲】
【請求項1】
ゲーム装置のコンピュータに実行させるゲームプログラムであって、
前記コンピュータを、
慣性センサを備える操作装置から、当該慣性センサの出力に基づく操作データを取得する操作データ取得手段、
前記操作データに基づいて、前記操作装置への振り入力が行われたか否かを判定する振り判定手段、
それぞれが複数の振り方向のうちいずれか１つに対応付けられる複数の教師データに基づいて生成され、前記操作装置が当該複数の振り方向のうちどの振り方向に振られたかを判定するための学習済みモデルを管理する管理手段、
前記学習済みモデルに、前記振り入力が行われた期間において取得した前記操作データを入力し、当該入力に応じた当該学習済モデルの出力に基づいて前記操作装置が振られた振り方向を判定する振り方向判定手段、
前記操作装置が振られたと判定された前記振り方向に基づいて、ゲーム処理を実行するゲーム処理実行手段として機能させる、ゲームプログラム。
前記コンピュータを、
慣性センサを備える操作装置から、当該慣性センサの出力に基づく操作データを取得する操作データ取得手段、
前記操作データに基づいて、前記操作装置への振り入力が行われたか否かを判定する振り判定手段、
それぞれが複数の振り方向のうちいずれか１つに対応付けられる複数の教師データに基づいて生成され、前記操作装置が当該複数の振り方向のうちどの振り方向に振られたかを判定するための学習済みモデルを管理する管理手段、
前記学習済みモデルに、前記振り入力が行われた期間において取得した前記操作データを入力し、当該入力に応じた当該学習済モデルの出力に基づいて前記操作装置が振られた振り方向を判定する振り方向判定手段、
前記操作装置が振られたと判定された前記振り方向に基づいて、ゲーム処理を実行するゲーム処理実行手段として機能させる、ゲームプログラム。
【請求項2】
前記振り方向判定手段は、前記振り入力が行われた期間において漸次的に取得した複数の前記操作データを前記学習済みモデルに入力し、当該入力に応じた当該学習済モデルの出力に基づいて前記操作装置が振られた振り方向を判定する、請求項１に記載のゲームプログラム。
【請求項3】
前記振り判定手段は、前記取得した前記操作データに含まれる前記加速度データが示す加速度の大きさが閾値を超えた場合に前記振り入力が開始したと判定し、当該加速度の大きさがピークに達した後の解除タイミングにおいて、当該振り入力が終了したと判定し、
前記振り方向判定手段は、前記振り入力が開始された時点から前記解除タイミングまでに取得した複数の前記操作データの入力に応じた前記学習済みモデルからの出力に基づいて、前記振り方向を判定する、請求項１または２のいずれかに記載のゲームプログラム。
前記振り方向判定手段は、前記振り入力が開始された時点から前記解除タイミングまでに取得した複数の前記操作データの入力に応じた前記学習済みモデルからの出力に基づいて、前記振り方向を判定する、請求項１または２のいずれかに記載のゲームプログラム。
【請求項4】
前記振り方向判定手段は、前記操作データが前記学習済モデルに入力された場合に出力される、複数の振り方向のそれぞれに対応する類似度を用いて、当該複数の振り方向のうち、どの振り方向に対して前記操作装置が振られたかを判定する、請求項１～３のいずれかに記載のゲームプログラム。
【請求項5】
前記振り方向判定手段は、前記複数の振り方向のうち、２つ以上の振り方向のそれぞれに対応する前記類似度がそれぞれ所定の類似条件を満たす場合、最も高い類似度が対応付けられる振り方向に対して前記操作装置が振られたものと判定する、請求項４に記載のゲームプログラム。
【請求項6】
前記類似度に関する前記所定の類似条件は、前記ゲーム処理の実行によるゲームの状況に応じて異なるように設定される、請求項５に記載のゲームプログラム。
【請求項7】
前記教師データは、加速度の大きさまたは角速度の大きさとを少なくとも含む第１パラメータを含み、
前記操作データは、加速度の大きさまたは角速度の大きさとを少なくとも含む第２パラメータを含む、
、請求項１～５のいずれかに記載のゲームプログラム。
前記操作データは、加速度の大きさまたは角速度の大きさとを少なくとも含む第２パラメータを含む、
、請求項１～５のいずれかに記載のゲームプログラム。
【請求項8】
前記第１パラメータ、および前記第２パラメータはそれぞれ、前記操作装置の姿勢を示す姿勢データを更に含む、請求項７に記載のゲームプログラム。
【請求項9】
前記操作装置への振り入力が行われていないと判定されている間は、前記仮想空間に配置されるプレイヤキャラクタオブジェクトの姿勢を、前記操作データに基づいて算出される前記姿勢データで示される姿勢に応じた姿勢となるように変化させる、請求項８に記載のゲームプログラム。
【請求項10】
前記ゲーム処理実行手段は、ゲーム中における実行条件を満たすタイミングにおいて前記操作装置への振り入力が行われたと判定された場合に、前記ゲーム処理を実行する、請求項１～９のいずれかに記載のゲームプログラム。
【請求項11】
前記ゲーム処理実行手段は、前記仮想空間に配置されるプレイヤオブジェクトの位置と移動オブジェクトの位置とが所定の位置関係にあるタイミングにおいて前記操作装置への振り入力が行われたと判定された場合に、当該操作装置が振られたと判定された前記振り方向に基づいて当該移動オブジェクトを移動させる処理を実行する、請求項１０に記載のゲームプログラム。
【請求項12】
前記ゲームプログラムは、前記コンピュータを
前記移動オブジェクトを所定の速度で移動させ、当該移動オブジェクトの前記仮想空間における高さが所定の高さを下回る場合、当該所定の速度よりも速度が小さくなるように減速させて当該移動オブジェクトを移動させる移動制御手段として更に機能させる、請求項１１に記載のゲームプログラム。
前記移動オブジェクトを所定の速度で移動させ、当該移動オブジェクトの前記仮想空間における高さが所定の高さを下回る場合、当該所定の速度よりも速度が小さくなるように減速させて当該移動オブジェクトを移動させる移動制御手段として更に機能させる、請求項１１に記載のゲームプログラム。
【請求項13】
前記ゲーム処理実行手段は、前記所定の位置関係と、前記操作装置が振られたと判定された前記振り方向とが所定の条件を満たす場合、当該所定の条件を満たさない場合よりも有利となるように前記ゲーム処理を実行する、請求項１１に記載のゲームプログラム。
【請求項14】
前記ゲーム処理実行手段は、前記学習済みモデルの出力が、前記所定の類似条件を満たす振り方向がないことを示す場合は、前記操作装置への振り入力が行われていないとしてゲーム処理を実行する、請求項５に記載のゲームプログラム。
【請求項15】
前記ゲーム処理実行手段は、前記学習済みモデルの出力が、前記所定の類似条件を満たす振り方向がないことを示す場合は、前記振り入力が行われた期間に係る前記操作データに基づいて算出される当該操作装置の姿勢の変化に応じてプレイヤキャラクタオブジェクトの姿勢を変化させる、請求項５に記載のゲームプログラム。
【請求項16】
前記振り方向判定手段は、前記学習済みモデルの出力が、前記所定の類似条件を満たす振り方向がないことを示す場合は、当該類似条件は満たしていないが、前記操作データから算出される振り方向との類似性が最も高い振り方向に前記操作装置が振られたと判定し、
前記ゲーム処理手段は、当該振り方向に基づいてゲーム処理を実行する、請求項５に記載のゲームプログラム。
前記ゲーム処理手段は、当該振り方向に基づいてゲーム処理を実行する、請求項５に記載のゲームプログラム。
【請求項17】
慣性センサを備える操作装置から、当該慣性センサの出力に基づく操作データを取得する操作データ取得手段、
前記操作データに基づいて、前記操作装置への振り入力が行われたか否かを判定する振り判定手段、
それぞれが複数の振り方向のうちいずれか１つに対応付けられる複数の教師データに基づいて生成され、前記操作装置が当該複数の振り方向のうちどの振り方向に振られたかを判定するための学習済みモデルを管理する管理手段、
前記学習済みモデルに前記振り入力が行われた期間において取得した前記操作データを
入力し、当該入力に応じた当該学習済モデルの出力に基づいて前記操作装置が振られた振り方向を判定する振り方向判定手段、
前記操作装置が振られたと判定された前記振り方向に基づいて、ゲーム処理を実行するゲーム処理実行手段とを備える、ゲームシステム。
前記操作データに基づいて、前記操作装置への振り入力が行われたか否かを判定する振り判定手段、
それぞれが複数の振り方向のうちいずれか１つに対応付けられる複数の教師データに基づいて生成され、前記操作装置が当該複数の振り方向のうちどの振り方向に振られたかを判定するための学習済みモデルを管理する管理手段、
前記学習済みモデルに前記振り入力が行われた期間において取得した前記操作データを
入力し、当該入力に応じた当該学習済モデルの出力に基づいて前記操作装置が振られた振り方向を判定する振り方向判定手段、
前記操作装置が振られたと判定された前記振り方向に基づいて、ゲーム処理を実行するゲーム処理実行手段とを備える、ゲームシステム。
【請求項18】
慣性センサを備える操作装置から、当該慣性センサの出力に基づく操作データを取得する操作データ取得手段、
前記操作データに基づいて、前記操作装置への振り入力が行われたか否かを判定する振り判定手段、
それぞれが複数の振り方向のうちいずれか１つに対応付けられる複数の教師データに基づいて生成され、前記操作装置が当該複数の振り方向のうちどの振り方向に振られたかを判定するための学習済みモデルを管理する管理手段、
前記学習済みモデルに、前記振り入力が行われた期間において取得した前記操作データを入力し、当該入力に応じた当該学習済モデルの出力に基づいて前記操作装置が振られた振り方向を判定する振り方向判定手段、
前記操作装置が振られたと判定された前記振り方向に基づいて、ゲーム処理を実行するゲーム処理実行手段とを備える、ゲーム装置。
前記操作データに基づいて、前記操作装置への振り入力が行われたか否かを判定する振り判定手段、
それぞれが複数の振り方向のうちいずれか１つに対応付けられる複数の教師データに基づいて生成され、前記操作装置が当該複数の振り方向のうちどの振り方向に振られたかを判定するための学習済みモデルを管理する管理手段、
前記学習済みモデルに、前記振り入力が行われた期間において取得した前記操作データを入力し、当該入力に応じた当該学習済モデルの出力に基づいて前記操作装置が振られた振り方向を判定する振り方向判定手段、
前記操作装置が振られたと判定された前記振り方向に基づいて、ゲーム処理を実行するゲーム処理実行手段とを備える、ゲーム装置。
【請求項19】
ゲーム装置のコンピュータに実行させるゲーム処理方法であって、
前記コンピュータに、
慣性センサを備える操作装置から、当該慣性センサの出力に基づく操作データを取得させ、
前記操作データに基づいて、前記操作装置への振り入力が行われたか否かを判定させ、
それぞれが複数の振り方向のうちいずれか１つに対応付けられる複数の教師データに基づいて生成され、前記操作装置が当該複数の振り方向のうちどの振り方向に振られたかを判定するための学習済みモデルを管理させ、
前記学習済みモデルに、前記振り入力が行われた期間において取得した前記操作データを入力し、当該入力に応じた当該学習済モデルの出力に基づいて前記操作装置が振られた振り方向を判定させ、
前記操作装置が振られたと判定された前記振り方向に基づいて、ゲーム処理を実行させる、ゲーム処理方法。
前記コンピュータに、
慣性センサを備える操作装置から、当該慣性センサの出力に基づく操作データを取得させ、
前記操作データに基づいて、前記操作装置への振り入力が行われたか否かを判定させ、
それぞれが複数の振り方向のうちいずれか１つに対応付けられる複数の教師データに基づいて生成され、前記操作装置が当該複数の振り方向のうちどの振り方向に振られたかを判定するための学習済みモデルを管理させ、
前記学習済みモデルに、前記振り入力が行われた期間において取得した前記操作データを入力し、当該入力に応じた当該学習済モデルの出力に基づいて前記操作装置が振られた振り方向を判定させ、
前記操作装置が振られたと判定された前記振り方向に基づいて、ゲーム処理を実行させる、ゲーム処理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、慣性センサを備える入力装置を利用するゲーム処理に関する。
【背景技術】
【0002】
従来から、慣性センサを用いた入力を行わせるゲームであって、コントローラを振る振り入力によってオブジェクトの移動を開始させるゲームが知られている（例えば特許文献１）。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０１７－２１７４８９号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記のゲームでは、所定のタイミングで振り入力があった場合、所定のオブジェクトを仮想空間において移動開始させていた。
【0005】
この点につき、ゲーム内容によっては、ユーザが行った振り入力について、どのような振り方が行われたのか、振り方向がどの方向であるのか、を判定する必要がある場合もある。そして、このような場合に関して、振り判定の精度を向上させる余地があった。
【0006】
それ故に、本開示における目的は、振り入力に係る操作装置の振り方（振り方向）の判定精度を向上できるゲームプログラム、ゲームシステム、ゲーム装置、およびゲーム処理方法を提供することである。
【課題を解決するための手段】
【0007】
上記目的を達成するために、例えば以下のような構成例が挙げられる。
【0008】
構成例の一例は、ゲーム装置のコンピュータに実行させるゲームプログラムであって、
前記コンピュータを、操作データ取得手段、振り判定手段、管理手段、振り方向判定手段、ゲーム処理実行手段として機能させる。操作データ取得手段は、慣性センサを備える操作装置から、当該慣性センサの出力に基づく操作データを取得する。振り判定手段は、操作データに基づいて、操作装置への振り入力が行われたか否かを判定する。管理手段は、それぞれが複数の振り方向のうちいずれか１つに対応付けられる複数の教師データに基づいて生成され、操作装置が当該複数の振り方向のうちどの振り方向に振られたかを判定するための学習済みモデルを管理する。振り方向判定手段は、学習済みモデルに、振り入力が行われた期間において取得した操作データを入力し、入力に応じた当該学習済モデルの出力に基づいて操作装置が振られた振り方向を判定する。ゲーム処理実行手段は、操作装置が振られたと判定された振り方向に基づいて、ゲーム処理を実行する。
前記コンピュータを、操作データ取得手段、振り判定手段、管理手段、振り方向判定手段、ゲーム処理実行手段として機能させる。操作データ取得手段は、慣性センサを備える操作装置から、当該慣性センサの出力に基づく操作データを取得する。振り判定手段は、操作データに基づいて、操作装置への振り入力が行われたか否かを判定する。管理手段は、それぞれが複数の振り方向のうちいずれか１つに対応付けられる複数の教師データに基づいて生成され、操作装置が当該複数の振り方向のうちどの振り方向に振られたかを判定するための学習済みモデルを管理する。振り方向判定手段は、学習済みモデルに、振り入力が行われた期間において取得した操作データを入力し、入力に応じた当該学習済モデルの出力に基づいて操作装置が振られた振り方向を判定する。ゲーム処理実行手段は、操作装置が振られたと判定された振り方向に基づいて、ゲーム処理を実行する。
【0009】
上記構成例によれば、振り入力に係る操作データを学習済みモデルに入力して得られた結果に基づき操作装置が振られた振り方向を判定できる。これにより、ゲーム処理における振り入力の判定精度を向上させることができる。
【0010】
他の構成例として、振り方向判定手段は、振り入力が行われた期間において漸次的に取得した複数の操作データを前記学習済みモデルに入力し、当該入力に応じた当該学習済モデルの出力に基づいて操作装置が振られた振り方向を判定してもよい。
【0011】
上記構成例によれば、振り入力が行われた期間における複数の操作データを用いて判定を行うことができる。これにより、判定の精度を向上させることができる。
【0012】
他の構成例として、振り判定手段は、取得した操作データに含まれる加速度データが示す加速度の大きさが閾値を超えた場合に振り入力が開始したと判定し、当該加速度の大きさがピークに達した後の解除タイミングにおいて、当該振り入力が終了したと判定してもよい。そして、振り方向判定手段は、振り入力が開始された時点から解除タイミングまでに取得した複数の操作データの入力に応じた上記学習済みモデルからの出力に基づいて、振り方向を判定してもよい。
【0013】
上記構成例によれば、加速度の変化を見て振り入力の開始と終了を判定している。これにより、振り入力の開始と終了を簡易な処理で検出できる。また、より正確な振り入力期間における操作データを用いた判定が可能となる。
【0014】
他の構成例として、振り方向判定手段は、操作データが学習済モデルに入力された場合に出力される、複数の振り方向のそれぞれに対応する類似度を用いて、当該複数の振り方向のうち、どの振り方向に対して操作装置が振られたかを判定してもよい。
【0015】
上記構成例によれば、複数の振り方向それぞれとの類似性を見ることで、操作装置が振られた方向を判定する。これにより、所定の振り方向にある程度類似している振り方向に操作装置が振られた場合も、当該所定の振り方向に振られたものとして扱うことができる、これにより、ユーザ個々の振り方の個人差をある程度吸収した判定ができ、判定精度を向上できる。
【0016】
他の構成例として、振り方向判定手段は、複数の振り方向のうち、２つ以上の振り方向のそれぞれに対応する類似度がそれぞれ所定の類似条件を満たす場合、最も高い類似度が対応付けられる振り方向に対して操作装置が振られたものと判定してもよい。
【0017】
上記構成例によれば、類似条件を満たすものの中から最も類似度が高いものを選択して振り方向として判定するため、判定精度をより向上できる。
【0018】
他の構成例として、類似度に関する所定の類似条件は、ゲーム処理の実行によるゲームの状況に応じて異なるように設定してもよい。
【0019】
上記構成例によれば、類似条件をゲームの状況に応じて動的に変更できる。これにより、ゲーム展開に応じて、所定の振り入力が判定されやすい状態を作り出すことができる。例えば、操作装置を振るユーザの腕の動きが小さくなりがちな状況の場合でも、ユーザが所定の振り入力を行ったことを判定できる。
【0020】
他の構成例として、教師データは、加速度の大きさまたは角速度の大きさとを少なくとも含む第１パラメータを含み、操作データは、加速度の大きさまたは角速度の大きさとを少なくとも含む第２パラメータを含んでいてもよい。
【0021】
他の構成例として、第１パラメータおよび第２パラメータはそれぞれ、操作装置の姿勢を示す姿勢データを更に含んでいてもよい。
【0022】
上記構成例によれば、姿勢データを用いて類似度判定を行うことができ、判定精度をより向上できる。
【0023】
他の構成例として、操作装置への振り入力が行われていないと判定されている間は、仮想空間に配置されるプレイヤキャラクタオブジェクトの姿勢を、操作データに基づいて算出される姿勢データで示される姿勢に応じた姿勢となるように変化させてもよい。
【0024】
上記構成例によれば、ユーザが操作装置を振っていない間は、ユーザによって動かされた操作装置の姿勢変化をプレイヤキャラクタオブジェクトの姿勢に反映するため、ゲームへの没入感を高めることができる。
【0025】
他の構成例として、ゲーム処理実行手段は、ゲーム中における実行条件を満たすタイミングにおいて操作装置への振り入力が行われたと判定された場合に、ゲーム処理を実行してもよい。
【0026】
上記構成例によれば、振り入力を行うタイミングをユーザに判断させるというゲーム性を提供し、ゲームの興趣性を向上できる。
【0027】
他の構成例として、ゲーム処理実行手段は、仮想空間に配置されるプレイヤオブジェクトの位置と移動オブジェクトの位置とが所定の位置関係にあるタイミングにおいて操作装置への振り入力が行われたと判定された場合に、当該操作装置が振られたと判定された振り方向に基づいて当該移動オブジェクトを移動させる処理を実行してもよい。
【0028】
上記構成例によれば、移動オブジェクトを移動させることで進行するゲームにおいて、当該移動させるための振り入力の判定精度を向上でき、ひいてはこのようなゲームに対するユーザ体験を向上できる。
【0029】
他の構成例として、ゲームプログラムは、コンピュータを、移動オブジェクトを所定の速度で移動させ、当該移動オブジェクトの仮想空間における高さが所定の高さを下回る場合、当該所定の速度よりも速度が小さくなるように減速させて当該移動オブジェクトを移動させる移動制御手段として更に機能させてもよい。
【0030】
上記構成例によれば、所定の状況下（例えば移動オブジェクトが地面に近い状況）において、振り入力を行うための時間的猶予をユーザに与えることができる。これにより、振り判定が行われやすい状況とすることができ、ユーザ体験を向上できる。
【0031】
他の構成例として、ゲーム処理実行手段は、所定の位置関係と、操作装置が振られたと判定された振り方向とが所定の条件を満たす場合、当該所定の条件を満たさない場合よりも有利となるようにゲーム処理を実行してもよい。
【0032】
上記構成例によれば、所定の条件を満たすようにユーザに振り入力を行わせるというゲーム性を提供でき、ゲームの興趣性を向上できる。
【0033】
他の構成例として、ゲーム処理実行手段は、学習済みモデルの出力が、所定の類似条件を満たす振り方向がないことを示す場合は、操作装置への振り入力が行われていないとしてゲーム処理を実行してもよい。
【0034】
上記構成例によれば、いずれにも類似していなかった場合、例えば何もアクションを起こさないように制御するというゲーム処理を実行することができ、適切な振り入力ができていなかったことをユーザに認識させることができる
【0035】
他の構成例として、ゲーム処理実行手段は、学習済みモデルの出力が、所定の類似条件を満たす振り方向がないことを示す場合は、振り入力が行われた期間に係る操作データに
基づいて算出される当該操作装置の姿勢の変化に応じてプレイヤキャラクタオブジェクトの姿勢を変化させてもよい。
基づいて算出される当該操作装置の姿勢の変化に応じてプレイヤキャラクタオブジェクトの姿勢を変化させてもよい。
【0036】
上記構成例によれば、ユーザが行った振り入力に対してプレイヤキャラクタオブジェクトに何らかのアクションを行わせることが可能となる。
【0037】
他の構成例として、振り方向判定手段は、学習済みモデルの出力が、所定の類似条件を満たす振り方向がないことを示す場合は、当該類似条件は満たしていないが、操作データから算出される振り方向との類似性が最も高い振り方向に操作装置が振られたと判定してもよい。そして、ゲーム処理手段は、当該振り方向に基づいてゲーム処理を実行してもよい。
【0038】
上記構成例によれば、振り入力に対して何らかのゲーム処理を実行できる。これにより、振り入力が受け付けられなかったことによるゲーム進行の行き詰まりの発生やゲーム的に不利な展開となることを防ぎ、ゲームの難易度を下げることができる。
【発明の効果】
【0039】
本実施形態によれば、振り入力の判定精度を向上できる。
【図面の簡単な説明】
【0040】
【図1】本体装置２に左コントローラ３および右コントローラ４を装着した状態の一例を示す図
【図2】本体装置２から左コントローラ３および右コントローラ４をそれぞれ外した状態の一例を示す図
【図3】本体装置２の一例を示す六面図
【図4】左コントローラ３の一例を示す六面図
【図5】右コントローラ４の一例を示す六面図
【図6】本体装置２の内部構成の一例を示すブロック図
【図7】本体装置２と左コントローラ３および右コントローラ４との内部構成の一例を示すブロック図
【図8】本実施形態に係るゲーム画面の一例
【図9】オーバーの動きの一例
【図10】オーバーの動きの一例
【図11】オーバーの動きの一例
【図12】アンダーフォアの動きの一例
【図13】アンダーフォアの動きの一例
【図14】アンダーバックの動きの一例
【図15】アンダーバックの動きの一例
【図16】本実施形態に係る処理の概要を説明するための図
【図17】オーバーの場合のコントローラの姿勢変化を示す波形の一例
【図18】アンダーフォアの場合のコントローラの姿勢変化を示す波形の一例
【図19】アンダーバックの場合のコントローラの姿勢変化を示す波形の一例
【図20】ショット可能領域の一例
【図21】ＤＲＡＭ８５に記憶される各種データの一例を示すメモリマップ
【図22】プレイヤキャラクタデータ３０３の一例
【図23】操作データ３０６の一例
【図24】本実施形態に係るバドミントンゲーム処理の詳細を示すフローチャート
【図25】試合処理の詳細を示すフローチャート
【図26】プレイヤキャラ制御処理の詳細を示すフローチャート
【図27】振り入力関連処理の詳細を示すフローチャート
【図28】振り方判定処理の詳細を示すフローチャート
【図29】ショット発生判定処理の詳細を示すフローチャート
【図30】ショット発生判定処理の詳細を示すフローチャート
【図31】シャトル移動制御処理の詳細を示すフローチャート
【発明を実施するための形態】
【0041】
以下、一実施形態について説明する。
【0042】
以下、本実施形態の一例に係るゲームシステムについて説明する。本実施形態におけるゲームシステム１の一例は、本体装置（情報処理装置；本実施形態ではゲーム装置本体として機能する）２と左コントローラ３および右コントローラ４とを含む。本体装置２は、左コントローラ３および右コントローラ４がそれぞれ着脱可能である。つまり、ゲームシステム１は、左コントローラ３および右コントローラ４をそれぞれ本体装置２に装着して一体化された装置として利用できる。また、ゲームシステム１は、本体装置２と左コントローラ３および右コントローラ４とを別体として利用することもできる（図２参照）。以下では、本実施形態のゲームシステム１のハードウェア構成について説明し、その後に本実施形態のゲームシステム１の制御について説明する。
【0043】
図１は、本体装置２に左コントローラ３および右コントローラ４を装着した状態の一例を示す図である。図１に示すように、左コントローラ３および右コントローラ４は、それぞれ本体装置２に装着されて一体化されている。本体装置２は、ゲームシステム１における各種の処理（例えば、ゲーム処理）を実行する装置である。本体装置２は、ディスプレイ１２を備える。左コントローラ３および右コントローラ４は、ユーザが入力を行うための操作部を備える装置である。
【0044】
図２は、本体装置２から左コントローラ３および右コントローラ４をそれぞれ外した状態の一例を示す図である。図１および図２に示すように、左コントローラ３および右コントローラ４は、本体装置２に着脱可能である。なお、以下において、左コントローラ３および右コントローラ４の総称として「コントローラ」と記載することがある。
【0045】
図３は、本体装置２の一例を示す六面図である。図３に示すように、本体装置２は、略板状のハウジング１１を備える。本実施形態において、ハウジング１１の主面（換言すれば、表側の面、すなわち、ディスプレイ１２が設けられる面）は、大略的には矩形形状である。
【0046】
なお、ハウジング１１の形状および大きさは、任意である。一例として、ハウジング１１は、携帯可能な大きさであってよい。また、本体装置２単体または本体装置２に左コントローラ３および右コントローラ４が装着された一体型装置は、携帯型装置となってもよい。また、本体装置２または一体型装置が手持ち型の装置となってもよい。また、本体装置２または一体型装置が可搬型装置となってもよい。
【0047】
図３に示すように、本体装置２は、ハウジング１１の主面に設けられるディスプレイ１２を備える。ディスプレイ１２は、本体装置２が生成した画像を表示する。本実施形態においては、ディスプレイ１２は、液晶表示装置（ＬＣＤ）とする。ただし、ディスプレイ１２は任意の種類の表示装置であってよい。
【0048】
また、本体装置２は、ディスプレイ１２の画面上にタッチパネル１３を備える。本実施形態においては、タッチパネル１３は、マルチタッチ入力が可能な方式（例えば、静電容量方式）のものである。ただし、タッチパネル１３は、任意の種類のものであってよく、例えば、シングルタッチ入力が可能な方式（例えば、抵抗膜方式）のものであってもよい
。
。
【0049】
本体装置２は、ハウジング１１の内部においてスピーカ（すなわち、図６に示すスピーカ８８）を備えている。図３に示すように、ハウジング１１の主面には、スピーカ孔１１ａおよび１１ｂが形成される。そして、スピーカ８８の出力音は、これらのスピーカ孔１１ａおよび１１ｂからそれぞれ出力される。
【0050】
また、本体装置２は、本体装置２が左コントローラ３と有線通信を行うための端子である左側端子１７と、本体装置２が右コントローラ４と有線通信を行うための右側端子２１を備える。
【0051】
図３に示すように、本体装置２は、スロット２３を備える。スロット２３は、ハウジング１１の上側面に設けられる。スロット２３は、所定の種類の記憶媒体を装着可能な形状を有する。所定の種類の記憶媒体は、例えば、ゲームシステム１およびそれと同種の情報処理装置に専用の記憶媒体（例えば、専用メモリカード）である。所定の種類の記憶媒体は、例えば、本体装置２で利用されるデータ（例えば、アプリケーションのセーブデータ等）、および／または、本体装置２で実行されるプログラム（例えば、アプリケーションのプログラム等）を記憶するために用いられる。また、本体装置２は、電源ボタン２８を備える。
【0052】
本体装置２は、下側端子２７を備える。下側端子２７は、本体装置２がクレードルと通信を行うための端子である。本実施形態において、下側端子２７は、ＵＳＢコネクタ（より具体的には、メス側コネクタ）である。上記一体型装置または本体装置２単体をクレードルに載置した場合、ゲームシステム１は、本体装置２が生成して出力する画像を据置型モニタに表示することができる。また、本実施形態においては、クレードルは、載置された上記一体型装置または本体装置２単体を充電する機能を有する。また、クレードルは、ハブ装置（具体的には、ＵＳＢハブ）の機能を有する。
【0053】
図４は、左コントローラ３の一例を示す六面図である。図４に示すように、左コントローラ３は、ハウジング３１を備える。本実施形態においては、ハウジング３１は、縦長の形状、すなわち、図４における上下方向（図４に示すｚ軸方向）に長い形状である。左コントローラ３は、本体装置２から外された状態において、縦長となる向きで把持されることも可能である。ハウジング３１は、縦長となる向きで把持される場合に片手、特に左手で把持可能な形状および大きさをしている。また、左コントローラ３は、横長となる向きで把持されることも可能である。左コントローラ３が横長となる向きで把持される場合には、両手で把持されるようにしてもよい。
【0054】
左コントローラ３は、方向入力デバイスの一例である左アナログスティック（以下、左スティックと呼ぶ）３２を備える。図４に示すように、左スティック３２は、ハウジング３１の主面に設けられる。左スティック３２は、方向を入力することが可能な方向入力部として用いることができる。ユーザは、左スティック３２を傾倒することによって傾倒方向に応じた方向の入力（および、傾倒した角度に応じた大きさの入力）が可能である。なお、左コントローラ３は、方向入力部として、アナログスティックに代えて、十字キーまたはスライド入力が可能なスライドスティック等を備えるようにしてもよい。また、本実施形態においては、左スティック３２を押下する入力が可能である。
【0055】
左コントローラ３は、各種操作ボタンを備える。左コントローラ３は、ハウジング３１の主面上に４つの操作ボタン３３～３６（具体的には、右方向ボタン３３、下方向ボタン３４、上方向ボタン３５、および左方向ボタン３６）を備える。更に、左コントローラ３は、録画ボタン３７および－（マイナス）ボタン４７を備える。左コントローラ３は、ハ
ウジング３１の側面の左上に第１Ｌボタン３８およびＺＬボタン３９を備える。また、左コントローラ３は、ハウジング３１の側面の、本体装置２に装着される際に装着される側の面に第２Ｌボタン４３および第２Ｒボタン４４を備える。これらの操作ボタンは、本体装置２で実行される各種プログラム（例えば、ＯＳプログラムやアプリケーションプログラム）に応じた指示を行うために用いられる。
ウジング３１の側面の左上に第１Ｌボタン３８およびＺＬボタン３９を備える。また、左コントローラ３は、ハウジング３１の側面の、本体装置２に装着される際に装着される側の面に第２Ｌボタン４３および第２Ｒボタン４４を備える。これらの操作ボタンは、本体装置２で実行される各種プログラム（例えば、ＯＳプログラムやアプリケーションプログラム）に応じた指示を行うために用いられる。
【0056】
また、左コントローラ３は、左コントローラ３が本体装置２と有線通信を行うための端子４２を備える。
【0057】
図５は、右コントローラ４の一例を示す六面図である。図５に示すように、右コントローラ４は、ハウジング５１を備える。本実施形態においては、ハウジング５１は、縦長の形状、すなわち、図５における上下方向（図５に示すｚ軸方向）に長い形状である。右コントローラ４は、本体装置２から外された状態において、縦長となる向きで把持されることも可能である。ハウジング５１は、縦長となる向きで把持される場合に片手、特に右手で把持可能な形状および大きさをしている。また、右コントローラ４は、横長となる向きで把持されることも可能である。右コントローラ４が横長となる向きで把持される場合には、両手で把持されるようにしてもよい。
【0058】
右コントローラ４は、左コントローラ３と同様、方向入力部として右アナログスティック（以下、右スティックと呼ぶ）５２を備える。本実施形態においては、右スティック５２は、左コントローラ３の左スティック３２と同じ構成である。また、右コントローラ４は、アナログスティックに代えて、十字キーまたはスライド入力が可能なスライドスティック等を備えるようにしてもよい。また、右コントローラ４は、左コントローラ３と同様、ハウジング５１の主面上に４つの操作ボタン５３～５６（具体的には、Ａボタン５３、Ｂボタン５４、Ｘボタン５５、およびＹボタン５６）を備える。更に、右コントローラ４は、＋（プラス）ボタン５７およびホームボタン５８を備える。また、右コントローラ４は、ハウジング５１の側面の右上に第１Ｒボタン６０およびＺＲボタン６１を備える。また、右コントローラ４は、左コントローラ３と同様、第２Ｌボタン６５および第２Ｒボタン６６を備える。
【0059】
また、右コントローラ４は、右コントローラ４が本体装置２と有線通信を行うための端子６４を備える。
【0060】
図６は、本体装置２の内部構成の一例を示すブロック図である。本体装置２は、図３に示す構成の他、図６に示す各構成要素８１～９１、９７、および９８を備える。これらの構成要素８１～９１、９７、および９８のいくつかは、電子部品として電子回路基板上に実装されてハウジング１１内に収納されてもよい。
【0061】
本体装置２は、プロセッサ８１を備える。プロセッサ８１は、本体装置２において実行される各種の情報処理を実行する情報処理部であって、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ
Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）のみから構成されてもよいし、ＣＰＵ機能、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）機能等の複数の機能を含むＳｏＣ（Ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ）から構成されてもよい。プロセッサ８１は、記憶部（具体的には、フラッシュメモリ８４等の内部記憶媒体、あるいは、スロット２３に装着される外部記憶媒体等）に記憶される情報処理プログラム（例えば、ゲームプログラム）を実行することによって、各種の情報処理を実行する。
Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）のみから構成されてもよいし、ＣＰＵ機能、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）機能等の複数の機能を含むＳｏＣ（Ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ）から構成されてもよい。プロセッサ８１は、記憶部（具体的には、フラッシュメモリ８４等の内部記憶媒体、あるいは、スロット２３に装着される外部記憶媒体等）に記憶される情報処理プログラム（例えば、ゲームプログラム）を実行することによって、各種の情報処理を実行する。
【0062】
本体装置２は、自身に内蔵される内部記憶媒体の一例として、フラッシュメモリ８４およびＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）８５を備える。フラッシュメモリ８４およびＤＲＡＭ８５は、プロセッサ８１に接続される。フラ
ッシュメモリ８４は、主に、本体装置２に保存される各種のデータ（プログラムであってもよい）を記憶するために用いられるメモリである。ＤＲＡＭ８５は、情報処理において用いられる各種のデータを一時的に記憶するために用いられるメモリである。
ッシュメモリ８４は、主に、本体装置２に保存される各種のデータ（プログラムであってもよい）を記憶するために用いられるメモリである。ＤＲＡＭ８５は、情報処理において用いられる各種のデータを一時的に記憶するために用いられるメモリである。
【0063】
本体装置２は、スロットインターフェース（以下、「Ｉ／Ｆ」と略記する。）９１を備える。スロットＩ／Ｆ９１は、プロセッサ８１に接続される。スロットＩ／Ｆ９１は、スロット２３に接続され、スロット２３に装着された所定の種類の記憶媒体（例えば、専用メモリカード）に対するデータの読み出しおよび書き込みを、プロセッサ８１の指示に応じて行う。
【0064】
プロセッサ８１は、フラッシュメモリ８４およびＤＲＡＭ８５、ならびに上記各記憶媒体との間でデータを適宜読み出したり書き込んだりして、上記の情報処理を実行する。
【0065】
本体装置２は、ネットワーク通信部８２を備える。ネットワーク通信部８２は、プロセッサ８１に接続される。ネットワーク通信部８２は、ネットワークを介して外部の装置と通信（具体的には、無線通信）を行う。本実施形態においては、ネットワーク通信部８２は、第１の通信態様としてＷｉ－Ｆｉの規格に準拠した方式により、無線ＬＡＮに接続して外部装置と通信を行う。また、ネットワーク通信部８２は、第２の通信態様として所定の通信方式（例えば、独自プロトコルによる通信や、赤外線通信）により、同種の他の本体装置２との間で無線通信を行う。なお、上記第２の通信態様による無線通信は、閉ざされたローカルネットワークエリア内に配置された他の本体装置２との間で無線通信可能であり、複数の本体装置２の間で直接通信することによってデータが送受信される、いわゆる「ローカル通信」を可能とする機能を実現する。
【0066】
本体装置２は、コントローラ通信部８３を備える。コントローラ通信部８３は、プロセッサ８１に接続される。コントローラ通信部８３は、左コントローラ３および／または右コントローラ４と無線通信を行う。本体装置２と左コントローラ３および右コントローラ４との通信方式は任意であるが、本実施形態においては、コントローラ通信部８３は、左コントローラ３との間および右コントローラ４との間で、Ｂｌｕｅｔｏｏｔｈ（登録商標）の規格に従った通信を行う。
【0067】
プロセッサ８１は、上述の左側端子１７、右側端子２１、および下側端子２７に接続される。プロセッサ８１は、左コントローラ３と有線通信を行う場合、左側端子１７を介して左コントローラ３へデータを送信するとともに、左側端子１７を介して左コントローラ３から操作データを受信する。また、プロセッサ８１は、右コントローラ４と有線通信を行う場合、右側端子２１を介して右コントローラ４へデータを送信するとともに、右側端子２１を介して右コントローラ４から操作データを受信する。また、プロセッサ８１は、クレードルと通信を行う場合、下側端子２７を介してクレードルへデータを送信する。このように、本実施形態においては、本体装置２は、左コントローラ３および右コントローラ４との間で、それぞれ有線通信と無線通信との両方を行うことができる。また、左コントローラ３および右コントローラ４が本体装置２に装着された一体型装置または本体装置２単体がクレードルに装着された場合、本体装置２は、クレードルを介してデータ（例えば、画像データや音声データ）を据置型モニタ等に出力することができる。
【0068】
ここで、本体装置２は、複数の左コントローラ３と同時に（換言すれば、並行して）通信を行うことができる。また、本体装置２は、複数の右コントローラ４と同時に（換言すれば、並行して）通信を行うことができる。したがって、複数のユーザは、左コントローラ３および右コントローラ４のセットをそれぞれ用いて、本体装置２に対する入力を同時に行うことができる。一例として、第１ユーザが左コントローラ３および右コントローラ４の第１セットを用いて本体装置２に対して入力を行うと同時に、第２ユーザが左コント
ローラ３および右コントローラ４の第２セットを用いて本体装置２に対して入力を行うことが可能となる。
ローラ３および右コントローラ４の第２セットを用いて本体装置２に対して入力を行うことが可能となる。
【0069】
本体装置２は、タッチパネル１３の制御を行う回路であるタッチパネルコントローラ８６を備える。タッチパネルコントローラ８６は、タッチパネル１３とプロセッサ８１との間に接続される。タッチパネルコントローラ８６は、タッチパネル１３からの信号に基づいて、例えばタッチ入力が行われた位置を示すデータを生成して、プロセッサ８１へ出力する。
【0070】
また、ディスプレイ１２は、プロセッサ８１に接続される。プロセッサ８１は、（例えば、上記の情報処理の実行によって）生成した画像および／または外部から取得した画像をディスプレイ１２に表示する。
【0071】
本体装置２は、コーデック回路８７およびスピーカ（具体的には、左スピーカおよび右スピーカ）８８を備える。コーデック回路８７は、スピーカ８８および音声入出力端子２５に接続されるとともに、プロセッサ８１に接続される。コーデック回路８７は、スピーカ８８および音声入出力端子２５に対する音声データの入出力を制御する回路である。
【0072】
本体装置２は、電力制御部９７およびバッテリ９８を備える。電力制御部９７は、バッテリ９８およびプロセッサ８１に接続される。また、図示しないが、電力制御部９７は、本体装置２の各部（具体的には、バッテリ９８の電力の給電を受ける各部、左側端子１７、および右側端子２１）に接続される。電力制御部９７は、プロセッサ８１からの指令に基づいて、バッテリ９８から上記各部への電力供給を制御する。
【0073】
また、バッテリ９８は、下側端子２７に接続される。外部の充電装置（例えば、クレードル）が下側端子２７に接続され、下側端子２７を介して本体装置２に電力が供給される場合、供給された電力がバッテリ９８に充電される。
【0074】
【0075】
左コントローラ３は、本体装置２との間で通信を行う通信制御部１０１を備える。図７に示すように、通信制御部１０１は、端子４２を含む各構成要素に接続される。本実施形態においては、通信制御部１０１は、端子４２を介した有線通信と、端子４２を介さない無線通信との両方で本体装置２と通信を行うことが可能である。通信制御部１０１は、左コントローラ３が本体装置２に対して行う通信方法を制御する。すなわち、左コントローラ３が本体装置２に装着されている場合、通信制御部１０１は、端子４２を介して本体装置２と通信を行う。また、左コントローラ３が本体装置２から外されている場合、通信制御部１０１は、本体装置２（具体的には、コントローラ通信部８３）との間で無線通信を行う。コントローラ通信部８３と通信制御部１０１との間の無線通信は、例えばＢｌｕｅｔｏｏｔｈ（登録商標）の規格に従って行われる。
【0076】
また、左コントローラ３は、例えばフラッシュメモリ等のメモリ１０２を備える。通信制御部１０１は、例えばマイコン（マイクロプロセッサとも言う）で構成され、メモリ１０２に記憶されるファームウェアを実行することによって各種の処理を実行する。
【0077】
左コントローラ３は、各ボタン１０３（具体的には、ボタン３３～３９、４３、４４、および４７）を備える。また、左コントローラ３は、左スティック３２を備える。各ボタン１０３および左スティック３２は、自身に対して行われた操作に関する情報を、適宜の
タイミングで繰り返し通信制御部１０１へ出力する。
タイミングで繰り返し通信制御部１０１へ出力する。
【0078】
左コントローラ３は、慣性センサを備える。具体的には、左コントローラ３は、加速度センサ１０４を備える。また、左コントローラ３は、角速度センサ１０５を備える。本実施形態においては、加速度センサ１０４は、所定の３軸（例えば、図４に示すｘｙｚ軸）方向に沿った加速度の大きさを検出する。なお、加速度センサ１０４は、１軸方向あるいは２軸方向の加速度を検出するものであってもよい。本実施形態においては、角速度センサ１０５は、所定の３軸（例えば、図４に示すｘｙｚ軸）回りの角速度を検出する。なお、角速度センサ１０５は、１軸回りあるいは２軸回りの角速度を検出するものであってもよい。加速度センサ１０４および角速度センサ１０５は、それぞれ通信制御部１０１に接続される。そして、加速度センサ１０４および角速度センサ１０５の検出結果は、適宜のタイミングで繰り返し通信制御部１０１へ出力される。
【0079】
通信制御部１０１は、各入力部（具体的には、各ボタン１０３、左スティック３２、各センサ１０４および１０５）から、入力に関する情報（具体的には、操作に関する情報、またはセンサによる検出結果）を取得する。通信制御部１０１は、取得した情報（または取得した情報に所定の加工を行った情報）を含む操作データを本体装置２へ送信する。なお、操作データは、所定時間に１回の割合で繰り返し送信される。なお、入力に関する情報が本体装置２へ送信される間隔は、各入力部について同じであってもよいし、同じでなくてもよい。
【0080】
上記操作データが本体装置２へ送信されることによって、本体装置２は、左コントローラ３に対して行われた入力を得ることができる。すなわち、本体装置２は、各ボタン１０３および左スティック３２に対する操作を、操作データに基づいて判別することができる。また、本体装置２は、左コントローラ３の動きおよび／または姿勢に関する情報を、操作データ（具体的には、加速度センサ１０４および角速度センサ１０５の検出結果）に基づいて算出することができる。
【0081】
左コントローラ３は、電力供給部１０８を備える。本実施形態において、電力供給部１０８は、バッテリおよび電力制御回路を有する。図示しないが、電力制御回路は、バッテリに接続されるとともに、左コントローラ３の各部（具体的には、バッテリの電力の給電を受ける各部）に接続される。
【0082】
図７に示すように、右コントローラ４は、本体装置２との間で通信を行う通信制御部１１１を備える。また、右コントローラ４は、通信制御部１１１に接続されるメモリ１１２を備える。通信制御部１１１は、端子６４を含む各構成要素に接続される。通信制御部１１１およびメモリ１１２は、左コントローラ３の通信制御部１０１およびメモリ１０２と同様の機能を有する。したがって、通信制御部１１１は、端子６４を介した有線通信と、端子６４を介さない無線通信（具体的には、Ｂｌｕｅｔｏｏｔｈ（登録商標）の規格に従った通信）との両方で本体装置２と通信を行うことが可能であり、右コントローラ４が本体装置２に対して行う通信方法を制御する。
【0083】
右コントローラ４は、左コントローラ３の各入力部と同様の各入力部を備える。具体的には、各ボタン１１３、右スティック５２、慣性センサ（加速度センサ１１４および角速度センサ１１５）を備える。これらの各入力部については、左コントローラ３の各入力部と同様の機能を有し、同様に動作する。
【0084】
右コントローラ４は、電力供給部１１８を備える。電力供給部１１８は、左コントローラ３の電力供給部１０８と同様の機能を有し、同様に動作する。
【0085】
［本実施形態におけるゲーム処理の概要］
次に、本実施形態に係るゲームシステム１で実行されるゲーム処理の動作概要を説明する。上記のように、上記ゲームシステム１では、本体装置２は、左コントローラ３および右コントローラ４がそれぞれ着脱可能な構成となっている。本体装置２に左コントローラ３および右コントローラ４を装着した状態でゲームを遊ぶ場合は、ゲーム画像はディスプレイ１２に出力される。また、左コントローラ３および右コントローラ４をそれぞれ外した状態の本体装置２単体がクレードルに装着された場合は、本体装置２が、クレードルを介してゲーム画像を据置型モニタ等に出力することもできる。本実施形態では、後者の態様でゲームプレイを行う場合を例に説明する。具体的には、左コントローラ３および右コントローラ４をそれぞれ外した状態の本体装置２単体がクレードルに装着され、本体装置２が、クレードルを介してゲーム画像等を据置型モニタ等に出力する態様である。また、以下の説明では、左コントローラ３、または、右コントローラ４のことを単にコントローラを呼ぶこともある。
次に、本実施形態に係るゲームシステム１で実行されるゲーム処理の動作概要を説明する。上記のように、上記ゲームシステム１では、本体装置２は、左コントローラ３および右コントローラ４がそれぞれ着脱可能な構成となっている。本体装置２に左コントローラ３および右コントローラ４を装着した状態でゲームを遊ぶ場合は、ゲーム画像はディスプレイ１２に出力される。また、左コントローラ３および右コントローラ４をそれぞれ外した状態の本体装置２単体がクレードルに装着された場合は、本体装置２が、クレードルを介してゲーム画像を据置型モニタ等に出力することもできる。本実施形態では、後者の態様でゲームプレイを行う場合を例に説明する。具体的には、左コントローラ３および右コントローラ４をそれぞれ外した状態の本体装置２単体がクレードルに装着され、本体装置２が、クレードルを介してゲーム画像等を据置型モニタ等に出力する態様である。また、以下の説明では、左コントローラ３、または、右コントローラ４のことを単にコントローラを呼ぶこともある。
【0086】
また、以下の説明では、特に断りがない限り、右利きのユーザが、右手に右コントローラ４を把持している態様で、ゲームをプレイする場合を想定する。なお、ユーザが左利きの場合は、右コントローラ４の代わりに左コントローラ３を用いる態様で、以下に説明するような処理が行われてもよい。
【0087】
［想定するゲームについて］
本実施形態で想定するゲームは、仮想３次元空間内において対戦するバドミントンゲームである。また、本実施形態では、一例として、シングルスの試合で、対ＣＰＵ戦を行う場合を例として説明する。もちろん、他のプレイヤが対戦相手を操作する、プレイヤ同士の対戦形式でもよい。また、プレイヤ同士の対戦の場合、１台のゲーム装置を用いて２人のプレイヤで対戦プレイしてもよいし、２台のゲーム装置をネットワーク経由で接続した通信対戦プレイであってもよい。また、シングルスではなくダブルスの試合であってもよい。
本実施形態で想定するゲームは、仮想３次元空間内において対戦するバドミントンゲームである。また、本実施形態では、一例として、シングルスの試合で、対ＣＰＵ戦を行う場合を例として説明する。もちろん、他のプレイヤが対戦相手を操作する、プレイヤ同士の対戦形式でもよい。また、プレイヤ同士の対戦の場合、１台のゲーム装置を用いて２人のプレイヤで対戦プレイしてもよいし、２台のゲーム装置をネットワーク経由で接続した通信対戦プレイであってもよい。また、シングルスではなくダブルスの試合であってもよい。
【0088】
図８に、本実施形態に係るバドミントンゲームのゲーム画像の一例を示す。図８で示すゲーム画像は、３次元仮想空間（仮想コート）を仮想カメラで撮像した画像である。当該ゲーム画像（仮想コート内）には、２体の選手キャラクタが表示されている。仮想コートの手前側のコート（自側コート）には、ユーザの操作対象であるプレイヤキャラクタオブジェクト（以下、プレイヤキャラと呼ぶ）ＰＣが配置されている。また、ネット越しの奥行き側のコート（相手側コート）には、対戦相手となる選手キャラクタ（以下、相手キャラクタと呼ぶ）ＮＰＣが配置されている。また、各選手キャラクタは、ラケットオブジェクト（以下、単にラケット）を右手に持っている。その他、ゲーム画像には、移動オブジェクトであるシャトルオブジェクト（以下、単にシャトルと呼ぶ）２０３も表示されている。
【0089】
本実施形態に係るバドミントンゲームの基本的な仕様・操作方法について説明する。まず、本ゲームでは、ユーザは、ラケットに見立てたコントローラを振る（振り入力を行う）ことで、プレイヤキャラＰＣに、ラケットを振らせることができる。ここで、本実施形態では、プレイヤキャラＰＣに当該ラケットを振らせる動作（以下、ラケットスイングアニメーション）として、基本的には、次の３種類の動作のいずれかを行わせる。すなわち、オーバーヘッドストローク（以下、単にオーバーと呼ぶ）、フォアハンドのアンダーハンドストローク（以下、単にアンダーフォアと呼ぶ）、バックハンドのアンダーハンドストローク（以下、単にアンダーバックと呼ぶ）のいずれかのラケットスイングアニメーションを行わせる。
【0090】
図９～図１５に、プレイヤキャラＰＣが行う上記３種類のラケットスイングアニメーシ
ョンの動作例を示す。なお、いずれも、ユーザが右利きである場合の例である。図９～図１１は、プレイヤキャラＰＣが行うオーバーのラケットスイングアニメーションの一例である。これらの図で示されるように、プレイヤキャラＰＣは、ラケットを上から下方向に向けて振り下ろす動きを行う。このような動きを行わせるために、ユーザは、コントローラ（右利きの例示であるため、この場合は右コントローラ４）を上から下に振り下ろすような振り入力を行う。つまり、プレイヤキャラＰＣにオーバーのラケットスイングアニメーションを行わせるために、ユーザは、コントローラを上げた姿勢を取ってから（図９の状態に対応）、ユーザから見て下方向に向けてコントローラを振る（図１０～図１１の状態に対応）という振り入力（振り下ろし）が要求される。
ョンの動作例を示す。なお、いずれも、ユーザが右利きである場合の例である。図９～図１１は、プレイヤキャラＰＣが行うオーバーのラケットスイングアニメーションの一例である。これらの図で示されるように、プレイヤキャラＰＣは、ラケットを上から下方向に向けて振り下ろす動きを行う。このような動きを行わせるために、ユーザは、コントローラ（右利きの例示であるため、この場合は右コントローラ４）を上から下に振り下ろすような振り入力を行う。つまり、プレイヤキャラＰＣにオーバーのラケットスイングアニメーションを行わせるために、ユーザは、コントローラを上げた姿勢を取ってから（図９の状態に対応）、ユーザから見て下方向に向けてコントローラを振る（図１０～図１１の状態に対応）という振り入力（振り下ろし）が要求される。
【0091】
図１２～図１３は、プレイヤキャラＰＣが行うアンダーフォアのラケットスイングアニメーションの一例である。これらの図で示されるように、プレイヤキャラＰＣは、ラケットを（プレイヤキャラＰＣの右側から）左上に向けて振り上げるような動きを行う。このようなアンダーフォアのラケットスイングアニメーションをプレイヤキャラＰＣに行わせるために、ユーザは、コントローラを自身の右側に構えてから（図１２の状態に対応）、ユーザから見て左上方向に向けてコントローラを振る（図１３の状態に対応）という振り入力（左上方向への振り上げ）が要求される。
【0092】
図１４～図１５は、プレイヤキャラＰＣが行うアンダーバックのラケットスイングアニメーションの一例である。これらの図で示されるように、プレイヤキャラＰＣは、ラケットを（プレイヤキャラＰＣの左側から）右上に向けて振り上げるような動きを行う。このようなアンダーバックのラケットスイングアニメーションをプレイヤキャラＰＣに行わせるために、ユーザは、コントローラを自身の左側に構えてから（図１４の状態に対応）、ユーザから見て右上方向に向けてコントローラを振る（図１５の状態に対応）という振り入力（右上方向への振り上げ）が要求される。
【0093】
次に、プレイヤキャラＰＣの移動について説明する。本ゲームでは、プレイヤキャラＰＣの移動はオートで制御される。具体的には、シャトル２０３の移動軌道（移動方向）に応じて、シャトル２０３を打ち返せるような位置に向けてプレイヤキャラＰＣは自側コート内で自動的に移動する（以下、このような移動のことをオート移動と呼ぶ）。例えば、プレイヤキャラＰＣが自側コート内の左側に位置する場合に、シャトル２０３が自側コート内の右側に向けて移動する場合を想定する。この場合は、シャトル２０３を打ち返せるような位置（例えば、シャトル２０３の軌道の左側の任意の位置）が算出される。そして、算出された位置（以下、オート移動先）に向けてプレイヤキャラＰＣがオート移動を行うように制御される。オート移動先を算出する際には、プレイヤキャラＰＣに対して設定される移動速度、シャトル２０３の移動方向や移動速度、シャトル２０３が移動を開始する時点におけるプレイヤキャラＰＣの位置などのパラメータが用いられてよい。なお、プレイヤキャラＰＣのオート移動先を算出する際、シャトル２０３の軌道の左右のどちら側をオート移動先と指定するかに関し、自側コートのｘ軸における中央部分に近い位置が優先的にオート移動先となるように算出してよい。例えば、シャトル２０３が移動を開始する時点におけるプレイヤキャラＰＣの位置が、自側コートの右端付近に位置する場合であって、シャトル２０３がプレイヤキャラＰＣの現在位置の左側を通過する軌道で移動する場合には、シャトル２０３の軌道の左側の任意の位置をオート移動先として算出してもよい。これにより、なるべくプレイヤキャラＰＣがコート中央付近に位置するようにプレイヤキャラＰＣの位置を制御することができる。なお、シャトル２０３の移動する軌道から見てコート中央側の位置に移動する時間がない場合には、代わりに、シャトル２０３の移動する軌道から見てコート端側の位置をオート移動先として算出してもよい。
【0094】
このように、本実施形態におけるバドミントンゲームは、プレイヤキャラＰＣの移動はオート移動に任せておき、ユーザは、コントローラを振る操作に集中すればよいというゲ
ームとなっている。すなわち、シャトル２０３が来たタイミングを見計らって、上記３種類の振り方（振り方向）の中から適切な振り方（シャトル２０３を打ち返すことが可能な振り方向）をユーザに判断させてコントローラを振らせる、というゲームとなっている。
ームとなっている。すなわち、シャトル２０３が来たタイミングを見計らって、上記３種類の振り方（振り方向）の中から適切な振り方（シャトル２０３を打ち返すことが可能な振り方向）をユーザに判断させてコントローラを振らせる、というゲームとなっている。
【0095】
次に、本実施形態における振り入力の検出手法に関して説明する。本実施形態ではコントローラは、上述の方法で本体装置２に対し、慣性センサの出力を含む操作データを送信する。そして、操作データが振り入力に関する条件を満たす場合には、コントローラに対して振り入力が行われたものと判定する。振り入力に関する条件は適宜設定されてよいが、例えば本実施形態では、操作データが、慣性センサの所定軸に係る加速度の大きさが閾値を超えている場合に、コントローラに対する振り入力が行われたものと判定してもよい。そして、コントローラに対する振り入力が行われたものと判定された場合、本体装置２は、以下で説明するような処理によって、どのような振り方が行われたか、すなわち、振り方向がどの方向であるかを判定する処理を行う。
【0096】
次に、本実施形態のバドミントンゲームにおいて行われる、コントローラの振り方（振り方向）の判定に関する処理の概要について説明する。図１６は、本実施形態における振り方向の判定手法とその結果を用いるバドミントンゲーム処理の概要を示す図である。本実施形態では、ユーザが行った振り入力を判定するために、ディープラーニングを用いて生成された学習済みモデルを利用する。図１６の上半分は、学習済みモデルの生成過程を示す。また、下半分は、当該学習済みモデルを用いた本実施形態に係るバドミントンゲーム処理の概要を示す。
【0097】
［学習処理について］
まず、上記学習済みモデルの生成（学習処理）に関して簡単に説明する。本実施形態では、上記コントローラの振り入力によって得られた生データと、振り方を示すラベルとをセットにしたデータセット（以下、教師データと呼ぶ）を複数用意し、学習用データセットとしている。具体的には、生データとして、１回分の振り入力が行われている期間中において漸次的に取得された加速度データおよび角速度データと、コントローラの姿勢データとからなるデータセットを用いる（なお、姿勢データは加速度・角速度に基づき算出される）。そして、それぞれの生データに対して、そのときの振り方を示すラベルをつける。ラベルとしては、上記のようなオーバー（下方向への振り下ろし）、アンダーフォア（左上方向への振り上げ）、アンダーバック（右上方向への振り上げ）の３種類の振り方のいずれかを示すラベルが用いられる。また、各振り方について（一例として）５０００件程度の教師データが用意されている。そして、教師データの集合からなる上記学習用データセットをディープラーニングにかけることで、学習済みモデルが生成される。当該学習済みモデルは、例えば、上記ディープラーニングによって調整された学習済みパラメータが組み込まれた推論プログラムであってもよい。
まず、上記学習済みモデルの生成（学習処理）に関して簡単に説明する。本実施形態では、上記コントローラの振り入力によって得られた生データと、振り方を示すラベルとをセットにしたデータセット（以下、教師データと呼ぶ）を複数用意し、学習用データセットとしている。具体的には、生データとして、１回分の振り入力が行われている期間中において漸次的に取得された加速度データおよび角速度データと、コントローラの姿勢データとからなるデータセットを用いる（なお、姿勢データは加速度・角速度に基づき算出される）。そして、それぞれの生データに対して、そのときの振り方を示すラベルをつける。ラベルとしては、上記のようなオーバー（下方向への振り下ろし）、アンダーフォア（左上方向への振り上げ）、アンダーバック（右上方向への振り上げ）の３種類の振り方のいずれかを示すラベルが用いられる。また、各振り方について（一例として）５０００件程度の教師データが用意されている。そして、教師データの集合からなる上記学習用データセットをディープラーニングにかけることで、学習済みモデルが生成される。当該学習済みモデルは、例えば、上記ディープラーニングによって調整された学習済みパラメータが組み込まれた推論プログラムであってもよい。
【0098】
次に、上記学習済みモデルを用いた本実施形態のバドミントンゲーム処理の概要を簡単に説明する。
【0099】
［類似度の算出］
本ゲーム処理では、まず、ユーザの１回分の振り入力に係る振り入力データと、上記３種の振り方に関する学習済みモデルとを用いて、類似度が算出される。当該振り入力データには、操作データ（加速度・角速度データ）および、操作データから算出されるコントローラの姿勢データが含まれる。当該振り入力データを上記学習済みモデルに入力することで、学習済みモデルからの出力結果として、上記３種類の振り方それぞれについての類似度が算出される（推論処理）。本実施形態では、当該類似度の値の一例として、－５０～＋５０の範囲内の値で算出される例で説明する。当該値は、０を基準として、＋の値が高いほど類似度が高く、－の値が高いほど類似度が低いことを示す。例えば、ある振り入
力データを学習済みモデルへ入力すると、「オーバー：＋１０、アンダーフォア：－１０、アンダーバック：－２０」のような内容が学習済みモデルから出力される。
本ゲーム処理では、まず、ユーザの１回分の振り入力に係る振り入力データと、上記３種の振り方に関する学習済みモデルとを用いて、類似度が算出される。当該振り入力データには、操作データ（加速度・角速度データ）および、操作データから算出されるコントローラの姿勢データが含まれる。当該振り入力データを上記学習済みモデルに入力することで、学習済みモデルからの出力結果として、上記３種類の振り方それぞれについての類似度が算出される（推論処理）。本実施形態では、当該類似度の値の一例として、－５０～＋５０の範囲内の値で算出される例で説明する。当該値は、０を基準として、＋の値が高いほど類似度が高く、－の値が高いほど類似度が低いことを示す。例えば、ある振り入
力データを学習済みモデルへ入力すると、「オーバー：＋１０、アンダーフォア：－１０、アンダーバック：－２０」のような内容が学習済みモデルから出力される。
【0100】
ここで、類似度の算出（類似性の判定）について補足する。上記のように、本実施形態では、教師データとして、振り入力が行われている期間中において漸次的に取得された加速度データおよび角速度データと、コントローラの姿勢データとを用いている。そのため、本実施形態では、振り入力が行われている期間中における加速度、角速度、コントローラの姿勢の変化の推移に基づいて、類似度を算出するものといえる。つまり、ユーザの振り入力の開始から終了までの期間において、加速度、角速度、コントローラの姿勢からなるデータセットが、所定の単位時間（例えば１フレーム）毎に得られる。そして、この期間中に得られたこれらのデータセットと、（これと同様のデータ形式が用いられている）学習用データセットとの類似性が判定されることになる。また、単一のフレームに係るデータセットの類似性ではなく、振り入力の開始から終了までの複数フレームのそれぞれのデータセットを学習用データセットとの類似性を判定している。
【0101】
本実施形態における類似性判定手法の概念的な一例として、コントローラの加速度・角速度に基づいて算出される、所定の座標系におけるコントローラの座標の推移を示す値に着目した例を挙げる。本実施形態においては、コントローラが基準姿勢にある時に設定される３次元座標系におけるコントローラの座標のうち、コントローラの振り始めから振り終わりまでのｘｙ軸における座標の変化に着目する。図１７～１９は、上記３種それぞれの振り方に係る、所定の座標系におけるコントローラの座標の推移の一例を示した波形（グラフ）である。１回分の振り入力に係る上記振り入力データ（に含まれる姿勢データ）に基づき、所定の座標系におけるｘ軸、ｙ軸についてのコントローラの座標の推移として、このような波形が導出され得る。図１７は、オーバーの場合の波形を示し、図１８は、アンダーフォアの場合の波形を示し、図１９は、アンダーバックの場合の波形を示す。各波形ともに、横軸が所定の座標系におけるｘ軸に対応し、縦軸がｙ軸に対応している。振り動作には個人差があり、図１７～１９で示すコントローラの所定の座標軸における座標の変化は一例であるが、このように、振り方の違いによって得られる値には差があり、これらから導出され得る波形もそれぞれ異なるものとなることが示されている。
【0102】
この他、図示は省略するが、所定の座標系におけるコントローラのｚ軸における座標についても、その推移を示す値が導出されるため、類似性判定においてはそちらの値を用いてもよい。また、他の例として、所定の座標系におけるコントローラの座標を示す値ではなく、加速度や角速度の変化についても各軸毎にその変化の推移を示す値が導出され得るため、類似性判定においてこのような値を用いてもよい。このような値が、学習用データセット（各教師データ）、振り入力データのそれぞれに含まれている。本実施形態においては、振り方の違いによって得られる値に差があることを利用して、コントローラの振り方を判定している。本実施例において用いられる学習用データセット（各教師データ）は、事前にコントローラを実際に振ることで得られた生データに対し、振り方向を示すラベルを付すことで用意されたものである。そして、このようにして用意された学習用データセットを用いて生成された学習済みモデルに対し、実際のゲーム中におけるユーザの振り操作に基づく振り入力データを入力することで、上記３種の振り方それぞれと、今回の振り操作との類似度を算出し、出力する。そして、最も類似度が高いとされる振り方に対して今回の振り操作が行われたものと判定するような処理が行われている。
【0103】
なお、本実施形態では、教師データとして、加速度、角速度、および（コントローラの）姿勢の各データを用いる例を示すが、他の実施形態では、姿勢データについては教師データに含めないようにしてもよい。つまり、類似性の判定に姿勢データは用いずに、加速度・角速度だけを用いるようにしてもよい。但し、本実施形態のように姿勢データを類似性の判定に用いるようにすることで、判定精度の向上が期待できる。
【0104】
［ゲーム処理で用いる振り方（振り方向）の判定］
上記のように３種の振り方それぞれの類似度が得られれば、次に、これら３つの類似度の中から、類似度が所定の閾値（例えば＋１）以上のものを選択することで、ユーザの振り入力に係る振り方を判定する。なお、類似度が当該所定の閾値以上である振り方が２つ以上ある場合は、その中から最も高い類似度の振り方が選択される。そして、３種の振り方のいずれの振り方であるかが判定できれば、各振り方に対応する振り方向にコントローラが振られたとものして扱うことができる。つまり、この３種の振り方の中から、最も高い類似度の振り方が行われたものと判定して、以降のゲーム処理が行われる。
上記のように３種の振り方それぞれの類似度が得られれば、次に、これら３つの類似度の中から、類似度が所定の閾値（例えば＋１）以上のものを選択することで、ユーザの振り入力に係る振り方を判定する。なお、類似度が当該所定の閾値以上である振り方が２つ以上ある場合は、その中から最も高い類似度の振り方が選択される。そして、３種の振り方のいずれの振り方であるかが判定できれば、各振り方に対応する振り方向にコントローラが振られたとものして扱うことができる。つまり、この３種の振り方の中から、最も高い類似度の振り方が行われたものと判定して、以降のゲーム処理が行われる。
【0105】
［振り方に基づいたゲーム処理］
次に、上記判定された振り方（振り方向）に基づいたゲーム処理が行われる。具体的には、当該振り方と、プレイヤキャラＰＣとシャトル２０３との位置関係（換言すれば、コントローラを振ったタイミング）とに基づいて、シャトル２０３を打ち返すことが出来るか否かの判定が行われる。そして、打ち返し可能と判定されれば、振り方（振り方向）に応じたラケットスイングアニメーションを再生すると共に、シャトル２０３を相手方コートに打ち返す（移動させる）処理が行われることになる。
次に、上記判定された振り方（振り方向）に基づいたゲーム処理が行われる。具体的には、当該振り方と、プレイヤキャラＰＣとシャトル２０３との位置関係（換言すれば、コントローラを振ったタイミング）とに基づいて、シャトル２０３を打ち返すことが出来るか否かの判定が行われる。そして、打ち返し可能と判定されれば、振り方（振り方向）に応じたラケットスイングアニメーションを再生すると共に、シャトル２０３を相手方コートに打ち返す（移動させる）処理が行われることになる。
【0106】
ここで、打ち返しが可能となるプレイヤキャラＰＣとシャトル２０３との位置関係に関して補足説明する。本実施形態では、上記３種類の振り方のそれぞれに応じて、シャトル２０３の打ち返しが可能な３次元領域が予め定められている。以下の説明では、オーバーによる打ち返し（オーバーショット）が可能な領域のことを「オーバー可能領域」、アンダーフォアによる打ち返し（アンダーフォアショット）が可能な領域のことを「アンダーフォア可能領域」、アンダーバックによる打ち返し（アンダーバックショット）が可能な領域のことを「アンダーバック可能領域」と呼ぶ。また、これら３つの領域を総称して、「ショット可能領域」と呼ぶこともある。
【0107】
図２０に、上記ショット可能領域の設定の一例を示す。ショット可能領域は、プレイヤキャラＰＣの前方近傍の位置に設けられている。各領域についてみると、まず、オーバー可能領域は、プレイヤキャラＰＣの頭部前方に位置し上方向に延びるような縦長形状の領域である。アンダーフォア可能領域は、プレイヤキャラＰＣから見て、概ね胸の位置から下であって、プレイヤキャラＰＣの中心から右側に延びるような横長形状の領域である。アンダーバック可能領域は、プレイヤキャラＰＣから見て、概ね胸の位置から下であって、プレイヤキャラＰＣの中心から左側に延びるような横長形状の領域である。そして、これらのいずれかの領域内にシャトル２０３があるタイミングで、各領域に対応した振り方を行えば、シャトル２０３を打ち返すことができる。なお、各領域の形状・位置、大きさはあくまで一例であり、例えば領域の形状は球形の領域であってもよい。
【0108】
［ミスショットについて］
ここで、本実施形態では、上記ショット可能領域内にシャトル２０３がないときに振り入力を行うと、原則として、「空振り」として扱われる。すなわち、上記学習済みモデルを用いて判別された振り方に対応するラケットスイングアニメーションが再生されるのみとなる。但し、例外として、本実施形態では、所定の条件下では「ミスショット」を発生させる処理も行っている。具体的には、アンダーフォアまたはアンダーバックによってシャトル２０３を打ち返すべき状況において、オーバーに対応する振り方が行われた場合は、「ミスショット」となる。アンダーフォアまたはアンダーバックによってシャトル２０３を打ち返すべき状況とは、上記アンダーフォア可能領域またはアンダーバック可能領域内にシャトル２０３があるタイミングのことである。この場合は、「ミスショット」のラケットスイングアニメーションが再生されて、シャトル２０３を（一応は）打ち返すことができる。但し、ミスショットで打ち返した場合は、打ち返したシャトル２０３の移動速
度を極端に低下させる（勢いの弱い動きとする）ような調整も行われる。つまり、ミスショットで打ち返した場合、シャトル２０３の勢いが落ちている状態となるため、相手にとっては打ち返すタイミングが測りやすい状況（自分にとっては不利な状況）になるものといえる。なお、他の例では、上記ショット可能領域内にシャトル２０３がないときに振り入力が行われた場合、判別された振り方に対応するラケットスイングアニメーションの再生は行わなくてもよい。
ここで、本実施形態では、上記ショット可能領域内にシャトル２０３がないときに振り入力を行うと、原則として、「空振り」として扱われる。すなわち、上記学習済みモデルを用いて判別された振り方に対応するラケットスイングアニメーションが再生されるのみとなる。但し、例外として、本実施形態では、所定の条件下では「ミスショット」を発生させる処理も行っている。具体的には、アンダーフォアまたはアンダーバックによってシャトル２０３を打ち返すべき状況において、オーバーに対応する振り方が行われた場合は、「ミスショット」となる。アンダーフォアまたはアンダーバックによってシャトル２０３を打ち返すべき状況とは、上記アンダーフォア可能領域またはアンダーバック可能領域内にシャトル２０３があるタイミングのことである。この場合は、「ミスショット」のラケットスイングアニメーションが再生されて、シャトル２０３を（一応は）打ち返すことができる。但し、ミスショットで打ち返した場合は、打ち返したシャトル２０３の移動速
度を極端に低下させる（勢いの弱い動きとする）ような調整も行われる。つまり、ミスショットで打ち返した場合、シャトル２０３の勢いが落ちている状態となるため、相手にとっては打ち返すタイミングが測りやすい状況（自分にとっては不利な状況）になるものといえる。なお、他の例では、上記ショット可能領域内にシャトル２０３がないときに振り入力が行われた場合、判別された振り方に対応するラケットスイングアニメーションの再生は行わなくてもよい。
【0109】
なお、オーバーによってシャトル２０３を打ち返すべき状況において、アンダーフォアまたはアンダーバックに対応する振り方が行われた場合は、「空振り」となる。
【0110】
［スマッシュについて］
更に、本実施形態では、オーバー可能領域内にシャトル２０３がある場合であって、更にシャトルの高さが一定以上の高さにあるときにオーバーに対応する振り方が行われた場合、「スマッシュ」を発生させる処理も行っている。例えば、上記図２０で示されるように、オーバー可能領域の略上半分は、「スマッシュ可能領域」としても定義される。そして、シャトル２０３が、当該「スマッシュ可能領域」にあるときに、オーバーに対応する振り方が行われると、「スマッシュ」が発生する。この場合、オーバーのスイングアニメーションとは少し異なるスマッシュ専用のラケットスイングアニメーションが再生されると共に、打ち返されたシャトル２０３の移動速度も、オーバーで打ち返した場合よりも速い速度で移動するように制御される。
更に、本実施形態では、オーバー可能領域内にシャトル２０３がある場合であって、更にシャトルの高さが一定以上の高さにあるときにオーバーに対応する振り方が行われた場合、「スマッシュ」を発生させる処理も行っている。例えば、上記図２０で示されるように、オーバー可能領域の略上半分は、「スマッシュ可能領域」としても定義される。そして、シャトル２０３が、当該「スマッシュ可能領域」にあるときに、オーバーに対応する振り方が行われると、「スマッシュ」が発生する。この場合、オーバーのスイングアニメーションとは少し異なるスマッシュ専用のラケットスイングアニメーションが再生されると共に、打ち返されたシャトル２０３の移動速度も、オーバーで打ち返した場合よりも速い速度で移動するように制御される。
【0111】
［地面近くでの減速調整について］
また、本実施形態では、上記のような振り判定に係る処理に加えて、シャトル２０３が仮想コートの地面に近い位置にある場合（地面から所定閾値以下の高さにある場合）、地面からの高さに応じた割合でシャトル２０３の移動速度を減速させる処理も行っている。例えば、仮想空間における高さで、地面から４０ｃｍ以下の高さにシャトル２０３がある場合に、４０ｃｍ未満３０ｃｍ以上の範囲内ではシャトル２０３の移動速度を本来の９０％に低下させ、３０ｃｍ未満２０ｃｍ以上の範囲内ではシャトル２０３の移動速度を本来の７５％に低下させ、２０ｃｍ未満１０ｃｍ以上の範囲内ではシャトル２０３の移動速度を本来の６０％に低下させ、１０ｃｍ未満ではシャトル２０３の移動速度を本来の５０％に低下させる、というような制御も行っている。このように、シャトル２０３がある程度地面に近いときに移動速度を一時的に低下させることで、特にアンダーフォアまたはアンダーバックに対応する振り入力を行うための猶予をユーザに与えることができる。また、本実施形態では、バドミントンゲームの処理を行っているが、現実におけるバドミントンのシャトルは、その形状から、コルクの部分に重心が偏るものといえる。そのため、ゲーム処理においてシャトル２０３の動きを物理演算で制御するような場合、地面に近づくほどシャトル２０３の落下速度（加速度）が高まり、ユーザにとってタイミングが取りづらくなる可能性がある。その結果、ユーザが行うアンダーフォアやアンダーバックに係る振り入力が間に合わない可能性も高まる。そのため、上記のような減速調整を行うことで、ユーザに振り入力を行わせるための時間的猶予を与えるようにでき、特にバドミントンゲームにおいて有用な制御でもある。
また、本実施形態では、上記のような振り判定に係る処理に加えて、シャトル２０３が仮想コートの地面に近い位置にある場合（地面から所定閾値以下の高さにある場合）、地面からの高さに応じた割合でシャトル２０３の移動速度を減速させる処理も行っている。例えば、仮想空間における高さで、地面から４０ｃｍ以下の高さにシャトル２０３がある場合に、４０ｃｍ未満３０ｃｍ以上の範囲内ではシャトル２０３の移動速度を本来の９０％に低下させ、３０ｃｍ未満２０ｃｍ以上の範囲内ではシャトル２０３の移動速度を本来の７５％に低下させ、２０ｃｍ未満１０ｃｍ以上の範囲内ではシャトル２０３の移動速度を本来の６０％に低下させ、１０ｃｍ未満ではシャトル２０３の移動速度を本来の５０％に低下させる、というような制御も行っている。このように、シャトル２０３がある程度地面に近いときに移動速度を一時的に低下させることで、特にアンダーフォアまたはアンダーバックに対応する振り入力を行うための猶予をユーザに与えることができる。また、本実施形態では、バドミントンゲームの処理を行っているが、現実におけるバドミントンのシャトルは、その形状から、コルクの部分に重心が偏るものといえる。そのため、ゲーム処理においてシャトル２０３の動きを物理演算で制御するような場合、地面に近づくほどシャトル２０３の落下速度（加速度）が高まり、ユーザにとってタイミングが取りづらくなる可能性がある。その結果、ユーザが行うアンダーフォアやアンダーバックに係る振り入力が間に合わない可能性も高まる。そのため、上記のような減速調整を行うことで、ユーザに振り入力を行わせるための時間的猶予を与えるようにでき、特にバドミントンゲームにおいて有用な制御でもある。
【0112】
【0113】
［使用データについて］
まず、本バドミントンゲーム処理にて用いられる各種データに関して説明する。図２１は、本体装置２のＤＲＡＭ８５に記憶される各種データの一例を示すメモリマップである。本体装置２のＤＲＡＭ８５には、ゲームプログラム３０１、学習済みモデル３０２、プ
レイヤキャラクタデータ３０３、相手キャラクタデータ３０４、シャトル移動パラメータ３０５、操作データ３０６、振り判定用データ３０７、振り方情報３０８、再生アニメ指定情報３０９、進行管理用データ３１０、振り状態フラグ３１１、ショット発生フラグ３１２等が記憶されている。
まず、本バドミントンゲーム処理にて用いられる各種データに関して説明する。図２１は、本体装置２のＤＲＡＭ８５に記憶される各種データの一例を示すメモリマップである。本体装置２のＤＲＡＭ８５には、ゲームプログラム３０１、学習済みモデル３０２、プ
レイヤキャラクタデータ３０３、相手キャラクタデータ３０４、シャトル移動パラメータ３０５、操作データ３０６、振り判定用データ３０７、振り方情報３０８、再生アニメ指定情報３０９、進行管理用データ３１０、振り状態フラグ３１１、ショット発生フラグ３１２等が記憶されている。
【0114】
ゲームプログラム３０１は、本実施形態におけるバドミントンゲーム処理を実行するためのプログラムである。
【0115】
学習済みモデル３０２は、上述したようなディープラーニングで生成された学習済みモデルが記憶されたものである。なお、本実施形態では、当該学習済みモデル３０２は、例えばゲームアプリケーションの一部として（ゲームデータとして）組み込まれている学習済みモデルをＤＲＡＭ８５にロードして用いるものとする。つまり、予め用意された学習済みモデルを利用するものとする。なお、他の実施形態では、例えばゲーム開始時等の所定のタイミングで、所定のサーバから学習済みモデルをダウンロードして取得する構成としてもよい。
【0116】
プレイヤキャラクタデータ３０３は、上記プレイヤキャラＰＣに関するデータである。図２２に、プレイヤキャラクタデータ３０３のデータ構成の一例を示す。プレイヤキャラクタデータ３０３には、外観データ３３１、キャラクタ位置データ３３２、キャラクタ姿勢データ３３３、オート移動先データ３３４、プレイヤ状態データ３３５、アニメーションデータ３３６等が含まれる。
【0117】
外観データ３３１は、プレイヤキャラＰＣの外観を構成するためのデータである。外観データ３３１には、例えば、プレイヤキャラＰＣの３次元モデルのモデリングデータや、テクスチャデータ等が含まれる。
【0118】
キャラクタ位置データ３３２は、プレイヤキャラＰＣの現在位置を示すための座標データである。キャラクタ姿勢データ３３３は、プレイヤキャラＰＣの現在の姿勢を示すデータである（どの方向に向いているか等）。
【0119】
オート移動先データ３３４は、上記オート移動先となる位置を示す座標データである。
【0120】
プレイヤ状態データ３３５は、プレイヤキャラＰＣの現在の状態（以下、プレイヤ状態）を管理するためのデータである。本実施形態では、プレイヤ状態として、以下のような状態を用いる。そして、プレイヤ状態データ３３５には、下記のいずれかのプレイヤ状態を示す情報が設定される。
「移動中」：プレイヤキャラＰＣがオート移動先に向けて移動中の状態を示す。
「オーバー」：プレイヤキャラＰＣがオーバーの動作を行っている状態を示す。
「スマッシュ」：プレイヤキャラＰＣがスマッシュの動作を行っている状態を示す。
「アンダーフォア」：プレイヤキャラＰＣがアンダーフォアの動作を行っている状態を示す。
「アンダーバック」：プレイヤキャラＰＣがアンダーバックの動作を行っている状態を示す。
「ミスショット」：プレイヤキャラＰＣがミスショットの動作を行っている状態を示す。
「待機中」：上記のいずれの状態でもない場合の状態を示す。
「移動中」：プレイヤキャラＰＣがオート移動先に向けて移動中の状態を示す。
「オーバー」：プレイヤキャラＰＣがオーバーの動作を行っている状態を示す。
「スマッシュ」：プレイヤキャラＰＣがスマッシュの動作を行っている状態を示す。
「アンダーフォア」：プレイヤキャラＰＣがアンダーフォアの動作を行っている状態を示す。
「アンダーバック」：プレイヤキャラＰＣがアンダーバックの動作を行っている状態を示す。
「ミスショット」：プレイヤキャラＰＣがミスショットの動作を行っている状態を示す。
「待機中」：上記のいずれの状態でもない場合の状態を示す。
【0121】
アニメーションデータ３３６は、プレイヤキャラＰＣの各種の動きに対応するアニメーションのデータである。アニメーションデータ３３６には、上記ラケットスイングアニメーション（ミスショットやスマッシュのアニメーションも含む）や、「待機中」のときの
アニメーションや、オート移動中のアニメーション等のデータが含まれる。
アニメーションや、オート移動中のアニメーション等のデータが含まれる。
【0122】
なお、当該アニメーションデータ３３６に関し、１つの振り方に対応するラケットスイングアニメーションとして、複数のアニメーションのデータが用意されていてもよい。これら複数のアニメーションは、シャトル２０３の高さに応じて用意されたものであってもよい。例えば「オーバー」に対応するアニメーションのデータとして、シャトル２０３の高さに応じた複数のアニメーションが用意されていてもよい。そして、オーバーに係る振り入力が行われたときのシャトル２０３の高さに応じた「オーバー」のアニメーションが選択され、これが再生されてもよい。
【0123】
図２１に戻り、相手キャラクタデータ３０４は、上記相手キャラクタＮＰＣに関するデータである。その内容は、上記プレイヤキャラクタデータ３０３と同様のものが記憶される。
【0124】
シャトル移動パラメータ３０５は、シャトル２０３の移動制御を行うためのデータである。シャトル移動パラメータ３０５には、例えばシャトル２０３の現在位置や移動軌道や移動速度、シャトル２０３の現在の状態（ミスショットされたシャトル２０３か否か等）を示す各種のパラメータが含まれる。
【0125】
操作データ３０６は、上記コントローラから得られるデータであり、ユーザの操作内容を示すデータである。図２３に、操作データ３０６のデータ構成の一例を示す。操作データ３０６には、デジタルボタンデータ３６１と、右スティックデータ３６２と、左スティックデータ３６３と、右慣性センサデータ３６４と、左慣性センサデータ３６５とが少なくとも含まれている。デジタルボタンデータ３６１は、コントローラが有する各種ボタンの押下状態を示すデータである。右スティックデータ３６２は、上記右スティック５２に対する操作内容を示すためのデータである。具体的には、ｘ、ｙの２次元のデータが含まれる。左スティックデータ３６３は、上記左スティック３２に対する操作内容を示すためのデータである。右慣性センサデータ３６４は、右コントローラ４の加速度センサ１１４や角速度センサ１１５の慣性センサの検出結果を示すデータである。具体的には、３軸の加速度データや３軸の角速度データが含まれる。左慣性センサデータ３６５は、左コントローラ３の加速度センサ１０４や角速度センサ１０５の慣性センサの検出結果を示すデータである。なお、以下の説明では、右慣性センサデータ３６４および左慣性センサデータ３６５を総称して慣性センサデータと呼ぶこともある。
【0126】
図２１に戻り、振り判定用データ３０７は、振り入力が行われたか否かを判定するためのデータであり、また、（振り入力が行われている期間中における）振り入力の内容を示すデータでもある。具体的には、振り判定用データ３０７は、上記各慣性センサから得られた加速度データおよび角速度データと、これらに基づいて算出されるコントローラの姿勢データを所定の期間分（例えば数十フレーム分）溜め込むことが可能なバッファである。当該姿勢データは、例えば、コントローラのローカル座標系におけるｘ、ｙ、ｚの３軸のベクトルで示されるデータであってもよい。本実施形態では、当該振り判定用データ３０７を用いて、上記のような振り入力を検出したり、上記学習済みモデルを用いた振り方の判定処理を行ったりする。
【0127】
振り方情報３０８は、上記学習済みモデルを用いた振り方の判定結果として得られた、コントローラの振り方（振り方向）を示す情報である。すなわち、上記３種の振り方のうち最も類似していると判定された振り方を示す情報である。本実施形態では、「オーバー」「アンダーフォア」「アンダーバック」「該当無し」のいずれかを示す情報が設定されるものとする。また、当該振り方情報３０８は、振り方向を示す情報とも言える。上記のように、本実施形態では、「オーバー」は下方向への振り、「アンダーフォア」は左上方
向への振り、「アンダーバック」は右上方向への振り（いずれも右利きの場合）と対応する。そのため、振り方が判定できれば、必然的に振り方向も決まると言える。
向への振り、「アンダーバック」は右上方向への振り（いずれも右利きの場合）と対応する。そのため、振り方が判定できれば、必然的に振り方向も決まると言える。
【0128】
再生アニメ指定情報３０９は、プレイヤキャラＰＣについて再生するアニメーションを指定する情報である。
【0129】
進行管理用データ３１０は、試合の進行を管理するためのデータである。具体的は、サーブを行う局面であるか否かを示すサーブフラグや、得点状況を示すスコア情報等のデータが含まれる。
【0130】
振り状態フラグ３１１は、コントローラが振られている状態である「振り状態」であるか否かを示すためのフラグである。初期値はオフであり、振り状態のときは、オンが設定される。
【0131】
ショット発生フラグ３１２は、ユーザの振り入力が行われた結果、シャトル２０３の打ち返し（ショット）を発生させる状態であるか否かを示すためのフラグである。初期値はオフであり、ショットを発生させる状態のときはオンが設定される。
【0132】
その他、ゲーム処理に必要な各種データも適宜生成され、ＤＲＡＭ８５に格納される。
【0133】
［プロセッサ８１が実行する処理の詳細］
次に、本実施形態に係るバドミントンゲーム処理の詳細を説明する。なお、以下に示すフローチャートは、処理過程の単なる一例にすぎない。そのため、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよい。また、変数の値や、判定ステップで利用される閾値も、単なる一例であり、必要に応じて他の値を採用してもよい。
次に、本実施形態に係るバドミントンゲーム処理の詳細を説明する。なお、以下に示すフローチャートは、処理過程の単なる一例にすぎない。そのため、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよい。また、変数の値や、判定ステップで利用される閾値も、単なる一例であり、必要に応じて他の値を採用してもよい。
【0134】
図２４は、バドミントンゲーム処理の詳細を示すフローチャートである。ユーザが試合を開始するための所定の操作を行うことで、当該処理の実行が開始される。なお、当該フローチャートにおけるステップＳ２～Ｓ３の処理ループは、１フレーム毎に繰り返し実行される。
【0135】
まず、ステップＳ１で、プロセッサ８１は、試合を開始する準備のための準備処理を実行する。この処理では、仮想コートが配置された仮想３次元空間を構築し、プレイヤキャラＰＣや相手キャラクタＮＰＣ等の各種オブジェクトを配置する処理が実行される。そして、各種オブジェクトが配置された仮想空間が仮想カメラで撮像されることでゲーム画像が生成され、当該画像が据置型モニタ等に出力される。また、以下の処理で用いられる各種データの初期化も行われる。その後、例えば試合開始演出を表示する処理が行われ、試合が開始する。
【0136】
次に、ステップＳ２で、プロセッサ８１は、試合処理を実行する。図２５は、当該試合処理の詳細を示すフローチャートである。
【0137】
［プレイヤキャラクタの制御］
図２５において、まず、ステップＳ１１で、プロセッサ８１は、プレイヤキャラクタ制御処理を実行する。図２６は、当該プレイヤキャラクタ制御処理の詳細を示すフローチャートである。図２６において、まず、ステップＳ２１で、プロセッサ８１は、操作データ３０６を取得する。
図２５において、まず、ステップＳ１１で、プロセッサ８１は、プレイヤキャラクタ制御処理を実行する。図２６は、当該プレイヤキャラクタ制御処理の詳細を示すフローチャートである。図２６において、まず、ステップＳ２１で、プロセッサ８１は、操作データ３０６を取得する。
【0138】
［オート移動制御］
次に、ステップＳ２２で、プロセッサ８１は、プレイヤキャラＰＣをオート移動制御す
る。具体的には、プロセッサ８１は、シャトル移動パラメータ３０５に基づいてシャトル２０３の移動先を判定する。更に、プロセッサ８１は、シャトル２０３を打ち返せるような位置を上記オート移動先データ３３４として算出する。そして、プロセッサ８１は、当該オート移動先に向けてプレイヤキャラＰＣを移動させる制御（キャラクタ位置データ３３２の更新）を行う。また、プロセッサ８１は、移動の開始・終了に伴うプレイヤ状態の遷移を管理し、プレイヤ状態データ３３５に「待機中」や「移動中」を示す情報を適宜設定する。また、プロセッサ８１は、「待機中」や「移動中」のプレイヤ状態に応じたアニメーションを指定する情報を再生アニメ指定情報３０９に適宜設定する。
次に、ステップＳ２２で、プロセッサ８１は、プレイヤキャラＰＣをオート移動制御す
る。具体的には、プロセッサ８１は、シャトル移動パラメータ３０５に基づいてシャトル２０３の移動先を判定する。更に、プロセッサ８１は、シャトル２０３を打ち返せるような位置を上記オート移動先データ３３４として算出する。そして、プロセッサ８１は、当該オート移動先に向けてプレイヤキャラＰＣを移動させる制御（キャラクタ位置データ３３２の更新）を行う。また、プロセッサ８１は、移動の開始・終了に伴うプレイヤ状態の遷移を管理し、プレイヤ状態データ３３５に「待機中」や「移動中」を示す情報を適宜設定する。また、プロセッサ８１は、「待機中」や「移動中」のプレイヤ状態に応じたアニメーションを指定する情報を再生アニメ指定情報３０９に適宜設定する。
【0139】
［振り入力に関連する処理］
次に、ステップＳ２３で、プロセッサ８１は、振り入力関連処理を実行する。この処理では、振り入力の検出や、上記学習済みモデルを用いた振り方向の判定処理、ショット発生の判定処理等が行われる。
次に、ステップＳ２３で、プロセッサ８１は、振り入力関連処理を実行する。この処理では、振り入力の検出や、上記学習済みモデルを用いた振り方向の判定処理、ショット発生の判定処理等が行われる。
【0140】
図２７は、振り入力関連処理の詳細を示すフローチャートである。図２７において、まず、ステップＳ３１で、プロセッサ８１は、振り状態フラグ３１１に基づき、現在が振り状態か否かを判定する。当該判定の結果、振り状態ではない場合は（ステップＳ３１でＮＯ）、ステップＳ３２で、プロセッサ８１は、振り判定用データ３０７に基づき、振り入力の開始が検出されたか否か、すなわち、振り状態が開始したか否かを判定する。振り状態の開始および終了の検出手法はどのような手法でもよいが、例えば、上記操作データ３０６に含まれる加速度データが示す加速度の変化が所定の閾値以上になったときに、振り状態が開始されたと判定してもよい。更に、振り状態の終了については、振り状態開始と判定された後に当該加速度データが示す加速度の大きさがピークに達した後、当該加速度の大きさがある程度減衰したときに、振り状態が終了と判定してもよい。そして、振り状態の終了をもって、振り入力が行われたと判定してもよい。
【0141】
上記判定の結果、振り状態が開始していない場合は（ステップＳ３２でＮＯ）、ステップＳ３３で、プロセッサ８１は、慣性センサデータに基づき、プレイヤキャラＰＣの姿勢（およびラケットの姿勢）を変化させる。すなわち、プロセッサ８１は、そのときのコントローラの姿勢を慣性センサデータに基づき算出し、この姿勢をプレイヤキャラＰＣの姿勢に反映させる。つまり、コントローラが振られていない場合は、ユーザにより行われたコントローラ自体の動きや姿勢変化がプレイヤキャラＰＣおよびラケットの姿勢に反映されることになる（いわば、ラケットを構えている状態となる）。その後、プロセッサ８１は、振り入力関連処理を終了する。
【0142】
一方、上記ステップＳ３２の判定の結果、振り状態が開始した場合は（ステップＳ３２でＹＥＳ）、ステップＳ３４で、プロセッサ８１は、振り状態フラグ３１１にオンを設定する。
【0143】
次に、ステップＳ３５で、プロセッサ８１は、振り判定用データ３０７を更新する。具体的には、プロセッサ８１は、上記操作データに含まれる慣性センサデータを振り判定用データ３０７に記憶する。つまり、振り状態の期間中、１フレーム毎に慣性センサデータを振り判定用データ３０７に溜め込んでいく処理が実行される。またこの際、加速度、角速度のデータに基づいて、コントローラの姿勢を示す姿勢データも算出され、これも振り判定用データ３０７に溜め込まれる。その後、プロセッサ８１は、振り入力関連処理を終了する。
【0144】
次に、上記ステップＳ３１の判定の結果、振り状態であると判定された場合の処理（ステップＳ３１でＹＥＳ）について説明する、この場合は、まず、ステップＳ３６で、プロセッサ８１は、振り状態が終了したか否かを判定する。当該終了の判定手法は上述したと
おりである。当該判定の結果、まだ振り状態が終了していない場合は（ステップＳ３６でＮＯ）、上記ステップＳ３５に処理が進められ、振り判定用データ３０７の更新が行われる。
おりである。当該判定の結果、まだ振り状態が終了していない場合は（ステップＳ３６でＮＯ）、上記ステップＳ３５に処理が進められ、振り判定用データ３０７の更新が行われる。
【0145】
一方、振り状態が終了したと判定された場合は（ステップＳ３６でＹＥＳ）、ステップＳ３７で、プロセッサ８１は、振り方判定処理を実行する。この処理では、振り状態に係る振り方と上記３種の振り方の類似度に基づき、今回行われた振り方を判定する処理が行われる。図２８は、当該振り方判定処理の詳細を示すフローチャートである。図２８において、まず、ステップＳ５１で、プロセッサ８１は、振り判定用データ３０７を取得する。次に、ステップＳ５２で、プロセッサ８１は、振り判定用データ３０７、および、学習済みモデル３０２を用いた、上記類似度の算出処理を行う。具体的には、プロセッサ８１は、今回の振り状態の期間中における加速度、角速度、コントローラの姿勢のデータ（上記図１６の振り入力データ）を学習済みモデル３０２に入力する。その出力結果として、今回ユーザが行った振り入力（振り方）と、オーバー、アンダーフォア、アンダーバックのそれぞれとの類似度が算出される。
【0146】
次に、ステップＳ５３で、プロセッサ８１は、現在のゲーム状況が、サーブまたはスマッシュを打つことが可能な状況であるか否かを判定する。本実施形態では、サーブ可能な状況か否かは、進行管理用データ３１０（上記サーブフラグ）に基づいて判断可能である。また、スマッシュ可能な状況か否かは、シャトル２０３の位置が上記スマッシュ可能領域内にあるか否かで判定可能である。
【0147】
上記判定の結果、サーブまたはスマッシュのいずれかを打つことが可能な状況の場合は（ステップＳ５３でＹＥＳ）、ステップＳ５４で、プロセッサ８１は、上記算出された３つの類似度を参照し、類似度の値が第１の閾値、具体的は、“－１”以上の振り方があるか否かを判定する。当該判定の結果、類似度が“－１”以上の振り方があれば（ステップＳ５４でＹＥＳ）、次に、ステップＳ５５で、プロセッサ８１は、当該類似度が“－１”以上の振り方を示す情報を振り方情報３０８に設定する。その結果、振り方情報３０８には、「オーバー」、「アンダーフォア」、「アンダーバック」のいずれかを示す情報が設定されることになる。また、類似度が“－１”以上の振り方が２つ以上ある場合は、これらの振り方の中から最も類似度が高い振り方を選択して、その振り方を示す情報を振り方情報３０８に設定する。その後、プロセッサ８１は、振り方判定処理を終了する。
【0148】
一方、類似度が“－１”以上の振り方が無い場合、すなわち、３種全ての振り方について類似度が“－１”未満の場合は（ステップＳ５４でＮＯ）、ステップＳ５６で、プロセッサ８１は、振り方情報３０８に「該当無し」の情報を設定する。その後、プロセッサ８１は、振り方判定処理を終了する。
【0149】
次に、上記ステップＳ５３の判定の結果、サーブまたはスマッシュのいずれも打てる状況ではないと判定された場合（ステップＳ５３でＮＯ）について説明する。この場合は、ステップＳ５７で、プロセッサ８１は、上記算出された３つの類似度を参照し、類似度の値が、上記第１の閾値より大きな第２の閾値、具体的は、“＋１”以上の振り方があるか否かを判定する。当該判定の結果、類似度が“＋１”以上の振り方があれば（ステップＳ５７でＹＥＳ）、次に、ステップＳ５８で、プロセッサ８１は、当該類似度が“＋１”以上の振り方が１つだけであれば、その振り方を示す情報を振り方情報３０８に設定する。また、２つ以上ある場合は、これらの振り方の中から最も類似度が高い振り方を選択して、その振り方を示す情報を振り方情報３０８に設定する。その後、プロセッサ８１は、振り方判定処理を終了する。
【0150】
一方、類似度が“＋１”以上の振り方が無い場合、すなわち、３種全ての振り方につい
て類似度が“＋１”未満の場合は（ステップＳ５７でＮＯ）、上記ステップＳ５６に進み、プロセッサ８１は、振り方情報３０８に「該当無し」の情報を設定する。その後、プロセッサ８１は、振り方判定処理を終了する。
て類似度が“＋１”未満の場合は（ステップＳ５７でＮＯ）、上記ステップＳ５６に進み、プロセッサ８１は、振り方情報３０８に「該当無し」の情報を設定する。その後、プロセッサ８１は、振り方判定処理を終了する。
【0151】
ここで、本実施形態では、上記のように、第１の閾値を第２の閾値より小さな値とすることで、サーブまたはスマッシュを打てる状況である場合は、多少類似度が低くてもいずれかの振り方による振り入力が行われたと判定されやすいようにしている。このようにサーブまたはスマッシュを打てる状況である場合とそうではない場合とで、異なる閾値（判定条件）を用いる理由について補足する。まず、サーブに関して説明する。バドミントンゲームにおいて、サーブの操作を行う場合、ユーザは、コントローラを振り上げるような腕の動き（本実施形態でいうとアンダーフォアの動き）を行うことになる。しかし、サーブするときの振り上げ動作は、サーブ以外の状況で打ち返すときの振り上げ動作に比べて、小さく動かすユーザも多いと考えられる。つまり、動かし方としては同じ振り上げ（アンダーフォア）ではあるが、その動きの大きさが小さくなる傾向が想定される。この場合、類似度算出に用いる振り入力に係るデータ量が（通常の打ち返し時の場合よりも）少なくなり、判定精度が下がる虞がある。そのため、本実施形態では、サーブを行う状況のときは、そうではない状況のときよりも判定条件を緩め、類似度が多少低くてもアンダーフォアの振り方が行われたと判定されやすいようにしている。
【0152】
次に、スマッシュの場合について説明する。スマッシュの場合も、サーブの場合と同様に、認識精度が下がる虞があることに対しての対応策という位置づけである。具体的には、ユーザが、スマッシュを打てる状況であると認識した場合、例えば、ゲーム処理において、スマッシュのチャンスであることを視覚的にユーザに示すような場合、これを認識したユーザは、スマッシュを打とうとして慌ててしまうことが考えられる。そして、ユーザが慌ててスマッシュを打とうとコントローラを振った結果、コントローラの振りが雑な振り方になってしまう、ということが想定される。このような雑な振り方が行われた結果、判定精度（この場合はオーバーの判定）が下がる虞がある。そのため、スマッシュが打てるような状況である場合も、判定条件を緩めて、（雑な振り方でも）スマッシュが発生しやすいようにしている。
【0153】
なお、上記第１の閾値、第２の閾値の具体的な数値は、上記に限るものではなく、ゲームバランス等の観点から適宜調整されればよい。
【0154】
図２７に戻り、次に、ステップＳ３８で、プロセッサ８１は、ショット発生判定処理を実行する。これは、今回行われた振り入力と、シャトル２０３およびプレイヤキャラＰＣの位置関係に基づき、ショット（シャトル２０３の打ち返し）が発生するか否かの判定と、これに伴って必要な設定を行う処理である。
【0155】
図２９～図３０は、当該ショット発生判定処理の詳細を示すフローチャートである。図２９において、まず、ステップＳ７１で、プロセッサ８１は、振り方情報３０８が「オーバー」か否かを判定する。当該判定の結果、「オーバー」の場合は（ステップＳ７１でＹＥＳ）、ステップＳ７２で、プロセッサ８１は、上記図２０で示したようなオーバー可能領域内にシャトル２０３が存在しているか否かを判定する。当該判定の結果、存在する場合は（ステップＳ７２でＹＥＳ）、ステップＳ７３で、プロセッサ８１は、上記スマッシュ可能領域内にシャトル２０３が存在しているか否かを更に判定する。当該判定の結果、スマッシュ可能領域内にシャトル２０３が存在している場合は（ステップＳ７３でＹＥＳ）、ステップＳ７４で、プロセッサ８１は、プレイヤ状態データ３３５に「スマッシュ」を設定する。一方、スマッシュ可能領域内にシャトル２０３が存在していない場合は（ステップＳ７３でＮＯ）、ステップＳ７５で、プロセッサ８１は、プレイヤ状態データ３３５に「オーバー」を設定する。
【0156】
次に、ステップＳ７６で、プロセッサ８１は、ショット発生フラグ３１２にオンを設定する。
【0157】
次に、ステップＳ７７、プロセッサ８１は、プレイヤキャラＰＣに行わせるラケットスイングアニメーションを設定する。具体的には、プロセッサ８１は、プレイヤ状態データ３３５に基づいて、再生すべきラケットスイングアニメーションを決定する。そして、プロセッサ８１は、決定したラケットスイングアニメーションに係るアニメーションを指定する情報を再生アニメ指定情報３０９に設定する。例えば、プレイヤ状態データ３３５が「オーバー」であれば、「オーバー」に対応するラケットスイングアニメーションのアニメーションが再生アニメ指定情報３０９に設定される。なお、上記のように、１つの振り方に対応するラケットスイングアニメーションとして、シャトル２０３の高さに応じた複数のアニメーションを用いる場合は、この時点におけるシャトル２０３の高さに応じたアニメーションを選択し、再生アニメ指定情報３０９に設定してもよい。
【0158】
その後、プロセッサ８１は、ショット発生判定処理を終了する。
【0159】
次に、上記ステップＳ７２の判定の結果、オーバー可能領域内にシャトル２０３が存在していない場合（ステップＳ７２でＮＯ）について説明する。この場合は、ステップＳ７８で、プロセッサ８１は、上記アンダーフォア可能領域、または、アンダーバック可能領域内にシャトル２０３が存在しているか否かを判定する。当該判定の結果、存在する場合は（ステップＳ７８でＹＥＳ）、ステップＳ７９で、プロセッサ８１は、プレイヤ状態データ３３５に「ミスショット」を設定する。つまり、オーバーで打ち返すべき状況でアンダーフォアまたはアンダーバックの振り入力が行われた場合は、ミスショットとして扱うための設定を行う。その後、上記ステップＳ７６に処理が進められる（なお、ミスショットは空振りではないため、ショット発生フラグ３１２はオンに設定されることになる）。
【0160】
一方、上記判定の結果、上記アンダーフォア可能領域、または、アンダーバック可能領域内にシャトル２０３が存在していない場合は（ステップＳ７８でＮＯ）、ステップＳ８０で、プロセッサ８１は、プレイヤ状態データ３３５に「オーバー」を設定する。次に、ステップＳ８１で、プロセッサ８１は、ショット発生フラグ３１２にオフを設定する。つまり、この場合は、「オーバー」のラケットスイングアニメーションは行われるがショットは発生せずに空振り、という結果とするための処理が行われる。その後、上記ステップＳ７７に処理が進められる。
【0161】
次に、上記ステップＳ７１の判定の結果、振り方情報３０８が「オーバー」ではない場合（ステップＳ７１でＮＯ）について説明する。この場合は、図３０のステップＳ８２で、プロセッサ８１は、振り方情報３０８が「アンダーフォア」か否かを判定する。当該判定の結果、「アンダーフォア」の場合は（ステップＳ８２でＹＥＳ）、ステップＳ８３で、プロセッサ８１は、プレイヤ状態データ３３５に「アンダーフォア」を設定する。次に、ステップＳ８４で、プロセッサ８１は、上記アンダーフォア可能領域内にシャトル２０３が存在しているか否かを判定する。当該判定の結果、存在する場合は（ステップＳ８４でＹＥＳ）、上記ステップＳ７６に処理が進められる。一方、存在していない場合は（ステップＳ８４でＮＯ）、ステップＳ８５で、プロセッサ８１は、ショット発生フラグ３１２にオフを設定する。つまり、空振りさせる設定が行われる。その後、上記ステップＳ７７に処理が進められる。
【0162】
一方、上記ステップＳ８２の判定の結果、振り方情報３０８が「アンダーフォア」ではない場合は（ステップＳ８２でＮＯ）、次に、ステップＳ８６で、プロセッサ８１は、振り方情報３０８が「アンダーバック」か否かを判定する。当該判定の結果、「アンダーバ
ック」の場合は（ステップＳ８７でＹＥＳ）、ステップＳ８７で、プロセッサ８１は、プレイヤ状態データ３３５に「アンダーバック」を設定する。次に、ステップＳ８８で、プロセッサ８１は、上記アンダーバック可能領域内にシャトル２０３が存在しているか否かを判定する。当該判定の結果、存在する場合は（ステップＳ８８でＹＥＳ）、上記ステップＳ７６に処理が進められる。一方、存在していない場合は（ステップＳ８８でＮＯ）、上記ステップＳ８５に処理が進められる。
ック」の場合は（ステップＳ８７でＹＥＳ）、ステップＳ８７で、プロセッサ８１は、プレイヤ状態データ３３５に「アンダーバック」を設定する。次に、ステップＳ８８で、プロセッサ８１は、上記アンダーバック可能領域内にシャトル２０３が存在しているか否かを判定する。当該判定の結果、存在する場合は（ステップＳ８８でＹＥＳ）、上記ステップＳ７６に処理が進められる。一方、存在していない場合は（ステップＳ８８でＮＯ）、上記ステップＳ８５に処理が進められる。
【0163】
一方、上記ステップＳ８６の判定の結果、振り方情報３０８が「アンダーバック」ではない場合は（ステップＳ８６でＮＯ）、振り方情報３０８には「該当無し」が設定されていることになる。この場合は、ステップＳ８９で、プレイヤ状態データ３３５に「待機中」を設定する。その後、上記ステップＳ８５に処理が進められる。つまり、ユーザが振り入力を行ったものの、上記３種の振り方のいずれにも類似していないと判定された場合は、プレイヤキャラＰＣはラケットスイングアニメーションを行わないことになる。
【0164】
図２７に戻り、次に、ステップＳ３９で、プロセッサ８１は、振り状態フラグ３１１にオフを設定する。その後、プロセッサ８１は、振り入力関連処理を終了する。
【0165】
［プレイヤキャラクタのアニメーション制御］
図２６に戻り、次に、ステップＳ２４で、プロセッサ８１は、プレイヤキャラＰＣのアニメーションの再生制御を行う。プロセッサ８１は、再生アニメ指定情報３０９に設定されているアニメーション（ラケットスイングアニメーション含む）の再生を行う。また、プロセッサは、所定のアニメーションの再生が終了すれば、プレイヤ状態データ３３５の内容を適宜更新する。例えば、ラケットスイングアニメーションの再生が終われば、そのときのプレイヤキャラＰＣの状況に応じて、プレイヤ状態データ３３５には「待機中」あるいは「移動中」が設定される。その後、プロセッサ８１は、プレイヤキャラクタ制御処理を終了する。
図２６に戻り、次に、ステップＳ２４で、プロセッサ８１は、プレイヤキャラＰＣのアニメーションの再生制御を行う。プロセッサ８１は、再生アニメ指定情報３０９に設定されているアニメーション（ラケットスイングアニメーション含む）の再生を行う。また、プロセッサは、所定のアニメーションの再生が終了すれば、プレイヤ状態データ３３５の内容を適宜更新する。例えば、ラケットスイングアニメーションの再生が終われば、そのときのプレイヤキャラＰＣの状況に応じて、プレイヤ状態データ３３５には「待機中」あるいは「移動中」が設定される。その後、プロセッサ８１は、プレイヤキャラクタ制御処理を終了する。
【0166】
［相手キャラクタの制御］
図２５に戻り、次に、ステップＳ１２で、プロセッサ８１は、ＮＰＣ制御処理を実行する。この処理は、相手キャラクタＮＰＣをＡＩ制御するための処理である。操作主体がプロセッサ８１（ＡＩ）となるが、基本的な処理内容は上記プレイヤキャラクタ制御処理と同様の制御が行われる。
図２５に戻り、次に、ステップＳ１２で、プロセッサ８１は、ＮＰＣ制御処理を実行する。この処理は、相手キャラクタＮＰＣをＡＩ制御するための処理である。操作主体がプロセッサ８１（ＡＩ）となるが、基本的な処理内容は上記プレイヤキャラクタ制御処理と同様の制御が行われる。
【0167】
［シャトル移動制御］
次に、ステップＳ１３で、プロセッサ８１は、シャトル移動制御処理を実行する。図３１は、当該シャトル移動制御処理の詳細を示すフローチャートである。図３１において、まず、ステップＳ１０１で、プロセッサ８１は、ショット発生フラグ３１２がオンであるか否かを判定する。当該判定の結果、オフの場合は（ステップＳ１０１でＮＯ）、後述のステップＳ１０６に処理が進められる。一方、オンの場合は（ステップＳ１０１でＹＥＳ）、シャトル２０３の打ち返しが発生したことになるため、次に、ステップＳ１０２で、プロセッサ８１は、プレイヤ状態データ３３５に基づき、プレイヤ状態が「ミスショット」であるか否かを判定する。当該判定の結果、「ミスショット」ではない場合は（ステップＳ１０２でＮＯ）、ステップＳ１０３で、プロセッサ８１は、（ミスショットではない場合における）打ち返されたシャトル２０３の移動パラメータを算出する。具体的には、振り速度等の振り入力の内容、および、今回行われたショットの内容（オーバーかアンダーフォアか等）に基づいて、シャトル２０３の移動軌跡や移動速度が算出される。そして、プロセッサ８１は、算出したパラメータをシャトル移動パラメータ３０５に設定する。その後、ステップＳ１０５に処理が進められる。
次に、ステップＳ１３で、プロセッサ８１は、シャトル移動制御処理を実行する。図３１は、当該シャトル移動制御処理の詳細を示すフローチャートである。図３１において、まず、ステップＳ１０１で、プロセッサ８１は、ショット発生フラグ３１２がオンであるか否かを判定する。当該判定の結果、オフの場合は（ステップＳ１０１でＮＯ）、後述のステップＳ１０６に処理が進められる。一方、オンの場合は（ステップＳ１０１でＹＥＳ）、シャトル２０３の打ち返しが発生したことになるため、次に、ステップＳ１０２で、プロセッサ８１は、プレイヤ状態データ３３５に基づき、プレイヤ状態が「ミスショット」であるか否かを判定する。当該判定の結果、「ミスショット」ではない場合は（ステップＳ１０２でＮＯ）、ステップＳ１０３で、プロセッサ８１は、（ミスショットではない場合における）打ち返されたシャトル２０３の移動パラメータを算出する。具体的には、振り速度等の振り入力の内容、および、今回行われたショットの内容（オーバーかアンダーフォアか等）に基づいて、シャトル２０３の移動軌跡や移動速度が算出される。そして、プロセッサ８１は、算出したパラメータをシャトル移動パラメータ３０５に設定する。その後、ステップＳ１０５に処理が進められる。
【0168】
一方、ミスショットである場合は（ステップＳ１０２でＹＥＳ）、ステップＳ１０４で
、プロセッサ８１は、シャトル２０３の動きがミスショットの場合の動きとなるように、シャトル移動パラメータ３０５を算出する。例えば、プロセッサ８１は、移動速度のパラメータを通常よりも遅くしたり、移動軌道がふらふらとした軌道となるように設定したり、ミスショットされた状態のシャトル２０３であることを示すフラグにオンを設定したりする。
、プロセッサ８１は、シャトル２０３の動きがミスショットの場合の動きとなるように、シャトル移動パラメータ３０５を算出する。例えば、プロセッサ８１は、移動速度のパラメータを通常よりも遅くしたり、移動軌道がふらふらとした軌道となるように設定したり、ミスショットされた状態のシャトル２０３であることを示すフラグにオンを設定したりする。
【0169】
次に、ステップＳ１０５で、プロセッサ８１は、ショット発生フラグ３１２にオフを設定する。
【0170】
次に、プロセッサ８１は、上述したような、シャトル２０３が地面にある程度近い場合の減速調整制御を行う。まず、ステップＳ１０６で、プロセッサ８１は、シャトル２０３の高さが、減速調整を行うための閾値として予め設定されている高さである減速閾値以下の高さか否かを判定する。当該判定の結果、減速閾値以下の高さである場合は（ステップＳ１０６でＹＥＳ）、ステップＳ１０７で、プロセッサ８１は、地面からの高さに応じた減速割合でシャトル２０３の移動速度が減速するように、シャトル移動パラメータ３０５の内容を調整する。つまり、地面に近いほどシャトル２０３の移動速度がより大きく減速するような調整が行われる。
【0171】
一方、シャトル２０３の高さが減速閾値以下ではない場合は（ステップＳ１０６でＮＯ）、上記ステップＳ１０７の処理はスキップされる。
【0172】
次に、ステップＳ１０８で、プロセッサ８１は、シャトル移動パラメータ３０５に基づいて、シャトル２０３を移動させる。以上で、シャトル移動制御処理は終了する。
【0173】
［試合進行管理］
図２５に戻り、次に、ステップＳ１４で、プロセッサ８１は、ゲーム進行管理処理を実行する。当該処理では、得点の判定、スコアの管理等が行われる。また、プロセッサ８１は、サーブを打つ局面である場合は上記サーブフラグをオンに設定し、当該サーブが打たれた後はサーブフラグをオフにする処理も行う。また、試合を終了する条件が満たされた場合は、プロセッサ８１は、例えば試合終了を示すための終了フラグにオンを設定する。
図２５に戻り、次に、ステップＳ１４で、プロセッサ８１は、ゲーム進行管理処理を実行する。当該処理では、得点の判定、スコアの管理等が行われる。また、プロセッサ８１は、サーブを打つ局面である場合は上記サーブフラグをオンに設定し、当該サーブが打たれた後はサーブフラグをオフにする処理も行う。また、試合を終了する条件が満たされた場合は、プロセッサ８１は、例えば試合終了を示すための終了フラグにオンを設定する。
【0174】
［ゲーム画像生成および出力］
次に、ステップＳ１５で、プロセッサ８１は、ゲーム画像を生成する。すなわち、プロセッサ８１は、上記のような処理が反映された仮想空間を仮想カメラで撮像することで、ゲーム画像を生成する。そして、プロセッサ８１は、生成したゲーム画像を据置型モニタ等に出力する。以上で、試合処理は終了する。
次に、ステップＳ１５で、プロセッサ８１は、ゲーム画像を生成する。すなわち、プロセッサ８１は、上記のような処理が反映された仮想空間を仮想カメラで撮像することで、ゲーム画像を生成する。そして、プロセッサ８１は、生成したゲーム画像を据置型モニタ等に出力する。以上で、試合処理は終了する。
【0175】
図２４に戻り、次に、ステップＳ３で、プロセッサ８１は、試合が終了したか否かを進行管理用データ３１０に基づいて判定する。当該判定の結果、試合が終了していない場合は（ステップＳ３でＮＯ）、ステップＳ２に戻り処理が繰り返される。試合が終了した場合は（ステップＳ３でＹＥＳ）、プロセッサ８１は、試合結果表示等の演出処理を適宜行い、バドミントンゲーム処理を終了する。
【0176】
以上で、本実施形態に係るバドミントンゲーム処理の詳細説明を終了する。
【0177】
このように、本実施形態では、上記のような３種類の振り方を使い分けるようなバドミントンゲームにおいて、学習済みモデルを用いて上記のような３種類の振り方（振り方向）の類似度を算出している。そして、これに基づいてユーザの行った振り入力に係る振り方を判定している。これにより、振り方の判定精度を向上させることができる。すなわち、振り入力は、ユーザの腕（手首）を動かすことによるアナログな入力でもあるところ、
例えば同じアンダーフォアの動き（本例では左上への振り上げ）が行われても、個々のユーザの振り方や振るときのクセ等の違いから、ユーザ間で振り方の個人差が大きくなり得るという側面もある。このような、複数種類の振り方を判別したいが、それぞれの振り方の個人差の幅が大きいと想定されるような場合、プログラムのコーディングにおいて振り方毎に加速度や角速度等の具体的な値や範囲を設定する手法では、上記振り方の個人差が吸収できずに十分な判定精度が得られない虞がある。この点、本実施形態のように上記学習済みモデルによる類似性の判定を用いることで、上記のような個人差にも対応でき、振り入力に係る振り方の判定精度の向上が期待できる。また、本実施形態の処理は、判定したい振り方の種類数が多いほど、その有用性は高まる。
例えば同じアンダーフォアの動き（本例では左上への振り上げ）が行われても、個々のユーザの振り方や振るときのクセ等の違いから、ユーザ間で振り方の個人差が大きくなり得るという側面もある。このような、複数種類の振り方を判別したいが、それぞれの振り方の個人差の幅が大きいと想定されるような場合、プログラムのコーディングにおいて振り方毎に加速度や角速度等の具体的な値や範囲を設定する手法では、上記振り方の個人差が吸収できずに十分な判定精度が得られない虞がある。この点、本実施形態のように上記学習済みモデルによる類似性の判定を用いることで、上記のような個人差にも対応でき、振り入力に係る振り方の判定精度の向上が期待できる。また、本実施形態の処理は、判定したい振り方の種類数が多いほど、その有用性は高まる。
【0178】
また、上記の処理は、換言すれば、ユーザが行った振り入力を、上記３種類の振り方のいずれかに当てはめて、その振り方での振り入力が行われたものとしてゲーム処理を実行するものともいえる。
【0179】
［変形例］
なお、上記実施形態では、３種類の振り方（振り方向）を判定する場合を例示したが、２種類の振り方を判定する場合や、４種類以上の振り方を判定する場合でも、上記の処理は適用可能である。上記のように、判定したい振り方の種類が多いほど、本実施形態の処理の有用性は高くなる。
なお、上記実施形態では、３種類の振り方（振り方向）を判定する場合を例示したが、２種類の振り方を判定する場合や、４種類以上の振り方を判定する場合でも、上記の処理は適用可能である。上記のように、判定したい振り方の種類が多いほど、本実施形態の処理の有用性は高くなる。
【0180】
また、上記実施形態では、振り方判定処理において、第１の閾値あるいは第２の閾値以上の類似度の振り方がなかった場合、３種類の振り方のいずれにも類似しないと判定し、プレイヤキャラＰＣにラケットスイングアニメーションを行わせない例を示した。他の実施形態では、この場合でも、最も類似度の高い振り方を選択するようにしてもよい。つまり、上記第１の閾値や第２の閾値を用いないような判定手法としてもよい。この場合は、振り入力に対して、３種類の振り方のうちのいずれか１つに対応するラケットスイングアニメーションが必ず再生されることになる（そして、タイミングが合っていればショットも発生し得る）。
【0181】
また、更に他の実施形態では、３種類の振り方のいずれにも類似しないと判定された場合は、そのときに行われた振り入力の内容をそのまま反映するようにプレイヤキャラＰＣにラケットスイングアニメーションを行わせるようにしてもよい。つまり、上記３種類の振り方ではないラケットスイングアニメーションが再生されるようにしてもよい。またこの場合、ラケットスイングアニメーションは行われるものの、シャトル２０３は打ち返せずに空振りとなるように処理しても良い。
【0182】
また、上記実施形態では、学習用データセット等の、振り方の判定の基礎となる要素として、慣性センサから得られたデータを用いる例を示した。この他、例えば、画像データを用いてディープラーニングさせて生成された学習済みモデルを併用して、振り方の類似性を判定するようにしても良い。例えば、コントローラを振るユーザを撮像した画像（動画）を学習用データセットとして、学習済みモデルを作成してもよい。そして、ゲームプレイにおいて、ユーザを所定のカメラで撮像できるようなゲームシステムを構成し、このカメラから得られた画像データを上記画像に基づく学習済みモデルに入力し、類似性を判定させてもよい。そして、これを、上記慣性センサのデータに基づく類似性判断に加えて、補助的に併用して判定するような構成としてもよい。これにより、判定精度の更なる向上が期待できる。
【0183】
また、他の実施形態では、類似度の高さに応じて、打ち返したシャトル２０３の動作を変化させても良い。例えば、同じ「オーバー」での打ち返しの場合でも、類似度が低い場合よりも類似度が高い場合のほうが、球速が速くなるような制御を行ってもよい。いわば
、類似度が高い方が、「理想的なフォームに近い」ものとして扱い、類似度が低い場合よりもゲームの進行に有利な効果が得られるような処理を行ってもよい。
、類似度が高い方が、「理想的なフォームに近い」ものとして扱い、類似度が低い場合よりもゲームの進行に有利な効果が得られるような処理を行ってもよい。
【0184】
また、上記実施形態では、振り方の類似性の判定について、振り状態の開始から終了までの期間における一連の（複数の）加速度等の変化の推移を比較するような例を示した。他の実施形態では、単一のフレームに係る振り入力データを用いて類似性を判定するように構成してもよい。例えば当該期間中におけるいずれか１のフレームにおける振り入力データについて、上記のような類似性を判定するような構成としてもよい。
【0185】
また、上記実施形態では、スマッシュまたはサーブを打てる状況の場合に、上記第２閾値より小さな値の第１閾値を用いて判定する例を挙げた。他の実施形態では、３種類の振り方のうち、ゲーム状況に応じて選択されたいずれか１種類の振り方についてのみ、上記のような小さめの閾値を用いて判定するようにしてもよい。つまり、ゲーム状況に応じて、３種類のうちの特定の振り方が他の振り方よりも判定されやすい状態としてもよい。
【0186】
また、他の実施形態では、上記振り方判定処理において用いる上記第１の閾値、第２の閾値を、ユーザ毎に動的にカスタマイズ可能な構成としてもよい。例えば、上記振り方判定処理において算出された類似度について、ユーザ毎に統計を取るようにしてもよい（前提として、ユーザはゲーム開始時に所定のログイン処理を行う等で、ユーザが特定できる環境である）。そして、３種の振り方それぞれの類似度の統計を取り、その統計結果に基づいて、上記第１の閾値や第２の閾値として用いる値を調整するようにしてもよい。例えば、オーバーの類似度は＋１５～＋２５の範囲内の値となることが多いが、アンダーフォアの類似度が＋１～＋３の範囲内の値となることが多いような場合を想定する。この場合、類似度が低めの値であるアンダーフォアの判定に用いる閾値を少し下げて、アンダーフォアが判定されやすいような調整を行ってもよい。そして、そのような調整結果をユーザ毎のパーソナルデータとして保存するようにしてもよい。
【0187】
また、上記ではバドミントンゲームを例示したが、この他、ラケットまたはこれに相当するような道具を振るようなスポーツゲーム全般についても、上記の処理は適用可能である。例えば卓球、テニス等のスポーツゲームにも適用可能である。
【0188】
また、上記実施形態においては、バドミントンゲーム処理に係る一連の処理を単一の本体装置２で実行される場合を説明した。他の実施形態においては、上記一連の処理が複数の情報処理装置からなる情報処理システムにおいて実行されてもよい。例えば、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの一部の処理がサーバ側装置によって実行されてもよい。更には、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの主要な処理がサーバ側装置によって実行され、当該端末側装置では一部の処理が実行されてもよい。また、上記情報処理システムにおいて、サーバ側のシステムは、複数の情報処理装置によって構成され、サーバ側で実行するべき処理を複数の情報処理装置が分担して実行してもよい。また、いわゆるクラウドゲーミングの構成としてもよい。例えば、本体装置２は、ユーザの操作を示す操作データを所定のサーバに送り、当該サーバにおいて各種ゲーム処理が実行され、その実行結果が動画・音声として本体装置２にストリーミング配信されるような構成としてもよい。
【符号の説明】
【0189】
１ ゲームシステム
２ 本体装置
３ 左コントローラ
４ 右コントローラ
８１ プロセッサ
８４ フラッシュメモリ
８５ ＤＲＡＭ
２ 本体装置
３ 左コントローラ
４ 右コントローラ
８１ プロセッサ
８４ フラッシュメモリ
８５ ＤＲＡＭ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】