Archive for 2010年10月

mezzo forte intuos4慣らし運転中


2010年10月28日 01:58 by mezzo forte

とりあえずラクガキ投下。OSから何から全部一新してしまったので、デバイスに合わせて人間の方が慣らし運転中…

Tongに見せたところ「手書きでインク切れかけのマッキーで描いたみたい」と評されましたが、まさに私もインク切れのマジックでキシュキシュ言わせながら描いてる感じでした>intuos4

mezzo forte intuos4


2010年10月25日 23:31 by mezzo forte

堪えきれず、買ってしまいました>intuos4 Large

ワコムから最新のドライバを引っ張ってきて、買ったばかりの Windows 7 pro 64bit 機に突っ込んだのですが、まるでタブレットが言うことを聞かない。古いドライバを持ってきたり、Windows7 のタブレット機能を切ったりもしたのだが、今度は Photoshop の筆圧検知をしない、消しゴム使えないなど、まったくどうにもこうにも。

結局、アンインストールしてCDのドライバを入れ直して再起動したらスコンと動きましたとさ。ああ、こんな機械どもに煩わされずに私はただ絵を描きたいだけなのに…とりあえず、10分ぐらい筆圧検知のテストで落書き。うーん、慣れの問題もあるだろうけど、以前の intuos2 の方が描きやすかったかなぁ…

やっと動くようになったな、と思って安心したら今度は無線マウスの動きが変になってきた…もー、なんだか、もーっ!

mezzo forte 浦島太郎


2010年10月23日 00:52 by mezzo forte

前回のTongのエントリーにあるように、先日Tongとアキバで共に一夜を過ごしてきました。私は別にアキバじゃなくてもと思うのですが、どうもTongの方が行きたいようで、ビジネスホテルの屋上露天風呂に一緒に浸かったりしてきました。最近PCトラブルで疲れたカラダにはいいリフレッシュになったかも。

Tongとリアルに会ったのは半年ぶりですが、ほぼ毎日テレワークと称した雑談チャットをしているので、久しぶりな感動もなかったりします。「横文字でわざわざ『シームレス』って使ったりする人いるけど『継ぎ目がない』でいいんじゃない?」とか何とか、あんまりゲーム開発と関係ない話も多かった気もしますが、対面コミュニケーションはやはり重要。夜中の4時までコッペリウスのプログラム構造について議論を重ね、特にフレームワークの部分での成果と課題がわかったことで、今後の見通しが立ったような気がします。あくまでも「気」だけですが。

一夜明けて一緒にアキバを散策していたのですが、この街はしばらく目を離すとやたら様変わりしますね。古くから残っているところもあるので何とか迷わずに済みますが、店が入れ替わってるだけでなく、建物自体がなくなったり建て替えられていたりでびっくりです。

先日HDDがクラッシュして新しいPCを買ったのですが、もうすっかり世代交代しているんですね。アキバを見て回ったらウチで現役のシリアルポート (D-Sub 9pin) だのパラレルポート (D-Sub 25pin) はとっくに絶滅品種でジャンク扱い。私も思わず無線キーボードとか Bluetooth とかに手を出してしまいました。物欲の街おそるべし。

で、荷物抱えてウキウキで帰宅し、開梱したら以前のDAW環境や古いデバイスが新しいPCで動かせなくてぐったり。結局古いPCに絶滅品種のIDE HDDつないで再生したりしていたのですが、これがまったく上手い具合に動かない。筐体を何度も開けたりバラしたりして一気に疲れて老け込んだ気分です。ああ、これってまるで浦島太郎の玉手箱。私はこんな箱に煩わされずに、ただ普通に絵が描きたいだけなのに…

そんなわけでH.H.Gの進行が滞っております。ううむ…

tong After EffectsにSSD!


2010年10月19日 15:39 by tong

ご存知の方もいるかもしれませんが、当方とmezzoは住んでいる場所の距離が700kmほど離れており、結構なテレワーク環境でゲームの開発を行っています。
ところが最近副業の方で当方が東京に寄る機会が増えてきたので、その都度できる限りmezzoと秋葉で合宿を組むようにセッティングしています。 (さらに…)

tong 愚直な状態遷移機械は作るのが大変


2010年10月12日 09:24 by tong

この手のプログラムの仕組みを真剣に考えたことがある人は、恐らくこの部分ハードルの高さに開発を躊躇する、あるいは「どの様に回避するかを真剣に考える」事でしょう。
かく言う当方もその一人です。

この手のプログラムとは当方の場合コッペリウスであり、プレーヤーの操作(外部からの刺激)に応じて反応を返し、そして状態が変化してゆく機械の事を指します。
この様な機械は何か正式な名称が有るのかもしれませんが当方は知らないのでここでは、これを仮に状態遷移機械と呼ぶことにします。

人の場合外部からの刺激に対してなにがしかの反応を返しますが、その反応は(生成方法はともかく)自動的に生成されます。
しかし、状態遷移機械の場合は自動的には生成されません。故に製作者あるいは開発者が、全ての刺激に対する反応をあらかじめ用意しておく必要があります。
そしてクリックアドベンチャの場合、反応とは「絵や動画」であり「テキストや音声」に他なりません。

●初期状態
お尻をつつく 体をよじって嫌がる
胸をもむ 激しく拒否する
クリトリスをつまむ 泣きだす

上記の例ですと3つの刺激に対して3つの反応を返します。
つまり、製作者は「3つの状態を表現するために3つの反応を用意しなければならない」事になります。
では、これが初期状態だとして何度か刺激を加える事により状態が変化したとします。
ここでは仮に「刺激に慣れ受け入れた」としましょう。

●初期状態 ●刺激に慣れ受け入れた
お尻をつつく 体をよじって嫌がる お尻をつつく 息が荒くなる
胸をもむ 激しく拒否する 胸をもむ 拒否する
クリトリスをつまむ 泣きだす クリトリスをつまむ 感じるのを怖がる

この場合で注目すべきは「状態が1増えただけで用意しなければならない反応は3増える」と言う事です。
つまり「状態が増えると用意しなければならない反応は2次関数的に増えてゆく」そして、反応の数は作業量に直結すると言う事でです。
さらに、「いつも同じ反応だとつまらないので、さらにランダム性を持たせたい」とかなってくるとどうなるか・・・、言わずもがなだと思います。

これをどのように回避するか、あるいは真正直に正面突破?
プログラムと言うか制作側の問題かもしれません