いう、なかなかありえない構成。いいかんじの会合になったとおもいます。偏ってた気はするけど(^^;しかしプレゼンうまいですなぁ。私のは準備とかちょといまいちですた(汗)。昨日仕入れた(苦笑)アイディアを発展させたおもいつきメモ(妄想ともいう)某システムでは作中に登場するキャラクタは「キャラクタオブジェクト」として状態管理されてます。管理対象は立ち絵とボイスで次のような定義を行っています。5);--------------------------------------------------はい、ありがちなかんじですね。直接オブジェクトにエントリしていくのは、少ないといいけど多いと大変なことに!これの登録作業はプログラマ、または、よく文法を理解したスクリプタによって行われています。記述はもちろんテキストエディタ。パラメータのこれなんだっけと忘れて、マニュアル(主に脳内またはソースコード)をあさるはめになります。キャラクタ登録はまだましで、イベント登録とか、アクション登録とか、エモーション登録とか、けっこう泣きそうです。プログラマはこんな作業からは開放されるべき(怠惰は美徳)→全部スクリプタかデザイナにおしつけてしまおう→そのためにはシステム化は必須だ。「キャラクタスキーム」によるフォームを開くフォームからキャラクタ諸元を登録。立ち絵も全て画像そのものをぺこぺこ登録する保存。扱えば良い......すばらしいかもしんない。これはもちろんキャラクターに限らず、あらゆるものに応用可能なわけです。某システムだと、アクション定義、エモーション定義、照明定義、BGM定義、SE定義、他なんでもいけそう。データ生成までの実現可能性は十分高いと思われます。そのままでは、使えません。テキストのままだとローディングに時間かかるし、なにより、大量に画像があるわけで、キャラクタを一つインスタンス化した時点で全部ロードされちゃったりしたら大変なことに。XMLのバイナリデータ形式(とそのライブラリ)で「使える」ものはあるのだろーか?構造は一気に読みこむけどデータ本体部分は指定するまでよみこまれないってのが必要。画像部はさっくりと別DBに切り出して名前参照にしてしまえば良いわけなのですがが。DB系もどうすればいいかのぅ。▽InfoPathやっぱデータは特化したほうがいいですかね。うまいこと縛りをかけた上で、数値、文字列、データブロック、およびそれのリストの組み合わせに展開してしまって、それの読み書きのためのコードを自動生成するような枠組みを作ればええのかな。機械的置換でどーにかできるように考えてみよう。触ったことはありません(爆)。早急に仕入れてこなければ。ページには単品パッケの情報がみあたらないのですが、普通に単品売りしてるようです。▽某アレちょっと日記組みなおし。整理しなおすことになるのではないかと思われます(苦笑)微妙に関係なきにしもあらず(笑)。もってます例えば表情「笑」状態になってるキャラクタを「顔」状態に遷移させると、画面からは立ち絵が消えて、その状態を引き継いだまま顔が出るわけですね。フェイス表示状態はメッセージ窓に対して会話のタイミングで送られます。キャラクター別にメッセージ窓を割り当てた場合はそれぞれのメッセージ窓にフェイスが出ます。キャラクタがメッセージ窓を持ってない場合は、キャラクタが所属する環境オブジェクトが保有する主メッセージ窓にフェイスが送信されて、他のキャラクタとシェアすることになります。あと、特殊なモードとして、「顔表示モード:ON」にすると、キャラクタの現在位置が「出」の場合にも常時フェイスが出るようになってます。すると、画面上立ち絵とメッセージ窓のフェイスが連動することになります。活用は演出用途に応じてってことになりますな。キャラクタにつき状態は一つしかもてないので、「立ち絵とフェイスを連動させない」とか「画面上に複数立ち絵をだしたい」とかいう場合は、別キャラクタとして定義してもらうことになります。あー、コンストラクタにキャラクタを渡すと、定義情報を引き継いで初期化かける、ドッペる機能、ってのつくっておくほうがよさげっすな。あー、フェイスと立ち絵を連動させないってのは演出としてありですな。「顔表情」属性だけ変更。うちのシステムは原則として「変更」命令を発行するまで実際の表示変更がおこらないので、これで大丈夫です。