JP2017038808A - オンラインゲーム開発システム - Google Patents

Abstract

【課題】より高品質なオンラインゲームを開発するシステムを提供する。
【解決手段】開発したいオンラインゲームの構成を表す通信指向型状態遷移図を作成し、この状態遷移図に基づいてオンラインゲームの各プラグインを開発する。クライアント端末およびゲームサーバの間で行う複数の通信を１つに集約することで、通信障害発生時のリカバリをより容易にする。
【選択図】図５

Description

本発明は、サーバおよびクライアント端末の間で行う通信を伴うオンラインゲームを開発するシステムに関する。

近年、オンラインゲームの需要が高まっている。オンラインゲームとは、ゲームのプレイヤーが操作するゲーム端末が、ゲームのプレイ中またはその前後に、ゲームサーバなどの他コンピュータと通信するタイプのコンピュータゲームである。したがって、オンラインゲームを開発する際には、プレイヤーがゲーム端末上で実行するクライアント側のアプリケーションソフトウェアに加えて、ゲームサーバが実行するサーバ側のアプリケーションソフトウェアをも用意する必要がある。

オンラインゲームでは、複数のプレイヤーが同じゲームサーバと通信することによって、それぞれのプレイヤーが他のプレイヤーと協力することも、反対に競争することも可能である。複数のプレイヤーが同時に影響し合えるタイプのオンラインゲームを、ここではリアルタイム型オンラインゲームと呼ぶ。

また、オンラインゲームでは、自分のプレイ結果データをゲームサーバ上に残すことも、反対に他プレイヤーのプレイ結果データをゲームサーバから取得することも可能である。複数のプレイヤーが非同期的に影響し合えるタイプのオンラインゲームを、ここでは非リアルタイム型オンラインゲームと呼ぶ。

オンラインゲームは、上記のような優位性を持つ半面、ゲーム端末およびゲームサーバの間の通信に障害が発生した場合にこれを克服する必要がある。そのための工夫は、クライアント側およびサーバ側の両方のアプリケーションソフトウェアに、オンラインゲームを開発する際に予め用意しておくことが好ましい。

上記に関連して、特許文献１（特許４０７２０１７号）では、状態推定装置に係る発明が開示されている。この状態推定装置は、観測により時系列に入力される観測信号に基づいて、その観測を行ったシステムの内部状態を推定する。この状態推定装置は、濾波推定手段と、予測推定手段とを有する。ここで、濾波推定手段は、観測信号と先に推定した内部状態と予め設定された推定規則とに基づいて、現在の内部状態を推定するものであって、観測信号の種類に対応して多段接続される。また、予測推定手段は、内部状態と予め設定されたその内部状態を遷移させる状態遷移規則とに基づいて、未来の内部状態を推定するものであって、内部状態の種類に対応して多段接続される。

また、特許文献２（特許４４０２６６７号）では、タイミングチャート処理システムに係る発明が開示されている。このタイミングチャート処理システムは、ハードウェア及びソフトウェアでの処理タイミングを表すものである。このタイミングチャート処理システムは、関連情報取得手段と、処理期間情報取得手段と、タイミングチャート作成手段と、見積もり手段と、表示手段とを有することを特徴とする。ここで、関連情報取得手段は、ハードウェア及びソフトウェアでの処理相互の関連を表す関連情報を取得する。処理期間情報取得手段は、ハードウェア及びソフトウェアそれぞれの処理期間を表す処理期間情報を取得する。タイミングチャート作成手段は、取得された関連情報及び処理期間情報に基づいて、ハードウェア及びソフトウェアのいずれかでの処理を契機とするハードウェア及びソフトウェアそれぞれの処理にて構成される一連の処理における、ハードウェア及びソフトウェアそれぞれの処理のタイミングを特定して表したタイミングチャートを作成する。見積もり手段は、作成されたタイミングチャートに基づいて、一連の処理に対して見積もられる期間を見積もり処理期間として演算する。表示手段は、タイミングチャートの画像及び見積もり処理期間の情報を表示する。ソフトウェアの処理期間を表す処理期間情報は、処理期間の最大と最小とを表す情報を含む。タイミングチャート作成手段は、ソフトウェアの処理期間の最大と最小とを区別して当該ソフトウェアの処理タイミングを表すタイミングチャートを作成する。見積もり手段は、一連の処理に対して見積もられる最大の期間と最小の期間とを見積もり処理期間として演算する。

また、特許文献３（特許４８６４８６７号）では、モデル検査支援装置に係る発明が開示されている。このモデル検査支援装置は、状態遷移系として表されたシステムの動作に関する仕様と制約条件とを記述したモデル検査プログラムから、システムの動作に関する仕様に基づいて可能な全ての動作シーケンスを生成し、生成されたそれぞれの動作シーケンスにおいて制約条件が満たされているかどうかを検証するモデル検査器で検査されるモデル検査プログラムを生成する。このモデル検査支援装置は、仕様入力部と、モデル生成部を有する。ここで、仕様入力部は、システムの動作に関する仕様とシステムに求める性質である制約条件とを表形式の情報として受け取る。モデル生成部は、この表からシステムの動作に関する仕様と制約条件とを抽出して所定のモデル記述言語によってシステムの動作に関する仕様と制約条件とを記述したモデル検査プログラムを生成する。
この表は、状態遷移表と、制約条件表と、アクション表と、条件判定表とを有する。ここで、状態遷移表は、システムで発生するイベントとシステムの各状態に対応して、システムが実行するアクション名と次に遷移する状態とを記述する。制約条件表は、状態遷移表で定義された状態毎に、当該システムを構成する要素の値を記述する。アクション表は、アクション名に対応して、当該アクションの実行によるシステムを構成する要素の値の変化と、システムを構成する要素の値で表される当該アクションの実行前後で成立していなければならない条件とを規定する。条件判定表は、状態遷移表において記述可能になされた、アクションあるいは遷移の実行が可能か否かを判定するための判定条件を、システムを構成する要素の値として記述する。
モデル検査プログラムは、システムの動作に関する仕様を、状態遷移表と、条件判定表と、アクション表で規定されたアクションの実行によるシステムを構成する要素の値の変化とに基づいて記述し、制約条件を、制約条件表と、アクション表で規定されたアクションの実行前後で成立していなければならない条件とに基づいて記述する。

また、非特許文献１（大規模ＲＰＧのためのシナリオ記述言語と統合開発環境の開発）では、ＲＰＧやアドベンチャーゲームに分類されるビデオゲームにおいてシナリオを記述する言語と、この言語を用いるＩＤＥ（Ｉｎｔｅｇｒａｔｅｄ Ｄｅｖｅｌｏｐｍｅｎｔ Ｅｎｖｉｒｏｎｍｅｎｔ：統合開発環境）とが提案されている。

また、非特許文献２（ゲームプログラムのシナリオに基づいた状態遷移系を生成するシステムの提案）では、ゲームプログラムにおけるオブジェクトやシナリオ、プログラムが走るマシン環境などを単位としてまとめ、その振る舞いを個別のゲームプログラムの状態遷移として記述し、ゲーム全体の振舞を、個別の状態遷移の積としてコンパイルするシステムが提案されている。

また、非特許文献３（ＦＤＲによるＲＰＧシナリオの検証）では、複雑に分岐するストーリを含むＲＰＧ（Ｒｏｌｅ Ｐｌａｙｉｎｇ Ｇａｍｅ：ロールプレイングゲーム）のシナリオを、複数のキャラクタによる行動の集合と捉える、キャラクタ指向開発が提案されている。

また、非特許文献４（レゴプログラム向け状態遷移図設計支援システム）では、状態遷移図に対する状態指向という概念の提案がなされている。また、そのような状態遷移図の有用性を評価していくために、レゴのプログラミングに状態指向の状態遷移図の概念を取り入れた状態遷移図設計支援システムが提案されている。

また、非特許文献５（「モデル検査」のススメ（ゲームシナリオ進行編））では、コンピュータゲームにおけるシナリオ進行を検証するにあたって、ソフトウェア工学において検討されてきた「モデル検査」を用いる手法が提案されている。

また、非特許文献６（高品質ノベルゲーム開発基盤の提案）では、ノベルゲームを開発するにあたって、ＤＳＬ（Ｄｏｍａｉｎ Ｓｐｅｃｉｆｉｃ Ｌａｎｇｕａｇｅ：）、ＦＳＰ（Ｆｉｎｉｔｅ Ｓｔａｔｅ Ｐｒｏｃｅｓｓｅｓ）表現、モデル検査、香盤表などの利用が提案されている。

特許４０７２０１７号 特許４４０２６６７号 特許４８６４８６７号

清木昌、「大規模ＲＰＧのためのシナリオ記述言語と統合開発環境の開発」、２００３年３月、［平成２７年８月６日検索］、インターネット＜ＵＲＬ：http://www.ipa.go.jp/files/000005647.pdf＞ 金城拓実、河野真治、「ゲームプログラムのシナリオに基づいた状態遷移系を生成するシステムの提案」、日本ソフトウェア科学会第２１回大会（２００４年度）論文集、２００４年９月発行、［平成２７年８月６日検索］、インターネット＜ＵＲＬ：http://www.ie.u-ryukyu.ac.jp/~kono/papers/kono/2004/jsss-kinjo-2004.pdf＞ 長久勝、「ＦＤＲによるＲＰＧシナリオの検証」、２００７年、［平成２７年８月１１日検索］インターネット＜ＵＲＬ：http://www.slideshare.net/mnagaku/fdr-rpg＞ 今井康平、紫合治著、「レゴプログラム向け状態遷移図設計支援システム」、２０１２年０３月０８日発行、「研究報告ソフトウェア工学（ＳＥ）」第２０１２−ＳＥ−１７５巻、第７号、第１〜８頁 長久勝、「「モデル検査」のススメ（ゲームシナリオ進行編）」、２０１３年、［平成２７年８月１１日検索］、インターネット＜ＵＲＬ：http://www.slideshare.net/mnagaku/cedec2013mnagaku4946＞ 長久勝、「高品質ノベルゲーム開発基盤の提案」、２０１４年９月１１日、［平成２７年８月１１日検索］、インターネット＜ＵＲＬ：http://www.juse.jp/sqip/symposium/2014/timetable/files/happyou_B2-3.pdf＞

より高品質なオンラインゲームを開発するシステムを提供する。その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

以下に、（発明を実施するための形態）で使用される番号を用いて、課題を解決するための手段を説明する。これらの番号は、（特許請求の範囲）の記載と（発明を実施するための形態）との対応関係を明らかにするために付加されたものである。ただし、それらの番号を、（特許請求の範囲）に記載されている発明の技術的範囲の解釈に用いてはならない。

一実施の形態によれば、オンラインゲーム開発システム（２）は状態遷移図作成機能部を有し、状態遷移図作成機能部はオンラインゲームの構造を表す通信指向型状態遷移図を作成する。

前記一実施の形態によれば、サーバおよびクライアント端末の間で行う通信の不具合をリカバリし易い、高品質なオンラインゲームを開発することが出来る。

図１Ａは、オンラインゲームを運用するシステムの一構成例を示すブロック図である。 図１Ｂは、図１Ａに示した各コンピュータの一般的な構成例を示すブロック図である。 図２Ａは、機能指向的な方法で開発された従来のオンラインゲームにおいて、クライアント端末およびサーバの間で行う理想的な通信の一例を示すタイムチャートである。 図２Ｂは、図２Ａに例示した通信で起こり得る通信障害の一例を示すタイムチャートである。 図２Ｃは、図２Ｂに例示した通信障害を復旧する方法の一例を示すタイムチャートである。 図３Ａは、通信指向的な方法で開発されたオンラインゲームにおいて、クライアント端末およびサーバの間で行う理想的な通信の一例を示すタイムチャートである。 図３Ｂは、図３Ａに例示した通信で起こり得る通信障害およびその復旧の一例を示すタイムチャートである。 図４は、通信指向的な方法で開発するオンラインゲームの一構成例を表す通信指向型状態遷移図である。 図５は、本発明のオンラインゲーム開発システムの一構成例を示すブロック図である。 図６は、本発明のオンラインゲーム開発システムの一構成例を機能別に示すブロック図である。 図７Ａは、本発明のオンラインゲームの開発方法の一構成例を示すフローチャートの一部である。 図７Ｂは、図７Ａに示したフローチャートの残りである。

添付図面を参照して、本発明によるオンラインゲーム開発システムを実施するための形態を以下に説明する。

まず、本発明によるオンラインゲーム開発システムで開発するオンラインゲームについて説明する。なお、ここでは主に非リアルタイム型のオンラインゲームの場合について述べるが、これはリアルタイム型のオンラインゲームに係る権利範囲を排除するものではない。

（実施形態）
図１Ａは、オンラインゲームを運用するシステムの一構成例を示すブロック図である。

図１Ａに示したオンラインゲームシステムの構成要素について説明する。オンラインゲームシステム１は、クライアント端末１１、１２と、ネットワーク２０と、アプリケーションサーバ２１と、ゲームサーバシステム３０とを含んでいる。ゲームサーバシステム３０は、ゲームサーバ３１と、運用管理ユーザインタフェースサーバ３２と、ゲームデータベース３３とを含んでいる。

図１Ａに示した各構成要素の接続関係について説明する。クライアント端末１１、１２と、アプリケーションサーバ２１と、ゲームサーバ３１とは、それぞれ、ネットワーク２０に接続されている。

その他、ゲームサーバ３１と、運用管理ユーザインタフェースサーバ３２と、ゲームデータベース３３とは、相互に接続されている。なお、この接続関係は、ネットワーク２０を介していても良いし、図示しない別のネットワークを介していても良い。

図１Ａに示した各構成要素の動作について説明する。クライアント端末１１、１２のそれぞれは、例えば、パーソナルコンピュータや、ゲーム専用機器や、スマートフォンなどの、オンラインゲームのクライアント側アプリケーションソフトウェアを実行可能で、かつ、通信機能を有する情報端末であり、ネットワーク２０は、例えば、インターネットや、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ：ローカルエリアネットワーク）などの、複数の端末を通信可能に接続するネットワーク回路である。アプリケーションサーバ２１は、オンラインゲームのクライアント側アプリケーションソフトウェアを、ネットワーク２０を介してクライアント端末１１、１２などに供給するサーバである。ゲームサーバ３１は、オンラインゲームのサーバ側アプリケーションソフトウェアを実行し、かつ、ネットワーク２０を介してクライアント端末１１、１２で実行されるクライアント側アプリケーションソフトウェアのそれぞれとの通信を行う。運用管理ユーザインタフェースサーバ３２は、ゲームサーバ３１の運用管理や監視を行う。ゲームデータベース３３は、オンラインゲームで利用される各種データのうち、不揮発な情報を主に格納し、必要に応じてゲームサーバ３１に提供する。

図１Ａに示したクライアント端末１１、１２、アプリケーションサーバ２１、ゲームサーバ３１、運用管理ユーザインタフェースサーバ３２およびゲームデータベース３３のそれぞれは、例えば、所定のプログラムを実行するコンピュータとして実現可能である。

図１Ｂは、図１Ａに示した各コンピュータの一般的な構成例を示すブロック図である。

図１Ｂに示したコンピュータ１００の構成要素について説明する。コンピュータ１００は、バス１０１と、通信装置１０２と、演算装置１０３と、記憶装置１０４と、入力装置１０５と、出力装置１０６と、外部記憶装置１０７とを含む。ここで、図１Ａに示した各コンピュータは、図１Ｂに示した構成要素のうち、一部だけを含んでいても良いし、他の構成要素をさらに含んでいても良い。

図１Ｂに示した各構成要素の接続関係について説明する。バス１０１は、通信装置１０２と、演算装置１０３と、記憶装置１０４と、入力装置１０５と、出力装置１０６と、外部記憶装置１０７とに接続されている。

その他、通信装置１０２は、ネットワーク２０に接続されていることが好ましい。また、外部記憶装置１０７は着脱可能な記憶媒体１０８に接続されていることが好ましい。

図１Ｂに示した各構成要素の動作について説明する。バス１０１は、複数の構成要素の間で通信を仲介するネットワーク回路である。なお、図１Ｂではバス１０１を象徴的に表しており、実際には複数のネットワーク回路に分かれていても良いし、これら複数のネットワーク回路のそれぞれが図１Ｂに示した複数の構成要素の一部だけに接続されていても良い。

演算装置１０３は、例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：中央演算装置）などであって、プログラムやアプリケーションソフトウェアを実行する。

記憶装置１０４は、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ：ランダムアクセスメモリ）や、不揮発性のストレージなどを含み、プログラムや、アプリケーションソフトウェアや、各種のデータを格納し、必要に応じてこれらを演算装置に提供する。

入力装置１０５は、例えばキーボードや、物理ボタンや、液晶ディスプレイと一体型のタッチパネルや、カメラモジュールなどであって、利用者による操作や、外部環境などに基づく各種信号を入力して演算装置１０３に提供する。

出力装置１０６は、例えば液晶ディスプレイや、スピーカや、バイブレーション機能部などであって、演算装置１０３の出力信号を外部に出力する。

外部記憶装置１０７は、例えば光学メディアドライブなどであって、記憶媒体１０８としての光学メディアなどからプログラムや、アプリケーションソフトウェアや、データなどを読み取る。

次に、オンラインゲームを開発するにあたって、従来の機能指向的な方法に対して、本実施形態で提案する方法が通信指向的であることについて、ゲーム内の一場面であるバトル開始時に行う通信を例に挙げて説明する。

ここでは、プレイヤーが選択した番号に対応するステージマップ上に予め配置された複数の敵キャラクターを、他の参加メンバから提供される複数の味方キャラクターと協力して倒すことを目的とするバトルについて考える。クライアント端末で実行されるクライアント側アプリケーションソフトウェアは、バトル開始時に、ステージマップ情報と、敵配置情報と、参加メンバ情報とを、ゲームサーバ３１から取得する必要がある。ここで、ステージマップ情報はステージマップを定義し、敵配置情報は敵キャラクターの種類や位置関係を定義し、参加メンバ情報はプレイヤーに協力してくれる参加メンバとその味方キャラクターを定義する。

図２Ａは、機能指向的な方法で開発された従来のオンラインゲームにおいて、クライアント端末およびサーバの間で行う理想的な通信の一例を示すタイムチャートである。

図２Ａに示したタイムチャートでは、クライアント端末１１で実行されるクライアント側アプリケーションソフトウェアが、ステージマップ管理機能１１１と、敵配置管理機能１１２と、参加メンバ管理機能１１３とを含んでいる。ここで、ステージマップ管理機能１１１はステージマップ情報を管理しており、必要に応じて指定したステージのステージマップ情報をゲームサーバ３１から取得する。同様に、敵配置管理機能１１２は敵配置情報を管理しており、必要に応じて指定したステージの敵配置情報をゲームサーバ３１から取得する。同様に、参加メンバ管理機能１１３は参加メンバ情報を管理しており、必要に応じてバトルに参加する参加メンバ情報をゲームサーバ３１から取得する。

さらに、ゲームサーバ３１で実行されるサーバ側アプリケーションソフトウェアも、ステージマップ管理機能３１１と、敵配置管理機能３１２と、参加メンバ管理機能３１３とを含んでいる。ここで、ステージマップ管理機能３１１はステージマップ情報を管理しており、クライアント端末１１からのリクエストに応じて指定されたたステージのステージマップ情報を提供する。同様に、敵配置管理機能３１２は敵配置情報を管理しており、クライアント端末１１からのリクエストに応じて指定されたステージの敵配置情報を提供する。同様に、参加メンバ管理機能３１３は参加メンバ情報を管理しており、クライアント端末１１からのリクエストに応じてバトルに参加する参加メンバ情報を提供する。

機能指向的に開発された従来のオンラインゲームでは、クライアント側アプリケーションソフトウェアに含まれるステージマップ管理機能１１１、敵配置管理機能１１２および参加メンバ管理機能１１３が、それぞれの機能によって分割された設計に基づいて通信を行う。同様に、サーバ側アプリケーションソフトウェアに含まれるステージマップ管理機能３１１、敵配置管理機能３１２および参加メンバ管理機能３１３も、それぞれの機能によって分割された設計に基づいて通信を行う。

図２Ａに示した例では、まずクライアント端末１１において、バトル開始時に、ステージマップ管理機能１１１がステージマップ管理機能３１１に向けてステージマップ情報リクエスト２０１を送信する。また、敵配置管理機能１１２が、ステージマップ管理機能１１１とは無関係に、敵配置管理機能３１２に向けて敵配置情報リクエスト２０２を送信する。さらに、参加メンバ管理機能１１３が、ステージマップ管理機能１１１および敵配置管理機能１１２とは無関係に、参加メンバ管理機能３１３に向けて参加メンバ情報リクエスト２０３を送信する。

次にゲームサーバ３１において、ステージマップ管理機能３１１は、ステージマップ情報リクエスト２０１を受信すると、ステージマップ管理機能１１１に向けてステージマップ情報２１１を送信する。また、敵配置管理機能３１２は、敵配置情報リクエスト２０２を受信すると、ステージマップ管理機能３１１とは無関係に、敵配置管理機能１１２に向けて敵配置情報２１２を送信する。さらに、参加メンバ管理機能３１３は、参加メンバ情報リクエスト２０３を受信すると、ステージマップ管理機能３１１および敵配置管理機能３１２とは無関係に、参加メンバ管理機能１１３に向けて参加メンバ情報２１３を送信する。

次にクライアント端末１１において、ステージマップ管理機能１１１は、ステージマップ情報２１１を受信すると、ステージマップ管理機能３１１に向けてステージマップ情報アクノリッジ２２１を送信する。また、敵配置管理機能１１２は、敵配置情報２１２を受信すると、ステージマップ管理機能１１１とは無関係に、敵配置管理機能３１２に向けて敵配置情報アクノリッジ２２２を送信する。さらに、参加メンバ管理機能１１３は、参加メンバ情報２１３を受信すると、ステージマップ管理機能１１１および敵配置管理機能１１２とは無関係に、参加メンバ管理機能３１３に向けて参加メンバ情報アクノリッジ２２３を送信する。

ここで、ステージマップ情報２１１と、敵配置情報２１２と、参加メンバ情報２１３とがクライアント端末１１に揃うと、クライアント側アプリケーションソフトウェアに含まれるバトル機能が動作を開始する。

次に、ゲームサーバ３１において、ステージマップ管理機能３１１がステージマップ情報アクノリッジ２２１を受信し、敵配置管理機能３１２が敵配置情報アクノリッジ２２２を受信し、参加メンバ管理機能３１３が参加メンバ情報アクノリッジ２２３を受信すると、サーバ側アプリケーションソフトウェアはクライアント側アプリケーションソフトウェアのバトル機能の動作開始を状況的に認識出来る。

このように、機能指向的に開発されたオンラインゲームでは、複数の機能がそれぞれに分割された通信を行う。図２Ａに示した理想的な場合はこれで問題無いが、通信障害が発生するとその復旧が困難となることを説明する。

図２Ｂは、図２Ａに例示した通信で起こり得る通信障害の一例を示すタイムチャートである。図２Ｃは、図２Ｂに例示した通信障害を復旧する方法の一例を示すタイムチャートである。図２Ｂおよび図２Ｃに示した例では、図２Ａに示した例に、いくつかの違いを加えたものに等しい。したがって、図２Ｂおよび図２Ｃのうち、図２Ａと重複する部分については詳細な説明を省略する。

図２Ａに示した例と比較して、図２Ｂに示した例では、第１の違いとして、ステージマップ情報リクエスト２０１の送信時に通信障害２０１ａが発生している。その結果、ステージマップ管理機能１１１では、ステージマップ情報２１１を受信しないままタイムオーバー２０１ｂが発生する。

さらに、第２の違いとして、参加メンバ情報２１３の送信時にも通信障害２１３ａが発生している。参加メンバ管理機能１１３では、参加メンバ情報２１３を受信しないままタイムオーバー２０３ｂが発生し、参加メンバ管理機能３１３では、参加メンバ情報アクノリッジ２２３を受信しないままタイムオーバー２１３ｂが発生する。

また、図２Ａに示した例と比較して、図２Ｃに示した例では、第１の違いとして、ステージマップ管理機能１１１は、タイムオーバー２０１ｂが発生した後、ステージマップ管理機能３１１に向けてステージマップ情報リクエストの再送２０１ｃを行っている。その結果、ステージマップ管理機能３１１およびステージマップ管理機能１１１の間で、ステージマップ情報２１１およびステージマップ情報アクノリッジ２２１を送信する通信が回復する。

さらに、第２の違いとして、参加メンバ管理機能１１３は、タイムオーバー２０３ｂが発生した後、参加メンバ情報リクエスト２０３の送信を再度行っている。その結果、参加メンバ管理機能１１３および参加メンバ管理機能３１３の間で、参加メンバ情報２１３の送信と、参加メンバ情報アクノリッジ２２３を送信する通信とが回復する。

ここで、クライアント端末１１に揃ったステージマップ情報２１１、敵配置情報２１２および参加メンバ情報２１３は、それぞれがゲームサーバ３１から送信された時刻が、タイムオーバー２０１ｂ、２０３ｂ、２１３ｂの影響により、大きく異なることに注目されたい。

オンラインゲームの場合は、期間限定イベントなどと呼ばれる期限付き仕様変更によって、バトルの各種条件が所定の時刻を境に切り替わることが少なくない。つまり、タイムオーバー２０１ｂ、２０３ｂ、２１３ｂなどの影響により、クライアント端末１１に揃ったステージマップ情報２１１、敵配置情報２１２および参加メンバ情報２１３の間で整合性が取れていない可能性を考慮して、予め対策を用意する必要がある。そして、このような対策の難易度は、整合性を取るべきデータの総数に応じて上昇する可能性がある。

例えば、タイムオーバー２０１ｂ、２０３ｂ、２１３ｂなどの間に、ゲームデータベースの更新などの永続的な情報の変更が発生した場合は、タイムオーバー後にデータの再送を行う前に、変更の取り消しが必要になる。したがって、情報の変更は、その取り消しが可能でなければならない。

このような困難を回避するために、発明者は、オンラインゲームの通信指向的な開発方法を提案する。発明者は、クライアント端末およびサーバの間の、情報の整合性の観点から、一連の処理は不可分なものとして扱われるべきであって、通信も１回の情報交換で完結させるべきであると考える。ここで、一連の処理とは、例えば、ステージマップ管理と、敵配置管理と、参加メンバ管理の処理のことであるが、この例に限定されない。

図３Ａは、通信指向的な方法で開発されたオンラインゲームにおいて、クライアント端末およびサーバの間で行う理想的な通信の一例を示すタイムチャートである。なお、図３Ａのうち、図２Ａと共通する部分については詳細な説明を省略する。

図３Ａに示したタイムチャートでは、クライアント端末１１で実行されるクライアント側アプリケーションソフトウェアが、ステージマップ管理機能１１１と、敵配置管理機能１１２と、参加メンバ管理機能１１３とに加えて、集約通信機能１１４をさらに含んでいる。集約通信機能１１４は、クライアント端末１１がゲームサーバ３１との間で行う通信を集約する。図３Ａの場合、集約通信機能１１４は、図２Ａで示したステージマップ情報リクエスト２０１、敵配置情報リクエスト２０２および参加メンバ情報リクエスト２０３からなる３つのリクエストを、単独の集約情報リクエスト２３１に集約してゲームサーバ３１に向けて送信する。

さらに、ゲームサーバ３１で実行されるサーバ側アプリケーションソフトウェアも、ステージマップ管理機能３１１と、敵配置管理機能３１２と、参加メンバ管理機能３１３とに加えて、集約通信機能３１４をさらに含んでいる。集約通信機能３１４は、ゲームサーバ３１がクライアント端末１１との間で行う通信を集約する。図３Ａの場合、集約通信機能３１４は、図２Ａで示したステージマップ情報２１１、敵配置情報２１２および参加メンバ情報２１３からなる３つの情報を、単独の集約情報２３２に集約してクライアント端末１１に向けて送信する。

集約通信機能１１４は、集約情報２３２を受信すると、集約情報アクノリッジ２３３を集約通信機能３１４に向けて送信する。

ここで、集約情報２３２がクライアント端末１１に届くことは、ステージマップ情報２１１と、敵配置情報２１２と、参加メンバ情報２１３とがクライアント端末１１に揃うことに等しい。このとき、クライアント側アプリケーションソフトウェアに含まれるバトル機能が動作を開始する。

集約通信機能３１４が集約情報アクノリッジ２３３を受信すると、サーバ側アプリケーションソフトウェアはクライアント側アプリケーションソフトウェアのバトル機能の動作開始を状況的に認識出来る。

このように、通信指向的に開発されたオンラインゲームでも、機能指向的に開発された場合と同様の通信を行うことが出来る。次に、通信障害が発生しても、その復旧が容易であることを説明する。

図３Ｂは、図３Ａに例示した通信で起こり得る通信障害およびその復旧の一例を示すタイムチャートである。図３Ｂに示した例では、図３Ａに示した例に、いくつかの違いを加えたものに等しい。したがって、図３Ｂのうち、図３Ａと重複する部分については詳細な説明を省略する。

図３Ａに示した例と比較して、図３Ｂに示した例では、第１の違いとして、集約情報リクエスト２３１の送信時に通信障害２３１ａが発生している。その結果、集約通信機能１１４では、集約情報２３２を受信しないままタイムオーバー２３１ｂが発生する。

さらに、第２の違いとして、集約通信機能１１４は、タイムオーバー２３１ｂの後、集約情報の再送２３１ｃを行っている。その結果、集約通信機能３１４および集約通信機能１１４の間で、集約情報２３２および集約情報アクノリッジ２３３を送信する通信が回復する。

ここで、例えばクライアント端末１１がバトルを開始する前に各種情報をリクエストする段階のままタイムオーバー２３１ｂが発生していたとしても、リクエストを受信していないゲームサーバ３１も同じ段階に留まることになる。したがって、タイムオーバー２３１ｂの後に通信が回復すれば、クライアント端末１１に届いた集約情報２３２に含まれるステージマップ情報２１１、敵配置情報２１２および参加メンバ情報２１３は、ゲームサーバ３１から送信された時刻にも差は無く、したがってさらなるリカバリ処理は不要である。

また、仮に通信障害が集約情報２３２の送信時に発生して、タイムオーバーが集約通信機能３１４で発生した場合は、クライアント端末１１は各種情報をリクエストする段階にとどまり、ゲームサーバ３１だけがその次のバトルの開始を認識する段階に進む、という問題が発生し得る。このような場合も、集約通信機能３１４にキャッシュ機能を設けるだけで、さらなるリカバリ処理は不要となる。

ここで、キャッシュ機能とは、集約情報リクエスト２３１などのリクエストへの返答として送信した集約情報２３２などの情報を所定の記憶領域に格納しておき、再度同じリクエストを受信した場合には格納しておいた情報を記憶領域から再送する機能である。上記の例では、ゲームサーバ３１がバトルを開始する段階に進んだまま、直前の段階に戻ることなく、集約通信機能３１４は一度送信した集約情報２３２を集約通信機能１１４に再送することが可能となる。このとき、通信障害のリカバリ処理が簡略化されているのみならず、ゲームサーバ３１の計算量も節約出来ていることに注目されたい。

このとき、タイムオーバー後にクライアント端末１１がゲームサーバ３１に向けて再送する集約情報リクエスト２３１は、ワンタイムセッションＩＤを含んでいることが好ましい。ワンタイムセッションＩＤを参照することで、ゲームサーバ３１は、受信するリクエストが、初めて送信された新しいリクエストであるのか、それとも過去に送信されたリクエストと同一のリクエストであるのかを判別出来る。すなわち、ゲームサーバ３１は、受信したリクエストが１つ古いワンタイムセッションＩＤを含んでいる場合には、キャッシュ機能により返信済みの情報を再送し、受信したリクエストが正規のワンタイムセッションＩＤを持つ場合には、集約通信機能３１４により初めて受信した新しいリクエストに対応する新たな情報を返信することが出来る。

図３Ａおよび図３Ｂに示したように、クライアント端末１１からゲームサーバ３１への全ての情報リクエストと、ゲームサーバ３１からクライアント端末１１への全ての情報提供とを、１回の情報交換で済ませることで、図２Ａ〜図２Ｃを参照して説明した従来の通信で必要とされた複雑なリカバリ処理について考えずに済む。

本実施形態では、クライアント端末１１およびゲームサーバ３１の間で、送受信する頻度を下げ、１度に送受信するデータを複雑化する。このことは、クライアント端末１１およびゲームサーバ３１の間で行う通信の解読をより困難にし、不正アクセスへの悪用を防止する効果をもたらす。さらに、ワンタイムセッションＩＤの採用により、リクエストのコピーを悪用した不正操作や、複数のクライアント側アプリケーションソフトの同時利用による意図的競合状態下での攻撃行為を防止する効果が得られる。

図３Ａおよび図３Ｂに例示した、通信指向型のオンラインゲームを開発する方法と、この方法を実現するための開発システムとについて説明する。

図４は、通信指向的な方法で開発するオンラインゲームの一構成例を表す通信指向型状態遷移図である。

図４に示した通信指向型状態遷移図の構成要素について説明する。図４の通信指向型状態遷移図は、ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ：統一モデリング言語）の表記法を拡張して表されており、合計８個の状態ノードＮ００〜Ｎ０７と、合計１３本の遷移エッジＥ０１〜Ｅ１３とを含んでいる。

ここで、状態ノードＮ００〜Ｎ０７は、オンラインゲームのプレイ中に切り替わる複数の内部状態をそれぞれ表す。図４の例では、各状態ノードを、角を丸めた長方形で表している。この長方形の上部には、各状態ノードのタイトルが表示されている。この長方形の下部には、各状態ノードの詳細を表示しても良いが、図４では省略している。

また、遷移エッジＥ０１〜Ｅ１３は、状態ノードＮ００〜Ｎ０７の間で行われる状態遷移と、状態遷移の際にクライアント端末１１およびゲームサーバ３１の間で行われる通信とを表す。各遷移エッジは、遷移元の状態ノードから遷移先の状態ノードに向かう矢印と、その際にクライアント端末およびゲームサーバの間で通信される入出力データとを含んでいる。矢印の下に配置された文字列のうち、スラッシュ記号「／」の左側部分に、遷移元の状態から遷移先の状態に遷移するきっかけとなる遷移トリガを示し、右側部分に、通信の名称と、クライアント端末１１からゲームサーバシステム３０への入力データと、ゲームサーバシステム３０からクライアント端末１１への出力データとを、「出力データ＝通信の名称（入力データ）」の形式で示す。

第０状態ノードＮ００は、通信型指向状態遷移図の開始点を示す。第１状態ノードＮ０１は、クライアント端末１１によるゲームサーバシステム３０へのログイン状態問い合わせを完了した状態を示す。第２状態ノードＮ０２は、クライアント端末１１がゲームサーバシステム３０へのログイン処理を完了した状態を示す。第３状態ノードＮ０３は、クライアント端末１１がゲームサーバシステム３０からお知らせ取得を完了し、メニュー画面を表示している状態を示す。第４状態ノードＮ０４は、クライアント端末１１がゲームサーバシステム３０からステージ一覧取得を完了し、ステージを選択する画面を表示している状態を示す。第５状態ノードＮ０５は、クライアント端末１１がゲームサーバシステム３０からアイテム一覧取得を完了し、アイテム購入画面を表示している状態を示す。第７状態ノードＮ０７は、クライアント端末１１がステージ番号や参加メンバをゲームサーバシステム３０に送信し、バトルを開始するために必要なステージマップや敵配置の情報取得を完了し、バトルを開始して終了するまでの状態を示す。第６状態ノードＮ０６は、クライアント端末１１がバトルの勝敗をゲームサーバシステム３０に送信し、獲得アイテムの通知を受け、バトルの結果を表示している状態を示す。

図４に示した各構成要素の接続関係について説明する。第１遷移エッジＥ０１は、通信「ログイン状態問い合わせ」を伴う、第０状態ノードＮ００から第１状態ノードＮ０１への状態遷移を示す。第２遷移エッジＥ０２は、通信「ログイン処理」を伴う、第１状態ノードＮ０１から第２状態ノードＮ０２への状態遷移を示す。第３遷移エッジＥ０３は、通信「お知らせ取得」を伴う、第１状態ノードＮ０１から第３状態ノードＮ０３への状態遷移を示す。第４遷移エッジＥ０４は、通信「お知らせ取得」を伴う、第２状態ノードＮ０２から第３状態ノードＮ０３への状態遷移を示す。第５遷移エッジＥ０５は、通信「ステージ一覧取得」を伴う、第３状態ノードＮ０３から第４状態ノードＮ０４への状態遷移を示す。第６遷移エッジＥ０６は、通信「アイテム一覧取得」を伴う、第３状態ノードＮ０３から第５状態ノードＮ０５への状態遷移を示す。第７遷移エッジＥ０７は、第４状態ノードＮ０４から第３状態ノードＮ０３への状態遷移を示す。第８遷移エッジＥ０８は、通信「バトル開始」を伴う、第４状態ノードＮ０４から第７状態ノードＮ０７への状態遷移を示す。第９遷移エッジＥ０９は、第５状態ノードＮ０５から第３状態ノードＮ０３への状態遷移を示す。第１０遷移エッジＥ１０は、通信「アイテム購入」を伴う、第５状態ノードＮ０５での自己ループ遷移を示す。第１１遷移エッジＥ１１は、第６状態ノードＮ０６から第４状態ノードＮ０４への状態遷移を示す。第１２遷移エッジＥ１２は、通信「バトル終了」を伴う、第７状態ノードＮ０７から第６状態ノードＮ０６への状態遷移を示す。第１３遷移エッジＥ１３は、通信「アイテム消費」を伴う、第７状態ノードＮ０７での自己ループ遷移を示す。

図４に示した通信指向型状態遷移図で表されるオンラインゲームの動作について説明する。まず、第０状態ノードＮ００において、オンラインゲームのクライアント側アプリケーションソフトウェアをクライアント端末１１上で起動する。第０状態ノードＮ００の次は、第１遷移エッジＥ０１を介して第１状態ノードＮ０１に遷移する。

第１遷移エッジＥ０１において、クライアント側アプリケーションソフトウェアは、クライアント端末１１がオンラインゲームにログインしている状態にあるか否かをゲームサーバシステム３０に確認する。

もし、クライアント端末１１が既にログインしている状態にあれば、第３遷移エッジＥ０３を介して第３状態ノードＮ０３に遷移する。このときクライアント端末１１は、メニューに表示するためのお知らせを、ゲームサーバシステム３０に問い合わせる。

反対に、もし、クライアント端末１１がまだログインしていない状態にあれば、第２遷移エッジＥ０２を介して第２状態ノードＮ０２に遷移する。このとき、クライアント端末１１は、ログインに必要な情報をゲームサーバシステム３０に伝え、ゲームサーバシステム３０はログインを受け入れた後の通信に使われるワンタイムセッションＩＤをクライアント端末１１に送信する。このとき、クライアント端末１１はプレイヤーにＩＤやパスワードなどの入力を求めても良いし、予め記憶されているＩＤやパスワードなどを自動的に利用しても良い。

第２状態ノードＮ０２において、クライアント端末１１がオンラインゲームへのログインを完了した状態となる。第２状態ノードＮ０２の次は、第４遷移エッジＥ０４を介して第３状態ノードＮ０３に遷移する。このときクライアント端末１１は、メニューに表示するためのお知らせを、ゲームサーバシステム３０に問い合わせる。

第３状態ノードＮ０３において、クライアント端末１１は、お知らせなどを含むメニュー画面を表示する。メニュー画面には、プレイヤーが次に取れる行動の選択肢が表示されていることが好ましい。図４に示した例では、プレイヤーが次にとれる行動として、アイテムの購入と、バトルとが選択可能である。なお、メニュー画面には、さらに、プレイヤーの各種パラメータや、プレイヤーが所持する各種アイテムの種類および数量などが表示されても良い。

第３状態ノードＮ０３のメニュー画面において、アイテムの購入を選択した場合は、第６遷移エッジＥ０６を介して第５状態ノードＮ０５に遷移する。このときクライアント端末１１は、現在購入可能なアイテムの一覧データを、ゲームサーバシステム３０に問い合わせる。

第５状態ノードＮ０５において、クライアント端末１１は、アイテム購入画面を表示する。アイテム購入画面には、ゲームサーバシステム３０から取得した、現在購入可能なアイテムの一覧が表示される。

アイテムの購入は、一覧表示された購入可能アイテムをプレイヤーが選択し、かつ、アイテムごとに設定された対価を支払い、プレイヤーのアイテム所持数をクライアント端末１１およびゲームサーバシステム３０の両方のデータ上で調整することで完了する。アイテムの対価は、例えば、オンラインゲームに特有の仮想通貨や、ネット上で流通可能なオンライン通貨などを利用して支払われても良い。

アイテムの購入を行う場合は、第１０遷移エッジＥ１０を介して、第５状態ノードＮ０５に自己ループ遷移を行う。このとき、クライアント端末１１およびゲームサーバシステム３０は、アイテム所持数や、仮想通貨などの増減に係る通信を行い、クライアント端末１１はアイテム購入が完了した旨をプレイヤーに伝える通知をゲームサーバシステム３０から取得する。

アイテムの購入が完了し、またはアイテムの購入を取りやめ、メニュー画面に戻る場合は、第９遷移エッジＥ０９を介して第３状態ノード０３に戻る。このとき、クライアント端末１１およびゲームサーバシステム３０の間で行う通信は特に無い。

第３状態ノードＮ０３のメニュー画面において、バトルを選択した場合は、第５遷移エッジＥ０５を介して第４状態ノードＮ０４に遷移する。このときクライアント端末１１は、現在利用可能なステージの一覧を、ゲームサーバシステム３０に問い合わせる。

第４状態ノードＮ０４において、クライアント端末１１は、ステージ選択画面を表示する。ステージ選択画面には、ゲームサーバシステム３０から取得した、現在利用可能なステージの一覧が表示される。ステージの選択は、一覧表示された利用可能ステージをプレイヤーが選択することで完了する。その後、第８遷移エッジＥ０８を介して第７状態ノードＮ０７に遷移する。このとき、クライアント端末１１およびゲームサーバシステム３０は、バトルを開始するために必要な情報に関する通信を行い、クライアント端末１１でバトルを開始できる状態とする。

第７状態ノードＮ０７において、クライアント端末１１は、バトル画面を表示する。バトル画面では、第４状態ノードＮ０４で選択されたステージ上に、プレイヤーの自キャラクターや、協力してくれる参加メンバの味方キャラクターや、敵キャラクターなどが表示されても良い。

第７状態ノードＮ０７において、バトル中にアイテムを消費する場合は、第１３遷移エッジＥ１３を介して、第７状態ノードＮ０７に自己ループ遷移を行う。このとき、クライアント端末１１およびゲームサーバシステム３０は、指定されたアイテム所持数を減らす通信を行い、クライアント端末１１はアイテムを消費したことで得られる効果を処理する。

バトルが終了すると、第１２遷移エッジＥ１２を介して第６状態ノードＮ０６に遷移する。このとき、クライアント端末１１は、バトルの終了状態をゲームサーバシステム３０に通知し、獲得アイテムの情報を得る。

第６状態ノードＮ０６において、クライアント端末１１は、バトルの結果画面を表示する。その後、通信を伴わない第１１遷移エッジＥ１１を介して、第４状態ノードＮ０４に戻る。

第４状態ノードＮ０４において、ステージの選択を取りやめ、メニュー画面に戻る場合は、第７遷移エッジＥ０７を介して第３状態ノード０３に戻る。このとき、クライアント端末１１およびゲームサーバシステム３０の間で行う通信は特に無い。

以上に説明したように、図４に例示した通信指向型状態遷移図では、オンラインゲームの内部状態の切り替えが、クライアント端末１１に表示される画面の切り替えに対応しており、かつ、クライアント端末およびサーバの間で発生する通信は、画面の切り替えタイミングに合わせて行われる。ここで、クライアント端末１１およびゲームサーバシステム３０の間で行われる通信が、１回の状態遷移ごとに１回に集約されていることに注目されたい。

また、図４に例示した通信指向型状態遷移図は、オンラインゲームの内部状態の切り替えが、クライアント端末１１に表示される画面の切り替えに対応しているため、オンラインゲームの開発者にとって直観的に理解し易い。通信指向型状態遷移図は、オンラインゲームの構成という抽象的な概念を、複数の開発者の間で高精度に共有するためのツールとしても有用であり、その結果、オンラインゲーム開発の生産性向上につながる。

また、クライアント端末１１およびゲームサーバ３１の間で、定義された状態遷移が守られているかを確認しながら動作が可能であるため、正規の通信に割り込まれて行われる不正などに対し、耐性を持つことができる。この際、通信指向型状態遷移図から、画面の切り替えを捨象し、通信に注目した抽象化を行って、通信を伴わない遷移エッジを取り去った状態遷移を使うことが出来る。

次に、図４に例示したような通信指向型状態遷移図を用いてオンラインゲームを開発する方法と、この方法を実現するオンラインゲーム開発システムとについて説明する。

図５は、本発明のオンラインゲーム開発システム２の一構成例を示すブロック図である。

図５に示したオンラインゲーム開発システム２の構成要素について説明する。図５のオンラインゲーム開発システム２は、クライアント端末１１と、ネットワーク２０と、アプリケーションサーバ２１と、ゲームサーバシステム３０と、開発用ゲームサーバ４１と、開発用ユーザインタフェースサーバ４２と、開発用ゲームデータベース４３と、開発用端末４４と、プラグインリポジトリ４５と、テスト用ゲームサーバ４６と、開発用クライアント端末１３とを含んでいる。ゲームサーバシステム３０は、ゲームサーバ３１と、運用管理ユーザインタフェースサーバ３２と、ゲームデータベース３３とを含んでいる。

なお、クライアント端末１１と、ネットワーク２０と、アプリケーションサーバ２１と、ゲームサーバシステム３０は、ゲームサーバ３１と、運用管理ユーザインタフェースサーバ３２と、ゲームデータベース３３とだけを抜き出すと、図５に示したオンラインゲーム開発システム２が図１Ａに示したオンラインゲームシステム１を含んでいることが分かる。

図５に示した構成要素の接続関係について説明する。開発用端末４４は、プラグインリポジトリ４５と、開発用ユーザインタフェースサーバ４２とに接続されている。開発用ユーザインタフェースサーバ４２は、開発用ゲームサーバ４１と、開発用ゲームデータベース４３と、開発用端末４４と、プラグインリポジトリ４５とに接続されている。プラグインリポジトリ４５は、ゲームサーバ３１と、テスト用ゲームサーバ４６と、開発用ゲームサーバ４１と、開発用ユーザインタフェースサーバ４２と、開発用端末４４とに接続されている。開発用ゲームサーバ４１は、開発用クライアント端末１３と、開発用ゲームデータベース４３と、プラグインリポジトリ４５と、開発用ユーザインタフェースサーバ４２とに接続されている。開発用ゲームデータベース４３は、開発用ユーザインタフェースサーバ４２と、開発用ゲームサーバ４１に接続されている。テスト用ゲームサーバ４６は、ネットワーク２０と、ゲームデータベース３３と、プラグインリポジトリ４５とに接続されている。ネットワーク２０は、クライアント端末１１と、アプリケーションサーバ２１と、ゲームサーバ３１と、テスト用ゲームサーバ４６とに接続されている。ゲームサーバ３１は、ゲームデータベース３３と、運用管理ユーザインタフェースサーバ３２と、ネットワーク２０とに接続されている。ゲームデータベース３３は、ゲームサーバ３１と、テスト用ゲームサーバ４６と、運用管理ユーザインタフェースサーバ３２とに接続されている。運用管理ユーザインタフェースサーバ３２は、ゲームデータベース３３と、ゲームサーバ３１とに接続されている。クライアント端末１１は、ネットワーク２０に接続されている。アプリケーションサーバ２１は、ネットワーク２０に接続されている。

図５に示した構成要素の動作について説明する。

開発用端末４４は、オンラインゲーム開発者が直接操作する端末である。開発用端末４４には、通信指向型状態遷移図を生成するためのＵＭＬツールや、各状態ノードおよび各遷移エッジにそれぞれ対応するプラグインを生成するためのプログラミング開発ツールなどがインストールされていることが好ましい。なお、開発用端末４４は、プラグインリポジトリ４５を検索して既存のプラグインや雛形プラグインなどを読み出し、これらを流用し、または改良しても良い。開発用端末４４は、開発者のそれぞれが有していることが好ましく、その総数は複数であっても良いし、それぞれの開発用端末４４で異なるプログラミング言語を使用しても良い。

プラグインリポジトリ４５は、自動生成された雛形プラグインや、過去に開発されたオンラインゲーム用プラグインを格納しており、必要に応じて開発用端末４４に提供する。なお、プラグインリポジトリ４５は、内部に格納されたプラグインのそれぞれについて、再利用の可否や、ソースコードの開示の可否を管理する機能を有していることが好ましい。開発者がソースコード管理システムを特に指定した場合、プラグインリポジトリ４５の他に、指定されたソースコード管理システムに、プラグイン一式をコピーする。この場合、指定されたソースコード管理システムが、プラグインリポジトリ４５に相当するものとして振る舞う。プラグインリポジトリ４５に用意されたプラグイン一式において、雛形プラグインについては、開発用端末４４を使って、意図した働きを行うように、プログラミング作業を行う。プラグインリポジトリ４５に用意されたプラグイン一式に対するプログラミング作業が完了したら、開発用ユーザインタフェースサーバ４２は、プラグイン一式を、開発用ゲームサーバ４１に配備する。

開発用ユーザインタフェースサーバ４２は、設計情報として開発用端末４４で生成された通信指向型状態遷移図に基づき、プラグインリポジトリ４５に登録されたプラグイン一式を開発用ゲームサーバ４１に配備するなどの処理を行う。設計情報として開発用端末４４で生成された通信指向型状態遷移図は、開発用ユーザインタフェースサーバ４２に送信され、雛形プラグインを自動生成した上で、プラグインリポジトリ４５に登録する。この際、通信指向型状態遷移図で、既に開発済みでプラグインリポジトリ４５に登録済みの通信が指定されていた場合、雛形プラグインは生成されず、登録もされない。

開発用ゲームデータベース４３は、本番用のゲームデータベース３３と同様に、オンラインゲーム内の不揮発な情報を格納する。開発用ゲームデータベース４３と、本番用のゲームデータベース３３とは、テーブル構造などが同じ構成ではあるものの、別々の実体として設けられる。

開発用ゲームサーバ４１は、開発中のオンラインゲームに合わせてプラグインを配備したゲームサーバである。開発用クライアント端末１３や、開発用ゲームデータベース４３との組み合わせで、開発中のオンラインゲームをテストプレイする環境が構築される。

テスト用ゲームサーバ４６は、ゲームサーバ３１の補助として動作する。オンラインゲームがリリースされて、一般ユーザなどへのサービスが開始された後に、プラグインの改修や、ゲームデータベース３３の更新などが必要となり、その結果としてゲームサーバ３１の振る舞いが変わる場合がある。このような場合に、回収や変更を行った後のオンラインゲームの検証を、本番環境に準じたテスト用ゲームサーバ４６を用いて行う。この検証を経た後、本番環境用のゲームサーバ３１の更新が実行される。

なお、クライアント端末１１、ネットワーク２０、アプリケーションサーバ２１、ゲームサーバ３１、運用管理ユーザインタフェースサーバ３２およびゲームデータベース３３の動作については、図１Ａを参照して既に説明したとおりであるので、ここでは省略する。

図６は、本発明のオンラインゲーム開発システム２の一構成例を機能別に示す機能ブロック図である。

図６に示した機能ブロック図の構成要素について説明する。図６の機能ブロック図において、本発明のオンラインゲーム開発システム２は、状態遷移図作成機能部５１と、プラグイン作成機能部５２と、開発環境構築機能部５３と、本番環境構築機能部５４とを含んでいる。

状態遷移図作成機能部５１は、状態プログラムモジュール作成機能部５１１と、遷移情報集約機能部５１２とを含んでいる。

プラグイン作成機能部５２は、プラグイン格納機能部５２１と、既存プラグイン検索機能部５２２と、雛形プラグイン提供機能部５２３とを含んでいる。

開発環境構築機能部５３は、開発版プレイ機能部５３１と、テストプレイ機能部５３２を含んでいる。

図６に示した構成要素と、図５に示した構成要素の対応関係について説明する。

状態遷移図作成機能部５１は、開発用端末４４および開発用ユーザインタフェースサーバ４２のうち、状態遷移図の作成および加工に用いられる部分に対応する。

状態プログラムモジュール作成機能部５１１は、開発用端末４４および開発用ユーザインタフェースサーバ４２のうち、状態遷移図の状態遷移情報からゲームの状態遷移を監視するプログラムモジュールの作成に用いられる部分に対応する。

遷移情報集約機能部５１２は、開発用端末４４および開発用ユーザインタフェースサーバ４２のうち、状態遷移図の各遷移エッジに含まれる通信の定義を集約し、プラグイン作成機能部５２のための情報の作成に用いられる部分に対応する。

プラグイン作成機能部５２は、開発用端末４４と、開発用ユーザインタフェースサーバ４２と、プラグインリポジトリ４５のうち、プラグインの作成に用いられる部分に対応する。

プラグイン格納機能部５２１は、プラグインリポジトリ４５に含まれる記憶領域のうち、プラグインの格納に用いられる部分に対応する。

既存プラグイン検索機能部５２２は、プラグインリポジトリ４５のうち、プラグインリポジトリ４５の記憶領域から既存プラグインを検索するために用いられる部分に対応する。

雛形プラグイン提供機能部５２３は、開発用ユーザインタフェースサーバ４２のうち、雛形プラグインの提供に用いられる部分に対応する。

開発環境構築機能部５３は、開発用ユーザインタフェースサーバ４２と、プラグインリポジトリ４５とのうち、開発環境の構築に用いられる部分に対応する。

テストプレイ機能部５３２は、テスト用ゲームサーバ４６、ゲームデータベース３３およびクライアント端末１１のうち、テストプレイに用いられる部分に対応する。

本番環境構築機能部５４は、開発用ユーザインタフェースサーバ４２およびプラグインリポジトリ４５のうち、本番環境の構築に用いられる部分に対応する。

図６に示した各構成要素の動作を、図７Ａおよび図７Ｂを参照して説明する。

図７Ａは、本発明のオンラインゲームの開発方法の一構成例を示すフローチャートの一部である。図７Ｂは、図７Ａに示したフローチャートの残りである。

図７Ａおよび図７Ｂのフローチャートは、第０ステップＳ００〜第１５ステップＳ１５の、合計１６のステップを含んでいる。

第０ステップＳ００は、本発明のオンラインゲーム開発方法の開始点を示す。第０ステップＳ００の次に、第１ステップＳ０１を実行する。

第１ステップＳ０１において、状態遷移図作成機能部５１が、通信指向型状態遷移図を編集する。ここで、状態遷移図作成機能部５１は、通信指向型状態遷移図を、最初から生成しても良いし、既存の通信指向型状態遷移図を流用しても良いし、既存の通信指向型状態遷移図を改良しても良い。

第２ステップＳ０２において、状態プログラムモジュール作成機能部５１１が、通信指向型状態遷移図から、状態遷移情報を取り出す。

第３ステップＳ０３において、状態プログラムモジュール作成機能部５１１が、取り出した状態遷移情報から、状態プログラムモジュールを作成する。作成されたプログラムモジュールは、クライアント側の通信呼び出し履歴をサーバ側でチェックし、状態遷移図の通りにゲームが進行しているか、ゲームの状態遷移を監視する機能を有する。

第４ステップＳ０４において、遷移情報集約機能部５１２が、通信指向型状態遷移図から、各遷移エッジの通信の情報を取り出す。取り出された各通信の情報は、プラグインとして実装されるため、プラグイン作成機能部５２に渡される。

第５ステップＳ０５において、プラグイン作成機能部５２が、遷移情報集約機能部５１２から受け取った各通信について、対応するプラグインが在るか否かを、既存プラグイン検索機能部５２２を用いて判定する。もし、対応するプラグインが既にプラグインリポジトリ４５に格納されていれば（ＹＥＳ）、第５ステップＳ０５の次に第７ステップＳ０７を実行する。反対に、もし、対応するプラグインがプラグインリポジトリ４５を検索しても見つからなければ（ＮＯ）、第５ステップＳ０５の次に第６ステップＳ０６を実行する。

第６ステップＳ０６において、指定された通信のプラグインの雛形を自動生成する。生成された雛形プラグインは、プラグイン格納機能部５２１により、プラグインリポジトリ４５に格納される。第６ステップＳ０６の次に、第８ステップＳ０８を実行する。

第７ステップＳ０７において、見つかったプラグインを、開発に使えるように、プラグインリポジトリ４５内でコピーを行う。コピーすることで、元となったプラグインに影響を与えることなく、プラグインの改造など派生開発を行うことが可能となる。

第８ステップＳ０８において、プラグイン作成機能部５２が、第５ステップＳ０５の段階で、遷移情報集約機能部５１２から受け取っていた各通信について、対応するプラグイン（雛形も含む）が、プラグインリポジトリ４５に揃っているかを確認する。揃っていれば（ＹＥＳ）、第８ステップＳ０８の次に第９ステップＳ０９を実行する。揃っていなければ（ＮＯ）、第８ステップＳ０８の次に第５ステップＳ０５に戻る。

第９ステップＳ０９において、開発用端末４４上で、雛形プラグインに対するプログラミング作業の進捗を確認する。プログラミング作業の終わっていない雛形プラグインが残っていれば（ＹＥＳ）、第９ステップＳ０９の次に第１０ステップＳ１０を実行する。プラグインに対するプログラミング作業が終わっていれば（ＮＯ）、第９ステップＳ０９の次に第１１ステップＳ１１を実行する。

第１０ステップＳ１０において、開発用端末４４上で、雛形プラグインに対するプログラミング作業を行う。第１０ステップＳ１０の次に第９ステップＳ０９を実行する。

第１１ステップＳ１１において、開発環境構築機能部５３に含まれる開発版プレイ機能部５３１が、開発中の最新のプログラムを使って、開発用ゲームサーバ４１と、開発用ゲームデータベース４３と、開発用クライアント端末１３に、開発版プレイ環境を構築する。

第１２ステップＳ１２において、開発版プレイ機能部５３１が、開発用ゲームサーバ４１と、開発用ゲームデータベース４３と、開発用クライアント端末１３とを用いたゲームのプレイに問題が在るか否かを判定する。もし、プレイに問題が在った場合（ＮＯ）は、第１２ステップＳ１２の次に第１ステップＳ１に戻る。プレイに問題が無い場合（ＹＥＳ）は、つまり、オンラインゲームのプログラムが完成した場合は、第１３ステップＳ１３を実行する。

第１３ステップＳ１３において、開発環境構築機能部５３に含まれるテストプレイ機能部５３２が、開発版プレイ環境と同じプログラムを使って、テスト用ゲームサーバ４６と、ゲームデータベース３３と、クライアント端末１１に、テストプレイ環境を構築する。

第１４ステップＳ１４において、テストプレイ機能部５３２が、テスト用ゲームサーバ４６と、ゲームデータベース３３と、クライアント端末１１とを用いたゲームのプレイに問題が在るか否かを判定する。もし、プレイに問題が在った場合（ＮＯ）は、第１４ステップＳ１４の次に第１ステップＳ１に戻る。プレイに問題が無い場合（ＹＥＳ）は、つまり、オンラインゲームのプログラムが、テストプレイ環境でも問題ないと分かった場合は、第１５ステップＳ１５を実行する。

第１５ステップＳ１５において、本番環境構築機能部５４は、本番用のゲームサーバ３１および運用管理ユーザインタフェースサーバ３２のシステムを構築し、オンラインゲームは完成する。

このように、本実施形態によるオンラインゲーム開発システムは、通信指向型状態遷移図に基づく開発方法を用いることによって、オンラインゲームの開発をその設計手法からカバーしている。その一方で、従来の手法は機能指向型であって、通信モデルや各機能のレイヤからしかカバーしておらず、このような観点から本実施形態によるオンラインゲーム開発システムはより高品質なオンラインゲームの開発を可能にする。

また、本実施形態によるオンラインゲーム開発システムでは、複数の通信を１つに集約することによって、通信のモデルがより単純になり、仮に通信障害が発生してもそのリカバリがしやすい。その一方で、従来の手法はオンラインゲームの開発者が高い知見を有しない限りその品質が下がりやすい。このような観点からも、本実施形態によるオンラインゲーム開発システムはより高品質なオンラインゲームの開発を可能にする。

以上、発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。また、前記実施の形態に説明したそれぞれの特徴は、技術的に矛盾しない範囲で自由に組み合わせることが可能である。

１ オンラインゲームシステム
２ オンラインゲーム開発システム
１１ クライアント端末
１２ クライアント端末
１３ 開発用クライアント端末
２０ ネットワーク
２１ アプリケーションサーバ
３０ ゲームサーバシステム
３１ ゲームサーバ
３２ 運用管理ユーザインタフェースサーバ
３３ ゲームデータベース
４１ 開発用ゲームサーバ
４２ 開発用ユーザインタフェースサーバ
４３ 開発用ゲームデータベース
４４ 開発用端末
４５ プラグインリポジトリ
４６ テスト用ゲームサーバ
１００ コンピュータ
１０１ バス
１０２ 通信装置
１０３ 演算装置
１０４ 記憶装置
１０５ 入力装置
１０６ 出力装置
１０７ 外部記憶装置
１０８ 記憶媒体
１１１ ステージマップ管理機能
１１２ 敵配置管理機能
１１３ 参加メンバ管理機能
１１４ 集約通信機能
２０１ ステージマップ情報リクエスト
２０１ａ 通信障害
２０１ｂ タイムオーバー
２０１ｃ ステージマップ情報リクエスト再送
２０２ 敵配置情報リクエスト
２０３ 参加メンバ情報リクエスト
２０３ｂ タイムオーバー
２０３ｃ 参加メンバ情報リクエスト再送
２１１ ステージマップ情報送信
２１２ 敵配置情報送信
２１３ 参加メンバ情報送信
２１３ａ 通信障害
２１３ｂ タイムオーバー
２２１ ステージマップ情報アクノリッジ
２２２ 敵配置情報アクノリッジ
２２３ 参加メンバ情報アクノリッジ
２３１ 集約情報リクエスト
２３１ａ 通信障害
２３１ｂ タイムオーバー
２３１ｃ 集約情報リクエスト再送
２３２ 集約情報送信
２３３ 集約情報アクノリッジ
３１１ ステージマップ管理機能
３１２ 敵配置管理機能
３１３ 参加メンバ管理機能
３１４ 集約通信機能
５１ 状態遷移図作成機能部
５１１ 状態プログラムモジュール作成機能部
５１２ 遷移情報集約機能部
５２ プラグイン作成機能部
５２１ プラグイン格納機能部
５２２ 既存プラグイン検索機能部
５２３ 雛形プラグイン提供機能部
５３ 開発環境構築機能部
５３１ 開発版プレイ機能部
５３２ テストプレイ機能部
５４ 本番環境構築機能部

Claims (10)

1. サーバおよびクライアント端末の間で行う通信を伴うオンラインゲームを開発するシステムであって、
   前記オンラインゲームの構造を表す通信指向型状態遷移図を作成する状態遷移図作成機能部と、
   前記通信指向型状態遷移図に含まれる複数の状態ノードにそれぞれ対応する複数の状態プログラムを作成する状態プログラムモジュール作成機能部と、
   前記通信指向型状態遷移図に含まれる複数の遷移エッジにそれぞれ対応する複数の通信の情報を取り出す遷移情報集約機能部と
   を具備し、
   前記複数の状態ノードは、前記クライアント端末に表示される複数のゲーム画面にそれぞれ対応し、
   前記複数の遷移エッジは、前記複数のゲーム画面の切り替えにそれぞれ対応する
   オンラインゲーム開発システム。
2. 請求項１に記載のオンラインゲーム開発システムにおいて、
   前記遷移情報集約機能部は、
   同一の状態遷移に伴って前記サーバおよび前記クライアント端末の間で行われる複数の通信を、１つの通信に集約する
   オンラインゲーム開発システム。
3. 請求項２に記載のオンラインゲーム開発システムにおいて、
   前記遷移情報集約機能部は、前記複数の通信の一部を、前記クライアント端末または前記サーバのキャッシュ機能で代用して省略する
   オンラインゲーム開発システム。
4. 請求項２または３に記載のオンラインゲーム開発システムにおいて、
   前記遷移情報集約機能部は、集約された前記１つの通信に、１度だけ有効なワンタイムセッションＩＤを用いる
   オンラインゲーム開発システム。
5. 請求項１〜４のいずれか一項に記載のオンラインゲーム開発システムにおいて、
   前記状態遷移図作成機能部は、前記通信指向型状態遷移図を、ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ：統一モデリング言語）形式で作成する
   オンラインゲーム開発システム。
6. サーバおよびクライアント端末の間で行う通信を伴うオンラインゲームを開発する方法であって、
   前記オンラインゲームの構造を表す通信指向型状態遷移図を作成することと、
   前記通信指向型状態遷移図に含まれる複数の状態ノードにそれぞれに対応する複数の状態プログラムを作成することと、
   前記通信指向型状態遷移図に含まれる複数の遷移エッジにそれぞれに対応する複数の通信の情報を取り出すことと
   を具備し、
   前記複数の状態ノードは、前記クライアント端末に表示される複数のゲーム画面にそれぞれ対応し、
   前記複数の遷移エッジは、前記複数のゲーム画面の切り替えにそれぞれ対応する
   オンラインゲーム開発方法。
7. 請求項６に記載のオンラインゲーム開発方法において、
   前記複数の通信の情報を取り出すことは、
   同一の状態遷移に伴って前記サーバおよび前記クライアント端末の間で行われる複数の通信を、１つの通信に集約すること
   を具備する
   オンラインゲーム開発方法。
8. 請求項７に記載のオンライン開発方法において、
   前記集約することは、
   前記複数の通信の一部を、前記クライアント端末または前記サーバのキャッシュ機能で代用して省略すること
   を具備する
   オンラインゲーム開発方法。
9. 請求項７または８に記載のオンラインゲーム開発方法において、
   前記複数の通信の情報を取り出すことは、
   前記１つに集約された通信に、１度だけ有効なワンタイムセッションＩＤを追加すること
   をさらに具備する
   オンラインゲーム開発方法。
10. 請求項６〜９のいずれか一項に記載のオンラインゲーム開発システムにおいて、
    前記通信指向型状態遷移図を作成することは、
    前記通信指向型状態遷移図を、ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ：統一モデリング言語）形式で作成すること
    を具備する
    オンラインゲーム開発方法。
    

Images