出先がぷちデスマーチ。私は残業しない主義者なので時間がきたらたいていさっくり帰ってはいるのですが、こんなん設計書じゃねー(どーん)とか、先生仕様がありません(泣)とかいいながら、出てる時間、ほぼフルでコーディングか会議をするのはさすがに疲れるのです……。
帰ってからはアレの作業。こっちは主に大変なのはスクリプタの人であって私ではないのですが、まだ調整が不足してて対応の必要が(涙)。とりあえず順次あがってくるボイスで心を癒す(ぉ
県税事務所と市役所と税務署から会社の決算の確定申告の書類が届きました。提出は今月末まで。会計的なデータは全部そろってるんだからさっさとまとめないとねぇ。
土曜夜。あ、イノセンス今日からか。お、市川妙典もネットで予約できるようになってるのか、ということでレイトで予約してみるテスト。席とかも選べるのね。便利かも。※飛べません
内容については……うーん。「ふーん」ってかんじで(苦笑)。基本的にはなんかなやんでるみたいだけど、原作の要素をなにかしら越えたところがあるかっつーとそうでもないかのぅというか、そんなかんじで。
携帯こわれた……。前からちょくちょく切れてたりしたのですが、ついに全然相手方の音が聞こえなくなってしまいました。ということで今日秋葉のauのサービスにもちこんで修理に。たぶんスピーカーの線がきれちゃったのかなぁと。よくおとしたからなぁ(汗) 代替機かしてくれてできたら連絡くれるとのこと。そういうシステムだたのか。
日曜。「ゲーム制作者が語る会 第一回」。面子は、企画とか２人、プログラマ１２人 (コンシューマ3,えろげ2,フリーランス2,業務とか組み込みとか5) という、なかなかありえない構成。けっこういいかんじの会合になったとおもいます。偏ってた気はするけど(^^;
しかしプレゼンうまいですなぁ。私のは準備とかちょといまいちですた(汗)。
昨日仕入れた(苦笑)アイディアを発展させたおもいつきメモ(妄想ともいう)
某システムでは作中に登場するキャラクタは「キャラクタオブジェクト」として状態管理されてます。管理対象は立ち絵とボイスで次のような定義を行っています。
オブジェクト定義ファイル抜粋 ------------------------- # キャラクタ定義: arg1 ボイスファイルベースファイル名 character,ゆかり,yk -------------------------
オブジェクト初期化処理スクリプト抜粋
--------------------------------------------------
// 立ち絵名称, ベースファイル名、表情差分ファイル名, エモーション表示オフセットX, Y
ゆかり.addPose("ウェイトレス", "yk_%d_0_%d", "yk_%d_0_%d", 0, 800);
// 表情名称, 表情番号
ゆかり.addFace("ノーマル", 1);
ゆかり.addFace("喜", 2);
ゆかり.addFace("笑", 3);
ゆかり.addFace("哀", 4);
ゆかり.addFace("怒", 5);
--------------------------------------------------
はい、ありがちなかんじですね。直接オブジェクトにエントリしていくのは、少ないといいけど多いと大変なことに！これの登録作業はプログラマ、または、よく文法を理解したスクリプタによって行われています。記述はもちろんテキストエディタ。よくパラメータのこれなんだっけと忘れて、マニュアル(主に脳内またはソースコード)をあさるはめになります。キャラクタ登録はまだましで、イベント登録とか、アクション登録とか、エモーション登録とか、けっこう泣きそうです。
プログラマはこんな作業からは開放されるべき(怠惰は美徳)→全部スクリプタかデザイナにおしつけてしまおう→そのためにはシステム化は必須だ。うむ、完璧な理論だ(ぉ
要件:
ソリューション:
キャラクタデータ作成手順
キャラクタデータ動作手順
キャラクタデータ管理方法
……すばらしいかもしんない。これはもちろんキャラクターに限らず、あらゆるものに応用可能なわけです。某システムだと、アクション定義、エモーション定義、照明定義、BGM定義、SE定義、他なんでもいけそう。ぶらぼー。
なにやら MS InfoPath はかなり「使える」ブツらしく、基礎になるXML データ生成までの実現可能性は十分高いと思われます。が、できあがった XML そのままでは、使えません。テキストのままだとローディングに時間かかるし、なにより、大量に画像があるわけで、キャラクタを一つインスタンス化した時点で全部ロードされちゃったりしたら大変なことに。
XMLのバイナリデータ形式(とそのライブラリ)で「使える」ものはあるのだろーか？構造は一気に読みこむけどデータ本体部分は指定するまでよみこまれないってのが必要。まあ画像部はさっくりと別ＤＢに切り出して名前参照にしてしまえば良いわけなのですがが。
いろいろDB系もどうすればいいかのぅ。システムとしての完成形は遠い(^^;
やっぱデータは特化したほうがいいですかね。少なくともXMLのパースは実行時にしたくないです(^^; うまいこと縛りをかけた上で、数値、文字列、データブロック、およびそれのリストの組み合わせに展開してしまって、それの読み書きのためのコードを自動生成するような枠組みを作ればええのかな。このあたりは Java のがいろいろ環境はそろってそうな気がするんだけど、読み込む側は C++ なんだよね。まあ、機械的置換でどーにかできるように考えてみよう。
ちなみに私もまだ InfoPath を触ったことはありません(爆)。早急に仕入れてこなければ。なぜか MS のページには単品パッケの情報がみあたらないのですが、普通に単品売りしてるようです。 Sofmapの例
ちょっと日記組みなおし。
ぐは、「照明」としてつくったはずの機能が、個別回転と個別移動をつけたことによってさっくりと汎用レイヤアクションにつかわれてしまうというのは予想するべきだったか(苦笑)
たぶん次版では、汎用レイヤは別に機能を分けて、「照明」については、より特化した構造 (スポットライトとかビームライトとか定番形状の動的生成、かな) で整理しなおすことになるのではないかと思われます(苦笑)
微妙に関係なきにしもあらず（笑）。私の話してるのは初期定義の話ですが、実際の駆動時にもちゃんとオブジェクトとしてふるまってますので(^^;
うちのアレの場合、キャラクタは配置の属性として、前後(ユーザが登録:Z位置から導き出される解像度別に立ち絵をバインド)、左右(ユーザがX座標を登録)、に加えて表示状態(出/消/顔) をもってます
例えば表情「笑」状態になってるキャラクタを「顔」状態に遷移させると、画面からは立ち絵が消えて、その状態を引き継いだまま顔が出るわけですね。
フェイス表示状態はメッセージ窓に対して会話のタイミングで送られます。キャラクター別にメッセージ窓を割り当てた場合はそれぞれのメッセージ窓にフェイスが出ます。キャラクタがメッセージ窓を持ってない場合は、キャラクタが所属する環境オブジェクトが保有する主メッセージ窓にフェイスが送信されて、他のキャラクタとシェアすることになります。
あと、特殊なモードとして、「顔表示モード:ON」にすると、キャラクタの現在位置が「出」の場合にも常時フェイスが出るようになってます。こうすると、画面上立ち絵とメッセージ窓のフェイスが連動することになります。活用は演出用途に応じてってことになりますな。
キャラクタにつき状態は一つしかもてないので、「立ち絵とフェイスを連動させない」とか「画面上に複数立ち絵をだしたい」とかいう場合は、別キャラクタとして定義してもらうことになります。あー、コンストラクタにキャラクタを渡すと、定義情報を引き継いで初期化かける、ドッペる機能、ってのつくっておくほうがよさげっすな。
あー、フェイスと立ち絵を連動させないってのは演出としてありですな。従来の「表情」「ポーズ」に加えて、「顔表情」「顔ポーズ」の属性値と命令を増やしてもいいかも。「表情」命令発行時は「表情」「顔表情」の両属性を変更。「顔表情」命令発行時は「顔表情」属性だけ変更。うちのシステムは原則として「変更」命令を発行するまで実際の表示変更がおこらないので、これで大丈夫です。
立ち絵連動 詩子[泣]いたいですぅぅ〜 非連動 詩子[笑,顔表情 泣]いたくないです〜 ※ ] によって実際の絵の変更が発生