[TOP][電波…とどいた? TOP]

電波…とどいた? 200404上旬/中旬/下旬

[←前のページ]
[次のページ→]

2004年4月21日の電波状況

雑記

マシンをひとまとめにするええ方法はないかと思案中。や、台数ふえすぎてて、電力消費が……(汗)

VMWare Workstation はログアウトするとおわっちゃうのでサーバ運用的にはアレなのよね。一応 XP or Server ならログインしっぱなしって手はあるんだけど、やっぱりねぇ。 Linux 版にしろ? それはごもっともなのですが、うちはなんやかやで Win マシンは必要なので(^^; ホストは Win にしたいのです。たぶん Virtual PC もそのあたりは同じなのではないかと思うのですがどうなんでしょ?

VMWare の Server 版があるのは知ってるんだけど、値段とか要問い合わせだったりするし、高いんだろうなーっておもってたら、MS ってば、よくよく見ると、Virtual Server ってのが商品のラインアップにあがってたのね……というか、こっちが MS 的には大本命か(^^;

ベータ版の評価やってるのでとりあえず申し込み、と。現時点だと値段とかがわからないけど、かなり安く戦略的価格にしてきそうな予感はするしー。これでマシン統合できるなら、Win鯖2003 をコアにして、各種検証用マシン群と、あと、UNIX 系 OS のサーバ群もそのまま稼働できれば万々歳。

ゲームエンジンの話とか

続き。 いまいちよくわからないとのことなので(^^;;; 声待ちの話をちと整理しときます。

現行システムの仕様(当初)

やりたいこと: ボイス(・テキスト)・表情演出の同期

→現行システムでやりたいことを実現するには適当なタイミングで「待ち」を行う必要がある

「待ち」機能の仕様 : 命令後最低一定時間待つ。クリックしたらキャンセルされる。

→テキスト表示にあわせて待ちを入れるとテキスト表示速度が変動すると絶対ずれる
→「待ち」が複数あると、クリックを何度もおさないとテキストをスキップできない

対策:ボイスの情報をオブジェクトがもっていることを利用して「ボイス待ち」命令を追加

→ボイス速度指定に関わらず、ボイスと演出を合致させることができる
→スキップ時には一括でスキップ処理がおこるのでいらつくことはない

さらにやりたいこと:タイミング指定にあわせて文字表示速度を変動させる 現在はタイミング指定にあわせた「待ち」なので、文字のほうが高速に表示されてあとは待たされる(もしくはその逆で待ち指定が意味をなさない)という状態がおこりうる。ボイスにタイミングをあわせるのなら、それにあわせた速度制御を行ってしまうのが妥当

→現状のシステムは逐次型のため待ちで指定されている時間指定を先に把握することができない

→潜在的な問題 「テキストにコマンドをうめこむ」=「テキストを修正するとスクリプトが変化する」ことを意味する。誤字脱字の補整や文章の簡単な調整ごときによってスクリプトが変化するのは美しくない。

対案A: 先読みの工夫対案B: 全部あらかじめ高度な構造化データにしておく

→対案B のほうが妥当というのが私の考え

やぱ図がないとわかりにくいなぁ……

2.「メソッドによる初期化」の限界

当初はオブジェクトの数ももつ機能が少なかったので、初期化は、定義時にパラメータを単純にカンマ区切りで渡す(コンストラクタ的イメージ)、またはオブジェクトの初期化用のメソッド群を使うことで特に問題なくまわっていました。その後、大規模なオブジェクトが入ってきて、どんどん状態指定の要素が増えたにもかかわらず、その最初の設計を引き継いだせいでたいへんなことになってしまいました(汗)。

たとえば、「夏音 -Overture-」のシステム初期化コードは、800行ほどのスクリプトです。でかすぎ。さらに、これを記述するためには、個別のオブジェクトの機能を詳細まで知っておく必要があります。

これも、それぞれのオブジェクトの「初期化のためのデータ構造」を定めてしまえば、たとえば HTML フォーム + CGI の形で情報入力をおこなってしまうことが可能になります。フォームが十分に情報を提供することで、データ登録作業を行う人にはオブジェクトに関する深い知識は必要なくなります。

3.コンバート方式を原因とする作業効率の著しい低下

疲れたので続く。

2004年4月23日の電波状況

買い物

  • 『美鳥の日々6』(井上和郎/サンデーコミックス)[amazon]
  • 『ハレグゥ2』(金田一蓮十郎/ガンガンコミックス)[amazon]
  • 『フルーツバスケット14』(高屋奈月/花とゆめCOMICS)[amazon]
  • 『るくるく3』(あさりよしとお/アフタヌーンKC)[amazon]
  • 『ラブやん3』(田丸浩史/アフタヌーンKC)[amazon]
  • 『電撃大王10』()[amazon]
いろいろでてますた。ハレグゥはラヴコメですよ(笑)

アマゾンのあれの前半期の報告きてました。2439円。おー、漫画本何冊かぶんにはなったか。あ、しまった。ラブロマもでてたのか……。いそいでたので見逃したか。


2004年4月24日の電波状況

雑記

雪技ついでに買い物。

  • 『ラブロマ 2』(とよ田みのる/アフタヌーンKC)[amazon]
  • 『ケロロ軍曹 2』(吉崎 観音/角川コミックスA)[amazon]
  • 『ケロロ軍曹 3』(吉崎 観音/角川コミックスA)[amazon]
  • 『ケロロ軍曹 4』(吉崎 観音/角川コミックスA)[amazon]
  • 『ジャングルはいつもハレのちグゥFINAL 5』(DVD)[amazon]
ラブロマはなごんで良いですなぁ。ケロロ軍曹は1見て気に入ったので順次ゲット中。ハレグゥはまた観賞会しましょう>だれとはなく

カルテット

さっくりインストールしてさっくりプレイしてさっくりコンプリート。プレイ時間は2.5時間ぐらい。

ポップなノリで、読みやすくておもしろかったんですが、ちょっと薄味かなー。いや、味付け自体は濃いんだけど、浅いというほうが正しいか。のどごしすっきりしすぎ。

キャラクタたちはよく立っててそれぞれとても魅力的だとは思うのですが、プレイしてる「世界」に、「時間」がいまいち感じられません。見せ場だけをつないでいるせいなのか、シーン間に脈絡が無く、ぶつ切り印象が高いです。キャラクタの間に順次できていったはずの絆みたいなものが見えてこないので、なかなか感情移入して楽しめるタイプの作品になってないように思います。二周目以降、前半部がほぼシェアになっているってのもマイナス要因なのかな。プレイ時間配分は、1.5 + 0.5 + 0.5 でした。

作品の空気として「夏音」と合い通ずるものがあるように思います。ただ、夏音のほうは、問答無用でまぬけ不思議時空に引きずりこんでいく妙なパワーがあるのですが、この作品にはそういった点は無いので、私にはインパクト的に弱い(^^; もっとも、これは、声効果の影響もでかい気はします。声が魅力的だと、ついきいてしまうので、プレイ時間も必然的に延びますからねぇ(^^;

……メイがいちばんお気に入りなんですが、サブキャラなんだよな(苦笑)。最後あるとおもったのにー(なにが?

システム的な面はさすがといいましょうか、文句つける余地がありません。軽いし、きれいだし、操作体系に統一がとれてるし、親切。

で、そのシステムを駆使した演出はたしかに一見の価値はありなのですが、演出バリエーションとしてはあんまり無いのかなという気も同時にしてしまいました。基本的に多くの素材が「単品もの」であり、それは素材として最強なのは事実なのですが、その反面、「素材加工」「組み合わせ」「動きの工夫」といった素材の少なさをカバーするための『仕事』があんまりなされてないんですね。新鮮で生きが良い素材だけだと江戸前寿司にはならんつーか、そんなかんじ。

えっちシーンの動き演出とかも悪くないんのですが、最近けっこうある同種の演出 +なにより「声つき」になれてしまっていると弱い気がしてしまいます。このあたりはライアーソフトのそれという先達があるわけですが、それに及んでない。あと、演出に対する『仕事』としては、今年は Fate という大作を見てしまっているのと、あと手前味噌入ってしまいますが、夏音「6月期シナリオ」のその作業を近傍でみてしまうと……

なんとなく声がないのが不満なだけな気がしてきたので↑このへん削除(苦笑)。気がむいたら実際に比較ってことでー(ぉ

もっとも、そんなことまでやってると、とてもじゃないけど作業おわらないよって話はありそうです(大汗)。むずかしいところなのでしょう。なんかの雑誌のインタビューで、次は別のシステムで、的なことかかれてたのを目にしたのですが、そういった意見がでてくるのもわからなくもない(苦笑)。

複雑な演出をいかにして楽な作業にできるのかってのは私的な課題になっています。このあたりについては最近ときどき書いてるスクリプト関係の話でも今後順次でてくる予定。


2004年4月27日の電波状況

ゲームエンジンの話とか

続き。各種アイデアを整理するにはとりあえず書くべしってことで。

3.コンバート方式を原因とする作業効率の著しい低下

スクリプティング作業のフローは次のようになります。

  1. スクリプトファイル(テキスト形式)をエディット
  2. コンバート
  3. エラーがでたら 1 にもどってやりなおし
  4. エンジンで起動するスクリプトファイルを指定
  5. シーンの頭から再生・確認
  6. 問題があったら 1 にもどってやりなおし

私の想定では、1 から6までのターンアラウンドは、複数の問題点を一度にチェックしてから、それを修正、というのを考えていました。プログラマ的思考ですね。ところが実際には、沢村さんはこの作業をほぼ行(=キャラクタの会話)単位で行っていることが判明しました。

シーンの先頭に近い部分だとあまり問題にならないのですが、後半になると、そこまでとばすだけで無駄に時間がかかってしまいます。ついとばしすぎてしまうと目もあてられません。「3kbが限界」発言はここから来ています(^^;

さて、もともと本システムでは、データの保存はシリアライズの手法を採用していて、ある瞬間の状態を復帰する方針でくんであったのですが、これは、

  1. スクリプトの変更に弱い
  2. シリアライズ処理のコストは案外高い

という問題をかかえており、編集作業中にこれを利用した行単位での状態復帰・継続処理を行うのはほぼ絶望的です。

そこで、これを契機に、思いきってバイトコードエンジンの動作原理を変更しました。 ※1

システムの状態として、「通常」「スキップ」があったのですが、さらに「瞬間スキップ」を加え、指定された「行」に達するまで、内部的な状態変更だけを行って、画面表示などの時間がかかるロジックはすべて処理遅延を行わせる、という処理を組み入れました。たとえばキャラクタに立ち絵ポーズ更新指令が2回あった場合、後から実行されたほうのみが有効になって、瞬間スキップが完了した時にはじめてそれの表示が実行されます。

この仕様変更により、「特定シーン」の「特定行」に対する復帰がほぼ一瞬になりました。さらに、コマンドライン、またはドラッグ&ドロップによっていたコンバートエンジンの呼び出しをゲームエンジンにくみこむことで、1キーでの

の処理を実行可能としました。これにより、相当の作業効率の改善がみられました。スクリプタは、テキストエディタから適宜編集を行って、任意のタイミングでエンジン側でリロード操作を行えば、その反映結果を確認できます。前後だけでなく一度に移動したい場合は、別途メニューを呼び出して、直接行番号を指定することで対応しています。

さて、ここまでできているなら、次に見えてくるのは、エンジンそのもののオーサリングツール化です。基本的に、このシステムのスクリプティング作業は、コマンド埋め込みに終始しています。そうなると、外部のコンバータにたよるまでもなく、エンジン自身に直接内部データ形式に変更させた上で、それを動的に保持し、任意のタイミングに対して、再生、巻き戻し、早送りを行ったりすることは十分可能です。

先日の「音声同期」の指定についても、あれだけ複雑になってしまった場合、テキスト形式でのスクリプティングはもちろん可能なのですが、スクリプトうめこみテキストの可読性の低下や、調整の煩雑さが懸念されるわけで、こういったオーサリングツール化しか、基本的には未来は無いように思えます。

ぶっちゃけ、各社はどうやってるんだろう?と思うわけなのですが、どうなんでしょね(^^; Fate とか、スクリプトすげーことになってるわけですが、死にながら作業してたんだろうか。あと Qualtett も。なにかしらツールはつかってるよね? ね?


ゲームエンジンの話とか2

時刻同期についてはその通りです。で、さらに、そういった情報を入れるのならば、そもそも、それによる「文字単位での表示時刻制御」もやっちゃおう、というところまで含んでます。

このことはそもそも問題なのか?

クリティカルなものではありません。ただ、純粋にテキストをみたい場合に見辛いのはたしかです

うまくスクリプト文法を作れば解決できるのではないか?

スクリプト文法的な問題もありません。適切な(=論理的に目的とするデータ構造を再現する)文法はいくらでも提供できるでしょう。ただ、その文法の熟知をスクリプタに求めるのは酷です。

うまく補助ツールを作れば解決できるのではないか?

その通りです。目標は「補助ツール」ではなく「完全ツール」の提供にあります。

そもそも、テキスト埋め込みスタイルのスクリプトはプログラマとして捨てるわけにはあかんので(笑)、以下のような使い分けをするのがいいのかなと。
形式 用途 操作方法
プレーンテキスト 初期スクリプティング、構成管理 テキストエディタ
構造化テキスト データ定義、構成管理 データ入力ツール(WEBベースCGIやInfoPathなど)
DB オーサリング オーサリングツール(ゲームエンジン内包)
DB 形式は、オーサリング作業用で、この形式からは、テキスト+構造化データに対する export/importを可能とします。これは構成管理を確実に行う上でも必要になります。

たとえば「構造化テキスト」の一つとして「オブジェクト名+テキスト+文節情報」というのを考えています。次のようなスタイルになります。

0000:鈴菜:詩子も来るでしょ?|と言うか来い。|付き合え

元のコマンド埋め込みのスクリプトをDB化したあと、このスタイルで export し、誤字脱字チェックや補正を行ったあと (この時文節情報だけは破壊しないように注意する必要がある。チェックツールは区切り文字を無視しつつも破壊しない動作が必要) 、DBに書きもどすことで、スクリプティング(オブジェクト操作コマンド)を維持したままで、テキストのみの編集、といったことが可能になります。

このように、用途に応じて、適切なスタイルで出したり入れたりできる、ということが重要になります。スクリプティングの初期作業とか一括変換とかの作業は、テキストエディタでががーとやったほうがやっぱ早いことが多いと思いますしね。

ゲームエンジンの話とか3

戦術級で進歩すると、ついついそれにこだわってしまって、全体がおざなりになってしまう、ってのはありがちな話ですねぇ、というか、実際、微妙にツール改善してしまったせいで凝りすぎてる側面がアレにもなきにしもあらず(汗)

で、話はかわって、戦略的な観点での進歩についても、技術的な支援は十分可能だと考えるのであります、サー (CV:詩子たん)。次回はそのへんに関連したシステム開発のビジョンをちまちまと語ってみる予定は未定。


2004年4月28日の電波状況

ゲームエンジンの話とか

4.過剰演出問題

3.として発生した問題に対して行った対策は、adhoc ながら効果的で、その結果として、別の問題を招きました。――そう、演出氏の暴走です(爆)。機能拡張作業を並列で行っていたため、新機能によって新しい演出効果が次々使えてしまう状態だったことがそれに拍車をかけました。使える機能は使いたくなるのが人情ってものです(苦笑)

具体的には次のようなことが起きました。

このこと自体は悪いことではないのですが、プロジェクトとしては、次の点で問題になります。

わーい(汗)

5.リリースコントロールの破綻

対案を示すより前にもう一つ。これは結果的には、まあ、何とかなったのですが、プロジェクト的にはやはり問題なので明記。

作業が「β」まで進んだあとで、企画のコアメンバーによるチェックが入った結果、多くの修正指示が出ました。手戻りの発生です(涙)。リリーススケジュールは事前に内部で予告されているものなのであり、リリース作業担当の権限で「却下」してしまうことも可能ではあったのですが、実際には「出来なくは無い作業」だったので、そのまま作業してしまいましたが、やっぱアレです。

なにより、リリースのための各種パッケージング作業(難しくないけど煩雑)を何度も繰り返すはめになって、ムキーってなってしまうのは怠惰を美徳とする者にとっては大問題です(ぉ

これらは、プロジェクト運営そのものに関係する話であり、解決も政治層に属する話です。そういった場合に、権限を持たないプログラマ的にはには出番がないかっつーとそうでもなくて、「そういった問題が発生しにくい作業システムを考える」ことができるわけです。こうなってくると、正確にはプログラマというより SEになってくるわけなのですが、細かいことは気にしないってことで

ゲームエンジンの話とか2

まずは演出上作業負荷の分散の話から。

演出に必要な素材の作成を指示するのは演出の仕事ですが、実際の作業まで演出が行う必要はありません、というか、仮に演出が作業しても、絵の人からダメ出しが入ってしまってその作業やりなおし、ということが往々にして発生します、つーかしました。

根本的には素材加工作業ワークフローの確立が必要なわけですが、そこにシステム側からコミットできることは無いか?ということで以下次号


2004年4月29日の電波状況

ゲームエンジンの話とか

演出作業の負荷分散を実現しやすくするためのシステム面からのアイディアなど。

演出作業の遅延の原因の一つに「加工素材作業」があることがわかりました。加工素材は、システム的に機能が無い、もしくは、弱い(能力が無い、あっても重い、など)部分を補助するために、「あらかじめ結果のデータをつくっておく」ことで対処するためのものです。弊社システムは、かなり重い(汗)ので、これをうまくつかわないと、やってられないという現実があります。

だからといって、これを無制限に許可してしまうと、演出家が凝りはじめてしまい、作業遅延の要因になります。そこで次のようなアプローチをとります。

原則:

  1. 効果として一般的な画像加工ソフトが提供するものは過不足なく提供
    ex. 拡大縮小、回転、ぼかしなど各種効果、色補正etc
  2. ある要素に対して複数の効果が指定可能
  3. 素材加工演出は「システム機能に対する指令(機能+パラメータ×複数)」の形で行う

補助機能:

  1. 指令をキーとして結果を「単独の画像のロード」に差し換えることができる
  2. 指令による生成結果をその場で「画像として保存」することができる
  3. 行われた指令に対する統計をとってレポートを出力することができる

あるシーンの画面構築作業は次のようになります。

  1. 舞台(背景)や各キャラクタを構成する個別の画像要素に対して状態を定義する

    それぞれの要素は、スクリプト命令のテキストでの手打ち、またはGUI での操作パネルによって動的に状態変化させます。これは画面で即時に確認可能です。

  2. 状態を確定させる

    「完了」操作によりスクリプトが確定します。また、この時、「画像保存」指示を出すことで、その結果をキャッシュ的に保持することができます。

  3. 再生

    キャッシュ画像があればそれによって演出が再現されます。無い場合は、リアルタイムに生成されます

要するに「ゲームエンジンに『素材エディタ』を組み込む」ということです。ゆんゆんのところでは、吉里吉里で画像加工エディタをつくってあるそうで、そのあたりが元ネタの一つ。

スクリプトとして生成されるのは「キャッシュ画像のロード」ではなく、あくまで「効果を生成する命令」です。これは、後から再エディット(他の人、あるいは気が変わった自分による) することを容易にするためです。基本的な演出はそのままで、絵師の人に直接パラメータ調整してもらうのもありでしょう。

さて、システムが提供した機能によるエディット結果にいまいち満足できない場合はどうするのか? そのための統計とレポートです。生成された画像とその生成パラメータが「参考資料」として添付された「素材発注書」を吐き出させます。これを絵師にまわして、完璧な素材をつくってもらい、あがってきたらそれを差し込みます。(再生時優先順は 登録データ>キャッシュ生成データ>パラメータ動的生成)

上記説明では「絵」を前提にしましたが、同様のアプローチは、音声系データについても同様にとることができるでしょう。

まあ、これはあくまで、作業の切り分けをきっちりすることを支援するだけで、演出氏が凝りまくること自体は回避できないっつーのがたぶん事実なのですが、少なくとも、フォトショップといったりきたりしながらあーでもない、こーでもない、とやりはじめるのはかなりの割合で回避できるんではないかなーと(希望的観測)

ゲームエンジンの話とか・反応

インデックスは、なんか、このへんにできてるみたいですよ?(笑)

演出の半自動化、沢村さんは、とりあえず定番パターンはテキストエディタで開いた別のテキストにためていって、こぴぺで対応されてたようです(^^; 第一歩としては、これの補助機能(パターンのパレットへの登録と参照)を組み込むからかなと。あとはゲーム世界の「物理法則」を増やして、トリガのみでの演出指定をもっと組み込むこととか。

ボイスシンクロは、とりあえずデフォルトはボイスにテキスト全体をあわせて、あと、音節単位の手動調整でなんとかならんもんかと考えてますが甘いですかね(^^; なにはともあれ前例の作品をさがしてやってみるべし、か……。しすたぁエンジェルも入手してやってみないとなぁ。

話がまざりますが、Quartett!のボイス、私がほしいなとおもったのはえちシーンだけです。ボイスでもないとあれは間がもたない……。

はい、 その理解でいいです。思考の流れのべたがきで整理されてなくてわかりにくい文章ですみません(^^;

いろいろ考えているわけなのですが、

というのは、今後も絶対に変えたくない点です。

当初の目標にはこれに加えて「最低限の文法での記述」というのもあったわけで、これには「別の(文法の)スクリプトを複数準備する」という対応をとっていたのですが、結局それでは「演出がしがし」の要望を処理しきることはできませんでした。本当に必要だったのは、スクリプトの「(機能別)細分化」ではなく、スクリプトの「(同機能)多態化」だったってことだったようで、オーサリングツール化はさけられない見通しです(^^;


2004年4月30日の電波状況

雑記

みんなでイスラエル料理食ってきました。そして踊る(謎)。つーか、なんでみんなあんなに踊りうまいですか(苦笑)。楽しかったのです。

[←前のページ]
[次のページ→]