スタッフBLOG

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

ワールドカップもベスト８が出揃い、いよいよ大詰めですね。
日本代表は残念ながら昨日の試合で負けてしまいましたが、
開催前の予想をいい意味で裏切り、世界を驚かせてくれました。
おつかれさまでした。

予想と言えば、ワールドカップ開催前に恒例の
最新サッカーゲームを使った全試合シミュレーションが
行われました。

シミュレーションの結果は、
今欧州で最も勢いのあるスペインとサッカー王国ブラジルが
決勝戦を戦い、スペインが優勝しました。
ちなみに日本は予選リーグ敗退だったそうです。

たしかに所属する選手の顔ぶれだけを見れば納得のいく結果です。
しかし、ふたを開けてみれば日本は予選リーグを見事に突破し、
逆に予選リーグ突破するというシミュレーション結果が出ていた
イタリアやフランスは涙を飲んでいます。
選手のパラメータを積み上げただけでは読めない勝負の世界、
それがスポーツの醍醐味ではないでしょうか。

今大会はそういった番狂わせを起こす要素がたくさんあります。
さすがに、ゲームエンジンの中に「ブブゼラ効果」や「ジャブラニ補正」、
「チーム内紛イベント」までは反映しきれなかったのは仕方のないことです。

ゲームプランナーは作りたいゲームを表現するために、
こうした多くのパラメータを扱うことになります。
パラメータの基本は数値と計算のオンパレードなので、
やはりプランナー志望の人は数字に強くなって欲しいですね。
さらに、グラフなどを使って全体をグラフィカルに把握出来る能力が
あればサクサク仕事がはかどることでしょう。

不安に思えてきた諸君、心配ご無用。
パラメータ作成のコツは、先に完成形をイメージすることだと思います。
どうしても端から作りたくなってしまうけれど、
完成形から逆算して作った方が余計なパラメータに埋もれて身動きが
取れなくなることも無くなるでしょう。
あとは、下手な計算するくらいなら直接数値を入れてしまう
大胆さを持つということでしょうか。

さぁ、サクサク仕事終わらせてサッカーを見に帰ろう！

おはようございます。
プランナーのM.Hです。

本日はタクシーのお話。

最近、タクシーを利用することが多くなりまして、色々なタクシーに乗ります。
深夜帯ですので料金が２割増だったりで、懐が寂しい今日この頃ですが、
高いお金を払ったとしても、子どもの寝顔と、朝の家事手伝いのため、
がんばって帰ります。

以前は、タクシーに乗ると、ぼへ～としていることが多かったのですが、
最近は、タクシーの運転手さんと色々とお話をすることが面白く感じるようになりました。
やはり、色々なお客さんを乗せていることから、話上手な方が多いです。


大体聞くことは、

・運転手さんの仕事時間
・最近のお客さんの傾向
・業界について


といった、お約束？という内容なのですが、
毎回聞いていますので、大体返答の傾向がわかる様になります。


仕事時間に関しては、夕方～深夜の方が最も多く、
次いで、私を乗せた後はもう切り上げて帰るという方が多かったです。
中には、朝まで仕事して、そこから打ちっ放し行くぜ！というパワフルな方もいました。

お客さんの傾向に関しては、深夜帯になってくると以前の様に
接待や残業などによる男性客は減少傾向にあり。
逆に女性客が多いという意外な結果が！

業界に関しては、敢えて言及しませんが、どこも一緒ですね。


こういった話は、実際に仕事に携わっている方でないと分からない内容ですので、
私としてはとても貴重な情報です。



もしタクシーの運転手さんをターゲットとしたゲームを作るとしたら
私はどういった企画をするでしょうか？

きっと、今まで聞いてきたことを念頭に企画を作るのかなと思います。

今のところそういった予定は無いのですが、企画とは様々な所から発生するもの。
そのために日々情報収集です！

おはようございます。本日の当番、プランナーのN.F.Hです。
じめじめとした気候が続いていますが、みなさんいかがお過ごしでしょうか。
社内ではすでにエアコンが稼働し、私の目の前では扇風機が全力で回って
エアコンで冷えた空気を叩きつけてきます。

・・・寒いです。

あまりの冷え冷えっぷりにＦがフリージングのＦになるくらいです。
普段は暑がりで評判（？）な私でも、この状況は厳しい。
かと言って扇風機を止めると、空気が淀んでいる気がして落ち着かない。

どうすればいいねん・・・。
あぁ・・・、あの西海岸の太陽が照りつける日差しが懐かしいぜ・・・。


そう！　
先日までアメリカ、ロサンゼルスで行われていたE3に視察へ行って来ました！
初の訪米、海外出張、海外での展示会への参加など、初めての事ばかりで終始
ドキドキが止まんない状態でした！

アクセスゲームズのみんなもE3への関心が高く、帰国後は質問攻めが続きました。

「あの新型携帯機はどうやった？」
「向こうで何食ってきたん？」
「あの新型コントローラーはどうやった？」
「ハンバーガーはおいしかった？」
「ハードが小さくなって、コントローラーが必要ないあのゲームはどうやった？」
「朝からステーキばっかり食ってきたん？」

って、食い物の話ばっかりやんけ！
たしかに、ガッツリ食べてばかりでしたが、帰国後に体重を量ると出発前よりも
減っていたのが不思議です。


ちなみにこういった物ばかり食べてました。


とろけるチーズがたまらない！



こんなに分厚いチキンサンドイッチ！



盛り過ぎハンバーガー！


もちろんハンバーガーを食べにアメリカに行ったわけではありません！
E3の視察に行ったのですが、見てきた事、感じたことなど、その全てを
書き連ねると膨大な量になりそうなので、割愛させていただきます。
E3の詳細につきましては、近日公開予定のイベントレポートでお楽しみください。

それでも、最も印象に残ったことを１つだけ挙げるなら、やはり

「これまでとは異なった操作方法と、これまでにはなかった表現方法
　を可能とするハードメーカーによる新しい発表で広がる可能性」

に集約されます。

今回のE3でハードメーカーから発表された内容はどれもチャレンジングです。
その特性を存分に発揮したゲームを作り出すのは、これもまたチャレンジングです。
すでにロンチタイトルが何作品も発表されていますので、それらと異なった
アプローチでハードの能力を引き出したゲームの企画を考えるとなると、
かなりチャレンジングです。
チャレンジングすぎて、考えただけでワクワクします。

・・・熱いです。

これまでにない新しい遊びを作り出していくという作業は、ゲーム開発者、
特にプランナーにとっては究極の楽しみとも言えます。
全国のプランナー、あるいはプランナー志望のみなさんの脳内でもきっと
ワクワクとニヤニヤがあふれてきていることでしょう。
私も全国のライバル達、いや全世界のライバル達に負けないように、
楽しいゲームを作っていこうと改めて思いました。


気持ちだけが西海岸にトリップしてしまい、高ぶってきた気持ちを切り替えるため、
窓を開けて空気を入れ換えると、湿気を含んだ風が室内になだれ込みます。

・・・暑いです。

いつの間にか、もう夏が近づいていたんですね・・・。

皆様、おはようございます。
ディレクターのSWERYです。

先日、梅雨入りしたにも関わらず殆ど雨が降りませんね。
空はどんよりしていますけど…

雨と言えば『レッド シーズ プロファイル』の制作中のことですが、制作中に大きめの節目があると必ず雨が降っていたのを思い出します。
キックオフミーティング。アクターオーディション。モーションキャプチャー。ボイスオーバー。α版打ち上げ。などなど。なぜか非常に雨が多かった。お気に入りの靴をビショビショにして、某モーションキャプチャースタジオへ通ったのを思い出します。

ゲームのシナリオ中で「なぜかいつも雨が降っている」や「雨の降る日が多い」というような設定は、こんな所から来ているのかもしれませんね。ははは。



さて、今日はタイトルどおりのお話を。

実はここ数ヶ月ですが、流行の【Twitter】をやっておりまして、ありがたいことにフォロワーの数が1000人を超えました。
皆様、本当にありがとうございます。


前回のブログ記事にも書いたとおり、『レッド シーズ プロファイル』の北米版が評価をいただいたこともあり、多くの方々と交流する機会を得ています。


しかしながら、そのうち約９５％が海外の方からのフォローになっておりまして、不詳ながら英語でつぶやく日々を送っております。
う～～む、この年齢になって英語と格闘することになろうとは…。

「日本のみんなー！もっとオラの相手してくれ－！」と元気玉のポーズで叫んでみましたが、まあ、これが今のところの僕の実力のようです。



それにしても、遠い異国の地からわざわざ応援メッセージをいただけるという経験は、何ものにも代え難く、本当に良い経験をさせていただいています。
慣れない英語、聞き慣れないスラング、時にはスペイン後やイタリア語、中国語でのコメントもいただき、そのどれもがパズルのようで非常に刺激的です。
中でも、世界中の方々とリアルタイムに接するという性質上、時差を体感することが多く、恐ろしい時代が来た物だと痛感させられます。

例えばロサンゼルスから午前１１時に、「ＳＷＥＲＹ！ランチは何にするつもり？」とコメントをいただくと、僕は翌日の午前４時にそのメッセージを受け取っている事になります。

なんか、すごくないですか？

時差ってなに？

地球ってすげー！！

（転じて）人間ってすげーー！！



フォロワーの皆様、この場を借りてお礼を申し上げます。
本当にありがとう。

これからも出来る限りの時間を見つけて、皆さんの応援に目を通させていただきます。
今後とも、よろしくお願いいたします。

そして、いつの日か、↓↓↓のような事になったら最高だなぁと思います。






『レッドシーズプロファイル』ディレクターズブログですが、公式な連載自体は終了しましたが、今後もいくつかのインタビュー記事をアップしていく予定です。※すでにいくつかのメディアへ対応しました！

お時間の有る方は、是非、こちらもお楽しみください。




最後に、親愛なるロスの友人へ。
Ｅ３へ視察出張へ行ったメンバーからちゃんと”お土産”受け取りました！！





僕の大好きなお菓子を覚えてくれててありがとう！
”ディナー”としていただきました（笑）

おしまい。

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

今年も、Ｅ３シーズン到来で、ディレクター富田他数名が『Ｅ３　２０１０』の視察の為、ロサンゼルスに行って来ました。
視察時のお話は、イベントレポートの方で、近々掲示させていただけるかと思いますので、楽しみにしていてください。

さて、いつもは、僕のゲーム開発の記憶をたどってお話していますが、今回はちょっと息抜きと言う事で、僕のプライベートのお話にお付き合いください。

タイトルでも書いていますが、太陽光発電を自宅に付けてみたのですが、実は３～４年前頃興味があり、当時、情報を集めてちょこっと研究をしてみたのですが、根っから面倒くさがりの僕なので、一度立ち消えになっていました。

ではそんな面倒くさがりがなぜ重い腰を上げたのかと言うと、常々毎月の光熱費が高いと我が家で問題になっていましたが、それよりも、自宅を建ててほぼ十年、このところいろんな設備が悲鳴を上げ出したのがきっかけでした・・・十年タイマー発動？！

会社では高額な設備等は通常、保守と言う、有料での保障やバージョンアップの為の保険のようなものに入るのですが、家庭でも幾つかの設備に関して実は保守があったりします。
ただし、それに加入できるのは、設備を取り付けて１０年間程度までの物が多く、これまで保守費でまかなえてきた数々の修理が、これからは実費でやる必要があると考えると、「そりゃ恐ろしい事になるんじゃないの！！」と・・・。

それで、いっそ各種設備をエコも兼ねて新しくしてみてはという事になり、それならと、太陽光発電の情報も改めて色々集めてみると、現在は、国や地方自治体からの補助金制度ある事や、発電時の余剰電気を売電（ばいでん）するシステムがあったりと、うちの光熱費もちょっとは安くなるかもと言った期待が膨れていきました。

また、この数年間で、太陽光パネル（いわゆる太陽電池）のスペックもほぼピークに達しているようで、あとは太陽光パネルのメーカー選びと設備業者の選定を進めて、遂に先日、全ての工事が終わりました。


あぁ、やっぱり面倒くさかった！！


・・・で、ここまでは、実は余談で、今回のお話はここからが本題。

この、太陽光発電システムですが、（全てのメーカーさんがそうなのかは分かりませんが）リビング等の室内で〝電気使用量〟〝発電量〟〝売電料〟〝買電料〟等々のデータが、その瞬間と１日単位～数年単位に切り替えて見る事が出来る、液晶モニターが付いています。
丁度、〝iPhone〟の１．５倍ぐらいの大きさの物をイメージしてください。

実際に、いろいろ触ってみてふと思ったのですが、表示方法を幾らか変更できる様になっており、役割は十分果たしているのですが、その、、、〝あそび心〟っていう部分が少ないんですよね。
前記した様に、結構なサイズの液晶が付いているので、一応、ユーザーにエンタテインメントをお届けしている僕の厳しい？目からすると、「折角こんなリッチな液晶が付いてんねんからもっと遊ぼうよ・・・〝もったいない〟」でした。

おそらく真面目な方が設計されたのではないかと思いますが、教えてくれる各種データはいい感じで集計されていますので、あとは、ＧＵＩの部分なんですが、色々出来る事、満載です。
僕らゲーム開発者に一言相談してもらえればどうなるでしょうか？

例えば、簡単なところでは、ユーザーがアバターを作れたりして、発電された電気や買っている電気等をアバターで擬人化し、それらが液晶内でプチ生活（世界）をするなかで、協力しあったり闘う等、各種電気の増減をビジュアル化するだけでも、毎日のぞく気がわいてきそうです。

その程度の遊びでも、太陽光発電を導入したユーザーの実生活と液晶内のプチ生活の〝妙にリンク〟している事が、いつしか楽しく感じる様になってきて、きっとその家庭の〝楽しい日課〟になること請け合いです。
何より、その実生活と〝妙にリンク〟している楽しさが、○○の森のように口コミやセールストークで広がれば、太陽光発電システム普及にもっと加速をつけられるのではないかと思いました。


最後に、

●太陽光発電システムの、メーカーさんへ。
⇒そんな感じで、共感を持たれましたら、いつでもアクセスゲームズに御相談下さい。

●今から家を建てようと考えている方へ。
⇒設計変更が可能でしたら、太陽光発電システム導入の可能性も考えて、日照時間の長い方角に屋根を出来るだけ大きく設計して貰いましょう！
　※いや、これマジで大事です！！

今回は、ゲームから離れているようで、ちょっとエコ推進に関してゲーム会社のノウハウが何か役立てれそうだな、と言うお話でした。

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

何度かブログでも話題に出ていますが、Ｅ３が終わりましたね。
某社のカンファレンスは、ネットで生中継を見ながら友達とメッセンジャーで会話しつつ盛り上がっていました。自分の部屋にいながらにして、世界の最新情報を手に入れることができる・・・いい世の中になったものです。

やはり新しい情報というのはいいですね。見ててテンション上がります。
ただですね・・・某社の社長が舞台を右に左に歩きながら喋っていたのですが・・・
さすが世界に情報を発信する場。
喋ってる方は日本人なのに全部英語です。

なんとなーくはわかるんですが・・・大半はわかりません。
聞いたことのある単語が聞こえたら、どんな意味やったっけ？と脳内で日本語に直して・・・とかやってる間にもう次のこと喋ってます。全く追いつきません。

プログラムも英語ですが、日本でプログラムをやってる間はそんなに難しい英語を書くことは多分ありません。（僕が経験が少ないだけですが・・・）
変数名は単語で済みますし、コメントも日本語です。

だからと言って難しい英語を避けて通れるか、と言えばそうでもありません。
書くことはあまりないでしょうけど、読むことは何度かありました。APIを使っていればコメントが英語なこともあります。

以前あったのが、途中から参画したプロジェクトで修正担当になった箇所に、あるライブラリが使われていたのですが、そのライブラリのドキュメントが全て英語で書かれていました。

最初は英語で書かれているドキュメントに少し構えていたのですが、翻訳サイトや辞書で調べて少しずつ読んていけば、意外となんとかなるもんですね。
少し時間がかかりましたが、何とか読んで修正することができました。

他にも、ゲームの情報を調べていたら海外の掲示板に辿りついて、翻訳しながら読んでいったこともあります。こっちの方がやる気がでたのはここだけの話。

皆さんも、もし英語の文章を読む機会があれば、英語で書かれているというだけで読むのをやめずに、まずは辞書を引っぱり出したり、翻訳サイトを開いて英語と向き合ってみませんか？
完全に理解するのは難しいですが、せっかく情報があるのに読まないのはもったいないですからね。

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

最近、梅雨のせいでジメジメしたイヤな感じが続いていますが、そんなジメジメも吹き飛ばすくらいに世界中の人が熱狂しているものといえば、やっぱり、サッカーワールドカップですよね。
なので、今回はそのワールドカップの話題をと思ったのですが、そっちの話題はほかの人に任せて、先日あった出来事を少し書こうかなと思います。

先日、友人を乗せて車で走っていると、前のほうでトラックが止まっていました。
日頃から割とよく通る道で信号があるのを知っていたので、赤信号で止まっているんだなと思っていたんですが、近づくにつれて人だかりができているのに気付き、その中には警察の方もいるようでした。
よく見てみると、そのトラックは信号の少し手前にある線路の高架のあたりで止まっていました。
どうやら、そのトラックは高架の高さ制限を超えているのに気付かず、その道を通ろうとしてぶつかってしまったようです。
幸い、けが人は出ていなかったようですが、トラックの荷台の上の部分がひしゃげていたり、荷物が少し散乱していたりと、ひどいありさまでした。
少し、急いでいたので脇道にそれてその場は通り過ぎましたが、一緒に乗っていた友達と、「初めて通る道だったのかな？」とか、「初めて乗ったトラックで、いつもの感覚で行けると思ったんじゃないか？」などと話していましたが、どちらにしても今の状況を把握して進まないといけないよなと思いました。

しかし、それは仕事においてもいえることではないかと思います。
例えば、なにか物事を頼まれた時でも、それを今の自分がスケジュール的にも、技術的にもこなせるものなのかということをしっかり考えておかないと、その作業をすることによってほかの作業が間に合わなくなったり、さっきの事故のように大きな失敗につながる可能性があります。
なので、今の自分の置かれている状況をしっかり把握しているというのはとても重要で、日頃から気を付けていきたいなと思いました。

あと、車はもちろん安全運転で！！

昨日、遅くに仕事を終えて家に帰ると、エアコンがついていました。

・・・朝８時くらいにつけて、今の時間までだから・・・

約　１　６　時　間　つ　け　っ　ぱ　な　し　。

・・・・・・・・・・・・。

と、とりあえず、おはようございます。本日の当番、プログラマのY.Tです。
Ｗ杯で湧き上がっている今日この頃、皆様は如何お過ごしでしょうか？

世界的なイベントとしてもう一つ、忘れてはならないのが、
現在、米ロサンゼルスで開催中のＥ３。

驚きの情報が色々と発表され、毎日ワクワクしながら新着記事を読んでいます。
好きなジャンルの新作情報なんかが飛び込んでくるともうたまりませんｗ

アクセスゲームズも毎年、数名がＥ３視察の為出張しています。
きっと今も皆目を輝かせながら新しい情報を仕入れている事でしょうｗ

さて、長期出張となると、
その間の出張者の業務を一時的に代行する人間が必要です。
そこで発生するのが「引き継ぎ作業」です。

忙しかったりすると結構さらっと流されがちなのですが、
引き継ぎ作業が不十分だと、
色々と問題が発生する可能性があります。

極端な例になりますが・・・

Ａさん　→　しばらく留守にする人
Ｂさん　→　Ａさんの代行者
Ｃさん　→　Ａさんと組んで仕事している人
とします。

----------------------------------------------------

Ａさん「このファイルは使ってないけど、一応置いておくか。」

↓

Ａさん「このファイル使ってないけど、置いておくのでよろしくね。」
Ｃさん「了解。んじゃ置いとく方向で。」

↓

Ａさん「留守にするんでＢさん代行よろしく。作業内容は・・・
　　　　・・・後、このファイル全く使ってないからローカルで作業する時は
　　　 邪魔だから先に消した方がいいよ。」
Ｂさん「了解。」

↓

Ｂさん「このファイル使ってないんだったな・・・。
　　　　混乱するし、これからの作業も考えて元のファイルも消しておくか。」

↓

Ｃさん「あれ？ファイル無くなってる・・・。
　　　　どういう事？使っていなくても置いとくんじゃないの！？」

↓

もめ事発生

----------------------------------------------------

かなり簡略化されていますが、この場合、「必要ないファイルの扱い方」というルールが、引き継ぎ説明時にＡさんが特に言及せず、Ｂさんも特に質問しなかった為、
Ａさん　→　"一応は置いておく位の物"
Ｂさん　→　"消してもいい物"
Ｃさん　→　"置いておく物"
と、それぞれ違う受け止め方をしている事が原因で起こってしまっています。

ここで我の強い方が集まってしまうと、
「そんな事は聞いていない」だの
「勝手にやる方が問題」だの
全く生産性のない責任のなすりつけ合いが始まったり・・・。

ＡＢＣが全員社内の人間なら、まだマシですが、
社外の方が絡んでしまうと、もめ事の度合いによっては信用問題に発展しかねません。やはりお客様あっての仕事ですので、それだけは避けるべきです。
たとえ小さな事だったとしても、その積み重ねが大きな事を生み出すので。

「引き継ぎ」と聞くと、どうしても話し手も聞き手も、
作業内容や流れの方を強く意識してしまいますが、
それらは、効率よくやる方法を考えて時間短縮を図れそうなら、
必ずしも言われた通りにやる必要はなく、
それより、作業を行う上でのルールを話し手がしっかり伝えて、
聞き手がちゃんと把握する事の方がはるかに大事なのではないでしょうか？

・・・等と考えている今日この頃でした。

「偉そうなこと言いやがって！お前はちゃんと出来てんのか！」
と言いたいそこのあなた。

正解。

すいません・・・ちゃんと出来る様に頑張ります・・・。

・・・でも今は今月の電気代の事で頭いっぱいです・・・。

おはようございます。
近頃またフリゲにハマりだした、プログラマーのN.Iです。

フリゲって良いですよね。
無料だから、クオリティは安定しないけど、色んなモノを遊ぶことが出来る。

だからフリゲしよーぜ！　　なんて言う気はありませんがｗ
だからフリゲ作ろーぜ！！　なんて言う気はもっとありませんが…

ちなみに"フリゲ"とは"フリーゲーム"の略です。
広く一般的に使われているので、通用するとは思いますが念の為に補足をば。

…
………

そんなもの必要ないとか言わないでー！

皆にとっては、"そんなもの"でも、世界中の誰かにはきっと必要な情報だから！！

むしろ、このブログを長くするという意味では大変貴重なものだから！！！

そんなこんなで最近、自宅ＰＣを起動する頻度が上がってます。
自宅ＰＣの稼働率が上がるってことは、その分プログラムをする時間が増えるってことなので、良いことだと思うんです。
が、ＰＣ起動すると必ず最初に、プログラム関連のフォルダを開いてしまう癖がついてるのだけは、なんとかしたいです。
指が勝手に動くんですよ。これがいわゆる職業病ってやつですかね。
でもまぁ、毎回プログラム関連のフォルダを開いてしまうことによって、プログラム組まなきゃなぁって気にさせてくれるので、これはこれで必要なのかも？
ちなみに、ここ数年自宅ＰＣを起動していなかったので、数日前に起動した時は、ひどい有様でした。
何が酷かったのかって？
それはですね、プログラムのソース見ても、何書いてあるのかさっぱりだったことですよ…

という訳で、自宅ＰＣでプログラムを組み直そうかと考えてます。
手始めに昨日、「ランダムダンジョン生成用」なんていうカオスそうなフォルダがあったので開いてみたのですが。
一万行以上あるソースファイルが一つ、ぽつんと入ってました。
しかも、なんかごちゃっとしてて、数分眺めてると頭が痛くなってきたし。
思い立った瞬間に挫折しそうなんですが…。
でもあえて、この辺から手をつけてみるべきか？
いや、むしろこういうのからやるべきなのか？？
そんなこんなで、まずはソースを分けることから始める必要がありそうです。
ガンバルゾー。オー。

昔のソースを解析することに成功したら、次回で何か書けるかもです。乞うご期待？
"次回に続く"的な内容も書けたことですし、今回はこの辺で失礼します。
サヨナラ。サヨナラ。

おはようございます。本日の当番、日頃の運動不足中、偶な運動をして筋肉痛に悩まされているプログラマのT.Yです。

さて、本日のテーマは運動について書いていこうと思います。

挨拶で運動不足感が漂ってたりしますが、
実際この手のデスクワーク主体の仕事は、驚くほど体を動かす機会は少ないです。そして、危険なのは普段別にその状態でも目立った問題が特に起こらない事です。

そんな中、自分でヤバイと思ったのが、つい先日の事。。。

何気なしに電気街へ徘徊しに出かけたときに、A3対応のプリンタが特価で売られていたのを思わず2台衝動買いして、2箱をそれぞれ両手に抱えて家まで持って帰ったのですが、その後。。。

いつも通りにPCをつけて、キーボードで入力しようとしたときに。。

「Aが押せな・・・い」

なんと、この持って帰った時の筋力の消耗で小指がいうことをきかなくなってしまったのです。。
最後にこんな事したときには、そんなことになったことが無かったので、これは心底ビビリました。

ちなみに、その後3日間ほど、肩から手首まで筋肉痛にも悩まされました。

確かに思い返してみると最近、左シフトを酷使すると、左手の小指が若干痛くなりやすかったり、
どことなく若干風邪っぽいような感じが長続きしたりというのはあったけど、、、まさかここまでひ弱になっていたとは。。。

これは油断するとどんどんひ弱になると思い、
以下の簡単なトレーニングを始めました。

・家のベッドの手すり（2段ベッドの上の段）を使って懸垂10回を2セット
・腕立て伏せ10回を2セット
・ハンドグリップ（あのニギニギする奴ですね）を10回ニギニギ
・両手の小指ををそれぞれ引っかけて互いに
  引っ張った状態にして小指を曲げるを10回

これを行ったところなんと、プログラム書いてる時のキーボードの感触が軽くなったんですよ。
マウスのクリックも。
あと、どことなく体も軽くなったような。

運動をするということは体を動かすということ、
体を動かすということは代謝が活発になる。
代謝が活発になることは健康への第一歩。

もう良いことづくしですね。

とはいっても、まだ始めて3日なので、きっとプラシーボって奴ですね。
とりあえず、目標は次回ブログまで続いていれば勝ち組ということで。。。
がんばります。

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

開発が進んでくると、
キャラやエフェクトやイベントの追加が楽になりますよね。

既に同じような挙動がある場合、
プログラムを使いまわすことができるからです。

「これとこれを追加してこの一行書けばＯＫ！」とかね。

で、逆にそれに慣れてくると、自分の記憶を頼りに作ってしまい、
あれ？なんで動かないんだ？となることがちょくちょくあります。

単にフローが一つ抜けているだけなんですが・・・。

こういうヒューマンエラーを防ぐため、
「追加フロー」を明確化してメモっておき、
次に作成する時、フローを順に追って作成していきます。

ちょっと面倒かもしれませんが、
そうしておくとフロー抜けから起きるエラーはなくなります。

またエラーが起きた場合はフローを確認し、
問題のある箇所を修正していけば、フローは厳格化していきます。

また、自分の作業がスケジュール的に追いつかなくなった場合、
そのフローを公開して誰でもある程度の部分までは作れるようにもできます。

「キャラを作成する際のフロー」とか大仰なものでなくても構いません。

「プログラムに分岐を追加するときのフロー」とか、
「テンプレートを編集して追加するフロー」とか、
ちょっとややこしいけどフローを追えば簡単という部類のものを、
個人的にフローのメモとして置いておくと、後々役に立つことが多いです。

後の楽のために先にちょっとだけ頑張りましょう。

自動化すんのが一番とかヤボったいことはなしね！

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

突然ですが、皆さんは自分の書いたプログラムの無駄な部分を探したことはあるでしょうか？

無駄な部分？そんなとこねーよ！！という人もいるかもしれませんが
一度探してみてください、必ずあります。

無駄な部分とは、

・同じ処理を何度も書いている箇所
・現状のプロジェクトでは使用しないコード
・テスト的に書いたコード

大体はこんな感じでしょうか？？

何でこんなことを聞くかというと、先日自分の書いたコードを縮小していた時にふと思い出した、、だけなんですけどね。

、、、決してブログのネタがなかったからではないですよ！！

まあ、それは置いておいて、

私の場合、特に多かったのは、コードを書いたけど仕様変更されたため使わなくなっていたケースです。
もちろん削除するのをさぼっていたわけではなく、
後々何かで必要になった時に使用できるように残しておいたのです。

ですが、プログラムサイズがメモリが大きくなりすぎて縮小対象になってしまいました。そりゃそうですよね、実際には使ってないんだもん。

悲しいですが、削らざるを得ませんでした。

メモリの調整と聞くと、モデルやテクスチャのようなデータ側での作業のように聞こえますが、プログラムサイズも少なからずメモリを占有しているのです。
開発ハードにもよりますが、場合によってはそのサイズが大きすぎてメモリ限度を超えてしまう場合もあったりします。

皆さんもコードを書くときは、サイズも気にして組みましょうね！！！

え？そんなのお前だけだ？？
すいません、、反省します。

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

前回のブログでアークタンジェントのお話をしましたが、
その話の最後の方で【 atan2 を自作する】のも方法の１つだと紹介しました。

今回はその自作の方法をどうしたらいいのか、
そもそも自作したその関数は本当に軽くなるのかなど、
いくつか例を挙げながら紹介をしていこうと思います。

まずは前回の復習から

アークタンジェント関数とは座標を渡すと角度が取得できる関数で
例えばオブジェクトをプレイヤーの方向に向かせたい時などに使います。

オブジェクトの座標を （ ox , oy ）
プレイヤーの座標を　 （ px , py ） としたとき

そこまでのベクトルは以下のようになります。
vx = px - ox
vy = py - oy
このベクトル （ vx , vy ） をアークタンジェント関数に入れるとそこへの角度が取得できます。
そして、キャラクターの向きをその角度に回転させることで目的の方向を向くことになります。
　

　
　
では、いよいよ自作してみましょう。
（今回自作する関数は、ある程度その方向を向けばいいキャラクターに使うものです）

自作と言いましても、そんなすごい計算をするというわけではありません。
内容としては座標を渡したら角度を返すだけの関数ですので、
前もってデータを作っておき、その中から条件に合う値を返す感じで考えてみます。

というわけでまずは以下のようなデータを用意します。

　 |y|/|x|　角度（°）
　 0.00000　　0
　 0.01746　　1
　 0.03492　　2
　 0.05241　　3
　 0.06993　　4
　 0.08749　　5
　　：
　 1.00000　 45
　　：
　19.08113　 87
　28.63626　 88
　57.28996　 89

で、この関数に渡された x y の絶対値の比を上のデータから順番に見ていって
その数を超えたところの角度を返します。
例えば
x = 100
y = 6
の時は、その比が 0.06 になりますので取得できる角度は 3°になります。

この後 x y のそれぞれの符号を見ることで実際の角度に変更します。
x プラス　・y プラス　：そのまま
x プラス　・y マイナス：取得した角度をマイナスにする
x マイナス・y プラス　：180°から取得した角度を引く
x マイナス・y マイナス：180°から取得した角度を引いたものをマイナスにする

ここで注意しないといけないことがいくつかあります。

ひとつは、渡した x の値が 0 の時の場合です。
比を出すために割ろうとするとゼロ徐算になってしまいプログラムが動きません。
この関数の頭で x が 0 の時のチェックをを忘れないようにしましょう。

そしてもうひとつは、比の値が 57.29004 を超えた場合です。
この場合はこれ以上比べる数値がありませんので返す角度は 90°になります。

以上で一応角度の取得はできるようになりました。
しかし、このままでは atan2f と処理負荷はあまり変わりません。
というか、むしろこっちの方が処理負荷がかかってしまう場合もあります。
　
　
というわけでここからが処理軽減の本題になります。
上で紹介した関数にさらに手を加えていきましょう。
やり方はいろいろあるとは思いますが、今回は簡単にできそうな方法をいくつか紹介します。
　
　
処理軽減の方法その１：データ量を減らす

上の例では、角度 0°から 90°の間で 1°ごとに取得するデータを使っています。
ゲームの仕様にもよりますが、もう少し大雑把な角度の取得でいいのであれば
この取得する角度を 2°や 3°ごとにすることで調べるデータ量を半分以下にできます。
当然ながら処理速度もそれだけ減らすことができます。
　
　
処理軽減の方法その２：渡した値が真ん中より大きいか小さいかでデータの参照場所を変える

これは、方法その１が使えない時や、データ量を減らしたとしてもまだデータが大きな場合に使えます。
例えば上で使っているデータでいうと、比：1.00000 角度：45°の場所がちょうど真ん中になります。
ですので x y の絶対値の比が 1.00000 より大きいか小さいかでデータを見ていく場所を変えていきます。

まずは、関数の一番上で、比の値を調べます。
そして、例えば 1.00000 より小さかったら最初から真ん中まで調べればいいですし、
1.00000 より大きかったら真ん中から最後まで調べていけば必要な値が取得できます。
これだけで、元々の関数からは半分の処理で済むようになります。

あとはこの方法の１・２をうまく組み合わせることでさらなる処理軽減も可能になってきます。
　
　
今回は座標から角度を求めるためのデータを例としてあげましたが
それ以外にも大きなデータから必要な値を取得する場面はいろいろとあると思います。

みなさんも、関数が１つできたからとそこで安心することなく、
その関数をさらに軽くすることができないか考えてみてはどうでしょうか？
オブジェクトを１個多く出せたりエフェクトを少しだけ豪華にできるかも知れませんよ。

おはようございます。タイトルにあるとおり小休止は重要だなと最近特に感じている、本日の当番、プログラマーのM．Oです。

コンパイル中や、ちょっとしたロード時間、原因究明が進まない時、いいアイデアが思い浮かばない時、このような時には、コーヒーを飲んだり、ゲーム雑誌を読んだり、ぼけーっとしたりしています。

やっていることを並べて書くとサボっているように感じられますが、
これらの行動が重要だったりするのです。

なんで重要なのかって言うと、落ち付きを取り戻したり、頭の中を整理したりと一旦リセットできるからです。

私の場合、忙しい時ほどPCの前にかじりつき、必死に考えてキーボードを打ちます。
この時、頭の中で考えがまとまっていれば問題ないのですが、まとまっていないことがあります。
そのことに自分自身気づいておらず、「これで解決する。」と思い込んでいることもあります。
やることなすこと的外れのことだったり、悪い時にはバグを仕込んでしまったりと。
こういう時に打ち込んだプログラムを落ち着いてから見返すと大体ひどいことになっています。
皆さんも、切羽詰まった時には、このような状態になることが多少なりともあると思います。

その様な時に、一度頭の中をリセットすることで別の視点から問題について考えることができます。
私の場合は、お手洗いに行ったらいいアイデアを思いつきますが、
人によっては起床時に思いついたりと、全然関係ない時に思いつくってやつです。

私は、余裕がない時ほど早く終わらせようとして、小休止を取るのが難しいと感じますが、「休憩してこいや！」と、助言をくれた先輩のおかげで今は意識できています。

ですので、ゲーム雑誌を見て、にやにやしていてもサボっているわけではないのですよー。

おはようございます。本日の当番、ゴルファー兼プログラマのJ.Kです。
次回コース予定が決まっていない上、右肩が四十肩気味でモチベーションダウン中です。

さて、本日のお題は「連動」です。
　
　
「連動」というと、何をイメージするでしょうか？
　
　
例えば、歩く時は、右足、左足、そして右足、というように左右の足が連動しているから上手に歩くことができます。
また、同時に、左腕、右腕、そして左腕、というように左右の腕も連動しています。

上手くバランスが取れています。
しかもそれが自然にできているということが、素晴らしいです。

で、これらはゴルフでも同様です。

ゴルフでは、右膝の捻転が右足の付け根に伝わり、それが右腰に伝わり、
それが上半身に伝わり、それが肩、腕へと伝わり、パワーが蓄えられていきます。

イメージとしては、ゴムでできた棒を捻っている感じでしょうか。
その場合、ゴムはどの部分を見ても、均等に捻れているはずです。
ゴムの場合、自然に均等に捻れますが、人間の体ではそう簡単にはいきません。

まず、ここまでの「連動」を体に覚えさせることが必要です。

ここで、捻った状態のゴムから手を放すとどうなるでしょうか？
そうです、一気に元の状態に戻ろうとします。

この状態を作ることができれば、持っているパワーの最大値を引き出すことができます。
「連動」することで、スムーズに力を出すことができるわけです。

ただ、残念なことに、この動きは、練習しなければ習得することができません。
そうです。
自然にはできないのです。

歩く、という行為のように、ほぼ毎日、日常的に行われている行為であれば、ある意味でそれ自体が練習になっているようなものですが、日常的に行わない行為は、そうそう身につくことはありません。

なので、ゴルフもブランクがあると下手になるのですよ…
　
　
では、開発業務ではどうでしょうか？
　
　
前述したような、体を使う作業はありませんが、ちゃんと「連動」は存在します。

例えば、上司がちゃんと部下を管理して効率良く作業が進む、これも「連動」です。
プランナーが作成した仕様を、チーム全員が正しく把握する、これも「連動」です。
デザイナーが作成したデータをプログラマが画面に表示する、これも「連動」です。

これらの「連動」が自然に機能すれば、開発における最大パワーが発揮されるでしょう。

ただ、開発では、どこかの職種の作業が滞ってしまい、他の職種にまで影響が出ることが多々あります。

そう。
作業の遅延も、ある意味「連動」してしまうわけです。

人間ですから、どこかでミスをすることはあります。
しかし、チーム一丸となり「連動」すれば、ミスの「連動」を断ち切ることも可能です。

ミスの「連動」を減らすべく、日常的に意思の疎通という行為を身につけることも大事だということですね。
そして、それが自然にできるようになれば、素晴らしいことです。

（ミス以外の）「連動」って大事だね。

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

６月に入り、Ｗ杯開催まであとわずかですね！
うーん、ちょっと前に近所の長居スタジアムで
Ｗ杯の試合があって賑わってたなぁと思っていたのですが…。
え、それってもう８年前になるんですか！？

…とまぁこのように光陰矢のごとしとはよく言ったもので、
月日の経つのはホントに早いです。
無駄に過ごすことは避けなければなりません。

というわけで、今回は時間のお話です。

開発が進行していくと、
ソースコードの量も増えてくるので
コンパイルにかかる時間も日増しに長くなります。

高性能なＰＣを使用している場合でも、
フルコンパイルとなると、そこそこ時間がかかってしまいます。

重要なのはそういった「待ち時間」をどう過ごすか？
何もしないで待っているだけでは、時間がもったいない！
某ネコ型ロボットがいれば、
時間を止めたり、未来や過去に行き来するのも自由自在ですが、
現実はそういうわけにもいきません。

僕はそういった時間があれば、
主にソースコードの見直しをしています。
ソースコードは一度書いたら終わりではなく、
いったん時間をおいてから、見直してみることが大事です。

以前、自分がどういった内容を書いていたかを再認識できますし、
関数などを整理することでプログラムの保守性が高まります。

プログラムに限らず、いろいろ作業していると
どうしても待ち時間、空き時間が発生する場合があります。
そういった時間を無駄にしないようにすることが大切ですね。

僕はプログラマですので、ソースの見直しを例にあげましたが、
仕事の効率アップにつながるのであれば
時間の使い道はなんでも良いと思います。

椅子から立ち上がって、
軽くストレッチをするのもいいかもしれませんね。
息抜きや気分転換に雑誌を読んだり、
仕事の邪魔にならない程度に軽く雑談をするのもいいかもしれません。

少しの時間でも無駄にせず、大事に使える人は、
仕事も出来る人だと思います。
僕ももっと時間をうまく使える人になれるように頑張ります！

ほんの数週間まえからようやく暖かくなってきた、と思ったのもつかの間、急に汗ばむほどの暑さになってきた今日この頃、皆様、いかがお過ごしでしょうか？

最近Ｗｅｂで青い鳥は身近な鳥かごにいるとの情報を得て鳥かごを置く場所を作るために部屋の掃除をする道具を求めてネットの海で釣られないように疑心暗鬼になりながら青い鳥なんて実はいないんじゃね～のと呟くのに忙しいM.L.Kです。プログラマです。
あ、おはようございます。本日の当番です。ＬはLuckのLです（Luck&Lack!!）。

さて、前回は減色の奥深さの迷宮に踏み込んでしまいましたが、小手先だけの問題解決の様相となっていたのを改めて、少し初心に還ろうと思います。

メディアンカット法とは、色の分布を中央値で分割していき、目的の分割数となるまで、これを繰り返す、というものです。かなり大雑把な説明ですが。

色の分布、というのを聞いて、たいていのヒトは次のようなものを思いつくと思います。

INT anFrec[256][256][256];

画像中にある色

が１ピクセルあれば、

anFrec[R0][G0][B0]++;

として、24bits色（すなわち、1677万色）のうちのどのいろがどれだけ出現したかを数え上げようという魂胆なワケですね。

ちなみに、上の配列は、256×256×256×4bytes＝64Mbytesとなります。
ひと昔前なら「Ｍ？ないやろ～！」とか言っていたんですが、昨今のメモリ容量の増大化の風潮では、思うべくところもありません。いや？穢された？ワタシ？若干？

昔話はさておき、後はこのanFrecの中のデータをもとに、グループ分けを行います。
とりあえず、各チャンネルの最大値と最小値を求めましょう。
と、思いきや、これはちょっと面倒。

Ｒチャンネルの最小値を求める場合、anFrec[0][0][0]から初めて、anFrec[0][0][1]、anFrec[0][0][2]と、どこに１以上の値が入っているかをチェックして、初めて１以上の値が入っていたところが、Ｒチャンネルの最小値となります。

コードで書くとこんなカンジ？

for( int i = 0; i < 256; i++ )
{
　　for( int j = 0; j < 256; j++ )
　　{
　　　　for( int k = 0; k < 256; k++ )
　　　　{
　　　　　　if( anFrec[i][j][k] > 0 )
　　　　　　{
　　　　　　　　min = i;　//minは最小値の格納変数
　　　　　　　　i = 256;
　　　　　　　　j = 256;
　　　　　　　　break;
　　　　　　}
　　　　}
　　}
}

最大値の場合は、これを255から始めて、0までデクリメントしていくカンジでしょうか？しかも、Ｇチャンネル、Ｂチャンネルについてこれを繰り返すワケです。
う～ん、ループし過ぎ！

で、次は中央値（メディアン）を求めるワケなのですが、仮に、画像中のピクセル数をnとします。とすると、中央値の基準はn/2ですね。
あと、各チャンネルの最小値、最大値をRmin、Rmax、Gmin、Gmax、Bmin、Bmaxとします。

Ｒチャンネルの中央値を求めるコードを書くとこんなカンジ？

int count = 0;

for( int i = Rmin; i <= Rmax; i++ )
{
　　for( int j = Gmin; j <= Gmax; j++ )
　　{
　　　　for( int k = Bmin; k <= Bmax; k++ )
　　　　{
　　　　　　count += anFrec[i][j][k];
　　　　　　if( count >= n/2 )
　　　　　　{
　　　　　　　　median = i;　//minは最小値の格納変数
　　　　　　　　i = 256;
　　　　　　　　j = 256;
　　　　　　　　break;
　　　　　　}
　　　　}
　　}
}

うあっ！またループだよっ！

まあ、気を取り直して、メディアンカットのココロ、グループ分けに入ります。
グループのデータとして保持しなければならないのは、各チャンネルの最小値、最大値、それに中央値です。

struct GROUP
{
　　INT anMin[3];
　　INT anMax[3];
　　INT anMedian[3];
};

とでもいたしましょうか、ここに先ほど求めた各値を入れると、ジャーン！メディアンカット１色減色のグループ分けが完了です！

あ、ぶたないでっ。Ｍとかないんでっ。

真面目な話、このグループを２つに分ける方法さえ揃えば、後はその繰り返しです。
…繰り返し…？ゴクリ…。

例えば、GROUPがm個あったとして、

INT differenceMax = 0;
INT idxDivide;
INT chDivide;

for( int i = 0; i < m; i++)
{
　　for( int j = 0; j < 3; j++ )
　　{
　　　　INT difference = group[i].anMax[j] - group[i].anMin[j];
　　　　if( difference > differenceMax )
　　　　{
　　　　　　idxDivide = i;
　　　　　　chDivide = j;
　　　　　　differenceMax = difference;
　　　　}
　　}
}

新しいグループをgroup[m+1]、分割される元のグループをgroup[idxDivide]とすると、先ほど最も差が大きかったチャンネルについては、とりあえず、

group[m+1] = group[idxDivide];

として、

group[m+1].anMin[chDivide] = group[idxDivide].anMedian[chDivide];
group[idxDivide].anMax[chDivide] = group[idxDivide].anMedian[chDivide]-1;

と、新たに分割されたグループとして書き換えを行い、最初に出てきた最小値を求めるループの０と２５６が書かれているトコロを、各々のanMin[]とanMax[]を各チャンネルで対応してやれば、それぞれの最小値が求まります。
同様に、最大値、中央値も求められる、といった具合です。

“後はその繰り返し”と言ったのは、このグループの分割とそれぞれの値を求めることを、目的の色数になるまで繰り返して行う、ということを指しています。

これだけループを繰り返しているワケですから、当然のことながら、処理には時間がかかります。救いと言えば、このやり方なら、元画像のピクセル数が膨大な数になったとしても、最初のanFrec[][][]のデータを作成する時に処理が増えますが、以後の処理量は変わりません。まあ、それを差し引いても、余りあるくらいに遅くはあるのですが。

こうやって振り返ってみると、やり方によって処理の時間が大幅に減せる（例えば、以前に紹介した２００行程度の実装のように）ということに、改めて思い至ります。

前回のブログで、「むちゃくちゃ遅い」といっていた実装も、ひょっとするともっと速くするやり方があるかもしれません。…少し希望が湧いてきました。

ま、家の中を探したら実は鳥かごがあった、程度の希望なんですけどね。

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

意外にも粘りに粘る「プログラマー的デザイン表現」７回目です。
今回は予告通り、パーティクルシステムを取り上げます。
あまり斬新なことはしませんが、お付き合い頂ければと思います。

さて、そもそもパーティクルシステムとは？
簡単に説明すると、煙や炎、魔法等といった表現をパーティクル（粒子）の
集合体で制御するシステムのことを指します。

小難しい説明はここまでとして、とりあえずは以下をご覧下さい。

＜↓クリックすると拡大出来ます＞

 


煙を表現したパーティクルです。
各パーティクルの回転や移動、重力等に不規則性を持たせ、アニメーションも
個別に制御しています。そうすることで、より自然に映るよう演出します。
というか、この辺はセオリー通りです。

さて、ここからがプログラマーならではの話題です。
先程の画像、ちょっと気になる箇所があります。赤マル印で囲った部分、
パーティクルが地形に刺さっています。ちょっと昔のタイトルによく見られる
交差現象ですが、近年ではほとんど改善されています。

具体的には、地形との深度値に応じてアルファ値を変化させ、上手く溶け込ませる
「ソフトパーティクル」という技術を使っているからです。
ピクセル単位での比較が必要なので、シェーダによる処理が必須です。

ということで、これを実装した結果が以下になります。

＜↓クリックすると拡大出来ます＞

 


先程見られた交差現象は軽減されています。より自然な感じになったのではないでしょうか。

但し、それなりに処理負荷も掛かるので、トレードオフの為、１／４の解像度に
レンダリングしたものを合成しています。
当然、品質は劣化しますが、パーティクル自体が元々ボヤけているので、

多少解像度を落としてもそれほど影響はありません。

さて、次に気になるのが、パーティクルの「のっぺり感」です。光源計算を全くやっていないので、当然と言えば当然です。

テクスチャ自体に陰影を描いておけば良いのかもしれませんが、
それでは芸が無いのでシェーダによる光源計算を行います。

どうやって計算するのかといいますと、まずパーティクルの表示方向から
法線を算出し、更にテクスチャに法線マップを持たせることで、

ピクセル単位での光源計算を行います。
パーティクルの表示方法がビルボードなので、物理的に正確な計算方法とは成り得ませんが、それなりの効果は出るはずです。

以下、光源計算を追加した結果です。

＜↓クリックすると拡大出来ます＞

 


先程と比べて、結構ボリューム感が出たかと思います。

この画像では判りませんが、裏側に回れば煙は暗く表示されます。
フェイクにしては効果は結構高いですね。
ちなみに、炎等のような自己発光物には使えません。当たり前ですが、念の為。

今回はここまで。というか、ネタ切れです（汗）

今までの例と同じく、今となっては珍しくとも何ともない技術ですが、
自己学習も兼ねて紹介してみました。

縮小レンダリングはフィルレートの改善にも貢献しています。
大量のパーティクルを出すには必須ですね。

さて次回ですが、ここまで学習してきた内容を織り交ぜて色々やってみたいと思います。
どんな形になるのか、自分でも皆目見当がつきませんが、お楽しみに！？

ではでは。

おはようございます。本日の当番、CGデザイナーのM.Hです。
前回の当番、E.Fと同様、私も今年で二年目になります。
この一年の経験を糧に、気持ち新たに頑張りたいと思います。

最近、週末によく自転車に乗っています。
元々バイクなど乗り物が好きで、ロードバイクというものに乗ってみたかったのと、
運動不足解消にもなり丁度良いという点から、先月購入しました。

これがなかなか、ママチャリなどとは違う圧倒的な軽さと、
回せば回すだけダイレクトに力が伝わるその機動力は、想像以上に楽しく、
近所を走り回るだけでは満足できなくなり、もっと良い道は無いものかと
インターネットで調べるようになるのはそう時間はかかりませんでした（笑

地図をにらめっこした結果。
北大阪を横断する一級河川、淀川。そこの河川敷が地図を見る限り、
自分の住むエリアから十三梅田周辺まで、
まっすぐ、平坦、車の通りがない、の三拍子揃った素晴らしい道のようでした。


ならば自転車で梅田まで行こう！ということで
早速休日には家から一番近い河川敷の入口へ。
そこにはひょろりと伸びた、一本の道が。

 

反対側の河川敷にはゴルフ場が見えます。

早速中に入り、道を突き進む私。



道はあれよあれよと言う間に広くなり、、、ウム、実にスバラシイ。
とても走りやすいです。
しかし、快適と思えた道に思わぬ罠、、、、



なんとそこには、車やバイクが通り抜け出来ないよう設置された柵が！
たしかに自転車が通れるようにはなっていますが、
一度自転車を降りないと渡るのは難しい模様。
保安の為ならば仕方があるまいとしぶしぶ通りぬける私。
しかし、気を取り直し再び自転車にまたがった私が見たものは、
目と鼻の先にある別の種類の柵！
なんということでしょう、地図の上からは快適に思えたサイクリングロードは、
実際に走ってみると、様々な障害物が待ち構えているのでした。

形状、配置が色々な柵たち。
ゴルフ場周辺や河川敷への出入り口などは重点的に柵でかためられているようです。



荒れてくる道。



！？

実際走ってみないと分からなかった数々の障害。
目的地まで、地図を見るだけではこれ以上無いほど快適に見えた道ですが、
それは大きな認識違いでした。



ちょっと一休み。




そんなこんなで一時間半近く走ったでしょうか。街並みはどんどん都会的になり、
そしてついに、見覚えのある建物が！

   

障害を乗り越え、とうとう梅田周辺へとたどり着きました。
思えばこの道のりは、仕事でも同じ事があるなあと思ったりしました。
スケジュールだけを見てみればスムーズに行けると思っていたその作業が、
ふたを開けてみると様々なクリアしなければならない課題があるかのように。
しかしながら、それを乗り越えた時、
ゴールへ到達したときの達成感は、やはり素晴らしいものがあるなあと、
そんなことを考えながらぼーっとし、そして帰路へと付くM.Hでした。

おはようございます。本日の当番、CGデザイナーのE.Fです。
入社して2年目になります。2年目1発目のブログです。
2010年も半分に差し掛かって参りました。
本当に1年って早いものですね。

最近、クレーンゲームで遊ぶ事がありました。
ゲームセンターによく置かれている、アレです。
何故か…？理由はありません。ただ久しぶりに遊んでみたかったからです。

クレーンゲームと言えば、
２つ、もしくは３つの歯で何か景品をつかみ上げ穴まで運ぶ…
そんなゲームだったと思います。

…だった。

…と…思います。

最近のクレーンゲームって…何ですか？

歯が一つしか無いって何？
転がすって何？？
紙に穴を開けるってナニ？？？

同じクレーンゲームなのにここまで遊び方を考える人…すごいです。

それだけではなく

景品をちょっと歯が触れるくらいで落ちそうな所に置き、
如何にも簡単に取れますよ～と言わんばかりに観せたり、
でも、ちょっと歯が触れただけで持ち上げる動作に切り替わるように
してあるもんね～って設定されていたり。

この様に観せるスタッフさんの配置する技術と、機械の技術も…すごいです。


…あれ？
実はクレーンゲームってテレビでやるゲームとかに似てる？

色々な遊び方を考える…プランナーさん？
取れるように観せる…デザイナーさん？
歯が触れた時の判定を行ったりするシステムを組む…プログラマーさん？

…さすがに少し無理やりすぎますかね。


でも何でしょう。
遊んだ後の「やりました感」は、景品が取れても取れなくても、
テレビでやるゲームで遊んだ後に感じる気持ちと変わらない気がしました。

やっぱりゲームなのですね。

景品が取れない時の悔しさと、もう一度チャレンジしたいという気持ちとか…
テレビでやるゲームが、クリアーできない時と同じだと思いました。
景品を取ることができた時の快感と達成感は、テレビでやるゲームがクリアーできた時、
そして景品が手に入った時の満足感、これはやっぱりクレーンゲームだけでしか
味わえない醍醐味だと私個人は思っております。
ただ、景品を取るだけの数秒で終わるゲームでも、ここまで色々な気持ちを
与えてくれるクレーンゲーム…奥深いです。

私もデザイナーとして、観せる所から色々な気持ちを与えられるような
デザインを行っていけたら…と思っております。

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

さて、人間やらなければならない時があります。
はい、いきなり重たい！！

やらなきゃいけないのに、できない。
そういう時ってありますよね？
そんな時どうすんだ？私はこうする！
今日はそんなお話。

プロジェクト終盤に近付くと、忙しさは加速度的に増加していき
忙しさに比例するように、疲れも増加していきます。
日々の疲労がたまっていくと
どうしても、ほげぇ～ってなってしまったり
時にはDream　Worldに旅立ってしまう時もあります。

そんな時、エイサー！と気持ちを入れ替えて集中するためには・・・。


なにかしら切り替えのスイッチのようなものを用意しておくと良いです。


スイッチ！！
人によって集中力の上げ方は色々ありますよね。
体をくねくねとさせて体操してみたり
テンションの上がる音楽を聞いたり
とりあえず5分ほど瞑想（睡眠）してみたり

私の場合は、

“自らの眼球を潰す。”

これ！


ってあかんあかん！
某柱の男じゃあるまいし。
覚悟の度合いが半端なさすぎです。



気を取り直して・・
私の場合は、

とりあえずコーヒーを飲む。
これ！

ふ・・普通ですか・・・そうですか・・・。
そうですよね・・・。

すいません。
眼鏡潰してきます。


潰してきました。
た・・ただ、普通に缶コーヒーを飲んでるわけじゃないんだからっ！！

自家製の集中力アップブレンド砂糖と称した特別ブレンド！
コーヒー粉を大量に入れて激甘、激苦のコーヒーを一気に飲みます。
そうしたら眠気と疲れが一定時間飛ぶんですよ、これが。。

いや、ほんとです。ほんとですよ。ええ。

これ、飲んだ日と飲まない日の集中力が違います。
もはや条件反射的な何かかもしれませんが・・・・。

今日？もちろん飲んでます。
ていうか、毎日飲んでます。

ただ、あまりやりすぎると慣れてしまって
ブースト率が落ちてしまうかもしれないので注意です。

さて、今日もコーヒー飲んで頑張ろうと思います。
みなさんも、集中できない時は
気持ちを切り替えるスイッチを考えてみてはどうでしょう？

オススメは

“自らの眼球を潰す。”

これ！

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


タイトルにもあるように「まさかの出会い」がありましたので
その時の話を少し・・・・。


先日、友達の舞台を見るために、遠路はるばる東京まで足を運ぶ機会があったん
です。
慣れない土地で、あーでもない！こーでもない！と、地図と睨めっこしながらも
なんとか到着し、友達との再会を喜び合いながら、舞台も無事に鑑賞し終わり
さあ、大阪に戻ろうと、帰りの電車に揺られていた・・・・

その時！

出会っちゃたんですよ。


遠くの方で一際目立つ建造物、東京スカイツリーに！


建設していることは知っていたんですが、予想してなかったまさかの
出会いにビックリ！

この瞬間、デザイナーの本能が動いたのか「これは拝見せなあかんね」と
結構掛かっている電車賃を気にせず、途中下車し、慣れない土地で
「道、わからへん」とつぶやきながらも、「たぶんこっちだろう」的な
野生のカンを頼りになんとか到着。





でけー！


建設途中だったんですが、下から眺めた迫力は、凄いの一言！
このスカイツリー、日本伝統の建築技術「そり」と「むくり」を意識してデザイン
されているそうで、眺める位置を変えるとタワーが、反っていたり、膨らんでいたり
するんです。
ほかにも、一見丸い形のように見えるんですが、じつはタワーの足元から頂上にかけ
て、造形が三角形から円形に変化しており、下から見る角度によって
さまざまな表情を出してくれるんです。





ちょっと捻っている。


日本建築と最新の技術を、融合させてデザインされているそうなので
デザイナーとしては、一目見るだけでもかなり価値はあると思います。

時間の都合で夜景は見れなかったんですけど
夜も美しくライトアップされるんでしょうね。



とまあ、短い時間でしたが、良いものを見ることができました。

見る角度によってさまざまな表情を出して、飽きさせないようにデザインしていたり
昔の技術を生かしつつ、最新の技術を取り入れて、色褪せないデザインをするなど
改めて、とても大切だと思い知らされましたね。

ゲーム開発でも、実際にプレイされる方のことを考えながら開発していくので
今回のことを改めて意識して、新しい表現や日本独自の表現を模索しながら
開発に活かしていきたいものです。