JP7337697B2

JP7337697B2 - プログラム、及びシステム

Info

Publication number: JP7337697B2
Application number: JP2019542906A
Authority: JP
Inventors: 新平坂田
Original assignee: Square Enix Co Ltd
Current assignee: Square Enix Co Ltd
Priority date: 2017-09-22
Filing date: 2017-09-22
Publication date: 2023-09-04
Anticipated expiration: 2037-09-22
Also published as: US20200222806A1; US11161042B2; WO2019058500A1; JPWO2019058500A1

Description

本発明の実施形態の少なくとも１つは、複数のモデルで構成されるキャラクタの外観を変更する機能をユーザ端末に実現させるためのプログラムに関する。また、本発明の実施形態の少なくとも１つは、通信ネットワークと、サーバと、ユーザ端末とを備え、複数のモデルで構成されるキャラクタの外観を変更するシステムに関する。また、本発明の実施形態の少なくとも１つは、複数のモデルで構成されるキャラクタの外観を変更する機能をサーバに実現させるためのプログラムに関する。

従来、所定の時機でキャラクタの外観を変更するシステムがある。

このようなシステムには、キャラクタの外観設定を登録可能なＮ種類（Ｎは２以上）の登録設定データそれぞれに、ユーザの操作入力に従ってキャラクタの外観設定を登録するものがある（特許文献１参照）。

特開２００８－２７２１２４号公報

このようなシステムにおいて、キャラクタの外観が損なわれないようにするために隣接する２つのモデルが重複することを禁止することが有効となる場合がある。この場合、例えば各モデルが衝突するか否かを判定することでキャラクタへの設定の可否を判定する構成などが考えられる。しかし、このような構成では処理負荷が過大になる場合があった。そのため、キャラクタの外観を損なわずにキャラクタの外観を変更する場合に、衝突判定をする場合に比べて処理負荷を小さくする工夫が求められていた。

本発明の少なくとも１つの実施形態の目的は、より処理負荷が小さい構成でキャラクタの外観を損なわずにキャラクタの外観を変更するシステムを提供することにある。

非限定的な観点によると、本発明の一実施形態に係るプログラムは、複数のモデルで構成されるキャラクタの外観を変更する機能をユーザ端末に実現させるためのプログラムであって、前記ユーザ端末に、少なくとも１のモデルを判定対象として特定する特定機能と、前記キャラクタを構成する複数のモデルのうち前記判定対象に対応する箇所のモデル（以下「変更対象」という。）が前記判定対象に変更される場合に所定の隣接条件が満たされるかについて、前記判定対象の形状と前記変更対象に隣接するモデルの形状とに基づいて判定する判定機能と、該判定機能よる判定結果に基づいて、前記変更対象を前記判定対象に変更可能かを決定する決定機能と、を実現させるためのものである。

非限定的な観点によると、本発明の一実施形態に係るシステムは、通信ネットワークと、サーバと、ユーザ端末とを備え、複数のモデルで構成されるキャラクタの外観を変更するシステムであって、少なくとも１のモデルを判定対象として特定する特定手段と、前記キャラクタを構成する複数のモデルのうち前記判定対象に対応する箇所のモデル（以下「変更対象」という。）が前記判定対象に変更される場合に所定の隣接条件が満たされるかについて、前記判定対象の形状と前記変更対象に隣接するモデルの形状とに基づいて判定する判定手段と、該判定手段よる判定結果に基づいて、前記変更対象を前記判定対象に変更可能かを決定する決定手段と、を含むことを特徴とする。

非限定的な観点によると、本発明の一実施形態に係るプログラムは、複数のモデルで構成されるキャラクタの外観を変更する機能をサーバに実現させるためのプログラムであって、前記サーバに、少なくとも１のモデルを判定対象として特定する特定機能と、前記キャラクタを構成する複数のモデルのうち前記判定対象に対応する箇所のモデル（以下「変更対象」という。）が前記判定対象に変更される場合に所定の隣接条件が満たされるかについて、前記判定対象の形状と前記変更対象に隣接するモデルの形状とに基づいて判定する判定機能と、該判定機能よる判定結果に基づいて、前記変更対象を前記判定対象に変更可能かを決定する決定機能と、を実現させるためのものである。

本願の各実施形態により１又は２以上の不足が解決される。

本発明の実施形態の少なくとも一つに対応するシステムの構成の例を示すブロック図である。本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。本発明の実施形態の少なくとも一つに対応するゲーム関連処理の例を示すフローチャートである。本発明の実施形態の少なくとも一つに対応するゲーム関連処理におけるサーバ側の動作の例を示すフローチャートである。本発明の実施形態の少なくとも一つに対応するゲーム関連処理における端末の動作の例を示すフローチャートである。本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。本発明の実施形態の少なくとも一つに対応するゲーム関連処理の例を示すフローチャートである。本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。本発明の実施形態の少なくとも一つに対応するゲーム関連処理の例を示すフローチャートである。本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。本発明の実施形態の少なくとも一つに対応する調整処理の例を示すフローチャートである。本発明の実施形態の少なくとも一つに対応する概念を説明するための説明図である。本発明の実施形態の少なくとも一つに対応する概念を説明するための説明図である。本発明の実施形態の少なくとも一つに対応する情報の格納状態の例について説明するための説明図である。本発明の実施形態の少なくとも一つに対応する概念を説明するための説明図である。本発明の実施形態の少なくとも一つに対応する情報の格納状態の例について説明するための説明図である。本発明の実施形態の少なくとも一つに対応するサーバの構成の例を示すブロック図である。本発明の実施形態の少なくとも一つに対応するゲーム関連処理の例を示すフローチャートである。

以下、本発明の実施形態の例について図面を参照して説明する。なお、以下で説明する各実施形態の例における各種構成要素は、矛盾等が生じない範囲で適宜組み合わせ可能である。また、ある実施形態の例として説明した内容については、他の実施形態においてその説明を省略している場合がある。また、各実施形態の特徴部分に関係しない動作や処理については、その内容を省略している場合がある。さらに、以下で説明する各種フローを構成する各種処理の順序は、処理内容に矛盾等が生じない範囲で順不同である。

［第１の実施形態］
図１は、本発明の一実施形態におけるシステム１００の構成の例を示すブロック図である。図１に示すように、システム１００は、サーバ１０と、システム１００のユーザが使用するユーザ端末２０，２０１～２０Ｎ（Ｎは任意の整数。以下単に「端末２０，２０１～２０Ｎ」という。）とを含む。なお、システム１００の構成はこれに限定されず、単一の端末を複数のユーザが使用する構成としてもよいし、複数のサーバを備える構成としてもよい。

サーバ１０と複数の端末２０，２０１～２０Ｎは、それぞれインターネットなどの通信ネットワーク３０に接続されている。なお、図示しないが、複数の端末２０，２０１～２０Ｎは、通信業者によって管理される基地局と無線通信回線によるデータ通信を行うことによって、通信ネットワーク３０と接続する。

システム１００は、サーバ１０と複数の端末２０，２０１～２０Ｎとを備えることにより、複数のモデルで構成されるキャラクタの外観を変更するための各種処理を実行する。

ここで、モデルとは、ビデオゲームに登場するキャラクタを構成するものを意味する。モデルは、１のキャラクタの部位（例えば、腕や足や胴体）毎に設定可能であることが好適である。モデルの例には、所定の分類毎に設定可能なものがある。所定の分類は、生物学的な区切りに限定されず、例えば、胴と腕を合わせたものを一つの分類とし、手を別の分類とすることがある。また、キャラクタとは、ビデオゲームにおいて登場する人物や動物を意味する。キャラクタは、いわゆるオブジェクトであれば特に限定されず、部位毎に外観を変更できることが好ましい。キャラクタの例には、いわゆるアバターがある。なお、各モデルは、１のアイテムとしてユーザが所有可能に構成されていてもよい。

サーバ１０は、システム１００の管理者によって管理され、複数の端末２０，２０１～２０Ｎに対して各種処理に関する情報を提供するための各種機能を有する。本例において、サーバ１０は、ＷＷＷサーバなどの情報処理装置によって構成され、各種情報を格納する記憶媒体を備える。なお、サーバ１０は、制御部などコンピュータとして各種処理を行うための一般的な構成を備えるが、ここでの説明は省略する。また、システム１００においては、複数の端末２０，２０１～２０Ｎそれぞれにかかる処理負荷を軽減させるといった観点から、各種情報はサーバ１０が管理することが好適である。ただし、サーバ１０がアクセス可能な状態で記憶領域が備えられていればよく、例えば専用の記憶領域がサーバ１０の外部に備えられるようにシステム１００が構成されてもよい。

図２は、サーバ１０の構成の例であるサーバ１０Ａの構成を示すブロック図である。図２に示すように、サーバ１０Ａは、特定部１１（特定機能の一例に相当）と、判定部１２（判定機能の一例に相当）と、決定部１３（決定機能の一例に相当）と、を少なくとも備える。

特定部１１は、少なくとも１のモデルを判定対象として特定する処理を実行する機能を有する。ここで、判定対象とは、ビデオゲームに登場するモデルのうち、所定の判定の対象になるモデルを意味する。判定対象を特定するための構成は特に限定されないが、判定対象とする所定条件を満たしたものを判定対象とする構成が好ましい。このような構成の例には、ユーザにより選択されたモデルを判定対象とする構成がある。

判定部１２は、キャラクタを構成する複数のモデルのうち判定対象に対応する箇所のモデル（以下「変更対象」という。）が判定対象に変更される場合に所定の隣接条件が満たされるかについて、判定対象の形状と変更対象に隣接するモデルの形状とに基づいて判定する機能を有する。ここで、判定対象に対応する箇所とは、判定対象の部位属性と同じ又は代わりになる部位属性を有する箇所を意味する。また、部位属性とは、例えば、腕、脚、手など、どの部位のモデルかを示す属性を意味する。例えば、判定対象が腕を示すモデルである場合、「キャラクタを構成する複数のモデルのうち判定対象に対応する箇所のモデル」は、キャラクタを構成するモデルのうち腕を示すモデル、または腕の代わりになる部位のモデルになる。また、変更対象が判定対象に変更される場合とは、現在キャラクタを構成するモデルのうちの一部のモデルが別のモデルに変更されることを意味する。変更対象が判定対象に変更される場合の例には、手モデルＭＤＬ１を手モデルＭＤＬ２に変更する場合がある。また、隣接条件とは、複数のモデルがぶつかり合う状態（いわゆる、干渉）を引き起こさないための条件である。隣接条件の内容は特に限定されないが、モデルの形状（例えば、大きさ、長さ、形、デザインなど）に関することが好適である。隣接条件の例には、形状Ａは形状Ａと隣接できるという条件がある。隣接条件の他の例には、形状Ｂは、形状Ａ及び形状Ｂと隣接できるという条件がある。なお、隣接条件は、複数の要件で構成されてもよい。また、隣接とは、１のキャラクタを構成する複数種類のモデルのうち、位置関係が隣り合う２つのモデルの関係を意味する。すなわち、本例において、２つのモデルが実際に接点を持たない場合にも隣接するという場合がある。２つのモデルが隣接する例には、２つのモデルが直接的に繋がっていることがある。２つのモデルが隣接する他の例には、他の物体（例えば、キャラクタの腕）を介在して２つのモデルが間接的につながっていることがある。

決定部１３は、判定結果に基づいて、変更対象を判定対象に変更可能かを決定する処理を実行する機能を有する。決定部１３による決定をどのように利用するかについては特に限定されない。決定部１３による決定は、例えば、変更できないモデルを選択できないようにするための処理や、変更できること又は変更できないことを報知するための処理や、モデルを変更するための処理などに利用される。

複数の端末２０，２０１～２０Ｎは、それぞれ、ビデオゲームを行うユーザ（又はプレイヤ）によって管理され、例えば携帯電話端末やＰＤＡ（ＰＥＲＳＯＮＡＬＤｉｇｉｔａｌＡｓｓｉｓｔａｎｔｓ）、携帯型ゲーム装置などのネットワーク配信型のゲームを行うことが可能な通信端末によって構成される。なお、システム１００が含み得る端末の構成は上述した例に限定されず、ユーザがビデオゲームを認識できる構成であればよい。端末の構成の他の例には、スマートウォッチなどの所謂ウェアラブルデバイスや、ウェアラブルデバイスと通信端末等との組み合わせがある。

また、複数の端末２０，２０１～２０Ｎは、それぞれ、通信ネットワーク３０に接続し、サーバ１０との通信を行うことによりビデオゲームを実行するためのハードウェア（例えば、ゲーム画面を表示する表示装置や音声出力装置など）及びソフトウェアを備える。なお、複数の端末２０，２０１～２０Ｎそれぞれは、サーバ１０を介さずに互いに直接通信を行うこともできる構成とされていてもよい。また、複数の端末２０，２０１～２０Ｎは、サーバ１０から送信される情報（例えば、ゲーム画像に関する情報）に基づいて自己の表示装置にゲームの画像を出力する。

次に、本例のシステム１００の動作について説明する。

図３は、システム１００が実行するゲーム関連処理の例を示すフローチャートである。以下、サーバ１０Ａと、端末２０とによりビデオゲームに関する情報の送受信を行う場合を例にして説明する。なお、本例のゲーム関連処理は、ユーザからキャラクタの手のモデルを変更するための変更要求を受信した場合に実行される。

サーバ１０Ａは、ゲーム関連処理において、先ず、判定対象を特定する（ステップＳ１１）。本例において、サーバ１０Ａは、ユーザにより指定された手モデルＭＤＬ１を判定対象として特定する。

サーバ１０Ａは、判定対象を特定すると、隣接条件が満たされるかを判定する（ステップＳ１２）。本例において、サーバ１０Ａは、現在のキャラクタの手モデルＭＤＬ２が手モデルＭＤＬ１に変更されるとした場合に、手モデルＭＤＬ１の形状と、手モデルＭＤＬ２に隣接するモデルの形状と、に基づいて、隣接条件が満たされるかを判定する。

サーバ１０Ａは、判定結果に基づいて、変更対象を判定対象に変更可能かを決定する（ステップＳ１３）。本例において、サーバ１０Ａは、判定結果が隣接条件を満たすとするものである場合、手モデルＭＤＬ２を手モデルＭＤＬ１に変更できることを決定する。一方で、本例において、サーバ１０Ａは、判定結果が隣接条件を満たさないとするものである場合、手モデルＭＤＬ２を手モデルＭＤＬ１に変更できないことを決定する。さらに、サーバ１０Ａは、決定に関する情報を端末２０に送信する。

図４は、ゲーム関連処理におけるサーバ１０Ａ側の動作の例を示すフローチャートである。ここでは、システム１００におけるサーバ１０Ａの動作について改めて説明する。

サーバ１０Ａは、ゲーム関連処理において、先ず、判定対象を特定し（ステップＳ１０１）、隣接条件が満たされるかを判定し（ステップＳ１０２）、変更対象を判定対象に変更可能かを決定し（ステップＳ１０３）、ここでの処理を終了する。

図５は、端末２０がゲーム関連処理を実行する場合の端末２０の動作の例を示すフローチャートである。以下、端末２０が、単体でゲーム関連処理を実行する場合を例にして説明する。なお、端末２０の構成については、サーバ１０Ａの構成と同様の機能を備えるものであるため、重複説明を避ける観点から記載を省略する。

端末２０は、ゲーム関連処理において、先ず、判定対象を特定し（ステップＳ２０１）、隣接条件が満たされるかを判定し（ステップＳ２０２）、変更対象を判定対象に変更可能かを決定し（ステップＳ２０３）、ここでの処理を終了する。

以上に説明したように、第１の実施形態の一側面として、ビデオゲームの進行を制御するシステム１００が、特定部１１と、判定部１２と、決定部１３と、を少なくとも備え、少なくとも１のモデルを判定対象として特定し、変更対象が判定対象に変更される場合に所定の隣接条件が満たされるかについて、判定対象の形状と変更対象に隣接するモデルの形状とに基づいて判定し、判定結果に基づいて、変更対象を判定対象に変更可能かを決定し、より処理負荷が小さい構成でキャラクタの外観を損なわずにキャラクタの外観を変更する。

特に、システム１００は、隣接条件を満たすかについて、隣接するモデルの互いの形状に基づいて判断する。すなわち、システム１００において、隣接するモデルの互いの形状が隣接条件を満たせば、その隣接条件を満たすモデルに変更することができる。このように構成されていることで、衝突するかどうかの判定（つまり、モデルどうしのコリジョン判定）を行うよりも、より処理負荷が小さい構成でキャラクタの外観を損なわずにキャラクタの外観を変更する。

［第２の実施形態］
図６は、サーバ１０の例であるサーバ１０Ｂの構成を示すブロック図である。本例において、サーバ１０Ｂは、特定部１１と、判定部１２Ｂ（判定機能の一例に相当）と、決定部１３と、を少なくとも備える。

判定部１２Ｂは、各モデルに設定されている形状のタイプを参照して、所定の隣接条件が満たされるかを判定する処理を実行する機能を有する。ここで、各モデルに形状のタイプを設定するための構成は特に限定されないが、モデルに関する情報を記憶する際に形状のタイプを含んで記憶する構成とされていることが好適である。また、形状のタイプを参照して判定する構成の例には、判定対象のタイプと、変更対象に隣接するモデルの形状のタイプと、隣接可能となるタイプを定義した情報と、に基づいて判定する構成がある。なお、各種の情報は所定の記憶領域に格納されている構成とされていればよい。

図７は、システム１００が実行するゲーム関連処理の例を示すフローチャートである。以下、サーバ１０Ｂ側の動作を例にして説明する。なお、端末２０（サーバ１０Ｂの構成と同様の機能を備える端末２０）が単体でゲーム関連処理を実行する場合についての説明、及び既に説明している箇所については、重複説明を避ける観点から記載を省略する。

サーバ１０Ｂは、判定対象を特定すると、各モデルに設定されている形状のタイプを参照して、所定の隣接条件が満たされるかを判定する（ステップＳ２－１１）。本例において、サーバ１０Ｂは、手モデルＭＤＬ２が手モデルＭＤＬ１に変更される場合に、手モデルＭＤＬ１の形状のタイプと、手モデルＭＤＬ２に隣接するモデルの形状のタイプと、隣接可能となるタイプを定義した情報と、に基づいて、隣接条件が満たされるかを判定する。

以上に説明したように、第２の実施形態の一側面として、システム１００が、特定部１１と、判定部１２Ｂと、決定部１３と、を少なくとも備え、各モデルに設定されている形状のタイプを参照して、所定の隣接条件が満たされるかを判定し、より処理負荷が小さい構成でキャラクタの外観を損なわずにキャラクタの外観を変更する。

すなわち、モデルそれぞれが形状のタイプを有することで、様々な形状のモデルを採用したビデオゲームであっても、キャラクタの外観を損なわずにキャラクタの外観を変更する場合に、衝突判定をする場合に比べて処理負荷を小さくすることができる。換言すれば、システム１００は、キャラクタの外観を損なわずにキャラクタの外観を変更するビデオゲームにおいて、モデルの多様化を従来よりも小さな処理負荷で実現できる。また、新たなモデルの追加する場合において、従来のモデルの情報を書き換えることなく対応できるようになるため、システム１００は、モデル設計の自由度を従来よりも小さな処理負荷で向上できる。

［第３の実施形態］
図８は、サーバ１０の例であるサーバ１０Ｃの構成を示すブロック図である。本例において、サーバ１０Ｃは、特定部１１と、判定部１２Ｃ（判定機能の一例に相当）と、決定部１３と、を少なくとも備える。

判定部１２Ｃは、各モデルに設定されている他のモデルと隣接する部分に関するタイプ（以下「隣接部分タイプ」という。）を参照して、所定の隣接条件が満たされるかを判定する処理を実行する機能を有する。ここで、各モデルに隣接部分タイプを設定するための構成は特に限定されないが、モデルに関する情報を記憶する際に隣接部分タイプを含んで記憶する構成とされていることが好適である。また、隣接部分タイプを参照して判定する構成の例には、判定対象の隣接部分タイプと、変更対象に隣接するモデルの隣接部分タイプと、隣接可能となる隣接部分タイプを定義した情報と、に基づいて判定する構成がある。なお、各種の情報は所定の記憶領域に格納されている構成とされていればよい。

図９は、システム１００が実行するゲーム関連処理の例を示すフローチャートである。以下、サーバ１０Ｃ側の動作を例にして説明する。なお、端末２０（サーバ１０Ｃの構成と同様の機能を備える端末２０）が単体でゲーム関連処理を実行する場合についての説明、及び既に説明している箇所については、重複説明を避ける観点から記載を省略する。

サーバ１０Ｃは、判定対象を特定すると、各モデルに設定されている隣接部分タイプを参照して、所定の隣接条件が満たされるかを判定する（ステップＳ２－１１）。本例において、サーバ１０Ｂは、手モデルＭＤＬ２が手モデルＭＤＬ１に変更される場合に、手モデルＭＤＬ１の隣接部分タイプと、手モデルＭＤＬ２に隣接するモデルの隣接部分タイプと、隣接可能となる隣接部分タイプを定義した情報と、に基づいて、隣接条件が満たされるかを判定する。

以上に説明したように、第３の実施形態の一側面として、システム１００が、特定部１１と、判定部１２Ｃと、決定部１３と、を少なくとも備え、各モデルに設定されている隣接部分タイプを参照して、所定の隣接条件が満たされるかを判定し、より処理負荷が小さい構成でキャラクタの外観を損なわずにキャラクタの外観を変更する。

すなわち、モデルそれぞれが隣接部分タイプを有することで、様々な形状のモデルを採用したビデオゲームであっても、キャラクタの外観を損なわずにキャラクタの外観を変更する場合に、衝突判定をする場合に比べて処理負荷を小さくすることができる。システム１００は、キャラクタの外観を損なわずにキャラクタの外観を変更するビデオゲームにおいて、モデルの多様化を従来よりも小さな処理負荷で実現できる。また、新たなモデルの追加する場合において、従来のモデルの情報を書き換えることなく対応できるようになるため、システム１００は、モデル設計の自由度を従来よりも小さな処理負荷で向上できる。

［第４の実施形態］
図１０は、サーバ１０の例であるサーバ１０Ｄの構成を示すブロック図である。本例において、サーバ１０Ｄは、特定部１１と、判定部１２と、決定部１３と、調整部１５（調整機能の一例に相当）と、を少なくとも備える。

調整部１５は、モデルに設定された情報に基づいて、隣接するモデルの形状を調整する処理を実行する機能を有する。隣接するモデルの形状を調整するとは、モデルどうしが干渉しないように隣接するモデルの少なくとも一部の形状を変えることを意味する。モデルの形状を調整する構成は特に限定されないが、隣接するモデルの少なくとも一方に設定されたテーパ値を参照して、調整対象となるモデルの形状を変える構成が好適である。このような構成の例には、隣接するモデルのうちキャラクタの中枢側に位置するモデルの接合部分の形状を末端部分に向かって徐々にテーパリングする構成がある。また、モデルの形状を調整する構成の他の例には、モデルの所定の基準位置（調整用の基準位置）が一致するように一方または互いのモデルの形状を調整する構成がある。なお、隣接するモデルの少なくとも一方にテーパ値が設定された構成とするための構成は特に限定されない。このような構成の例には、キャラクタが、１つの胴体モデルと、２つの手モデルと、２つの足モデルとにより構成されるとともに、各手モデル及び各足モデルにテーパ値が設定されている構成がある。

図１１は、システム１００が実行する調整処理の例を示すフローチャートである。以下、サーバ１０Ｄ側の動作を例にして説明する。なお、端末２０（サーバ１０Ｄの構成と同様の機能を備える端末２０）が単体で調整処理を実行する場合についての説明、及び既に説明している箇所については、重複説明を避ける観点から記載を省略する。なお、本例において、手モデルの変更が行われた場合を例にして説明を行う。

サーバ１０Ｄは、調整処理において、先ず、モデルに設定された情報に基づいて、隣接するモデルの形状を調整し（ステップＳ４－１１）、ここでの処理を終了する。本例において、サーバ１０Ｄは、胴体モデルの接合部分（つまり、手モデルと足モデルとに繋がる部分）の形状を、２つの手モデル及び２つの足モデルそれぞれに設定された情報に基づいて、末端部分に向かって徐々にテーパリングする。

以上に説明したように、第４の実施形態の一側面として、システム１００が、特定部１１と、判定部１２と、決定部１３と、調整部１５と、を少なくとも備え、モデルに設定された情報に基づいて、隣接するモデルの形状を調整し、より処理負荷が小さい構成でキャラクタの外観を損なわずにキャラクタの外観を変更する。

すなわち、システム１００は、変更可能と判定されたモデルについて、隣接する他のモデルに干渉することを許容しておきつつ、モデルに設定した情報に基づいて調整することで、外観を損なわずにキャラクタの外観の変更を実現する構成とされている。換言すれば、システム１００は、キャラクタの外観が損なわれないシステムを提供するにあたり、隣接条件を満たすモデルを絞り込みすぎずに（つまり、モデル設計の制約を大きくせずに）、モデルに設定された情報を利用して柔軟な対応を可能にする。したがって、システム１００は、より処理負荷が小さい構成でキャラクタの外観を損なわずにキャラクタの外観を変更し、モデルの組み合わせを多様化できる。

［第５の実施形態］
本例において、システム１００は、複数のモデルで構成されるキャラクタ（例えば、アバター）の外観を変更できる。キャラクタの所有者は、様々なモデルを組み合わせることができ、キャラクタをカスタマイズすることを楽しめる。

図１２は、キャラクタを構成するモデルの概念を説明するための説明図である。図１２に示すように、キャラクタ１０００は、顔モデル１０１０と、髪モデル１０２０と、胴体モデル１０３０と、手モデル１０４０と、足モデル１０５０と、の５つの種類のモデルで構成される。ここで、胴体モデル１０３０はどこの部位までを含むかが予め定められている。具体的には、腕（手首まで）、胸、腹、首、及び脚（足首まで）が胴体モデル１０３０を構成する部位になる。一方で、手モデル１０４０及び足モデル１０５０については、構成する部位のタイプが複数タイプある。手モデル１０４０には、構成する部位を、手の指から腕までとするものや、手の指から肘までとするものなどがある。また、足モデル１０５０も同様に、足モデル１０５０には、構成する部位を、足の指から足首までとするものや、足の指から膝までの範囲のものなどがある。

なお、図１２では、裸の状態のキャラクタが示されている。つまり、服やアイテムなどが反映されておらず、キャラクタを構成するモデルはキャラクタの素の状態を示すモデルとなっている。しかしながら、本例でいうモデルには、例えば、服を着用した胴体モデルのように、服やアイテムが反映されたものが含まれるものとする。

本例においては、特に、胴体モデルと手モデルとが組み合わせることができるか、または胴体モデルと足モデルとが組み合わせることができるかが判定される。判定に用いる条件は２つある。１つは、胴体モデルのデザインと、胴体モデルに接続されるモデルの長さに関する条件（以下「第１隣接条件」という。）である。もう１つは、胴体モデルと胴体モデルに接続されるモデルとの接続箇所における、両モデルのサイズに関する条件（以下「第２隣接条件」という。）である。第１隣接条件及び第２隣接条件が満たされると、モデルの変更が許容される。

図１３は、手モデルと胴体モデルとの組み合わせの概念を示す概念図である。図１３の左側に示すように、手モデル１０４０は、長さの観点から複数段階に分類される。本例において、手モデル１０４０は、ショートモデル１０４１、ミドルモデル１０４２、及びロングモデル１０４３に分類される。図１３の右側に示すように、手首までを含む胴体モデル１０３０と、分類された長さの手モデル１０４０が組み合わさる。ここで、必ず図１３の右側のように組み合わすことができるとは限らない。上述の通り、第１隣接条件を満たすことが求められる。

図１４は、第１隣接条件を示す情報の格納状態の例について説明するための説明図である。各項目に対する対応関係がマトリクス状に規定される。マトリクス内において丸印がついている組み合わせは、第１隣接条件を満たすことを示す。すなわち、具体的には、ロングモデルに対応可能な胴体モデル（Ｌ対応胴体）については、ショートモデル（Ｓ手モデル）、ミドルモデル（Ｍ手モデル）、ロングモデル（Ｌ手モデル）のいずれにも対応可能なことを意味する。一方で、マトリクス内においてバツ印がついている組み合わせは、第１隣接条件を満たさないことを示す。すなわち、具体的には、ショートモデルに対応可能な胴体モデル（Ｓ対応胴体）については、ミドルモデル（Ｍ手モデル）、ロングモデル（Ｌ手モデル）については対応していないことを意味する。

図１５は、胴体モデルと手モデルとの接続箇所の概念を示す概念図である。図１５の上段に示すように、胴体モデルと手モデルは、それぞれ、ラージサイズのモデル（１０３５，１０４５）と、スモールサイズのモデル（１０３７，１０４７）と、を含む。ここでいうサイズは、接続箇所のサイズを意味し、隣接部分タイプに相当する。図１５の下段に示すように、サイズが同じものどうしが接続する場合もあれば、互いに異なるサイズのモデルが組み合わさる場合がある。ここで、必ず図１５の下段のように組み合わさるとは限らない。上述の通り、第２隣接条件を満たすことが求められる。

図１６は、第２隣接条件を示す情報の格納状態の例について説明するための説明図である。各項目に対する対応関係がマトリクス状に規定される。マトリクス内において丸印がついている組み合わせは、第２隣接条件を満たすことを示す。すなわち、具体的には、胴体モデルがスモールサイズ（Ｓ腕部胴体）である場合、手モデルのサイズはスモールサイズ（Ｓサイズ手）でもラージサイズ（Ｌサイズ手）でも対応可能であることを意味する。一方で、マトリクス内においてバツ印がついている組み合わせは、第２隣接条件を満たさないことを示す。すなわち、具体的には、胴体モデルがラージサイズ（Ｌ腕部胴体）である場合、手モデルのサイズはラージサイズの手モデル（Ｌサイズ手）は対応しないことを意味する。

以上、図１２、図１３、図１４、図１５、及び図１６を用いて、手モデルと胴体モデルとの関係を例に、第１隣接条件及び第２隣接条件を説明した。次に各モデルに関する情報について説明する。本例において、対応付けされる情報は、部位ごとに異なる。胴体モデルに対しては、どの長さのモデルに対応できるかを示す情報と、接続箇所のサイズを示す情報と、が少なくとも対応付けされている。このような情報が対応付けされていることで、第１隣接条件が満たされるか及び第２隣接条件が満たされるかを判定できる。また、手モデルに対しては、長さのタイプに関する情報と、接続箇所のサイズを示す情報とが少なくとも対応付けされている。このような情報が対応付けされていることで、第１隣接条件が満たされるか及び第２隣接条件が満たされるかを判定できる。

なお、足モデルと胴体モデルとの関係は、手モデルと胴体モデルとの関係と同様であるため、ここでの説明は省略する。

次に、システム１００の構成について説明する。

システム１００は、サーバ１０Ｚと、ユーザ端末２０，２０１～２０Ｎ（Ｎは任意の整数。以下単に「端末２０，２０１～２０Ｎ」という。）と、を含む。なお、システム１００の構成はこれに限定されず、単一の端末を複数のユーザが使用する構成としてもよい。

サーバ１０Ｚは、ビデオゲームを進行するための各種機能を有する。例えば、サーバ１０Ｚは、仮想空間におけるキャラクタに関する各種情報を処理する機能を有する。また、サーバ１０Ｚは、複数の端末２０，２０１～２０Ｎに対してゲーム画像を表示するための情報を提供するための各種機能を有する。また、サーバ１０Ｚは、通信ネットワーク３０を介して端末２０，２０１～２０Ｎなどの外部装置と通信を行うための各種機能を有する。本例においてサーバ１０Ｚは、ＷＷＷサーバなどの情報処理装置によって構成され、各種情報を格納する記憶媒体を備える。なお、サーバ１０Ｚが、アクセス可能な状態で記憶領域が備えられていてもよい。例えば、記憶領域が、外部に備えられるようにシステム１００が構成されてもよい。

図１７は、サーバ１０の例であるサーバ１０Ｚの構成を示すブロック図である。本例において、端末２０Ｚは、特定部１１Ｚ（特定機能の一例に相当）と、判定部１２Ｚ（判定機能の一例に相当）と、決定部１３Ｚ（決定機能の一例に相当）と、調整部１５Ｚ（調整機能の一例に相当）と、を少なくとも備える。

特定部１１Ｚは、少なくとも１のモデルを判定対象として特定する処理を実行する機能を有する。本例では、ユーザからの変更要求における変更する側のモデルを判定対象とする構成がある。

判定部１２Ｚは、判定対象と変更対象に隣接するモデルが隣接条件を満たすかを判定する処理を実行する機能を有する。隣接条件には、第１隣接条件と第２隣接条件が含まれる。すなわち、判定対象と変更対象に隣接するモデルとの関係が、第１隣接条件と第２隣接条件を満たす関係かを判定する。ここで、隣接条件は、モデルどうしの干渉を許容しないことを定めた条件ではなく、一定範囲の干渉を許容する条件とされていることが好適である。また、一定範囲の干渉は、後述する調整部１５Ｚによる処理により調整可能な程度であることが好適である。

決定部１３は、判定結果に基づいて、変更対象を判定対象に変更可能かを決定する処理を実行する機能を有する。本例においては、さらに決定部１３は、変更できると決定した場合に、モデルを変更する処理を実行する機能を有する。一方で、さらに、決定部１３は、変更できないと決定した場合に、モデルを選択できないようにする処理を実行する機能を有する。

調整部１５Ｚは、モデルに設定された情報に基づいて、隣接するモデルの形状を調整する処理を実行する機能を有する。本例において、調整部１５Ｚは、手モデルまたは足モデルに設定されたテーパ値を参照して、連続した面をもつ胴体部分との不整合を起こさせないように、胴体モデルの他のモデルと隣接する箇所（または接続箇所）を末端部分に向かって徐々にテーパリングする。すなわち、手モデルと胴体モデルとが隣接する場合には、胴体モデルにおける腕部分が細くなる。末端部分か否かの定義は、頂点カラーなどを用いる。また、本例において、太い又は細いに関する定義は、頂点法線方向の正負のオフセットで対応する。また、本例の調整部１５Ｚは、シェーダを使用してＧＰＵ上で頂点処理を行う。なお、モデルに設定されるテーパ値は、０の場合がある。この場合には、調整した結果も調整していないものと同じ結果になる。

また、複数の端末２０，２０１～２０Ｎは、それぞれ、通信ネットワーク３０に接続し、サーバ１０Ｚとの通信を行うことによりビデオゲームを実行するためのハードウェア（例えば、ゲーム画面を表示する表示装置や音声出力装置など）及びソフトウェアを備える。なお、複数の端末２０，２０１～２０Ｎそれぞれは、サーバ１０Ｚを介さずに互いに直接通信を行うこともできる構成とされていてもよい。また、複数の端末２０，２０１～２０Ｎは、サーバ１０Ｚから送信される情報（例えば、ゲーム画像に関する情報）に基づいて自己の表示装置にゲームの画像を出力する。

次に、本例のシステム１００の動作について説明する。

図１８は、システム１００が実行するゲーム関連処理の例を示すフローチャートである。以下、サーバ１０Ｚの動作を例にして説明する。なお、端末２０（サーバ１０Ｚの構成と同様の機能を備える端末２０）が単体でゲーム関連処理を実行する場合についての説明、及び既に説明している箇所については、重複説明を避ける観点から記載を省略する。本例のゲーム関連処理は、ユーザからの手モデルの変更要求を受け付けた端末２０から変更要求に関する情報を受信した場合に実行される。

サーバ１０Ｚは、ゲーム関連処理において、先ず、判定対象を特定する（ステップＳ５－１１）。本例において、サーバ１０Ｚは、ユーザにより指定された手モデルＭＤＬ１を判定対象として特定する。

次いで、サーバ１０Ｚは、第１隣接条件が満たされているか否かを判定する（ステップＳ５－１２）。本例において、サーバ１０Ｚは、手モデルＭＤＬ１の長さと、胴体モデルＭＤＬ９が対応できる長さと、第１隣接条件を示す情報と、に基づいて、第１隣接条件が満たされるかどうかを判定する。

サーバ１０Ｚは、第１隣接条件が満たされないと判定した場合（ステップＳ５－１２のＮ）、変更できないことを決定する（ステップＳ５－１３）。次いで、サーバ１０Ｚは、変更できないことを決定すると、変更できないという決定に基づく各種処理を実行し（ステップＳ５－１４）、ここでの処理を終了する。本例において、サーバ１０Ｚは、変更できないことを示す情報を表示する画像情報を端末２０に送信する。

一方で、サーバ１０Ｚは、第１隣接条件が満たされると判定した場合（ステップＳ５－１２のＹ）、第２隣接条件が満たされているか否かを判定する（ステップＳ５－１５）。本例において、サーバ１０Ｚは、手モデルＭＤＬ１の接続箇所のサイズと、胴体モデルＭＤＬ９の手モデルＭＤＬ１との接続箇所のサイズと、第２隣接条件を示す情報と、に基づいて、第２隣接条件が満たされるかどうかを判定する。

サーバ１０Ｚは、第２隣接条件が満たされないと判定した場合（ステップＳ５－１５のＮ）、変更できないことを決定する（ステップＳ５－１３）。一方で、サーバ１０Ｚは、第２隣接条件が満たされると判定した場合（ステップＳ５－１５のＹ）、変更できることを決定する（ステップＳ５－１６）。

次いで、サーバ１０Ｚは、変更できることを決定すると、モデルを調整する（ステップＳ５－１７）。本例において、サーバ１０Ｚは、手モデルＭＤＬ１に設定されているテーパ値を参照して、手モデルＭＤＬ１と接続する胴体モデルＭＤＬ９の接続箇所について末端部分に向かい徐々にテーパリングする。

サーバ１０Ｚは、モデルを調整すると、調整したモデルに変更し（ステップＳ５－１８）、ここでの処理を終了する。本例において、サーバ１０Ｚは、キャラクタのモデルの手の部位を、手モデルＭＤＬ１に変更してキャラクタ情報を更新するとともに、かつ胴体モデルＭＤＬ９のテーパリング結果キャラクタ情報に反映する。また、本例において、サーバ１０Ｚは、更新及び反映した情報を端末２０に送信する。なお、本例において、調整を行うタイミングを、変更できることを決定した後としたが、このような構成には限られない。例えば、システム１００は、ゲーム画像として表示するデータを生成する際に調整を行う構成とされていてもよい。つまり、システム１００は、調整処理を別途実行する構成とされていてもよい。

以上に説明したように、第５の実施形態の一側面として、ビデオゲームの進行を制御するシステム１００が、特定部１１Ｚと、判定部１２Ｚと、決定部１３Ｚと、を少なくとも備え、少なくとも１のモデルを判定対象として特定し、変更対象が判定対象に変更される場合に所定の隣接条件が満たされるかについて、判定対象の形状と変更対象に隣接するモデルの形状とに基づいて判定し、判定結果に基づいて、変更対象を判定対象に変更可能かを決定し、より処理負荷が小さい構成でキャラクタの外観を損なわずにキャラクタの外観を変更する。

また、第５の実施形態の一側面として、システム１００が、特定部１１Ｚと、判定部１２Ｚと、決定部１３Ｚと、を少なくとも備え、各モデルに設定されている形状のタイプを参照して、所定の隣接条件が満たされるかを判定し、より処理負荷が小さい構成でキャラクタの外観を損なわずにキャラクタの外観を変更する。

また、第５の実施形態の一側面として、システム１００が、特定部１１Ｚと、判定部１２Ｚと、決定部１３Ｚと、を少なくとも備え、各モデルに設定されている隣接部分タイプを参照して、所定の隣接条件が満たされるかを判定し、より処理負荷が小さい構成でキャラクタの外観を損なわずにキャラクタの外観を変更する。

また、第５の実施形態の一側面として、システム１００が、特定部１１Ｚと、判定部１２Ｚと、決定部１３Ｚと、調整部１５Ｚと、を少なくとも備え、モデルに設定された情報に基づいて、隣接するモデルの形状を調整し、より処理負荷が小さい構成でキャラクタの外観を損なわずにキャラクタの外観を変更する。

なお、上述した実施形態では特に言及していないが、システム１００は、モデル毎に変更可能なモデルのタイプが対応付けされた情報を参照して判定する構成とされていてもよい。また、他の例として、モデル毎にモデルの形状を分類した情報と、隣接可能となる組み合わせを定義した情報と、変更する側と変更される側の形状と、を参照して変更が許容されるかを判定する構成とされていてもよい。また、モデルの形状に基づくとは、モデルの姿かたちに基づくことを意味する。形状に基づく構成の例には、形、長さ、及び大きさのうち何れか１つ以上の要素に基づく構成がある。

なお、上述した実施形態では特に言及していないが、モデルに設定されるテーパ値が０の場合においても調整を行う構成としているが、このような構成には限られない。例えば、システム１００は、テーパ値が０より大きいかを判定し、０より大きい場合にのみ調整を行う構成とされていてもよい。

なお、上述した実施形態では特に言及していないが、本例では変更箇所について調整を行う構成としているが、キャラクタ情報を更新するに際に、すべてのモデルのテーパ値を反映させるようにモデルを調整する構成とされていてもよい。

以上に説明したように、本願の各実施形態により１又は２以上の不足が解決される。なお、夫々の実施形態による効果は、非限定的な効果又は効果の一例である。

なお、上述した各実施形態では、複数のユーザ端末２０，２０１～２０Ｎとサーバ１０は、自己が備える記憶装置に記憶されている各種制御プログラム（例えば、プログラム）に従って、上述した各種の処理を実行する。特に図示しない制御部が、各部で実行される処理を実行する機能を有する構成とされていてもよい。

また、システム１００の構成は上述した各実施形態の例として説明した構成に限定されず、例えばユーザ端末が実行する処理として説明した処理の一部又は全部をサーバ１０が実行する構成としてもよいし、サーバ１０が実行する処理として説明した処理の一部又は全部を複数のユーザ端末２０，２０１～２０Ｎの何れか（例えば、ユーザ端末２０）が実行する構成としてもよい。また、サーバ１０が備える記憶部の一部又は全部を複数のユーザ端末２０，２０１～２０Ｎの何れかが備える構成としてもよい。すなわち、システム１００におけるユーザ端末２０とサーバ１０のどちらか一方が備える機能の一部又は全部を、他の一方が備える構成とされていてもよい。

［付記］
上述した実施形態の説明は、少なくとも下記発明を、当該発明の属する分野における通常の知識を有する者がその実施をすることができるように記載した。
［１］
複数のモデルで構成されるキャラクタの外観を変更する機能をユーザ端末に実現させるためのプログラムであって、
前記ユーザ端末に、
少なくとも１のモデルを判定対象として特定する特定機能と、
前記キャラクタを構成する複数のモデルのうち前記判定対象に対応する箇所のモデル（以下「変更対象」という。）が前記判定対象に変更される場合に所定の隣接条件が満たされるかについて、前記判定対象の形状と前記変更対象に隣接するモデルの形状とに基づいて判定する判定機能と、
該判定機能よる判定結果に基づいて、前記変更対象を前記判定対象に変更可能かを決定する決定機能と、を
実現させるためのプログラム。
［２］
前記判定機能にて、各モデルに設定されている形状のタイプを参照して、前記所定の隣接条件が満たされるかを判定する機能を
実現させるための［１］記載のプログラム。
［３］
前記判定機能にて、各モデルに設定されている他のモデルと隣接する部分に関するタイプを参照して、前記所定の隣接条件が満たされるかを判定する機能を
実現させるための［１］または［２］記載のプログラム。
［４］
前記ユーザ端末に、
モデルに設定された情報に基づいて、隣接するモデルの形状を調整する調整機能を
実現させるための［１］から［３］のうち何れかに記載のプログラム。
［５］
前記判定機能では、モデル毎の大きさを含むモデル情報を記憶する記憶領域を参照して、前記所定の隣接条件が満たされるか判定する機能を
実現させるための［１］から［４］のうち何れかに記載のプログラム。
［６］
前記判定機能では、前腕まで含む胴体モデルに関するモデル情報と、胴体モデルに含まれる部位と一部が重なるモデルを少なくとも含む手モデルに関するモデル情報と、を記憶する記憶領域を参照して、前記所定の隣接条件が満たされるか判定する機能を
実現させるための［１］から［５］のうち何れかに記載のプログラム。
［７］
前記判定機能では、足首まで含む胴体モデルに関するモデル情報と、胴体モデルに含まれる部位と一部が重なるモデルを少なくとも含む足モデルに関するモデル情報と、を記憶する記憶領域を参照して、前記所定の隣接条件が満たされるか判定する機能を
実現させるための［１］から［６］のうち何れかに記載のプログラム。
［８］
［１］から［７］のうち何れかに記載のプログラムが前記ユーザ端末に実現させる機能のうち少なくとも１つの機能を、当該ユーザ端末と通信可能なサーバに実現させるためのプログラム。
［９］
［１］から［８］のうち何れかに記載のプログラムがインストールされたユーザ端末。
［１０］
複数のモデルで構成されるキャラクタの外観を変更するシステムであって、
少なくとも１のモデルを判定対象として特定する特定手段と、
前記キャラクタを構成する複数のモデルのうち前記判定対象に対応する箇所のモデル（以下「変更対象」という。）が前記判定対象に変更される場合に所定の隣接条件が満たされるかについて、前記判定対象の形状と前記変更対象に隣接するモデルの形状とに基づいて判定する判定手段と、
該判定手段よる判定結果に基づいて、前記変更対象を前記判定対象に変更可能かを決定する決定手段と、を含む
ことを特徴するシステム。
［１１］
前記サーバが、前記特定手段と、前記判定手段と、前記決定手段と、を含み、
前記ユーザ端末が、前記サーバから送信された前記ビデオゲームの進行を示すゲーム画像を表示するための画像情報に基づいて、表示装置の表示画面にゲーム画像を出力する表示手段と、を含む
［１０］記載のシステム。
［１２］
複数のモデルで構成されるキャラクタの外観を変更する機能をユーザ端末に実現させるためのプログラムであって、
少なくとも１のモデルを判定対象として特定する特定機能と、
前記キャラクタを構成する複数のモデルのうち前記判定対象に対応する箇所のモデル（以下「変更対象」という。）が前記判定対象に変更される場合に所定の隣接条件が満たされるかについて、前記判定対象の形状と前記変更対象に隣接するモデルの形状とに基づいて判定する判定機能と、
該判定機能よる判定結果に基づいて、前記変更対象を前記判定対象に変更可能かを決定する決定機能と、を
備えるサーバから送信された前記ビデオゲームの進行を示すゲーム画像を表示するための情報に基づいて、装置の表示画面にゲーム画像を出力する出力機能をユーザ端末に
実現させるためのプログラム。
［１３］
複数のモデルで構成されるキャラクタの外観を変更する機能をサーバに実現させるためのプログラムであって、
前記サーバに、
少なくとも１のモデルを判定対象として特定する特定機能と、
前記キャラクタを構成する複数のモデルのうち前記判定対象に対応する箇所のモデル（以下「変更対象」という。）が前記判定対象に変更される場合に所定の隣接条件が満たされるかについて、前記判定対象の形状と前記変更対象に隣接するモデルの形状とに基づいて判定する判定機能と、
該判定機能よる判定結果に基づいて、前記変更対象を前記判定対象に変更可能かを決定する決定機能と、を
実現させるためのプログラム。
［１４］
複数のモデルで構成されるキャラクタの外観を変更する方法であって、
少なくとも１のモデルを判定対象として特定する特定処理と、
前記キャラクタを構成する複数のモデルのうち前記判定対象に対応する箇所のモデル（以下「変更対象」という。）が前記判定対象に変更される場合に所定の隣接条件が満たされるかについて、前記判定対象の形状と前記変更対象に隣接するモデルの形状とに基づいて判定する判定処理と、
該判定機能よる判定結果に基づいて、前記変更対象を前記判定対象に変更可能かを決定する決定処理と、を含む
ことを特徴とする方法。
［１５］
通信ネットワークと、サーバと、ユーザ端末とを備え、複数のモデルで構成されるキャラクタの外観を変更する方法であって、
少なくとも１のモデルを判定対象として特定する特定処理と、
前記キャラクタを構成する複数のモデルのうち前記判定対象に対応する箇所のモデル（以下「変更対象」という。）が前記判定対象に変更される場合に所定の隣接条件が満たされるかについて、前記判定対象の形状と前記変更対象に隣接するモデルの形状とに基づいて判定する判定処理と、
該判定機能よる判定結果に基づいて、前記変更対象を前記判定対象に変更可能かを決定する決定処理と、を含む
ことを特徴とする方法。

本発明の実施形態の一つによれば、複数のモデルで構成されるキャラクタの外観を変更するビデオゲームに有用である。

１０サーバ
１１特定部
１２判定部
１３決定部
１５調整部
２０，２０１～２０Ｎユーザ端末
３０通信ネットワーク
１００システム

Claims

複数のモデルで構成されるキャラクタの外観を変更する機能をユーザ端末に実現させるためのプログラムであって、
前記ユーザ端末に、
少なくとも１のモデルを判定対象として特定する特定機能と、
前記キャラクタを構成する複数のモデルのうち前記判定対象に対応する箇所のモデル（以下「変更対象」という。）が前記判定対象に変更される場合に、複数の前記モデルがぶつかり合う状態を引き起こさないための形状に関する条件である所定の隣接条件が満たされるかについて、前記判定対象の形状と前記変更対象に隣接するモデルの形状とに基づいて判定する判定機能と、
該判定機能よる判定結果に基づいて、前記変更対象を前記判定対象に変更可能かを決定する決定機能と、
モデルに設定された情報のうち少なくともテーパ値の情報に基づいて、隣接するモデル同士が干渉しないように、隣接するモデルのうち少なくとも一方のモデルにおいて他方のモデルと隣接する箇所の形状を前記テーパ値の大きさに応じた調整量となるようにテーパリングすることで当該モデルの形状を調整する調整機能とを
実現させるためのプログラム。
前記判定機能にて、各モデルに設定されている形状のタイプを参照して、前記所定の隣接条件が満たされるかを判定する機能を
実現させるための請求項１記載のプログラム。
前記判定機能にて、各モデルに設定されている他のモデルと隣接する部分に関するタイプを参照して、前記所定の隣接条件が満たされるかを判定する機能を
実現させるための請求項１又は請求項２記載のプログラム。
複数のモデルで構成されるキャラクタの外観を変更するシステムであって、
少なくとも１のモデルを判定対象として特定する特定手段と、
前記キャラクタを構成する複数のモデルのうち前記判定対象に対応する箇所のモデル（以下「変更対象」という。）が前記判定対象に変更される場合に、複数の前記モデルがぶつかり合う状態を引き起こさないための形状に関する条件である所定の隣接条件が満たされるかについて、前記判定対象の形状と前記変更対象に隣接するモデルの形状とに基づいて判定する判定手段と、
該判定手段よる判定結果に基づいて、前記変更対象を前記判定対象に変更可能かを決定する決定手段と、
モデルに設定された情報のうち少なくともテーパ値の情報に基づいて、隣接するモデル同士が干渉しないように、隣接するモデルのうち少なくとも一方のモデルにおいて他方のモデルと隣接する箇所の形状を前記テーパ値の大きさに応じた調整量となるようにテーパリングすることで当該モデルの形状を調整する調整手段とを含む
ことを特徴するシステム。
複数のモデルで構成されるキャラクタの外観を変更する機能をサーバに実現させるためのプログラムであって、
前記サーバに、
少なくとも１のモデルを判定対象として特定する特定機能と、
前記キャラクタを構成する複数のモデルのうち前記判定対象に対応する箇所のモデル（以下「変更対象」という。）が前記判定対象に変更される場合に、複数の前記モデルがぶつかり合う状態を引き起こさないための形状に関する条件である所定の隣接条件が満たされるかについて、前記判定対象の形状と前記変更対象に隣接するモデルの形状とに基づいて判定する判定機能と、
該判定機能よる判定結果に基づいて、前記変更対象を前記判定対象に変更可能かを決定する決定機能と、
モデルに設定された情報のうち少なくともテーパ値の情報に基づいて、隣接するモデル同士が干渉しないように、隣接するモデルのうち少なくとも一方のモデルにおいて他方のモデルと隣接する箇所の形状を前記テーパ値の大きさに応じた調整量となるようにテーパリングすることで当該モデルの形状を調整する調整機能とを
実現させるためのプログラム。