スタッフBLOG

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

みなさんは数学は得意ですか？
ゲームプログラムにおいて数学は非常に重要です。

例えば
・キャラクターの移動
・当たり判定
・向きを求める
・高速化

等々、色々な場面で数学が使われています。

数学の知識があるのと無いのとでは作業効率が変わってきます。
知識があれば、より高速で効率の良いプログラムが書けます。

私は、思いっきり文系の人間なので、学生時代から数学はほとんど勉強して
いませんでした。というか、勉強全般を全くしてませんでした。
文系とか全然関係ないですね、ハイ、スイマセン。

とまぁ、そんなこんなでプログラムを始めたころは知らないことが多くて
めちゃくちゃ苦労しました。

今でもまだ苦労しています。
いたるところに出てきますからね、数学。

いやー、学生時代にきっちり勉強しておかないと、後々大変ですよ。
今になって、あの時ちゃんと勉強しておけばよかったなー、なんて思います。
皆さんは周りの大人の言うことを聞いてしっかり勉強してくださいね。

まぁ今は、それほど知識がなくてもインターネットを使えば
行列の計算やら、角度の求め方やら色々と計算方法は出てきます。
出てきますが、頼り切ってはいけません。
学生の頃頼り切って、会社の試験で焦りまくった人がここにいます。
ですので、調べるだけではなくしっかりと身に付けましょう。

これからプログラマを目指す皆さん！
私も頑張りますので皆さんも頑張って勉強しましょう！

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

突然ですが、プログラムを見て「カオスなプログラムだ」と言ったことはないです
か？　私の場合は、専門学校の友人が使っており、いつの間にか使うように
なっていました。

さて、この「カオス」とはどんな意味なんでしょう？
気になったので調べてみました。

「カオス」…混沌、混乱、無秩序。単に意味不明、理解できないものを指す事も。
　　　　　　　（"ウィキペディア"より）

「混沌」　…(1)天地創造の神話で、天と地がまだ分かれず混じり合っている状態。
　　　　　　(2)入りまじって区別がつかず、はっきりしないさま。
　　　　　　（"goo辞書"より）

という意味だそうです。
まぁ、なんとなくそんな感じだろうとは思っていましたが。
それにしても…

「混沌としている、はっきりしないプログラム」

改めて見てみるとすごいこと言ってますよね。
順序立てて組み上げている筈のプログラムがはっきりしないなんて…
実際には、関数で色々な場所に飛ぶので、上から下にとはいきませんから
複雑なプログラムの場合は、読みにくいかもしれませんが。
専門学校時代にそんなプログラムを組む人は少ない訳でして。

つまるところ他に原因があるということになるのです。
私の場合でいいますと…

　・同じ名前の変数を多用する
　　i や j は同じ名前でも良いかもしれませんが、
　　何かを一時的に保持する変数名が全て temp だったり
　　何かをカウントする変数名が全て count だったり
　　という状況になると後で処理が解らなくなります。

　　temp だから「何か」を保持しているのは解りますが
　　何を保持しているかを、見る度に確認しないといけませし、
　　count だから「何か」のカウントをしているのは解りますが
　　何をカウントしてるか、見る度に確認しないといけません。

　　こうなると、見直す度に混乱しかねませんし
　　他人が見た時に全く理解できないモノにもなってしまいます。

という「カオスなプログラム」がありました。
きっと最初にＣ言語を覚えた時の、喜々として参考書を見ながら組んでいた
あの頃のプログラムが癖になっているのでしょう…
今でもちらほらとやってしまい、その度に涙を流すのです。
あの頃は変数名なんて気にしてなかったもんなぁ。

皆さんも、しっかりと考えてプログラムを組むようにしましょー
でないと涙を流すハメになりますよ？

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

突然ですが、みなさんはハードウェアについてどの程度の知識、理解をお持ちでしょうか？

なぜこんなことを質問するのか、実際には無くてもプログラムを組むことはできます。でもあったらいいなぁと最近思うからです。

なぜかというと、ゲーム開発を行う上で必ず全体のうちに発生してしまうのが、高速化作業・・・
作成途中は、大概大量のデバッグ機能などのてんこ盛りでもっさり状態で作成作業を行っているので、重たいのは当然なのですが、問題はその大量のデバッグ機能をいざ取り除いた時に、想定しているゲーム速度が実現できていない場合があります。

PCの場合は最終的には公表する動作環境の下限を底上げしたり、ユーザー側もプレイフィールの向上を行おうと思えば、CPUを交換したり、メモリを増やしたり、etc...などで対応は可能です。

ですが、コンシューマの場合は当然ながら、CPUを交換したり、メモリ増やしたりなんて事はできやしません。なんとしてでも、このハードウェアスペックで予定する速度にしなければならないのです。

ここで役に立つのは、ハードウェア知識。
たとえばですと、現在の据え置き型ゲーム機の多くはCPUにPowerPCアーキテクチャのCPUを搭載したものが多いです。

ですので、PowerPC系のハードウェア仕様をある程度浅くでも知っていると、計算処理を眺めながら

「確かこういう計算してくれる命令セット持ってなかったっけ？」

なんてポロっと思い浮かび、ドキュメントを漁ると

「おっ、あるある。。」カキカキ・・・

ここで重要なのは、全くこの知識が無いとそもそも、こういう命令セットがあることすらこういう場になると思い浮かびません。
少なくとも自分はそうです。

　
そんなこんなで、ハードウェアの仕様を知ってると結構幸せになれそうです。
ただ上の例えの場合、

実際にはそんなところに手を出すよりも、

　「根本的に処理を見直す必要がある場所もあったりするわけですが。。。」

それはここだけの話ということで。

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

さて皆様、突然ですがプログラムにおいて楽をすることとは何でしょうか？
様々だと思いますが、僕が思うにプログラムを書かないことではないでしょうか？

誤解を招くような書き方をしましたが、ここで言う書かないというのは仕事をしないという意味ではなく、極力ハードコーディングしないということです。

ゲームを開発する場合、調整と呼ばれる工程がほぼ確実に発生します。
その内容は様々で、例えば

・キャラの移動速度の調整
・コンボ入力のタイミングの調整
・アニメーションの調整
・エトセトラ、エトセトラ

であったりします。

もし、これらのパラメータがソースコードに直接記述されていた場合、調整するためには必ずプログラマの作業が必要になります。ソースコードを他の職種の人が直接触るわけにも行きませんので当然です。
となると、そちらに時間を割かれてしまい結果的に余分な手間が発生しますし、値を変更するたびにコンパイルしなければいけなくなり効率も宜しくありません。

これを防ぐために、

・外部ファイルからパラメータを読み込む形にする
・これらを操作するためのツールを作成する

などの方法で誰でも触れるような形にしてしまうわけです。当然それ相応の手間が掛かりますが、それを惜しんででもそういう作りにしたほうが結果的には楽が出来るのではないかと思うわけです。

しかし、大抵の場合これらはハードコーディングしたほうが速く作成できるため、特に開発末期などではそちらを優先してガリガリとコーディングしてしまう場合があります。
が、最終的にはいい結果を生み出さない場合も往々にしてあるわけで・・・

はい、反省してます・・・ orz

　
などとペーペーがデカイ口を叩きましたが、これが理想よってことで。最終的に楽をするための手間を惜しまないような作り方を目指しております。が、まだまだ勉強中の身、なかなか実現できてないのが現実だったりしますが・・・

はい、反省してます・・・ orz

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

最近、またよく物忘れをします。一時期は良くなったのですが、、、
多分プロジェクトが進んで自分が管理するソースが多くなってきたので、そっちの方に脳の記憶容量が取られているんじゃないかと勝手に思っています。

それはとりあえず置いておいて、、

プログラムというのは、行き当たりばったりで組んでいると不安定な積み木みたいに、いつ崩れてもおかしくないような状態になってしまうものです。
これは管理するソースが多くなればなるほどそうなるといえます。

ただ積み上げていくなら比較的簡単なのですが、世の中には仕様変更というものがありまして、、
せっかく積み上げたものを崩さないといけない場合が出てきます。
その場合プログラマーは、崩すのは一部だけでよいのか、初めから積み直した方が良いのか、色々考えなくてはいけません。
その判断を間違え続けると、最終的には初めに言ったように不安定なものに仕上がってしまいます。

なので、プログラムを追加/変更する場合は、きちんと他の場所に及ぼす影響を考えて組んでいかないといけません。

しかし、長いこと同じものを作っていると、どこに積んでも他の場所が崩れてしまうといった場合が必ず存在します。
そんな時は、崩れる部分を無理やり補強して上に乗せていくしかないんですが、これをやりすぎると補強だらけの見た目によろしくないものができてしまいます。
見た目によろしくないものが出来上がってくると、次にどこに何を積んでいけばいいのかがだんだんと分かりにくくなっていきます。
その結果結局初めから作り直した方が、早かったりする場合もあります。

　
まあ結局何が言いたいかというと、、
プログラムを追加/変更する場合は、きちんと他の場所に及ぼす影響を考えて組んでいくしかないということです。

おわり

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

　
ブログへの投稿も今回で７回目になりますが、
毎回ながら文章を書くことの難しさを痛感します。

はたして分かりやすい文章になっているだろうか？
ちゃんと自分の意図したことが伝わっているだろうか？

自分が読むだけのメモのようなものならまだしも
ブログのように他の人に読んでもらう文章となると
表現ひとつひとつにも気を配らなければなりません。

ただ【文字】を書き連ねるだけではなく
ちゃんとした【文章】にしていかなければならない。
それはブログだけではなく、企画書や報告書など
色んな文章に当てはまる事だと思います。

　
　
そして、それはプログラムにおいても同じことが言えると思います。

プログラマーが【プログラム言語】ができるというのは
上で挙げた【文字】が書けると同じことだと思います。

そのプログラム言語を用いて、どのように【プログラム】を組むか。
同じく上で挙げた、どのように【文章】を書くかが重要になってきます。

ちゃんと意図した処理になっているのか
他の人が見ても分かりやすい書き方になっているか
バグのないプログラムを組んでいるか
バグが出たとしても、それを発見しやすい構造になっているか

などなど

特に開発末期になり、バグを修正していく作業になりますと
どうしても他の人が担当している部分のプログラムを読む必要が出てきます。

　
例えば、プレイ結果表示画面で表示がおかしい、というバグがあったとします。

これは表示する側のプログラムに問題があるのか
それとも表示用に取得しているパラメータに問題があるのか
そもそもここでは結果表示画面に来ること自体が間違いなのか

　
このような感じで、描画担当、パラメータ担当、フロー担当という感じで
それぞれの担当しているプログラムを確認しなければなりません。

最終的に修正するのはその担当者になるとは思いますが
どこが間違っているのかを見つけるために
他の担当のプログラムを確認することも必要になります。

そのためにも、他の人が見ても分かりやすいプログラムを心がけていきたいものです。

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

すっかり暑くなって、液状化です。
そんな私がお送りする、今日のネタは「状態と遷移」です。

いつもどおりな私。夏バテでぷるぷるしてる私。寝苦しくて目の焦点があっていない私。微ハイテンションで頭が変にとんがってる私。色んな状態の私がいるけれど、ゲームにも色んな状態があります。

　
例えば、次のような簡単なメニューがあったとします。

・各項目はすべてフォントを使った文字列で表現される。
・メニューが始まるときは、各項目の文字列が浮き上がってくる。
・メニューが終わるときは、各項目の文字列が薄れて消えていく。
・各項目の文字列は選択時は若干大きく、非選択時は通常の大きさで表示される。
・選択項目が決定されると文字列が明滅する。
・上下ボタンが押されると、選択項目が変更される。
・決定ボタンが押されると、選択項目が決定され、メニューが終了する。
・キャンセルボタンが押されると、メニューが終了する。
・メニューの項目は一つのみ選択されている状態となる。

　
この時、とり得る状態を書いてみます。

●メニューの各項目の文字列（ニューゲーム、コンテニュー、オプション等）
Ａ．状態なし（メニュー画面に移行してきた瞬間）
Ｂ．表示移行待ち状態
Ｃ．選択されていない状態
Ｄ．選択演出状態
Ｅ．選択されている状態
Ｆ．非選択演出状態
Ｇ．決定演出状態
Ｈ．非表示移行待ち状態
Ｉ．非表示状態

●メニュー全体
０．状態なし（メニュー画面に移行してきた瞬間）
１．表示物の表示移行待ち状態
２．ユーザ入力待機状態
３．選択演出状態
４．決定演出状態
５．表示物の非表示移行待ち状態
６．非表示状態

これだと、メニュー全体と各項目で同じ状態があり、あれ？と思うかもしれませんが、メニュー全体の状態を元に、一括処理できるから各項目の状態いらないんじゃない？って判断すると、後々面倒なことが起こりえます。

「一斉に浮き出てきてるのを、上から順番にしてくれない？」とか。各項目ごとに制御する必要があるので、個別で状態を管理できる方が分かりやすいです。

　
次に状態がどのように遷移するか書いてみます。

　　遷移元（遷移条件）　　　　　　　　　　　　　　　→遷移先

●メニューの各項目の文字列

●メニュー全体

このように、状態がどう遷移するか挙げていけば、考えやすくなります。

　
しかし、いくらさまざまな条件を考えても、スライミィな私ではキングスライミィには状態遷移しねぇぇ。

おはようございます。本日の当番、ゴルファー兼プログラマのJ.Kです。

先日、晴天下で８１の好スコアで回ってきて絶好調中です。

さて、本日はこの業界の法則のお話を。

ゲームは世間に販売されますので、当然不具合があれば非常に問題になります。
※回収騒ぎなんて発生した時には気絶もんです。

世間の皆さんにお金を出してもらって、買って頂くという性質上、やはりチェックは重要になります。

定期的に内容や挙動のチェックが行われるわけですが、この時に法則が発動します。それは何かと言いますと…

あれ…動かない…
あれ…なんか挙動が変…

…

そう「重要な局面で必ず不具合が出る」法則です…

何かしらのチェックが行われる時に限って、何かしらの不具合が出る…

今までに一度も発生した事がないバグや挙動の数々…

ワキから滝のように汗が流れます…

自分が開発している部分は、開発中からチェックに至るまで、常に自分のルーチンで操作します。よって、いつも同じ動作をさせているに等しいのです。

このいつも同じ動作から脱線すると…

見たことも無いような不具合が発生するわけです。

自分ではかなりチェックしたつもりでも、それはあくまで自分のルーチン内でのお話。井の中の蛙とでも言いましょうか。

自分のルーチンとは異なる操作＝自分以外の人の操作、は非常に重要、かつ、シビアです。

経験を積むにつれて、怪しそうな操作を自ら行って、大半の不具合を潰す事はできます。それでも、時間が許すのであれば、できる限り自分以外の人にも操作してもらいたい。

通常は、バグチェックでそういう操作が行われますが、そこまで放置もできないわけで…個人的には、チェック項目を全て洗い出し、一つ一つ潰していくようにしています。

それでも、溢れるかもしれない。
その時は…

バグチェックの人、宜しく！

としか言いようがない…

…

ま、とりあえずは、自分のチェックは完全に信用せずに、
一つ一つ丁寧に確認しましょう！

そして、締め切り直前という大局面で不具合が発生した時は「法則！法則！」と言いつつ、心の中で泣きましょう…

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

えっと、いきなり個人的な事を書いてしまいますが、
僕は推理小説が大好きです。
小学校の頃から読んでいて、
図書館から借りる本はほとんど推理小説という有様でした。

さてさて、その推理小説に付き物なのが、いわゆる名探偵ですよね。
灰色の脳細胞を持っていたり、警察キャリアだったり、三毛猫だったり（！）と姿形は多種多様ですが、
共通しているのは、洞察力、推理力が素晴らしい！というところだと思うのです。

名探偵には欠かせない洞察力と推理力ですが、
プログラマーにとっても実に重要だと思うのです。

例えば、不可解なバグが起こったとします。
普通に探したのでは原因がつかめません。
そんなときはどうするのか？
…そうです、自分も名探偵になりきるのです！

1.ふむふむ、ここの関数を通せば、違った結果になるな…。
2.ほうほう、この部分をマスクすれば、バグは起こらないのか…。
3.いやいや、以前のデータを使えば、うまく動作するぞ…。
4.え、実は変数の初期化し忘れですか…orz

…というように、容疑者のアリバイをチェックしていく名探偵のごとく、
洞察力と推理力を発揮してバグの原因を見つけ出していくのです。

……え？こんなことしてるのってお前だけだろうって？
いやいや、みなさんも名探偵になったつもりでデバッグに望めば、
いつもよりも早くバグの原因を特定できるかもしれませんよ！

日頃から推理小説を読んで、名探偵レベルを鍛えておけば、
いざというときも大丈夫ですね！

おはようございます。本日の当番、プログラマのM.L.Kです（LはLieのLです、Lie＆Rest！）。

世の中には２種類の人間がいます。
すなわち、プログラマと、そうでない人間、です。

そして、プログラマとは、
ある２種類の状態を定義する者と定義できます。
すなわち、真（true）と偽（false）です。

Ｃ言語で言うところの、if文だとか、while文などの条件分岐に使われるアレですね。

「定義っつっても、trueは“１”で、falseは“０”だろ」

確かに、仰るとおり。
例えば、Ｃ言語だと、

typedef int bool;
const bool true = 1;
const bool false = 0;

とか書いて、
trueとfalse自体を、１と０とに定義するのはよくある話です。

if(true)
{
　　printf("Hello World!");
}

と書けば、「Hello World!」と表示されますし、

if(false)
{
　　printf("Hello World!");
}

と書けば、表示されません。

if文内で、“true”＝ 真、“false”＝ 偽、と解釈されているからです。
定義が意図したとおりの挙動です。

では、

if(5)
{
　　printf("Hello World!");
}

では、どうでしょう？
結論を言えば、「Hello World!」は表示されます。
更に言えば、括弧内に０以外の数値が入る場合は、全て表示されます。

条件文での真偽判定は、０は偽、それ以外は全て真、ということになっているからです。

従って、
例えば、失敗時は０、成功時はその状態を数値で返す、とある関数、success()があったとして、

if( success() )
{
　　printf("success state = %d", success());
}

としたとき、成功時にのみ、「success state = ～」と、表示されます。
事実、このような使い方を期待して、関数を実装する場合が多々あります。
実際上の“真”の定義は、実装するプログラマ次第、ということですね。

ただ、便利な仕様ですが、これが思わぬ罠になることも。

成功 ＝ 真 ＝“true”

という思い込みで、

if( success() == true )
{
　　printf("success state = %d", success());
}

と書いてしまい、いつまで経っても、成功の１種類の成功状態しか表示されない、なんてことに…。

もっとも、上の記述のようなミスが“確実”に起こるのは、Ｃ言語の話。
Ｃ＋＋に至っては、コンパイル環境によっては、思惑通りの挙動になる場合もあります。
（整数型からbool型へのキャストが定義されているかどうかによると思われる）
思い込みに拍車をかける結果となります。

特に、Ｃ言語環境とＣ＋＋環境を行き来するようでしたら、

if( success() != false )

というように記述する癖をつけたほうがいいかもしれません。

ちなみに、私はたまにこのミスをやってしまいます。
「謎の組織でも何でもいいから、頭脳はまんまで子どもに戻して欲しい」
と密かに思っているからですね。多分。

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

突然ですが、皆さんは「プログラマー３５歳限界説」という言葉を
耳にしたことはあるでしょうか？

プログラマーという仕事は、思いのほか体力／精神疲労の消耗が激しく、また技術自体の進化も早いため、その時々によっては、それまで培ってきた既存の技術を捨て去り、イチから覚え直すのも辞さない覚悟が必要だったりします。

そのため、高年齢になればなるほど、体力／精神的にキツくなり、新たな技術の習得にも対応出来なくなります。その限界年齢の基準というのが「３５歳」と言われています。

さて、この限界説…、ゲームプログラマーでも当てはまるのでしょうか？

まず、技術の進化で言えば、ここ数年で間違いなく飛躍的に向上していると言えます。最近で言うと、プログラマブルシェーダーに始まり、マルチプロセッサ、物理演算と、それまでは思いもしなかった革新技術の連続です。

ネットワークゲームが主流になり、コンテンツのダウンロード販売など、一昔前の据え置きゲーム機での振舞いとは、同じゲーム機として比べるには雲泥の差があります。

そんな状況で、実際にその限界年齢に直面しようとしているプログラマー（大川）はどうなのか、と言いますと！

「実は、そんなに大した事は無かったりします」

さて、その理由なんですが、おそらくは以下↓でしょう。

・アセンブラなどの低級言語から、Ｃ／Ｃ＋＋（いわゆる高級言語）が主流になった。
・プログラマーの分業化が進み、個々に適した役割を発揮出来るようになった。
・情報の共有化（インターネット）により、最新技術の適応が容易になった。

高級言語になったことで、プログラム自体の作成が容易になり、また作業の分散化によって、プログラマー各人の知識／技術の蓄積負担が軽減されたと思います。インターネット／書籍の普及も、そういった負担を軽減したポイントと言えるでしょう。

私の場合、まだ衰える気配はありませんし、シェーダや物理演算などの技術欲についても、全然ＯＫの状態です。その背景には、前述した恩恵があるのでしょうか。先人に感謝ですね。

あ、でも体力の衰えは否めないかもしれません。
この点については、健康管理の問題！？

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

夏です。日本の夏。アクセスゲームズの夏。そして、俺の夏。

はいどうも、夏とは関係ありませんが、
本日は素敵な背景を作成する一工夫をまたまた紹介します。
今回は、地形（実際にプレイヤーが歩くＭＡＰ）に関してのあれこれ。

背景を作成する上で、地形に物が少ないとなんだか寂しい印象を受けてしまいます。
ごちゃごちゃし過ぎるのも考え物ですが、できるだけ賑やかにする（というか存在感
やリアルさを出す）ために、たくさんのものを配置したり、色々な要素を加えていき
ます。

しかし使用できるポリゴン数は無限ではないので、
好き放題に物を増やせるわけではありません。
なので、ポリゴン数を節約しながらできる範囲で物を増やします。

物は増やす。ポリゴン数は増やさない。
両方やらなきゃあいけないってのが、CGデザイナーのつらいところです。

さて、この無茶難題をどういうトンチで解決するかと言いますと・・・。
答えは簡単。ポリゴン数を減らせばいいのです。

「ええ！？一休さん！でも、物を増やせばポリゴン数は増えるのが当たり前！さよちゃんでも知ってるでござるよ！」

とブチ切れのそこの新右衛門さん。ちょっと黙れ。

慌てない慌てない。
ポリゴン数を増やせないなら、少ないポリゴン数で作ればいいわけです。
それがポリゴン数を減らす、ということに繋がってきます。

ただし、単にポリゴン数を減らしてしまうとお粗末な背景になってしまいます。
プレイヤーから近いところにあるものをローポリゴンで作ると目立ってしまうので、
プレイヤーから遠いところのポリゴン数を削ります。これ！

さらに、もっと割り切ってしまえば、立体ですらなくなることもあります。

「ええ！？一休さん！３Dゲームでござるよ！？
立体じゃないって、何をトンチキなことを・・。」

はい黙れ、新右衛門。

立体ではないけど、違和感を生まないものとは・・。
はい、描き割り。
これ！！

プレイヤーから見える角度が決まっている場合。
１枚のペラペラのポリゴンに絵を貼り付けて表示することもあります。
もちろん、横から見たらペラッペラなので
プレイヤーが近づける場所には作れませんが。

わかりやすく例えると木などもそういう風に作ってたり作ってなかったり。
遠くにたくさん木を植えたい時などは、書き割りの木を大量に置いたりします。
また、遠くの景色を描いた絵を貼り付けたり・・など、
奥行きを出すのに素敵な効果を発揮している描き割りです。

そうそう、昔プレイしたレースゲームではギャラリーの人間達を描き割ってました。
止まったポーズのまま動きませんが、プレイヤー（車）は超速度で動いてるのであま
り気にならなかったです。
ものすごい勢いで疾走するレースゲームだからこその描き割りっぷりですね。

「一休さーん、そんなところまで見てるなんて、あれでござるな・・ププ。」

黙れ、新右衛門。

これを読んでいる方。
いますぐ近くにあるゲームをプレイして、描き割りを探してみてはいかが？
え？描き割りがない？

残念・・・実は今見ているそれが描き割りです。

はい、遠くの方に、キレイなお姉さんを見かけたとしても油断するな！
それも、描き割りだ！！

そして、今読んでいるこのブログも・・・・。

「いやいや、さすがにそれは・・。」

黙れ。

「ちょ・・・一休さん。」

黙れ。

「ちょ！！」

そんなこんなで、日々自分の中の新右衛門さんと戦いながら
賑やかで奥行きのある背景が作れるような工夫をしています。

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

早いもので、もう7月です。七夕も終わり、織姫と彦星は会えたのかな～と
自分的にはかなり気になったりしましたが、そんなロマンチックなことを言ってる
暇もなく本格的な夏がやってきました。
この時期はキャンプに、祭りに、虫取りに、海水浴に、旅行に、ビアガーデン、
楽しみなイベントが盛りだくさんです。
もちろん気温も高くなり暑くなってきます！ムンムンしてきます！

実は、自分この暑さすこし苦手っス！
でも、さすがに毎年この暑さに悩まされているわけではありません。
緩和する方法もあるわけです。

たとえば・・・。

■氷を口の中で溶かす。
　口の中で少しずつ氷を溶かすことで、体の中から体温を冷やすことができます。

■水の入ったバケツに足をつける
　小さいころに試しましたが、結構効果絶大です。

■冷蔵庫で冷やしたタオルを顔に被せて横になる。
　最初は冷たすぎ！と思いますが、気温が高いこともあり徐々に涼しくなってきます。

ってな具合で、暑さを緩和して快適な空間で過ごしてきたわけです。

しかし、会社ではこの暑さ対策が効果なしなのです！
なぜ、なぜ、なぜなの？と考えた結果気づいてしまった衝撃的事実！！
それは、普通の家にはまずないであろう、沢山のテレビやパソコンや開発機材が一つの部屋に密集しているから、どうしても暑くなりがちです。
そら～エアコンの温度を21度に設定しても涼しくならないわけですよ。

しか～しそんな非常事態にも臆することなく会社でも出来る簡単な暑さ対策を考えているのです。

たとえば・・・。

■冷たい飲み物を買って動脈部分を冷やす。
　さあ朝は迷わず自販機に行ってみよう！

■ツボを冷やしてみる。
　冷たいタオルをツボに被せてマッサージすることで体全体の体温を下げることができるはず。
　（方法はいろいろあると思いますがね）

■涼しい場所に席を移動する
　かなり無理があるかもしれませんが、暑さは確実に凌げるはず！

ってな感じで、暑さ対策をすれば快適な空間で仕事ができるので作業効率もアップするんじゃないでしょうか。
扇風機を複数配置して部屋全体に涼しい風が行きわたるように対処もしていますしね。

でも、最近は別のことが原因なんじゃないか？と思っています。

それは、いいものを作りたいというみんなの熱意が部屋全体の気温をあげているんじゃないのか？
そして、もしかしたら、これがクリエイターにとって快適な空間ではないだろうかと気づいてしまったのです。

さあみんなも夏の暑さにも負けない熱意を持つクリエイターが集まるアクセスゲームズに来てみないかい。

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

先日、会社の系列グループで催された懇親会がありまして、関西を中心とした系列グループ数百名が会場に集まり、アクセスゲームズ社員全員も加わって発展を祝ってきました。その様子を簡単にレポートしたいと思います。

会場は太閤園の大宴会場。大阪市内でありながら、約7000坪の広大な敷地に日本庭園を有するという、とてもリッチなロケーションです。

グループ会長の激励スピーチで宴会は和やかにスタート。フォーマルな格好の人ばかりな中で、アクセスゲームズはカジュアルな格好がデフォルト。会場入りした時、視線が突き刺さるように感じたのは気のせいでしょうか？気のせいです。なんせ、ほとんどのメンバーのシャツに襟はありましたから！

お料理がおいしかったです。特に、目の前で焼いてくれるこのお肉は絶品でした。ブースには行列ができ、並びなおして何度も食べてる人も続出。

飲み放題で、お酒も進みます。ルネッサ～ンス！とあちらこちらで聞こえます。流行ってますね。

寿司取ってきたぞ～！いただきま～す！

SWERYさんに、スイーツ責め！

いつものようにモリモリ食べる人も。こう見えてナカナカ食べる人も。

アクセスゲームズ社員同士も楽しく過ごしたのはもちろんのこと、以前一緒に仕事をさせて頂いた系列会社の人に久しぶりにお会いして、ぜひ次もご協力をお願いしたい的な話から、今度呑みに行こうぜ的な話もあったりで、有意義な時間でした。

イベントがあると期日が迫るにつれて及び腰になりがちな自分ですが、行ってみたら楽しめることが大半です。こういう機会は大切にしないといけませんね。

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

うい！ブログを書き込む出番がまたやってまいりました。やってやろうぜ。

梅雨も終わり七夕も終わり、ついに夏到来です。
いやはや実に楽しい季節がやってまいりましたね。

まあ暑くて外に出るのも嫌な人も居られるでしょうが、まあそんな事言わずアイス
でも食いながら外に出れば、楽しい事があるかもしれませんスよ。

特にデザイナーを目指す方々は、思いっきり外に出て欲しいと思います。

当然デッサンを描いたり画集、映像作品やらに目を通す事も大事です。

ですが、外にはそれよりももっと沢山の情報があります。
色々な建物のデザイン、色々な人のファッション、色々な人との出会い、
色々な景観、色々な臭い、色々な感触。
自然物～人工物、全てデザインに関する物で溢れています。

まあ、無理して特殊な場所に行かずとも、ふと目に止るパラソルの模様などが、
今まで煮詰まっているデザイン案を解消してくれるかもしれません。

ついでに外に出掛けてストレス発散も出来るし一石二鳥です。

某映画の考古学者も、以下みたいな事を言ってました。
うろ覚えですが、「真の考古学者には図書館など用はない！」と。まあ、
超人的身体能力を持っている考古学者の意見なんで、鵜呑みには出来ないです
が・・・確かにそうかもしれません。
デザイナーにも近い事が当てはまるかもしれませんね。

特に夏場の暑さが苦手やけど自然に触れたい方などは、高野山などに登るのも
良いかもしれません。
２～３年前に行った事ありますが夏場でも涼しいので、今の季節自然物の景観
などを観たい時などは、過しやすいし行ってみるのも一興です。
ケーブルカーで登るのも楽しいし、世界遺産や和のデザインも沢山あるし。

こんな暑い夏ですが、デザインに対する視覚・触覚・嗅覚を潤しに、休日は外に
遊びに出掛ける事をオススメします。

ちなみに昔、真夏にコンビニが遠い上に誰も居ない工場地帯の海岸で、
水分補給もせず一人で映画撮影をしてて、日射病で倒れそうになった事は、ココだ
けのヒミツだ・・・。

出掛ける際は倒れないように、水分も補給しながらのんびり行きましょう。

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

天体望遠鏡を買って早半年、
一度も箱を開けていない私は一体なんでしょうか？
七夕を見過ごしてしまった・・・
あ～星を観る道具をもっているのに勿体無い・・・無念・・・

それはさておき

現在、私は会社までの通勤時間が自転車で６分の距離に住んでいます。
最近引越しを考えておりまして、引越し後の通勤時間を考えて早起きを
実践しているのですがこれが中々、今までの生活サイクルを自分で
矯正するのが難しく、日々自分の意志の弱さに嘆いております。

嘆きながらも最近実践し始めたのが、帰宅して直ぐに

　即飯　即風呂　即寝

いつもは帰宅後、自分の時間として夜に娯楽を楽しんでいたのですが
この時間を起床後にシフトさせ１日の時間の使い方を変えてみました。

例えば帰宅途中で借りたDVDを朝に観たり、いつもは眠くなるまで
していたゲームを朝からプレイしたりなどなど

要は早寝早起きですｗ

するとどうでしょう。

会社の出勤直後から頭の調子が「非常に良い」ではありませんか！

自脳比1.2倍位でしょうか（ちょっと微妙ｗ）
とにかく頭がスッキリ！です。

人間の脳が働き出すのは起床２時間後位と聞いたことがありますが、
当にその通り、意識して実践した事はなかったのであまりの変化に
驚いてしまいました。

今思えば、子供の頃に

　早寝早起き　朝の掃除　朝ご飯はしっかり食べる

・・・ちゃんと教えられてきたはずなのに、
どうしてもおろそかになってしまう基本的な習慣。

ゲーム業界なにかと日々忙しいイメージがありますが、どんな状況でも
こういった部分をしっかり抑えて生活する事が非常に重要である事を
改めて認識した瞬間でした。

さ～て、早起きに慣れてきたところで「明けの明星」観測に行くかな。

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

　
１ヶ月の研修も無事に終わり、ゲーム制作に関わり始めて早２ヶ月が経とうとしています。現在もこうしてモーションデザイナーとして働いている訳ですが、モーションは疎かゲームの〝ゲ〟の字も理解出来ていない事に気付きました。確かにゲーム制作に関わるのは今回が初めてですが、ここまでゲームの概念に溺れるとは…

１人で思い詰めても仕方がありません。新人らしく、今日はゲームの概念に溺れてしまった僕の失敗談を聞いて下さい。

今回は〝演出〟についてのトライアンドエラーです。

それぞれのゲームにはそれぞれのコンセプトがあり、それに見合った様々な演出があります。僕が最近携わった〝演出〟といえば〝カメラ演出〟などです。
当然、仕様に基づいてカメラを操作していく訳ですが、ただ闇雲にカメラを振り回すだけじゃなく、ここはデザイナーらしく臨場感のあるカメラワークを演出、作成しようと思っていました。

がしかし、ここで素人、いや新人ならではの失敗にぶちあたります。

やりすぎたのです。
当時、仕様上でしかゲームを理解していなかったせいか過剰な演出をつけてしまい、全体のバランスとマッチしない結果になってしまったのです。

分かりやすく言えば、老夫婦が住む和室の照明にシャンデリアを設置してしまったといったところでしょうか。しかし、全国探せば和室にシャンデリアをぶら下げている老夫婦も中にはいるでしょう。正直浮いてます。でも、そのセンス僕は好きです。部屋の照明などインテリアのコーディネートは自由で結構です。自己満足で大いに結構だと思います。

一方、僕たち私たちはゲーム開発者。お客様に遊びを提供する義務があります。自己満足では、提供する側のやり方としては間違っていると思います。

よって、和室に住む老夫婦の事を考えると、どれだけ美しいシャンデリアも２人にとっては無駄に電気代を食う眩しい飾りにしかならないんじゃないかと気を利かせます。

そこで僕は考えます、例えばロウソクなどはどうか…月明かりといった演出もいいでしょう。いづれも和室の風情ある雰囲気にはうってつけの照明達です。これで天の川をみたりしたら甘酒がとまらないこと請け合いでしょう。

現実的ではありますが、多少地味でもゲームを作る上で型にはまる演出を加えるという事はとても重要なことだと今は実感しています。しかし、気づくことが多い新人だからこそこんな失敗も楽しく思えてきます。

私情ではありますが、初めから無難に作業していては息が詰りますし、何より明確な基準が見え難いと思います。上司の言葉ではありますが、大いに失敗して徐々に自分のものさしを作っていく。色々現実的になってしまうと楽しい作業も楽しくなくなってきてしまうと思うんです。気づく楽しさ、気づくための手段として、失敗して基準を見つけるということは新人の一種の特権だと思います。

ただ、失敗をすることを前提にではなく、成功を夢見ながら作業をするとよりいいと思います（笑）
新人のみなさん、用法用量を守り正しく暴れましょう！

おはようございます。本日の当番、新人モーションデザイナーのR.Iです。
入社して３ヶ月が経とうとしております。
初めは電話の音が鳴るたびにビクッとしていましたが、会社の雰囲気にもようやく慣れてきました。

さて、本日はスクリプトについてお話させていただきます。

仕事をする上で、面倒な作業というのは必ず存在します。
それらを効率よく進める時にスクリプトが便利です。

最近、仕事で色々なスクリプトを使う機会が増え、こういうスクリプトがあればいいのにと思うことが多々ありますが、自分で作成するとなるとスクリプトの知識がいるので、デザイナーの自分にとっては難しい内容です。

ですが３ＤＣＧソフトの中には自分が行った内容をスクリプトに置き換えてくれる便利な機能があります。
それがスクリプトエディタというものです。
自分はＸＳＩを使っているので、それで説明したいと思います。

まず、スクリプトエディタを開きます。

ためしに立方体を作成してみます。すると、スクリプトエディタ内にスクリプトが表示されます。

CreatePrim "Cube", "MeshSurface"

これが立方体を作成するためのスクリプトということになります。
これをコピー＆ペーストして実行することで同じことができます。
作ったスクリプトはショートカットキーにも登録することができます。

ためしに、球を作成してみます。

CreatePrim "Sphere", "MeshSurface"

ただ、見ているだけでは何もわからないので立方体作成のスクリプトと比較してみましょう。

CreatePrim "Cube", "MeshSurface"　　立方体作成スクリプトです。

CreatePrim "Sphere", "MeshSurface"　球作成スクリプトです。

これで何がわかるかというと、CreatePrimと"MeshSurface"が共通の内容で、"Cube"と"Sphere"が変わっているということです。

さらに詳しく言うと、CreatePrimがモデル作成のための命令で、"Cube"と"Sphere"がモデルであるということです。ちなみに、"MeshSurface"はポリゴンモデルであることを表しており、これが"NurbsSurface"になるとナーブスモデルであることを表しています。

この比較で少しずつスクリプトに慣れようというのが自分の勉強法です。
「スクリプトできる人に任せればいいじゃん」と思うかもしれませんが、ほしいスクリプトが作成できることに意義があると思います。

モデル作成以外にも、スクリプトエディタはスクリプトを表示してくれるので、色々な機能を使って、スクリプトを表示させてみてスクリプトに興味をもってみてはいかがでしょうか。

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

さてタイトルの【眼力】。別に５キロ先の野生動物が見えるとか、メガネキャラがどうとかって話ではありません。

物を動かす仕事って目が上達してから腕がついてくるって話です。
これは絵を描く仕事でも同じことだと思います。
…というよりコレは私が絵で食べてた頃に学んだことだったりします。

つまり、
①上手く出来ないし、修正されても何が改善されたかもよくわからない。
　教えられたこと丸飲み時代
②上手く出来ないが、修正されたら「おおっ！」と思えるようになる。
　こうかな？と自分で考えだす時代
③自分の作った物がどこか変なのかはわかるが、直せない。
④時間を置けば自分の作った物の変な所がわかる。直せる。
⑤自分の作った物の変な所がすぐわかり、すぐ直せる。
⑥失敗などしねぇっ！俺完璧★キュピーン

という段階を踏んで上達するものだと私は思います。
んで、このタイトルの目が先行する期間ってのが③にあたります。
「こうかな？…いやまだ変だなぁ」「こうじゃね？…いやいや。ないわ～」
と直そうとするけどなかなか直らないし納得できない。うき～ってなる期間。
そしてこの期間が超長い…。さらにつらい…。
ここであきらめて辞めていく人をたくさん見ました。

と偉そうに語ってる私もまだこの段階なんですが、実は③と④の間に【経験でごまかす】という邪道があります。
「この表現はヤベェ！」と直感で解るようになり、【直す】のではなく
自分の引き出しから別表現を用いて【避ける】のです。
技術的には前進していません。チャレンジ精神０です。
そしてなんの苦労もないからあまりにも甘美…。
仕事が忙しいと悩むリスクを避けてこの禁断の手段を用いてしまいます。
ただ、この手を使っている限り上達はしません。素人にはおすすｍ（略

業界年数重ねてもなるべく【邪道】に走らず、目に腕を追いつかせたいものです。

…すぐに【邪道】万歳になってるから私がまだ③から抜けられないのでは？
ってのは言わない約束。

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

モーションを作成する際、例えば歩きや会話モーションなどは
360度から見てもおかしくならないよう留意して作成します。
いつ、どこから見られているか分かりませんからね。

さて、それがデモの場合ですとカメラ視点に切り替わりますから、撮影されている箇所でしか認識する事が出来ません。（カメラが固定の場合）
かなり大雑把に言いますと、カメラに映っていなければ役者さんが多少おかしな演技をしていも分かりにくくなります。

例えば、とある男性が走っているシーンがあるとします。
実はその男性のモーションは膝が伸びる際に伸びきってしまい、走るたび膝がカクカクなっているとしましょう。
こうなったモーションは、そのままではプレイ中に使用する事が出来ません。
カクカクならないよう、修正する必要があります。
ただ、このモーションをデモで使用する場合、カメラの角度や位置を変えて撮影する事により、修正せずに使用する事が出来てしまいます。
ですが、カメラを変えただけでモーションを修正したわけではありません。
ゲーム制作上、より良くする為にそのデモのカメラ割りが変更になり、上半身だけ映っていた男性が、全身映るカットになる……という可能性もあります。
そうなってしまうと、カメラの調整の他にモーションの修正までも必要となり、制作する上で手間が出てきてしまいます。
特に最終調整の段階でこのような事が起きてしまうと、少しの修正でも大きな時間のロスになってしまいます。

私が専門学生時代、カメラでの演技重視で作っていた時の事。
構図的に矛盾が出てしまい、カメラ割りを大幅に変更するという少々面倒な作業が発生。
カメラの前で演技していたキャラクターは、実は上半身しかまともに動かしておらずその適当さが後々になって大変な事に……。

という甘酸っぱくて苦い経験も、今となっては良い思い出です。（遠い目）

こんな事にならないよう、カメラに映っていない役者さんもサボらずキチンと演技するよう、心掛けておきましょう。

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

先日、ストリートダンスの全国大会予選なるものを見に行ってきました。
ダンサーの方っていうのは、本当に凄いですね。「ホントに人間の動きかよ…。」と思うような人がごまんといました。
流石に予選とは言え、全国大会というだけあって、出場しているのはめちゃめちゃダンスのうまい人ばかり。
今までＴＶでそういったストリートダンスを見たことはあったのですが、生で見たのは初めてでやはり圧巻でしたね。

やはりと言いますかモーションデザインに役立ちそうなものが、たくさん詰まっていました。流石はカッコいい動きを追求する人達。自らの体を使ったモーションデザイナーなのでしょうか。
ものすごい速さで色々な動きをしているのですが、「やかましくない（？）」んですよ。体全体のシルエットが纏まっていて、バランスが良いんですよね。

例えば、LOCKダンスなんかは動きの緩急が非常に分かりやすかったです。「LOCK」と言う文字の通り動きを「LOCK（固定）」する訳ですね。動いている時は、腕をクルクル回したりして、どんな動きをしているのかハッキリ分からない程速い動きなのですが、ポーズを決める時はガッチリ固定。
ゲームでの攻撃モーションを作る時と良く似た動き方の様に感じました。短いフレームで攻撃の動きをトばして、攻撃後のポーズやフォローの部分にしっかり時間を持たせる。動きが止まったり、詰まった部分がしっかり目に残りますね。

また、私もストリートダンスをやって色々な体の動かし方を覚えたいなと思いました。そうすれば、自分が表現出来る動きの幅も広がると思いますし。実際に人が踊っているのを見ていても、体をどう動かせばそういう動きを表現出来るのかは良く分かりませんでした。まぁ動きが速すぎるというのもありますが。
しかし、自分でその動きが出来るようになれば、どこをどう動かせばどんな動きが表現出来るのか分かるはずだと思います。

人間訓練すれば、本当に色々な動きが出来るようになるんだなぁと感心した１日でした。

しかしながら、女性ダンサーのあの悩ましげな腰使いだけは……いやいや、なんでもないです…。

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

先々月に引越し、先週ようやく最後のダンボールが片付きました。
収納スペースがほとんど無いところに引越したので引越しに合わせて収納家具を結構一杯購入。限られた予算の中で場所の制約などの要件に合ったものを探す都合上組み立て家具を選ぶことになります。

組み立て家具って、当たり前なんですが組み立てるまでは家具じゃないので、家具が到着した段階では引越しの荷を解くことができません。
一時期はダンボールで一部屋が埋まる大変な状況でした。
注文家具を毎週組み立てあげては荷を片付けるという作業がようやく先週終わりを迎えたということです。さてそんな週末を送る中で体験した事柄が業務にも当てはまりそうでしたので取り上げたいと思います。

それはとある日曜日、その日の家具は本棚でした。
サイズは横90cm程度、高さは2m超とまぁまぁ大きく、上側と下側で奥行きが違うため形もただの矩形ではなくパーツもまぁまぁ多様です。
しかし、組み立て説明書は５ページほど。

それまで組み立ててきた中で最も少ないページ数です。
確かに、これまで組み立ててきたチェストやカウンターは引き出しや扉が付いていたのでその分パーツが多く大変でした。
今回は結構楽できるのかと期待しながら組み立てを開始。本棚ができたら箱がだいぶ片付くのでとっとと終わらせよう…

1ページ目

へー不思議な手順だなっとちらっと思いましたがすぐに作業を開始。接合部分がなかなか付けにくいので念入りに付けた後、次の工程へ。

愚かなる者、汝の名は…俺
次のページには宇宙の神秘が記されていました。

2ページ目

…。この重量の下、一体どうやったら、一手順でこの図の通りにできるのか。
描いたやつちょっとやってみろやっ！！！
2ページ目の詰め込み具合にびっくりした後、怒りを抑えながら、一挙に与えられた全組み合わせから最も楽そうな工程を検討しているとようやくあることに気づきました。
賢明な皆さんならもうおわかりでしょう。1ページ目で説明されていた手順はその後の作業を著しく困難にする罠工程だったのでした。
まず1ページ目の成果物はこの地上で安定して存在できません。支えていてやらないとすぐに倒れて壊れてしまいます。

ばらばらになっていれば、両側面もしくは底面を下にして普通に
安定した構造を増設していくことで比較的楽に組み立てることができたでしょう。
しかし今や支柱になる部分がとても不安定な形で最初にくり貫かれてしまっているのです。何をやるにしてもやりにくい事この上無し。あわてて最初の構造を分解しようとしましたが時既に遅くボンドが一部くっついて、無理やり抜くと残念な事が起こりそうな状態に。
あ～～っ　う～～っっっ

この棚は結局とっととは片付けられず6時間くらいかかってようやく完成を見たのでした。

毎週家具を購入して組み立ててはいないという方のために念のために言っておきますが、普通は１ページ目の図程度の小規模な手順で完成までの全工程が区切られているものなんです。
この説明はかなり大雑把な部類に入るのではないでしょうか。

しかし、そんな愚痴を言っていても何にもなりません。
結局しんどいのはその工程に実際に取り組んでいる自分達自身、そう思うといろいろと反省点が見えてきました。
今回の事から学んだ事は以下。

・甘い言葉には要注意
　今回はパーツが多くしかも多様さに比べて作業説明が少なす
　ぎました。
　しかし、勝手に合点して楽なんだろうと思い込み、結果本当に
　楽な工程をとることができなくなってしまいました。
　甘い言葉にただ乗っかると後々痛い目に遭うかも…

・常に自分の頭で考えて作業に取り組むこと
　作業のパーツ（要素）をざっと眺めて完成までのステップを思
　い描いて見るとよいでしょう。
　作業手順を誤ると後でとても苦しむこともありえます。

・やっちゃったら、まずは落ち着くこと
　万が一甘い判断に身を委ねて陥穽に落っこちても怒り狂って
　それまで作り上げてきたものを壊したりしてはいけません。
　たとえ後戻りができない状況になってしまっていたとしても
　まずはケーキでも食べて落ち着きを取り戻しましょう。
　不誠実、無責任に打ち明けられた残りの工程も理性を持って
　事に当たったほうが何とかなりやすいです。

・チームワークを大切に
　仲間がいるのであればチームワークを発揮して乗り切りましょ
　う。乗り越えればそれも良い糧になります。
　後に訪れるよい状況に思いを馳せれば案外楽しく乗り切れま
　すよ。

作り上げたそれは大きな恩恵をもって役割を果たしてくれます。
皆さんもがんばって本棚を組み上げてください。