JP2019217245A - ゲームプログラム、ゲーム方法、および情報処理装置 - Google Patents

Abstract

【課題】ゲームの興趣が低下する懸念を抑えることができるゲームプログラム、ゲーム方法、および情報処理装置を提供する。【解決手段】麻雀の団体戦に臨む４チームの各々には、５人のキャラクタが編成される。また、当該団体戦では５つの対局が用意され、当該５人のキャラクタは１局ずつ麻雀を行う。ここで、当該４チームのうちのいずれか１チームに属するキャラクタが親となり、当該キャラクタの対局が終了すると、残りの３チームのうち所定の順序で指定された１チームのキャラクタが親となって対局を引き継ぐ。各チームに属するキャラクタには、当該団体戦に関する有利度が関連付けられており、どのチームのキャラクタに１局目の親を割り当てるかは、当該有利度に基づいて決定される。【選択図】図１２

Description

本発明は、ゲームプログラム、ゲーム方法、および情報処理装置に関する。

麻雀では、４人のプレイヤのうちの１人のプレイヤが親となり、残りの３人のプレイヤが子となって対局を行う。また、親のポジションは、局の切り替わり時に右隣りのプレイヤに変更され、各プレイヤには、４局につき１局の割合で親が回ってくる。非特許文献１においては、４人のプレイヤで１チームを編成し、４チームによる団体戦形式で麻雀を行うことが示されている。

"社会人麻雀団体リーグ戦"、［ｏｎｌｉｎｅ］、[平成３０年６月７日検索]、インターネット＜https://mj-news.net/news/2015080318733＞

非特許文献１のような団体戦をコンピュータ麻雀ゲームにおいて、プレイヤの自由度やゲーム性等を考慮して、例えば５人のキャラクタで１チームを編成することもあり得る。また、当該５人のキャラクタ各々が行う対戦としては、プレイ時間を短縮するために、当該５人のキャラクタに１局ずつ割り当てて、計５局の対局で勝ち負けを争う団体戦もあり得る。

しかし、計５局の対局を行う団体戦の場合、４チームのうちのいずれか１チームには２回親が回ってくるが、残りの３チームには１回しか親が回ってこない。親の得点期待値は、子の得点期待値よりも高くなる。このため、親が回ってくる回数によって有利・不利を生じさせてしまう。その結果、最初に親を担当するチームを無作為に決定するような方式では、プレイヤに納得感を抱かせることができず、ゲームの興趣を低下させてしまう虞があった。

本発明は、かかる実情に鑑み考え出されたものであり、その目的は、ゲームの興趣が低下する懸念を抑えることができる、ゲームプログラム、ゲーム方法、および情報処理装置を提供することである。

本開示に示す一実施形態のある局面によれば、プロセッサ、メモリ、および表示部を備えるコンピュータにおいて実行されるゲームプログラムが提供される。ゲームプログラムは、プロセッサに、ユーザによる操作プレイヤと対戦プレイヤとを含む複数のプレイヤが対戦する対戦パートであって、対戦可能な回数が対戦するプレイヤの数で除することにより１以上の余りが生じる回数に定められている特定の対戦パートを実行する第１ステップと、特定の対戦パートにおける対戦毎に、対戦するプレイヤのうちから他のプレイヤよりも有利となるオーナープレイヤを設定する第２ステップとを実行させ、対戦するプレイヤ各々には、特定の対戦パートに関する有利度が関連付けられており、第２ステップは、余り分の対戦におけるオーナープレイヤとして設定するプレイヤであって、当該特定の対戦パートにおいてオーナープレイヤとして対戦を行う回数が他のいずれかのプレイヤよりも多くなるプレイヤを、対戦するプレイヤ各々に関連付けられている有利度に基づいて決定する。

一実施形態のある局面によれば、プロセッサ、メモリ、および入力部を備えるコンピュータにおいて実行されるゲーム方法が提供される。ゲーム方法は、コンピュータが、ゲーム方法は、コンピュータが、ユーザによる操作プレイヤと対戦プレイヤとを含む複数のプレイヤが対戦する対戦パートであって、対戦可能な回数が対戦するプレイヤの数で除することにより１以上の余りが生じる回数に定められている特定の対戦パートを実行する第１ステップと、特定の対戦パートにおける対戦毎に、対戦するプレイヤのうちから他のプレイヤよりも有利となるオーナープレイヤを設定する第２ステップとを備え、対戦するプレイヤ各々には、特定の対戦パートに関する有利度が関連付けられており、第２ステップは、余り分の対戦におけるオーナープレイヤとして設定するプレイヤであって、当該特定の対戦パートにおいてオーナープレイヤとして対戦を行う回数が他のいずれかのプレイヤよりも多くなるプレイヤを、対戦するプレイヤ各々に関連付けられている有利度に基づいて決定する。

一実施形態のある局面によれば、ゲームプログラムを記憶する記憶部と、ゲームプログラムを実行することにより、情報処理装置の動作を制御する制御部とを備える情報処理装置が提供される。制御部は、ユーザによる操作プレイヤと対戦プレイヤとを含む複数のプレイヤが対戦する対戦パートであって、対戦可能な回数が対戦するプレイヤの数で除することにより１以上の余りが生じる回数に定められている特定の対戦パートを実行する第１ステップと、特定の対戦パートにおける対戦毎に、対戦するプレイヤのうちから他のプレイヤよりも有利となるオーナープレイヤを設定する第２ステップとを実行し、対戦するプレイヤ各々には、特定の対戦パートに関する有利度が関連付けられており、第２ステップは、余り分の対戦におけるオーナープレイヤとして設定するプレイヤであって、当該特定の対戦パートにおいてオーナープレイヤとして対戦を行う回数が他のいずれかのプレイヤよりも多くなるプレイヤを、対戦するプレイヤ各々に関連付けられている有利度に基づいて決定する。

本発明によれば、ゲームの興趣が低下する懸念を抑えることができる。

ゲームシステムの全体的な構成を示す模式図である。 ユーザ端末の機能的構成を示す図である。 ゲームサーバの機能的構成を示すブロック図である。 キャラクタパラメータ管理テーブルの一例を示す図である。 キャラクタスキル管理テーブルの一例を示す図である。 配牌スキル管理テーブルの一例を示す図である。 ツモスキル管理テーブルの一例を示す図である。 （Ａ）はユーザ１によって作成された編成管理テーブルの一例を示す図であり、（Ｂ）はユーザ２によって作成された編成管理テーブルの一例を示す図であり、（Ｃ）はユーザ３によって作成された編成管理テーブルの一例を示す図であり、（Ｄ）はユーザ４によって作成された編成管理テーブルの一例を示す図である。 編成情報管理テーブルの一例を示す図である。 対戦プレイモードにおいてユーザ側プログラムによって実行されるキャラクタ編成処理の一例を示すフローチャートである。 対戦プレイモードにおいて管理者側プログラムによって実行されるエントリー処理の一例を示すフローチャートである。 対戦プレイモードにおいて管理者側プログラムによって実行される起家決定処理の一例を示すフローチャートである。 対戦プレイモードにおいて管理者側プログラムによって実行される対局前処理の一例を示すフローチャートである。 対戦プレイモードにおいてユーザ側プログラムによって実行される対局処理の一例を示すフローチャートである。 （Ａ）は編成画面の一例を示す図であり、（Ｂ）は対局画面の一例を示す図である。

以下、図面を参照しつつ、本発明の実施の形態について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称および機能も同じである。したがって、それらについての詳細な説明は繰り返さない。

図１は、ゲームシステム１の全体的な構成を示す模式図である。本実施形態では、ゲームシステム１は、役の成立により特典（例えば点数等）を付与するゲームを提供する。ゲームの種類としては、ユーザ（プレイヤ）によって操作されるキャラクタが、他のユーザによって操作されるキャラクタまたはＮＰＣ（ノンプレイヤキャラクタ）と対戦可能な麻雀ゲームを例示する。

麻雀ゲームでは、部屋の麻雀卓に積まれた１３６枚あまりの牌（識別情報）の山から牌をプレイヤ毎に１つずつ引き、１４枚〜１８枚の手牌（当該ユーザが所有する牌）の組合せからなる役の成立を目指す。麻雀ゲームでは、４人のユーザのうちの１人のユーザが親（オーナープレイヤ）となり、残りの３人のユーザが子となって対局を行う。親のポジションは、局の切り替わり時に右隣りのユーザに変更され、各ユーザには、４局につき１局の割合で親が回ってくる。

麻雀ゲームでは、家（自家または他家）、副露、晒すなどの専門用語が用いられる。ここで、家はユーザを意味し、自家は自ユーザを意味し、他家は他ユーザを意味する。また、副露は、ポン、チー、大明槓、暗槓、小明槓の総称であり、晒すは牌の模様を他ユーザに見せることを意味する。

本実施形態の麻雀ゲームは、高校生を表す５人のキャラクタで１チームを編成し、４チームが団体戦で麻雀を行う設定となっている。各チームのキャラクタには、先鋒、次鋒、中堅、副将または大将が、オーダーとして割り当てられる。各チームのキャラクタは、当該オーダーに従って対戦に臨み、当該キャラクタに関連付けられているスキルを発動させながら対戦を進める。各チームには２０万点の点棒が付与され、対戦は点棒を引き継ぎながら実行される。

本実施形態では、麻雀ゲームの対戦モードとして、東風戦、半荘戦、一荘戦および団体戦が設けられており、いずれかの対戦モードがユーザにより選択可能である。対戦モードのうちの団体戦は、５局により構成され、先鋒、次鋒、中堅、副将および大将の各々のキャラクタは、この順で１局だけ対戦を行う。これにより、キャラクタ毎に半荘戦または一荘戦を行うものと比較して、短時間であっても東風戦や、ユーザが５つのキャラクタを選択し、各キャラクタを用いて１局ずつ対戦を行うといった面白みのある団体戦を行うことができ、ユーザの利便性を向上させることができる。なお、団体戦は、対戦の回数（局数）が対戦に臨むチーム数で除することにより１以上の余りが生じる回数に定められている特定の対戦パートに相当する。

先鋒戦、次鋒戦、中堅戦、副将戦および大将戦の各局は、親が上がり続ける限り継続され、親が負けたとき又は流局したときに終了する。今回の対戦（局）が終了すると、右隣りのキャラクタに親が切り替わり、次の対戦（局）が開始される。即ち、親の切替条件は、親が負けたとき又は流局したときに成立する。

なお、ゲームの種類は、ゲームの進行に応じて親が切り替わるゲームであればこれに限らず、例えば、トランプを用いたゲーム（例えばポーカー）などであってもよい。また、ゲームは、役の成立により特典（例えば点数等）を付与するゲームに限らず、ユーザが保有するキャラクタから編成したキャラクタを用いてゲームを行うものであればよく、アクションゲーム、スポーツゲームなどの他のジャンルのゲームであってもよい。

図１に示すように、ゲームシステム１は、複数のユーザ端末１００と、ゲームサーバ２００とを含む。各ユーザ端末１００とゲームサーバ２００とは、ネットワーク２を介して接続されている。ネットワーク２は、インターネット、図示しない無線基地局によって構築される各種移動通信システム（たとえば、所謂３Ｇ、４Ｇ移動通信システム、ＬＴＥ（Long Term Evolution））、または所定のアクセスポイントによってインターネットに接続可能な無線ネットワーク（たとえばWi-Fi（登録商標））を含み得る。

（ユーザ端末およびゲームサーバの構成）
ユーザ端末１００は、スマートフォン、フィーチャーフォン、ＰＤＡ（Personal Digital Assistant）、またはタブレット型コンピュータ等の携帯端末であることがより好ましい。図１に示すように、ユーザ端末１００は、通信バスによって互いに電気的に接続されたプロセッサ１０と、メモリ１１と、ストレージ１２と、通信インターフェース（ＩＦ）１３と、入出力ＩＦ１４と、タッチスクリーン１５とを備える。

入出力ＩＦ１４は、ＵＳＢ（Universal Serial Bus）等を介した各種データ入出力機能、および音声入出力機能を備える。

タッチスクリーン１５は、入力部１５１と表示部１５２とを組合せた電子部品である。入力部１５１は、タッチセンシティブなデバイスであり、たとえばタッチパッド等によって構成される。表示部１５２は、たとえば液晶ディスプレイ、または有機ＥＬ（Electro-Luminescence）ディスプレイ等によって構成される。入力部１５１は、タッチスクリーン１５に対するユーザの指やスタイラスといった物体の接触または近接を検知し、操作入力として受け付ける。入力部１５１は、当該操作入力に含まれるユーザの作用（主に、タッチ操作、スワイプ操作、フリック操作、およびタップ操作等の物理的接触操作）が入力された画面位置の情報を検知して、該情報を外部へ情報信号として出力する機能を備える。タッチスクリーン１５は、タッチセンシティブであればよい。タッチセンシティブなデバイスは、静電容量方式、抵抗膜方式等のどのような方式を採用したものであってもよい。

ゲームサーバ２００は、ゲームに関する各種サービスを各ユーザ端末１００に提供する。ゲームサーバ２００は、ワークステーションまたはパーソナルコンピュータ等の汎用コンピュータであることが、より好ましい。図１に示すように、ゲームサーバ２００は、通信バスによって互いに電気的に接続されたプロセッサ２０と、メモリ２１と、ストレージ２２と、通信インターフェース（ＩＦ）２３と、入出力ＩＦ２４とを備える。

プロセッサ１０、２０は、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）等を含んで構成される。プロセッサ１０は、ユーザ端末１００全体の動作を制御する。プロセッサ２０は、ゲームサーバ２００全体の動作を制御する。

メモリ１１、２１は、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）等の揮発性記憶装置で構成され得る主記憶装置を含んで構成される。

ストレージ１２、２２は、フラッシュメモリまたはＨＤＤ（Hard Disk Drive）などの不揮発性記憶装置によって構成され得る補助記憶装置を含んで構成される。メモリ１１には、プロセッサ１０がストレージ１２からロードした各種プログラムおよびデータが一時的に記憶される。メモリ２１には、プロセッサ２０がストレージ２２からロードした各種プログラムおよびデータが一時的に記憶される。これによりメモリ１１は、プロセッサ１０に対して作業領域を提供する。メモリ２１は、プロセッサ２０に対して作業領域を提供する。

ゲームサーバ２００のストレージ２２には、ゲームプログラム等のゲームデータが格納される。ユーザ端末１００のストレージ１２には、ゲームサーバ２００からダウンロードされるゲームプログラム等のゲームデータが格納される。当該ゲームプログラムは、メモリ１１、２１に展開される。プロセッサ１０は、メモリ１１に展開されるゲームプログラムを実行する。プロセッサ２０は、メモリ２１に展開されるゲームプログラムを実行する。メモリ１１には、プロセッサ１０が当該ゲームプログラムに従って動作している間に生成した各種ゲームデータも一時的に格納される。メモリ２１には、プロセッサ２０が当該ゲームプログラムに従って動作している間に生成した各種ゲームデータも一時的に格納される。

通信ＩＦ１３、２３は、ユーザ端末１００とゲームサーバ２００との間で各種データを送受信するための通信制御機能を備える。通信制御機能には、たとえば、無線ＬＡＮ（Local Area Network）接続機能、有線ＬＡＮ、無線ＬＡＮ、携帯電話回線網を介したインターネット接続機能、近距離無線通信機能等が含まれる。

本実施形態では、各種データは、所定のゲームプログラム、ユーザ情報、ゲーム情報等のゲームデータ、それらをユーザ端末１００とゲームサーバ２００との間に送受信させる指示、および、ゲームを進行させるための指示を含む。

たとえばプロセッサ１０は、通信ＩＦ１３を介してユーザＩＤをゲームサーバ２００に送信することによって、当該ユーザＩＤに関連付けられたオブジェクト（キャラクタ、配牌スキル、ツモスキル、配牌、ツモ牌、捨て牌等）に関する情報をゲームサーバ２００から受信する。また、プロセッサ１０は、ユーザ作用に基づいて麻雀卓に牌を配置し、ゲームの結果として取得されたゲームポイント（点棒）を、通信ＩＦ１３を介してゲームサーバ２００に送信する。

ゲームサーバ２００の入出力ＩＦ２４は、マウス、キーボード等の情報入力機器である入力部、および、液晶ディスプレイ等の出力部を備えており、コンピュータの情報をモニタリングするために用いられる。

（ユーザ端末の機能的構成）
図２は、ユーザ端末１００の機能的構成を示す図である。ユーザ端末１００は、プロセッサ１０、メモリ１１、ストレージ１２、通信ＩＦ１３、および入出力ＩＦ１４等の協働によって、制御部１１０および記憶部１２０として機能し得る。記憶部１２０にはゲームプログラムが格納されている。このゲームプログラムは、主記憶上に展開されかつ制御部１１０において実行される。また、本実施形態では、このゲームプログラムは、プロセッサ１０およびメモリ１１を備えるユーザ端末１００に対し、麻雀ゲームを進行させる制御部１１０および記憶部１２０としてユーザ端末１００を機能させるプログラムである。

制御部１１０は、当該ゲームプログラムによって、作用受付部１１１、端末処理部１１２、タイマー部１１３、端末判定部１１４、表示制御部１１５、報酬計算部１１６、および送受信部１１７として機能し得る。制御部１１０が当該ゲームプログラムに従って動作している間に生成した各種ゲームデータ、および制御部１１０によって利用される各種ゲームデータも、主記憶上に一時的に格納される。

作用受付部１１１は、タッチスクリーン１５の入力部１５１に対するユーザの作用を検知する。作用受付部１１１は、タッチスクリーン１５およびその他の入出力ＩＦ１４を介したコンソールによる操作指示等から、いかなる入力がなされたかを判別し、その結果を端末処理部１１２等の必要な要素に出力する。作用受付部１１１は、タッチスクリーン１５に対する作用入力がなされた場合には、入力位置の座標情報および作用の種類（タッチ操作、スライド動作等）を検知する。また、作用受付部１１１は、連続して検知されていた入力が途切れることを検知することによって、タッチスクリーン１５から接触入力が解除されたことを検知する。

端末処理部１１２は、ユーザ端末１００全体の動作を制御し、各要素間におけるデータの送受信、およびゲームの実行に必要な演算処理その他の処理を行う。端末処理部１１２は、たとえば、作用受付部１１１によって検知された作用に基づいて、ゲームプログラムに従ったゲームを展開させ、その結果を示すゲーム画像を描画するよう、表示制御部１１５に指示する。また、端末処理部１１２は、タッチスクリーン１５に対する操作入力に基づいて仮想空間内におけるゲームオブジェクトを操作する。また、端末処理部１１２は、タッチスクリーン１５に対する操作入力および演算処理の結果等に基づいて、記憶部１２０に記憶されている各種データの更新等の処理を行う。なお、端末処理部１１２は、ゲームの進行状態に応じて、ゲーム空間の視野を指定するための仮想カメラの位置を制御してもよい。

タイマー部１１３は、麻雀部屋内の時刻を規定するとともに、麻雀部屋内の時間の経過を計測する。タイマー部１１３は、たとえば、牌がツモられた時刻を記憶部１２０に記憶させ、その後に経過した時間を測定する。タイマー部１１３は、測定することによって得られる時間情報を端末判定部１１４に提供する。端末判定部１１４は、タイマー部１１３および記憶部１２０を参照して、今回のツモから所定時間が経過したか否かなどを判定できる。

表示制御部１１５は、ゲームサーバ２００から受信したユーザ情報、ゲームプログラムによる演算結果、およびユーザの入力部１５１に対する作用に基づいて、表示部１５２に表示される画像を生成する。本実施形態では、ユーザ端末１００は、配牌、牌山、ツモ牌、捨て牌、ポン、チー、カン、ロンあがり、ツモあがり、流局等などの対局の開始から終了までに刻々と変化するゲーム情報をゲームサーバ２００から取得し、この情報を用いて対局画面の画像を生成する。なお、これらのゲーム情報は、ユーザ端末１００側においても記憶しているものであってもよい。表示制御部１１５は、端末処理部１１２によるゲーム進行制御に応じて表示画像を更新する。

報酬計算部１１６は、作用受付部１１１から受信した操作に基づいて、各ユーザに提供される報酬を算出して、ユーザに付与する。たとえば報酬計算部１１６は、ユーザに付与される点棒を算出し、ユーザに付与する。

送受信部１１７は、ゲームサーバ２００から各種情報を受信したり、ゲームサーバ２００に各種情報を送信したりする。送受信部１１７は、制御部１１０の制御によって各種情報をゲームサーバ２００に対して送信する。ゲームサーバ２００は、ネットワーク２および通信ＩＦ２３を介して当該情報を受信し、送受信部２１１が情報の内容を識別して受け付ける。送受信部１１７は、たとえば、ユーザ端末１００上で動作可能なゲームプログラム、ユーザ情報、ゲーム画面等のゲーム空間情報、自ユーザの配牌、牌山、他のユーザの捨て牌、他のユーザによるポン、チー、カン、ロンあがり、ツモあがり等のゲーム情報を、ゲームサーバ２００から受信することができる。なお、これらの情報は、ユーザ端末１００側においても記憶しているものであってもよい。一方、送受信部１１７は、ユーザ情報、自ユーザの捨て牌、自ユーザによるポン、チー、カン、ロンあがり、ツモあがり等のゲーム情報を、ゲームサーバ２００に送信することができる。

記憶部１２０には、制御部１１０が前述の各部として機能するために必要なデータが記憶されている。当該データとしては、たとえば、ゲームプログラム、ゲーム情報、およびユーザ情報が含まれる。ゲーム情報としては、オブジェクト管理テーブル等が挙げられる。ユーザ情報としては、ユーザ管理テーブル等が挙げられる。

本実施形態では、ゲームプログラムは、ユーザの立場で麻雀ゲームを進めるユーザ側プログラムと、管理者の立場で当該麻雀ゲームを取り仕切る管理者側プログラムとによって構成されている。また、本実施形態では、自ユーザにより操作されるキャラクタが３人のＮＰＣと対局を行うシングルプレイモードと、自ユーザにより操作されるキャラクタが３人の他ユーザによりそれぞれ操作される３人のキャラクタとオンラインで対局を行う対戦プレイモードとが準備されている。

このうち、シングルプレイモードでは、自ユーザと３人のＮＰＣとで麻雀卓を囲むパーティが構成され、対局が開始される。一方、対戦プレイモードでは、ユーザ１〜４のうちのいずれか１人がホストとして部屋を作り、残りの３人のユーザがゲストとして当該部屋に入ることで、麻雀卓を囲むパーティが構成され、対局が開始される。管理者側プログラムは、ホスト役のユーザによって操作されるユーザ端末１００において起動し、対局を仕切る。

本実施形態では、麻雀ゲームに用いる情報が各ユーザのユーザ端末１００において管理されている。図４は、ユーザ端末１００の記憶部１２０において管理されている情報のうち、各ユーザが獲得しているキャラクタのパラメータを管理するためのキャラクタパラメータ管理テーブル３０１を示しており、図５は、各ユーザが獲得しているキャラクタのスキルを管理するためのキャラクタスキル管理テーブル３０２を示している。このため、キャラクタパラメータ管理テーブル３０１およびキャラクタスキル管理テーブル３０２の設定内容は、ユーザ毎に異なる。

また、図６に示す配牌スキル管理テーブル３０３と、図７に示すツモスキル管理テーブル３０４とは、当該ユーザ端末１００の記憶部１２０にデフォルトで設けられる。ただし、各テーブルに設定された配牌スキルまたはツモスキルは、運営側の操作により更新可能である。

さらに、対戦プレイモードのために、ユーザ１が操作するユーザ端末１００の記憶部１２０には、図８（Ａ）に示す編成管理テーブル３０５ａが設けられており、ユーザ２が操作するユーザ端末１００の記憶部１２０には、図８（Ｂ）に示す編成管理テーブル３０５ｂが設けられており、ユーザ３が操作するユーザ端末１００の記憶部１２０には、図８（Ｃ）に示す編成管理テーブル３０５ｃが設けられており、ユーザ４が操作するユーザ端末１００の記憶部１２０には、図８（Ｄ）に示す編成管理テーブル３０５ｄが設けられている。編成管理テーブル３０５ａ〜３０５ｄの設定も、ユーザ操作に応じて更新される。

キャラクタは、所定の抽選（いわゆるガチャ）により獲得され、あるいはユーザがクリアしたイベント（いわゆるステージ、クエストともいう。）の報酬として獲得される。このため、ユーザ１〜４の各々が獲得しているキャラクタの数や種類は、抽選回数、抽選結果、イベントのクリア回数等に応じて異なる。また、抽選においては、獲得可能な複数種類のキャラクタや、キャラクタ各々の獲得率などが定められた抽選テーブルが用いられる。抽選テーブル（獲得可能なキャラクタや獲得率など）は、ゲームサーバ２００において管理されており、随時更新される。抽選テーブルが更新されることにより、ユーザが獲得可能となるキャラクタが新たに追加・更新される。

図９に示す編成情報管理テーブル３０６は、対戦プレイモードにおいて編成管理テーブル３０５ａ〜３０５ｄの設定が完了した後に、ホスト役のユーザが操作するユーザ端末１００の記憶部１２０に設けられる。

（ゲームサーバの機能的構成）
図３は、ゲームサーバ２００の機能的構成を示すブロック図である。ゲームサーバ２００は、各ユーザ端末１００にゲーム進行に必要な情報を提供するゲーム提供機能を有している。ゲームサーバ２００は、ユーザ端末１００からゲーム情報を受信し、ユーザ端末１００上で動作可能なゲームプログラム、Ｗｅｂページ（ゲーム画面等）、ユーザ情報およびゲームパラメータ等の各種ゲームデータ、各種通知等を送信する。ゲームサーバ２００は、プロセッサ２０、メモリ２１、ストレージ２２、通信ＩＦ２３、入出力ＩＦ２４等の協働によって、制御部２１０および記憶部２２０として機能し得る。

図３に示すように、制御部２１０は、記憶部２２０に格納されたゲームプログラムによって、送受信部２１１、サーバ処理部２１２、データ管理部２１３、マッチング部２１４、計測部２１５として機能し得る。本実施形態では、このゲームプログラムは、プロセッサ２０およびメモリ２１を備えるゲームサーバ２００に対し、麻雀ゲームを進行させる制御部２１０および記憶部２２０としてゲームサーバ２００を機能させるプログラムであり、管理者の立場で当該麻雀ゲームを取り仕切る上述の管理者側プログラムも含んでいる。

送受信部２１１は、各ユーザ端末１００から送信される各種情報を受信したり、各ユーザ端末１００に各種情報を送信したりする。

各ユーザ端末１００は、制御部１１０の制御に基づいて各種情報をゲームサーバ２００に対して送信する。ゲームサーバ２００は、ネットワーク２および通信ＩＦ２３を介して当該情報を受信し、送受信部２１１が情報の内容を識別して受け付ける。

送受信部２１１は、記憶部２２０に格納されている各種管理テーブルを参照する。送受信部２１１は、必要に応じてデータ管理部２１３によって更新された各種管理テーブルを参照して、必要な処理を実行する。当該情報には、各ユーザに配られる牌の組合せを特定するための配牌情報、配牌の後に残った牌を特定するための牌山情報、各ユーザによるポン、チー、カンなどの情報が含まれる。

また、送受信部２１１は、ユーザ端末１００上で動作可能なゲームプログラム、ユーザ情報、ゲーム画面等のゲーム空間情報、各ユーザの配牌、牌山、各ユーザの捨て牌、各ユーザによるポン、チー、カン、ロンあがり、ツモあがり等のゲーム情報をユーザ端末１００に送信する。

サーバ処理部２１２は、ゲームサーバ２００全体の動作を制御し、各要素間におけるデータの送受信、および、ゲームの進行に必要な演算処理を行う。サーバ処理部２１２は、たとえば、送受信部２１１が受信したユーザ端末１００からの情報または要求に基づいて、ゲームプログラムに従った演算処理を実行する。そして、その結果としての各種ユーザ情報、ゲーム情報等のゲームデータ、およびゲームプログラム等を、通信ＩＦ１３を介してユーザ端末１００に送信することによって、ユーザ端末１００においてさらにゲームを進行させる。

データ管理部２１３は、サーバ処理部２１２における各種演算結果に基づいて、記憶部２２０に格納されている各種ゲームデータ、およびデータベースのレコードを、追加、更新、または削除することによって、必要な処理を実行する。

送受信部２１１は、例えば、ユーザが麻雀卓に牌を晒すようにユーザ端末１００に作用を与えると、その結果としてユーザが保有するオブジェクト情報およびゲームポイントに関する情報をユーザ端末１００から受信する。サーバ処理部２１２は、受信された情報に基づいて必要な処理を実行し、一方、データ管理部２１３はユーザ情報およびゲーム情報を更新する。

また、例えば、送受信部２１１がユーザ端末１００から捨て牌を実行する要求を受信した場合、データ管理部２１３は、捨て牌の情報を、ユーザ情報と、捨て牌の配置位置等に関するゲーム情報とに関連付けて記憶する。

マッチング部２１４は、複数のユーザを所定のゲーム空間に関連付ける。たとえばマッチング部２１４は、ユーザがホストとして部屋を作る操作を行った場合、当該ユーザをホストとし、他のプレイヤをゲストとするパーティをマッチングによって組成し、当該パーティに属する複数のプレイヤを同じ麻雀部屋に一時的に関連付ける。

計測部２１５は、タイマー部１１３と同様に、麻雀部屋内の時刻を規定するとともに、麻雀部屋内の時間を計測する機能を有する。計測部２１５は、例えば、対局開始時に発動させたいスキルを選択するための画面が表示された時刻からの経過時間を計測する。計測部２１５は、麻雀部屋の時間情報を生成し、タイマー部１１３で生成された麻雀部屋の時間情報と照合する。これにより、ユーザ端末１００とゲームサーバ２００において麻雀部屋の時間情報が同期され、各種時間情報の計測および判定を円滑に実施し得る。

記憶部２２０には、ゲームプログラムおよびユーザの認証プログラム等が格納されている。また、記憶部２２０には、ユーザ管理テーブル等のユーザ情報、オブジェクト管理テーブル等のゲーム情報を管理するデータベースが構築されていてもよい。記憶部２２０には、図４に示すキャラクタパラメータ管理テーブル３０１と、図５に示すキャラクタスキル管理テーブル３０２と、図６に示す配牌スキル管理テーブル３０３と、図７に示すツモスキル管理テーブル３０４と、図８（Ａ）〜図８（Ｄ）に示す編成管理テーブル３０５ａ〜３０５ｄと、図９に示す編成情報管理テーブル３０６とを設けるようにしてもよい。

（キャラクタパラメータ管理テーブル）
図４を参照して、キャラクタパラメータ管理テーブル３０１は、高校生を表す複数のキャラクタのグループ属性（高校および学年）を管理するとともに、団体戦に関するキャラクタの有利度を規定する雀力およびオーダー適性を管理する。

雀力およびオーダー適性はいずれも、当該キャラクタの強さに関するパラメータである。雀力は、当該キャラクタが強いほど高い値を示すところ、団体戦における当該キャラクタのオーダーが当該キャラクタのオーダー適性と一致すれば、雀力は例えば１．２倍に補正される。即ち、オーダー適性は、当該キャラクタが当該オーダーでの対戦において自分本来の能力を発揮できる度合いを示すパラメータであり、“相性”に置き換えてもよい。

図４によれば、キャラクタＡ１のグループ属性はＷＷ高校２年生を表し、キャラクタＢ１のグループ属性はＷＷ高校２年生を表し、キャラクタＣ１のグループ属性はＷＷ高校２年生を表し、キャラクタＤ１のグループ属性はＷＷ高校２年生を表し、キャラクタＥ１のグループ属性はＷＷ高校１年生を表す。

キャラクタＡ１については、雀力は１２００ポイントに設定され、オーダー適性は大将に設定される。キャラクタＢ１については、雀力は９００ポイントに設定され、オーダー適性は次鋒に設定される。キャラクタＣ１については、雀力は１４００ポイントに設定され、オーダー適性は副将に設定される。キャラクタＤ１については、雀力は８００ポイントに設定され、オーダー適性は先鋒に設定される。キャラクタＥ１については、雀力は１０００ポイントに設定され、オーダー適性は中堅に設定される。

（キャラクタスキル管理テーブル）
図５を参照して、キャラクタスキル管理テーブル３０２は、当該複数のキャラクタの各々に関連付けられた配牌スキルと、ツモスキルとを管理する。ここで、配牌スキルは、対局開始時の配牌の組合せに関するスキルであり、対局開始時に発動可能である。一方、ツモスキルは、対局中のツモ牌の引き等に関するスキルであり、対局中に発動可能である。団体戦に関するキャラクタの有利度は、配牌スキルおよびツモスキルによっても規定される。

図５によれば、キャラクタＡ１には、配牌スキルとして筒子マスターが関連付けられ、ツモスキルとして爆速街道が関連付けられる。キャラクタＢ１には、配牌スキルとして索子マスターが関連付けられ、ツモスキルとして気合乗せが関連付けられる。キャラクタＣ１には、配牌スキルとして対子爆弾が関連付けられ、ツモスキルとして危機感知能力が関連付けられる。キャラクタＤ１には、配牌スキルとして断ヤオマスターが関連付けられ、ツモスキルとして必殺河拾いが関連付けられる。キャラクタＥ１には、配牌スキルとして槓子爆弾が関連付けられ、ツモスキルとして秘技ツバメ返しが関連付けられる。

なお、本実施形態では、ユーザが同じキャラクタを複数（重複）保有することはなく、同じキャラクタがキャラクタパラメータ管理テーブル３０１およびキャラクタスキル管理テーブル３０２の各々に重複して設定されることはない。即ち、各ユーザは、同じキャラクタを重複して保有することはできない。これによって、異なるキャラクタによるチーム編成ひいては戦術の多様化が促される（戦術の固定化が抑制される）。抽選やイベントクリアにより、既に保有しているキャラクタを獲得した場合には、既に保有しているキャラクタが強化（例えば、各種パラメータが向上）されるか、キャラクタを強化するための素材アイテムが付与されるなどの報酬がユーザに付与される。

（配牌スキル管理テーブル）
図６を参照して、配牌スキル管理テーブル３０３は、対局開始時に発動可能な配牌スキルの詳細と、当該配牌スキルを発動させるための条件と、当該配牌スキルの起家適性とを管理する。起家とは、初回の対戦で親となるキャラクタのことである。本実施形態では、団体戦形式の麻雀ゲームを想定しているため、先鋒戦に臨む４人のキャラクタのうちのいずれか１人のキャラクタが起家となる。

起家適性とは、当該配牌スキルが関連付けられているキャラクタが起家になり易い割合を示すパラメータである。このため、起家適性がありに設定されている配牌スキルが関連付けられているキャラクタは、起家適性がありに設定されていない配牌スキルが関連付けられているキャラクタよりも、起家になり易い。

配牌スキルは、対局開始時の配牌の組合せに関するスキルであり、筒子マスター、索子マスター、萬子マスター、字牌マスター、断ヤオマスター、三元メイカー、四喜メイカー、暗刻爆弾、順子爆弾、対子爆弾および槓子爆弾が設定される。

筒子マスターは８枚以上の筒子を配牌に含めるスキルであり、索子マスターは８枚以上の索子を配牌に含めるスキルであり、萬子マスターは８枚以上の萬子を配牌に含めるスキルであり、字牌マスターは９枚以上の字牌を配牌に含めるスキルであり、断ヤオマスターは１０枚以上の断ヤオ牌を配牌に含めるスキルである。

三元メイカーは大三元のタネを６枚以上配牌に含めるスキルであり、四喜メイカーは小四喜のタネを７枚以上配牌に含めるスキルであり、暗刻爆弾は２組以上の暗刻を配牌に含めるスキルであり、順子爆弾は２組以上の順子を配牌に含めるスキルであり、対子爆弾は４組以上の対子を配牌に含めるスキルであり、槓子爆弾は１組以上の槓子を配牌に含めるスキルである。

各々の配牌スキルには、スキル発動条件が関連付けられている。筒子マスターについては、大将戦またはキャラクタが子となる対局でスキル発動条件が成立する。索子マスターについては、キャラクタが親となる対局でスキル発動条件が成立する。萬子マスターについては、キャラクタの順位が最下位の対局でスキル発動条件が成立する。字牌マスターについては、先鋒戦でスキル発動条件が成立する。断ヤオマスターについては、中堅戦でスキル発動条件が成立する。

三元メイカーについては、キャラクタが子となる対局でスキル発動条件が成立する。四喜メイカーについては、次鋒戦でスキル発動条件が成立する。暗刻爆弾については、トップとの点数差が２００００点以上の対局でスキル発動条件が成立する。順子爆弾については、キャラクタが親となる対局でスキル発動条件が成立する。対子爆弾については、副将戦またはキャラクタが親となる対局でスキル発動条件が成立する。槓子爆弾については、キャラクタの順位が最下位の対局でスキル発動条件が成立する。

スキル発動条件に先鋒戦または親が規定されている配牌スキルについては、起家適性がありに設定される。また、スキル発動条件に先鋒戦および親のいずれも規定されていない配牌スキルについては、起家適性がなしに設定される。このため、索子マスター、字牌マスター、順子爆弾および対子爆弾の起家適性は、ありを示す。

なお、対局の状況が不利であるほどスキル発動条件が成立し易くなるように当該スキル発動条件を規定すれば、配牌スキルの発動による逆転可能性が高くなり、ひいてはゲームの興趣が高くなる。また、図６におけるスキル発動条件は、スキルに対して予め定められている例について説明したが、これに限らず、同じスキルであっても、当該スキルを備えるキャラクタの種類や団体戦の進行状況（戦況等）に応じて異なるようにしてもよい。

（ツモスキル管理テーブル）
図７を参照して、ツモスキル管理テーブル３０４は、対局中に発動可能なツモスキルの詳細と、当該ツモスキルを発動させるための条件とを管理する。また、ツモスキルとしては、筒子無双、索子無双、萬子無双、字牌無双、断ヤオ無双、ヤオ九無双、ないものねだり、強欲な右手、無難な左手、未来予知、危機察知能力、ぶっこ抜き、秘技ツバメ返し、怒涛のスリカエ、必殺河拾い、爆速街道、気合い乗せ、危機感知能力が設定される。

ツモスキルの種類としては、特定の種類の牌が引き易くなるスキルを含む。例えば、筒子無双は３巡連続で筒子を引き寄せるスキルであり、索子無双は３巡連続で索子を引き寄せるスキルである。萬子無双は３巡連続で萬子を引き寄せるスキルであり、字牌無双は３巡連続で字牌を引き寄せるスキルである。断ヤオ無双は３巡連続で断ヤオ牌を引き寄せるスキルであり、ヤオ九無双は３巡連続でヤオ九牌を引き寄せるスキルである。

ツモスキルの種類としては、自家の手牌またはツモ牌の履歴に基づいて定まる牌が引き易くなるスキルを含む。例えば、ないものねだりは、３巡連続でこれまでに一度も引いていない牌を引き寄せるスキルである。強欲な右手は、３巡連続で既に手牌に持っている牌を引き寄せるスキルである。無難な左手は、３巡連続でまだ一度も捨てていない牌を引き寄せるスキルである。

ツモスキルの種類としては、将来のツモ牌をユーザに報知するスキルを含む。例えば、未来予知は、３回分の未来のツモ牌を予知するスキルである。ツモスキルの種類としては、他家の手牌または捨て牌の履歴に基づいて、ユーザに有利な情報を報知するものであるとしてもよい。例えば、危機察知能力は、捨てようとした牌が誰かの当たり牌だった場合、危機を察知して捨てないようにナビゲーションをしてくれるスキルである。

ツモスキルの種類としては、自家の手牌の少なくとも一部を山牌または捨て牌と入れ替えるスキルを含む。例えば、ぶっこ抜きは、指定した４牌を山の４牌と入れ替えるスキルである。秘技ツバメ返しは、手牌全てを山牌と入れ替えるスキルである。怒涛のスリカエは、ツモった牌が気に入らなければ、次の牌とすり替えることができるスキルである。必殺河拾いは、捨て牌を河から拾い、代わりに手牌１枚を河に置くスキルである。

ツモスキルの種類としては、上述のスキルのほかに、自家にとって有利となるツモ牌を引く様々なスキルを含む。例えば、爆速街道は、シャンテン数が１つ下がるツモをするスキルである。気合い乗せは、裏ドラが必ず乗るようにするスキルである。危機感知能力は、指定した種類の牌が危険牌かどうかわかるスキルである。

なお、危機察知能力では、捨てようとする牌の指定が求められるのに対して、危機感知能力では、牌の種類の指定が求められるに留まる。このため、危機の到来を予知する能力としては、危機察知能力の方が危機感知能力よりも精度が高いと言える。また、シャンテンとは、最短で何回ツモればテンパイ可能かを示す用語である。

スキル発動条件としては、例えばテンパイに至るまでのシャンテン数に基づいたものとしてもよい。図７の例では、筒子無双のスキル発動条件は、自家のキャラクタの手牌が３シャンテン以上のときに成立する。スキル発動条件としては、例えば、自家の順位、場（東何局であるか等）、局における捨て牌の巡目（残りの山牌の数）に基づいたものとしてもよい。図７の例では、ないものねだりのスキル発動条件は、自家のキャラクタが２着以下で自家のキャラクタの手牌が３シャンテン以下のときに成立する。スキル発動条件としては、例えば、自家のキャラクタまたは他家のキャラクタの行動に基づいたものとしてもよい。図７の例では、気合い乗せのスキル発動条件は、自家のキャラクタがリーチした後に成立する。

なお、図７におけるスキル発動条件は、スキルに対して予め定められている例について説明したが、これに限らず、同じスキルであっても、当該スキルを備えるキャラクタの種類や団体戦の進行状況（戦況等）に応じて異なるようにしてもよい。

（編成管理テーブル）
対戦プレイモードでは、ユーザからの操作に基づいて、ＷＷ高校、ＸＸ高校、ＹＹ高校およびＺＺ高校に所属する複数のキャラクタのうちから麻雀ゲームに用いる５人の操作キャラクタが編成される。

具体的には、図８（Ａ）に示す編成管理テーブル３０５ａには、ユーザ１のユーザ端末１００が管理するキャラクタパラメータ管理テーブル３０１上の複数のキャラクタのうち、ユーザ１の操作に従う５人のキャラクタが登録される。図８（Ｂ）に示す編成管理テーブル３０５ｂには、ユーザ２のユーザ端末１００が管理するキャラクタパラメータ管理テーブル３０１上の複数のキャラクタのうち、ユーザ２の操作に従う５人のキャラクタが登録される。

図８（Ｃ）に示す編成管理テーブル３０５ｃには、ユーザ３のユーザ端末１００が管理するキャラクタパラメータ管理テーブル３０１上の複数のキャラクタのうち、ユーザ３の操作に従う５人のキャラクタが登録される。図８（Ｄ）に示す編成管理テーブル３０５ｄには、ユーザ４のユーザ端末１００が管理するキャラクタパラメータ管理テーブル３０１上の複数のキャラクタのうち、ユーザ４の操作に従う５人のキャラクタが登録される。

この結果、例えば編成管理テーブル３０５ａにおいては、キャラクタＥ１が先鋒として編成され、キャラクタＡ４が次鋒として編成され、キャラクタＣ１が中堅として編成され、キャラクタＤ３が副将として編成され、キャラクタＢ２が大将として編成される。

（編成情報管理テーブル）
図９を参照して、ホスト役のユーザが操作するユーザ端末１００の記憶部１２０またはゲームサーバ２００の記憶部２２０には、編成情報管理テーブル３０６が作成される。具体的には、編成情報管理テーブル３０６は、対戦プレイモードにおいて、図８（Ａ）〜図８（Ｄ）に示す編成管理テーブル３０５ａ〜３０５ｄが作成された後、当該管理テーブル３０５ａ〜３０５ｄの設定に基づいて作成される。この結果、編成情報管理テーブル３０６には、当該管理テーブル３０５ａ〜３０５ｄに設定されたキャラクタおよびオーダーが反映される。

（対戦プレイモードにおける動作について）
対戦プレイモードが選択されたとき、ユーザ端末１００の制御部１１０は、記憶部１２０に記憶されたユーザ側プログラムに従って、図１０に示すキャラクタ編成処理を実行する。ここでは、ユーザ１が操作するユーザ端末１００におけるキャラクタ編成処理を念頭において説明するが、ユーザ２〜４の各々が操作するユーザ端末１００においても同様のキャラクタ編成処理が実行される。また、キャラクタ編成処理に関連して、ホスト役のユーザが操作するユーザ端末１００の制御部１１０は、管理者側プログラムに従って、図１１に示すエントリー処理を実行する。

このうち、図１０に示すキャラクタ編成処理は、キャラクタパラメータ管理テーブル３０１に設定された複数のキャラクタのうちから団体戦に挑む５人のキャラクタを編成する編成パートに対応する処理である。また、図１１に示すエントリー処理は、団体戦への参加申込みをユーザ１〜４の各々から受付ける処理である。当該エントリー処理は、ゲームサーバ２００で実行し、処理結果を各ユーザ端末１００に送信するようにしてもよい。

図１０を参照して、ステップＳ０１では、図１５（Ａ）に示す編成画面をタッチスクリーン１５に表示する。図１５（Ａ）によれば、当該編成画面は、編成キャラクタエリアＴＭ１と、候補キャラクタエリアＣＨ１とを有する。候補キャラクタエリアＣＨ１の下側には、「部屋を作る」ボタンと、「部屋に入る」ボタンと、「戻る」ボタンとが表示される。このうち、「部屋を作る」ボタンは、自分がホストとなって対局を開始するためのボタンであり、「部屋に入る」ボタンは、ホストが作成した部屋にゲストとして入って対局を開始するためのボタンである。

編成キャラクタエリアＴＭ１には、図８（Ａ）に示す編成管理テーブル３０５ａに設定された５人のキャラクタが、スクロール表示可能な態様で表示される。各キャラクタの上側には、当該キャラクタのオーダーが表示され、各キャラクタの下側には、当該キャラクタのグループ属性が表示される。

より具体的には、編成キャラクタエリアＴＭ１には、５人のキャラクタのうちの３人が表示される。図１５（Ａ）においては、左側のキャラクタの上側に表示されたオーダーは次鋒を示し、中央のキャラクタの上側に表示されたオーダーは中堅を示し、右側のキャラクタの上側に表示されたオーダーは副将を示す。また、左側のキャラクタの下側に表示されたグループ属性はＺＺ高校３年を示し、中央のキャラクタの下側に表示されたグループ属性はＷＷ高校２年を示し、右側のキャラクタの下側に表示されたグループ属性はＹＹ高校２年を示す。

候補キャラクタエリアＣＨ１には、キャラクタパラメータ管理テーブル３０１に設定された複数のキャラクタが、スクロール表示可能な態様で表示される。当該複数のキャラクタのいずれか１人がタッチされると、タッチされたキャラクタのグループ属性と各種パラメータとが、編成キャラクタエリアＴＭ１の下端部に表示される。

より具体的には、候補キャラクタエリアＣＨ１には、当該複数のキャラクタのうちの４人が表示される。図１５（Ａ）は、このうち最も左側のキャラクタＥ２がタッチされた状態を示し、この結果、キャラクタＥ２のグループ属性と各種パラメータとが編成キャラクタエリアＴＭ１の下端部に表示される。

ステップＳ０２では、キャラクタの編成を変更する操作（以下、変更操作ともいう。）が行われたか否かを、タッチスクリーン１５に対する操作入力に基づいて判定する。候補キャラクタエリアＣＨ１に表示されたいずれかのキャラクタがタッチされ、タッチ位置が編成キャラクタエリアＴＭ１に表示されたいずれかのメインキャラクタの位置に移動されると、変更操作が行われたと判定される。このときはステップＳ０３に進み、編成管理テーブル３０５ａを更新する。

具体的には、候補キャラクタエリアＣＨ１上でタッチされたキャラクタを、タッチ位置の移動先に表示されたキャラクタの代わりに編成管理テーブル３０５ａに設定する。例えば、候補キャラクタエリアＣＨ１に表示されたキャラクタＥ２がタッチされ、タッチ位置が編成キャラクタエリアＴＭ１に表示された中堅のキャラクタＣ１の位置に移動されると、編成管理テーブル３０５ａに中堅として設定されたキャラクタＣ１がキャラクタＥ２に代替設定される。

ステップＳ０４では、更新された編成管理テーブル３０５ａに対応するように、編成画面を更新する。即ち、キャラクタＥ２がタッチされた状態で、タッチ位置が中堅のキャラクタＣ１の位置に移動された場合は、キャラクタＣ１がキャラクタＥ２に更新される。更新が完了すると、ステップＳ０５に進む。なお、ステップＳ０２において変更操作が行われたと判定されなかったときは、ステップＳ０３およびＳ０４の処理を行うことなくステップＳ０５に進む。

ステップＳ０５では、「部屋を作る」ボタンまたは「部屋に入る」ボタンがタッチされたか否かを、タッチスクリーン１５に対する操作入力に基づいて判定する。「部屋を作る」ボタンまたは「部屋に入る」ボタンがタッチされたと判定されなかったときは、ステップＳ０６に進む。ステップＳ０６では、「戻る」ボタンがタッチされたか否かを、タッチスクリーン１５に対する操作入力に基づいて判定する。「戻る」ボタンがタッチされたと判定されなかったときはステップＳ０２に戻り、「戻る」ボタンがタッチされたと判定されたときはキャラクタ編成処理を終了する。

ステップＳ０５で「部屋を作る」ボタンまたは「部屋に入る」ボタンがタッチされたと判定されたときはステップＳ０７に進み、編成管理テーブル３０５ａをゲームサーバ２００に通知する。

なお、ユーザ２が操作するユーザ端末１００においては、編成管理テーブル３０５ｂを対象として上述の処理が実行され、ユーザ３が操作するユーザ端末１００においては、編成管理テーブル３０５ｃを対象として上述の処理が実行され、ユーザ４が操作するユーザ端末１００においては、編成管理テーブル３０５ｄを対象として上述の処理が実行される。また、本実施形態では、ユーザ１〜４のうちのいずれか１人がホストとして部屋を作り、残りの３人がゲストとして部屋に入る。

ゲームサーバ２００は、ユーザ１〜４からなるパーティをマッチングによって組成し、このうちホスト役のユーザが操作するユーザ端末１００に対して編成管理テーブル３０５ａ〜３０５ｄを通知する。

図１１に遷って、ステップＳ１１では、編成管理テーブル３０５ａ〜３０５ｄがゲームサーバ２００から通知されたか否かを、通信ＩＦ１３による受信データに基づいて判定する。編成管理テーブル３０５ａ〜３０５ｄが通知されたと判定されれば、ステップＳ１２に進む。ステップＳ１２では、当該編成管理テーブル３０５ａ〜３０５ｄに基づいて図９に示す編成情報管理テーブル３０６を作成する。ステップＳ１２の処理が完了すると、ステップＳ１３に進み、エントリー完了をゲームサーバ２００に通知する。エントリー処理は、エントリー完了の通知の後に終了する。

ゲームサーバ２００は、ステップＳ１３の処理によって通知されたエントリー完了をユーザ１〜４の各々が操作するユーザ端末１００に送信する。図１０に戻って、ステップＳ０８では、当該エントリー完了がゲームサーバ２００から通知されたか否かを、通信ＩＦ１３による受信データに基づいて判定する。当該エントリー完了が通知されたと判定されると、キャラクタ編成処理を終了する。

エントリー処理が完了した後、ホスト役のユーザが操作するユーザ端末１００の制御部１１０は、管理者側プログラムに従って、図１２に示す起家決定処理を実行する。なお、当該起家決定処理は、ゲームサーバ２００で実行し、処理結果を各ユーザ端末１００に送信するようにしてもよい。

ステップＳ２１では、編成情報管理テーブル３０６に登録されたキャラクタのうち、いずれか１人のキャラクタを指定する。ステップＳ２２では、当該キャラクタのオーダーを編成情報管理テーブル３０６から特定し、当該キャラクタのオーダー適性をキャラクタパラメータ管理テーブル３０１から特定する。

ステップＳ２３では、当該キャラクタの雀力をキャラクタパラメータ管理テーブル３０１から特定し、ステップＳ２２で特定したオーダーがオーダー適性と一致するか否かに応じて当該雀力を補正する。具体的には、当該オーダーが当該オーダー適性と一致する場合に、当該雀力を例えば１．２倍にする。

例えば、キャラクタＤ４のオーダーは、ユーザ３によって次鋒に設定されるところ、キャラクタＤ４のオーダー適性は次鋒であるため、キャラクタＤ４の雀力は９００から１０８０に増大される。

ステップＳ２４では、当該キャラクタに関連付けられた配牌スキルの起家適性をキャラクタスキル管理テーブル３０２から特定する。ステップＳ２５では、当該キャラクタの雀力を当該起家適性に応じて補正する。具体的には、当該起家適性がありに設定されている場合に、当該雀力を例えば１．２倍にする。

例えば、ユーザ１が中堅に設定したキャラクタＣ１には、対子爆弾が関連付けられているところ、対子爆弾の起家適性はありに設定されているため、キャラクタＣ１の雀力は１４００から１６８０に増大される。

ステップＳ２６では、編成情報管理テーブル３０６に登録された全てのキャラクタが指定されたか否かをステップＳ２１の処理結果に基づいて判定する。当該全てのキャラクタが指定されたと判定されなければ、ステップＳ２１に戻り、当該全てのキャラクタが指定されたと判定されれば、ステップＳ２７に進む。

ステップＳ２７では、ユーザ１〜４の各々が編成したチームの総合雀力を特定する。具体的には、ステップＳ２３またはＳ２５で適宜補正された各キャラクタの雀力をチーム毎に積算して、各チームの総合雀力を特定する。

この結果、ユーザ１のチームの総合雀力は、６０８０（＝１０００＋１０００＋１４００＊１．２＋１０００＊１．２＋１０００＊１．２）となり、ユーザ２のチームの総合雀力は、７１６０（＝１２００＊１．２＋１２００＊１．２＋１４００＋１２００＋１４００＊１．２）となる。また、ユーザ３のチームの総合雀力は、４５６０（＝９００＊１．２＋９００＊１．２＋８００＋８００＋８００）となり、ユーザ４のチームの総合雀力は、５２００（＝１４００＋８００＋１２００＋９００＋９００）となる。

ステップＳ２８では、ステップＳ２７で特定された総合雀力に基づいて起家となるキャラクタを特定する。具体的には、総合雀力が最大となるチームの先鋒のキャラクタを起家に設定する。上述の例では、ユーザ２のチームの総合雀力が最大であるため、キャラクタＢ４が起家となる。

なお、総合雀力が最大のチームが２チーム以上いる場合は、例えば乱数抽選によって１つのチームを特定し、当該チームの先鋒のキャラクタを起家に設定する。

起家決定処理が完了した後、ホスト役のユーザが操作するユーザ端末１００の制御部１１０は、管理者側プログラムに従って、図１３に示す対局前処理を実行する。なお、当該対局前処理は、対局毎に実行される。また、図１３の対局前処理は、ゲームサーバ２００で実行し、処理結果を各ユーザ端末１００に送信するようにしてもよい。

ステップＳ３１では、麻雀ゲームの進行状況を表す各種のゲームパラメータに基づいて、今回の団体戦の区別（先鋒戦、次鋒戦、中堅戦、副将戦、大将戦のいずれであるか）を特定し、特定した区別が示された団体戦区別情報をゲームサーバ２００に通知する。ステップＳ３２では、ステップＳ３１で特定された団体戦に臨む４人のキャラクタを編成情報管理テーブル３０６に基づいて特定し、当該４人のキャラクタのうちのいずれか１人のキャラクタを指定する。

ステップＳ３３では、編成情報管理テーブル３０６と、キャラクタスキル管理テーブル３０２と、配牌スキル管理テーブル３０３とに基づいて、当該キャラクタが発動可能な配牌スキルと、当該配牌スキルの発動条件とを特定する。

例えば、図９に示す編成情報管理テーブル３０６の設定を前提として、ユーザ１が編成したキャラクタＡ４が次鋒戦に挑む場合は、キャラクタＡ４が発動可能な配牌スキルとして四喜メイカーが特定され、今回の対戦が次鋒戦であることが当該配牌スキルの発動条件として特定される。

ステップＳ３４では、ステップＳ３２で指定されたキャラクタの対局状況（団体戦の区別、今回の対戦における当該キャラクタのポジション（親／子）、当該キャラクタの順位、他のキャラクタとの点数差等）を、麻雀ゲームの進行状況を表す各種のゲームパラメータに基づいて特定する。ステップＳ３５では、ステップＳ３３で特定されたスキル発動条件が成立しているか否かを、ステップＳ３４で特定された対局状況に基づいて判定する。

当該スキル発動条件が成立していると判定されなかったときは、ステップＳ３７に進み、ステップＳ３２で指定したキャラクタに対して無作為な配牌を設定する。一方、当該発動条件が成立したと判定されたときは、ステップＳ３６に進む。ステップＳ３６では、発動させる配牌スキルに対応するスキルの詳細を配牌スキル管理テーブル３０３から特定し、当該スキルの詳細に従う配牌をステップＳ３２で指定したキャラクタに対して設定する。即ち、配牌スキルを発動させる。

図９に示す編成情報管理テーブル３０６の設定を前提として、ユーザ１が編成したキャラクタＡ４は次鋒戦に臨むため、キャラクタＡ４に関連付けられた四喜メイカーの発動条件が成立する。この結果、小四喜のタネを７枚以上含む配牌がキャラクタＡ４に対して設定される。

ステップＳ３６またはＳ３７の処理が完了すると、ステップＳ３８に進み、配牌情報をゲームサーバ２００に通知する。このとき、配牌情報には、ステップＳ３２で指定されたキャラクタを操作するユーザ名と、ステップＳ３６またはＳ３７で設定された配牌とが含められる。

ステップＳ３９では、ステップＳ３１で特定された団体戦に臨む４人のキャラクタの全てが指定されたか否をステップＳ３２の処理結果に基づいて判定する。当該４人のキャラクタの全てが指定されたと判定されなかったときはステップＳ３２に戻り、当該４人のキャラクタの全てが指定されたと判定されたときはステップＳ４０に進む。ステップＳ４０では、残りの牌を使って牌山を構築し、ステップＳ４１では、構築した牌山における牌の並びを示す牌山情報をゲームサーバ２００に通知する。ステップＳ４１の処理が完了すると、対局前処理を終了する。

ゲームサーバ２００は、ステップＳ３１の処理によって通知された団体戦区別情報をユーザ１〜４の各々が操作するユーザ端末１００に通知する。また、ゲームサーバ２００は、ステップＳ３８の処理によって通知された配牌情報に含まれるユーザ名を特定し、特定したユーザ名に対応するユーザ端末１００に対して当該配牌情報を通知する。

図１０に示すキャラクタ編成処理が終了すると、ユーザ１〜４の各々が操作するユーザ端末１００の制御部１１０は、ユーザ側プログラムに従って、図１４に示す対局処理を実行する。ここでも、ユーザ１が操作するユーザ端末１００における対局処理を念頭において説明するが、ユーザ２〜４の各々が操作するユーザ端末１００においても同様の対局処理が実行される。

ステップＳ５１では、団体戦区別情報がゲームサーバ２００から通知されたか否かを、通信ＩＦ１３による受信データに基づいて判定する。団体戦区別情報が通知されたと判定されると、ステップＳ５２に進む。ステップＳ５２では、当該団体戦区別情報が示す区別に基づいて対局に臨むキャラクタを特定し、編成情報管理テーブル３０６と、キャラクタスキル管理テーブル３０２と、ツモスキル管理テーブル３０４とに基づいて、当該キャラクタが発動可能なツモスキルと当該ツモスキルの発動条件とを特定する。

例えば、当該団体戦区別情報が次鋒戦であれば、キャラクタＡ４が対局に臨むキャラクタとして特定され、無難な左手が発動可能なツモスキルとして特定される。また、当該キャラクタＡ４が２着以下で、当該キャラクタＡ４の手牌が３シャンテン以下であることが、当該ツモスキルの発動条件として特定される。

ステップＳ５３では、配牌情報がゲームサーバ２００から通知されたか否かを、通信ＩＦ１３による受信データに基づいて判定する。配牌情報が通知されたと判定されると、ステップＳ５４に進み、図１５（Ｂ）に示す対局画面をタッチスクリーン１５に表示する。図１５（Ｂ）によれば、当該対局画面は、麻雀卓エリアＭＴ１と手牌エリアＴＨ１とツモスキルエリアＴＳ１とによって構成される。ステップＳ５２で特定されたツモスキルを表すアイコンは、ツモスキルエリアＴＳ１に表示され、ゲームサーバ２００から通知された配牌情報に含まれる配牌は、手牌エリアＴＨ１に表示される。

ステップＳ５５では、ゲームサーバ２００と通信しながら対局を進める。各家のキャラクタによる牌山からのツモ牌、河への捨て牌、他家のキャラクタの捨て牌に対する副露（ポン、チー、大明槓）、自家のキャラクタの手牌に対する副露（暗槓、小明槓）、各家のキャラクタのリーチの有無などの対局状況は、対局の進行に応じて変化する。

ステップＳ５６では、ステップＳ５２で特定されたスキル発動条件が成立したか否かを、麻雀ゲームの進行状況（ユーザ１が操作するキャラクタの手牌のシャンテン数、ユーザ１が操作するキャラクタの順位、各キャラクタのリーチの有無等）を表す各種のゲームパラメータに基づいて特定する。当該スキル発動条件が成立したと判定されると、ステップＳ５７に進み、ツモスキルが発動可能であることを報知する。具体的には、ツモスキルエリアＴＳ１に表示されたツモスキルのアイコンをハイライトさせる。

より具体的には、キャラクタＡ４が２着以下で、キャラクタＡ４の手牌が３シャンテン以下になったときは、無難な左手の発動条件が成立する。この結果、無難な左手に対応するアイコンがハイライトされる。ステップＳ５７の処理が完了すると、ステップＳ５８に進む。なお、ステップＳ５６において当該スキル発動条件が成立したと判定されなければ、ステップＳ５７の処理を行うことなくステップＳ５８に進む。

ステップＳ５８では、スキル発動条件が成立していたツモスキルについて発動条件が不成立となったか否かを、麻雀ゲームの進行状況を表す各種のゲームパラメータに基づいて特定する。当該スキル発動条件が不成立となったと判定されると、ステップＳ５９に進み、当該スキル発動条件が成立していたツモスキルの報知を終了する。具体的には、ツモスキルエリアＴＳ１に表示されているツモスキルのハイライトを終了させる。なお、ステップＳ５８において当該発動条件が不成立となったと判定されなければ、ステップＳ５９の処理を行うことなくステップＳ６０に進む。

ステップＳ６０では、発動可能なツモスキルに対する発動動作が行われたか否か、即ちハイライトされているツモスキルのアイコンがタッチされたか否かを、タッチスクリーン１５に対する操作入力に基づいて判定する。当該アイコンがタッチされたと判定されなければ、ステップＳ６３に進む。

一方、当該アイコンがタッチされたと判定されれば、ステップＳ６１で当該アイコンに対応するツモスキルを発動させる。このため、上述の例で無難な左手のツモスキルが発動された場合は、３巡連続でまだ一度も捨てていない牌をキャラクタＡ４が引き寄せるように、牌山における牌の並び替えが行われる。ステップＳ６２では、発動されたツモスキルについて発動可能であることの報知を終了する。具体的には、発動されたツモスキルのアイコンのハイライトを終了させる。

ステップＳ６２の処理が完了すると、ステップＳ６３に進み、対局中の４人のキャラクタのいずれか１人が上がったか又は今回の対局が流局となったか否かをステップＳ５５の処理結果に基づいて判定する。当該４人のキャラクタのいずれか１人が上がったか又は今回の対局が流局となったと判定されなければ、ステップＳ５５に戻る。一方、当該４人のキャラクタのいずれか１人が上がったか又は今回の対局が流局となったと判定されると、ステップＳ６４で清算と雀力の更新とを行う。この結果、ユーザ１が操作するキャラクタの順位や、キャラクタ間の点数差が特定されるとともに、当該キャラクタの雀力が増大または減少される。今回の対局処理は、ステップＳ６４の処理の後に終了する。

＜本実施形態の効果＞
本実施形態によれば、麻雀の団体戦に臨む４チームの各々には、５人のキャラクタが編成される。また、当該団体戦では５つの対局が用意され、当該５人のキャラクタは１局ずつ麻雀を行う。このとき、当該４チームのうちのいずれか１チームに属するキャラクタ（１チームのキャラクタを操作するプレイヤ）が親となり、当該親が勝利することなく対局が終了すると、残りの３チームのうち所定の順序で指定された１チームのキャラクタが親となって対局を引き継ぐ。このため、当該４チームのうち起家を務めたキャラクタが属するチームには２回親が回ってくるが、残りの３チームには１回しか親が回ってこない。

ただし、各チームに属するキャラクタには、当該団体戦に関する有利度が関連付けられており、どのチームのキャラクタを起家とするかは、当該有利度に基づいて決定される。このため、ユーザによるキャラクタ編成次第で、当該ユーザのチームが親を務める回数が変わってくる。

プレイヤにより編成されたキャラクタに関連付けられている有利度に基づいて起家を決定することにより、例えば起家になれなかったときであっても、プレイヤに納得感を抱かせることができる。その結果、無作為に起家を決定するものと比較して、ゲームの興趣が低下する懸念を抑えることができる。また、団体戦は５局により構成され、半荘戦または一荘戦よりも短時間でゲームを完結できるため、ユーザの利便性やゲームの稼働率を向上させることができる。

また、本実施形態によれば、当該有利度は、団体戦におけるキャラクタの強さに関するパラメータ（雀力、オーダー適性）を含み、当該パラメータに基づいて、強いキャラクタが属するチームほど２回親が回ってくる割合が高くなるように、起家が決定される。これによって、キャラクタをより強く育てて、団体戦のチームに編成しようという動機付けを働かせることができる。

さらに、本実施形態によれば、当該有利度は、キャラクタに関連付けられたスキルを含む。また、いずれかのスキルについては、起家適性がありに設定される。これを踏まえて、起家は、起家適性がありを示すスキルが関連付けられているキャラクタのチームほど２回親が回ってくる割合が高くなるように、決定される。これによって、起家適性がありを示すスキルが関連付けられているキャラクタをチームに編成しようという動機付けを働かせることができる。

また、本実施形態によれば、上述のようなキャラクタ編成は、対戦プレイモードにおいてプレイする４人のユーザの各々により実行される。当該４人のユーザのうちのいずれのユーザのチームが親を２回務めるかは、各ユーザが編成したキャラクタの総合雀力に基づいて決定される。これによって、ユーザ間でキャラクタ編成を競わせることができ、ひいてはゲームの興趣を向上させることができる。

さらに、本実施形態によれば、チームに編成可能なキャラクタには、子であることを条件として発動するスキルが関連付けられたキャラクタが含まれる。これにより、自ユーザのチームのキャラクタが起家となることを狙ったチーム編成を行うことを前提として、子であることを条件として発動するスキルが関連付けられたキャラクタについては、先鋒および大将以外のオーダーに配置するといった面白みを提供することができる。

また、本実施形態によれば、対戦は、親が勝利しないことによって終了する。換言すれば、対戦は、親が勝利する限り継続される。これによって、有利な立場で対戦を継続しようという動機付けが働く。

＜変形例＞
以上説明した実施形態の変形例などを以下に列挙する。

（１） 上記実施形態においては、４チームの各々は５人のキャラクタにより編成され、団体戦は５つの対局により構成される。しかし、当該団体戦における対局の回数は、当該団体戦に臨むチーム数（即ちプレイヤ数、例えば４）で除することにより１以上の余りが生じる回数である限り、５回以外の回数（例えば６回や７回）であってもよい。これは、各キャラクタが１局ずつ対戦を行うことを前提として、チームに編成されるキャラクタの人数が５人以外の人数（例えば６人や７人）であってもよいことを意味する。

（２） 上記実施形態においては、各チームに編成された５人のキャラクタ各々に関連付けられている有利度（雀力、オーダー適性、スキルの起家適性）に基づいて、起家となるキャラクタを決定するようにしている。しかし、各チームの特定の位置（例えば、先鋒）のキャラクタに関連付けられている有利度に基づいて、起家となるキャラクタを決定するようにしてもよい。これによって、有利度が際立って高い特定のキャラクタ（例えばレアリティの高いキャラクタ）を特定の位置に配置しようという動機付けが働き、ゲームの興趣を向上させることができる。

（３） 上記実施形態においては、各チームに編成された５人のキャラクタ各々のオーダー適性に基づいて各キャラクタの雀力を補正し、補正後の雀力に基づいて起家となるキャラクタを決定するようにしている。しかし、各チームの特定の位置（例えば、先鋒）に設定されたキャラクタのオーダー適性に注目し（このとき、雀力には注目しないか、雀力に対する注目度をオーダー適性に対する注目度よりも小さくする）、当該オーダー適性が当該特定の位置であるキャラクタを、当該オーダー適性が当該特定の位置でないキャラクタよりも高い割合で、起家として決定するようにしてもよい。

（４） 上記実施形態においては、ユーザが団体戦をプレイした回数や団体戦をプレイする頻度が起家決定処理において参照されることはない。しかし、キャラクタに関連付けられている有利度だけでなく、当該ユーザによる団体戦のプレイ回数またはプレイ頻度に基づいて、起家となるキャラクタを決定するようにしてもよい。具体的には、団体戦のプレイ回数またはプレイ頻度が高いユーザのキャラクタを、当該プレイ回数または当該プレイ頻度が低いユーザのキャラクタよりも高い割合で、起家として決定するようにしてもよい。あるいは、当該ユーザが団体戦を初めてプレイする場合には、例外的に、当該ユーザのチームのキャラクタを必ず起家として決定するようにしてもよい。

（５） 上記実施形態においては、過去の団体戦の結果が今回の団体戦において参照されることはない。しかし、キャラクタに関連付けられている有利度だけでなく、過去の団体戦の結果に基づいて、起家となるキャラクタを決定するようにしてもよい。具体的には、ユーザが過去の団体戦で負けた他のユーザと再戦する場合に、当該ユーザのキャラクタを、当該他のユーザのキャラクタよりも高い割合で、起家として決定するようにしてもよい。

（６） 上記実施形態においては、スキルは、キャラクタに対して固定的に関連付けるようにしている。しかし、各キャラクタに関連付けるスキルは、団体戦の開始時に（より具体的には起家決定処理の前の時点で）、例えば乱数抽選により決定するようにしてもよい。

（７） 上記実施形態においては、スキル発動条件はスキルに対して固定的に設定されている。しかし、過去の団体戦の結果に応じてスキル発動条件を変更し、当該変更に応じて起家適性も変更するようにしてもよい。

（８） 上記実施形態においては、団体戦は対戦プレイモードにおいて行うようにしている。しかし、当該団体戦はシングルプレイモードにおいて行うようにしてもよい。

（９） 上記実施形態においては、ユーザ端末１００間の同期は、ゲームサーバ２００を介して確立するようにしている。しかし、例えばローカルエリア・ネットワーク環境化において、ユーザ端末１００同士で通信を行うことで、ユーザ端末１００間の同期を確立するようにしてもよい。

（１０） 上記実施形態においては、管理者側プログラムに従う処理は、ホスト役のユーザのユーザ端末１００によって実行される。しかし、当該処理は、ゲームサーバ２００に担わせるようにしてもよい。

（１１） 上記実施形態においては、対戦プレイモードでは４人のユーザが必ず揃うことを前提としているが、実際には、４人全員が揃わない可能性もある。そこで、４人全員が揃わない場合には、不足するユーザをＮＰＣによって補うようにしてもよい。この場合、例えば、各ＮＰＣに対応するユーザ側プログラムは、通信回線への接続が可能な環境ではゲームサーバ２００において起動され、通信回線への接続が不可能な環境ではホスト役のユーザ端末１００において起動される。また、ＮＰＣ用の配牌スキル、ツモスキル、各種パラメータは、例えば乱数抽選等で決定される。さらに、ホスト役のユーザ端末１００の管理者側プログラムは、当該ユーザ側プログラムとの間でやり取りを行いながら対局を行う（通信回線への接続が不可能な環境では、当該ユーザ側プログラムとのやり取りは、ホスト役のユーザ端末１００内で行われる）。

（１２） 上記実施形態においては、対局に臨む４チームのうち、起家を務めたキャラクタが属するチームに、大将戦において２回目の親が回ってくることを踏まえて、どのチームのキャラクタを起家とするかを、各チームに属するキャラクタの有利度に基づいて決定するようにしている。しかし、先鋒戦から副将戦までの４局については、例えば乱数抽選により起家を決定した上で、所定順序で親を切り替えながら対局を行い、大将戦については、各チームに属するキャラクタの有利度に基づいて親を決定して対局を行うようにしてもよい。つまり、各プレイヤに対して親を均等に割り当てることができない余り分の対戦において親とするプレイヤであって、団体戦において親を担当する回数が他のいずれかのプレイヤよりも多くなるプレイヤを、各プレイヤに関連付けられている有利度に基づいて決定するようにしてもよい。これにより、起家以外のプレイヤが他のプレイヤよりも多く親を担当することも生じ得る。より具体的には、東１局で南家（すなわち、東２局で親）だったプレイヤが、東５局で親を獲得することが生じ得るようにしてもよい。これにより、各プレイヤに対して余り分となる対局において親となることに対する期待感を抱かせることができ、ゲームの興趣を向上させることができる。

また、大将戦以外の対戦（例えば先鋒戦）について、当該有利度に基づいて親を決定して対局を行い、残りの４局（例えば次鋒戦〜大将戦）については、乱数抽選で１局目の親を決定した上で、所定順序で親を切り替えながら対局を行うようにしてもよい。つまり、各プレイヤに関連付けられている有利度に基づいて、他のいずれかのプレイヤよりも多く親を担当するプレイヤを決定するものであれば、当該プレイヤが親を担当する対戦は、団体戦の最後の余り分となる対戦に限らず、団体戦が開始された直後の対戦であってもよく、また、団体戦における中盤の対戦であってもよい。

＜付記＞
以上の各実施形態で説明した事項を、以下に付記する。

（付記１）：
本開示に示す一実施形態のある局面によれば、プロセッサ、メモリ、および表示部を備えるコンピュータ（図１のユーザ端末１００）において実行されるゲームプログラムであって、前記ゲームプログラムは、前記プロセッサに、ユーザによる操作プレイヤと対戦プレイヤとを含む複数のプレイヤが対戦する対戦パートであって、対戦可能な回数が対戦するプレイヤの数で除することにより１以上の余りが生じる回数に定められている特定の対戦パート（団体戦）を実行する第１ステップ（図１３のＳ５１〜Ｓ６４）と、前記特定の対戦パートにおける対戦毎に、前記対戦するプレイヤのうちから他のプレイヤよりも有利となるオーナープレイヤ（親）を設定する第２ステップ（図１２のＳ２１〜Ｓ２８、図１３のＳ３４）とを実行させ、対戦するプレイヤ各々には、前記特定の対戦パートに関する有利度が関連付けられており、前記第２ステップは、前記余り分の対戦におけるオーナープレイヤとして設定するプレイヤであって、当該特定の対戦パートにおいてオーナープレイヤとして対戦を行う回数が他のいずれかのプレイヤよりも多くなるプレイヤを、対戦するプレイヤ各々に関連付けられている有利度に基づいて決定する（Ｓ２２〜Ｓ２５、Ｓ２７、Ｓ２８）。

（付記２）：
（付記１）において、前記第２ステップは、前記特定の対戦パートにおける初回の対戦を開始するときに、対戦するプレイヤのうちから他のプレイヤよりも有利となるオーナープレイヤを決定する決定ステップ（図１２のＳ２１〜Ｓ２８）と、予め定められた切替条件が成立して対戦を１回消化する毎に、対戦するプレイヤ各々に定められている順序に従って、現在のオーナープレイヤを基準として次のプレイヤを次回のオーナープレイヤに切り替える切替ステップ（図１３のＳ３４）とを含み、前記決定ステップは、対戦するプレイヤ各々に関連付けられている有利度に基づいて、前記オーナープレイヤを決定する。

（付記３）：
（付記２）において、前記切替条件は、前記オーナープレイヤが勝利することによっては成立せず、前記オーナープレイヤが勝利しないことによって成立可能である（親が負けるまで対局数は同じ）。

（付記４）：
（付記１）から（付記３）のいずれかにおいて、前記有利度は、前記特定の対戦パートにおけるプレイヤの強さに関するパラメータ（雀力、オーダー適性）であり、前記第２ステップは、対戦するプレイヤ各々に関連付けられているパラメータに基づいて、他のプレイヤよりも強いプレイヤを高い割合で前記オーナープレイヤに決定する。

（付記５）：
（付記１）から（付記４）のいずれかにおいて、前記有利度は、複数種類のスキルのうちプレイヤが発動可能なスキルを特定するための情報であり、前記第２ステップは、対戦するプレイヤ各々に関連付けられているスキルに基づいて、特定スキル（起家適性がありを示すスキル）が関連付けられていないプレイヤよりも前記特定スキルが関連付けられているプレイヤを高い割合で前記オーナープレイヤに決定する。

（付記６）：
（付記１）から（付記５）のいずれかにおいて、前記ゲームプログラムは、前記プロセッサに、前記操作プレイヤが対戦に用いるキャラクタを複数種類のキャラクタのうちから編成する編成パートを実行する第３ステップ（図１０のＳ０１〜Ｓ０８）と、前記対戦プレイヤが対戦に用いるキャラクタを前記複数種類のキャラクタのうちから特定する第４ステップ（図１１のＳ１２）とを実行させ、前記複数種類のキャラクタ各々には、前記特定の対戦パートに関する有利度（雀力、オーダー適性、スキル）が関連付けられており、前記第２ステップは、対戦するプレイヤ各々が対戦に用いるキャラクタに関連付けられている有利度に基づいて、前記オーナープレイヤを決定する。

（付記７）：
（付記６）において、前記第３ステップは、オーダーが各々に割り当てられる態様で複数のキャラクタを対戦に用いるキャラクタとして編成し、前記第４ステップは、オーダーが各々に割り当てられる態様で複数のキャラクタを対戦に用いるキャラクタとして特定し、前記複数種類のキャラクタ各々には、前記オーダーに対する当該キャラクタの相性（オーダー適性）が関連付けられており、前記第２ステップは、対戦に用いるキャラクタのうち特定の位置（先鋒）にオーダーが割り当てられているキャラクタに関連付けられている有利度に基づいて、前記オーナープレイヤを決定する。

（付記８）：
（付記６）または（付記７）において、前記複数種類のキャラクタは、前記オーナープレイヤではないこと（子であること）を条件として発動するスキルが関連付けられているキャラクタを含む。

（付記９）：
本開示に示す一実施形態のある局面によれば、プロセッサ、メモリ、および入力部を備えるコンピュータ（図１のユーザ端末１００）において実行されるゲーム方法であって、前記ゲーム方法は、前記コンピュータが、ユーザによる操作プレイヤと対戦プレイヤとを含む複数のプレイヤが対戦する対戦パートであって、対戦可能な回数が対戦するプレイヤの数で除することにより１以上の余りが生じる回数に定められている特定の対戦パート（団体戦）を実行する第１ステップと（図１３のＳ５１〜Ｓ６４）、前記特定の対戦パートにおける対戦毎に、前記対戦するプレイヤのうちから他のプレイヤよりも有利となるオーナープレイヤ（親）を設定する第２ステップ（図１２のＳ２１〜Ｓ２８、図１３のＳ３４）とを備え、対戦するプレイヤ各々には、前記特定の対戦パートに関する有利度が関連付けられており、前記第２ステップは、前記余り分の対戦におけるオーナープレイヤとして設定するプレイヤであって、当該特定の対戦パートにおいてオーナープレイヤとして対戦を行う回数が他のいずれかのプレイヤよりも多くなるプレイヤを、対戦するプレイヤ各々に関連付けられている有利度に基づいて決定する（Ｓ２２〜Ｓ２５、Ｓ２７、Ｓ２８）。

（付記１０）：
本開示に示す一実施形態のある局面によれば、情報処理装置（図１のユーザ端末１００）であって、ゲームプログラムを記憶する記憶部（図２の１２０）と、前記ゲームプログラムを実行することにより、前記情報処理装置の動作を制御する制御部（図２の１１０）とを備え、前記制御部は、ユーザによる操作プレイヤと対戦プレイヤとを含む複数のプレイヤが対戦する対戦パートであって、対戦可能な回数が対戦するプレイヤの数で除することにより１以上の余りが生じる回数に定められている特定の対戦パート（団体戦）を実行する第１ステップ（図１３のＳ５１〜Ｓ６４）と、前記特定の対戦パートにおける対戦毎に、前記対戦するプレイヤのうちから他のプレイヤよりも有利となるオーナープレイヤ（親）を設定する第２ステップ（図１２のＳ２１〜Ｓ２８、図１３のＳ３４）とを実行し、対戦するプレイヤ各々には、前記特定の対戦パートに関する有利度が関連付けられており、前記第２ステップは、前記余り分の対戦におけるオーナープレイヤとして設定するプレイヤであって、当該特定の対戦パートにおいてオーナープレイヤとして対戦を行う回数が他のいずれかのプレイヤよりも多くなるプレイヤを、対戦するプレイヤ各々に関連付けられている有利度に基づいて決定する（Ｓ２２〜Ｓ２５、Ｓ２７、Ｓ２８）。

〔ソフトウェアによる実現例〕
制御部１１０の制御ブロック（特に、作用受付部１１１、端末処理部１１２、タイマー部１１３、端末判定部１１４、表示制御部１１５、報酬計算部１１６、および送受信部１１７）は、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェアによって実現してもよい。

後者の場合、制御部１１０を備えた情報処理装置は、各機能を実現するソフトウェアであるプログラムの命令を実行するＣＰＵ、上記プログラムおよび各種データがコンピュータ（またはＣＰＵ）で読み取り可能に記録されたＲＯＭ（Read Only Memory）または記憶装置（これらを「記録媒体」と称する）、上記プログラムを展開するＲＡＭ（Random Access Memory）などを備えている。そして、コンピュータ（またはＣＰＵ）が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

今回開示された実施の形態はすべての点で例示であって制限的なものでないと考えられるべきである。この発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１ ゲームシステム、２ ネットワーク、１００ ユーザ端末、１１０ 制御部、１１１ 作用受付部、１１２ 端末処理部、１１３ タイマー部、１１４ 端末判定部、１１５ 表示制御部、１１６ 報酬計算部、１１７ 送受信部、１２０ 記憶部、１５１ 入力部、１５２ 表示部、２００ ゲームサーバ、２１０ 制御部、２１１ 送受信部、２１２ サーバ処理部、２１３ データ管理部、２１４ マッチング部、２１５ 計測部、２２０ 記憶部、３０１ キャラクタパラメータ管理テーブル、 ３０２ キャラクタスキル管理テーブル、 ３０３ 配牌スキル管理テーブル、３０４ ツモスキル管理テーブル、３０５ａ〜３０５ｄ 編成管理テーブル、 ３０６ 編成情報管理テーブル。

Claims (10)

1. プロセッサ、メモリ、および表示部を備えるコンピュータにおいて実行されるゲームプログラムであって、
   前記ゲームプログラムは、前記プロセッサに、
   ユーザによる操作プレイヤと対戦プレイヤとを含む複数のプレイヤが対戦する対戦パートであって、対戦可能な回数が対戦するプレイヤの数で除することにより１以上の余りが生じる回数に定められている特定の対戦パートを実行する第１ステップと、
   前記特定の対戦パートにおける対戦毎に、前記対戦するプレイヤのうちから他のプレイヤよりも有利となるオーナープレイヤを設定する第２ステップとを実行させ、
   対戦するプレイヤ各々には、前記特定の対戦パートに関する有利度が関連付けられており、
   前記第２ステップは、前記余り分の対戦におけるオーナープレイヤとして設定するプレイヤであって、当該特定の対戦パートにおいてオーナープレイヤとして対戦を行う回数が他のいずれかのプレイヤよりも多くなるプレイヤを、対戦するプレイヤ各々に関連付けられている有利度に基づいて決定する、ゲームプログラム。
2. 前記第２ステップは、
   前記特定の対戦パートにおける初回の対戦を開始するときに、対戦するプレイヤのうちから他のプレイヤよりも有利となるオーナープレイヤを決定する決定ステップと、
   予め定められた切替条件が成立して対戦を１回消化する毎に、対戦するプレイヤ各々に定められている順序に従って、現在のオーナープレイヤを基準として次のプレイヤを次回のオーナープレイヤに切り替える切替ステップとを含み、
   前記決定ステップは、対戦するプレイヤ各々に関連付けられている有利度に基づいて、前記オーナープレイヤを決定する、請求項１に記載のゲームプログラム。
3. 前記切替条件は、前記オーナープレイヤが勝利することによっては成立せず、前記オーナープレイヤが勝利しないことによって成立可能である、請求項２に記載のゲームプログラム。
4. 前記有利度は、前記特定の対戦パートにおけるプレイヤの強さに関するパラメータであり、
   前記第２ステップは、対戦するプレイヤ各々に関連付けられているパラメータに基づいて、他のプレイヤよりも強いプレイヤを高い割合で前記オーナープレイヤに決定する、請求項１〜請求項３のいずれかに記載のゲームプログラム。
5. 前記有利度は、複数種類のスキルのうちプレイヤが発動可能なスキルを特定するための情報であり、
   前記第２ステップは、対戦するプレイヤ各々に関連付けられているスキルに基づいて、特定スキルが関連付けられていないプレイヤよりも前記特定スキルが関連付けられているプレイヤを高い割合で前記オーナープレイヤに決定する、請求項１〜請求項４のいずれかに記載のゲームプログラム。
6. 前記ゲームプログラムは、前記プロセッサに、
   前記操作プレイヤが対戦に用いるキャラクタを複数種類のキャラクタのうちから編成する編成パートを実行する第３ステップと、
   前記対戦プレイヤが対戦に用いるキャラクタを前記複数種類のキャラクタのうちから特定する第４ステップとを実行させ、
   前記複数種類のキャラクタ各々には、前記特定の対戦パートに関する有利度が関連付けられており、
   前記第２ステップは、対戦するプレイヤ各々が対戦に用いるキャラクタに関連付けられている有利度に基づいて、前記オーナープレイヤを決定する、請求項１〜請求項５のいずれかに記載のゲームプログラム。
7. 前記第３ステップは、オーダーが各々に割り当てられる態様で複数のキャラクタを対戦に用いるキャラクタとして編成し、
   前記第４ステップは、オーダーが各々に割り当てられる態様で複数のキャラクタを対戦に用いるキャラクタとして特定し、
   前記複数種類のキャラクタ各々には、前記オーダーに対する当該キャラクタの相性が関連付けられており、
   前記第２ステップは、対戦に用いるキャラクタのうち特定の位置にオーダーが割り当てられているキャラクタに関連付けられている有利度に基づいて、前記オーナープレイヤを決定する、請求項６に記載のゲームプログラム。
8. 前記複数種類のキャラクタは、前記オーナープレイヤではないことを条件として発動するスキルが関連付けられているキャラクタを含む、請求項６または請求項７に記載のゲームプログラム。
9. プロセッサ、メモリ、および入力部を備えるコンピュータにおいて実行されるゲーム方法であって、
   前記ゲーム方法は、前記コンピュータが、
   ユーザによる操作プレイヤと対戦プレイヤとを含む複数のプレイヤが対戦する対戦パートであって、対戦可能な回数が対戦するプレイヤの数で除することにより１以上の余りが生じる回数に定められている特定の対戦パートを実行する第１ステップと、
   前記特定の対戦パートにおける対戦毎に、前記対戦するプレイヤのうちから他のプレイヤよりも有利となるオーナープレイヤを設定する第２ステップとを備え、
   対戦するプレイヤ各々には、前記特定の対戦パートに関する有利度が関連付けられており、
   前記第２ステップは、前記余り分の対戦におけるオーナープレイヤとして設定するプレイヤであって、当該特定の対戦パートにおいてオーナープレイヤとして対戦を行う回数が他のいずれかのプレイヤよりも多くなるプレイヤを、対戦するプレイヤ各々に関連付けられている有利度に基づいて決定する、ゲーム方法。
10. 情報処理装置であって、
    ゲームプログラムを記憶する記憶部と、
    前記ゲームプログラムを実行することにより、前記情報処理装置の動作を制御する制御部とを備え、
    前記制御部は、
    ユーザによる操作プレイヤと対戦プレイヤとを含む複数のプレイヤが対戦する対戦パートであって、対戦可能な回数が対戦するプレイヤの数で除することにより１以上の余りが生じる回数に定められている特定の対戦パートを実行する第１ステップと、
    前記特定の対戦パートにおける対戦毎に、前記対戦するプレイヤのうちから他のプレイヤよりも有利となるオーナープレイヤを設定する第２ステップとを実行し、
    対戦するプレイヤ各々には、前記特定の対戦パートに関する有利度が関連付けられており、
    前記第２ステップは、前記余り分の対戦におけるオーナープレイヤとして設定するプレイヤであって、当該特定の対戦パートにおいてオーナープレイヤとして対戦を行う回数が他のいずれかのプレイヤよりも多くなるプレイヤを、対戦するプレイヤ各々に関連付けられている有利度に基づいて決定する、情報処理装置。