スタッフBLOG

おはようございます。本日の当番、プロデューサーの角和です。

今回は、僕が初めてディレクターをさせてもらった際の、涙のエピソードを
お話したいと思います。

ある日、僕が所属していた部署の部長？から、部長室に来るようにとの
お達しがあり、緊張しつつ扉をノックして入室しました。

いつも厳しい部長ですが、今回はニコニコしながら開口いちばん『ネタと
条件は決まってるんやけど、ディレクターをやって欲しいんや！！
ええやろ！？！』との問いかけに、僕も何も考えずに
『勿論、やります！！』と二つ返事。

ところが、冒頭の「ネタ」と「条件」には、恐ろしい罠が隠されて
いたのでした。

「ネタ」とは、その会社で昔にヒットしたゲームの続編というお題目
でしたが、正直、そのゲームや同系統のゲームはあまり僕がプレイした事が
無いジャンルでした。
また、「条件」に関しては、もっと恐ろしいもので・・・それは、

　　　　　　　　　―――開発期間６ヶ月間―――

まあ、当時の業務用ゲーム開発では、結構短期開発と言うものがあったん
ですが、初めてディレクターをする僕にそんな短期間のプロジェクトを
クリアできるのか？？と、考えつつ持ち前の〝イージーさ〟で
『頑張らせて頂きます！』と答えて、部屋を後にしました。
大昔とは言え乗る方も乗る方だけど、そんな条件をつける方も如何な
ものかと思いますが、今考えてみるとラインナップの充実を図る為の戦略
だったのでしょうね・・・

しかし、そこからが大変。
開発期間もそんなに長く無いので、一日でも勿体無いと、その日じゅうに
関連各チームへ『僕のチームで○○なゲームを創るんだけど一緒にやって
みないか！！』と声をかけたところ、当時、僕がもっとも仲が良かった
プログラマーＦ君を中心に、入社以来腐れ縁の中堅女性背景デザイナー、
そして、女の子のキャラクタを描くのが大好きなキャラクターデザイナーの
３人が手を上げてくれました。

早速、二週間程かけてテキスト程度の企画草案を作成し、部長に持って
いったところ『これは続編とちゃうね・・・』と一刀両断。

ところが、『でも、まあまあ面白くなりそうだから、企画承認会議に
かけるんで、見切りでスタートしといて！』とのお言葉があり、何とか胸を
なでおろしチームへ報告。
これで方向性は決まり、チーム員全員、元ネタとなる機種と同ジャンルの
ゲームを研究しまくり、一気に最終までの仕様書を纏め上げました。

ここまでお話した時点で皆さんお気づきかもしれませんが、初めて
ディレクターをする際に誰もが陥りがちな問題に直面。
そうです。スタッフ一同も気づかぬ振りをしつつ、一気に書き上げた
仕様書は、僕たちに残された４．５ヶ月の期間では到底クリアできない
ボリュームになってしまっていたのです。
・・・最低でもキャラクターデザイナーがあと２人は必要である事と、全体
ボリュームを３分の２程度まで落とさないと、誰が考えても更に２ヶ月間は
かかるだろう仕様書でした。

再び部長室の扉を叩き、開発期間をもう少し延ばしてもらえないか相談
したところ、今度は怖い顔で

『あかんに決まってるやん！既に販売スケジュールも
全社的に告知したから、何とかせい！！』

とやっぱり一刀両断。

結局、まずは登場キャラクターを減らし、丁度入社して来たその年の新入
社員を引き込み、何とかチームと言える人数に増強してギリギリの線の
スケジュールの立て直しを敢行。
幸いその際に引き入れた新入社員の１人が、人や動物のアクションを分析
するのが得意だったので、思いのほかスケジュールが順調に進み、僕の
パートもかなりやってもらいました。
※当時僕はキャラクターデザイナーも兼ねていました

何を隠そう、その時の新人こそが、実は今でもアクセスゲームズで一緒に
開発をしている、ディレクターの〝富田〟その人なのです。

勿論、前作同様お約束で、僕も富田も当然のように自分で描いた
キャラクターのボイスを演じ、面白おかしく開発が終了できた事は
いうまでもありません。
※僕だけが喜んでやっていたと言う話も聞きますが・・・

大変ではありましたが、それなりに楽しく開発できたこの機種は、
大ヒットこそしなかったものの、短期開発の割にロケテストではそこそこの
インカムが取れて目標販売台数をクリアした事、そして「武○○闘」の
はしりだったり「フィニッシュ時の効果背景スクロール」や２Ｄハード
なのに「３Ｄ風パース変化」等々、恐らくこのゲームが初めてでは無いかと
思われるアイデアが幾つも盛り込めたので、初ディレクションの仕事としては
何とかミッションコンプリート出来たのではないかと、自負しています。

あっ、それから、僕はこのプロジェクト最中にめでたく？結婚しまして、
チーム員たちの非難を浴びつつも十日間ほどチームをＦ君に任せて旅行に
行きました。
開発終了までの間は、週一程度でしか帰宅が許されない、涙の「合宿生活」が
続いたのは言うまでもありません。

この機種に関しての思い出は初ディレクションだっただけに、まだまだ
あるのですが、長くなりそうなのでまたいつかお話したいと思います。

ではでは。

おはようございます。本日の当番、プログラマーのY.Tです。

最近急に寒くなりましたが、体調には気をつけてくださいね。
社内でも、咳をする人や、マスクをしている人が増えてます。
私はといいますと、他に先駆けてすでに風邪をひいた後なので大丈夫です！
・・・たぶん。


プログラムを組んでいると、予想もしないバグに出会うことがあります。
バグの原因を追いかけていくと、もんのすごく遠い場所にあったりします。
で、その原因が何かというと非数だったり、壊れたポインタだったり。
遠い異国の地で生み出されたバグが長い長い時間を掛けて旅をして、
ついに大暴れってなもんです。

単純なバグなんですけど、これを見つけるのに意外と時間を食われたりするんですよね。
ほんとに簡単なバグなんで、こんなものの為に貴重な時間が・・・
なんて事が昔は良くありました。昔は。
今では全くそんなこともなくなりましたが。
ウソジャナイヨ。ホントダヨ。


ソースが長くなるから嫌！なんて言ってエラーチェックを全くしない知人もいましたが、
少しでもバグを潰すためにも、他人に迷惑をかけないためにも、エラーチェックは行いましょう。
・ポインタを取得NULLチェックをする
・計算結果が不正なら関数の戻り値を○(お好きにどうぞ)にする
など、簡単でいいと思います。

自分ひとりで作っているなら好きにすればいいとは思いますけども、
1人でゲームを作ってる訳ではないですからね。

基本的な事なので、当たり前の事と思うかもしれませんが、つい忘れてしまうこともありますからね。
基本を忘れずに！ってことで。

おはようございます。本日の当番、プログラマーのN.Iです。

早くも１１月が終ろうとしています。
この時期は、年末商戦が近いということもあり
ゲームの新作タイトルという突風に煽られ
お財布の中のお札様が警報を発する頃合でございます。

また社内にも、その風は吹き抜けて行きます。
職業柄、社内には当然（？）ゲーム機があります。
ゲーム機がある…それはつまり、新作タイトルが遊べてしまうということです！
（もちろん、お財布の硬い紐を解かないといけませんが…）
そんな訳で、新しい風に乗った木の葉の如く
社内にも新作ゲームが舞い降り、ワイワイと開発室を盛り上げてくれます。
そして、必然的にこんな言葉を耳にする機会が増えます。
それは…

「ここの判定はどうやってるのかな？」　　　とか
「この場面、キャラの数多いのに速いよね」　とか
「背景が綺麗に作られてるよね～」　　　　　とか

ごく稀に、

「バグか？バグなのか！？」　とか
「きっと仕様でしょー？」　　とか

ってのも聞こえてきたりしますが…

そんな会話を聞いていると
新作タイトルのチェックも重要だなーと考えてしまいます。
そして学生時代に、この業界に潜入した友達から言われた言葉を思い出します。
それは、「ゲームを楽しめなくなる」という言葉です。
昔の私は、「普通に遊べば良いじゃんね？」と気楽に思っていたのですが
今の私では、「普通に」遊び続けることは出来そうにありません。
なぜなら…ゲームの捉え方が変わってしまったからです。

普段、何気なくゲームをしている際に考えていることといえば

・ＲＰＧなら、キャラのＨＰが少なくなっていないか　　とか
・ＡＣＴなら、あの穴どうやって越えようか　　　　　　とか
・ＳＬＧなら、どの拠点を攻めに行こうか　　　　　　　とか

こんな感じだと思います。
でもこれが

・キャラのＨＰ、９９９以上入りそうにないんだけど…
　１０００以上の数値が入ったらどうなるんだろう？　　　　とか

・この壁当たった瞬間、ちょっとめり込んだんだけど…
　壁の中に入ったりするのかな？　　　　　　　　　　　　　とか

・特定の画面になるとすごく処理速度が遅くなるんだけど…
　あのオブジェクトを画面外に出せば速くなるのかな？　　　とか

考え始めると、そこが気になってゲームを進められなくなります。
しかし、この疑問を解決しておくことによって、同じような場面に遭遇した際
「あの技術を使えば、もしや！？」というアイディアが浮かぶようになるのです。

ですので、ただゲームを遊ぶだけじゃなくて
もう少し細かな所まで観察すると、きっと良いことがありますよ。
「この処理がぁ～！」って悩んでいた部分が意外な事で解けちゃった、とかね。
ですが、基本の技術を知らないと疑問が解決できないこともあります。
その時は自分で調べましょう。それが世の中というものです。

…。
こんな大層なことを言いながら、今の私は
新作３Ｄゲームを買いにゲーム屋へ行ったのに
ＰＳＰで発売した某２Ｄアクションゲームを買い

特攻　→　爆死

を繰り返しているのでございます。
いくら残機が一杯あるからって…。って論点はそこじゃないですよねぇ。

私もまだまだ未熟なようです。
精進せねば…！

おはようございます　本日の当番　プログラマーのT.Yです。

突然ですが、皆さんの作られてるプログラムの関数は、
他の人が想定外の使い方をした際にはどのような挙動になりますか？

実は最近、私は尽くこれに後悔させられたからです。


たとえば最近通信処理を行っていますが。

StartSynchronizePad() ←同期開始
EndSynchronizePad() ←同期終了
IsSynchronizePad() ←キー同期しているか
IsDataSync() ←データ同期しているか

基本的にはこいつらが全てな訳ですが。

簡単な説明では、
同期開始関数が呼び出されると↓のような処理が内部的に行われます。

全員で共有しあうデータの同期
　　　　　　↓
乱数関係のシード値を同期
　　　　　　↓
キーコンフィグなどを情報を同期
　　　　　　↓
フレームの同期開始

といった流れになるので、使い方としては、
同期したデータも使いたい場合も考慮すると

「StartSynchronizePad()」を呼び出した後次のフレーム以降は
「IsDataSync()」でデータが同期されるのを待つ
「IsSynchronizePad()」で同期通信中かを確認した後から
通信対戦するゲーム処理に入る。

ここからは、全く同じ処理が全員で行われる事により、
少ない通信量で通信対戦が出来るでしょ？という訳。
ゲーム終了も同じフレーム数後に終了され、
終了時には「EndSynchronizePad()」を呼び出して、同期通信を終了する。

というのが本来の形。


これを、使ってもらうと現実には。。。。

「EndSynchronizePad()」を呼び出した後に
「IsDataSync()」でなぜかデータ同期待ちを行っていて、
実装した人に説明すると

「え？そうなん？」

みたいな事になったり。


同期通信後に、データのロード待ちが挟まってしまい、
ゲーム開始と同時にプレイヤーの座標がずれたり。
そして、「EndSynchronizePad()」の呼び出しフレームが変わったり。

結構簡単にカオスになってしまいます。


そして、私の元に、
「通信対戦中に、○○の後に画面が暗転したままストップしてしまいます」
だとか、
「通信対戦中に、キャラの座標がずれます」
といったバグとして、とりあえず飛んできます。


ですので、そんなことにならないように、
同期開始処理の呼び出しが一切行われない（または行われる見込みも無い）状況下で
同期完了待ちなんてしようとされた場合には。

assert((false)?"同期してないのに、同期待ちしてます":false));
とか
assert((false)?"終了フレームが違います":false));

とか入れてやらないといけない訳ですよ。
そうすることで
「あれ？止まった」
って時に、

assertion "(false)?"同期してないのに、同期待ちしてます":false" failed: file "source/main.cpp", line 284

とか出てくるので、ソースを見るまでもなく、原因がわかります。

まぁ、これは適当にサンプルとして書いてみただけなので、
#define YASSERT( x, mes ) assert( (x)?#mes:false )
とかして使いやすそうにするとか工夫は必要です。

そういう癖をつけておくと、そのうち幸せになれるかもしれませんよ？

おはようございます。本日の当番、プログラマーのT.Hです。

さて皆様、今回は仕様に関してのお話です。
仕様と聞くと企画的なことを想像しがちですが、まぁ役職で察してあげてください。
今回はデータの仕様、つまりデータフォーマットについてのお話です。

ゲームを制作する上で「データ」というものが必要になってきます。
モデルデータ、モーションデータ、サウンドデータ、エトセトラエトセトラ・・・
一概に「データ」とはいいましてもゲームに使用するものだけでも様々な種類が存在
します。
そして、これら全ては一定のフォーマットによって作成されているわけです。

モデルデータを例にとってみますと・・・
モデリング自体は一般的なツールによって行われ、そこから出力されたデータを使用
してゲームの画面上に表示するわけです。
しかし、あくまでこれはツール用のデータフォーマットでできているため、
当然ゲーム上では不要な情報も含まれているわけですね。

これをそのゲームに合わせた形にコンバートすることで不要な情報を省いたり、必要
な情報を追加するなりして最適なフォーマットに変更するわけです。
これはツール等で使用されているものではなく、そのゲームオリジナルのものになり
ますので製作者がエンジンに合わせた形でフォーマットを決定します。
そして、それを決定する際には必要な情報を全て洗い出す必要があるわけですが・・・

これがなかなか難儀なもんでして・・・

そもそもこの手のものは制作の序盤で決定するものなので、
今制作しているゲームではどんな情報が必要なのかというのをある程度事前に予測し
ておく必要があるわけです。
もし途中で、何かが不足しているという事態が発生した場合は、
制作の途中でフォーマットの変更するなんてことも起こりえます。
そうなると大惨事。
今まで作成したデータを全てコンバートしなおす必要が出てきたりします。

・・・

えぇ、過去に何度もやりましたし今でもやりますとも orz

とはいえ全てのことを予測することはほぼ不可能ですし、ましてやゲーム自体の仕様
変更なんてことも起こりえるわけですから完全に防ぐことはできないんでしょうね。
この辺りは経験値も必要なんでしょうけども・・・

ですので、そうなった時に如何にして対応するかという対策は用意しておいたほうが
良いと思われます。

ある程度余裕を持っておいて追加し易くするとか、
バージョンが古くても問題なく動作するとか、
バッチファイル一発で全コンバートできるとか
追加、変更がないように祈るとか・・・ orz

作成した全てのデータを一旦ツールで開いて保存しなおすなんてこと手間なのでやり
たくないですしね・・・

おはようございます。本日の当番、プログラマーのG.Iです。

突然ですが、プログラマーの皆さんは、自分のソースがどれくらいの行数か把握していますか？

私の場合は大体２０００行くらいだと思います。
というか２０００行くらいが限界です。
昔は１００００行とかいって自慢していたりしたんですが
最近になってそんなこと言っていた自分が恥ずかしくなって来ました、ほんとに・・・。

というのも、結局プログラムというのは見やすいほうがいいので、行数もやっぱり
少ないほうが良いにきまっているんです。

いいに決まっているんです！！

２０００行を超えてくると徐々にコードを探している時間が長くなってきます。最近気づきました。
さらに５０００行を超えてくるとコードを探すときに５分以上スクロールボタンをコロコロやっても
見つからなかったりします。
そんでもってやっと見つけたと思っても
今度は何で自分がそのコードを探していたかを忘れたりしていました。
そしてそして、それを思い出すのにまた５分くらいかかって
、
、
、
すごく効率が悪いです。

で、多くなったソースをどうやって少なくするかというと
まあ色々あるんですが、一番簡単なのがソースを複数に分割することです。
使用用途とかで分割しちゃいます。
そーすれば１００００行あったソースが簡単に５０００行になります。
でもやりすぎると今度はソースの数が増えてしまうので、ソース自体を探すのが大変になってきたりするので気をつけましょう。
４行のソースが７００個とかなっても意味ないですもんね。

もしそうなったら、もう地道にソースを整理するしかないです・・・ハイ。

同じコードを何回も使っていたら関数化するとか
スイッチケース文をテーブル化するとか
色々マクロ化するとか
コメント消すとか
頑張るとか
、
、
、
とりあえずとっても大変です。
でもそうやって減らしていくしかないんです。

あ、ちなみに順番はどっちを先にやってもいいです。
先にソースの整理をして、どうしようもなくなったときにソースを分けるというのでも別にいいです。
そこらへんは個人の自由ということで。
しいて言うなら、ある程度ソースの整理をしてから分割したほうがいいかもしんないです。


まあ、それでもどーしても行数が減らないって時は、

諦めてコード検索しましょうね・・・。

おはようございます。本日の当番、プログラマーのK.Yです。

ゲームを構成している要素にはいろいろなものがありますが、
その中のひとつに『サウンド』があります。

サウンドとひと言でいっても、

・各場面で流れるＢＧＭ
・何かアクションをした時に鳴る効果音
・キャラクターがしゃべった時の音声

など、様々な種類があります。

開発が進んでいきサウンドもだんだんと実装されていきますと、
ＢＧＭや効果音によってステージの臨場感が増したり、
音声によってキャラクターがより生き生きとしたものになっていきます。

このようにゲームには欠かせない要素のひとつサウンドですが
やはり実装するにあたってはいろいろなバグに直面します。


例えば、オブジェクトが爆発する時に鳴る『ドーン』という効果音。
爆発する時に１回だけ鳴らすのが正しい実装なのですが、
間違えて爆発したフラグが立っている間ずっと鳴らし続けてしまうと
『ドドドドドドド・・・』
という連続音になってビックリしてしまいます。

さらに、複数あるオブジェクトが次々と爆発した場合には
そんな連続音がどんどん増えていってしまいます。

これではＢＧＭも他の効果音もかき消されてしまい
うるさくてゲームどころではなくなってしまいます。


他には、パラメータの指定を間違えてしまったために
かわいい音声のはずが、ものすごく低い声になってしまったり、
データ番号を間違えたために、状況と全く違うセリフをしゃべったり、
緊迫した静かな場面で予定より大音量の効果音が鳴って焦ったりなど、
開発中ならではの少し面白いバグもあったりします。


あとバグとは少し違いますが、よくやってしまう（？）ミス。
それは一番最初にサウンドを鳴らそうとする時に起こります。

やはり最初の実装となると関数を呼ぶ順番がおかしかったり
数値の設定を間違えたりで、なかなか一発では音が鳴ってくれません。

おかしな箇所を見直して再びチャレンジ。
やはり音が聞こえません。

あれ？おかしいなぁ。
・・・
テレビの音量がゼロのままでした。


このようにいろいろなバグを経ながら実装しているサウンド。
ゲームをプレイする際にはそんなサウンドにも耳を傾けてみてください。
新たな魅力を発見できるかも知れませんよ。

おはようございます。本日の当番、プログラマーのM.Oです。

11月半ばを過ぎ寒くなってきました。この時期は年末にかけて
大量にゲームが発売され、何を遊ぶか迷ってしまいます。
私は迷って買ったゲームを楽しみつつ、気になった処理を
自分ならどのように実装するか、ゲーム性、操作性、画面構成等が
「何故そうなったのか？」と考えるようにしています。

というのも、仕様等でプログラマとして意見・提案を言うことがありますが、
ゲームの方向性が分かっていないと意味がないものになってしまいます。
自分がこれはいいんじゃないかなと思っても、
全体のバランスから見てありえないものだったりします。
あまりにもお馬鹿な発言をしてしまうと、周りから生暖かい目で見られますが、
私はＭじゃないのでそんな目で見られたくはありません。

そのように見られないためには、関係書類を読み担当者と話をして、
どのようにしたいか確認する必要があります。
で、理解するために無い頭をひねって考える必要があるんですが、
考え方の参考に、既存のゲームを見て考えた事が生きてきます。

他にも仕様書を読んでいて、違和感を感じることがあります。
自分の勘違いってことも多々ありますが、穴があったり、矛盾していたり、
方向性がずれている場合などがあります。
この時の違和感の原因の見定めや、プランナーとの意思疎通にも
既存のゲームを見て考えた事が役に立ちます。

このように企画意図を考えつつ、プログラムを組むように心がけています。
しかし、プログラムは組まれたとおり動くのですが、
自分の考えた様には動かないことがあります。
そのような時、「何故そうなったのか？」を考えるわけです。

みなさんも、普段と目線を変えて、何故そうなったのか？
と考えてみてはいかがでしょうか？
普段と違う楽しみ方ができるかもしれません。

おはようございます。本日の当番、ゴルファー兼プログラマのJ.Kです。
最近なぜか雨中でのプレーの多さと不調のため、少々へこみ気味です。


さて、本日はこの業界に入ってから聞いたまことしやかな噂？等のお話を。


この仕事をしていると、自分のデスクの周りにいろんな機材がずらりと並びます。

プログラマである私のデスク環境はというと…

まずは、プログラム作業を行うためのメインＰＣ。
次に、開発中タイトルの対象プラットフォーム開発用機材。
そして、ＴＶモニタ。
※もちろんメインＰＣのモニタもありますよ。

これが最低限の機材セットです。

この機材セットが、プログラマの人数分揃うわけです。

他にも、デザイナーやプランナーの機材や、サーバー等、様々な機材で社内はてんこもりです。

これらは電源を必要とする電子機器ですから、多かれ少なかれ「電磁波」を放出します。

ここで、まことしやかな噂が花開きます。


「体温が上がって熱っぽいと感じるのは、電磁波による電子レンジ状態だからだ！」


とか


「電磁波を浴び続けると、将来生まれてくるであろう自分の子供は、全て女の子になる！」


とか


「世の中には電磁波を防ぐ『電磁波防御エプロン』なるものがあるらしいぞ！」


とか…


どれもこれも根拠のない話なので、当時は冗談、というか笑い話的に使われていました。


が…


実は「電磁波防御エプロン」は存在しました。
※「電子レンジ」と「全て女の子」は不明。

私が社会人２年目の時の後輩女性社員が、なんと「電磁波アレルギー」だと。


なんだ「電磁波アレルギー」って！
難しい言葉を並べて、体調が悪い振りをして、仕事をサボろうとしてるな？


とか、ひどい思考で勘ぐったりしていました。

しかし、そのうち彼女は「電磁波防御エプロン」をして、自分のＰＣに向かっていました。


「電磁波アレルギー」って本当にあるのか…


その時の驚きと、彼女に対してひどい思考をしてしまった恥ずかしさは今でも覚えています。

エプロンだけでは防ぎきれなかったのか、その後、残念ながら彼女は退職されました。


自分が知らない事や、ありもしないと思いこんでいる事を、面白おかしく話すのはいけない事だ…

それを彼女に教わりました。


そして「まず自分自身が無知である事を知ろう」と思いました。


そう、いわゆる「無知の知」です。
これは非常に大切な思考だと思います。

知らなかったら調べよう。
調べたら理解しよう。
理解したら活用しよう。

今の私を支える考え方となっています。

おはようございます。本日の当番、プログラマのY.Hです。

今回のお題はエイジングについてです。
一般社会では聴きなれない言葉かもしれません。

エイジングとは開発機などでゲームを一定時間放置状態にしておき、正しく動作しているかどうかの耐久テストを行うことです。

このエイジングはプレイ中のときのみならず、タイトル画面やメニュー画面などいろんな場面で行います。
長い時は半日～１日間、ずっと放置して耐久テストを行います。

電気代がもったいない！という人もいるかもしれませんが、これはゲームの安定性を図るのに、非常に重要な作業なのです。

まぁ確かにＰＣ本体と開発機を点けっぱなしにするわけで、それも１台２台レベルじゃないので電気代は、かかりそうですが…。

また、ただ放置しているだけではなく、一定時間でゲームを終了させて、違うパターンでもう一度ゲームを開始させるといった自動化プログラムを走らせておくことも重要になってきます。

一概にエイジングといっても、ただ放置する以外にもいろいろあるのです。

こうした作業が行われて、安定したゲームが完成していくわけですね。


それでは、このあたりで失礼いたします………あれ？
誰か来たみたいですね。

え、なになに？僕の部屋の電気やテレビが点けっぱなしだって？
いやいや、それはエイジングしていたんですよ。

おはようございます。本日の当番、プログラマーの大川です。

今回は「パッチ処理」について考えてみようかと思います。
プログラマーの方にとっては、あまり聞きたくない言葉では、と思います（汗）

さて、一般的にパッチ処理とは、バグ修正や機能変更を実装する行為を言います。
当然、パッチ無しで動けば無問題（天才！）なのですが、現実的にはそうはいきません。
プログラミング作業の何処かしらで、必ずパッチ処理は必要になってきます。

パッチ処理の手法も色々あると思いますが、「部分的な修正のみを行う」か、「一切合切ソースを組み直して丁寧に修正するか」のどちらか、だと思います。

私の場合、時期にも依りますが、基本的には後者を採っています。
修正に時間が掛かったとしても、他に簡単に直せる方法があるとしても、あえて後者です。

何でそんな面倒な事をするのかと言いますと…、

基本的にパッチ処理というのは、増えれば増えるほどソースの構成が乱れてしまいます。
修正当初は「ここだけ汚くてもいいか～」と思っていても、更に修正～またまた修正、という工程が増えれば、メンテナンスも放棄したくなる事態となります。

処理の見通しが悪くなると、更なるバグを併発する可能性も出てくる訳で、そうなると管理する情報量が増える分、作業効率も散漫になってしまいます。

それを回避するため、ソースの全体構成を見直し、再構築することにしています。
ですが、いちいちそんな事をしていたら、時間だけを浪費する事になりますし、組み直しの過程によるバグ発生の可能性も無視出来ません。実際、余計に酷くなったこともあります。

でも、敢えて後者です。

何故かというと、プロジェクトの後半に備えた、ある程度の「余裕」を持たせる必要があるからです。
ここでいう「余裕」とは、ある程度のバグ修正を繰り返すことが出来る「管理的な余裕」を言います。

これまでの経験上、プロジェクト末期になると、パッチ処理（前者）が大量に発生します。
「ここは安全でしょ！」と思っている箇所にまで及ぶ事もありました。

ですので、そんな事態に備え、プロジェクト中期までは後者、末期では前者、という感じにしています。
プロジェクト中期までは面倒な事は多いですが、最終的に「助かった～！」と思う局面も多々ありました。

是非、ご参考に！

…、

書いてて、ふと思いました。

「パッチ処理の必要が無いプログラムが書ければなぁ～」と。

否！なかなか無理です（汗）
というか、おそらく一生無理なんじゃないかしら（泣）

おはようございます。本日の当番、プログラマーのM.L.Kです（LはのLittleのLです、Little&Big!）。

ある調査によると、コストの制約を伴う状況で、グレードの異なる３つの選択肢が与えられた場合、多くの人が、２番目のグレードを選択する傾向にあるそうです。

まあ要するに、財布ん中ぼちぼちの人が、“松”・“竹”・“梅”のいずれかを選べ、って言われたら、大抵の人が、“竹”を選ぶ、っちゅうアレです。

最近まで、これは“日本人の性格上～”、といった文脈で語られがちだったのですが、どうも、これは全人類に共通した性質みたいです。
行動経済学だとか、心理学だとかでは、ほとんど常識なんだそうで。

さて、16とか256とか65536とか、とにかくキリの良い数字が大好きなプログラマは、
「う～ん？だいたいそのあいだくらい？」
とか言われると、イラッとします（←ちょっと余裕なさすぎ）。

もっとも、ゲームのプログラミングは、曖昧な世界をデジタルに表現していく過程とも言えますので、そのどちらつかずな曖昧さを何とかコンピュータが理解できるようにしなければなりません。

２つの値の間を変動する数値を求める際、以下のような実装を行う場合があります。

α(1-t) + βt [0≦t≦1]

αとβとの間にある値を比率ｔを用いて表すやり方ですね。
ｔが0.5だったらちょうど半分、0.3だったらちょいα寄り、みたいな。

αとβのように単なる値だと、まあ、しょうもない話なんですが、ゲーム製作の現場では、もっと抽象的な要求が出る場合もままにあります。

例えば、
「ほとんど直線っぽくまっすぐなカンジなんだけど、やや曲線に曲がるカンジ？」

…


(ノ゜皿゜)ノ彡┻━┻

注）誤解のないように敢えて注釈しますが、プランナーやデザイナーがいい加減である為にこういった指示が生じているワケでは、決してありません。
それくらいに微妙で複雑な機微のやりとりをして製作する必要があるのです。


先ほどの式は、αとβの部分を、数式にすることもできます。
Ｆをf(x,y)、Ｇをg(x,y)の関数として、

Ｆ(1-t) + Ｇt [0≦t≦1]

上の例えで言えば、Ｆに直線の式、Ｇに曲線の式を入れて調整することになります。

余談ですが、ＦとＧをそれぞれ任意の曲線（曲面）の式にして、ｔが連続的に変化する様子を表現すると、いわゆる“モーフィング”の処理になります。映画なんかで使われているものは、色情報なども対象となるので、もっと複雑ですが。

ゲーム製作にはハードスペック等のどうしようもない制約が伴いますので、心に描くクオリティはなかなか実現が難しいものとなります。少しでも思い通りのものを作りたくなるのが人情。

そんな心情を察して、プログラマはそっと品書きを出すワケですよ。

松：f0(x,y)+f1(x,y)+f2(x,y)…+fn(x,y)　数式入れれば思うがまま
竹：Ｆ(1-t) + Ｇt [0≦t≦1] ｔを０～１の範囲で調整できちゃう
梅：f(x,y)　予め決まった曲線だけだよというか、直線？

…
つ┳━┳
ちゃぶ台、おいときますね。

おはようございます。本日の当番、ＣＧデザイナーのT.Nです。

近頃、急激に寒くなり社内でも風邪が流行ったり流行らなかったりの日々。
マスクを装備する人もチラホラと目にします。
時代はまさに、大マスク時代に突入したといっても過言ではないでしょう。

私も流行りに敏感な人間なので、このブログをマスクしながら書くと決めました。
このままマスクをし続けると、いずれは波紋が使えるようになると信じています。


さて、話はすごい勢いで変わりますが（時代の変化にも、話の変化にもついてこないとダメだぞ！）プロジェクトが一段落した時など、手が空いた社員は別のプロジェクトのヘルプに回されることがあります。

他のプロジェクトでも、自身の職種では人手が足りている場合、ちょいと、違う仕事が回ってくることも稀にあります。

かく言う私も、デザイナーでありながら、プランナーのお手伝いとして現代の叡智と名高い「すくりぷと」と言われる、謎の文字列を扱う機会を得ました。

私の、いと小さき脳みそでは、その文字列は、古代ルーン文字と見まがうほどの難解さ！！

初めは説明されても、脳みそが理解することを拒絶するかの如くほとんど、頭に入ってきませんでしたが、最近は少しずつわかってきました。
そうしてくると、いままで知らなかった世界が見えてきたような気がします。

これまでは、
「あいつ、いまスクリプトやってるらしいぞ」と噂で聞いても

「へ・・・へぇ～すくりぷとね。いいね、あれ。流行ってるらしいし！！
え？知ってるよ？俺、すくりぷと、ちゃんと知ってるよ！！
・・・・音楽・・？
じゃないよねー！そうだよねー！ジョーク！It's　ジョーク！ハハッ。
いや、マジ知ってるって！！ちょ・・・！！なんだよ、その目はぁ！！」

と、単語だけ知っていて実際何をしているのか認識していませんでしたが色々な仕事に触れて、その仕事内容を深く知ることができるとゲームがどういう風にできて行っているのかがさらに理解できていい感じです！

また、他の人の仕事を理解することによってその大変さがわかって。
なんか、その人に優しくできる・・・そんな気がするんです。

そうなってくるとスクリプトというものを言葉ではなく、心で理解したような気すらします。

自分の仕事を一所懸命こなすのは、非常に大切なことですが、周りのことも理解しながら、温かく、時に厳しく仕事ができると素敵ですね。



そしていつの日か、緊張でチワワのように震えてる新入社員（美少女）がスクリプトについて質問したその時には、声を大にしてこう答えたい。




「ルーン文字です！」と。

おはようございます。本日の当番、ＣＧデザイナーのH.Mです。

日頃から使っているものには愛着が沸いてくるものですよね。
季節の変わり目と同じくして、先日部屋の模様換えを行いました。

「いらないものはこっち」とか「いるものはあっち」とか整理していたのですが
模様替えにかなりの時間を費やしてしまいました。

なぜなら、捨てる予定のものに愛着が沸いていたのです。

前から「これはもう使わないから捨てようか～」と思っていたものが土壇場になって「お願いだから捨てないで～」と訴えてくるのです。
まあ僕の決断力不足なだけですけど・・・・。

古い雑誌を読み返したり、何を書いているのかわからないプリントにも目を通してみたり・・・・。
「やっぱりいるかも・・・・いや！いらんでしょう」
とか迷っているうちに時間が経過してしまったのです。

最終的には、心を鬼にして「さようなら今までありがとう」と
悲しみの別れをしましたが・・・・実際は捨てずに残していますけどね（笑）

会社にも愛着が沸くものがあります。

何処となく、しっくりくるマウスや自分の目線に調整しているディスプレイ。
文字を打ったときの感触が心地すぎるキーボード。
仕事中も姿勢を崩さないように調整された椅子など。

自宅にあるもの以外でも日頃から使っていると愛着が沸いてきます

絵を描いてる時も同じ感情が沸いてきませんか？

私は、自分が満足するまで調整したり、描いた絵を人に見せて指摘を受けると「もっと良くしたるぞー！」と愛着が沸いてきます。

作品を良くする大きな原動力ですね！

多くの人の意見を取り入れて「この絵もっと良くなる！良くなる」とわが子のように、愛情を持ちながら作るとすばらしい作品に仕上がる可能性があります。

普段抱いている感情が開発に影響を及ぼすことも少なくありませんね。

おはようございます。本日の当番、ＣＧデザイナーのK.8です。

自宅に液晶TVを買いました。薄型TVを手に入れるのはもう少し先でいいや、と21インチブラウン管を使い続けていたのですが、我慢しきれずに入れ替えちゃいました。大画面のHD画質に感激しています。

自分はゲーム開発者として、なるべくいろいろなゲームをプレイすることを心がけています。普段は食指を伸ばさないようなゲームジャンルや、携帯機、次世代機と、幅広くプレイしてみてます。しかし近頃、次世代機のゲームタイトルをプレイするのが大変になってきました。目がショボショボしちゃうのです。そりゃ、年のせいだとか、はい、そこ言わないで。

最近のゲームはグラフィックが向上して解像度の高いものが増えました。解像度が高くなるにつれて文字は小さくなってきていて、コンポジットで接続した小さなブラウン管ではボケてつぶれがちです。FPSの洋ゲーなどをプレイすると、字幕をリアルタイムで追うことができません。「突入経路を辿って退避しろ！」とか出ても漢字がつぶれて読めず、まごまごしているうちに死んでしまってやり直し。つぶれた字幕を目を凝らすように見続けてゲームを続けるのが辛く、何度も途中で投げ出してしまいそうに…

字幕なんか読まなくてもリアルタイムで英語のセリフが聞き取れるなら無問題なんですけども、そんなスキルはありません。文字がくっきり見えるよう、大画面の液晶TVに頼ることにした訳です。これで、「俺が突入するから援護しろ」と言っているのが分からず、一緒に突入して全滅したり、「奥の階段を上がって脱出しろ」と言っているのが分からず、沈み行く艦船と運命を共にしたりすることもなくなるはずです。…あれ？するはずなのになぁ。おかしいなぁ。字幕を読めたところで、うまく行動できるかどうかは、また別の問題とか、はい、そこ言わないで。

薄型TVの普及率は上がり、多くの家庭が高画質大画面でゲームをプレイできるようになってきました。ソフトメーカーもそれに合わせた絵作り・文字の大きさに変わってきてます。ゲーム開発者として高画質にはしつつも、なるべく多くの人に読みやすいよう、文字の大きさ・見易さに気をつけて行きたいところです。

…なんて、いろいろ書きましたが、液晶TVを買った理由の大部分は、先日発売された弊社開発担当の「スカイ・クロラ　イノセン・テイセス」を大画面・高画質でプレイしたいからなんですけどね！

おはようございます。本日の当番、ＣＧデザイナーのH.Fです。

もう11月です。
なんだかんだ言って暑い日が尾を引いてますが、いかがお過ごしでしょうか？
30過ぎたオヤジな僕ですが、基本的に赤ちゃん体温なので中途半端に暑いもの
は困りもんです。

第一に着る物に困ります。出掛ける為に着ていく服が無いとかそういう話では
なく、暑いのです。

といっても肉が一杯付いてるわけも無く、比較的痩せているほうです。
でも暑い、、、。

特に電車の中などでは、オシャレな革ジャンなんか着ていられません。
カッコつけて上着を着ているハズなのに、僕だけが汗をポタリと垂らして情け
ない姿になります（泣）。

モヒカン頭の涼しそうな頭のツレに、「どんな気分だ？」とツッコまれた事も
懐かしい思い出です、、、。

いやまあ、あの冬場の電車内の暖房も、たまに暴力的に暑い時もあるので一概
にも僕の赤ちゃん体温のせいでは無い場合もあると思います、、、たぶん。

まあ、冬場で電車の中で汗かいて、真に何が一番の問題かというと、今度は外に
出ると寒いのである。
最初は心地よく涼しいのですが、次第に汗が体を冷しに掛かってきやがります。
なんという、体を酷使するコンボ。

すると、今度は風邪を引くという、、、。たまらん、、。

前置きが長くなりましたが、、

まあ、こういう経験をしていると、背景のデザインを考える時は、暑くも無く、
寒くも無く、不快でなく、快適で心地よい空間を考えたくなるのが人情です。

ですがゲームのデザインを考える者にとっては、それだけでなく微妙で不快な
空間を作成するデザイン案なども提案しなければなりません。

そう考えると、こういう暑くて不快な経験も逆に考えると、今後の製作に生かせ
られると思えば悪くないのかなぁ、、、と思う今日このごろ。

ちなみに昔からよくレストルームを作る事が多かったのですが、昔は偏見があり、
「何で便所なんか作らなアカンねん」と、心の中で叫んでいた頃がありましたが、
それも逆に考えると、実に良い経験をしたもんだと。

おはようございます。本日の当番、ＣＧデザイナーの西出です。

数年前からイームズの椅子を数脚購入しています。
イームズは家具に興味をお持ちの方であれば、一度は聞いた名前だと思いますが、

アメリカのデザイナーの名前で、主にインテリアデザインでは、
夫婦で名を連ねて「チャールズ＆レイ・イームズ」と表記されているのがそれです。
夫のチャールズは建築家や映像作家でもあります。
詳しくはネットで調べてみてくださいｗ

最近はミッドセンチュリー（1940～1960年代）のインテリアデザインを
総称する名前として、しばしばネット上で使用されているようですが、
全てがイームズではありません。

イームズで有名なのはシェルサイドチェアーと
ラウンジチェアー＆オットマンでしょうか？他にもいろいろありますが・・・
この前イームズ家具の中でも定番中の定番？である
ハーマンミラー社製のシェルサイドチェアーを購入しました。

出来るだけレプリカは避けて当時の本物を持ちたいとオークションで
70年代に作られた製品を手ごろな価格で購入しました。

４０年前のものなのでそれ相応に汚れてはいましたが、
これがなんともまあ実によろしい具合で、
実物を使用して感じた事が、何点かあります。

　・どんな部屋に置いても主張しすぎず
　・どんなシチュエーションにもあう
　・尚且つ、実に飽きがこない一体形成された滑らかなフォルム
　・それでいて機能的である

４０年も前に生み出されたものなのに、全く色あせを感じないデザインは、
時代の流行に囚われない何か普遍的なものを有しているようにも思います。
テレビゲームも同じように、今まで数え切れないほどのタイトルが生み出されてきました。
多くがその時代のトレンドに合わせて生み出されたものだと感じていますが、
最終的に残るのは、前述した普遍性をどこかに秘めているものなのだと
最近感じています。
それが良いか悪いかの話はしていませんのでご了承ください。

なにかこむつかしい話になりましたが、要は旬を過ぎてもロングランで遊べる
唯一なテレビゲームをデザイン出来るように日々邁進したいなと、
イームズチェアーに座りながら思いに浸ったお話でした。

ちなみにイームズチェアーの１脚は花柄ですｗ

おはようございます。本日の当番、新人モーションデザイナーのK.Iです。


日頃あくせくしながら仕事をしていると、気付かない所でミスが起きてしまうことが、
今日までに沢山ありました。
そんな時、僕の場合は一度０に戻り、過去を辿り返しています。
当然時間はかかりますが、過去に遡って辿り返してみれば、
必然的に目的地へ到着できるものです。
もし到着できなかったら順序が抜けているということ。
ピンポイントで、ミスした原因を思い出すよりも効率的です。

このアイデアは職場だけじゃなく、様々な場所や状況でも役立っています。
例えばこんな場所でも…



この写真、一見普通の倉庫に見えますが、実は大型インテリアショップの店内に
ある購入用の商品を格納してある倉庫なんです。

と、いきなり言われても「？？？」な人も多いと思いますが、
この倉庫へ辿りついた経緯の中に、あのアイデアが活躍しているんです。

関西某所、とある大型インテリアショップへ行った時の話です。

本社をスウェーデンに置く有名な人気ショップです。
その人気の秘密は、非常にリーズナブルな商品が購入できる事、
そして「完全セルフサービス」だという事です。

店内に入るとまず目に付くのは数々のショールーム。
そして通路には矢印が足跡のように伸びていました。

その矢印は各ブースに繋がっており、
僕達買い手は矢印を辿りながら商品を選んでいきます。
例えば、

本棚やソファなどの大型家具
↓
カーテンやカーペットなど
↓
キッチンやバス回りの小物などの生活用品
↓
間接照明や食器、観葉植物などなど
↓
巨大倉庫
↓
そしてレジ

気付いた時には生活に必要な物が必然的に集まっているという、
上手すぎる購買方法もといセルフサービス！
驚いた事に、ちょうどいい距離を歩いた先に、
飲食エリアが設けてあり、しかもバイキングという徹底したセルフっぷり。

にも関わらず、買い忘れや、衝動的な購買意欲などが出てきてしまうのが、
人間です（僕だけ？）

こんな時に順序を設けてあげると、カーテンを買い忘れた！なんてミスも、
「キッチンコーナーの手前まで戻ろう」と冷静に判断し対処できます。

コーナーが個々に設置してあると戻りたくても、
「どこだっけ？」なんて事になりかねません…

どうでしょう、まるで自分が発案したかのような言い回しですが、
実は上司の教えです。
仕事の中でも日頃、順序を作っていければもう迷うことは、ない！
…と切に思う今日この頃です。