(57)【要約】      （修正有）【課題】強さのレベルが異なる対戦者間でも、ゲーム機会を増やせることができるゲームシステムを提供する。【解決手段】プレーヤー毎に保持しているポイントデータ１０１と、プレーヤー毎に保持している持ち時間データ１０２と、プレーヤーの要求に応じて持ち時間データ１０２を追加する持ち時間追加ステップＳ１０７と、持ち時間追加ステップＳ１０７で追加された回数を記録する持ち時間追加回数記録１０８と、持ち時間追加回数記録１０８に基づいてプレーヤー間、またはプレーヤーとサーバー運営者間で再分配される贈与ポイントを計算する贈与ポイント計算ステップＳ１０６と、贈与ポイント計算ステップＳ１０６の結果に基づいて各プレーヤー間、またはプレーヤーとサーバー運営者間でポイントの再分配を行う贈与ポイント再分配ステップＳ１０５とを備える。【選択図】図１
2013230330.tif 000002
【特許請求の範囲】
【請求項１】
複数プレーヤーがネットワークを通じて仮想的な盤面を共有するネットワークゲームにおいて、複数プレーヤーとサーバー運営者が保持しているポイントデータと、プレーヤー毎に保持している持ち時間データと、プレーヤーの要求に応じて前記持ち時間データを追加する持ち時間追加ステップと、前記持ち時間追加ステップで追加された回数を記録する持ち時間追加回数記録と、前記持ち時間追加回数記録に基づいてプレーヤー間、またはプレーヤーとサーバー運営者間で再分配される贈与ポイントを計算する贈与ポイント計算ステップと、前記贈与ポイント計算ステップの結果に基づいて前記各プレーヤー間、またはプレーヤーとサーバー運営者間でポイントの再分配を行う贈与ポイント再分配ステップとを有することを特徴とする情報処理方法。
【請求項２】
複数プレーヤーがネットワークを通じて仮想的な盤面を共有するネットワークゲームにおいて、複数プレーヤーとサーバー運営者が保持しているポイントデータと、前記仮想的な盤面を記述する盤面データと、プレーヤーの要求に応じて前記盤面データを戻す盤面戻しステップと、前記盤面戻しステップで戻された回数を記録する盤面戻し同数記録と、前記盤面戻し回数記録に基づいてプレーヤー間、またはプレーヤーとサーバー運営者間で再分配される贈与ポイントを計算する贈与ポイント計算ステップと、前記贈与ポイント計算ステップの結果に基づいて前記各プレーヤー間、またはプレーヤーとサーバー運営者間でポイントの再分配を行う贈与ポイント再分配ステップとを有することを特徴とする情報処理方法。
【請求項３】
前記贈与ポイント計算ステップにおいて、贈与ポイントが持ち時間追加回数、または、盤面戻し回数に関する等比級数となることを特徴とする請求項１または請求項２に記載の情報処理方法。
【請求項４】
コンピュータに、複数プレーヤーとサーバー運営者が保持しているポイントデータと、プレーヤー毎に保持している持ち時間データを記録させ、プレーヤーの要求に応じて前記持ち時間データを追加する持ち時間追加ステップと、前記持ち時間追加ステップで追加された回数を記録する持ち時間追加回数記録と、前記持ち時間追加回数記録に基づいてプレーヤー間、またはプレーヤーとサーバー運営者間で再分配される贈与ポイントを計算する贈与ポイント計算ステップと、前記贈与ポイント計算ステップの結果に基づいて前記各プレーヤー間、またはプレーヤーとサーバー運営者間でポイントの再分配を行う贈与ポイント再分配ステップとを実行させることを特徴とするコンピュータ読み取り可能なプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明はネットワークを介して複数人が同じゲームをプレイする情報処理方法に関するものである。ここでいうゲームとは、例えば囲碁、将棋等の２人でプレイするボードゲーム、麻雀などの３人以上でプレイするゲームなどがある。
【背景技術】
【０００２】  従来、ネット碁会所に代表されるインターネットを介してプレイする仮想ボードゲームが存在した。これはサーバー上に存在する仮想の碁盤を遠隔地にいる二人のプレーヤーが交互に操作することによって遊ぶというものである。そして、同じ技術は将棋、麻雀等のボードゲームにも適用され、ネット将棋、ネット麻雀を遠隔地にいる複数のプレーヤーが楽しんでいる。このような対戦型のネットゲームではプレーヤーの強さがランク付けされており、勝率が上がるとレベルが上がり、勝率が下がるとレベルが下がるというシステムになっている。そして現在待機しているプレーヤーの一覧表示をこのレベル順にすることによって、どのレベルのプレーヤーがどれぐらい存在するかが一目でわかる仕組みになっている。
【発明の概要】
【発明が解決しようとする課題】
【０００３】  しかしながら、上記従来の方法は、基本的に同じレベルのプレーヤーがプレイすることが多かった。ハンディキャップを弱いプレーヤーに与えることによって、相対的に弱いプレーヤーも同じゲームに参加することも可能であったが、その場合、相対的に強いプレーヤーの欲求不満が募ることとなった。結果、ハンディ戦はあまり実施されることがなく、弱いプレーヤーが強いプレーヤーとの対戦を通じて成長する機会が限られるという現象が起こっていた。
【課題を解決するための手段】
【０００４】  そこで、本発明によれば、複数プレーヤーがネットワークを通じて仮想的な盤面を共有するネットワークゲームにおいて、情報処理方法に、プレーヤー毎に保持しているポイントデータと、プレーヤー毎に保持している持ち時間データと、プレーヤーの要求に応じて前記持ち時間データを追加する持ち時間追加ステップと、前記持ち時間追加ステップで追加された回数を記録する持ち時間追加回数記録と、前記持ち時間追加回数記録に基づいてプレーヤー間で再分配される贈与ポイントを計算する贈与ポイント計算ステップと、前記贈与ポイント計算ステップの結果に基づいて前記各プレーヤー間でポイントの再分配を行う贈与ポイント再分配ステップとを備える。
【発明の効果】
【０００５】  相対的に強いプレーヤーのインセンティブが上がり、強いプレーヤーと弱いプレーヤーとの対戦が増えるという効果がある。
【図面の簡単な説明】
【０００６】
【図１】実施形態１の処理手順を説明するデータの流れを説明する図である。
【図２】実施形態の情報処理装置のハードウェア構成を表す図である。
【図３】実施形態１の処理手順を説明するフローチャートである。
【図４】実施形態１のユーザーインターフェースを説明する図である。
【発明を実施するための形態】
【０００７】  以下、添付図面を参照しながら本発明の実施形態を説明する。
【０００８】  ＜実施形態１＞
図１は、実施形態１による情報処理方法の基本的なデータの流れを説明する図である。図１を詳述する前に、本実施形態の情報処理方法が実装される装置の構成について説明する。
【０００９】  図２は、以下の実施形態に係わる情報処理装置のハードウェア構成を示すブロック図である。なお、図２に示すのは、最も典型的な情報装置としてサーバーコンピュータをモデルにした構成となっている。しかしながら、本情報処理装置としてはこれに限ったものではなく、ピアツーピアネットワークを構成するタブレット端末などであってもよい。
【００１０】  ＣＰＵ２０１は、後述するフローチャートに対応する処理手順を含む各種プログラムを実行し、装置各部の制御をおこなう。ＲＯＭ２０２は、不揮発性のメモリであり、情報処理装置を初期動作させる際に必要なプログラムなどを記録する。ＲＡＭ２０３は、ＣＰＵ２０１のワークエリアを提供し、２次記憶装置２０４から読み出されたプログラムなどを一時記憶する。２次記憶装置２０４は、ＯＳ２１１、アプリケーション２１２、モジュール２１３、およびデータ２１４を格納する。
【００１１】  各デバイス２０１〜２０４は、バス２０５を通して情報をやりとりする。情報処理装置は、バス２０５を介して、ディスプレイ２０６、キーボード２０７、マウス２０８、ネットワークデバイス２０９とつながっている。そしてネットワークデバイス２０９はインターネットを介して各プレーヤーの端末とつながっている。
【００１２】  本実施形態の情報処理方法は、データとして１０１ポイントデータ、１０２持ち時間データ、１０３盤面データ、１０８持ち時間追加回数、１０９盤面戻し回数を保持する。そしてＳ１０４ポイント追加ステップ、Ｓ１０５贈与ポイント再分配ステップ、Ｓ１０６贈与ポイント計算ステップ、Ｓ１０７持ち時間追加ステップ、Ｓ１１０盤面戻しステップを実行する。
【００１３】  図１は特に、対戦者Ａが本発明にかかわる情報処理を実行した場合を記述している。１０１ポイントデータはＡ、Ｂ、Ｃのポイントデータに区分されている。ここでＢはもう一人の対戦者であり、Ｃはサーバー運営者を意味している。本実施形態は２人でプレイするゲームを想定しているが、本発明に係わる情報処理方法は、もちろん３人以上でプレイするゲームにも適用可能である。
【００１４】  １０２持ち時間データＡとは対戦者Ａの持ち時間である。ここでいう持ち時間とは、単純な時間のみではなく、考える時間という意味で使用している。具体的に持ち時間とはＮＨＫの囲碁将棋棋戦で採用されている考量時間のように例えば３０秒を超えたカウントダウンを行える回数でも構わない。以降の説明では、例えば１０分というような単純な持ち時間を指すとする。
【００１５】  まず、Ａのリクエストに応じてＳ１０７持ち時間追加ステップが実行される。すると１０２持ち時間データＡが加算され、１０８持ち時間追加回数がプラス１される。次に、Ｓ１０６贈与ポイント計算ステップは１０８持ち時間追加回数を用いて贈与ポイントを計算する。一番単純な計算方法は贈与ポイントは、時間追加回数に関係なく贈与ポイントを計算する方法である。この場合、何回時間を追加したとしても、例えば、贈与ポイントは１００ポイントとなる。一方、持ち時間は平等であるべきで、一方的な持ち時間の追加にはペナルティをつけるべきだという考え方もある。この考え方に基づくと、例えば、１回目の持ち時間追加では１００ポイント、２回目の持ち時間追加ではそれの１０倍の１０００ポイント、３回目の持ち時間追加ではそれの１０倍の１００００ポイント、というふうに、持ち時間追加回数に関して等比級数的に計算する方法もある。
【００１６】  一方、１０３盤面データは現在の盤面情報と現在の手番情報を内包する。２人のゲームではＡ、Ｂ、Ａ、Ｂと交互に手番が回ってくる。Ｓ１１０盤面戻しステップとは、いわゆる“待った”をすることを意味し、具体的にはＡの打った手をキャンセルする。もしＢが既に着手していたらＢとＡの打った手をキャンセルする。
【００１７】  Ａのリクエストに応じてＳ１１０盤面戻しステップが実行されると、１０３盤面データが、１手もしくは２手戻され、１０９盤面戻し回数がプラス１される。そしてＳ１０６贈与ポイント計算ステップが１０９盤面戻し回数を用いて贈与ポイントを計算する。この計算方法は１０８持ち時間追加回数を用いて計算したアルゴリズムと同じであってもよいし、異なっていてもよい。
【００１８】  最終的にＳ１０６贈与ポイント計算ステップで計算された贈与ポイントに従って、Ｓ１０５贈与ポイント再分配ステップが実行される。例えば、贈与ポイントが１００ポイントだったとすると、ポイントデータＡから１００ポイントを減算し、ポイントデータＢおよびポイントデータＣを５０ポイントずつ加算する。なお、この配分方法はもちろん等価配分ではなく、比例配分でも構わない。
【００１９】  ポイントデータＡからポイントを減算する際に、ポイントが０になるようならＳ１０４ポイント追加ステップをＡのリクエストに基づき実行することによってポイントを加算する。なお、このＳ１０４ポイント追加ステップは事前に行っておいても構わない。
【００２０】  次に図３のフローチャートを用いて図１の処理手順を詳述する。ゲームがスタートするとステップＳ３０１ゲーム情報初期化が行われる。このステップは盤面情報、手番情報、ハンディキャップ情報、持ち時間情報などのゲームに必要な情報すべてを初期化する。
【００２１】  次に、ステップＳ３０２で盤面表示を行い、ステップＳ３０３で現在の手番のプレーヤーの着手取得がなされる。そして、ステップ３０４で着手があったかどうかが判断される。手番のプレーヤーが考量時間中の場合、この結果はＮＯで、制御はステップＳ３０８の待った取得に移る。一方、ＹＥＳだった場合は、その手の結果終局になるかどうかのチェックをするステップＳ３０５に移る。
【００２２】  囲碁の場合ならパスが２回続いたケース、将棋の場合は王将を取られたケース、麻雀の場合はプレーヤーの一人があがったケースに、通常の終局となる。もちろんどちらが降参した結果終局する場合もある。着手の結果、終局でないと判断されたらステップＳ３０６の盤面更新を実行し、次にステップＳ３０７の手番交代を実行した後、ステップＳ３０２の盤面表示に戻る。
【００２３】  手番のプレーヤーが考量時間中だった場合、処理はステップＳ３０８へ移る。ここでプレーヤーの待ったを取得して、ステップ３０９で待ったがあったかどうかを判断する。もしプレーヤーが待ったをした場合は、ステップＳ３１０の贈与ポイント計算ステップＳ３１０の贈与ポイント計算を実行し、ステップＳ３１１の贈与ポイント再分配を実行し、続いてステップＳ３１２で盤面を１手または２手戻した後で、ステップＳ３０２の盤面表示に戻る。
【００２４】  プレーヤーの待ったリクエストがなかった場合、処理はステップＳ３１３に移る。ここでプレーヤーの持ち時間追加リクエストを取得して、ステップ３１４で持ち時間追加リクエストがあったかどうかを判断する。もしプレーヤーが持ち時間追加リクエストをした場合は、ステップＳ３１５の贈与ポイント計算ステップＳ３１６の贈与ポイント計算を実行し、ステップＳ３１７の贈与ポイント再分配を実行し、続いてステップＳ３１９の微小時間スリープに処理が移る。この微小時間とは例えば１０ミリ秒ほどの時間である。このステップはコンピュータでループが続けてまわりビジー状態になるのを防ぐ意味がある。そして、最後にステップＳ３０２の盤面表示に戻る。
【００２５】  ステップＳ３１４で持ち時間追加リクエストがないと判断された場合、ステップＳ３１８の時間切れチェック判断に処理が移る。ステップＳ３１８の時間切れチェックの結果、プレーヤーの一人が時間切れと判断された場合は、ゲームが終了となる。時間切れでないと判断されたら、ステップＳ３１９の微小時間スリープに処理が移る。なお、ゲームのほとんどの時間帯は、手番プレーヤーの考量時間で、待ったリクエストも待ち時間追加リクエストもないので、Ｓ３０２、Ｓ３０３，Ｓ３０４、Ｓ３０８、Ｓ３０９、Ｓ３１３、Ｓ３１４、Ｓ３１８、Ｓ３１９、そしてＳ３０２に戻るというループが回ることとなる。
【００２６】  最後に図４を用いて、本実施形態の典型的なユーザーインターフェースを説明する。なお、図４はあくまでインターフェースの例であり、本発明はこのインターフェースに限るものではない。図４（ａ）は端末画面であり、プレーヤーが見ている画面となる。画面中央に４０１盤面がある。その下に対戦者の残り時間（４０２）が表示してある。
【００２７】  その下に本実施形態に特有なインターフェースがある。４０３の追加できる時間表示と４０４の待ったできる回数表示である。これは当該プレーヤーの残りポイント数から逆算して追加できる時間と待ったできる回数を表示している。そして、４０５のポイント追加ボタンでいつでもポイントを追加することによって、４０３、４０４を増やすことができる。
【００２８】  ４０３、４０４のインターフェース部品は表示と同時にボタンにもなっており、これらのボタンをユーザーが押すことによって、それぞれＳ１０７持ち時間追加ステップ、Ｓ１１０盤面戻しステップが実行される。この時、Ｓ１０５の贈与ポイント再分配ステップも実行されるのだが、その直前に図４（ｂ）に示したようなダイアログボックスを表示してプレーヤーに最終確認を促しても良い。
【００２９】  また、時間切れ終局する直前に図４（ｃ）に示したようなダイアログボックスを表示してもよい。このボックスには４０６のカウントダウン表示があり、例えば時間切れ終局する前の１０秒間だけＳ１０７持ち時間追加ステップを実行できるチャンスが与えられている。
【００３０】  ＜他の実施形態＞
以上、実施形態を詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、１つの機器からなる装置に適用しても良い。
【００３１】  尚、本発明は、ソフトウェアのプログラムをシステム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによって前述した実施形態の機能が達成される場合を含む。この場合、供給されるプログラムは実施形態で図に示したフローチャートに対応したコンピュータプログラムである。
【００３２】  また、コンピュータが、コンピュータ読み取り可能なプログラムを読み出して実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳなどとの協働で実施形態の機能が実現されてもよい。この場合、ＯＳなどが、実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される。
【図１】
2013230330.tif 000003
【図２】
2013230330.tif 000004
【図３】
2013230330.tif 000005
【図４】
2013230330.tif 000006