ただ見上げるより この手を伸ばしてみたくなるだけ (ポコアポコ/カヒーナムジカ)
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

 昨日,ジョン湿地王先生主催のお絵描き合宿に少しだけ顔を出した後,帰宅してやはりスクリプトを書いていたのですが…
 その最中,ふと悟ることがありました。

 今回,「青の彼方の島」では確率図に「目標値がはっきり決まらない場合,あるいはぼんやりとこのぐらいとしか分かっていない場合,成功色と失敗色のグラデーションを表示する」という表示方法を導入してみました。
 このグラデーションも,今回の不満のタネでした。何がかと言うと,「狙った表現ができない」。
 グラデーションの範囲を指定できる形になっていなかったのですね。あやふやにしておきたい,「この範囲ならば成功も失敗もありうる」というエリアは,ダイス数によっても状況によっても違うでしょうと。
 そこで今行っているスクリプトの修正で,この範囲を指定できる形に改めた訳です。
 修正した後,テストを兼ねて入力する値を変えながら,表示がどんな風に変わっていくかなぁ…と眺めている時。
 ああ,私は今回「青の彼方の島」で、こういう作業をやっておきたかったんだなぁ,とささやかな満足感を得ました。
 結論から言うと,多くの場合グラデーション範囲をいじる必要性はほとんどありませんでした。
 「グラデーション範囲として適切そうだな」と思う値が,グラフの高さに対してだいたい一定であったからです。
 まあ状況によっては少し変化させたくなる場面はあると思いますが,多くはそうではない事が分かりました。

 しかし「実はいじる必要がない」と言うことは,実際にいじってみてから気が付くことだったのです。
 最初に全体の設計を考える段階では,「きっとグラデーション範囲を変化させたくなるから,範囲指定はできるようにしておこう」と考える訳です。でもその考えが当たっているのかどうかはやってみないと分からないのです。
 前作から継続されている部分はともかく,新しくやる事,前回から変更を加えた箇所などは,設計段階ではいかに妥当そうに見えても,目論見が正しく当るかどうかは誰にも分からない。そして目論見が外れていた場合,どうなるのでしょう?

 その構想が正しいのかどうか,不足はないか,それを確認して方針を修正する作業を、夏コミ前にしたくてもできなかったのですね。それを今できたことに,ようやく安堵感を覚えることができた訳です。
 夏コミ前にできなかったのは,ステップとしてきちんと組み込まれてもいなかった…というより,組み込もうとするのを頑張って拒否されたきらいがあります。

 このチェックは,ある程度実物ができていないと行えないものです。
 グラデーション範囲の話ならば,デザインが上がっていないとできません。
 のみならず,ある程度スクリプトができていて,クリティカル範囲,成功範囲,失敗範囲なども一緒に高さを変化させられないと,状態をきちんと把握できません。
 しかしスクリプトを書く人間にとって,途中で仕様を変更するというのはできるだけ避けたい事態です。今までやった作業が無駄になると言うことでもあり,無理に変更したせいでコードが複雑になり,予期せぬエラーの原因になったりもします。IT企業のプロジェクト遅延理由のトップが「仕様変更」であると言う話も聞きますし…。
 大げさに言えば、企画側とスクリプト側との理想は全く正反対なのですね。


 このコンフリクトについて考えていたところ,思い出した話がありました。
 昔,デジタルゲームのデザイナーが,「ゲームを考えたら,まず高級言語で仮組みしてみて動きを確認してみる。それから正式のプログラミングに入る」という話を雑誌に書いていたことがありました。
 その時は「ふーん」という程度で読み流していたのですが。
 今となると,その気持ちや必要性が痛いほど実感できます。
 すると,打開策は「仮組み」という発想なのかも知れません。最低限の機能だけスクリプトを書いて,各種変数を変化させながら,構想の正しさを検証する訳です。
 まあアクションスクリプトは十分高級言語だと思うので,仮組みも本式も高級言語で行う点が異なりますが。
 デザイン完成後に,「仕様を最終決定するための仮組み」というステップを,スクリプトの仕様書を書く前に入れると。
 そうすれば両サイドの衝突は避けることができるのではないでしょうか。

 さてその仮組みを誰がするのか,とか言う話になると,やっぱり私になるのでしょうか。それならば他のスクリプト書きから文句は言われないし。ただそうなると,私の手元の作業量が増え,より一層,他の人に作業を投げるタイミングが遅くなる訳ですが……まあ,いいか。


追記を閉じる▲
 結論から言うと,多くの場合グラデーション範囲をいじる必要性はほとんどありませんでした。
 「グラデーション範囲として適切そうだな」と思う値が,グラフの高さに対してだいたい一定であったからです。
 まあ状況によっては少し変化させたくなる場面はあると思いますが,多くはそうではない事が分かりました。

 しかし「実はいじる必要がない」と言うことは,実際にいじってみてから気が付くことだったのです。
 最初に全体の設計を考える段階では,「きっとグラデーション範囲を変化させたくなるから,範囲指定はできるようにしておこう」と考える訳です。でもその考えが当たっているのかどうかはやってみないと分からないのです。
 前作から継続されている部分はともかく,新しくやる事,前回から変更を加えた箇所などは,設計段階ではいかに妥当そうに見えても,目論見が正しく当るかどうかは誰にも分からない。そして目論見が外れていた場合,どうなるのでしょう?

 その構想が正しいのかどうか,不足はないか,それを確認して方針を修正する作業を、夏コミ前にしたくてもできなかったのですね。それを今できたことに,ようやく安堵感を覚えることができた訳です。
 夏コミ前にできなかったのは,ステップとしてきちんと組み込まれてもいなかった…というより,組み込もうとするのを頑張って拒否されたきらいがあります。

 このチェックは,ある程度実物ができていないと行えないものです。
 グラデーション範囲の話ならば,デザインが上がっていないとできません。
 のみならず,ある程度スクリプトができていて,クリティカル範囲,成功範囲,失敗範囲なども一緒に高さを変化させられないと,状態をきちんと把握できません。
 しかしスクリプトを書く人間にとって,途中で仕様を変更するというのはできるだけ避けたい事態です。今までやった作業が無駄になると言うことでもあり,無理に変更したせいでコードが複雑になり,予期せぬエラーの原因になったりもします。IT企業のプロジェクト遅延理由のトップが「仕様変更」であると言う話も聞きますし…。
 大げさに言えば、企画側とスクリプト側との理想は全く正反対なのですね。


 このコンフリクトについて考えていたところ,思い出した話がありました。
 昔,デジタルゲームのデザイナーが,「ゲームを考えたら,まず高級言語で仮組みしてみて動きを確認してみる。それから正式のプログラミングに入る」という話を雑誌に書いていたことがありました。
 その時は「ふーん」という程度で読み流していたのですが。
 今となると,その気持ちや必要性が痛いほど実感できます。
 すると,打開策は「仮組み」という発想なのかも知れません。最低限の機能だけスクリプトを書いて,各種変数を変化させながら,構想の正しさを検証する訳です。
 まあアクションスクリプトは十分高級言語だと思うので,仮組みも本式も高級言語で行う点が異なりますが。
 デザイン完成後に,「仕様を最終決定するための仮組み」というステップを,スクリプトの仕様書を書く前に入れると。
 そうすれば両サイドの衝突は避けることができるのではないでしょうか。

 さてその仮組みを誰がするのか,とか言う話になると,やっぱり私になるのでしょうか。それならば他のスクリプト書きから文句は言われないし。ただそうなると,私の手元の作業量が増え,より一層,他の人に作業を投げるタイミングが遅くなる訳ですが……まあ,いいか。

【2007/10/15 19:48】 | 天地未だ形れざるとき
トラックバック(0) |
コメント
この記事へのコメント
コメントを投稿
URL:

Pass:
秘密: 管理者にだけ表示を許可
 
トラックバック
この記事のトラックバックURL
この記事へのトラックバック
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。