JP4920838B2 - How to manage network games - Google Patents
How to manage network games Download PDFInfo
- Publication number
- JP4920838B2 JP4920838B2 JP2001268220A JP2001268220A JP4920838B2 JP 4920838 B2 JP4920838 B2 JP 4920838B2 JP 2001268220 A JP2001268220 A JP 2001268220A JP 2001268220 A JP2001268220 A JP 2001268220A JP 4920838 B2 JP4920838 B2 JP 4920838B2
- Authority
- JP
- Japan
- Prior art keywords
- player
- game
- character
- game server
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Description
【0001】
【産業上の利用分野】
この発明は、通信ネットワークを通してログインをしたプレイヤのゲーム装置にゲームを提供するゲームサーバのゲーム管理方法、あるいは、通信ネットワークを利用したゲームに適用されるゲーム装置,ゲームサーバ,ゲームプログラムまたは記憶媒体に関する。
【0002】
【従来技術】
インターネットを利用した多人数参加型RPG(Role Playing Game)としては、エレクトロニック・アーツ・スクウェア社が提供するウルティマオンラインがよく知られている。このような多人数参加型RPGでは、インターネット上のゲームサーバにゲームマップおよびプレイヤキャラクタデータが用意され、ゲームサーバにログインした各々のクライアントコンピュータのディスプレイには、自分のプレイヤキャラクタが登場した仮想空間が再現される。仮想空間には、別のプレイヤキャラクタも登場し、このプレイヤキャラクタは別のクライアントコンピュータによって操作される。このように、仮想空間内に登場するプレイヤキャラクタはいずれもクライアントコンピュータによって操作されるため、スタンドアローンのRPGでは味わえないリアルな駆け引きを楽しむことができる。
【0003】
【発明が解決しようとする課題】
しかし、従来技術では、ゲームサーバにログインしているプレイヤキャラクタしか仮想空間に登場しない。このため、ゲームサーバにログインしていないプレイヤとゲームを行なうためには、ゲーム内に設けられた掲示板に書き込むような非リアルタイムな方法をとるか、電話をかけるなどの実空間の連絡方法を用いなければならず、ゲームを開始するのに手間がかかっていた。また、従来技術のようなゲームでは、ゲーム内では友人としての役割を演じても実空間では相手との関わりを持ちたくないというプレイヤも多く存在し、このようなプレイヤには電話連絡をとることはできない。
【0004】
また、多人数参加型ゲームでは共通の趣味を持った人に出会えるのが楽しみの一つであるが、従来のシステムではその時点でログインしているプレイヤの中でしか新しい友人を探せない。もちろん、掲示板に「○○○が好きな人、××日の××時に△△に来てね」という伝言を残すなどの方法で共通の趣味を持つ人に出会うことはできるが、この場合、待ち合わせの時刻に必ずアクセスする必要があるため融通が効かないだけでなく、掲示板にメッセージを書き込んでからこのメッセージを相手に読んでもらうまでに十分な時間を取る必要がある。このため、希望する相手とゲームを楽しむまでに時間がかかるという問題があった。
【0005】
それゆえに、この発明の主たる目的は、ゲームサーバにログインしているプレイヤとゲームサーバにログインしていないプレイヤとの間で簡単かつ速やかにゲームを行なうことができる、ゲーム管理方法を提供することである。
【0006】
この発明の他の目的は、ログインをしているプレイヤがログインをしていないプレイヤと簡単かつ速やかにゲームを行なうことができる、ゲームサーバを提供することである。
【0007】
この発明のその他の目的は、ゲームサーバにログインしていないプレイヤと簡単かつ速やかにゲームを行なうことができる、ゲーム装置を提供することである。
【0008】
この発明のさらにその他の目的は、ゲームサーバにログインしているプレイヤとゲームサーバにログインしていないプレイヤとの間で簡単かつ速やかにゲームを行なうことができる、ゲームプログラムを提供することである。
【0009】
この発明の他の目的は、ゲームサーバにログインしているプレイヤとゲームサーバにログインしていないプレイヤとの間で簡単かつ速やかにゲームを行なうことができるゲームプログラムを記憶した、記憶媒体を提供することである。
【0010】
【課題を解決するための手段】
第1の発明は、予め登録された複数のプレイヤのうち通信ネットワークを通してログインをした第1プレイヤの第1ゲーム装置にゲームを提供するゲームサーバのゲーム管理方法において、複数のプレイヤのうちログインをしていない第2プレイヤを示すプレイヤ情報を第1ゲーム装置に送信するステップと、第2プレイヤを選択する第1選択信号を第1ゲーム装置から受信したとき第2プレイヤの第2ゲーム装置にログイン操作要求を送信するするステップを含むことを特徴とする、ゲーム管理方法である。
【0011】
第2の発明は、予め登録された複数のプレイヤのうち通信ネットワークを通してログインをした第1プレイヤの第1ゲーム装置にゲームを提供するゲームサーバにおいて、複数のプレイヤのうちログインをしていない第2プレイヤを示すプレイヤ情報を第1ゲーム装置に送信する送信手段、および第2プレイヤを選択した選択信号を第1ゲーム装置から受信したとき第2プレイヤの第2ゲーム装置にログイン操作要求を送信する送信手段を備えることを特徴とする、ゲームサーバである。
【0012】
第3の発明は、通信ネットワークを通してゲームサーバにログインしたプレイヤによって操作されるゲーム装置において、ゲームサーバにログインしたとき予め登録されたかつゲームサーバにログインしていない特定プレイヤを示すプレイヤ情報をゲームサーバから受信するプレイヤ情報受信手段、プレイヤ情報に基づいて特定プレイヤの選択を案内する案内手段、特定プレイヤが選択されたとき特定プレイヤへのログイン操作要求の送信をゲームサーバに要求する要求手段、およびゲームサーバにログインしていないときゲームサーバからログイン操作要求を受信するログイン操作要求受信手段を備えることを特徴とする、ゲーム装置である。
【0013】
第4の発明は、通信ネットワークを通してゲームサーバにログインするプレイヤによって操作されるゲーム装置に実行させるためのゲームプログラムにおいて、ゲームサーバにログインしたとき予め登録されたかつゲームサーバにログインしていない特定プレイヤを示すプレイヤ情報をゲームサーバから受信するプレイヤ情報受信ステップ、プレイヤ情報に基づいて特定プレイヤの選択を案内する選択案内ステップ、特定プレイヤが選択されたとき特定プレイヤへのログイン操作要求の送信をゲームサーバに要求する要求ステップ、およびゲームサーバにログインしていないときゲームサーバからログイン操作要求を受信するログイン操作要求受信ステップを備えることを特徴とする、ゲームプログラムである。
【0014】
第5の発明は、通信ネットワークを通してゲームサーバにログインするプレイヤによって操作されるゲーム装置に実行させるためのゲームプログラムを記憶した記憶媒体において、ゲームプログラムは、ゲームサーバにログインしたとき予め登録されたかつゲームサーバにログインしていない特定プレイヤを示すプレイヤ情報をゲームサーバから受信するプレイヤ情報受信ステップ、プレイヤ情報に基づいて特定プレイヤの選択を案内する選択案内ステップ、特定プレイヤが選択されたとき特定プレイヤへのログイン操作要求の送信をゲームサーバに要求する要求ステップ、およびゲームサーバにログインしていないときゲームサーバからログイン操作要求を受信するログイン操作要求受信ステップを備えることを特徴とする、記憶媒体である。
第6の発明は、通信ネットワークを通してゲームサーバにログインしたプレイヤによって操作されるゲームシステムにおいて、ゲームサーバにログインしたとき予め登録されたかつゲームサーバにログインしていない特定プレイヤを示すプレイヤ情報をゲームサーバから受信するプレイヤ情報受信手段、プレイヤ情報に基づいて特定プレイヤの選択を案内する案内手段、特定プレイヤが選択されたとき特定プレイヤへのログイン操作要求の送信をゲームサーバに要求する要求手段、およびゲームサーバにログインしていないときゲームサーバからログイン操作要求を受信するログイン操作要求受信手段を備えることを特徴とする、ゲームシステムである。
【0015】
【作用】
第1および第2の発明においては、ゲームサーバには複数のプレイヤが予め登録されており、ゲームサーバは、通信ネットワークを通してログインをした第1プレイヤの第1ゲーム装置にゲームを提供する。このとき、ゲームサーバは、ログインをしていない第2プレイヤを示すプレイヤ情報を第1ゲーム装置に送信し、第2プレイヤを選択する第1選択信号を第1ゲーム装置から受信したとき第2プレイヤの第2ゲーム装置にログイン操作要求を送信する。プレイヤ情報が第1ゲーム装置に送信されることで、ログインをしていない第2プレイヤが第1ゲーム装置によって容易に把握される。ここで、第1プレイヤによって第2プレイヤが選択されると、第1選択信号が第1ゲーム装置からゲームサーバに与えられ、ゲームサーバから第2ゲーム装置にログイン操作要求が送信される。つまり、第1プレイヤから第2プレイヤに対してゲームへの参加が勧誘される。
【0016】
この発明のある局面では、各々のプレイヤは、ログイン操作要求の送信を一律に許可/禁止する第1送信情報をゲームサーバに登録することができる。第2プレイヤの第1送信情報が禁止を示すとき、ゲームサーバは、ログイン操作要求を第2ゲーム装置に送信することなく第1メッセージを第1ゲーム装置に返送する。
【0017】
この発明の他の局面では、各々のプレイヤは、ログイン操作要求の送信をプレイヤ毎に許可/禁止する第2送信情報をゲームサーバに登録することができる。第2プレイヤの第2送信情報が第1プレイヤについて禁止を示すとき、ゲームサーバは、ログイン操作要求を第2ゲーム装置に送信することなく第1メッセージを第1ゲーム装置に返送する。
【0018】
この発明のその他の局面では、ゲームサーバは、ログイン操作要求に対して第2ゲーム装置からログイン操作拒否が返送されたとき、第2メッセージを第1ゲーム装置に返送する。
【0019】
なお、ログイン操作要求には、第1プレイヤを特定できる識別情報を含めてもよい。
【0020】
この発明のさらにその他の局面では、各々のプレイヤは個人情報をゲームサーバに登録することができる。第2プレイヤを選択する第2選択信号を第1ゲーム装置から受信したとき、ゲームサーバは、第2プレイヤの個人情報を第1ゲーム装置に返送する。
【0021】
この発明の他の局面では、ゲームサーバは、第1プレイヤが操作する第1キャラクタを示す第1キャラクタ信号と第2プレイヤが操作する第2キャラクタを示す2キャラクタ信号と第1プレイヤのログイン時に既にログインしている第3プレイヤが操作する第3キャラクタを示す第3キャラクタ信号とをメモリから読み出し、第2キャラクタ信号にプレイヤ情報を付加し、第1キャラクタ信号とプレイヤ情報が付加された第2キャラクタ信号と第3キャラクタ信号とを第1ゲーム装置に送信する。第2キャラクタは、第1キャラクタおよび第3キャラクタと異なる態様で第1ゲーム装置に表示される。
【0022】
第3ないし第5の発明においては、プレイヤがゲーム装置を操作すると、通信ネットワークを通してゲームサーバにログインされる。ゲームサーバにログインすると、予め登録されたかつゲームサーバにログインしていない特定プレイヤを示すプレイヤ情報がゲームサーバから送信され、このプレイヤ情報に基づいて特定プレイヤの選択が案内される。特定プレイヤが選択されると、特定プレイヤへのログイン操作要求の送信要求がゲームサーバに送信される。ゲームサーバにログインしていないゲーム装置は、ゲームサーバからログイン操作要求を受信する。つまり、ログインしているゲーム装置において特定プレイヤが選択されると、ログイン操作要求が特定プレイヤのゲーム装置に与えられる。
【0023】
【発明の効果】
第1および第2の発明によれば、第1プレイヤによって第2プレイヤが選択されると、第1選択信号が第1ゲーム装置からゲームサーバに与えられ、ゲームサーバから第2ゲーム装置にログイン操作要求が送信されるため、第1プレイヤと第2プレイヤとの間で簡単かつ速やかにゲームを行なうことができる。
【0024】
第3ないし第5の発明によれば、ログインしているゲーム装置において特定プレイヤが選択されると、ログイン操作要求が特定プレイヤのゲーム装置に与えられるため、ログインをしているプレイヤがログインをしていないプレイヤと簡単かつ速やかにゲームを行なうことができる。
【0025】
この発明の上述の目的,その他の目的,特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【0026】
【実施例】
図1を参照して、この実施例のネットワークゲームシステム10は、常に通信ネットワーク40に有線接続されるゲームサーバ20と、必要に応じて通信ネットワーク40に無線接続される複数の携帯通信端末30,30,…を含む。ゲームサーバ20に登録済みのプレイヤが自分の携帯通信端末30を操作してゲームサーバ20にログインすると、ゲームサーバ20は、ログインしたプレイヤの携帯通信端末30にゲームを提供する。これによって、ログインしたプレイヤ間でのゲームが可能となる。
【0027】
ゲームサーバ20は、図2に示すようにCPU22およびメモリ24を備え、メモリ24には、図3に示すようにプログラム格納領域24a,地形マトリクス格納領域24b,キャラクタデータ格納領域24cおよびワーク領域24dが形成される。プログラム格納領域24aはゲームプログラムを格納し、地形マトリクス格納領域24bはゲームを行なう仮想空間の地形を示すマトリクスデータを格納する。また、キャラクタデータ格納領域24cは、各々のプレイヤによって操作されるキャラクタ1,2,3…のデータ(キャラクタデータ)を格納する。さらに、ワーク領域24dは、仮想空間に登場するキャラクタを示すマトリクスデータ(キャラクタマトリクス)や、このキャラクタマトリクスの送信先を列挙した送信リストなどを格納する。
【0028】
なお、メモリ24としては、ハードディスクや不揮発性メモリ(たとえばEEPROM)のような着脱不可能に装置内部に設けられる記憶媒体のほか、光磁気ディスクやメモリカードのような着脱自在な記憶媒体を用いてもよい。
【0029】
プログラム格納領域24aに格納されたゲームプログラムは、図23〜図31に示すフロー図に従う処理を実行する。
【0030】
地形マトリクス格納領域24bに格納されたマトリクスデータは、仮想空間全域の地形(地図)を示すデータである。仮想空間は水平方向および垂直方向のいずれにおいてもnブロックに分割され、各々のブロックには座標(X1,Y1)〜(Xn,Yn)が割り当てられる。地形マトリクスは、各ブロックの座標データと各ブロックに再現すべきグラフィックデータの識別番号(グラフィック番号)とによって表される。
【0031】
キャラクタデータ格納領域24cに格納されたキャラクタデータは、キャラクタID,名前,メールアドレス,IPアドレス,個人情報,位置情報,マップサイズ情報,ステータス情報および受付モード情報からなる。キャラクタIDは各々のキャラクタに割り当てられた固有の識別子であり、名前は各々のキャラクタに割り当てられた固有のキャラクタ名であり、メールアドレスおよびIPアドレスは、キャラクタを操作するプレイヤ(携帯通信端末30)に割り当てられた固有のアドレスである。メールアドレスはゲームサーバ20側から携帯通信端末30にログイン操作要求を送信するときに用いられ、IPアドレスはログインが完了した携帯通信端末30にマップデータなどを送信するときに用いられる。
【0032】
個人情報は、キャラクタの性別,キャラクタの年齢,キャラクタの職業,キャラクタのグラフィック番号,キャラクタが持っている能力,キャラクタの持ち物(アイテム)およびキャラクタが各プレイヤに向けて発するメッセージを含む。位置情報は、キャラクタが仮想空間のどのブロック(座標)に存在し、どの方向を向いているかを示す情報であり、マップサイズ情報は、サイズ1およびサイズ2のいずれのサイズの仮想空間をプレイヤの携帯通信端末30に表示すべきかを示す情報であり、ステータス情報は、プレイヤがログイン/ログアウトのいずれの状態にあるかを示す情報である。
【0033】
受付モード情報は、どのプレイヤからの発呼であれば受け付けてもよいかを示す情報である。どのプレイヤの発呼も受け付けるとき(ニュートラル受付)は、スイッチ1に“呼び出しを許可する”が設定され、スイッチ2に“全てのキャラクタを許可”が設定され、そしてキャラクタリストが空欄とされる。特定のキャラクタからの発呼のみを受け付けるとき(友人からの発呼のみ受付)は、スイッチ1に“呼び出しを許可する”が設定され、スイッチ2に“特定のキャラクタのみ許可”が設定され、そしてキャラクタリストに特定のキャラクタ(友人キャラクタ)の名前が登録される。
【0034】
特定のキャラクタ以外からの発呼を受け付けるとき(要注意人物からの発呼を拒否)は、スイッチ1に“呼び出しを許可する”が設定され、スイッチ2に“特定のキャラクタ以外を許可”が設定され、そしてキャラクタリストに特定のキャラクタ(要注意人物キャラクタ)の名前が登録される。いずれのキャラクタからの発呼も拒否するときは、スイッチ1に“呼び出しを禁止する”が設定され、スイッチ2およびキャラクタリストの内容は無効とされる。ゲームサーバ20は、あるプレイヤが別のプレイヤへのログイン操作要求の送信を要求してきたとき、この受付モード情報を参照してログイン操作要求を送信すべきかどうかを判断する。
【0035】
なお、ゲームに参加したいプレイヤはゲームサーバ20への事前登録が必要であり、この登録時に任意のキャラクタデータがプレイヤによって作成される。
【0036】
ワーク領域24dに格納されたキャラクタマトリクスは、仮想空間に登場するキャラクタを示すマトリクスデータである。キャラクタマトリクスは、プレイヤからログイン要求,ログアウト要求,キャラクタの移動要求などが与えられたとき、要求元のプレイヤのキャラクタを中心とする一部の仮想空間について作成される。この一部の仮想空間は水平方向および垂直方向のいずれにおいてもmブロックに分割され、各々のブロックには座標(Xp,Yp)〜(Xp+m,Yp+m)が割り当てられる(m<n)。キャラクタマトリクスもまた、地形マトリクスと同様、座標データとグラフィック番号とによって表される。
【0037】
同じキャラクタであっても、キャラクタの向きが異なれば(前向き,後ろ向き,右向き,左向き)、表示態様は異なる。また、ログアウト中のキャラクタについては、眠った状態で仮想空間に表示される。このようにキャラクタについては複数の表示態様があるため、表示態様を識別するために、拡張子が各々のグラフィック番号に付加される。たとえば、キャラクタが前向きであれば“f”が付加され、キャラクタが後ろ向きであれば“b”が付加され、キャラクタが右向きであれば“r”が付加され、キャラクタが左向きであれば“l”が付加され、そしてキャラクタが眠った状態であれば“s”が付加される。なお、各々のキャラクタの座標および向きは位置情報によって特定され、ログイン/ログアウトはステータス情報によって特定される。
【0038】
ワーク領域24dに格納された送信リストは、地形マトリクスおよびキャラクタマトリクスからなるマップデータを送信すべきプレイヤを列挙したリストである。仮想空間を更新する必要のある携帯通信端末30は、ログイン要求,ログアウト要求,移動要求などを与えたプレイヤのキャラクタと別のキャラクタとの相対位置、ならびに表示する仮想空間のサイズ(マップサイズ)によって異なる。このため、各々のキャラクタの位置情報およびマップサイズ情報に基づいて、仮想空間を更新する必要のあるプレイヤが送信リストに列挙される。
【0039】
地形マトリクス領域24bおよびワーク領域24dからは、列挙された各々のプレイヤのキャラクタを中心とする一部の地形マトリクスおよびキャラクタマトリクスが切り出され、切り出された地形マトリクスおよびキャラクタマトリクスがマップデータとして各々のプレイヤの携帯通信端末30に送信される。
【0040】
携帯通信端末30は、図4に示すように細長い楕円形状に形成された本体32を含む。本体32の上面にはアンテナ34が突出し、本体32の前面には、通話用スピーカ36,ディスプレイ38,ゲームキー40,電話キー42および通話用マイク44が配置される。ゲームキー40としては、自分のキャラクタの振る舞い,メニュー画面の表示,メニュー項目の選択などを制御するためのAボタン40aおよびBボタン40bと、自分のキャラクタまたはメニュー画面上のカーソルを移動させるための十字キー40cとが存在する。また、電話キー42としては、フックキー42a,ホールドキー42b,“0”〜“9”を示す数字キー42c,*キー42d,#キー42e,マナーキー42fおよび音声メモキー42gが存在する。なお、数字キー42c,*キー42dおよび#キー42eには、アルファベットや平仮名などが割り当てられ、これによってメールの作成が可能となる。
【0041】
本体32の内部は、図5に示すように構成される。アンテナ34は通信回路44に接続され、通話用スピーカ36および通話用マイク42は音声変換回路46に接続される。通信回路44および音声変換回路46は互いに接続され、いずれもCPU48によって制御される。CPU48にはまた、ゲームキー40,電話キー42,ディスプレイ36,振動モータ52,呼び出し用スピーカ54およびEEPROMにような不揮発性のメモリ50が接続される。振動モータ52はメールまたは着呼信号の受信時に本体32を振動させ、呼び出し用スピーカ54はメールまたは着呼信号の受信時に呼び出し音を出力する。なお、呼び出し用スピーカ54は本体32の背面に設けられる。
【0042】
メモリ50には、図6に示すようにプログラム格納領域50a,グラフィックデータ格納領域50b,ワーク領域50cおよび表示領域50dが形成される。プログラム格納領域50aは、プレイヤがキャラクタデータを登録したときにゲームサーバ20から受信したゲームプログラムを格納する。グラフィックデータ格納領域50bは、ログインしたときにゲームサーバ20から受信したグラフィックデータを格納する。ワーク領域50cは、ログイン中にゲームサーバ20から受信したマップデータや、プレイヤ自身が設定した受付モード情報および知人キャラクタリストを格納する。受付モード情報および知人キャラクタリストは、ログイン時にプログラム格納領域50aからワーク領域50dに転送され、ログアウト時にワーク領域50dからプログラム格納領域50aに転送される。
【0043】
なお、プログラム格納領域50aは不揮発性メモリに形成する必要があるが、グラフィックデータ格納領域50b,ワーク領域50cおよび表示領域50dは、揮発性のRAMに形成するようにしてもよい。また、グラフィックデータは、ゲームサーバ20への登録時にゲームプログラムとともに受信してもよいが、この場合、グラフィックデータ格納領域50bは不揮発性メモリに形成する必要がある。
【0044】
プログラム格納領域50aに格納されたゲームプログラムは、図32〜図46に示すフロー図に従う処理を実行する。
【0045】
グラフィックデータ格納領域50bに格納されたグラフィックデータは、“木”,“岩”,“芝生”などの仮想空間を形成するオブジェクトの画像データと仮想空間に登場するキャラクタの画像データとを含み、各々の画像データには互いに異なるグラフィック番号が割り当てられる。キャラクタについては、上述のように前向き,後ろ向き,右向き,左向きおよび睡眠中の5つの状態があり、それぞれの状態を示す画像データがグラフィックデータ格納領域50bに用意されている。各々の画像データには、共通のグラフィック番号が割り当てられるが、グラフィック番号に付加される拡張子は互いに異なる。
【0046】
ワーク領域50cに格納されたマップデータは、ディスプレイ38に再現される仮想空間(サイズ1またはサイズ2の仮想空間)の地形マトリクスおよびキャラクタマトリクスからなる。図7に示すように、地形マトリクスは、仮想空間を形成する各ブロックの座標(X1,Y1)〜(Xs,Ys)と各ブロックで再現される地形のグラフィック番号からなり、キャラクタマトリクスもまた、仮想空間を形成する各ブロックの座標(X1,Y1)〜(Xs,Ys)と各ブロックで再現されるキャラクタのグラフィック番号からなる。サイズ1の仮想空間の場合、水平ブロック数および垂直ブロック数はたとえば“9”であり(s=9)、サイズ2の仮想空間の場合、水平ブロック数および垂直ブロック数はたとえば“5”である(s=5)。なお、サイズ1およびサイズ2のいずれについても、s<mである。
【0047】
このようなマップデータとグラフィックデータ格納領域50bのグラフィックデータとに基づいて、図8に示すサイズ1またはサイズ2の仮想空間データ(ゲーム画面データ)が作成される。作成された仮想空間データは表示領域50dに格納され、これに基づく仮想空間(ゲーム画面)がディスプレイ38に表示される。図8によれば、地形は“岩”,“木”,“石畳”などによって表現され、このような地形の上に“ピエロ”,“魔導師”,“山男”などのキャラクタが登場する。ログイン中のキャラクタは立ち上がり、仮想空間を歩き回っている。一方、ログアウト中のキャラクタはログアウト直前に存在していた場所で眠っている。つまり、この実施例では、ゲームサーバ20に登録されているキャラクタは、プレイヤがゲームサーバ20にログインしているかどうかに関係なく、全て仮想空間に再現される。
【0048】
図6に戻って、ワーク領域50cに格納された受付モード情報は、ゲームサーバ20側のキャラクタデータを形成する受付モード情報と異なり、スイッチ1およびスイッチ2しか持たない。ただし、受付モード情報とは別に知人キャラクタリストが格納され、このキャラクタリストに“友人キャラクタ”,“ニュートラルキャラクタ”および“要注意人物キャラクタ”のサブリストが形成される。スイッチ1,スイッチ2,友人キャラクタ,ニュートラルキャラクタおよび要注意人物キャラクタの持つ意味は、ゲームサーバ20側と携帯通信端末30側とで同じである。
【0049】
ログアウト中の携帯通信端末30のディスプレイ38には、図9に示すようなスタートメニュー画面が表示されており、ここで“ゲーム”が選択されると、スタートメニュー画面が図10に示すゲームメニュー画面に更新される。図10によれば、画面上側にタイトル“Online Game”が表示され、画面下側に“ゲームを開始する”および“受付モード変更”のメニュー項目といずれかのメニュー項目を指向するカーソルとが表示される。プレイヤが十字キー40cおよびAボタン40aによって“ゲームを開始する”を選択すると、ログイン要求が携帯通信端末30からゲームサーバ20に送信される。ゲームサーバ20は、ログイン要求を送信したプレイヤのキャラクタデータを図3に示すキャラクタデータ格納領域24cから検出し、検出したキャラクタデータに含まれるステータス情報を“ログアウト”から“ログイン”に更新する。
【0050】
さらに、各々のキャラクタデータに含まれる位置情報,マップサイズ情報およびステータス情報に基づいて、今回のログインによって画面を更新する必要のあるプレイヤを送信リストにリストアップし、リストアップされたプレイヤについて個別にマップデータを作成する。作成されたマップデータは、リストアップされた各プレイヤの携帯通信端末30に個別に送信され、マップデータを受信した携帯通信端末30は、このマップデータに基づくゲーム画面をディスプレイ38に表示する。今回ログインした携帯通信端末30の表示は、図10に示すゲームメニュー画面から図11または図12に示すゲーム画面に更新される。既にログイン中の携帯通信端末30では、ゲーム画面に表示されている睡眠中のキャラクタが立ち上がる。
【0051】
ログインしたプレイヤが十字キー40cを操作すると、移動要求がゲームサーバ20に送信される。ゲームサーバ20は、移動要求が与えられたとき、要求元のプレイヤのキャラクタデータをキャラクタデータ格納領域24bから検出し、検出したキャラクタデータに含まれる位置情報を更新する。さらに、上述と同様に、ゲーム画面を更新する必要のあるプレイヤをリストアップし、リストアップされたプレイヤ毎に異なるマップデータを作成し、そして作成したマップデータを各プレイヤの携帯通信端末30に送信する。これによって、マップデータを受信した携帯通信端末30のディスプレイ38の表示が、このマップデータに基づいて更新される。つまり、十字キー40cを操作したプレイヤのキャラクタが、マップデータを受信した各々の携帯通信端末30のゲーム画面上を移動する。
【0052】
プレイヤが自分のキャラクタを別のキャラクタの前に移動させ、Aボタン40aを操作すると、図13に示すように、“調べる”および“起こす”の2つのメニュー項目を持つ行動メニュー画面が画面右上に多重表示される。ここで、プレイヤが十字キー40cおよびAボタン40aを操作して“調べる”を選択すると、「調べる」情報がゲームサーバ20に送信される。ゲームサーバ20は、「調べる」情報を送信したプレイヤのキャラクタデータを図3に示すキャラクタデータ格納領域24cから検出し、検出したキャラクタデータに含まれる位置情報(座標および向き)と別のキャラクタデータに含まれる位置情報(座標)とに基づいて、調べたい相手(前方に存在するキャラクタ)のキャラクタデータを特定する。そして、特定したキャラクタデータに含まれるキャラクタ名および個人情報を「調べる」情報の送信元に返送する。キャラクタ名および個人情報を受信した携帯通信端末30は、まずキャラクタ名を図6に示す“ニュートラルキャラクタ”のサブリストに登録し、続いて図14に示すような個人情報画面をディスプレイ38に表示する。
【0053】
図14によれば、画面の左上にキャラクタ画像が表示され、キャラクタ画像の右側にキャラクタの名前,職業,性別および年齢が表示され、そして画面の下側にメッセージが表示される。キャラクタ画像は、個人情報に含まれるグラフィック番号と図6に示すグラフィックデータ格納領域50bに格納されたグラフィックデータとに基づいて生成される。また、受信した個人情報のうち、能力および持ち物は表示されない。
【0054】
図13に示す行動メニュー画面において“起こす”が選択されると、「起こす」情報が携帯通信端末30からゲームサーバ20に送信される。ゲームサーバ20は、「起こす」情報を送信したプレイヤのキャラクタデータを図3に示すキャラクタデータ格納領域24cから検出し、検出したキャラクタデータに含まれる位置情報と別のキャラクタデータに含まれる位置情報とに基づいて、起こしたい相手(前方に存在するキャラクタ)のキャラクタデータを特定する。そして、特定したキャラクタデータに含まれる受付モード情報を判別する。
【0055】
ここで、スイッチ1の内容が“呼び出しを禁止する”であれば、「起こす」情報の送信元に情報Aを返送する。情報Aを受信した携帯通信端末30のディスプレイ38には、図15に示す要領で“熟睡していて起きる気配もない...”とのメッセージが表示される。スイッチ1の内容が“呼び出しを許可する”であっても、スイッチ2の内容が“特定のキャラクタのみ許可”であり、かつキャラクタリストに「起こす」情報の送信元のキャラクタ名が登録されていない場合、あるいはスイッチ2の内容が“特定のキャラクタ以外を許可”であり、かつキャラクタリストに「起こす」情報の送信元のキャラクタ名が登録されている場合は、上述と同様に情報Aが返送され、図15に示すメッセージが送信元の携帯通信端末30に表示される。
【0056】
これに対して、スイッチ1およびスイッチ2の内容が“呼び出しを許可する”および“全てのキャラクタを許可する”である場合、スイッチ1およびスイッチ2の内容が“呼び出しを許可する”および“特定のキャラクタのみ許可する”で、キャラクタリストに要求元のキャラクタ名が登録されている場合、あるいはスイッチ1およびスイッチ2の内容が“呼び出しを許可する”および“特定のキャラクタ以外を許可する”で、キャラクタリストに要求元のキャラクタ名が登録されていない場合は、ゲーム専用メール(ログイン操作要求)がゲームサーバ20から起こしたい相手の携帯通信端末30に送信される。つまり、キャラクタデータ格納領域24cから起こしたい相手のメールアドレスを検出し、要求元のキャラクタ名を含むゲーム専用メールを検出したアドレス宛てに送信する。
【0057】
ゲーム専用メールを受信した携帯通信端末30のディスプレイ38には、図17に示すような呼び出し画面が表示される。図17によれば、画面の中央に要求元のキャラクタ名を含む呼び出しメッセージが表示され、呼び出しメッセージの下に“ゲームを開始する”,“今は遊ばない”および“呼び出し禁止モードに変更”の3つのメニュー項目が表示される。
【0058】
ここで、ゲーム専用メールを受信したプレイヤが十字キー40cおよびAボタン40aによって“ゲームを開始する”を選択すると、対応するコマンド情報がゲームサーバ20に返送される。ゲームサーバ20は、ログイン要求を受信したときと同様の処理を行ない、これによって「起こす」情報を送信した携帯通信端末30およびゲーム専用メールを受信した携帯通信端末30を含む複数の携帯通信端末30の表示が更新される。
【0059】
ゲーム専用メールを受信したプレイヤが図17に示す“今は遊ばない”を選択すると、対応するコマンド情報がゲームサーバ20に返送される。ゲームサーバ20はこのとき情報Bを「起こす」情報の送信元に返送する。情報Bを受信した携帯通信端末30のディスプレイ38には、図16に示す要領で“むにゃむにゃ...起きそうでおきない”とのメッセージが表示される。
【0060】
ゲーム専用メールを受信したプレイヤが図17に示す“呼び出し禁止モードに変更”を選択すると、図6に示す受付モード情報のスイッチ1の内容が“呼び出しを禁止する”に更新されるとともに、選択されたメニュー項目に対応するコマンド情報がゲームサーバ20に返送される。ゲームサーバ20はこのとき、コマンド情報を送信したプレイヤのキャラクタデータを図3に示すキャラクタデータ格納領域24cから検出し、検出したキャラクタデータに含まれる受付モード情報のスイッチ1の内容を“呼び出しを禁止する”に変更する。さらに、情報Aを「起こす」情報の送信元に送信する。「起こす」情報の送信元には、図15に示すメッセージが表示される。
【0061】
図12に示すようにいずれのメニュー画面も表示されていない状態でプレイヤがBボタン40bを操作すると、図18に示すシステムメニュー画面がディスプレイ38に多重表示される。図18によれば、“画面サイズ変更”,“その他設定”および“ゲーム終了”の3つのメニュー項目がディスプレイ38に表示される。
【0062】
ここで、プレイヤが十字キー40cおよびAボタン40aによって“画面サイズ変更”を選択すると、サイズ変更要求がゲームサーバ20に送信される。ゲームサーバ20はこのとき、図3に示すキャラクタデータ格納領域24cから要求元のキャラクタデータを検出し、検出したキャラクタデータに含まれるマップサイズ情報を更新する。つまり、サイズ変更要求を受信する前のマップサイズ情報が“サイズ1”であれば“サイズ2”に更新し、サイズ変更要求を受信する前のマップサイズ情報が“サイズ2”であれば“サイズ1”に更新する。さらに、更新後のマップサイズ情報に基づいてマップデータを作成し、作成したマップデータを要求元の携帯通信端末30に返送する。携帯通信端末30は、受信したマップデータに基づいてゲーム画面データを作成し、これによって図11に示すゲーム画面がディスプレイ38に表示される。
【0063】
図18に示すシステムメニュー画面が表示されているときに、カーソルが“ゲーム終了”に合わせられ、Aボタン40aが押されると、ログアウト要求がゲームサーバ20に送信される。ゲームサーバ20は、要求元のプレイヤのキャラクタデータをキャラクタデータ格納領域24bから検出し、検出したキャラクタデータに含まれるステータス情報を更新する。さらに、上述と同様に、ゲーム画面を更新する必要のあるプレイヤをリストアップし、リストアップされたプレイヤ毎に異なるマップデータを作成し、そして作成したマップデータを各プレイヤの携帯通信端末30に送信する。マップデータを受信した携帯通信端末30の表示はこのマップデータに基づいて更新され、ゲーム画面上ではログアウトしたプレイヤのキャラクタが睡眠状態に変化する。一方、ログアウト要求を送信した携帯通信端末30の表示は、図18に示すゲーム画面から図9に示すスタートメニュー画面に更新される。
【0064】
図10に示すゲームメニュー画面においてプレイヤが“受付モード変更”を選択すると、図19に示す受付モード設定画面がディスプレイ38に表示される。図19によれば、“スイッチ1”,“スイッチ2”,“キャラクタリスト編集”および“設定終了”がメイン項目として表示され、“スイッチ1”の下位に“呼び出しを許可する”および“呼び出しを禁止する”のサブ項目が、“スイッチ2”の下位に“全てのキャラクタを許可”,“特定のキャラクタのみ許可”および“特定のキャラクタ以外を許可”のサブ項目が、それぞれ表示される。
【0065】
最初は“スイッチ1”,“スイッチ2”,“キャラクタリスト編集”または“設定終了”を指向するカーソルが有効化され、十字キー40cが操作されると、この有効カーソルが移動する。カーソルが所望のメイン項目を指向しているときにAボタン40aが押されると、所望のメイン項目の下位に位置するサブ項目のカーソルが有効化される。有効化されたカーソルを所望のサブ項目に合わせると、所望のサブ項目の内容が図6に示す受付モード情報に設定される。たとえば、有効カーソルが“呼び出しを許可する”に合わせられると、図6に示す受付モード情報のスイッチ1に“呼び出しを許可する”が設定される。また、有効カーソルが“特定のキャラクタのみを許可する”に合わせられると、図6に示す受付モード情報のスイッチ2に“特定のキャラクタのみ許可する”が設定される。
【0066】
有効カーソルが“キャラクタリスト編集”を指向しているときにAボタン40aが押されると、受付モード設定画面に代えて、図20に示すキャラクタリスト編集画面がディスプレイ38に表示される。図20によれば、メインリストとして“友人”,“ニュートラル”,“要注意人物”および“編集終了”が表示され、“友人”,“ニュートラル”および“要注意人物”の下位に友人キャラクタのサブリスト,ニュートラルキャラクタのサブリストおよび要注意人物キャラクタのサブリストがそれぞれ表示される。各々のサブリストは、図6に示すサブリストと一致する。
【0067】
ここでも、最初はメインリスト上のカーソルが有効化され、この有効カーソルが所望のメニュー項目を指向している状態でAボタン40aが押されると、所望のメニュー項目の下位にあるサブリスト上のカーソルが有効化される。サブリスト上の有効カーソルが所望のキャラクタ名を指向している状態でAボタン40aが押されると、図21に示す要領で移動先リストが表示される。移動先リストのメニュー項目は、有効カーソルが現時点で指向していない2つのサブリストである。たとえば、有効カーソルがニュートラルキャラクタ名を指向していれば、“友人”および“要注意人物”が移動先リストに表示される。
【0068】
移動先リスト上のカーソルが所望の項目に合わせられ、Aボタン40aが押されると、サブリストにおいてカーソルが指向するキャラクタ名がサブリストから削除され、削除されたキャラクタ名が、移動先リストにおいてカーソルが指向する項目のサブリストに追加される。このとき、図6に示す知人キャラクタリストも、同時に変更される。たとえば、ニュートラルキャラクタ名のサブリストにおいて“リチャード”が選択されているときに、移動先リストにおいて“友人”が選択されると、ニュートラルキャラクタのサブリストから“リチャード”が削除され、友人キャラクタのサブリストに“リチャード”が追加される。
【0069】
こうしてキャラクタリストが編集された後に、カーソルが“編集終了”に合わせられ、Aボタン40aが押されると、キャラクタリスト編集画面が図19に示す受付モード設定画面に更新される。受付モード設定画面においてカーソルが“設定終了”に合わせられ、Aボタン40aが押されると、スイッチ1,スイッチ2およびキャラクタリストからなる受付モード情報(送信データ)が作成され、この送信データがゲームサーバ20に送信される。このとき、送信データのスイッチ1およびスイッチ2は図6に示す受付モード情報のスイッチ1およびスイッチ2と一致し、キャラクタリストの設定はスイッチ2の内容に従う。スイッチ2が“全てのキャラクタを許可する”であればキャラクタリストは空欄とされ、スイッチ2が“特定のキャラクタのみ許可”であれば友人キャラクタ名がキャラクタリストに設定され、そしてスイッチ2が“特定のキャラクタ以外を許可”であれば要注意人物キャラクタ名がキャラクタリストに設定される。
【0070】
作成された受付モード情報は、ゲームサーバ20に送信される。ゲームサーバ20は、受付モード情報を送信したプレイヤのキャラクタデータを図3に示すキャラクタデータ格納領域24cから検出し、検出したキャラクタデータに含まれる受付モード情報を受信した受付モード情報によって更新する。携帯通信端末30側では、受付モード情報が送信された後、ディスプレイ38の表示が図19に示す受付モード設定画面から図10に示すゲームメニュー画面に更新される。
【0071】
ゲームサーバ20に設けられたCPU22の処理を、図23〜図31を参照して説明する。
【0072】
まず図23を参照して、CPU22は、ステップS1,S5,S9,S13,S17,S21およびS25の各々で、携帯通信端末30からどのような要求または情報が与えられたかを判別する。ログイン要求が与えられたときは、ステップS1でYESと判断し、ステップS3でログイン処理を行なう。ログアウト要求が与えられたときは、ステップS5でYESと判断し、ステップS7でログアウト処理を行なう。移動要求が与えられたときは、ステップS9でYESと判断し、ステップS11で移動処理を行なう。サイズ変更要求が与えられたときは、ステップS13でYESと判断し、ステップS15でサイズ変更処理を行なう。「起こす」情報が与えられたときは、ステップS17でYESと判断し、ステップS19で起こす処理を行なう。ステップS3,S7,S11,S15またはS19の処理を終えると、ステップS1に戻る。
【0073】
受付モード情報が与えられたときは、ステップS21からステップS23に進む。このステップでは、受付モード情報に付加されたキャラクタIDに基づいて送信元のプレイヤのキャラクタデータをキャラクタデータ格納領域24cから検出し、検出したキャラクタデータに含まれる受付モード情報を携帯通信端末30から送信された受付モード情報に従って更新する。上述のように、送信された受付モード情報にはスイッチ1,スイッチ2およびキャラクタリストが含まれ、キャラクタデータ格納領域24cから検出された受付モード情報のスイッチ1,スイッチ2およびキャラクタリストは、送信された受付モード情報のスイッチ1,スイッチ2およびキャラクタリストによって更新される。
【0074】
「調べる」情報が与えられたときは、ステップS25からステップS27に進む。このステップでは、「調べる」情報に含まれるキャラクタIDに基づいて送信元のプレイヤのキャラクタデータをキャラクタデータ格納領域24cから検出し、検出したキャラクタデータに含まれる位置情報と別のキャラクタデータに含まれる位置情報とに基づいて、調べたい相手(送信元のキャラクタの前方に存在するキャラクタ)のキャラクタデータを特定する。さらに、特定したキャラクタデータからキャラクタ名および個人情報を検出し、検出したキャラクタ名および個人情報を「調べる」情報の送信元に返送する。
【0075】
ステップS3におけるログイン処理は、図24に示すサブルーチンに従う。まずステップS31で、ログイン要求に含まれるキャラクタIDに基づいて要求元のプレイヤのキャラクタデータを図3に示すキャラクタデータ格納領域24bから検出し、検出したキャラクタデータに含まれるステータス情報を“ログアウト”から“ログイン”に更新する。ステータス情報の更新が完了すると、ステップS33でログイン許可を要求元の携帯通信端末30に送信し、ステップS35でマップデータを更新すべきプレイヤをリストアップする。続くステップS37では、リストアップされたプレイヤの携帯通信端末30にマップデータを送信する。具体的には、リストアップされたプレイヤのキャラクタデータに含まれる位置情報およびマップサイズ情報に基づいてマップデータ(地形マトリクスおよびキャラクタマトリクス)を作成し、作成したマップデータを携帯通信端末30に送信する。このような処理をリストアップされた各々のキャラクタIDについて行ない、処理が完了すると上階層のルーチンに復帰する。
【0076】
図23に示すステップS7のログアウト処理は、図25に示すサブルーチンに従う。まずステップS41で、ログアウト要求に含まれるキャラクタIDに基づいて要求元のプレイヤのキャラクタデータをキャラクタデータ格納領域24bから検出し、検出したキャラクタデータに含まれるステータス情報を“ログイン”から“ログアウト”に更新する。続いて、ステップS43でログアウト通知(終了通知)を要求元の携帯通信端末30に送信し、ステップS45でマップデータを更新すべきプレイヤをリストアップする。ステップS47では、リストアップされたプレイヤの携帯通信端末30にマップデータを送信し、送信が完了すると上階層のルーチンに復帰する。
【0077】
図23に示すステップS11の移動処理は図26に示すサブルーチンに従う。まずステップS51で、移動要求に含まれるキャラクタIDに基づいて要求元のプレイヤのキャラクタデータをキャラクタデータ格納領域24dから検出し、検出したキャラクタデータに含まれる位置情報(座標または向き)を移動要求に従って更新する。ステップS53ではマップデータを更新する必要のあるプレイヤをリストアップし、ステップS55ではリストアップされたプレイヤの携帯通信端末30にマップデータを送信する。送信が完了すると上階層のルーチンに復帰する。
【0078】
図23に示すステップS15のサイズ変更処理は、図27に示すサブルーチンに従う。まずステップS61で、サイズ変更要求に含まれるキャラクタIDに基づいて要求元のプレイヤのキャラクタデータをキャラクタデータ格納領域24cから検出し、検出したキャラクタデータに含まれるマップ情報を特定し、そして特定したマップ情報を更新する。現時点のマップ情報が“サイズ1”であれば“サイズ2”に更新し、現時点のマップ情報が“サイズ2”であれば“サイズ1”に更新する。ステップS63では上述と同様のリストアップ処理を行ない、ステップS65ではサイズ変更要求の送信元にのみマップデータを送信する。送信が完了すると、上階層のルーチンに復帰する。
【0079】
ステップS35,S45,S53またはS63におけるリストアップ処理は、図28および図29に示すサブルーチンに従う。まず、ステップS71でワーク領域24dに形成されたキャラクタマトリクスおよび送信リストの内容をクリアする。ステップS73では、ログイン要求,ログアウト要求,移動要求またはサイズ変更要求を送信したプレイヤのキャラクタデータ(キャラクタn)をキャラクタデータ格納領域24cから特定し、特定したキャラクタデータから位置情報およびマップサイズ情報を検出する。続くステップS75では、図3に示すワーク領域24dに形成するキャラクタマトリクスの中心座標をステップS73で検出された位置情報に基づいて決定する。キャラクタマトリクスの中心座標は検出された位置情報に含まれる座標と一致し、キャラクタマトリクスのサイズは、常に大きい方のマップサイズ(サイズ1)の2倍である。このため、キャラクタマトリクスの中心座標およびサイズは、図22に示すように決定される。
【0080】
キャラクタマトリクスの中心座標およびサイズが決定されると、ステップS77はキャラクタ番号iを“1”にセットし、ステップS79でキャラクタiのキャラクタデータ(キャラクタデータ格納領域24cから特定)から位置情報を検出する。ステップS81では、キャラクタiがキャラクタマトリクスの範囲に含まれるかどうかをステップS79で検出された位置情報に基づいて判断し、NOであればそのままステップS87に進む。一方、ステップS79でYESであれば、ステップS83でキャラクタiのキャラクタデータからステータス情報およびグラフィック番号を検出し、ステップS85でグラフィック番号をキャラクタマトリクスにマッピングしてからステップS87に進む。ステップS85では、具体的には、位置情報(キャラクタiの向き)およびステータス情報に基づいて決定した拡張子をグラフィック番号に付加し、拡張子が付加されたグラフィック番号をステップS79で検出された位置情報(キャラクタiの座標)に従ってキャラクタマトリクスにマッピングする。
【0081】
ステップS87ではキャラクタ番号iをインクリメントし、続くステップS89ではインクリメントされたキャラクタ番号iを最大キャラクタ番号imaxと比較する。ここで、i≦imaxであれば、ステップS79〜S87の処理を繰り返す。これによって、キャラクタnの周囲に存在する複数のキャラクタのグラフィック番号がキャラクタマトリクスにマッピングされる。図22によれば、キャラクタi,i’,i”およびnのうち、キャラクタi,i”およびnのグラフィック番号がキャラクタマトリクスにマッピングされる。
【0082】
i>imaxとなると、ステップS89からステップS91に進み、キャラクタ番号iを再度“1”に設定する。続くステップS93ではキャラクタiがキャラクタnに一致するかどうか判断する。ここでYESであれば、ステップS103でキャラクタi(=n)のキャラクタIDを送信リストに追加し、ステップS105に進む。つまり、キャラクタnのキャラクタIDは、無条件に送信リストに追加される。
【0083】
一方、ステップS93でNOであれば、ステップS95でキャラクタiのキャラクタデータ(キャラクタデータ格納領域24cに格納)からステータス情報を検出し、ステップS97でキャラクタiがログイン状態およびログアウト状態のいずれであるかを判別する。ログアウト状態であれば、送信リスト追加処理を行なうことなくステップS105に進む。これに対して、ログイン状態であれば、ステップS99でキャラクタiのキャラクタデータからマップサイズ情報を検出し、ステップS101でキャラクタiの視界にキャラクタnが存在するかどうかを判断する。具体的には、検出したキャラクタiのマップサイズ情報と位置情報とに基づいて、キャラクタiのマップサイズの範囲内にキャラクタnの座標が含まれるかどうかを判断する。そして、YESであればステップS103における送信リスト追加処理を経てステップS105に進むが、NOであればそのままステップS105に進む。
【0084】
ステップS105ではキャラクタ番号iをインクリメントし、続くステップS107ではインクリメントされたキャラクタ番号iを最大キャラクタ番号imaxと比較する。i≦imaxであれば、ステップS93〜S107の処理を繰り返す。これによって、キャラクタnのキャラクタIDとキャラクタnが視界に存在するキャラクタのキャラクタIDとが、送信リストに追加される。図22によれば、キャラクタnが視界に存在するのは、キャラクタiのみである。このため、キャラクタnおよびiのキャラクタIDが送信リストに追加される。i>imaxと判断されると、上階層のルーチンに復帰する。
【0085】
上述のステップS37,S47およびS55では、こうして送信リストに登録された各々のプレイヤについて、地形マトリクスおよびキャラクタマトリクスの切り出しによってマップデータを作成する。一方、ステップS65では、サイズ変更要求を送信したプレイヤについてのみ、地形マトリクスおよびキャラクタマトリクスの切り出しによってマップデータを作成する。いずれの場合も、マップデータのサイズは送信先のプレイヤのマップサイズ情報に従い、マップデータの中心座標には送信先のプレイヤのグラフィック番号が割り当てられる。
【0086】
図23に示すステップS19では、図30および図31に示すサブルーチンを処理する。ステップS111では、「起こす」情報に含まれるキャラクタIDに基づいて送信元のプレイヤのキャラクタデータをキャラクタデータ格納領域24cから特定し、特定したキャラクタデータに含まれる位置情報(座標および向き)に基づいて起こしたい相手のキャラクタデータを特定し、そして特定した相手のキャラクタデータから受付モード情報を検出する。ステップS113では検出した受付モード情報のスイッチ1の内容が“呼び出しを許可する”であるかどうか判断し、NOであればステップS125で許可/禁止フラグを“禁止”にセットする。一方、ステップS113でYESであれば、ステップS115およびS117でスイッチ2の内容を判別する。
【0087】
スイッチ2の内容が“全てのキャラクタを許可する”であれば、ステップS115でYESと判断し、ステップS123で許可/禁止フラグを“許可”にセットする。スイッチ2の内容が“特定のキャラクタのみ許可”であれば、ステップS117からステップS121に進み、ステップS111で検出した受付モード情報のキャラクタリストに呼び出し元のキャラクタが登録されているかどうか判断する。ここでYESであれば、ステップS123で許可/禁止フラグを“許可”にセットするが、NOであれば、ステップS125で許可/禁止フラグを“禁止”にセットする。スイッチ2の内容が“特定のキャラクタ以外を許可”であれば、ステップS117からステップS119に進み、ステップS111で検出した受付モード情報のキャラクタリストに呼び出し元のキャラクタが登録されているかどうか判断する。ここでNOであれば、ステップS123で許可/禁止フラグを“許可”にセットするが、YESであれば、ステップS125で許可/禁止フラグを“禁止”にセットする。
【0088】
こうして許可/禁止フラグの設定が完了すると、ステップS127で許可/禁止フラグの設定状態を判別する。そして、設定状態が“禁止”であれば、ステップS137で情報Aを送信してから上階層のルーチンに復帰する。情報Aが送信されることで、呼び出し元の携帯通信端末30のディスプレイ38には、“熟睡して起きる気配もない…”とのメッセージが表示される。
【0089】
一方、設定状態が“許可”であれば、ステップS129でゲーム専用メールを作成し、作成したゲーム専用メールをステップS131で相手の携帯通信端末30に送信する。ゲーム専用メールは、相手にログイン操作を要求するためのメールであり、中には呼び出し元のキャラクタ名が含まれる。このゲーム専用メール(ログイン操作要求)に対して、相手が“呼び出し禁止モードに変更する”を選択すると、ステップS133からステップS135に進む。このステップでは、相手のキャラクタデータをキャラクタデータ格納領域24cから検出し、検出したキャラクタデータに含まれる受付モード情報のスイッチ1を“呼び出しを禁止する”に更新する。更新処理が完了すると、ステップS137で情報Aを送信してから上階層のルーチンに復帰する。
【0090】
ゲーム専用メールに対して、相手が“今は遊ばない”を選択すると、ステップS139からステップS141に進み、情報Bを呼び出し元の携帯通信端末30に送信する。情報Bが送信されることで、呼び出し元の携帯通信端末30のディスプレイ38には、“むにゃむにゃ…起きそうで起きない”とのメッセージが表示される。情報Bの送信が完了すると、上階層のルーチンに復帰する。
【0091】
ゲーム専用メールに対して、相手が“ゲームを開始する”を選択するか、または相手が何も選択しないうちにタイムアウトとなると、ステップS143またはS145でYESと判断し、そのまま上階層のルーチンに復帰する。ただし、“ゲームを開始する”が選択されたときは、携帯通信端末30からログイン要求が送信され、図23に示すステップS3のログイン処理によってゲームが開始される。
【0092】
次に、携帯通信端末30に設けられたCPU48の処理を図32〜図46に示すフロー図に従って説明する。
【0093】
CPU48はまず、ステップS151,S153およびS155の各々で外部からの信号受信の有無やプレイヤによるキー操作を判別する。外部から信号を受信したときはステップS151からステップS157に進み、受信した信号がメール信号であるか通話のための着呼信号であるかを判別する。受信信号が着呼信号であればステップS159に進み、通話処理を行なう。ステップS161では通話処理が完了したかどうかを判別し、NOであればステップS159に戻り通話処理を繰り返すが、YESであればステップS151に戻る。
【0094】
受信信号がメール信号であれば、このメール信号が通常メールであるかゲーム専用メールであるかをステップS165で判別し、通常メールであればステップS167による通常メール処理を経てステップS151に戻る。一方、受信したメール信号がゲーム専用メールであれば、ステップS169でゲームメール処理を行なうとともに、ステップS171でゲーム開始フラグの状態を判別する。ここで、ゲーム開始フラグがリセット状態であればそのままステップS151に戻るが、ゲーム開始フラグがセット状態であれば、ステップS173,S175およびS177でログイン処理,ゲーム処理およびログアウト処理を行なってからステップS151に戻る。
【0095】
図10に示すメニュー画面において、プレイヤが十字キ040cによってカーソルを“受付モード変更”に合わせ、Aボタン40aを押すと、ステップS153からステップS163に進み、受け付けモード変更処理を行なう。処理が完了すると、ステップS151に戻る。一方、図10に示すメニュー画面においてプレイヤが十字キー40cおよびAボタン40aによって“ゲームを開始する”を選択すると、ステップS155でYESと判断し、ステップS173に進む。
【0096】
ステップS169におけるゲームメール処理は、図33に示すサブルーチンに従う。まず、ステップS181で呼び出し用スピーカ54を通して呼び出し音を発生するとともに、ステップS183で振動モータ52によって振動を発生させる。ステップS185では受信したゲーム専用メールから呼び出し元のキャラクタ名を検出し、ステップS187では検出したキャラクタ名を図6に示すワーク領域50cに形成された“ニュートラルキャラクタ”のサブリストに追加する。なお、検出されたキャラクタ名が知人キャラクタリストに既に登録されているときは、ステップS187の処理は行なわれない。
【0097】
ステップS187の処理が完了すると、ステップS189で図11に示す呼び出し画面をディスプレイ38に表示するとともに、“ゲームを開始する”,“今は遊ばない”および“呼び出し禁止モードに変更”のいずれのメニュー項目がプレイヤによって選択されたかをステップS191,S197およびS205で判別する。
【0098】
十字キー40cによってカーソルが“ゲームを開始する”に合わせられ、Aボタン40aが押されると、ステップS191からステップS193に進み、選択されたメニュー項目に対応するコマンド情報をゲームサーバ20に送信する。その後、ステップS195でゲーム開始フラグをセットしてから上階層のルーチンに復帰する。十字キー40cおよびAボタン40aによって“呼び出し禁止モードに設定する”が選択されたときは、ステップS197でYESと判断し、ステップS199でこのメニュー項目に対応するコマンド情報をゲームサーバ20に送信するとともに、ステップS201でワーク領域50cに格納された受付モード情報のスイッチ1に“呼び出しを禁止する”をセットする。その後、ステップS203でゲーム開始フラグをリセットしてから上階層のルーチンに復帰する。
【0099】
十字キー40cおよびAボタン40aによって“今は遊ばない”が選択されたときは、ステップS205でYESと判断し、ステップS207でこのメニュー項目に対応するコマンド情報をゲームサーバ20に送信してからステップS203に進む。プレイヤがいずれのメニュー項目も選択しないうちにタイムアウトが生じたときは、ステップS209でYESと判断し、そのままステップS203に進む。
【0100】
なお、ゲームサーバ20側では、ステップS193,S199またはS207で送信されたコマンド情報に基づいて、図31に示すステップS133,S139およびS143の判別処理が行なわれる。
【0101】
ステップS173におけるログイン処理は、図34に示すサブルーチンに従う。まずステップS211で初期化を行ない、ステップS213でログイン要求をゲームサーバ20に送信する。ログイン要求に対して、ゲームサーバ20は、ログイン許可およびマップデータを返送する(ステップS33,S37)。このため、携帯通信端末30側ではステップS215およびS217の各々でログイン許可およびマップデータの受信の有無を判別し、マップデータを受信するとステップS219に進む。ステップS219では、受信したマップデータに基づいて図11または図12に示すような仮想空間(ゲーム画面)をディスプレイ38に表示する。表示処理が完了すると、上階層のルーチンに復帰する。
【0102】
ステップS175におけるゲーム処理は、図35および図36に示すサブルーチンに従う。まずステップS221でマップ更新処理を行ない、続いてステップS223,S227およびS229の各々で十字キー40c,Aボタン40aおよびBボタン40bの操作の有無を判別する。十字キー40cが操作されたときはステップS225で移動処理を行ない、処理を終えるとステップS221に戻る。
【0103】
Aボタン40aが押されたときはステップS231に進み、自分のキャラクタの前方に別のキャラクタが存在するかどうかを判別する。ここでNOであればステップS221に戻るが、YESであればステップS233に進み、図13に示す行動メニュー画面をディスプレイ38に表示する。
【0104】
ここでプレイヤが十字キー40cによってカーソルを“調べる”にセットし、Aボタン40aを押すと、ステップS235でYESと判断し、ステップS237で調べる処理を行なう。処理が完了すると、ステップS221に戻る。一方、プレイヤが十字キー40cによってカーソルを“起こす”にセットし、Aボタン40aを押すと、ステップS239でYESと判断し、ステップS241で起こす処理を行なう。処理が完了すると、ステップS221に戻る。他方、プレイヤがBボタン40bを押すと、ステップS243でYESと判断し、ステップS245で行動メニュー画面を消去してからステップS221に戻る。
【0105】
プレイヤがいずれのキー操作もしない間は、ステップS247でマップ更新処理を行なうとともに、自分のキャラクタの前方に別のキャラクタが存在するかどうかをステップS249で判別する。そして、YESであればステップS235に戻るが、NOであればステップS245で行動メニュー画面を消去してからステップS221に戻る。したがって、別のキャラクタが自分のキャラクタの前方から離れたときは、Bボタン40bを操作することなく行動メニュー画面が消去される。
【0106】
行動メニュー画面が表示されていない状態でプレイヤがBボタン40bを操作すると、ステップS229でYESと判断し、ステップS251で図18に示すシステムメニュー画面をディスプレイ38に表示する。ここでプレイヤが十字キー40cによってカーソルを“画面サイズ変更”にセットし、Aボタン40aを押すと、ステップS253でYESと判断し、ステップS255でサイズ変更処理を行なう。処理が完了すると、ステップS221に戻る。プレイヤが十字キー40cによってカーソルを“その他設定処理”にセットし、Aボタン40aを押すと、ステップS257でYESと判断し、ステップS259におけるその他設定処理を経てステップS221に戻る。プレイヤがBボタン40bを押すと、ステップS261でYESと判断し、ステップS263でシステムメニュー画面を消去してからステップS221に戻る。プレイヤが十字キー40cによってカーソルを“ゲーム終了”にセットし、Aボタン40aを押すと、ステップS265でYESと判断し、上階層のルーチンに復帰する。
【0107】
プレイヤがいずれのキー操作もしない間は、ステップS267でマップ更新処理を行ない、ステップS253に戻る。これによって、システムメニュー画面が表示されている間も、別のキャラクタはゲーム画面上を移動する。
【0108】
ステップS221,S247またはS267におけるマップ更新処理は、図37に示すサブルーチンに従う。まずステップS271で新規のマップデータを受信したかどうかを判別し、NOであればそのまま上階層のルーチンに復帰するが、YESであれば、ステップS273でゲーム画面を更新する。つまり、図6に示すワーク領域50cに格納されたマップデータを今回受信したマップデータによって更新する。表示領域50dには、更新されたマップデータとグラフィックデータ格納領域50bに格納されたグラフィックデータに基づいて作成されたゲーム画面データが展開され、これによってディスプレイ38のゲーム画面が更新される。このような更新処理を終えると、上階層のルーチンに復帰する。
【0109】
ステップS225における移動処理は、図38に示すサブルーチンに従う。まずステップS281で自分のキャラクタIDおよび移動先情報(上,下,右,左のいずれか)を含む移動要求をゲームサーバ20に送信する。ゲームサーバ20側では、要求元のプレイヤに対応する位置情報の更新処理(ステップS51)、および新規のマップデータの返送処理(ステップS55)が行なわれる。マップデータが返送されると、ステップS283でYESと判断し、ステップS285で上述のステップS273と同じ要領でゲーム画面を更新する。更新が完了すると、上階層のルーチンに復帰する。
【0110】
ステップS237における調べる処理は、図39に示すサブルーチンに従う。まずステップS291で自分のキャラクタIDを含む「調べる」情報を送信する。ゲームサーバ20側ではキャラクタ名および個人情報の検出/返送処理が行なわれるため(ステップS27)、続くステップS293ではキャラクタ名および個人情報の受信の有無を判別する。ここでYESと判断されるとステップS295に進み、受信したキャラクタ名を図6に示す“ニュートラルキャラクタ”のサブリストに登録する。ステップS297では、受信した個人情報に基づく個人情報画面データを図6に示す表示領域50dに展開し、図14に示すような個人情報画面をディスプレイ38に表示する。ステップS299ではBボタン40bの操作の有無を判別し、Bボタン40bが押されたときに上階層のルーチンに復帰する。なお、ステップS295の追加処理は、上述と同様、同じキャラクタ名が知人キャラクタリストに存在しないときに行なわれる。
【0111】
ステップS241における起こす処理は、図40に示すサブルーチンに従う。まずステップS301で自分のキャラクタIDを含む「起こす」情報を送信する。ゲームサーバ20は、「起こす」情報に対して情報Aまたは情報Bを返送するため(ステップS137またはS141)、「起こす」情報を送信した後はステップS303またはS307で情報Aまたは情報Bの受信の有無を判別する。情報Aが返送されたときはステップS305に進み、図15に示す要領で“熟睡して起きる気配もない...”とのメッセージをディスプレイ38に表示する。情報Bが返送されたときはステップS309に進み、図16に示す要領で“むにゃむにゃ...起きそうで起きない”とのメッセージをディスプレイ38に表示する。ステップS313ではBボタン40bの操作の有無を判別し、Bボタン40bが押されたときに上階層のルーチンに復帰する。なお、情報Aおよび情報Bのいずれも受信しないうちにタイムアウトとなると、ステップS311でYESと判断し、そのまま上階層のルーチンに復帰する。
【0112】
ステップS255におけるサイズ変更処理は、図41に示すサブルーチンに従う。まずステップS321で自分のキャラクタIDを含むサイズ変更要求をゲームサーバ20に送信する。ゲームサーバ20はサイズ変更要求に対してマップデータを返送するため(ステップS65)、ステップS323ではマップデータの受信の有無を判別する。マップデータを受信するとステップS325に進み、ゲーム画面を更新する。つまり、図6に示すワーク領域50cに格納されたマップデータを今回受信したマップデータによって更新する。表示領域50dには、更新されたマップデータとグラフィックデータ格納領域50bのグラフィックデータとに基づいて作成されたゲーム画面データが展開され、これによってディスプレイ38のゲーム画面が更新される。更新処理を終えると、上階層のルーチンに復帰する。
【0113】
図32に示すステップS177のログアウト処理は、図42に示すサブルーチンに従う。まずステップS331で自分のキャラクタIDを含むログアウト要求をゲームサーバ20に送信する。ゲームサーバ20はログアウト要求に対してログアウト通知を送信するため(ステップS43)、ステップS333ではログアウト通知の有無を判別する。ログアウト通知を受信するとステップS335でゲーム終了処理を行ない、その後に上階層のルーチンに復帰する。
【0114】
図32に示すステップS163の受付モード変更処理は、図43に示すサブルーチンに従う。まずステップS341で図19に示す受付モード設定画面をディスプレイ38に表示し、“スイッチ1”,“スイッチ2”,“キャラクタリスト編集”または“設定終了”を指向するカーソルを有効化する。続いて、ステップS343,S347,S351およびS355の各々で“スイッチ1”,“スイッチ2”,“キャラクタリスト編集”および“設定終了”のいずれが選択されたかを判別する。
【0115】
プレイヤが十字キー40cによってカーソルを“スイッチ1”に合わせ、Aボタン40aを押すと、ステップS343でYESと判断し、ステップS345でSW1変更処理を行なう。一方、プレイヤが十字キー40cによってカーソルを“スイッチ2”に合わせ、Aボタン40aを押すと、ステップS347でYESと判断し、ステップS349でSW2変更処理を行なう。
【0116】
図19を参照して、SW1変更処理では“呼び出しを許可する”または“呼び出しを禁止する”を指向するカーソルを有効化し、SW2変更処理では“全てのキャラクタを許可”,“特定のキャラクタのみ許可”または“特定のキャラクタ以外を許可”を指向するカーソルを有効化する。十字キー40cによってカーソルが所望のメニュー項目に合わせられると、カーソルが指向するメニュー項目によって図6に示す受付モード情報のスイッチ1またはスイッチ2を更新する。Bボタン40bが押されると、“スイッチ1”,“スイッチ2”,“キャラクタリスト編集”または“設定終了”を指向するカーソルを有効化してからステップS343に戻る。
【0117】
プレイヤが十字キー40cによってカーソルを“キャラクタリスト編集”に合わせ、Aボタン40aを押すと、ステップS351でYESと判断し、ステップS353でキャラクタリスト編集処理を行なう。キャラクタリスト編集処理が完了すると、ステップS343に戻る。
【0118】
プレイヤが十字キー40cによってカーソルを“設定終了”に合わせ、Aボタン40aを押すと、ステップS355からステップS357に進み、設定に変更があったかどうか判断する。ここでNOであればそのままステップS363に進み、モード変更画面を消去してから上階層のルーチンに復帰する。一方、ステップS357でYESであれば、ステップS359で受付モード情報作成処理を行ない、続くステップS361では作成された受付モード情報に自分のキャラクタIDを付加してゲームサーバ20に送信する。送信が完了すると、ステップS363でモード変更画面を消去してから上階層のルーチンに復帰する。
【0119】
ステップS353におけるキャラクタリスト編集処理は、図44に示すサブルーチンに従う。まずステップS371で図20に示すキャラクタリスト編集画面をディスプレイ38に表示し、ステップS373,S377,S381およびS385の各々で“友人”,“ニュートラル”,“要注意人物”および“編集終了”のいずれが選択されたかを判別する。
【0120】
カーソルが“友人”に合わせられた状態でAボタン40aが押されると、ステップS373からステップS375に進み、友人キャラクタについてのサブリスト編集処理を行なう。カーソルが“ニュートラル”に合わせられた状態でAボタン40aが押されると、ステップS377からステップS379に進み、ニュートラルキャラクタについてのサブリスト編集処理を行なう。カーソルが“要注意人物”に合わせられた状態でAボタン40aが押されると、ステップS381からステップS383に進み、要注意人物キャラクタについてのサブリスト編集処理を行なう。ステップS375,S379またはS383の処理が完了すると、ステップS373に戻る。カーソルが“編集終了”に合わせられた状態でAボタン40aが押されると、ステップS385でYESと判断し、ステップS387で編集画面を消去してから上階層のルーチンに復帰する。
【0121】
ステップS375,S379またはS383に示すサブリスト編集処理は、図45に示すサブルーチンに従う。ステップS391では、選択されたサブリストにカーソルを表示する。“友人”が選択されたときはいずれかの友人キャラクタ名を指向するようにカーソルを表示し、“ニュートラル”が選択されたときはいずれかのニュートラルキャラクタ名を指向するようにカーソルを表示し、そして“要注意人物”が選択されたときはいずれかの要注意人物キャラクタ名を指向するようにカーソルを表示する。ここでプレイヤが十字キー40cを操作すると、ステップS393でYESと判断し、ステップS395でカーソルを移動させてからステップS393に戻る。プレイヤがBボタン40bを操作すると、ステップS399でYESと判断し、ステップS401でサブリスト内のカーソルを消去してから上階層のルーチンに復帰する。
【0122】
プレイヤがAボタン40aを操作したときは、ステップS397でYESと判断し、ステップS403で図21に示すような移動先リストを多重表示する。図21に示す移動先リストは、ニュートラルキャラクタについてサブリスト編集を行なうときに表示されるリストであり、メニュー項目は“友人”および“要注意人物”である。友人キャラクタについてのサブリスト編集処理では、移動先リストのメニュー項目は“ニュートラル”および“要注意人物”であり、要注意人物キャラクタについてのサブリスト編集処理では、移動先リストのメニュー項目は“友人”および“ニュートラル”である。
【0123】
移動先リストが表示された状態でプレイヤが十字キー40cを操作すると、ステップS405からステップS407に進み、移動先リスト内のカーソルを所望の方向に移動させる。移動処理が完了すると、ステップS405に戻る。一方、プレイヤがBボタン40bを操作すると、ステップS411でYESと判断し、ステップS419で移動先リストを消去してからステップS393に戻る。
【0124】
他方、プレイヤがAボタン40aを操作すると、ステップS413以降の処理を行なう。まずステップS413で、表示中のサブリストにおいてカーソルが指向しているキャラクタ名を図6に示すワーク領域50cの対応するサブリストから削除する。ステップS415では、移動先リスト内でカーソルが指向しているメニュー項目に対応する図6のサブリストに、ステップS413で削除されたキャラクタ名を追加する。こうしてキャラクタ名の移動が完了すると、ステップS417でキャラクタリスト編集画面を更新し、ステップS419で移動先リストを消去してからステップS393に戻る。
【0125】
図43に示すステップS359の受付モード情報作成処理は、図46に示すサブルーチンに従う。まずステップS421およびS423で、送信する受付モード情報(送信データ)のスイッチ1およびスイッチ2の欄に図6に示す受付モード情報のスイッチ1およびスイッチ2の内容を設定する。ステップS425およびS429では、設定されたスイッチ2の内容を判別する。スイッチ2の内容が“全てのキャラクタを許可”であれば、ステップS425からステップS427に進み、送信データのキャラクタリストの欄をクリアする。一方、スイッチ2の内容が“特定のキャラクタのみ許可”であれば、ステップS429からステップS431に進み、図6に示す知人キャラクタリストに登録された友人キャラクタ名を送信データのキャラクタリストに設定する。他方、スイッチ2の内容が“特定のキャラクタ以外を許可”であれば、ステップS429からステップS433に進み、図6に示す知人キャラクタリストに登録された要注意人物キャラクタ名を送信データのキャラクタリストに設定する。こうして送信データが作成されると、上階層のルーチンに復帰する。
【0126】
以上の説明から分かるように、ゲームサーバ20には複数のプレイヤが予め登録されており、ゲームサーバ20は、通信ネットワーク40を通してログインをしたプレイヤの携帯通信端末30にゲームを提供する。このとき、ゲームサーバ20は、ログイン中のプレイヤのキャラクタを示すグラフィック番号だけでなく、ログアウト中のキャラクタを示すグラフィック番号もログインしたプレイヤのゲーム装置30に送信する。ゲーム装置30のディスプレイ38には、それぞれのキャラクタ画像が、ログイン/ログアウトに対応する態様で表示される。ここで、ログアウト中のキャラクタについて「起こす」が選択されると、「起こす」情報が携帯通信端末30からゲームサーバ20に与えられる。
【0127】
ゲームサーバ20は、ログアウト中のキャラクタの受付モード情報を判別し、スイッチ1の内容が“呼び出しを禁止する”であれば、「起こす」情報の送信元に情報Aを返送する。情報Aを受信した携帯通信端末30には、“熟睡していて起きる気配もない...”とのメッセージが表示される。スイッチ1の内容が“呼び出しを許可する”であっても、スイッチ2の内容が“特定のキャラクタのみ許可”であり、かつキャラクタリストに「起こす」情報の送信元のキャラクタ名が登録されていない場合、あるいはスイッチ2の内容が“特定のキャラクタ以外を許可”であり、かつキャラクタリストに「起こす」情報の送信元のキャラクタ名が登録されている場合は、上述と同様に情報Aが返送される。
【0128】
一方、スイッチ1およびスイッチ2の内容が“呼び出しを許可する”および“全てのキャラクタを許可する”である場合、スイッチ1およびスイッチ2の内容が“呼び出しを許可する”および“特定のキャラクタのみ許可する”で、キャラクタリストに要求元のキャラクタ名が登録されている場合、あるいはスイッチ1およびスイッチ2の内容が“呼び出しを許可する”および“特定のキャラクタ以外を許可する”で、キャラクタリストに要求元のキャラクタ名が登録されていない場合は、ログイン操作要求がゲームサーバ20から相手の携帯通信端末30に送信される。ログイン操作要求を受信した携帯通信端末30のディスプレイ38には、呼び出し元のキャラクタ名を含む呼び出しメッセージが表示される。
【0129】
ここで、ログイン操作要求を受信したプレイヤが“ゲームを開始する”を選択すると、ゲームサーバ20はログイン処理を行ない、これによって“ゲームを開始する”を選択したプレイヤの携帯通信端末30にゲームが提供される。ログイン操作要求を受信したプレイヤが“今は遊ばない”を選択すると、ゲームサーバ20情報Bを「起こす」情報の送信元に返送する。情報Bを受信した携帯通信端末30のディスプレイ38には、“むにゃむにゃ...起きそうでおきない”とのメッセージが表示される。
【0130】
このように、ログイン中のプレイヤによってログアウト中のプレイヤのキャラクタが選択されると、「起こす」情報がログイン中の携帯通信端末30からゲームサーバ20に与えられ、ゲームサーバ20からログアウト中の携帯通信端末30にログイン操作要求が送信される。このため、ログイン中のプレイヤとログアウト中のプレイヤとの間で簡単かつ速やかにゲームを行なうことができる。
【0131】
なお、この実施例では、地形およびキャラクタのグラフィックデータによって形成したゲーム画面を用いてゲームを進行するようにしているが、ゲームは、図47〜図51に示すようなテキストデータのみからなる画面を用いて進行するようにしてもよい。
【0132】
図47はゲームメニュー画面であり、画面中央にタイトル“Online game”が、画面下側に“ゲームを開始する”,“受付モード変更”および“戻る”のメニュー項目が、それぞれ表示される。
【0133】
図48はゲーム画面であり、現在地名“プレーリー草原”が画面上側に表示され、画面中央に複数のキャラクタ名が表示され、画面下側にメニュー項目が表示される。キャラクタ名については、自分のキャラクタ名“にんてん”が一番上に表示され、プレーリー草原に存在する別のキャラクタの名前“ロビン”,“ウイル”,“マリアン”および“ジョン”が“にんてん”の下に表示される。ロビンはログアウト中であり、“ロビン”の右側には“寝ている”との状態情報が表示される。メニュー項目については、“移動”,“調べる”,“設定”および“終了”の4つが表示される。
【0134】
ここで、“移動”が選択されると、図49に示す移動メニュー画面が表示される。図49によれば、画面上側にコマンド名“移動”が表示され、その下に現在地名“プレーリー草原”が表示される。画面中央には、移動方向“北”,“南”,“西”および“東”と、各々の方向に存在する地名“セルバの森”,“オルレアンの森”,“ノルド湿原”および“ボルホコ山”とが表示される。画面下側には、メニュー項目“戻る”が表示される。ここで、所望の移動先が選択されると、移動先の地名や移動先に存在するキャラクタの名前を含むゲーム画面が図48に示す要領で表示される。“戻る”が選択されると、図48に示すゲーム画面に戻る。
【0135】
図48に示すメニュー画面において、任意のキャラクタ名および“調べる”が選択されると、図50に示すような個人情報画面が表示される。画面上側には選択されたキャラクタの名前,性別および状態が表示され、画面中央には選択されたキャラクタのプロフィール(メッセージ)が表示され、画面下側には“調べる”および“戻る”の2つのメニュー項目が表示される。ここで“起こす”が選択されると、ロビンのプレイヤの携帯通信端末には、図51に示す呼び出し画面が表示される。図51によれば、画面上側にタイトル“Online Game”が表示され、画面中央に“にんてんさんがあなたを起こしています”とのメッセージが表示され、画面下側に“ゲームを開始する”,“今は遊ばない”および“呼び出し禁止に設定”の3つのメニュー項目が表示される。ここで、ロビンのプレイヤが各々のメニュー項目を選択したときの動作は、上述の実施例とほぼ同じである。
【0136】
このように、テキストデータからなるゲーム画面においても、ログアウト中のキャラクタ名を表示し、このキャラクタ名が選択されたときにプレイヤにログイン操作要求を送信するようにすれば、ログアウト中のプレイヤと簡単かつ速やかにゲームを行なうことができる。
【0137】
また、この実施例では、図23に示すように、ログイン処理,ログアウト処理,移動処理,サイズ変更処理,起こす処理,受付モード更新処理および個人情報送信処理のすべてを1つのゲームサーバによって行なうよいうにしているが、互いに距離を隔てた複数のサーバによって上述の処理を分担するようにしてもよい。この場合、互いに異なる位置に設置された複数のサーバによってゲームサーバが形成される。
【0138】
さらに、この実施例では、ゲームの具体的な内容や種類が詳しく説明されていないが、仮想空間に登場するキャラクタをプレイヤによって自在に制御できるものは、すべて“ゲーム”の概念に含まれると考えられる。
【図面の簡単な説明】
【図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】ゲームサーバの処理のその他の一部を示すフロー図である。
【図32】携帯通信端末の処理の一部を示すフロー図である。
【図33】携帯通信端末の処理の他の一部を示すフロー図である。
【図34】携帯通信端末の処理のその他の一部を示すフロー図である。
【図35】携帯通信端末の処理のさらにその他の一部を示すフロー図である。
【図36】携帯通信端末の処理の他の一部を示すフロー図である。
【図37】携帯通信端末の処理のその他の一部を示すフロー図である。
【図38】携帯通信端末の処理のさらにその他の一部を示すフロー図である。
【図39】携帯通信端末の処理の他の一部を示すフロー図である。
【図40】携帯通信端末の処理のその他の一部を示すフロー図である。
【図41】携帯通信端末の処理のさらにその他の一部を示すフロー図である。
【図42】携帯通信端末の処理の他の一部を示すフロー図である。
【図43】携帯通信端末の処理のその他の一部を示すフロー図である。
【図44】携帯通信端末の処理のさらにその他の一部を示すフロー図である。
【図45】携帯通信端末の処理の他の一部を示すフロー図である。
【図46】携帯通信端末の処理のその他の一部を示すフロー図である。
【図47】この発明の他の実施例において携帯通信端末に表示されるゲームメニュー画面の一例を示す図解図である。
【図48】この発明の他の実施例において携帯通信端末に表示されるゲーム画面の一例を示す図解図である。
【図49】この発明の他の実施例において携帯通信端末に表示される移動メニュー画面の一例を示す図解図である。
【図50】この発明の他の実施例において携帯通信端末に表示される個人情報画面の一例を示す図解図である。
【図51】この発明の他の実施例において携帯通信端末に表示される呼び出し画面の一例を示す図解図である。
【符号の説明】
10…ネットワークシステム
20…ゲームサーバ
22,48…CPU
24,50…メモリ
30…携帯通信端末
38…ディスプレイ[0001]
[Industrial application fields]
The present invention relates to a game management method of a game server that provides a game to a game device of a player who has logged in through a communication network, or a game device, game server, game program, or storage medium that is applied to a game using a communication network. .
[0002]
[Prior art]
As a multiplayer RPG (Role Playing Game) using the Internet, Ultima Online provided by Electronic Arts Square is well known. In such a multiplayer RPG, a game map and player character data are prepared on a game server on the Internet, and a virtual space where the player character appears is displayed on the display of each client computer logged into the game server. It is reproduced. Another player character also appears in the virtual space, and this player character is operated by another client computer. In this way, since all the player characters appearing in the virtual space are operated by the client computer, it is possible to enjoy realistic bargaining that cannot be experienced with a stand-alone RPG.
[0003]
[Problems to be solved by the invention]
However, in the prior art, only the player character logged into the game server appears in the virtual space. For this reason, in order to play a game with a player who is not logged in to the game server, a non-real-time method such as writing on a bulletin board provided in the game is used, or a real-space contact method such as making a call is used. It had to be time-consuming to start the game. In addition, in games such as the prior art, there are many players who do not want to have a relationship with the opponent in the real space even if they play a role as friends in the game, and such players are contacted by telephone. I can't.
[0004]
In addition, in a multiplayer game, it is one of the pleasures to meet people with a common hobby, but in the conventional system, new friends can be found only among players who are logged in at that time. Of course, you can meet people who have a common hobby by leaving a message such as “People who like XXX, come to △△ at XX days” on the bulletin board. It is necessary not only to be flexible because it is necessary to access at the meeting time, but it is also necessary to allow sufficient time for the message to be read by the other party after writing the message on the bulletin board. For this reason, there is a problem that it takes time to enjoy the game with the desired opponent.
[0005]
Therefore, a main object of the present invention is to provide a game management method capable of easily and quickly playing a game between a player who is logged into the game server and a player who is not logged into the game server. is there.
[0006]
Another object of the present invention is to provide a game server in which a player who has logged in can easily and quickly play a game with a player who has not logged in.
[0007]
Another object of the present invention is to provide a game device that can easily and quickly play a game with a player who has not logged into the game server.
[0008]
Still another object of the present invention is to provide a game program capable of easily and quickly playing a game between a player who is logged into the game server and a player who is not logged into the game server.
[0009]
Another object of the present invention is to provide a storage medium storing a game program capable of easily and quickly playing a game between a player who is logged into the game server and a player who is not logged into the game server. That is.
[0010]
[Means for Solving the Problems]
According to a first aspect of the present invention, there is provided a game server game management method for providing a game to a first game device of a first player who has logged in through a communication network among a plurality of pre-registered players. Player information indicating the second player who is not playing is transmitted to the first game deviceSteps to doWhen a first selection signal for selecting the second player is received from the first game device, a login operation request is transmitted to the second game device of the second player.Including steps toThis is a game management method.
[0011]
A second invention provides a game server that provides a game to a first game device of a first player who has logged in through a communication network among a plurality of pre-registered players, and the second that is not logged in among the plurality of players. Transmission means for transmitting player information indicating the player to the first game device, and transmission for transmitting a login operation request to the second game device of the second player when a selection signal for selecting the second player is received from the first game device. It is a game server characterized by including a means.
[0012]
According to a third aspect of the present invention, in a game device operated by a player who has logged in to a game server through a communication network, player information indicating a specific player who has been registered in advance and has not logged in to the game server when logging in to the game server is displayed. Player information receiving means for receiving from the player, guidance means for guiding selection of the specific player based on the player information, request means for requesting the game server to transmit a login operation request to the specific player when the specific player is selected, and a game A game apparatus comprising: a login operation request receiving means for receiving a login operation request from a game server when not logged into the server.
[0013]
According to a fourth aspect of the present invention, in a game program to be executed by a game device operated by a player who logs in to a game server through a communication network, a specific player who is registered in advance when logging in to the game server and is not logged in to the game server A player information receiving step for receiving player information indicating the player information, a selection guidance step for guiding selection of a specific player based on the player information, and transmission of a login operation request to the specific player when the specific player is selected. And a log-in operation request receiving step of receiving a log-in operation request from the game server when not logged in to the game server.
[0014]
According to a fifth aspect of the present invention, in a storage medium storing a game program to be executed by a game device operated by a player who logs in to a game server through a communication network, the game program is registered in advance when logging into the game server and A player information receiving step for receiving player information indicating a specific player who has not logged into the game server from the game server, a selection guidance step for guiding selection of a specific player based on the player information, and a specific player when a specific player is selected. A storage medium comprising: a requesting step for requesting a game server to transmit a login operation request of the user; and a login operation request receiving step for receiving a login operation request from the game server when not logged in to the game server. .
According to a sixth aspect of the present invention, in a game system operated by a player who logs in to a game server through a communication network, player information indicating a specific player who has been registered in advance and has not logged in to the game server when logging in to the game server is displayed. Player information receiving means for receiving from the player, guidance means for guiding selection of the specific player based on the player information, request means for requesting the game server to transmit a login operation request to the specific player when the specific player is selected, and a game A game system comprising: a login operation request receiving means for receiving a login operation request from a game server when not logged into the server.
[0015]
[Action]
In the first and second inventions, a plurality of players are registered in advance in the game server, and the game server provides a game to the first game device of the first player who has logged in through the communication network. At this time, the game server transmits player information indicating the second player who has not logged in to the first game device, and receives the first selection signal for selecting the second player from the first game device. A login operation request is transmitted to the second game device. By transmitting the player information to the first game device, the second player who has not logged in can be easily grasped by the first game device. Here, when the second player is selected by the first player, a first selection signal is given from the first game device to the game server, and a login operation request is transmitted from the game server to the second game device. That is, participation from the first player is invited to the second player.
[0016]
In one aspect of the present invention, each player can register, in the game server, first transmission information that uniformly permits / prohibits transmission of a login operation request. When the first transmission information of the second player indicates prohibition, the game server returns a first message to the first game device without transmitting a login operation request to the second game device.
[0017]
In another aspect of the present invention, each player can register, in the game server, second transmission information for permitting / prohibiting transmission of a login operation request for each player. When the second transmission information of the second player indicates prohibition for the first player, the game server returns a first message to the first game device without transmitting a login operation request to the second game device.
[0018]
In another aspect of the present invention, the game server returns a second message to the first game device when the login operation rejection is returned from the second game device in response to the login operation request.
[0019]
The login operation request may include identification information that can identify the first player.
[0020]
In still another aspect of the present invention, each player can register personal information in the game server. When the second selection signal for selecting the second player is received from the first game device, the game server returns the personal information of the second player to the first game device.
[0021]
In another aspect of the present invention, the game server already has a first character signal indicating the first character operated by the first player, a two character signal indicating the second character operated by the second player, and at the time of login of the first player. The third character signal indicating the third character operated by the logged-in third player is read from the memory, the player information is added to the second character signal, and the second character is added with the first character signal and the player information. The signal and the third character signal are transmitted to the first game device. The second character is displayed on the first game device in a manner different from that of the first character and the third character.
[0022]
In the third to fifth inventions, when the player operates the game device, the game server is logged in through the communication network. When logging in to the game server, player information indicating a specific player registered in advance and not logged in to the game server is transmitted from the game server, and selection of the specific player is guided based on this player information. When a specific player is selected, a transmission request for a login operation request to the specific player is transmitted to the game server. A game device that has not logged in to the game server receives a login operation request from the game server. That is, when a specific player is selected in the logged-in game device, a login operation request is given to the specific player's game device.
[0023]
【The invention's effect】
According to the first and second inventions, when the second player is selected by the first player, the first selection signal is given from the first game device to the game server, and the game server logs in to the second game device. Since the request is transmitted, the game can be easily and quickly performed between the first player and the second player.
[0024]
According to the third to fifth inventions, when a specific player is selected in the logged-in game device, a login operation request is given to the game device of the specific player, so that the logged-in player logs in. It is possible to play a game easily and quickly with a non-player.
[0025]
The above object, other objects, features and advantages of the present invention will become more apparent from the following detailed description of embodiments with reference to the drawings.
[0026]
【Example】
Referring to FIG. 1, a
[0027]
As shown in FIG. 2, the
[0028]
As the
[0029]
The game program stored in the
[0030]
The matrix data stored in the terrain
[0031]
The character data stored in the character data storage area 24c includes a character ID, a name, a mail address, an IP address, personal information, position information, map size information, status information, and reception mode information. The character ID is a unique identifier assigned to each character, the name is a unique character name assigned to each character, and the mail address and the IP address are the player who operates the character (mobile communication terminal 30). It is a unique address assigned to. The mail address is used when a login operation request is transmitted from the
[0032]
The personal information includes the character's gender, the character's age, the character's occupation, the character's graphic number, the character's ability, the character's belongings (items), and a message that the character issues to each player. The position information is information indicating which block (coordinates) the character is in and in which direction, and the map size information is the size of the virtual space of the
[0033]
The acceptance mode information is information indicating from which player the call may be accepted. When accepting a call from any player (neutral acceptance), “permit call” is set for
[0034]
When accepting a call from a character other than a specific character (rejecting a call from a person who needs attention), “Allow call” is set for
[0035]
A player who wants to participate in the game needs to be pre-registered with the
[0036]
The character matrix stored in the
[0037]
Even if they are the same character, the display mode is different if the direction of the character is different (forward, backward, right, left). Further, the character being logged out is displayed in the virtual space in a sleeping state. As described above, since a character has a plurality of display modes, an extension is added to each graphic number in order to identify the display mode. For example, “f” is added if the character is forward, “b” is added if the character is backward, “r” is added if the character is right, and “l” if the character is left. Is added, and “s” is added if the character is asleep. The coordinates and orientation of each character are specified by position information, and login / logout is specified by status information.
[0038]
The transmission list stored in the
[0039]
From the
[0040]
The
[0041]
The inside of the
[0042]
In the
[0043]
The
[0044]
The game program stored in the
[0045]
The graphic data stored in the graphic data storage area 50b includes image data of objects forming a virtual space such as “tree”, “rock”, “lawn”, and image data of characters appearing in the virtual space. Different image numbers are assigned to the image data. As described above, the character has five states: forward, backward, right, left, and sleeping, and image data indicating each state is prepared in the graphic data storage area 50b. A common graphic number is assigned to each image data, but extensions added to the graphic numbers are different from each other.
[0046]
The map data stored in the
[0047]
Based on such map data and graphic data in the graphic data storage area 50b, virtual space data (game screen data) of
[0048]
Returning to FIG. 6, the reception mode information stored in the
[0049]
A start menu screen as shown in FIG. 9 is displayed on the
[0050]
Furthermore, based on the position information, map size information, and status information included in each character data, the players whose screens need to be updated by this login are listed in the transmission list, and the listed players are individually listed. Create map data. The created map data is individually transmitted to the
[0051]
When the logged-in player operates the cross key 40c, a movement request is transmitted to the
[0052]
When the player moves his / her character in front of another character and operates the A button 40a, an action menu screen having two menu items “examine” and “wake up” is displayed on the upper right side of the screen as shown in FIG. Multiple display. Here, when the player operates the cross key 40c and the A button 40a to select “Check”, “Check” information is transmitted to the
[0053]
According to FIG. 14, the character image is displayed on the upper left of the screen, the name, occupation, sex and age of the character are displayed on the right side of the character image, and a message is displayed on the lower side of the screen. The character image is generated based on the graphic number included in the personal information and the graphic data stored in the graphic data storage area 50b shown in FIG. In addition, capabilities and belongings are not displayed in the received personal information.
[0054]
When “wake up” is selected on the action menu screen shown in FIG. 13, “wake up” information is transmitted from the
[0055]
Here, if the content of the
[0056]
On the other hand, when the contents of the
[0057]
A call screen as shown in FIG. 17 is displayed on the
[0058]
Here, when the player who has received the game-dedicated mail selects “start game” with the cross key 40 c and the A button 40 a, the corresponding command information is returned to the
[0059]
When the player who has received the game dedicated mail selects “do not play now” shown in FIG. 17, the corresponding command information is returned to the
[0060]
When the player who has received the game-specific mail selects “change to call prohibition mode” shown in FIG. 17, the contents of
[0061]
As shown in FIG. 12, when the player operates the
[0062]
Here, when the player selects “change screen size” using the cross key 40 c and the A button 40 a, a size change request is transmitted to the
[0063]
When the system menu screen shown in FIG. 18 is displayed and the cursor is set to “game end” and the A button 40 a is pressed, a logout request is transmitted to the
[0064]
When the player selects “change reception mode” on the game menu screen shown in FIG. 10, a reception mode setting screen shown in FIG. 19 is displayed on the
[0065]
Initially, a cursor directed to “
[0066]
When the A button 40a is pressed while the valid cursor is directed to “character list editing”, a character list editing screen shown in FIG. 20 is displayed on the
[0067]
Again, at first, the cursor on the main list is activated, and when the A button 40a is pressed while the effective cursor is directed to the desired menu item, the cursor is displayed on the sub-list below the desired menu item. The cursor is activated. When the A button 40a is pressed while the valid cursor on the sublist is pointing to the desired character name, the movement destination list is displayed as shown in FIG. The menu items of the movement destination list are two sublists to which the effective cursor is not currently directed. For example, if the valid cursor is directed to the neutral character name, “friend” and “person who needs attention” are displayed in the destination list.
[0068]
When the cursor on the destination list is set to a desired item and the A button 40a is pressed, the character name pointed to by the cursor in the sublist is deleted from the sublist, and the deleted character name is the cursor in the destination list. Is added to the sub-list of items that are oriented. At this time, the acquaintance character list shown in FIG. 6 is also changed at the same time. For example, if “Richard” is selected in the neutral character name sub-list and “friend” is selected in the destination list, “Richard” is deleted from the neutral character sub-list and the friend character sub-list is selected. “Richard” is added to the list.
[0069]
After the character list is edited in this way, when the cursor is set to “end editing” and the A button 40a is pressed, the character list editing screen is updated to the reception mode setting screen shown in FIG. When the cursor is set to “end of setting” on the reception mode setting screen and the A button 40a is pressed, reception mode information (transmission data) composed of the
[0070]
The created reception mode information is transmitted to the
[0071]
Processing of the
[0072]
First, referring to FIG. 23,
[0073]
When the reception mode information is given, the process proceeds from step S21 to step S23. In this step, the character data of the transmission source player is detected from the character data storage area 24c based on the character ID added to the reception mode information, and the reception mode information included in the detected character data is transmitted from the
[0074]
When “investigation” information is given, the process proceeds from step S25 to step S27. In this step, the character data of the transmission source player is detected from the character data storage area 24c based on the character ID included in the “investigating” information, and is included in character data different from the position information included in the detected character data. Based on the position information, character data of a partner to be examined (a character existing ahead of the transmission source character) is specified. Further, the character name and personal information are detected from the specified character data, and the detected character name and personal information are returned to the transmission source of the “check” information.
[0075]
The login process in step S3 follows a subroutine shown in FIG. First, in step S31, the character data of the requesting player is detected from the character
[0076]
The logout process in step S7 shown in FIG. 23 follows a subroutine shown in FIG. First, in step S41, the character data of the requesting player is detected from the character
[0077]
The movement process in step S11 shown in FIG. 23 follows a subroutine shown in FIG. First, in step S51, the character data of the requesting player is detected from the character
[0078]
The size changing process in step S15 shown in FIG. 23 follows a subroutine shown in FIG. First, in step S61, the character data of the requesting player is detected from the character data storage area 24c based on the character ID included in the size change request, the map information included in the detected character data is specified, and the specified map is detected. Update information. If the current map information is “
[0079]
The list-up process in step S35, S45, S53 or S63 follows the subroutine shown in FIGS. First, in step S71, the contents of the character matrix and transmission list formed in the
[0080]
When the center coordinates and size of the character matrix are determined, step S77 sets the character number i to "1", and in step S79, position information is detected from the character data of the character i (specified from the character data storage area 24c). . In step S81, it is determined whether or not the character i is included in the character matrix range based on the position information detected in step S79. If NO, the process directly proceeds to step S87. On the other hand, if “YES” in the step S79, status information and a graphic number are detected from the character data of the character i in a step S83, and the graphic number is mapped to a character matrix in a step S85, and then, the process proceeds to a step S87. In step S85, specifically, the extension determined based on the position information (the direction of the character i) and the status information is added to the graphic number, and the graphic number with the extension added is the position detected in step S79. Mapping to the character matrix according to the information (coordinates of character i).
[0081]
In step S87, the character number i is incremented, and in the subsequent step S89, the incremented character number i is compared with the maximum character number imax. Here, if i ≦ imax, the processes in steps S79 to S87 are repeated. As a result, the graphic numbers of a plurality of characters existing around the character n are mapped to the character matrix. According to FIG. 22, among the characters i, i ', i "and n, the graphic numbers of the characters i, i" and n are mapped to the character matrix.
[0082]
When i> imax, the process proceeds from step S89 to step S91, and the character number i is set to “1” again. In a succeeding step S93, it is determined whether or not the character i matches the character n. If “YES” here, the character ID of the character i (= n) is added to the transmission list in a step S103, and the process proceeds to a step S105. That is, the character ID of the character n is unconditionally added to the transmission list.
[0083]
On the other hand, if “NO” in the step S93, status information is detected from the character data of the character i (stored in the character data storage area 24c) in a step S95, and whether the character i is in a login state or a logout state in a step S97. Is determined. If it is in the logout state, the process proceeds to step S105 without performing the transmission list addition process. On the other hand, if it is a login state, map size information is detected from the character data of the character i at step S99, and it is judged whether the character n exists in the visual field of the character i at step S101. Specifically, based on the detected map size information and position information of the character i, it is determined whether or not the coordinates of the character n are included within the range of the map size of the character i. And if it is YES, it will progress to step S105 through the transmission list addition process in step S103, but if it is NO, it will progress to step S105 as it is.
[0084]
In step S105, the character number i is incremented, and in the subsequent step S107, the incremented character number i is compared with the maximum character number imax. If i ≦ imax, the processes in steps S93 to S107 are repeated. As a result, the character ID of the character n and the character ID of the character in which the character n exists in the field of view are added to the transmission list. According to FIG. 22, only character i has character n in the field of view. For this reason, the character IDs of the characters n and i are added to the transmission list. If i> imax is determined, the process returns to the upper-level routine.
[0085]
In steps S37, S47, and S55 described above, map data is created by cutting out the terrain matrix and the character matrix for each player registered in the transmission list in this way. On the other hand, in step S65, only for the player who transmitted the size change request, map data is created by cutting out the terrain matrix and the character matrix. In either case, the size of the map data follows the map size information of the destination player, and the graphic number of the destination player is assigned to the center coordinates of the map data.
[0086]
In step S19 shown in FIG. 23, the subroutine shown in FIGS. 30 and 31 is processed. In step S111, the character data of the transmission source player is specified from the character data storage area 24c based on the character ID included in the “wake up” information, and based on the position information (coordinates and orientation) included in the specified character data. The character data of the opponent to be woken up is specified, and the reception mode information is detected from the specified character data of the opponent. In step S113, it is determined whether or not the content of the
[0087]
If the content of the
[0088]
When the setting of the permission / prohibition flag is completed in this way, the setting state of the permission / prohibition flag is determined in step S127. If the setting state is “prohibited”, information A is transmitted in step S137, and then the routine returns to the upper layer routine. When the information A is transmitted, a message “There is no sign of awake sleep” is displayed on the
[0089]
On the other hand, if the setting state is “permitted”, a game-dedicated e-mail is created in step S129, and the created game-dedicated e-mail is transmitted to the partner
[0090]
When the other party selects “Do not play now” for the game-dedicated mail, the process proceeds from step S139 to step S141, and information B is transmitted to the calling
[0091]
In response to the game-dedicated mail, if the opponent selects “start game” or times out before the opponent selects anything, YES is determined in step S143 or S145, and the process returns to the upper level routine. To do. However, when “start game” is selected, a login request is transmitted from the
[0092]
Next, processing of the
[0093]
First, the
[0094]
If the received signal is a mail signal, it is determined in step S165 whether this mail signal is a normal mail or a game-dedicated mail. If it is a normal mail, the process returns to step S151 through the normal mail process in step S167. On the other hand, if the received mail signal is a game-dedicated mail, game mail processing is performed in step S169, and the state of the game start flag is determined in step S171. If the game start flag is in the reset state, the process directly returns to step S151. If the game start flag is in the set state, the login process, the game process, and the logout process are performed in steps S173, S175, and S177, and then step S151. Return to.
[0095]
In the menu screen shown in FIG. 10, when the player moves the cursor to “change accept mode” with the cross key 040c and presses the A button 40a, the process proceeds from step S153 to step S163, and accept mode change processing is performed. When the process is completed, the process returns to step S151. On the other hand, if the player selects “start game” with the cross key 40c and the A button 40a on the menu screen shown in FIG. 10, “YES” is determined in the step S155, and the process proceeds to a step S173.
[0096]
The game mail process in step S169 follows a subroutine shown in FIG. First, in step S181, a ringing sound is generated through the calling
[0097]
When the process of step S187 is completed, the call screen shown in FIG. 11 is displayed on the
[0098]
When the cursor is set to “start game” by the cross key 40c and the A button 40a is pressed, the process proceeds from step S191 to step S193, and command information corresponding to the selected menu item is transmitted to the
[0099]
If “do not play now” is selected by the cross key 40c and the A button 40a, YES is determined in the step S205, and the command information corresponding to the menu item is transmitted to the
[0100]
On the
[0101]
The login process in step S173 follows a subroutine shown in FIG. First, initialization is performed in step S211, and a login request is transmitted to the
[0102]
The game process in step S175 follows a subroutine shown in FIGS. First, in step S221, map update processing is performed, and then in steps S223, S227, and S229, it is determined whether or not the cross key 40c, the A button 40a, and the
[0103]
When the A button 40a is pressed, the process proceeds to step S231, and it is determined whether or not another character exists in front of the own character. If “NO” here, the process returns to the step S221, but if “YES”, the process proceeds to a step S233 to display the action menu screen shown in FIG.
[0104]
Here, when the player sets the cursor to “Check” with the cross key 40c and presses the A button 40a, YES is determined in Step S235, and the check is performed in Step S237. When the process is completed, the process returns to step S221. On the other hand, when the player sets the cursor to “raise” by the cross key 40c and presses the A button 40a, YES is determined in the step S239, and a process of raising in the step S241 is performed. When the process is completed, the process returns to step S221. On the other hand, when the player presses the
[0105]
While the player does not perform any key operation, map update processing is performed in step S247, and it is determined in step S249 whether another character exists in front of the player's own character. If YES, the process returns to step S235. If NO, the action menu screen is erased in step S245, and then the process returns to step S221. Therefore, when another character leaves the front of his / her character, the action menu screen is erased without operating the
[0106]
If the player operates the
[0107]
While the player does not perform any key operation, map update processing is performed in step S267, and the process returns to step S253. Thereby, another character moves on the game screen while the system menu screen is displayed.
[0108]
The map update process in step S221, S247 or S267 follows a subroutine shown in FIG. First, in step S271, it is determined whether or not new map data has been received. If NO, the process returns to the upper hierarchy routine. If YES, the game screen is updated in step S273. That is, the map data stored in the
[0109]
The movement process in step S225 follows a subroutine shown in FIG. First, in step S281, a movement request including its own character ID and destination information (upper, lower, right, or left) is transmitted to the
[0110]
The checking process in step S237 follows a subroutine shown in FIG. First, in step S291, “investigation” information including its own character ID is transmitted. Since the
[0111]
The process that occurs in step S241 follows a subroutine shown in FIG. First, in step S301, "wake up" information including his / her character ID is transmitted. Since the
[0112]
The size changing process in step S255 follows a subroutine shown in FIG. First, in step S321, a size change request including its own character ID is transmitted to the
[0113]
The logout process in step S177 shown in FIG. 32 follows a subroutine shown in FIG. First, in step S331, a logout request including its own character ID is transmitted to the
[0114]
The acceptance mode changing process in step S163 shown in FIG. 32 follows a subroutine shown in FIG. First, in step S341, the acceptance mode setting screen shown in FIG. 19 is displayed on the
[0115]
When the player moves the cursor to “
[0116]
Referring to FIG. 19, the SW1 change process enables a cursor pointing to “permit call” or “prohibit call”, and SW2 change process “allows all characters”, “allows only specific characters”. Enables a cursor that points to "or allow non-specific characters". When the cursor is set to a desired menu item by the cross key 40c, the
[0117]
When the player moves the cursor to “character list editing” with the cross key 40c and presses the A button 40a, YES is determined in step S351, and character list editing processing is performed in step S353. When the character list editing process is completed, the process returns to step S343.
[0118]
When the player moves the cursor to “end setting” with the cross key 40c and presses the A button 40a, the process proceeds from step S355 to step S357, and it is determined whether or not the setting has been changed. If “NO” here, the process proceeds to a step S363 as it is, and after the mode change screen is erased, the process returns to the upper hierarchy routine. On the other hand, if “YES” in the step S357, reception mode information creation processing is performed in a step S359, and in the subsequent step S361, the user ID is added to the created reception mode information and transmitted to the
[0119]
The character list editing process in step S353 follows a subroutine shown in FIG. First, in step S371, the character list editing screen shown in FIG. 20 is displayed on the
[0120]
If the A button 40a is pressed while the cursor is set to "friend", the process proceeds from step S373 to step S375, and the sub-list editing process for the friend character is performed. When the A button 40a is pressed while the cursor is set to "neutral", the process proceeds from step S377 to step S379, and the sub-list editing process for the neutral character is performed. If the A button 40a is pressed in a state where the cursor is set to “person requiring attention”, the process proceeds from step S381 to step S383, and a sublist editing process is performed for the person character requiring attention. When the process of step S375, S379 or S383 is completed, the process returns to step S373. If the A button 40a is pressed in a state where the cursor is set to “end editing”, YES is determined in the step S385, and the editing screen is erased in a step S387, and then the process returns to the upper hierarchy routine.
[0121]
The sublist editing process shown in steps S375, S379, or S383 follows the subroutine shown in FIG. In step S391, a cursor is displayed on the selected sublist. When "Friend" is selected, the cursor is displayed so that it points to one of the friend character names. When "Neutral" is selected, the cursor is displayed so that it points to one of the neutral character names. When “Caution required person” is selected, a cursor is displayed so as to point to one of the caution character names. Here, when the player operates the cross key 40c, YES is determined in a step S393, the cursor is moved in a step S395, and then the process returns to the step S393. When the player operates the
[0122]
When the player operates the A button 40a, YES is determined in a step S397, and a movement destination list as shown in FIG. The moving destination list shown in FIG. 21 is a list displayed when sublist editing is performed for a neutral character, and the menu items are “friends” and “persons requiring attention”. In the sublist editing process for the friend character, the menu items of the destination list are “neutral” and “person to be watched”. In the sublist editing process for the attention character, the menu item of the destination list is “friend”. "And" Neutral ".
[0123]
When the player operates the cross key 40c in a state where the movement destination list is displayed, the process proceeds from step S405 to step S407, and the cursor in the movement destination list is moved in a desired direction. When the movement process is completed, the process returns to step S405. On the other hand, when the player operates the
[0124]
On the other hand, when the player operates the A button 40a, the processing after step S413 is performed. First, in step S413, the character name to which the cursor is pointing in the currently displayed sublist is deleted from the corresponding sublist in the
[0125]
The reception mode information creation processing in step S359 shown in FIG. 43 follows a subroutine shown in FIG. First, in steps S421 and S423, the contents of
[0126]
As can be seen from the above description, a plurality of players are registered in advance in the
[0127]
The
[0128]
On the other hand, when the contents of the
[0129]
Here, when the player who has received the login operation request selects “start game”, the
[0130]
Thus, when the logged-in player character is selected by the logged-in player, the “wake-up” information is given to the
[0131]
In this embodiment, the game is progressed using a game screen formed by the terrain and character graphic data. However, the game has a screen consisting only of text data as shown in FIGS. You may make it progress using.
[0132]
FIG. 47 shows a game menu screen, in which the title “Online game” is displayed in the center of the screen, and “start game”, “change reception mode”, and “return” menu items are displayed at the bottom of the screen.
[0133]
FIG. 48 shows a game screen, where the current location name “Prairie Prairie” is displayed at the top of the screen, a plurality of character names are displayed at the center of the screen, and menu items are displayed at the bottom of the screen. As for the character name, your character name “Ninten” is displayed at the top, and the names of other characters “Robin”, “Wil”, “Marian” and “John” in the prairie grassland are It is displayed under “Tenten”. Robin is logging out and status information “sleeping” is displayed on the right side of “Robin”. For menu items, four items of “move”, “examine”, “set”, and “end” are displayed.
[0134]
Here, when “move” is selected, a move menu screen shown in FIG. 49 is displayed. According to FIG. 49, the command name “move” is displayed on the upper side of the screen, and the current location name “prairie grassland” is displayed below it. In the center of the screen, the moving directions “north”, “south”, “west” and “east” and the place names “Selva Forest”, “Orlean Forest”, “Nord Wetlands” and “Volkhoko” exist in each direction. "Mountain" is displayed. The menu item “Return” is displayed at the bottom of the screen. Here, when a desired destination is selected, a game screen including the place name of the destination and the name of the character existing at the destination is displayed as shown in FIG. When “RETURN” is selected, the game screen shown in FIG. 48 is restored.
[0135]
When an arbitrary character name and “Check” are selected on the menu screen shown in FIG. 48, a personal information screen as shown in FIG. 50 is displayed. The name, gender, and status of the selected character are displayed at the top of the screen, the profile (message) of the selected character is displayed at the center of the screen, and two types of “examine” and “return” are displayed at the bottom of the screen. Menu items are displayed. When “wake up” is selected here, a call screen shown in FIG. 51 is displayed on the mobile communication terminal of the Robin player. According to FIG. 51, the title “Online Game” is displayed at the top of the screen, the message “Nenten-san is waking you” is displayed at the center of the screen, and “Start the game” is displayed at the bottom of the screen. , Three menu items “not play now” and “set to call prohibition” are displayed. Here, the operation when the Robin player selects each menu item is substantially the same as in the above-described embodiment.
[0136]
In this way, even on a game screen made up of text data, if the character name being logged out is displayed and a login operation request is transmitted to the player when this character name is selected, it is easy to connect with the player being logged out. And a game can be played promptly.
[0137]
Further, in this embodiment, as shown in FIG. 23, all of login processing, logout processing, movement processing, size change processing, waking processing, reception mode update processing, and personal information transmission processing may be performed by one game server. However, the above-described processing may be shared by a plurality of servers spaced from each other. In this case, a game server is formed by a plurality of servers installed at different positions.
[0138]
Furthermore, in this embodiment, the specific contents and types of the game are not described in detail, but all the characters that can be freely controlled by the player in the virtual space are considered to be included in the concept of “game”. It is done.
[Brief description of the drawings]
FIG. 1 is an illustrative view showing one embodiment of the present invention;
FIG. 2 is a block diagram illustrating an example of a configuration of a game server.
FIG. 3 is an illustrative view showing a mapping state of a memory provided in the game server.
FIG. 4 is an external view showing an example of a mobile communication terminal.
FIG. 5 is a block diagram illustrating an example of a configuration of a mobile communication terminal.
FIG. 6 is an illustrative view showing a mapping state of a memory provided in the mobile communication terminal.
FIG. 7 is an illustrative view showing a structure of map data.
FIG. 8 is an illustrative view showing one example of a virtual space.
FIG. 9 is an illustrative view showing one example of a start menu screen displayed on the mobile communication terminal.
FIG. 10 is an illustrative view showing one example of a game menu screen displayed on the mobile communication terminal.
FIG. 11 is an illustrative view showing one example of a virtual space displayed on the mobile communication terminal.
FIG. 12 is an illustrative view showing another example of the virtual space displayed on the mobile communication terminal.
FIG. 13 is an illustrative view showing one example of a virtual space and an action menu screen displayed on the mobile communication terminal.
FIG. 14 is an illustrative view showing one example of a personal information screen displayed on a mobile communication terminal.
FIG. 15 is an illustrative view showing one example of a virtual space, an action menu screen, and a response message displayed on the mobile communication terminal.
FIG. 16 is an illustrative view showing another example of a virtual space, an action menu screen, and a response message displayed on the mobile communication terminal.
FIG. 17 is an illustrative view showing one example of a call screen displayed on a mobile communication terminal;
FIG. 18 is an illustrative view showing one example of a virtual space and a system menu screen displayed on the mobile communication terminal.
FIG. 19 is an illustrative view showing one example of a reception mode setting screen displayed on the mobile communication terminal.
FIG. 20 is an illustrative view showing one example of a character list editing screen displayed on the mobile communication terminal.
FIG. 21 is an illustrative view showing one example of a character list editing screen and a destination list displayed on a mobile communication terminal;
FIG. 22 is an illustrative view showing one portion of operation of the game server;
FIG. 23 is a flowchart showing a part of processing of the game server.
FIG. 24 is a flowchart showing another part of the processing of the game server.
FIG. 25 is a flowchart showing another part of the processing of the game server.
FIG. 26 is a flowchart showing yet another portion of the processing of the game server.
FIG. 27 is a flowchart showing another part of the process of the game server.
FIG. 28 is a flowchart showing another part of the processing of the game server.
FIG. 29 is a flowchart showing yet another portion of the processing of the game server.
FIG. 30 is a flowchart showing another part of the process of the game server.
FIG. 31 is a flowchart showing still another part of the processing of the game server.
FIG. 32 is a flowchart showing a part of the processing of the mobile communication terminal.
FIG. 33 is a flowchart showing another portion of the processing of the mobile communication terminal.
FIG. 34 is a flowchart showing another part of the processing of the mobile communication terminal.
FIG. 35 is a flowchart showing yet another portion of the processing of the mobile communication terminal.
FIG. 36 is a flowchart showing another part of the process of the mobile communication terminal.
FIG. 37 is a flowchart showing still another portion of the processing of the mobile communication terminal.
FIG. 38 is a flowchart showing yet another portion of the processing of the mobile communication terminal.
FIG. 39 is a flowchart showing another portion of the process of the mobile communication terminal.
FIG. 40 is a flowchart showing another part of the processing of the mobile communication terminal.
FIG. 41 is a flowchart showing yet another portion of the processing of the mobile communication terminal.
FIG. 42 is a flowchart showing another portion of the processing of the mobile communication terminal.
FIG. 43 is a flowchart showing another portion of the processing of the mobile communication terminal.
FIG. 44 is a flowchart showing yet another portion of the processing of the mobile communication terminal.
FIG. 45 is a flowchart showing another part of the process of the mobile communication terminal.
FIG. 46 is a flowchart showing still another portion of the processing of the mobile communication terminal.
FIG. 47 is an illustrative view showing one example of a game menu screen displayed on the mobile communication terminal in another embodiment of the present invention;
FIG. 48 is an illustrative view showing one example of a game screen displayed on a mobile communication terminal in another embodiment of the present invention;
FIG. 49 is an illustrative view showing one example of a movement menu screen displayed on the mobile communication terminal in another embodiment of the present invention;
FIG. 50 is an illustrative view showing one example of a personal information screen displayed on a portable communication terminal in another embodiment of the present invention.
FIG. 51 is an illustrative view showing one example of a call screen displayed on a mobile communication terminal in another embodiment of the present invention;
[Explanation of symbols]
10 Network system
20 ... Game server
22, 48 ... CPU
24, 50 ... Memory
30. Mobile communication terminal
38 ... Display
Claims (12)
前記複数のプレイヤのうち前記ログインをしていない第2プレイヤを示すプレイヤ情報を前記第1ゲーム装置に送信するステップと、
前記第2プレイヤを選択する第1選択信号を前記第1ゲーム装置から受信したとき前記第2プレイヤの第2ゲーム装置にログイン操作要求を送信するステップを含むことを特徴とする、ゲーム管理方法。In a game management method of a game server for providing a game to a first game device of a first player who has logged in through a communication network among a plurality of pre-registered players,
And transmitting the player information of a second player who is not the log of the plurality of players to the first game device,
A game management method comprising a step of transmitting a login operation request to a second game device of the second player when a first selection signal for selecting the second player is received from the first game device.
前記第2プレイヤの前記第1送信情報が前記禁止を示すとき、前記ログイン操作要求を前記第2ゲーム装置に送信することなく第1メッセージを前記第1ゲーム装置に返送するステップを含む、請求項1記載のゲーム管理方法。Each of the players can register, with the game server, first transmission information that uniformly permits / prohibits transmission of the login operation request,
When the first transmission information before Symbol second player indicates the prohibition, comprising the step of returning the first message to the first game device without transmitting the login operation request to the second game device, wherein Item 1. A game management method according to Item 1.
前記第2プレイヤの前記第2送信情報が前記第1プレイヤについて前記禁止を示すとき、前記ログイン操作要求を前記第2ゲーム装置に送信することなく前記第1メッセージを前記第1ゲーム装置に返送するステップを含む、請求項2記載のゲーム管理方法。Each of the players can register, in the game server, second transmission information that permits / prohibits transmission of the login operation request for each player,
When the second transmission information before Symbol second player indicates the prohibition for the first player, back to the first game device said first message without sending the login operation request to the second game device The game management method according to claim 2 , further comprising a step of :
前記第2プレイヤを選択する第2選択信号を前記第1ゲーム装置から受信したとき、前記第2プレイヤの前記個人情報を前記第1ゲーム装置に返送するステップを含む、請求項1ないし5のいずれかに記載のゲーム管理方法。Each of the players can register personal information with the game server,
When receiving the second selection signal for selecting a pre-Symbol second player from the first game device, comprising the step of returning the personal information of the second player in the first game device, of claims 1 to 5 The game management method according to any one of the above.
前記複数のプレイヤのうち前記ログインをしていない第2プレイヤを示すプレイヤ情報を前記第1ゲーム装置に送信する送信手段、および
前記第2プレイヤを選択した選択信号を前記第1ゲーム装置から受信したとき前記第2プレイヤの第2ゲーム装置にログイン操作要求を送信する送信手段を備えることを特徴とする、ゲームサーバ。In a game server that provides a game to a first game device of a first player who has logged in through a communication network among a plurality of pre-registered players,
Transmitting means for transmitting player information indicating the second player who has not logged in among the plurality of players to the first game device; and a selection signal for selecting the second player is received from the first game device. A game server comprising a transmission means for transmitting a login operation request to the second game device of the second player.
前記ゲームサーバにログインしたとき予め登録されたかつ前記ゲームサーバにログインしていない特定プレイヤを示すプレイヤ情報を前記ゲームサーバから受信するプレイヤ情報受信手段、
前記プレイヤ情報に基づいて前記特定プレイヤの選択を案内する案内手段、
前記特定プレイヤが選択されたとき前記特定プレイヤへのログイン操作要求の送信を前記ゲームサーバに要求する要求手段、および
前記ゲームサーバにログインしていないとき前記ゲームサーバから前記ログイン操作要求を受信するログイン操作要求受信手段を備えることを特徴とする、ゲーム装置。In a game device operated by a player who logs in to a game server through a communication network,
Player information receiving means for receiving, from the game server, player information indicating a specific player who has been registered in advance when logging into the game server and has not logged into the game server;
Guiding means for guiding selection of the specific player based on the player information;
Request means for requesting the game server to transmit a log-in operation request to the specific player when the specific player is selected, and log-in for receiving the log-in operation request from the game server when not logging into the game server A game device comprising operation request receiving means.
前記ゲームサーバにログインしたとき予め登録されたかつ前記ゲームサーバにログインしていない特定プレイヤを示すプレイヤ情報を前記ゲームサーバから受信するプレイヤ情報受信ステップ、
前記プレイヤ情報に基づいて前記特定プレイヤの選択を案内する選択案内ステップ、
前記特定プレイヤが選択されたとき前記特定プレイヤへのログイン操作要求の送信を前記ゲームサーバに要求する要求ステップ、および
前記ゲームサーバにログインしていないとき前記ゲームサーバから前記ログイン操作要求を受信するログイン操作要求受信ステップを備えることを特徴とする、ゲームプログラム。In a game program to be executed by a game device operated by a player who logs in to a game server through a communication network,
A player information receiving step of receiving, from the game server, player information indicating a specific player who has been registered in advance when logging in to the game server and has not logged in to the game server;
A selection guidance step for guiding the selection of the specific player based on the player information;
A requesting step for requesting the game server to transmit a login operation request to the specific player when the specific player is selected, and a login for receiving the login operation request from the game server when not logging in to the game server A game program comprising an operation request receiving step.
前記ゲームプログラムは、
前記ゲームサーバにログインしたとき予め登録されたかつ前記ゲームサーバにログインしていない特定プレイヤを示すプレイヤ情報を前記ゲームサーバから受信するプレイヤ情報受信ステップ、
前記プレイヤ情報に基づいて前記特定プレイヤの選択を案内する選択案内ステップ、
前記特定プレイヤが選択されたとき前記特定プレイヤへのログイン操作要求の送信を前記ゲームサーバに要求する要求ステップ、および
前記ゲームサーバにログインしていないとき前記ゲームサーバから前記ログイン操作要求を受信するログイン操作要求受信ステップを備えることを特徴とする、記憶媒体。In a storage medium storing a game program to be executed by a game device operated by a player who logs in to a game server through a communication network,
The game program is
A player information receiving step of receiving, from the game server, player information indicating a specific player who has been registered in advance when logging in to the game server and has not logged in to the game server;
A selection guidance step for guiding the selection of the specific player based on the player information;
A requesting step for requesting the game server to transmit a login operation request to the specific player when the specific player is selected, and a login for receiving the login operation request from the game server when not logging in to the game server A storage medium comprising an operation request receiving step.
前記ゲームサーバにログインしたとき予め登録されたかつ前記ゲームサーバにログインしていない特定プレイヤを示すプレイヤ情報を前記ゲームサーバから受信するプレイヤ情報受信手段、
前記プレイヤ情報に基づいて前記特定プレイヤの選択を案内する案内手段、
前記特定プレイヤが選択されたとき前記特定プレイヤへのログイン操作要求の送信を前記ゲームサーバに要求する要求手段、および
前記ゲームサーバにログインしていないとき前記ゲームサーバから前記ログイン操作要求を受信するログイン操作要求受信手段を備えることを特徴とする、ゲームシステム。 In a game system operated by a player who logs in to a game server through a communication network,
Player information receiving means for receiving, from the game server, player information indicating a specific player who has been registered in advance when logging into the game server and has not logged into the game server;
Guiding means for guiding selection of the specific player based on the player information;
Request means for requesting the game server to transmit a login operation request to the specific player when the specific player is selected; and
A game system comprising: a login operation request receiving means for receiving the login operation request from the game server when not logged in to the game server .
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001268220A JP4920838B2 (en) | 2000-12-28 | 2001-09-05 | How to manage network games |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000401236 | 2000-12-28 | ||
JP2000401236 | 2000-12-28 | ||
JP2000-401236 | 2000-12-28 | ||
JP2001268220A JP4920838B2 (en) | 2000-12-28 | 2001-09-05 | How to manage network games |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011180117A Division JP5001451B2 (en) | 2000-12-28 | 2011-08-22 | Game system, communication terminal and program |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2002253865A JP2002253865A (en) | 2002-09-10 |
JP4920838B2 true JP4920838B2 (en) | 2012-04-18 |
Family
ID=26607093
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001268220A Expired - Lifetime JP4920838B2 (en) | 2000-12-28 | 2001-09-05 | How to manage network games |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4920838B2 (en) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060205517A1 (en) * | 2005-03-08 | 2006-09-14 | Malabuyo Paolo V | Systems and methods for providing a system level user interface in a multimedia console |
US20060205518A1 (en) * | 2005-03-08 | 2006-09-14 | Microsoft Corporation | Systems and methods for providing system level notifications in a multimedia console |
JP2007104613A (en) | 2005-10-07 | 2007-04-19 | Sony Computer Entertainment Inc | Electronic communication method, electronic communication system, communication terminal, and server |
US8814693B2 (en) * | 2011-05-27 | 2014-08-26 | Microsoft Corporation | Avatars of friends as non-player-characters |
JP5894819B2 (en) * | 2012-02-02 | 2016-03-30 | 株式会社コナミデジタルエンタテインメント | Message exchange system, control method, and program |
JP7108389B2 (en) * | 2017-09-26 | 2022-07-28 | 株式会社コロプラ | Program, information processing device, information processing system, and information processing method |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU2322100A (en) * | 1999-01-28 | 2000-08-18 | Sega Enterprises, Ltd. | Network game system, game device terminal used in it and storage medium |
JP2000325657A (en) * | 1999-05-19 | 2000-11-28 | Casio Comput Co Ltd | Communication game device, server device, and storage medium with communication game program stored therein |
JP3512386B2 (en) * | 2000-01-20 | 2004-03-29 | 株式会社スクウェア・エニックス | Online composite service provision processing method and online composite service provision processing system |
-
2001
- 2001-09-05 JP JP2001268220A patent/JP4920838B2/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
JP2002253865A (en) | 2002-09-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5001451B2 (en) | Game system, communication terminal and program | |
JP4781743B2 (en) | Communication game system | |
KR100463731B1 (en) | Server device for network game, network game procedure controlling method and computer readable recording medium for recording a program for executing network game | |
JP6271692B2 (en) | Communication game system and communication control method | |
JP2010113728A (en) | Option selection system using plurality of information processors | |
JP4448814B2 (en) | Choice selection system using multiple information processing devices | |
JP4920838B2 (en) | How to manage network games | |
JP2007128534A (en) | Selection system of option using a plurality of information processors | |
JP5864017B1 (en) | Game server. | |
JP3694499B2 (en) | Network game system, game server, game terminal, control method and program thereof | |
JP3694511B2 (en) | Network game system, game server, game terminal, control method and program thereof | |
JP2019048058A (en) | Information processing device, information processing system, information processing program, and information processing method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080822 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110621 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110822 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20120110 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20120202 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 4920838 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150210 Year of fee payment: 3 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
EXPY | Cancellation because of completion of term |