スタッフBLOG

おはようございます。本日の当番、ディレクターのSWERYです。

暑かった夏もすぎ、ようやく涼しい季節になってきました。

食欲の秋、スポーツの秋、読書の秋・・・いろいろな秋がありますが、
皆さまにとっての秋は何の秋ですか？
ちなみに私SWERYにとって、秋は「おしゃれの秋」です。
頑張っておしゃれするぞ。



で、で、で、で、話は変わりますが本日は憤慨…ではなくニコニコであります。

それは、会社に「お土産」と呼ばれる、すてきな贈り物があるから。

「お土産」…それは旅行や出張などで、遠方へ行ってきた方々からの無償の「愛」。

バカンスで羽を伸ばし、または仕事で見知らぬ土地を踏みしめながら、現地で起こったであろう新たな発見に感動する。
そしてその喜びを、ゲーム制作の修羅場で日々格闘する我々に共有させてくれる愛のツール…それが「お土産」なのです。


ゲーム業界（特に弊社）で働いている場合、いろいろな場面でお土産を買うチャンスがあります。
が、中でも最もポピュラーなのは…

「アップ休暇」でしょう。


プロジェクトが無事にマスターアップを迎え、そのご褒美に会社から休暇が貰えちゃうわけですが、それを使って旅行！！って人は結構います。

プロジェクト単位でのお休みなので、とあるプロジェクトでアップ休暇中の人がいれば、まだまだ佳境のプロジェクトに参画している人もいる。
ですから、国内外問わず土地柄を感じさせるすてきな「お土産」が、戦場真っ直中のゲーム戦士の元に届けられることになるわけです。


たとえ代わり映えしないオフィスでも……一口「お土産」を頬張れば、一瞬にして世界とつながることが出来ます。



紀州の梅干しを食べたなら、
　　　目の前には白浜の浜辺が広がり…

ベルギー産のチョコレートを口に含めば、
　　　噛むたびに欧州の石畳の音が聞こえ…

アメリカのギッタギタのお菓子を口に含めば、
　　　サンタモニカの日差しやE3会場の喧噪が脳裏によみがえり…

また、某巨大テーマパークのクッキーをかじったなら、
　　　『手袋と蝶ネクタイのネズミさん』が
　　　　　　ニコニコと駆け寄ってくる様子が再現される。



ビバ！お土産！！

まさに、天からのギフト…世界で最初にお土産を贈った人、ありがとう。
僕も自分が買う際には、企画力を発揮して、喜んで貰えるように頑張ります。
　※その前にプロジェクトを完遂させるように頑張ります（汗


とまあ、いろいろと話してきましたが………

結局、何よりのお土産は「その人が無事に帰ること」と、楽しい「土産話」なのです。
読者の皆様、そしてスタッフの皆々、旅行の際には十分気をつけましょう。

おしまい。

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

前回の次回予告では、私が初めてディレクター職に就いた際の事を予告していましたが、ディレクターをやる直前に開発したゲームのちょっと変わったエピソードを書き忘れていましたので、そちらのお話をしたいと思います。

それは、当時プランナー兼デザイナーの僕が、自分の開発するゲームに登場するキャラクターのボイスをやらせてもらえた、と、言うか、やらないといけなくなった・・・という体験談です。

当時、ゲーム内で使うボイスは、あまり費用をかけないパターンが多く、殆どがサウンド開発者が付き合いのある劇団の、それほど有名ではない役者さんにお願いしていました。
※劇団員さんの良い収入源になっていたと聞いています

しかし、今回のゲームでは、主人公を含むキャラクターがアニメチックであったので、当時のディレクター意向により、キャラクターはボイスもきちんとした声優さんを起用しようと決まりました。
そして、キャラクターイメージに合う声優さん候補を幾つかあげて、各種プロダクションに見積もりを依頼しました。
数日後、サウンド担当者より見積もりが出揃った報告があり、その金額を見て一同びっくり！！

そもそも、本格的な声優さんに依頼した事がなく、ギャラの相場自体知らなかった私たちにはそれはもう、驚愕の費用でした。
※今では、ゲームデモにプロの声優さんを起用するのは当たり前で、驚く開発者はいないと思いますが・・・

とは言え今回はプロの声優を使おうと決めていたので、一同気を取り直し、詳細を確認していくと、第一候補と第二候補以下に挙げていた方のギャラとの差が〝３倍〟以上もありました。
「さすがにこれは何かの間違いではないのか？」と、再度、プロダクションに見積もりを依頼。

再見積もりを取った結果、やはり前回と同様の金額だったので、何故こんなに高いのかと確認したところ、なんと「第一候補の方は、アニメがきっかけで本人自身がTVに出演したりしており、ギャラが跳ね上がっているんですよ」
との回答・・・TV業界恐るべし！！

サウンド担当者からも、「それでなくてもサウンド開発予算は少ないのに、もしその声優を使う場合、殆ど予算がなくなりBGMやSEにお金をかける事が出来なくなりますよ」と説得され、ディレクターはしぶしぶ第二候補の声優さんと契約する事となりました。
それでも、その会社では初の「アニメ声優起用」と言う事で、それ以降のゲームでもプロの声優を使うようになりましたので、良いきっかけだったと思います。
※因みに僕は第二候補の方の出演作品の方が好きだったので、心の中では小躍りした事を覚えています

勿論、開発スタッフという事で私がその声優さんのボイス収録にも同席させてもらった事は言うまでもありません。

・・・で、いつ、自分がキャラクターのボイスをする事になった話になるのか？ですが・・・
主人公は何とかプロの声優さんで収録したものの、それでも当時のサウンド開発予算のかなりの金額を使ってしまった為、結局、もう一人の声優さんの費用を捻出するのは厳しいと言う話になり、ディレクターから「じゃあ、主人公以外は社内スタッフでやろう！」の一言で、キャラクターのボイスをする事になりました。

近年、現行の家庭用ゲーム機に移植されているのを知人に教えられ、一応記念に購入し、聞きなおしてみましたが、まったくお粗末な演技？で、今考えると良く会社も許したな！？と思います。

・・・勿論、恥ずかしくて家族にも聞かせていませんです、ハイ。

長々と書いてきましたが、いよいよ次回こそは本当に、僕が始めてディレクターをさせてもらった際の涙のエピソードをお話したいと思いますので、興味ある人もない人も次回当番をお待ちください。

ではでは。

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

みなさんはプログラムを組んでいく前に、しっかりと考えてから作っていますか？
何となく組んでいってはいませんか？
それではいけませんよ！
その都度必要なものを追加して、削除して、変更して・・・気付けば手をつけられない状態になってますよね。

一度作ったらもう二度とさわらない！
ぐらいの意気込みでしっかりと考えてから作っていきましょう。

例えば、超簡単にこんな感じで。

class CClassCount
{
public:
　void Set( const int iBoy, const int iGirl )
　{
　　m_iBoy　 = iBoy;
　　m_iGirl　= iGirl;
　　m_iTotal = iBoy + iGirl;
　}

　int GetTotalCount( void ){ return m_iTotal; }
　int GetBoyCount( void )　{ return m_iBoy; }
　int GetGirlCount( void ) { return m_iGirl; }

private:
　int m_iTotal; // 総人数
　int m_iBoy;　 // 男子
　int m_iGirl;　// 女子
};

これは1クラスの人数を管理するだけ。
成績などは別のクラスで。

class CClassGrade
{
　・
　・
};

class CClass
{
　・
　・

private:
　CClassCount m_Count;
　CClassGrade m_Grade;
};

とまぁ、こんな風にすれば一つのクラスにすべて詰め込んでこれが足りない、あれは必要ないと
ごちゃごちゃ変更して訳が分からなくならずに済みます。

・・・とは言ってみたものの、実際作っていくと気がついた時にはぐだぐだになってたりするんですよねぇ。
わかりますよ。私もそうですからね orz
はい、すいません、頑張ります！

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

さて、直球ですが・・
みなさんは、プログラムを書いてて、とりあえず一つの関数で大丈夫だろう・・・
とか思いながら関数作って、その中に処理を書き始めたりしませんでしょうか？
少なくとも自分は結構そうなりがちです。。

そしてその関数はいつの間にか数百行の膨大な関数化してしまった状態で、とりあえずその場では完成したかのような挙動で動いてくれます。

これ、後から分けようと思ってても案外忘れてそのまま放置されたりしがちです。
この後何もなければ良いのです。　何もなければ。。。

ただ、実際の現場で開発してると、確実に何かが起こるのです。
追加、修正、バグ、マスク等々

作ったことすら忘れた頃に修正作業する事になったときに、改めてみる過去の自分のコード・・・　自分で書いたコードでありながら、軽い殺意が芽生えます。。。

こうならないためにも、最初からある程度小分けに関数レベルで作って実装することをお勧めします。


その中で、つい最近閃いて作った処理がこんな感じです。


void funcA()
{
処理A
}
void funcB()
{
処理B
}
void funcC()
{
処理C
}
void funcD()
{
処理D
}

FUNCPOINTER FuncTable[]=
{
funcA,
funcB,
funcC,
funcD,
NULL
};


void Operation( FUNCPOINTER *pFuncList )
{
while(pFuncList != NULL)
{
(*FUNCPOINTER(*pFuncList))();
++pFuncList;
}
}


void funcMain()
{
Operation(FuncTable);
}


因みに元の処理は・・

void funcMain()
{
処理A
・
・
・

処理B
・
・
・

処理C
・
・
・

（以下略)
}

下の場合だと、funcAの処理とCの処理を入れ替えようとか思ったときには、ある程度の行数を選択して、コピペとかになったりで、その時点でグチャグチャになったりとかなり扱いづらいです。

その点新たな実装方法の処理だと、FuncTableの順番を

FUNCPOINTER FuncTable[]=
{
funcC,
funcB,
funcA,
funcD,
NULL
};

このようにすれば簡単に入れ替え出来ます。

また新たに、処理追加が必要になった場合にも、(仮にfuncEとします)

FUNCPOINTER FuncTable[]=
{
funcA,
funcB,
funcC,
funcD,
funcE,
NULL
};

となるわけです。

なんにしても、短時間でサラッと作ったような構造なので、改善の余地は大量にあるような気もしますが、今のところはショボンとなってないので、ヨシとしてます。


まぁ、何にしても皆さんもいろいろ試してみてくださいということです。。。

そして、新たな試みとしては、最近、某バーチャル歌姫がウマウマなダンスをするベンチマークを見かけ、ここ最近仕事以外であまり個人的にプログラムする事もなかったので、新たにシェーダの勉強と、その他諸々・・・・
そして。
「オレもウマウマさせてみたいなぁ。。」
という欲望の中何か作ってみる予定ですが、それはまたいつの日か。。。。

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

さて皆様、プログラムにおける関数の作成に置いて重要なこととは何でしょう？
処理速度？
汎用性？
当然それらも重要だと思います。
しかし、最も重要視すべきはインターフェースの容易さではないかと思います。

関数とは便利なものです。
同じ処理を作成する必要がなくなりますし、新しく作成するよりもバグの心配が少なくなります。

故にそれを使用するのは作成した本人だけとは限りません。
となると、誰が見てもわかりやすく誰でも使用できる形が理想となります。

プログラムの規模が大きくなっているこのご時世。
これらを軽視してしまいますと・・・
・指定する引数の数が多いとか
・使用するまでに一定の手順を踏まなければならないとか
・ことあるごとに引数が追加されるとか
という関数が出来てしまいます。

結果的に・・・
・使い方がわかりづらく混乱する
・使い方を間違える
・作った人に対しての怒りが沸いてくる
などなど、良いことなんて一つもありません。

僕の場合よくやってしまいがちなのは、手順が複雑になってしまうパターンです。
例えば・・・

　Flush();
　Begin();
　Reset();
　index = Convert(id);
　data = Get(index);
　data->Draw(x, y, uv, color, tex); ←これが目的の関数
　End();

ご覧の通り目的の関数を１発で呼べません。
しかも手順を間違えると正常に動かないというオマケ付き。
こんな関数だと使う側も鬱になってしまいますよね・・・

・・・えぇ、怒られましたともいろいろなところから。 orz

このようなことにならないように、必要な処理を洗い出し、取捨選択、細分化。
同じ処理でまとめられる場合はまとめるなどちゃんと設計してあげましょう。
すると皆が少しずつ幸せになれます。

どうしても複雑な関数が生まれてしまいがちですが上記のことを念頭に置いておくと別の良い方法が見つかるかもしれません。




僕もがんばります。 orz

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

プログラムのコードを書いていると色々確認しなくてはいけない事が出てきます。
バグがないかどうか、効率よくコードが書かれているかどうか、自分以外の人が
見ても分かりやすいコードになっているかどうか、、、。
などなど色々あります。

その中でも、最近特に大事だと思ったのは、
”これから作成予定のプログラムを、他の人が既に作成していないか確認する”
事だと思います。

細かい計算ルーチンとかでも、チーム内の別の人がすでに作成していたとかが
よくあります。他の人が作成していなくても、実はライブラリでサポートされて
いたりとかもよくあります。

これをやっちゃうとかなり時間の無駄です。
だって、同じ作業を２回やってることになるんですから、、、。

中には自分で作らないと気がすまない人とかいるかも知れないですけど
そういうのは自宅でプログラムの勉強をしている時だけにしましょう。

まあ何で特に大事だと思っているかというと

最近、僕がやっちゃったからです！！！

ごめんなさい、やっちゃったんです、、、。

しかも完成間近まで作成してから指摘されたのでびっくりしました。
全部が全部意味のないことをしていたというわけではないんですが、もし既に
用意されていたものを使用して作成していれば作業時間が大幅に短縮されて
いたと思います。コードも、もっときれいになっていたと思います。

みんな気をつけましょう！！！

ごめんなさい、気をつけます、、、。

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

さてみなさん、何かをするときには色々と考えを巡らせると思いますが、
私もプログラムを書くときには、作成物がどのような動きをするかできるだけ
詳細に想像するように気をつけています。

何故そうするか？

・不明瞭な部分が発見できたり
・不具合が発生しやすい部分が事前に察知できたり
・どんな方針で実装していくべきか検討できたり

より深く考えることで気づいていなかったものが明確になると思います。

例えばちょっと大雑把ですが、以下のような仕様のカメラを考えてみました。
・注視点は対象物とする。
・視点は対象物の姿勢とは独立して操作が可能である。
・視点に対する操作は左右上下旋回、ズームインアウトを可能とする。

このカメラの動きを実際に頭の中で想像してみます。
対象物を中心とした、ある長さの球面上の点から、対象物を常に見続けている
ものになると思います。

でそのときに「あるぇ？」って感じたのが↓です。
・対象物がなくなったらどうなる？
　その場を見続ける？
　他のカメラに切り替わる？
　新たな対象物が指定される？
　→座標だけ覚えとく？ガッされたくないし、対象物を直接知ってる必要ないし。
　　→なんかボタン押されたら対象物の向きのほうにカメラ向けるとかあるかも。
　　　→なら座標と姿勢を保持しとくか。対象物いなくなったらそこ見続けるとか
　　　　できるし。

・対象物の姿勢とは独立とは言うものの、初期状態ではどこから見るべき？
　→大体後ろからとかが多いけど・・・
　　→やっぱ姿勢は大事だねぇ

・視点に対する操作だけど、どんな動き？
　どのくらいの変化量？
　加速減速ある？
　操作入力時間とか関係する？
　これってスイッチ？　一回押されると決められた量動くとか、其の間の操作は
　受け付けないとか

・地面とかオブジェクトとかにめり込んだ場合どうする？
・視点、注視点の間に他の物があった場合どうする？
　滑らせる？
　他カメラに切り替える？
　いいかんじのところに視点をもって行く？

疑問に思ったところはまとめて、担当者と相談し修正を加えていきます。

しかし、ついつい忙しさにかまけて不十分な段階でコード作成に手をつけてしまう
事があります。そんなときは大抵修正作業に手をとられてしまい、あの時ちゃんと
今の状況を想像できていればと思うわけです。

おはようございます。本日の当番、ゴルファー兼プログラマのJ.Kです。
最近はゴルフが好調で、シニアプロデビューを目論見中です。

さて、本日はこの業界に必要な知識のお話を。

この業界で働いていくためには、当然ながら、開発をするための知識が必要です。
そうです、専門知識です。

私はプログラマなので、当然プログラムの知識が必要不可欠なわけです。
それは、ＩＴやＷＥＢのプログラムとはまた別の、ゲームを作るための知識です。

もうそれだけで、かなりの専門知識なわけです。

開発中にも、他の人のプログラムを見て
「なるほど！その手があったか！」
と自己発見し、自分流にアレンジして使ってみる…
こういうことの繰り返しで、日々成長するわけです。

しかし！

世の中はそんなに甘くはありません…

開発に携わり、日々成長を続け、それが少々の自信になりかけた時に事件は起こります…

それは…

・ウィンドウズが起動しなくなった！
・インターネットが見れなくなった！
・いつも使っているアプリケーションが起動しなくなった！
・社内のサーバーにアクセスできなくなった！
・アプリケーションをインストールしたらウィンドウズの挙動が変になった！
・メールの送受信ができなくなった！
・ＰＣから異音が発生するようになった！
・etc…

こういうことが、頻繁ではないにしろ、いつか確実に発生します。
開発は、必ず万全の状態で行える…というものではありません。

これら不具合を誰かが直してくれる…という環境であればいいでしょう。
しかし、そのような環境ばかりでもありません。
当然、これらの問題を自己解決する力も必要だと思います。

・問題がどこで発生しているか？を判断できる知識
・その問題が何故起こっているか？を調べる事ができる知識
・その問題に対しての最適な対応を行える知識

これらは基礎中の基礎…という知識ではありません。

しかし、ＰＣを扱う者としては、完璧ではないにしても、ある程度自由自在に操れる知識は必要だと思います。

この操れる知識こそが基礎知識だと思います。

頻繁に利用する知識ではないですが、いつか必ずその知識が必要になるでしょう。

また、この知識を持ち合わせていなくとも

・問題箇所を調べる
・原因を調べる
・対応方法を調べる

という事を繰り返していくうちに、経験値として蓄積されていきます。
そしてそれが知識となっていきます。

自宅のＰＣに異変が発生して、すぐにサポートに電話しているあなた！
基礎知識・専門知識ともに、自分の知識として吸収すれば、さらなる成長間違いなしですよ！

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

新社屋に引っ越して早くも一ヶ月が過ぎました。
そろそろ新しい環境にも慣れ始め、
近所のコンビニやマク○ナルドや吉○家の位置も
ばっちり把握しつつある今日この頃です。

さて、新社屋に引っ越して、
通勤電車に乗っている時間が短くなりました。
短くなったのは良いのですが、
残念な部分もあります。
それは脳内プログラミングする時間が減ったことです。

通勤電車の中で出来ることといえば、
携帯ゲーム機で遊んだり、読書したり、睡眠したりですが、
プログラマはさらに出来ることがあります。
それが脳内プログラミング。
そう、実はプログラミングはＰＣが無くても出来るのです！（力説）

頭の中でソースコードの追加、削除、組み替えを行い、
コンパイル実行するのです。
僕の脳内コンピュータは8bitくらいの性能しかないので、
あまり考えすぎると煙が出てしまいそうですが…。

通勤電車内に限らず、
駅から自宅まで歩いている時、
湯船に浸かっている時、
布団の中で眠りに付こうとしている時など、
脳内プログラミングはいろんな場所で可能なのです…素晴らしい！！

…まぁいろいろ書きましたが実際のところ、
勤務時間が終わったら仕事のことはすっきり忘れて、
頭と体を休ませるのも有効な手段かもしれません。
仕事をすっきり忘れて遊びまくれば頭もリフレッシュされて、
いいアイデアが閃くこともありますしね。

脳内プログラミングも良いですが、
頭から煙が出ない程度にしておきましょう。

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

日々プログラマなんぞやっていますと、数学に強いと思われているフシがままにあるため、数字に関する質問をうけることもしばしばです。

「あ～、M.L.K君、ちょっと」
「はい、なんですか？」
「eの小数点以下３１桁目の数字は何になるのかね？」
「eといいますと、あのネイピア数のeですか？」
「誰もちり紙の話なんぞしとらん！eと言えば、eだよ！e！」

いい歳こいたオッサンに、可愛く「イーっだ！イーっ！」とか言われて、後からデレられても困ります。ここは、軽く「すぐ調べます」と流しておくべきでしょう。

さて、Wikipedia先生に助けてもらいますか。
ネイピア数、っと。

e = 2.71828 18284 59045 23536 02874 71352 …

楽勝～！
１、２、３、４…、んん！？
３０桁目までしかねぇじゃねぇか…。

早々とピンチです。

しょうがねぇなぁ、自分で計算するか。

Wikipediaの記述を見て、計算しようと考えてしまうあたりがプログラマです。
オイラーの定義では、

e = lim(1+1/n)^n [n←∞]

ということは、ｎに適当に大きな数を入れれば、簡単に求まりそうです。
Windowsの電卓を立ち上げ、ｎ=2^32で計算です。
注）ここでの電卓は、関数電卓モードです。悪しからず。

[2]、[x^y]、[3]、[2]、[=]、[コピー]、
[1/x]、[+]、[1]、[=]、[x^y]、[貼り付け]、[=]
（[]はボタンやメニューアイテムの入力）

電卓：無効な値です。

なに～っ！
ちくしょう、桁が溢れやがった。
最初から激しく攻め過ぎたか。

次はやさしくしてやるぜ。
[2]、[x^y]、[3]、[1]←やさしさ、[=]、[コピー]、
[1/x]、[+]、[1]、[=]、[x^y]、[貼り付け]、[=]

電卓：変なウィンドウ（多分、「らめぇ」とか言ってる）を出して落ちる

ふうっ、落ちたか。
オレの手にかかって落とせないアプリケーションはないぜ！←違う

「M.L.K君！さっきの答えはまだかね！」
「ひゃいっ！」

[2]、[x^y]、[3]、[0]、[=]、[コピー]、
[1/x]、[+]、[1]、[=]、[x^y]、[貼り付け]、[=]

電卓：2.7182818271932466209354411302969

ふはは、楽勝～！
１、２、３、４…、んん！？
９桁目から数字が違う…

Wiki：2.718281828459045235360287471352…
電卓：2.7182818271932466209354411302969

どうしよう、精度が足りないよぅ…
しょうがないなぁ、逆関数～（ドラ○もん）。

[1]、[Inv]、[ln]（←もはや自分では計算していない）

電卓：2.7182818284590452353602874713527

１、２、３、４、…

「判りました！答えは７！（ちょっと考えて）あるいは６です！」
「なんだね、“あるいは”、というのは！」
「え～と、…量子論的見解？」
「ばっかもんっ！！」

プログラマとしてはまだまだなM.L.Kなのでした。

　
補足：
google先生の手を借りて調べたところ、
３１桁目は６、３２桁目が６となっており、
電卓の結果は四捨五入で７になってます。

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

今回のテーマですが、ズバリ「プログラマブル・シェーダ」を取り上げてみたいと思います。次世代機で搭載されている技術で、プログラミングについての知識が無い人でも言葉くらいは知っているのではないでしょうか。

さて、その「プログラマブル・シェーダ」（以下、シェーダ）ですが、歴史などを語り出すとかなりの長文になってしまいますので、ここでは割愛します。

「ほな、何を取り上げるねん？」ということになりますが、最先端の技術論とか展望などではなく、私が実際にゲームプログラムとしてシェーダを組み込んだ際のお話になります。

一般的にシェーダというと、画像処理やら複雑な計算式やらで難しそう、というイメージがあるかと思いますが、実はそんなことはありません。確かに基本的なグラフィックス知識は必要ですが、ゲーム用途（スキニングや法線マップなど）に限定すれば、既出の情報を参考にしながらで簡単に実装出来ます。それより問題なのは、その活用方法です。

ゲームグラフィックスでは、処理速度を重視した汎用的なシェーダ技術が要求されます。ボーンウェイト数の制御、光源計算／種類の有無、法線マップの切り替えなど、様々な機能を搭載したシェーダを設計しなければなりません。

これらの切り替えについては、シェーダの静的／動的分岐機能を活用すれば、実装自体にはさほど問題はありませんが、分岐コスト分の処理速度が犠牲になってしまいます。また、シェーダのレジスタ数にも限界があるため、もし機能が溢れた場合、マルチパスでのレンダリングが必要になります。そうなると、またまた処理速度に影響が出ます。

私もシェーダの設計段階でこういった問題に直面したことがあります。いくら性能が優れていても、処理速度に問題があれば改善はしなければなりません。そこで分岐を一切使わない、機能別にシェーダを事前に生成するシステムを試してみました。

その結果、確かに処理速度は向上しましたが、今度は生成されたシェーダ自体の容量がエラいことに…（汗）光源処理や法線マップなどといった組み合わせにして約８０００種類、容量にすると２０ＭＢ近くになってしまいました。

メモリ容量の問題は、処理速度と双璧を成すほど重要です。う～ん、完全なジレンマですね。で、どうしたかといいますと…、使用頻度の低い組み合わせを排除することで解決！しました。

というワケで、あまり派手なシェーダでなくても、それなりに考えなくてはいけません。私の場合、どちらかというと基礎レベルのシェーダのほうが難しい、と思ったほうでした。

何でも出来る！シェーダ論ではない、かなり地味なお話になってしまいましたが、中には「そうそう！」と共感した方もいらしたのではないでしょうか？

とは言え、数年後にはこんなこと考えなくてもよくなるんでしょうね～。
最近のグラフィックス技術の進歩は凄いですから！

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

いきなりですが、何かモノを作る時に必要なものってなんでしょう？

「おいおい、そんな話題散々このブログで語り尽くされてるよ、この豚野郎！！」

と、お思いのアナタ。

その通り、正解です。

　
　
豚野郎って部分がな！！

　
確かにいままでも様々な観点から語られてきましたね。

スキル
経験
知識
スピード
パワー（パワー！？パワーってなんだよ！）

んー、そのどれもが必要です。
（いや、パワーは知らないですけど。）

しかし今回語るのはそのどれでもありません。
ですが、色々な要素が内包しているとも言えなくないです。

今回のテーマ、それは

【ビジョン】です。

いえいえ、鳩のことではないです。それはピジョンです。

え？いやいやいや、眼鏡とか今は関係ないです。

ビジョン。
わかりやすく言えば完成予想図をイメージすること。
それはとても大切です。

例えば、ビジョンがはっきりしている人は仕事が早いです。
行くべきゴールの方向や距離がなんとなくわかっているので
足取りも軽く、ペース配分もバッチリです。
もちろん、神ではないのですべて完璧とまでは行かないでしょうが
それでも、立ち止まっている時間は比較的少ないです。

なんでも、伝説のビジョン神は
すべてのルート、ゴールがはっきり見えていたりもするとかしないとか。

ええ、噂です。

　
逆に、ビジョンがない人は、作業に時間がかかっちゃいます。
どうすれば正解なのかわからないゆえの試行錯誤・・・。
試しにやってみたらいい感じになったので、この方向で。
でも、ポリゴン数が多くなってしまったので、その解決策を模索。

まるで霧の中を歩いているような感じですね。
もう手探りで歩いてる（作業してる）ものだから、時間がかかっちゃいますし
全然違う方向に歩いている可能性もあります。

　
また進むべき方向が定まっていたとしても
どこまで作れば終了かがわからない時もあります。
なので、終了地点を手前に設定してしまうことも・・・。

このあたりで終了かなと立ち止まっていると先輩に肩を叩かれこう言われます。

「なに止まってんだ、豚野郎。早くゴール目指せ」と。

そこで初めて気づきます。
俺たちは、このはてしなく長い制作坂を登り始めたばかりなんだと。

　
　
ビジョンは大事です。

ビジョンビギナー（謎の造語）には一見越えられないと思われる壁＝試練も
ビジョンのある人は、なんなく越えていったりします。
簡単に越えられない場合も、越えようと試行錯誤します。
それは、壁を越えた先にあるものがイメージできるから。
そして、壁を越える自分をイメージできるから。

ビジョンビギナーは、そうは行きません。
思ってしまうんです。

壁・・・・。越えられない壁・・・。と。
これがダメ・・。この思考が・・・。

そして、考えてしまいます。
この壁を越えたとして、その先に道はあるのか？

俺たちに、未来はあるのか！とたまにカッコいい感じに自問自答をしたりもします。
そうやってマゴマゴしていると先輩にこう言われます。

　
「・・・・・なにしてんの？早く越えろよ。この豚野郎」と。

それはもう当たり前のことのように言われます。

えー、無理だろー・・・。とか思いつつも
なんとか越える努力をします。
先輩に手を引っ張ってもらったりしてようやく壁を越えるとそこで気づきます。

なるほど！壁は越えられる。
そして、越えられない壁なんてないんだ！

そして、次の壁を見てこう思うのです。

　
　
この壁は、さすがに無理だろう・・・。と。

ビジョンがまだまだな証拠です。

そんなこんなで、どこまで行ったら（作ったら）いいのかわからず
幾多の壁を越えがむしゃらに前に進んでいると、先輩からまた肩を叩かれます。

そして、こう言われます。

「ここらへんがゴールだ。やったな豚野郎・・・・。
　いや、お前はもう豚野郎なんかじゃあない。

　
　できる豚野郎だ」

　
そして、思うのです。

結局、豚野郎なのかよ！！！

　
　
さて、話が微妙に横道にそれてしまいましたが、
ビジョンをしっかり持つことが大切だということはなんとなくわかりましたね。

では、ビジョンを明確にするのに必要なのはなんなのでしょう？
経験ももちろん必要でしょう。
いろんなものを見ることも必要ですね。
資料や写真、他の人が作ったもの。
しかし、なにより必要なのは考えること
そしてイメージをする意志を持つことだと勝手に思ってます。

　
私はまだまだ若輩者ゆえ、ぼんやりとしたビジョンしか持てていません。
しかし、今後何かモノを作るときには
できる限り完成のビジョンをイメージし
それに近づけるように努力しようと思っています。

そしていつかは、世界に７人いるというビジョン神になってやる・・・。
と心に誓い今日もゲーム制作に精を出しています。

いや、ビジョン神は噂ですが。

　
そして最後にもう一つ・・・。

痩せるビジョンを持ちたい。

お後がよろしいようで。

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

皆さん、なぜ空は青いの？っと思ったことはないでしょうか？

誰でも一度は思ったことがあるはずです。
私自身も子供のころに「何で空は青いの？」と思ったことがあります。
子供の頃は、「そうか海が青いからだ～！」とか「空は青いものなんだぁ～」とか
答えが出ないまま日々の日常を過ごしていくうちに記憶の片隅へと埋もれてしまいました。


先日というか、結構前なんですが「空ってなんで青いんやろ～」と子供の頃の疑問が
復活し、この疑問に終止符を打つために、空が青い理由を調べてみました。

なんでも太陽の光は黄色に近い色で、プリズムで分解できるように青とか赤とか
いろんな色が含まれており、これらの色の光の波長（空間を伝わる波の長さ）
は異なっているそうです。
波長の中では紫が一番短く、藍色、青色、緑色、黄色、橙色の順に波長が長くなり
赤色が一番長くなります。
空気中に太陽の光が差し込むと、空気中の分子にぶつかり合い飛び散ります。
この時波長の長さによって飛び散る度合いが異なるそうで、波長の長い赤色は
空気中の分子にぶつかることなく通り過ぎてしまいます。
逆に波長が短い青い色は空気中の分子とぶつかり合い飛び散り
それが目に入り込んで青く見えるため、空が青く見えるそうです。

また、早朝や夕方のように時間帯や太陽の位置や角度や気象条件によっても
空の色は変化します。
他にも調べるともっと分かりやすく解釈できると思います。

調べてみた時は「・・・・へぇ～そうなんだ。」となんとな～く分りましたが
この知識、なんか役に立つかな～と思っていたら・・・・

なんとこれがゲーム開発に役立ちます。

例えば、野外のステージ（街とか荒野など）の空を作成する際
時間帯など、設定されていることが多いと思います。

そんな時に空が青い理由がなんとな～くでも分っていれば、青空を演出する時に
ほんのり藍色や緑色を加えてみると、建物や木や森とうまく調和して
説得力のある背景を演出することができます。

他にも、建物の窓から見える空が黄色や橙色だったら夕方？かなと
時計を見なくても時間が分かるなどの演出もできます。

身近なことでなんでだろうと思ったことがゲーム開発に役立つこともありますので
不思議に思ったことは少しずつでも良いので調べてみることをお勧めしますよ。

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

先月、ドイツ・ライプツィヒで行われたゲームコンベンション2008の視察に参加しました。ゲームショーの規模の大きさと活気には驚きでした…
ショーについてはすでに富田から報告されていますので、今回はショー以外の部分について触れさせて頂きます。

ドイツではショー視察と平行して、ハレ・ライプツィヒ・ドレスデン、三つの市街の取材を行ってきました。三つの市街は同じドイツでも雰囲気が違います。

ハレ中心街の裏道。緩やかに坂道になっていて、立体感があります。石造りの建物、石畳や落書きされた壁自体にも雰囲気がありますが、マップ構成において立体感を持たせるのは大事なんですよね。

ライプツィヒの廃墟。普通にこういう建物がいくつも建ってます。…といっても、表通りは綺麗に整えられた雰囲気の良い建物も並んでいます。ハレもそうでしたが、一つ筋を裏に進むと、こういう建物があります。マップにおいて土地勘を掴んで貰うのに裏通りの雰囲気をまったく変えてしまうのも手ですね。

ドレスデン中心部の歴史的建造物郡。繁栄と戦火の傷跡…歴史のある街。豪華な建造物が大戦で崩壊した後に復元されており、３つの時代が折り重なって深みがあります。時代の経過を感じさせるシチュエーションはゲームにおいて深みを出せそうです。

また、東ドイツの共産主義時代の合理的デザインの建造物が残っています。建造物は、思想の違いで大きくデザインが変わるということを目の当たりにしました。これも、世界観の深みを表現できそうな部分ですね。

そして、これら建造物に加え、改築・建替えが進んでどんどん現代建築が景色の中に入ってきています。旧来の文化の中に入り込む、異質な文化。これもうまく利用するとスパイスの効いた絵になります。

それぞれ街の成り立ちの違いによってデザインが異なり、個性のある景観を作り出しています。実際に目にすることにより、なかなか得にくい細部まで取材をすることができました。今後の制作に活かして行きたいと考えています。

　
…ハレ市内で夕暮れの町並みを撮影している時、少年に声をかけられました。しかし、突然のドイツ語に慌ててしまって、しゃべれないよ！という意思を見せるだけで精一杯でした。トボトボと残念そうに立ち去る少年。あ！よく見たら少年、ゲームコンベンションの紙バッグ持ってる！ゲーム話で盛り上がれたかもしれないのに！少年、ごめん。

言葉が分からないにしても、身振り手振りで会話を試みてみたらよかった！次回は、もっと飛び込んでいく気持ちを持って望みたいと思います。そうしたら、ドイツ美女とお知り合いになれr(ry

　
ゲームコンベンション2008については、下記弊社サイトにもレポートが掲載されています。ぜひ、ご覧下さい！

GAME CONVENTION 2008 出張者座談会 Round-Table Talk

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

さて８月も終り、今思い返すと色々とありました。おりゃ！！
お盆ラッシュ、北京オリンピック、東京スカイツリー着工、
淀川花火のピンポイント雷雨（関西限定）
などなど、、、。

その中でも、背景デザインに関わっている者としては、
一般的には賛否両論ありますが、東京スカイツリーの着工は
非常に完成が楽しみであります。

高さはアメリカ・イリノイ州のシカゴ・スパイアの609ｍを超える610ｍ。
巨大建築には血と汗とロマンがあります。
某缶コーヒーのＣＭでも表現されているように。

また、起り（むくり）や反り(そり)の曲線を生かした日本伝統建築の発想と
美的要素を盛り込み、五重の塔を参考に地震の揺れを抑える耐震構造と
なっているそうです。

いやはや、昔の建築技術がどれほど完成されていたのかが、良く分かります。

昔、勤めていた建築事務所でも社長から死ぬほど聞かされていましたとも、ええ。

完成は2011年12月竣工の予定だそうです。
是非とも建築物大好きな人間としては背景デザインの勉強がてら
行ってみたいですね。
本当の行きたい理由としては、個人的欲求が99.9％を占めていますが、、、。

まあ、その欲求が、自分の糧となり仕事に生かせる資料となるのですから、
背景デザインを目指してる方は、建築物を目的に旅行するのも楽しいと思います。

それだけの目的では堅苦しいし疲れる場合もあるので、
ご当地の美味い物食べたり、息抜きしたり、癒されながら行けると尚楽しい
ですね。


今後の仕事に役立つのなら、少しくらいの出費など痛くも痒くも無いですね。

ね。角和さん( *‘∀‘ )ノ 。

え？本の資料か通天閣でガマンしろぉって（´Д｀；）？

いや、、実際に行って自分で写真に収めるのと、本で眺めるのでは雲泥の差が、、。
しかも通天閣って、、、。
スカイツリーに通天閣は僅かに510ｍ足りないのです（；＾▽＾）。

そこをなんとか、、、(´・ω・`)　。

え？個人的に行きたいだけちゃうのって（汗）？
うっ、さあ、、仕事仕事っと（；´∀｀）。

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

今回はハッ!!とするような思考の転換があったときのお話です。

当たり前すぎて、改めて書くのも少し気が引けますが
限られた「制限」の中で物造りすることは、ゲーム造りも例外ではありません。

ハードという制約の中、CPU性能、メモリ制限、物理的にどうすることも
出来ない「制限」の中で、日々おユーザーが喜ぶものを提供する為に、日々
アイディアをひねり出し奮闘ています。

あるとき
ど～してもアイディアが出ないで悩んでおりました。
自分の不甲斐なさを棚にあげ、この「制限」のせいでアイディアが
出ないと思い込み

「制限された中で無限のアイディアなんて・・・」

と落ち込んでいました。

しかし正にそのときです。
私は思考を一変させれる素晴らしいものに出会いました。

それがコレです。

＝　コッホ曲線　＝

フラクタルに少しでも触れたことがあれば、ご存知と思いますが、
以下のようなものです。

--------------------------------------------------------------
線分を三等分して中央の線分を正三角形の二辺で置き換えていく操作を
無限に繰り返して得られる曲線。どんなに小さい一部分をとっても、
拡大してみると全体と同じ形（自己相似）をしている。
--------------------------------------------------------------

で上記の発展系が

＝　コッホ雪片　＝
--------------------------------------------------------------
コッホ雪片(コッホせっぺん)は、上記のコッホ曲線をつなぎ合わせ、
始点と終点を一致させたものである。
コッホ雪片は、有限の面積であるにもかかわらず、無限の周囲を持つ。
--------------------------------------------------------------

ここまで読んで、なんでコレが？とお思いでしょう！

注目すべきはこの「コッホ雪片」説明文の一行。
私の心理状態を一気に救ってくれました。

　「有限の面積であるにもかかわらず、無限の周囲を持つ」

　有限の面積　なのに
　無限の周囲　ですよっ！

　有限の面積が　制限なら
　無限の周囲が　アイディアじゃないですか！！

この瞬間、希望の光　ピキーン！！

内容が内容だけに直接的ではないので、少々飛躍している感はありますが、
プラス思考へ転換の瞬間でした。

私の頭の中では

　有限の中の無限のアイディア

が成り立った、ある意味救われた瞬間です。

人それぞれスランプからの脱出はいろいろあると思いますが
こういった切っ掛けは、ふとしたところに転がっているものなんですね。

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

先月、開発部が引っ越しし、我々開発陣も装いを新たに業務に取り組んでいる
今日この頃ですが、環境の変化によって制作意欲の向上など、大きな効果が期待
できるかもしれません。

僕の場合、通う路線が変わったため、電車に乗っている時も窓から見える風景は
もちろん、車内の人々など見えてくるものは全て新しく気持ちもモチベーションも
高まります。しかし、きっかけ無しに心機一転するのは、難しいと思います。
かといって何も出来ない訳ではありません。

例えば、デスクワークの方の場合なら自分のデスクにお気に入りの本やフィギュアを飾ったりしてみても良いでしょう。
ちなみにアクセスゲームズではデスクがトイザ○ス化している方もいらっしゃいます。

その他に、新しい靴を買ってみたり、ＰＣの壁紙を変えてみたり、どんな些細なこと
でもいいと思います。
新しい靴を買うと外へ出たくなるのと同じで、いつもと違うという感覚を意識的に感
じると、気持ちの変化もおのずと現われてくると思います。

僕にとっては〝常に新鮮な環境〟を自分から作ることはモチベーション
を更に高めるだけじゃなく面白いゲームを作る事に関しても効果的だと思います。
イライラしたり落ち込んでいたり、そういったネガティブな気持ちが続くと目の前の
仕事も作業的になってしまうかもしれません。
気持ちを切り替える１つの手段として、環境という＋αも時には役立ったりするかも
しれませんね。

ただ環境の変化によって、クーラーが容赦なく僕の体温を奪っていくのですが、
それはまた別の話。

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

気がつけば、もう九月。夜に虫の鳴く音が心地良い季節になりました。
(住んでる所が田舎なので…)

さて今回は、自分が専門学校に通っていた頃から続けている読書について
お話したいと思います。

読書と言っても、自分が好きなのは参考書を読むことです。
先週の休日、本棚の整理をしていたのですが、
「専門学校に通っていた頃から、よくこんなに本集めたな～」と思ったので、
数えてみたところ…

130冊以上ありました。

今までに数えたことなかったので、自分でもビックリしています。


ここまで読みあさるきっかけになったのは、
専門学校の頃に3DCGソフトを使う授業がありました。
結構、心配症だった自分は
「ここで失敗したら、ゲーム業界なんて無理だ。」とか
「学校は戦場だ。」とか思ってたので、真っ先に本屋に行って参考書を買い、
暇な時間を見つけては、参考書と睨めっこしてました。

すると面白い事に、スキルの吸収スピードが周りに比べて倍くらい変わりました。
なぜか具体的に言うと、
みなさんも経験あるとは思いますが、「あっ、これ見たことある」とか
「あっ、これ聞いたことある」という感覚と似ています。
この時には「わからない」という不安要素は消えているわけですから、
自分の言葉に置き換えて理解することは簡単なわけです。
その感覚が楽しくなり、今に至るという感じです。

集めた本にどんなものがあるかと言うと、

・3DCG関係の雑誌
・アニメ関係の雑誌
・ゲームの設定資料集
・解剖学の本
・画集
・写真集
・辞典(ミリタリー、神話など)
・映画のメイキング本
・プログラム関係の本(スクリプト少しずつ勉強中)
など

モーション関係で特に役立ったのが、美術解剖学の本です。
骨、筋肉の付き方など、わかりやすく載っているので、資料としては良いです。
骨の可動範囲が人間と異なる動物の動きなどを作る際、骨の位置を知ってるか、
知らないかで、全然違うものが出来上がります。

友達に「美術解剖学の本はいいよ」と言われ、間違って体の臓器や神経まで
載っている医療解剖学の本を本屋さんで2時間立ち読みし、店員さんに変な目で
見られたのはここだけの話。

学生時代から続けてきたことなので、
就職活動の時には自己ＰＲとして役立ちました。

常に技術が問われるゲーム業界ですので、この習慣は続けていこうと思います。

参考書に関して、始めは抵抗があるかもしれませんが、全て読む必要はないと
自分は思います。得た知識を実際に使って身に付くものだと思いますので、
使うものだけ覚えましょう。
全部読もうとすると、買ったのはいいけど、そのままっていう事になりそうなので。

身につけば必ずメリットがあると思いますので、この機会に一冊いかがでしょうか。

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

今日はモーションデザイナーを目指す方へ、学生時期に何を準備として勉強すれば
良いか私なりの考えを書こうと思います。

私が仕事としているモーションという班は、
新人さんが入社する際に特別な知識は要りません。
極端な話、プログラムなど、知らないと全く何も出来ないのに対し、
モーションはＣＧデザイナー班からもらったモデルを
動かす【だけ】なら全く経験の無い人にも出来てしまうのです。

例えばプログラマーの人と喧嘩したとして
「もういいよ！こっちで勝手にモーションさせておくよ！」
と、プログラマーの人に言われても、
「もういいよ！こっちで勝手にプログラム組んでおくよ！」
とは言い返せません。。
モデルが無ければ動かせないし、
プログラムが組まれていないと画面上で動かせない。
なんとも頼りない雰囲気が漂います。

ですが、逆に言えば誰でも出来ることをモーション班（もしくは個人）が
やらなきゃ駄目！って言わせる仕事が出来ないといけない。
…とも言える職種。難しいものです。

専門学校や、独学などで身に着けた技術は基本的なところはすごく役に立つの
ですが、制御（RIG）の組み方や物やキャラの動かし方などは会社によって
ばらつきがある上に、「表現方法」は多かれ少なかれ個々の「癖」がついて
しまう傾向があります。
また、時として何も知らない（癖の無い）人の方が吸収が早かったりする
こともあります。
厳しい会社では、この独学でついた癖を取るため、あえて何度も修正させて
癖の無い状態に戻してから指導をはじめると言う所もあるほどです。

では本題。私が考える勉強方法
まず、専門学校に行かれているならまず真面目に通って課題をこなして下さい。
これは大前提。決められたことを決められた期間でこなすことは職種関係無しに
絶対必要です。
　あとは…
好きなもの（趣味）に超集中して下さい。
＠映画やアニメが好きだ！
　　→手当り次第見まくってください。名作から駄作、古典から萌えまで。
＠スポーツ/アウトドアが好きだ！
　　→外に出まくってください。自然を感じ、体を動かしてください。
＠音楽聴くのが大好きだ！
　　→LIVEに行くなら屋内屋外路上問わずその場に行ってメンバーのサウンド、
　　　ファンの熱さを生で感じてください

…等々

ただその時、かっこいい！と思える動き、見てて気持ちいい動きなどをみたら
少しだけ自己分析して自分の引き出しにしまって下さい。
あのポーズかっこいいけどあのテンポじゃないとかっこ悪いよな。とか、
この動きが印象的だけどその後の動きで印象的に見せてるんだなぁとか
こういう時にかっこよく感じる。こういう時はかっこよくない。
など、自分の考えを整理し、自分がモーションを作成する時の
物差しを就職前までに作っておきます。

こうして作られた物差しは、自己分析のみの独りよがりなものだけど、
無いより断然良いと思います。
むしろ間違いに気づいたときにその物差しよりどれだけずれていたかを
修正すれば良いだけ。

こう考えるのは、前述の「独学では表現する方法に癖がつきやすい」の逆で、
吸収する方は器用不器用はあれど、癖はつかないと思うからです。

…以上。
俺が学生の頃こうやってりゃ、もうちっとうまくなれたかもなぁ…
と思って書きました。机上の空論かも…まぁ参考までに。

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

以前ブログに
『デモを作成する際、カメラから映らない所でもキチンと演技をさせましょう』
と書きましたが、私が他にやってしまうのが
『カメラの前で、過剰な演技をさせてしまう』
です。

カメラワークを考えながら作成していくと

《この背景に対してこのキャラクターの位置はここがいい》

とか

《絡みのあるこの３人の配置はこうしたい》

など、様々な要求に応えながらもカッコイイ構図を作っていくのが必要になってきます。

“とあるホテルの一室にて、真犯人を追い詰める刑事。
その刑事が右手に持っているのは、この事件を解く鍵となるらしいピアスが……”

さて、こんな場面で

《カメラに対してピアスを強調させるように……》
《この時、背景には夕日が差し込むベランダを見せて……》
《刑事がピアスを持つ手の形をナルシストっぽく……》

このようなカットにしたい時、実際に作成してみると

《ピアスは強調されるが、カメラに近すぎてぼやける……》
《それ以前に、逆光が眩し過ぎる》
《ナルシストっぽくしたいがカメラの角度からすると隠れてよく見えない……》

となる事も。
ここで３つ目の問題を解決しようと、指の形・手首の角度をカメラから自分なりにカッコよく見せようとした余り……

「実際にその手の形にすると、手がツルよ」

と、突っ込まれる……もとい、的確な指摘をされたりなんか……。

あくまでも重要なのは、基礎となる挙動をしっかりと作る事。
見た目を重視しても、基礎から捻じ曲げてしまっては台無しになってしまいます。

カッコよく作りたいのは皆同じ。
基礎をしっかりとさせた上で、自分が思うようなカッコよさに作り上げるよう心掛けましょう。

……。
次から気をつけます……！