スタッフBLOG

おはようございます。本日の当番、プランナーのK.Mです。
えっと、唐突ですが、今回はオレ、K.M が閃いたゲーム企画について書きます。
…と言っても、週末に思いついたばかりで、まだ全然まとまってません。


ゲーム企画アイデア
-----
【イントロダクション】

　・「死ぬ」＝やり直しではないゲーム。「死ぬ」事こそがゲームの鍵。

　・天国←現実→地獄を「死ぬ」事で自在に行き来できるチカラを持つ主人公。

　・死に方によって、天国行き／地獄行きが決まるらしい。上手く死に分けろ！

【ゲーム説明】

　・主人公は一見平凡なサラリーマン、ジェームズ。勤勉家だが、ドン臭い人物。

　・喧嘩は苦手だが正義感は人一倍。悪事の被害に遭っている人を見過ごせない。

　・が、屈強な悪党に勝てるはずも無く、ジェームズは悪党に殺されてしまう。

　・魂は天国へ昇り、天使の姿へ。背中の翼で宙を飛び、頭上の輪はチカラの印。

　・さっきの悪党が気がかりだ。天国で雲の切れ間を探し出し、現実へ帰還。

　・現実に還って来てしばらくは、天使のチカラを宿したまま。これなら勝てる！

　・天使のチカラで悪党をコテンパンだ！しばらくすると、元のひ弱男に逆戻り。

　・噂では、地獄に堕とされ、帰還すれば悪魔のチカラが手に入るらしい。

　・また別の噂では、死にっぷりによって、天使／悪魔のランクが変わるそうな。

　・天使と悪魔のチカラを宿し、悪党から人々を守れ！正義は、決して死なない！

　-----


いかがでしょうか？
ネガティブイメージの「死」や、宗教色が濃い「天国と地獄」という題材が、
刺激的になる可能性も、足枷になる可能性もありそうです。

閃いた直後なので、自分の企画アイデアを冷静な目で見られない状態です。
また、ゲームシステムや世界観の取っ掛かりを思いついただけの段階で、

　・そのゲームは、ゲーム会社が作りたいものになっているか？
　・そのゲームは、ユーザーが遊びたいものになっているか？
　・そのゲームは、かけた予算よりも売り上げが高くなる見込みがあるのか？

…まで、考えが及んでいません。


実際、会社員としてゲーム開発に従事しているなら、これらに関しての
配慮は重要で、避けて通れません。

閃いたアイデアを自分自身で気に入り、色々と練って膨らませようとする時、
上記のような点に、どの段階で配慮を始めるべきなのか？最初から考慮しつつ
その範囲内のアイデアを出すべきなのか、途中までは製品化について考慮せず
自由にアイデアを組み上げて仕上げ段階で考えるべきなのか、悩むところです。


わざわざ、そんな小難しい事を考えなくても、もし閃いたアイデアが
本当に素晴らしいものならば、

　・会社は喜んで作らせてくれて、
　・完成したゲームをユーザーは楽しく遊んでくれて、
　・結果は、大ヒット！

…となるはずなのでは？と、疑問を持たれる方もいるかと思います。
確かにそうなのですが、発想直後の段階から斬新さとシンプルさを兼ね揃え、
多くのユーザーに支持されるのが目に見えている…というような素晴らしい
アイデアは、そう転がっていません。

今回、「閃いた！」と冒頭で書いたゲーム企画のアイデアも、ユーザーが
楽しんでくれるか？や、ヒットするか？は、皆目分からない状態です。

こういうぼんやり段階の企画アイデアから、いちプランナーが、どんな風に
ゲーム企画書に仕上げていくのか？というプロセスをご覧いただければ、
ゲーム作りを仕事にしたいと考えている人にとって、何か参考にできる部分が
あるのではないかと考え、今回のブログを書かせていただいている次第です。
そうですね、最終的には１０ページぐらいのゲーム企画書にしよう。


もちろん、ゲーム内容を抽象的にぼやかせながらアイデアの練り方や
企画書の書き方のノウハウをアドバイス…なんて野暮な事はせずに、
冒頭で書いたように超具体的にゲーム内容を書いていくつもりです。
完成まで３回ぐらいの連載になるかな？約２ヶ月周期でメンバーが一巡する
ブログ日記なので半年後には完成！のはず。

では、「①発想→構築編」をスタートします！




…と思った矢先、紙面？が尽きましたので、次回に続く！
えっと…、お楽しみに！

おはようございます　本日の当番、プランナーのM.Yです。

先日、野球ゲームに登場する某チーム期待の大型ルーキーのパラメータが決まらないというニュースを見ました。
担当の方はキャンプ地まで乗り込んで能力を見極めてパラメータの設定を行なうそうです。
ということで今回はプランナーの重要なお仕事「パラメータ設定」の話です。

パラメータはゲームのバランスを左右する大変重要な要素であることは言うまでもありません。
ちょっと間違えて設定しているとトンデモゲームが誕生します。
例えば・・・
　■アメリカが舞台のゲームでタバコ１箱の価格が＄1000に設定されていると、ハイパーインフラか！
　■セダンが時速300ｋｍで走れるが足回りが追いつかず市街地を曲がれない設定になっていると、ドラッグレースカーか！
　■敵の武器がプレイヤーのライフを一撃で0にし、1000ｍ向こうからでも当たりますなんてバレットM82ばりの設定になっていると、こんなん勝たれへんわゴルァ！！！
となってしまいます。

開発途中なら笑い話にもなりそうですが、締め切りが迫っているときにミスっていると胃が痛くなるものです。
何事もバランスです。穿ち過ぎた設定にしても、ユーザーがクリアできないなんてことではゲームとして成立しないのです。

さらにリアルのモチーフがあるものはハードルが上がってしまいます。
世間のイメージとゲームバランスとのバランスを取るためプランナーは悪戦苦闘するのです。
ゲーム的なバランスはカンペキでも、掲示板で「○○のパラメータはこんなに低いわけがない」とか書かれたり、モデルとなった本人がショックを受けたり、関係団体からパラメータを上げろとクレームが来たりするなんて逸話があります。

パラメータ一つでゲームは名作にも迷作にもなってしまいます。
プランナーを志望する方は、プランナーが心血を注いで設定したそのパラメータの意味を考察してみるもの勉強になるでしょう。

あなたが倒したモンスターが落としたそのお金は、なぜその金額なのですか・・・？

おはようございます　本日の当番、プランナーのN.F.Hです。
Ｆはファッ○ンのＦになりました。

みなさんは
「おいおい、いい大人がそんな言葉を使うもんじゃないぜ？」
と思いましたか？

まさにその通りです。
３００と１７歳のサイバービーイングはその動詞形を連呼していましたが、ファッ○ンなんて言葉は人前で使ってはいけない言葉です。

みなさんは“放送禁止用語”と言う言葉をご存知かとは思います。
特定の職業、人種、身体的特徴などに対する差別的な表現や、猥褻、あるいは公序良俗に反する言葉などがそれに当たります。
新聞やテレビなどのマスコミで「使わないようにしましょう」と決められた言葉であって、厳密に禁止するような強制力はないのですが、それを見聞きして不快に思う人もいるので、使わないに越したことはありません。

外国語でも“Ｆワード”や“FOUR LETTER WORDS”と呼ばれる同様の言葉のルールがあります。
Ｆワードは先ほどのファッ○ンの動詞形や過去分詞形のことです。
FOUR LETTER WORDSは4文字で構成された汚い言葉のことを指し、シ○ト、ピ○、コ○ク、サ○ク、ダ○などがそれにあたります。
なお、英語ではFOUR LETTER WORDS以外にもビッ○、ア○など４文字以外のＮＧワードも存在します。
伏字ばかりになってしまいましたが、それらの言葉はどれも人前で使っていいような言葉ではありません。

ゲーム中に表示されるテキストについても、そういったルールに従っています。
差別的な言葉や汚い言葉などは、基本的にゲーム内で使うことはありません。
日本ではそういった言葉をゲーム中に使用していると、対象年齢の制限がかかることもあります。

日本語の放送禁止用語ならば、人生経験の中で知っていったり、ある程度は調べることができます。
しかし外国語になるとなかなか情報が少なくなり、
「海外版に移植する時になって翻訳してみたらヤバイ言葉になった」
という場合もあります。
そういった場合は翻訳の人と相談しながら、近い意味をもった別の言葉に置き換えてもらうことがあります。

テキストの修正ならばそのような対応がありますが、ゲームのタイトルの場合はそう簡単にはいきません。
海外版でタイトルが変わってしまうと
　・タイトルロゴやが変わる
　・海外のファンが検索時に日本のサイトを見つけられなれない場合がある
というような不便な事が増えてくるので、なるべくなら避けたいところですね。

そういった事態を避けるためにも、できる限りの情報収集と調査が必要です。
臭いものはすぐにフタがされてしまうため「不適切な表現」に関する情報はなかなか集めにくいものですが、それでも耳を研ぎ澄ませて情報を集めなければ、思わぬ失敗が待ち受けています。

私　：次のタイトルの案を考えてきました。
ボス：ほう？　早速聞かせてもらおう。
私　：“フルメタルユニット　コーディー＆ケリー”です！
ボス：・・・・・・
私　：頭文字をとって通称ＦＵ・・・
ボス：没だ。
私　：・・・ほ、他の案もあるんですよ！
ボス：ほう？　今度こそ大丈夫だろうな？
私　：“シークレットハイランダー　イリスとトーマス”です！
ボス：・・・・・・
私　：頭文字をとって・・・
ボス：・・・君は少し疲れているようだな。
　　　休暇をとってフロリダでバカンスでも楽しんできたらどうだ？

プランナーを目指す皆さんは、日ごろから様々な方面へのアンテナを張り巡らせるように心がけてください。

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

2008年も二月末を向かえ、大阪では雪が降ったり止んだりの日々が続いておりますが…
本年より、この「日報あくせくジェ～ムズ」もう少しだけ、ゲーム会社ならではの…、もう少しだけゲーム開発者っていうお仕事は・・・というのが読み取れるような内容にしたいと、皆頑張っております。

↑
そんなことより、ゲーム制作がんばれよ！

などという声も聞こえてきそうですが、いやいや、どっこい、これが結構大切なことなんです。

日々、「自分の仕事を考えて、それを、出来るだけ面白く他人に紹介するという作業。」これは、開発職にとってかけがえのない能力と密接に関係しているのです。

どういうことか？
では、話をわかりやすくするために、今回は僕の職種である企画マンを引き合いに出して話してみますね。

一般的に企画マンの能力を表す言葉に『企画力』という物があります。

この数値が高ければ高いほど、能力の高い企画マンという事になるわけですが、この数値がくせ者で、なかなか表に出てきません。

某マンガのようにス●ウターでもあれば、

『き…企画力8800！！　バ…バケモノか…』

などとリアクションも取りやすくなるのですが、そんな物はない。

では、これを如何にして導き出すのか？
僕なりに考えた答えは、『企画力という曖昧な言葉を、具体的要素に分解する』という事。

どんなものでも、そうなんですが、曖昧な物を構成する要素を、無理矢理にでも分解してみると、なんとなくそれがわかったような気になってくるから不思議です。

例えば・・・

『スピード感』

　＝　流れる景色　+　頬で感じる風　+　耳をつんざく轟音　+　制御不能の振動


『美味しい』

　＝　口の中一杯に広がる味　+　鼻腔から脳へ流れる香り　+　舌と顎を楽しませる食感


『チョー楽しい』

　＝　おネエさんのきれいな声　+　おネエさんの香り　+　おネエさんの谷間　+　おネエさんの・・・　おネエさんの・・・

どうです？
なんとなくわかったような感じになりませんか？

なんとなくですよ、あくまでも、なんとなぁ～～く。ね。ね。

んでもって、上記のように『企画力』を分解した結果・・・

『企画力』　＝　アイデア　+　構成力　+　コミュニケーション

という感じでは無いかと。

ここまで来たら、あとはもう簡単ですよ。

「こいつ、良いアイデア出しやがる！」→「アイデアポイント加算4000」


「こいつ、なかなかまとめてきやがったな！」→「構成力ポイント加算3500」


「こいつ、上手いこと取り入ってくるぜ！」→「コミュポイント加算1300」

　　→　き…企画力8800！！　バ…バケモノか…

とまあこんな具合です。

で、ここで話を元に戻しますが、日々、「自分の仕事を考えて、それを、出来るだけ面白く他人に紹介するという作業。」これは、企画マン（＝開発職）にとってかけがえのない能力（　アイデア　/　構成力　/コミュニケーション　）と密接に関係しているのというのが、なんとなぁ～～くわかってもらえたんじゃないでしょうか？

ですので、我がアクセスゲームズでは、日々このブログを書くことを、未来の自分に繋がる道だと信じて、社員へ強要、もとい…推奨しているのであります。

ここを見に来てくれている人の多くは、アクセスゲームズの新作情報を求めて来られているのだと思いますが、

その辺は、その辺でうまいことやってますので、とにかくよろしくお願いいたします。
ペコリ。

おはようございます。本日の当番、プロデューサーの角和です。
今回は、私がこの業界に入ったきっかけなどを、お話したいと思います。

あれはまだピッチピチの20代前半の頃、丁度ファ○コンのブームの兆しで、
本体が品薄になりつつあった頃のお話です。

当時は現在のようなゲームプランナーと言う職種が確立していなく、
各社ともデザイナーかプログラマーの募集が殆どでした。

その頃の私はゲームとは違う商品の開発業界で、プランナー兼デザインの
職についていていたのですが、学生時代、授業の合間を縫ってはゲーム
センターに入り浸っていたのもあり、例に漏れず、すっかりファ○コンに
ハマっておりました。

で・・・自分でもゲームを作ってみたいと考える様になり、異業界ながらも
自分の会社のコンテンツを活用したゲームソフト開発の企画書作成を始めました。
いろいろな知人を通じて、ゲームを開発してくれる協力会社に提案
してみたところ、その会社からも「結構面白そうな企画ですね」と
好感触だったので、勢いに乗って資料を纏めて、いざ商品開発会議へ。

ところが、当時はまだ異業界がゲーム業界参入という例も少なく、更には、
「何でうちがゲーム開発なんて、なに夢みたいな事を言っているんだ」と
ばかりに、笑いの渦となり、あえなく撃沈・・・温めてきたゲーム企画は
夢となってしまったのでした。
（今思えば、その直後に、社会現象と言える空前のファ○コンのブームが
到来し、異業界もどんどん参入し中にはヒットしている物もありましたので
時期が早すぎたのかもしれませんね・・・）

あきらめきれない自分としては、若気の至りというか単純と言うか
「ゲーム会社に入ればいいや！」と転職を決意。
さて、どの会社に行こうかなんて、当初は生意気にもえり好みをしていたのですが、
序盤でも書いたように殆どゲームプランナーを募集している会社が
ないと言う時代です。

それならと言う事で、学生時代に趣味で描いていたスケッチや授業の一環で
やっていたデッサンをかき集めて、とあるメーカーへデザイナーとして応募を
すると見事作品審査審査に合格し面接へ。
※なんでも大切に取っておくもんですね
ただ、面接の前に実技試験があるという事で、ちょっと焦りましたが、
そこは持ち前の愛嬌で乗り切り何とか合格する事が出来ました。

　『人間何事も諦めず、粘れば何とか道が開ける』と言う事ですね！

という訳で、紆余曲折を乗り越えて、私のゲーム開発者としての一歩が
始まったのでした。

・・・勿論、自分の企画したゲームが作れるようになるのはまだまだ先の
事ですが、ちょっと長くなってしまいましたので、この話の続きは
またの機会にお話したいと思います。

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

今回は私のオススメの勉強法を紹介したいと思います。

その方法とは・・・
他人のソースを見る！
これだけです。

とはいってもただ眺めているだけでは意味がありません。
ソースを追いながら、自分の知らなかった技術を調べたり
最適化をかけてみたりします。

そのなかで、使えると思ったものはバンバン盗んじゃいましょう。
もちろん、コピペは駄目ですよ。
「全部自分で考えて作りたい！」という人もいるかと思いますが、
スポーツにしろ、料理にしろ、技術を盗むということは成長する上で大切なことだと思います。

とは言うものの、人それぞれに癖などがあって、なかなか難しかったりします。
私自身も、何百・何千行にも渡って書かれているのを見たりすると、もうそれだけで投げ出したくなります。

しかし！
そこはぐっと我慢して地道にがんばりましょう！
プログラマとして就職したならば、他人のソースを見る事が増えるので
ソースを追う力を身につけておけば、必ず役に立ちますよ。

参考書が高いとお嘆きのそこのあなた！
今は、インターネットなどでソースも色々転がっているので
1円もお金が必要ない、財布にやさしい勉強法ですよ！
おひとついかがですか？

・・・まぁ、ただ眺めてるだけでも結構おもしろかったりしますが。
全くインデントをしない人。
極限まで行数を削っている人。
すごく丁寧にコメントをつけている人。
意外とプログラムに人それぞれの性格が出てるんですよね。
「プログラムから見る性格診断！」なんていけるんじゃない？
本とか出したら売れるかなぁ・・・。

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

最近、朝起きるのが辛くて仕方がないのです。
このまま、布団の中で１日中寝ていたい…そんな衝動に囚われてしまいそうです。
まぁ、実際やることは滅多にないと思いますが。

さて、寝起きの話は置いといて、いざ本題へ。
それは最近思ったことなのですが…

専門学校の友達と話をしている時のことです。
私は、ある言葉を就職してから口癖のように連呼してるのですが、
この日もいつものようにその一言を口にしたのです。

『ゲーム作ろうぜ！』　と。

すると友人からは、これまたいつも通りの返答が帰ってきます。

『じゃ、絵描いて』　と。

ここで

『自分で描きやがれー』　と言う事も出来るのですが、あえて言うのです。

『まかされたー』　と。

とまぁ他愛もないやりとりな訳ですが、ここでふと思ったのです。

モデルやら背景やらを自動で作ってくれるようなソフトはないものかなぁ　と。

そうなのです。ゲームを作るにしても、プログラムをテストするにしても自分で、モデルやら背景やらを作らないといけないのです。
ゲームを作ろうとしている場合には問題にならないのですが、プログラムのテストをしたいだけの時には、コレがかなり億劫に感じられます。

『俺はプログラムがやりたいだけなのに…』　なんて思い始めたら最後です。
数分後には、ほぼ確実にやる気がなくなります。
そして最後には友人に一言こう告げるのです。
『また明日がんばるわ。』　と。

これがいつものパターンになりつつあるわけですが。それではいけないのです！
そんなことでは、いつまで経ってもヒヨコのままなのです！！
そんなこんなで、モデル作りからゆっくりと取り掛かることにしようと思いました。昨日から。三日坊主にならないことを祈るばかりです。

え？四角形とかじゃダメなのかって？？
もちろんダメじゃないですけど…なんか、ねぇ？
やっぱり、やる気が出ないと言うかなんというか。
あ、あれですよ。
３Ｄで地面の当たり判定をやる場合、地面が板ポリだと細かい所を確認できないのです。そうなると、地面のモデルを変更した時に…

・穴が無いのに落っこちたり
・壁をよじ登ったり
・壁の間に挟まったり

なんて危険極まりないことになるかもしれないのです。
画面一杯に黒い世界が誕生してしまいかねないのです。
挙句の果てにはフリーズなんていう現象まで引き起こしやがります。
ＰＣが動かなくなったら危険信号です。

データが消えたなんてことになると…目の前が真っ白になります。
もうこうなると発狂するしか選択肢はありません。
偉い人はこういいます。『諦めましょう』　と。
あぁ、恐ろしい。恐ろしい。

…何か脱線してる気もしてきますが。
まぁ色々と支障が出てくるものなのです。

という訳で、モデル作りから始めることにしました。
寝る間も惜しんで勉強しろ！　という偉い人の言葉を胸に刻みながら…
そんなこんなで睡眠時間を減らして趣味の時間を増やそうと画策しています。
目指せ！　三時間睡眠！！　です。
もちろん、昨日から。三日坊主にならないことを祈るばかりです。

では、１日でも早くヒヨコから卒業するべくがんばりたいと思います。
もちろん、昨日から。…あ～眠たいなぁ。

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

コンシューマのゲーム開発で、最初に驚いたことを書こうと思います。。

学生だったころには、主にはVisualC++でWindowsアプリを作って勉強して、
自分の中では、このコンパイラが標準化してました。

コンシューマなどでは、コンパイラは当然別の物をつかいます。
そして、中には日本語に完全に対応できていないものなどがあります。

元々、プログラムのコードで日本語は文字列以外では使うことは無いので、問題ないですが、「コメント」は別で、当然のごとく日本語でコメントを書きます。

ただ、そこで要注意なのが、日本語の文字コードは2バイトで表されます。
問題があるのはその2バイト目が'￥'(5c)になる文字です。

問題のあるものを一部挙げますと、
'ソ''欺''圭''構''蚕''十''申''貼''能''表''暴''予''禄'
こんなやつ等で、
どういうことになるかと言いますと、

構造体のメンバでのパターン

struct test
{
int iMotionList[10]; //モーション対応表
int iLists; //表内の数
};

↓使う場所では。。。

test t;

t.iMotionList[0] = 10;
t.iLists = 1;

みたいに普通に使ってコンパイルをすると・・・・

iListsなんてメンバーはネェよ！！　とコンパイラがお怒りになられます。
思わず、「えぇ～～？　定義してるよぉ。。　どうして？」となってしまいます。

どうなってしまったかと言うと・・・

struct test
{
int iMotionList[10]; //モーション対応,0x95,'\\)'n' int iLists; //表内の数
};

表の部分の2バイト目の文字の'\'と改行コードの'\'が2つ並んで'\\'となって、改行コードが無くなって、下の1行が後ろにくっついて、1行コードがなくなってしまったのです。
これも十分タチが悪いですが、エラーという形でコンパイル段階で発見できるので、まだ優しいほうです。

エスカレートして、この手のパターンでタチが悪いパターン

//発射可能
if( IsShoot() )
{
...
}

↓

//発射可,(0x94),'\\'nif( IsShoot() )
{
...
}

これだと、条件が無くなってしまって、完全に別のコードになり、
コンパイラも特に文句も言わずにコンパイルが終わってしまいます。

そしてタチの悪いバグがここに誕生します。

最初、事情を知らずに、この問題に遭遇したときには、
まったく意味がわからずに、かなり悩みました。。

しかも、原因は、一番無関係と思いがちな、コメント。

今では、フィーリングで、「多分これじゃね？」といった具合に、慣れてきましたが、
そもそも、そんな問題が起きないコードを書くのが一番。

なんて思いながら、コメントをみんな英単語で書き始めたりしようとした時もありました。

あまりに英語力の無い自分の書いたコメント。
当然のように、可読性が低下します。
そして、この挫折感。

結局、なんだかんだで普通に日本語でコメントを書いてる自分がいたり。。。

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

さて、今回は関数名のお話です。
皆様は関数名を決める時どのような規則で命名しますか？

僕の場合、一番重要視しているのは「意味が通じること」です。
こと関数に関しては他の人が使う可能性もあるため、
これが何をするためのモノなのかを簡潔かつ明確に示すことが重要になります。

今となっては至極当然のことに思えるわけですが、
少し前まではこんなことを全く考えていませんでした。

当時の命名の方法はまずそれっぽい英単語を選んで、フィーリングで並べるだけです。なので、その時々で同じ役割の関数でも名前が違ったりします。

例えば、プレイヤーを攻撃する関数を作成するとした場合、
それっぽい英単語を並べてみると
Attack Player とか Player Attack になります。

しかし、この二つ実は全然意味が違うんですね。

Attack Player → プレイヤーを攻撃
Player Attack → プレイヤーが攻撃

といった具合です。
前者であれば問題はありませんが後者の場合は全く意味が逆です。
前述の通り昔の僕はその時々でどちらかを適当に使っていました。

ハードディスクを整理していてこんなソースを見つけたときはへこみます。
俗に言う黒歴史というやつです。

　
現在はそのような間違いが発生しないようにこんな方法を実践しています。

ex) ポジションを設定する関数を作成するとした場合

１．まず日本語で命令を作る
→「ポジションを設定しろ」

２．某翻訳サイトにて翻訳してみる
→「Set the position.」

３．適当に整形したりする
→「SetPos」

ざっとこんな感じでしょうか。
何にしても関数に命名するのは結構気を使います。
それこそ仕事そっちのけで名前を考える勢いです。

皆様は如何でしょうか？

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

最近ですが、どこかでこんな言葉を聞きました。

「仕事に私生活を持ち込むな！！」

なんか聞いたことのある台詞ですが、、
そこで自分の仕事に対する私生活の持ち込みっぷりを見てみると
私物で購入したゲームを昼休みに遊んでるくらいですかねー。
ていうかこれって私生活を持ち込んでいることになるんでしょうか？

どうなんでしょう、、

まあ、とりあえず仕事がうまくいけば、
どっちでもいいんじゃないかと思います。
私もまだ若いのでそんなことはよくわかりませんが。

プログラムにおいても、

「他のプログラムに必要な情報以外は、公開しないほうがいい！！」

っていうのは当たり前でさらに、

「公開すべき情報はなるべく少なく！！」

なーんて言われることがありますが
実際制限しすぎると、そのプログラムが使いにくくなったり、
コードの量が大幅に増えてしまう場合が多々あります。
なのでそこは、きちんと公開すべき情報としない情報を
きちんと見極めて分ける必要があるのです。

でもそんなの完璧にわかる人なんているんでしょうかねぇ。
私の思うところプログラムがきちんと動けば、
どっちでもいいような気がするんですが。

まあ、結果的に何が言いたいかって言うと、、
私もまだ若いのでそんなことはよくわかりません。

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

日々プログラムを記述している私ですが
その際に気をつけていることのひとつに『コメント』があります。

プログラムでのコメントとは例えば

　　SearchTarget();　//　ターゲットを探します
　　AttackTarget();　//　ターゲットに攻撃をします

のように書かれたときの 『 // 』 より後ろに記述されたものになります。

このようにコメントを書くことにより、
ここではどのような処理が行われているのかなどが分かりやすくなります。

ただ上で挙げた例のようなコメントは、
関数名を見たり流れを確認すればなんとなく分かりますので
特にコメントが無くてもそこまで困ることはないと思います。

では、コメントの何を気をつけているのか。
それは『 この処理が何をしているか 』も重要ですが、
それ以上に『 なぜこのような記述になったのか 』ということです。

いくつか例を

　
例１

　　//　敵１の行動
　　{
　　　SearchTarget();　//　ターゲットを探します
　　　AttackTarget();　//　ターゲットに攻撃をします
　　}

　　//　敵２の行動
　　{
　　　AttackTarget();　//　ターゲットに攻撃をします
　　}

　　なぜ、敵２は SearchTarget() が無いのでしょうか？
　　このように書けば迷わずにすみそうです。

　　//　敵２の行動
　　{
　　　//　敵２は必ずプレイヤーを狙うので他のターゲットは探さない
　　　AttackTarget();　//　ターゲットに攻撃をします
　　}

　　このコメントが無い場合、後々見直したときなどに
　　『 あ、敵２がターゲットを探してないや 』という感じで
　　敵２に SearchTarget() を追加してしまうかも知れません。
　　そうなると、敵２がプレイヤー以外のターゲットに向かってしまい
　　思ったとおりの動作をしなくなってしまいます。

　
例２

　　//　キャラクターのパラメータ設定
　　//　とりあえず
　　chara_HP　　 = 100;
　　chara_Speed　= 10;
　　chara_Power　= 10;

　　なにが "とりあえず" なのでしょうか？
　　昔、このコメントを書いた自分を問い詰めたくなります。

　　そんな時はこんなコメントを付け加えておけば焦ることは無いでしょう。

　　//　キャラクターのパラメータ設定
　　//　パラメータが存在していない時はこの数値を使う
　　chara_HP　　 = 100;
　　chara_Speed　= 10;
　　chara_Power　= 10;

　
などなど、後から読み返すと
『あの時の私は何を考えてこれを書いたのだろうか？』
と思うコメントに出くわすことがあります。

そしてプログラムを読み返して『あー、こうしたかったのね！』
と思うと同時に『ちゃんとコメント書いとけや！わし！』
となるわけです。

　
例３（例１・２と少し意味合いは違いますが、他にもこんなのがあります）

　　//　敵３の行動
　　{
　　　AttackTargetSword();　//　剣で攻撃します
　　　AttackTargetGun();　　//　剣で攻撃します
　　　↑（本当は銃での攻撃）
　　}
　　（コピペしてコメントだけほったらかしになっとるがな・・・）

　　これだけならまだしも、
　　やっぱり敵３は剣での攻撃は無くそうとなった時、
　　AttackTargetSword() の行だけを消したら

　　//　敵３の行動
　　{
　　　AttackTargetGun();　　//　剣で攻撃します
　　}

　　この１行だけになってしまいます。
　　プログラムとコメントが違っているという状況になり
　　後で見直したときに『ん？』となりそうです。

　
未来の自分がそのプログラムを見直したとき焦ることがないように
そして、他の人が読んだときにも誤解を与えないように
プログラムだけでなくコメントも的確に書いていきたいものです。

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

私は名前を考えるのが大変苦手です。3歳くらいに飼っていた、雪という名の白猫に子供が3匹出来ました。
基本白に眉間にちょっとだけ黒い斑が合った猫に「チョボ」
親と同じ白猫に「スノー」
泥をぶっかけたような斑模様で、子供心にばっちぃと思い「バッチ」
と付けた記憶が残っています。

今でも、ゲームの主人公の名前は、デフォルト設定がなかったら、
「お茶飲んでるし、茶っ葉で。」
「アフロだし、ボンバ。」
等、連想ゲームになるくらい安直です。こんな名前のキャラに愛着沸かないと思う人もいるでしょうが、意外と気になりません。

こんな私ですが、仕事の上で、プログラムで用いる識別名等は、意味のある名前を唸りながら真面目に考えてます。識別名が正しくないと、プログラムの解析難度があがります。今日昼ハンバーグだったから、
int iHamburger; // 昼はハンバーグ食べました。　これはカウンタとして使います。
みたいなことはやりません。こんなことすれば、自分の首を絞めます。プログラムソースのカオスっぷりに、何をやっているかわかりませんし、そもそも先輩がマジギレします。職場の雰囲気が悪くなります。私も他の人がこんなソース書いてたらマジギレですよ。識別子が全部食べ物とか、一度なら見てみたい気もしますが、自分じゃやりません。

上のようにカウンタなら、
int iHamburgerCount; // これはハンバーグの数をカウントします。
みたいに素直に識別名を付けます。慣習や命名規則に従って識別名を付ける分には楽なのですが、ちょっと変わったことをしていると、英語のスペルが分からないって事があります。こんなときはネットや辞書で調べるのですが、間違ってもローマ字で識別名を付けてはいけません。スペルミスもだめです。
「なんでローマ字やねん。かっこ悪。」
「スペル間違ってんで。かっこ悪。」
とか恥ずかしい思いをします。職場の雰囲気が悪くなります。私にはM気はないので勘弁。M気あったら職場の雰囲気がピンクになります。

ネーミングセンスは微妙ですが、職場をピンクにしないように、しっかりと名前をつけようと思います。

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

私は、プログラムを組んでいる際に、ふと、いかにサイズの小さい、高速なコードを書けるか？ということにチャレンジしたくなる時があります。
（当然、激しく忙しい時はそんな余裕はありませんが…）

大体の場合、サイズを小さくすると、低速化してしまったり、高速化すると、サイズが肥大してしまいます。

で、その情熱を満たすために、本やネットで色々と検索して見るわけです。
世の中は広いので、色々と有用な情報を入手する事ができ、様々な局面で重宝します。

今日も今日とて、その情熱を満たすために、色々と調べていたその時！

…

驚愕のプログラムを発見しました…

そのプログラムとは以下のとおり…

<body onKeyDown=K=event.keyCode><script>X=[Z=[B=A=12]];h=e=K=t=P=0;function Y()
{C=[d=K-38];c=0;for(i=4;i--*K;K-13?c+=!Z[h+p+d]:c-=!Z[h+(C[i]=p*A-Math.round(p/
A)*145)])p=B[i];!t|c+4?c-4?0:h+=d:B=C;for(f=K=i=0;i<4;f+=Z[A+p])X[p=h+B[i++]]=1
if(e=!e){if(f|B){for(l=228;i--;)Z[h+B[i]]=k=1;for(B=[[-7,-20,6,17,-9,3,6][t=++t
%7]-4,0,1,t-6?-A:-1];l--;h=5)if(l%A)l-=l%A*!Z[l];else for(P+=k++,j=l+=A;--j>A;)
Z[j]=Z[j-A]}h+=A}for(i=S="";i<240;X[i]=Z[i]|=++i%A<2|i>228)i%A?0:S+="<br>",S+=X
[i]?"■":"＿";document.body.innerHTML=S+P;Z[5]||setTimeout(Y,99-P)}Y()</script>

ギュウギュウに詰まって、見難いプログラムとはいえ、たった７行です。

このコードをテキストファイルにコピペします。
次に、このファイルをtest.htmという名前で保存します。
（別にtestである必要はないですが…拡張子がhtmならなんでも良いです）

当然、ファイル拡張子がhtmなので、ブラウザで開くことができます。

開いてみると

…

うぉ！テトリスだ！テトリスだよ！！！
７行でテトリスだよ！！！
（ちなみにカーソルキーで移動、エンターキーで回転です）

これは驚いた。
ここまでまとめれるとは…

ここまで、極端な結果は求めないにしても、プログラムの縮小・高速化は、常に目指して行きたいものです。

　
プログラム参照
http://www.geocities.jp/nanagyou/list.html

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

プログラムを書いていくと、
当然のごとくコード量が膨大になっていきます。
ですので、コードの整理作業を、
タイミングよく行う必要があります。

普通の人なら「大変そうだな～」と思ってしまいそうなこの作業ですが、
プログラマにとってはそうでもないのです。
なぜなら、この関数をまとめるという作業が、
気分がすっきりする大変心地よい作業だからなのです。
…いやまぁ人によるとは思いますけども（笑）

僕の場合、
「おっ、この関数とこの関数は、まとめられそうだな」と閃いた時は、
すごく幸せな気分になります。
その閃きを元にコードを組み替え、
きれいにまとまったコードが完成した時は、
まるで難しいパズルを解いたときのような感動があります。

ソースコードの整理作業は、
保守性を高めるのはもちろんなのですが、
上記のような効能（？）もあるのです。
自然とコードを見るのも楽しくなってきますね。

モニタに映し出されるコードをおかずに、
ご飯３杯食べれるようになったら、
あなたも立派なプログラマーです！

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

というわけで、デバッグ用出力の話です。

プログラミング経験がある方々は、ご存知だと思いますが、大抵の開発環境には、デバッグ用の出力命令として、TRACE命令（もしくは、それに準ずる関数）という、デバッグ用の画面に任意の文字列を出力する機能が用意されています。

このTRACE命令、処理の内部状態を把握する際に、手軽に使用されるのですが、致命的な弱点が２つあります。
ひとつは、外部デバイスに出力するため、一定以上の速度がでないこと。もうひとつは、出力の履歴を残せる範囲（スクロール可能範囲）に限りがある、ということです。

例えば、１秒間に６０回の更新が行われる処理上で、１００個あるキャラクタ全ての３次元座標の変遷を確認したい、となった場合、これをTRACE命令で実装すると、大変なことになります。

まず、外部出力の割り込みのために、１秒間に６０回の更新が行われなくなります。下手すると、１秒間に２回程しか更新されない、ということになってしまいます。

通信用のデバイスや、メディアデバイスと同期をとる必要があったりすると、致命的な問題も発生します。
なにより、こういった確認が必要なとき、バグ原因の究明を目的としていることが殆どなので、プログラマはもう既にイライラしています。
そんな状況で、通常の１／３０の速さで動作などという事態を余儀なくされるなら、確実にキレます。職場内の雰囲気が悪くなります。ダメダメです。

また、出力内容を確認し易くするために、文字列内に目印を入れたり、改行をふんだんに使用していたりする（通常はこういう工夫をします）と、「あっ」というまにスクロール範囲外に流されていってしまうので、極力改行を減らす必要が出てきます。

当然、内容は見辛くなります。

こういった確認が必要なとき、何時間もソースコードとにらめっこした後だったりすることが殆どなので、プログラマはもう既に目がお疲れです。
そんな状況で、通常の３０倍も見辛い文字列を確認するなどという事態を余儀なくされるなら、確実にキレます。職場内の雰囲気が悪くなります。もうダメダメです。

こういった危機的状況を未然に回避するために、デバッグ用のメモリ領域に文字列を出力する、という、やや古典的な技を使用します。

　　　デバッグ用のメモリ領域に出力
　　　　　　　　　↓
　　　適当なタイミングで処理を中断
　　　　　　　　　↓
　記録の先頭位置からメモリダンプを表示
　　　　　　　　　↓
　　　　　　任意の範囲をコピー
　　　　　　　　　↓
　　　バイナリエディタなどにペースト
　　　　　　　　　↓
　　　　　　　ファイル保存
　　　　　　　　　↓
　　　　　拡張子を‘txt’に変更

これをダブルクリックすると、座標記録テキストの出来上がりです。

古典的とはいえ、メモリダンプ上の文字列を直接読んでいた昔に比べて、かなり楽にはなっています。偉大なりコピー＆ペースト。

もっとも、この方法も、確保できるメモリの容量に限りがありますので、文字列での出力にしてしまうと、確認するのに十分ではないかもしれません。

そうした場合、結局、生のバイナリを出力して確認することになってしまうのですが、こういった確認が必要なとき、プログラマはもう既に混乱気味なので、生バイナリを読むよりも前に、取り敢えずキレます。
職場内の雰囲気も悪くなりそうですが、案外そんなこともありません。

こういった確認が必要なとき、他の皆んなはもう既にきちんと仕事を終えて、家に帰っているからです。

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

さて、最近のパソコンでは、マルチプロセッサー搭載機が当たり前になっています。
ひとつのＣＰＵでは処理を賄い切れないから、それならＣＰＵを複数積んで
複数の処理を一気をやってしまおう！という発想です。

それはパソコンに留まらず、最近のゲーム機（いわゆる次世代機）でもトレンドと
なっています。処理速度においては、２０年前のそれとは雲泥の差です。

そんな沢山のＣＰＵがあるんだから、今後のゲームはもっと凄くなるのでは！と
思うでしょうが、実際はそんな単純な話ではないのです。

複数の処理を同時に行えるのが、マルチプロセッサーの強みなのですが、
逆に複数の処理を「効率良く」出来なければならない、という弱みもあります。
この「効率良く」というのが、各ＣＰＵを制御する「プログラム」に懸かっています。

例えば、、、

「御飯を食べながら、新聞を見て、なおかつテレビの情報を集める」

などという行動（処理）を人間（制御プログラム）が行うとします。
要領の良い人間であれば、そそくさと済ませられるのでしょうが、これが
不器用な人間だと、パニックに陥ってしまい、結果としては、逆に時間だけを
浪費する結果となります。

それなら、要領の良いプログラムを作ればいいやん！と思うでしょうが、
そうもいきません。並列処理のもうひとつのワナ、「依存関係」です。

依存関係というのは、Ａが無いとＢが出来ない、などといった関係で、
これが沢山あればあるほど、本来のマルチプロセッサーの強みである
同時処理は難しくなります。

先程の要領の良い人間（制御プログラム）が、車でドライブをするとしましょう。

助手席の人と会話をしながら、運転をする事は問題無く出来るでしょうが、
地図を開いて目的地を凝視することは出来ません。そんな事をすれば
間違いなく事故（バグ）になるからです。
いくら要領の良い人間でも、これは無理ですね。
一旦、車を停める（処理を止める）ことになります。

こういった依存関係は、ゲームプログラムにおいても例外ではなく、これを
<効率良く処理するのは、なかなかの至難の業です。次世代機における
ゲームプログラマーの腕の見せ所ですね。

「処理速度が速ければ、面白いゲームになる！」という訳ではありませんが、
速いに越したことはありません。
私も決して要領の良い人間ではありませんが、
本業だけは出来るだけ「効率良く」仕事をしたいもんです。

おはようございます。
本日の当番、「賭博黙示録　俺」ことＣＧデザイナーのT.Nです。

入社してそろそろ１年を迎える僕ですが
まだまだ若輩者で、ミスも多くいまだに先輩に「へたっぴさ、T.Nくんそうへたっぴだ。」と罵られたり花山薫ばりの握力で太ももをつねられたりしています。

さて、そんなトンチキな僕ですが仕事をする上で少しでも良いものを作るために色々と心がけていることがあります。
それは正確性だったり、作業速度だったり、クオリティーだったり、データの整然さだったりするわけですが今回は、作業スピードについてあれこれ書きたいと思います。
僕は入社する前にインターンシップとして数ヶ月働かせてもらっていましたが
その時に一番痛感したのが

「俺、遅ぇ・・・！」

ということでした。
自分の作業スピードの遅さに絶望した僕ですが、
どうにか早くならないものかと色々工夫をしたわけですよ。
とりあえずすぐにできることとして

・早くするようにこころがける
　　→これは基本ですが、牧歌的に生きてきた僕にとって突然の狩猟生活の
　　ようなもの。しかし、意識次第で誰でも戦闘民族になれるはずです。
　　とても重要なことです。
　　
・作業内容を整理してから取り掛かる。
　　→慣れない仕事。データ量の多さにパニック状態になり、あれこれ考えてしまい
　　手が動かない。なのでまず何をやるべきかを決めてノートにまとめたりしました。
　　情報が整理されると作業にも自信を持って取り組めるものです。

・Photoshopのアクション機能を使ってみる
　　→毎回同じ処理ばかりをしていると、「俺はロボか！」と突っ込みたくなります。
　　自動化できる部分は、ツールにやってもらって作業効率アップ
　　　　
・ショートカットキーを多様する。
　　→マウスやペンタブを動かしている時間がもどかしいし、その都度
　　ツールバーを押してたのでは集中力が切れまくりボンバーなんですね。これが。
　　左手はキーボードに添えたまま！

など、色々と取り組んでインターン時代をなんとか乗り切ったわけです。

いまでも上記のことはしっかり取り組んでおります。
　　　　
特にショートカットには異常なこだわりを持っていまして
保存やツールのショートカットだけでは飽き足らず

Alt＋E→A→H　で水平方向に反転
Alt＋S→T　で選択範囲の変形　　　　（photoshop調べ）

など、ショートカットに設定されていない機能もメニューバーから
コマンド入力したりします。

「おいおい、全部覚えてんのかよこいつ。なんか気持ちわりーな」

と、思う無かれ！

まあ、気持ち悪いのは気持ち悪いかもしれませんが、
すべてを覚えているわけではなく、よく使う機能とか、その時に多様する
機能を一時的に覚えているわけですね。

「だからなんなんだよ、良いものを作るところに繋がってねーよ！！
こんちきしょーめ！」

と思う無かれ！

節約した時間は、作業に当てることができるのでクオリティーアップに貢献できたりするわけですね。へへ。

ただ、もっと早く！もっと軽やかに！！
急ぎすぎて正確性に欠けてしまう部分も多々あるので
太ももの肉がなくならないうちに、ミスがなくなるよう精進したいと思います。

P.S.
photoshopのアクション機能にショートカットキーが使えれば奇跡なんですが
もし、そんな機能があるのでしたら教えていただきたいです。

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

実は、私だって「工場萌えだ！」と書こうと思っていたのですが…数日前に先を越されてしまいましたので（笑）別の今更的なお話を少々。

私は歪みとか、汚れとか、雑然とした雰囲気が好きです。
※背景の話です。
入り組んだ構造や、使い込まれた感じも大好物。
整然とした空間より味があると思うからです（もちろんコンセプトやシチュエーション次第ですが）

3Dで、近代建築のプリミティブを組み合わせた様なシンプルでカッチョイイ空間を表現しようとすると、なんとなく味気なく間の抜けた絵面になりがちです。
建築は実際のその空間に行ってみてこその真価、だと思うのです。

なので、「絵面としての背景」を作る上で前述した「味」を大事にしたいな～と思うのですが。2Dの絵だと簡単に表現できるところが、3Dで作るとなると結構骨が折れるんですよね；

作りこむ事でポリゴン数・テクスチャ量が増えるとスペック上の制限に直結しますし、作業上に於いても工数がかかったり、修正が面倒になったり、使い回しが困難になったり…orz（そもそも仕様との絡みもありますしね）

まあ、そんな文句を云っても始まらないのでなんとか制限の中でひと手間かけてよりよく見える工夫をするわけですが。

以前に3D習いはじめの方の作品を拝見した折り、どうも「近代建築のモデルルーム」っぽいな～と感じたことがありました。

小奇麗なんだけど、整然としすぎていて人の匂いがしないというか、なんというか。
例えば…整然と並んだ椅子の一部をちょこっと移動・回転させて配置するだけでも椅子を使った形跡が残せますし、敷居の中央をすり減らした表現にすれば利用する人の多さを想像させたりできますよね。

そういう小さな工夫の積み重ねで人の手が入った雰囲気を作り出せるのではないか、と思います。

現実では人がいる事によって発生する無作為な現象が、3Dでは作為的に作ってやらないと表現できないんですよね。そこが難儀なところであり、工夫し甲斐のある醍醐味だとも思ったのでした。

諸々の制限ぎりぎりいっぱいまで使って「味のある空間」作りのために、日夜努力しています。皆さんも是非、「作為的」に素敵な空間作りを目指してみてください。

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

今回はデザインする上で個人的に注意していることを書きたいと思います。
日頃目に入る物を注意してるので結構デザインが助かりますが、
妄想もやってます（変な意味じゃないですよ）

何かデザインする時は、「あの建物をこういう感じで～」とか「あの国の建物がイメージに近いかなぁ～」とか
いろいろな設定があります。

背景をデザインする時に、設定とは違うものを作らないように、頭の中に見本となる街や建物を思い浮かべ、実際に自分がその場所で生活している様子を妄想しています。

たとえば、日ごろ歩いている道を一つ作るにしても形や曲がり方などさまざまな種類があり、道が曲がっているなら多分こんな車が通ったりしているんかなぁとか、道は耐久力を増すために表面を石・煉瓦・コンクリートなどで舗装してるんかなぁとか、道の小さな隙間から草が生えてたりしてるんかなぁとか、所々崩れていたり色が変化したりしてんのかなぁなど、道の出生を妄想します。

また所々崩れていたり、色が変化していたりしてるのは、何でそういう変化が起こるのだろうと、考えたりもします。
雨が多い場所なのか？車の石油が流れて変化しているのか？気候の影響で変化しているのか？
どんな場所に道が作られてるんだ？とか国？都会？田舎？そこに住む人はどんな人？どんな性格？・・・・。
もう頭の中が小さな国になってたりして、違うものまで妄想している時もあります。（笑）

自分が知らないものや外国の建物をデザインするときは、見本となる外国の資料を集めたり、その国の土の色や生えている草の種類や気候や・・・特産物や祭りの種類や有名人や・・・・関係ないものまで調べ、
やっぱり、頭の中自分がその場所に住んでいるような妄想をします。

妄想終了時に頭の中を覗いたら、本当に街や建物が出来ているかもしれませんね。（笑）

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

今回は、背景デザインで普段から心がけていることについて語ってみます。

３Ｄゲームでの背景は、スケール感も重要な要素です。キャラクターの大きさ、モーションに合わせて高さ・幅・広さをきちんと作っておく必要があるんですが…

○ＴＶ画面を通しての３Ｄ空間は現実よりも空間が把握しにくい
○第三者視点カメラが入る空間の確保
○プレイヤーに認識しやすいよう身振りの大きいモーションが多い
○キャラの身長が美形モデル体形180cmオーバーで対象が小さく見える

などなど、様々な理由があって、ゲーム中では現実のスケールより、やや大きめに作ることが多いようです。

現実よりやや大きく作るには、現実のスケールを把握しておく必要がある訳で、身の回りの物の大きさを知っておくといいですね。

　
ということで、計ってみよう。

　
ドアノブの高さ。

100cm！

　
エレベーターの下りボタンの高さ

124cm！

　
階段の一段の高さ

20cm！

　
…とまぁ、こんな感じ。しかし、これだけではまだ底が浅い。これは会社のビルで計ったので、オフィスのスケールサイズなんですね。これを一般家屋に当てはめて作成すると問題が出ることがあります。さらに、ゲームの舞台が外国であれば、その国でのスケールサイズが必要になってきます。

自分はメジャーを持ち歩いて、気になった時にはこっそり計ったりしてます。メジャーが無いときは、膝までの高さは～cmと長さを覚えておいて、自分の体で計る方法もありますよ。