スタッフBLOG

冬の厳しい寒さが続く毎日、皆様如何お過ごしでしょうか？
私は晴れの日に新しく購入したライディングブーツを履き込み、ウキウキしながらバイクで走り回っています。

おはようございます。本日の当番、バイク走行時間15分でお腹が冷えてトイレに駆け込むプランナーのS.101です。


今日は「目的」についてのお話。

ゲーム開発に関わる人の大半は「作ることが好き」なので、新しいスキルだったり、ワークフローだったり、ツールやプラグインだったりに興味津々です。
あんな事ができるな～こんな事もできそうだぞと思い巡らせます。
そういう好奇心だったり探求心だったりはゲーム開発者として非常に大切な事だと思います。

ただ、その思いのまま開発に取りかかることはあまりお勧めしません。

何故かというと、作るための手段に注目しすぎて、「どういうものを作らなければならないのか？」というところがぼんやりしちゃう事があります。
そうすると完成時に当初の想定からずれてしまってたり、さらに大人数の開発になればなるほど散らかったものができてしまう危険性があります。

私が伝えたいこととしまして、実際に手を動かして何かを作ったり計画を立てる前に「目的」という関わる人が全員目指すべきものをしっかりと定めておく必要があると言うことです。

この目的をしっかり固めて揺るがないものとすれば、それを目指すための手段はいくつもあります。
その時々、人それぞれで様々な手段をとられるかも知れないけど、結果として完成するものは目的に合致したものができます。

ゲーム開発には様々な職種、思想、スキル、経験を持つ人が大勢関わってきます。
その全員が共通で認識する「目的」は非常に大切なものなのです。

特にプランナーの方、並びに目指す方は「目的」を意識して話しに盛り込んだり書類の最初に定義することをお勧めしますよ。
きっと今までよりスムーズに物事が進むはずです。
もちろんプランナー以外の方も色んな場面で役に立つと思います。

It's so cool! You should check it out. ;-]

おはようございます。
好きな食べ物は春雨…本日の当番、プランナーのK.Mです。

前回のブログでは、文章はシンプル・イズ・ベスト…
皆さんも短文を心がけてみませんか？という記事を書きました。

前回ブログ
http://www.accessgames-blog.com/blog/2016/09/post-c478.html

前回記事の総文字数は「585」。
今回記事では短文自己記録を更新してやろうと意気込んでいます。

そう言えばTwitterは少し前まで140文字制限でしたね。
読み応えや満足感を与える文章を書こうと思うとかなり厳しい文字制約です。

しかし、それも序の口。
世の中にはさらに厳しい制限で大きな満足感を与えたい！
…という趣旨の文章があります。
なんと17文字制限。

はい、そうです。俳句や川柳ですね。

たった17文字で俳句は季節の情景を鮮やかに描き出し、川柳はユーモア混じりのインパクトを与えてくれます。
ちなみに社内恒例行事「秋の芸術イベント」では、三部門の内のひとつが川柳です。

この川柳。
良いゲーム企画書を書くための訓練としてオススメです。
企画書で何と言っても重要なのは独創的なアイデアですよね。
次に重要なのは何か？
そのアイデアをいかにインパクトを与える形で伝えられるか？
これ、とても重要です。

くどくど説明するのではなく、研ぎ澄ました言葉でアイデアの本質を言い当てる。
できれば少しの謎を残し、次ページを読み進めたくなるなるようなもの…。
そんな文章がベストでしょう。

言葉を研ぎ澄ますってどうやるの？
その練習にもってこいなのが川柳なのです。

5+7+5＝17というガチガチの文字数ルール。
制限下で状況説明しつつ、おっと思わせるオチをつける。
これはもう作文における猛特訓、ポエトリック・ブートキャンプですね。

…という訳で、ゲームデザイナーを目指している君！
川柳にチャレンジしてみませんか？


最後に「川柳川柳」を披露しましょう。

●川柳は　五七五が　ルールです

●川柳は　かわやなぎとは　読みません

●せんりゅうと　読めれば君も　ハマリ出す

●ハマリ過ぎ　その日一日　七五調


駄作の川柳を披露したり調子に乗ったせいもあって総文字数は「871」。
いつもの長文癖が出てしまいました。
まだまだ修行が足りないようです…。

本日のBlogは、諸事情により休載致します。

おはようございます。
最近、寒いせいで朝起きるのが辛い新人プログラマのK.Kです。

あと一週間程で今年も終わってしまいますね。
さて、年末になると「仕事の締め」「大掃除」「納会の準備」と色々やることが増えてきます。

こうなると、普段以上にスケジュール管理が大事になってきます。
何日までに終わらせないといけないから、一日何時間はこの作業に当てようとか、
この作業は期日が近いから優先度を上げて他よりも時間を多く取ろうなど、
自分の中でしっかりとしたスケジュールを立てて作業しないと、「あれも終わっていない」「これも終わっていない」とどんどん追い詰められていきます。

追いつめられるとミスをして、それを修正するのに時間を取られて、またスケジュールが遅れるという悪循環が発生します。

なので、スケジュールを立てるために、まず各作業の締日などから優先順位をつけて、そしてその中から一日の作業時間を決めるようにしています。

そうすると、締日が近づいてから慌てて作業しなくて済むので、ミスをすることが減りますし、何より余裕をもって作業を進めることが出来ます。

こんなことを書いていますが、私自身スケジュール管理に失敗して色々な締め切りに追われています。

これを治すために今は、この作業を一日一時間は絶対にやるようにして、作業をしています。
最初からちゃんとやっておけば今、こんなことにはならなかったんですが....

なので、皆さんはしっかりスケジュール管理をして余裕をもって年末を過ごしましょう。

おはようございます。

昨日まで、風邪でダウンしていたプログラマS.T.です。

今回は久々にプログラマ的記事です。

UnrealEngine4（以下UE4）を使っていると、陥る罠についてお話したいと思います。

UE4にはUnityビルドシステムという機能があります。
この機能を使用する事でコンパイルが高速に行えます。
具体的にどの様な事をこのシステムで行っているか簡単にいうと、
いくつかのcppを合体させ、一括にコンパイルする事でバラだったcppのリンク時間が大幅に削減されます。
例えば「TestGame」というプロジェクトを立ち上げ。
「Hoge00.cpp」「Hoge01.cpp」「Hoge02.cpp」というcppファイルを作成します。
すると、Unityビルドシステムにより「Modul.TestGame.cpp[From A]」というファイルが作成されます。
　※後述の為に[From A]と名付けます。
この中身は下記のような記述になっています。

Modul.TestGame.cpp[From A]=====
#include "Hoge00.cpp"
#include "Hoge01.cpp"
#include "Hoge02.cpp"
EoF============================

初めて、このコードを見た時、
「あー、なるほどなこれは確かに早くなるな、でも怖くてあまり使いたくないな。」
というのが正直な感想です。

僕がこの時感じた恐怖は、勝手に自分の知らないところで#includeが使われている所です。
C++を触ったことある人なら誰でも経験するであろう、多重インクルードの恐怖！！
これに陥ると、ほんと時間と気力を奪われます。
なので、僕は#includeに関しては、特に慎重に取り扱う事を心がけています。

これから、このシステムにおける、個人的に一番恐ろしい所についてお話します。

「正しくインクルードできていなく、本来はコンパイルエラーが発生する所で、エラーにならない事がある。」という事です。

「ならない事がある」という書き方をしていますが、大規模で長期のプロジェクトに携わっていると、
100%どこかのタイミングで発生していまう、問題です。

具体的にどのような事かというと。
上記のファイルの中身が以下のようだった場合です。

Hoge00.cpp=====================
#include "TestGame.h"
#include "Hoge00.h"
[省略]
EoF============================

Hoge01.cpp=====================
#include "TestGame.h"
#include "Hoge01.h"
#include "Hoge02.h"
[省略]
EoF============================

Hoge02.cpp=====================
#include "TestGame.h"

void Hoge02::Hoge()
{
　[省略]
}
EoF============================

本来ならば、Hoge02::Hogeの定義が見つからないと、エラーになるはずです。
しかし、この場合は「Hoge01.cpp」に記述されている、「#include "Hoge02.h"」があることによって、ビルドが通ってしまいます。

そして、このUnityビルドシステムは個人の開発環境毎に異なる物が作成されます。
AのPCとBのPCでは「Modul.TestGame.cpp」の中身が異なるのです。
BのPCの「Modul.TestGame.cpp[From B]」は以下の記述だとします。

Modul.TestGame.cpp[From B]=====
#include "Hoge00.cpp"
#include "Hoge02.cpp"
#include "Hoge01.cpp"
EoF============================

「Hoge01.cpp」「Hoge02.cpp」のインクルードの順番が入れ替わっています。
この場合、「Hoge02.cpp」ビルドは通りません。
仮にビルドが通り、動作の保証されている状態でSVNへコミットしたとしても、他の人の環境ではビルドエラーが発生する可能性が生まれます。

このシステムについて理解せずにコミットが行われ、自分の環境でエラーが発生すると、非常に迷惑です。
なので、#includeは記入者がしっかり管理してください。
テスト実装時に一時的に必要だったが、現在はもう必要がない#includeは削除してください。

しかし人間です、どこかで間違う事はあります。
なので、#includeが正しく行われているかどうか確認する方法があります。
それは「UnityビルドシステムをOFFにする」方法です。
UE4のSolutionExplorerに「TestGame.Build.cs」というファイルがあるはずです。
そこに1行書き足します。

TestGame.Build.cs==============
　public TestGame(TargetInfo Target) {
　　[中略]
　　BuildConfiguration.bUseUnityBuild = false;
　}
　[中略]
EoF============================

以上です。

これにより、ビルドの時間はかかってしまいますが、正しく#includeされていない場合は確実にエラーを出してくれます。
毎回行うには時間がかかりすぎてしまう為、多用はできないですが、不安が残る場合や一度に多数のファイルをコミットを行う際は、
一度この状態でビルドする事をお勧めします。

後で、僕にグチグチ言われたくなかったら、、、笑

おはようございます。新人プログラマーのT.Tです。

早いもので入社して、8か月が経ちました。
会社の雰囲気や業務にも慣れてきたかな。と思うこの頃...

最近、危機感を感じている事があります。
それは、スケジュールの管理や誤字脱字などのミスの多さです。
これによって少しずつ業務の遅れ等が出てきてしまい、先輩方や同僚に迷惑がかかってしまします。

このままではいけない！
なので、「自分を変えたい」と思うようになりました。

どうするか？
どうしていこうか？
どうすれば自分を変えていけるか？
そこで、まずは、“目標を強く持つべき”だと考えました。

目標①
僕は口数が少ない方なので、口数を増やす為に周りの人たちに沢山話しかけることを意識してます。

目標②
誤字脱字を直したいので、文字を書く時によく見直す様にし、直したい事を必要以上意識する様にしてます。

現在、この2点を自分の中で実行中です。

目の前の課題を黙々とこなすだけでは、その経験だけしか得られません。
これを読んでいる人で、もしも同じように毎日ミスを繰り返しており、直したいと思っているなら、
“ミスをゼロにする！”といった目標を立てて、それを意識して行動すれば、
自然に出来るようになっているはずです。いえ、なってる！

そう言った自分自身の課題をこなしていけば、きっと大きな成長が出来ていると思います。

おはようございます
新人プログラマーのK.T.です。

入社から半年以上たち、気がつけばもう年を跨ごうとしている事に驚きを感じます。

まさに「光陰矢の如し」ではありますが考えてみれば、入社してから様々なイベントがありました。

秋イベントでは実行委員として参加者の点呼などを担当し新入社員仲間や普段あまりしゃべらない先輩たちと友好を深め、15周年記念行事では、社員旅行でグアムに行き、ツアーで洞窟探検やファイヤーダンスなどの行事を楽しみました。
また、つい先日では忘年会が行われ、鍋料理を食べ、くじ引きなどをしました。
この時に私は、くじ引きでゲームを当てました。
今年分の運は間違いなく使い切りましたが、その分当てたゲームを休日に楽しむ予定です。

楽しい事もありましたが、これらの行事で学んだことは、人を楽しませるためには色々な事を楽しみ、その経験からどのようにすればみんなが楽しむことができるかを考える事が重要だということです。

そして現在、新人全員と実行委員の先輩たちとで、納会の準備をしています。
納会ではビンゴ大会を予定しており、そのビンゴの演出用のプログラムの作成や、景品を決めたりしています。

これまでの行事で学んだことを念頭に入れて、今年の納会を成功させたいと思います。

師走に入り、大阪も冬本番。
社内も社外も風邪が流行っています。
皆さんは体調を崩されていないでしょうか？
本日のブログ当番M.I.です。

少し前に画面全体のコントラストが弱く感じたので、
ポストプロセスでコントラストを上げたくなったことがありました。
輝度の低いところはより低く、高いところではより高く変換することで実装します。
画像をいじる人ならばトーンカーブを変更するという言い方の方が
分かりやすいかもしれません。

しかし、UE4のマテリアルには
トーンカーブを変更するというような直接的な機能はありません。
輝度値を取り出すのならRGBを取り出し、
HSL変換のLを変更してRGBに戻せばよさそうです。

コントラスト用関数で調べると、
高い値をより高く、低いところをより低くする関数として
シグモイド関数というものがあるらしいです。

ただ、今までそんな関数を知らなかった私には
何の数値を与えればどういう数値になるか想像もつきません。
とりあえずプロットしたい、エクセルでもプロットできそうですが、
ささっとコードを書いて確かめたい。

そんなときにRという言語があります。
統計や機械学習といった分野で活躍しているスクリプト言語です。
統計学者が作ったということで
2つのパラメータ間に相関関係があるかどうか調べる回帰分析、
音声認識などに使われる分類問題を解く機能もあり、
線グラフや分布図が手軽にプロットできるといった特徴があります。

例えば

plot(sin)

これだけでsinのxが0~1までの各値がプロットされます。
-3.14~3.14までをプロットさせれば1周期分見られます。
xlimに最低値、最大値を渡せばいいですね。

plot(sin , xlim = c(-3.14,3.14))

-3.14からちょっとずつ増やした値をsinに渡し、プロットさせるわけです。

こういったグラフが表示されます。

さて本題のシグモイド関数をプロットさせてみます。
2つの変数でグラフの傾きなどの特性を決められるようです。
関数定義はこういう書き方です。
http://www.hamanoweb.com/blog/?p=3408
の数式を参考にさせてもらいました。

sigmoid<-function(h,a,z)
{
  (1 / ( 1 + exp( -a*(z-h)) ) )
}

Rは最後に評価された式が返り値として扱われるタイプの言語です。
なのでreturn と書く必要がないのです。

先ほどのsinのようにプロットさせるには、
変数2つを固定して1引数関数として扱えばよさそうです。

sigmoidPlotter<-function(h,a)
{
  function(z)
  {
  sigmoid(h,a,z)
  }
}

2引数関数に1引数関数を返させるのも自然な書き方で実現できます。

h<-0.5
a<-16.6
plot(sigmoidPlotter(h,a) , xlim = c(0,1))

こういったグラフが表示されます。

何度か値を変えてプロットした結果、
hを中央として、aが大きいほど急なカーブを描く関数だということが分かりました。
また、アーティストさんにこういうトーンカーブにします、
という風に説明しやすくなりました。

画像から輝度を取り出すのはHSL変換なりで調べてもらえればいいので割愛します。
ただ時間がなかったので、下の画像はすでにやり方を知っている明度変更で実装しました。
結果が以下のようになりました。

元画像

コントラストを強めたもの

自在にトーンカーブをいじるなら
ルックアップテクスチャを用意するといったことが必要かもしれませんが、
手軽にコントラストを入れたいなら今回の方法も使えるかもしれません。

おはようございます。
プログラマーのS.Mです。

先日、旅行に行った際に、色々な物を体験しました。
フライボードやダイビング、実弾射撃など、初めて体験したものが多く、とても有意義な旅行になりました。

今までのテレビなどで見たことはあるものばかりなのですが、実際に体験するのと見るのでは、得られる情報がかなり違います。

フライボードでは、バランスの取り方の難しさや、実際に自分がかなり高く飛んでいると感じても、写真や動画で見るとそれほどに感じたりしました。

ダイビングでは、ずっと水中にいる不安感や息苦しさを感じる中で、キレイな景色や魚を見れる高揚感と水中を自由に動ける浮遊感などを感じました。

実弾射撃に関しては、
ゲームやアニメ、映画を見ていると良く銃を撃つ描写がありますが、実際に体験すると、撃った時の反動や、発砲音の大きさとかは想定以上でしたし、狙ったところに全然いかなかったりなどの現実と理想の違いが体感できました。

体験してみて初めてわかることはすごく多かったです。
実際に今回経験した内容は今後の作業にも活かせる部分がたくさんありました。
ゲームで同じような体験もしくは近しい体験を実装する事になった際に、今回の経験は活かせると思いますし、今回旅行で行った国に近い気候状態をゲーム上で表現する際に、その環境の空気感や建物の造り、現地の人の生活観など参考に出来ると思います。

なにより、もっと色々な事をやってみたい、色々な所に行ってみたいという意欲が湧いてきました。

また機会があれば、たくさんの事を体験して、自分の経験にしていきたいです。

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

過去にはPS4でゲームを作ったことがあるのですが、地味に便利な機能だなと思う機能があります。

PS4はシェア機能によってゲーム中の動画を録画しています。
今までは開発中に不意なバグでハングしたときに、記憶を頼りにバグの再発生を試みたりしたのですが、シェア機能でプレイ動画が撮られているのでハングしたときにシェアボタンを押してどういった状況でハングしたのかを確認したりします。

開発中によく聞く言葉「なんかしていたらハングしました。」

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

ブログでも何度か話が出ていますが、先月に社員旅行でグアムに行ってきました。
帰国前日に15周年記念パーティがあり、その中で行なわれたじゃんけん大会で優勝しました。
2016年の残りの運を使い切ってしまったんじゃないかと不安になるレベルの勝ちっぷりでした。

改めて数えてみるとじゃんけん大会では7連勝したのですが、二人でじゃんけんをする場合、こちらが勝つ確率は3分の1になります。
あいこはノーカウントとしても、7連勝する確率は約2187分の1となり、改めて考えると、とんでもないことをしてしまった感があります。

ゲームでも確率が表示されている場合や、ランダムで発生する事象は数多くあり、ゲームと確率は切っても切れない関係にありますが、以下のようなことに覚えのある人も多いのではないでしょうか。

おはようございます、プログラマーのＴ.Ｔです。
最近はChatOpsにハマっています。
ツール名とかではなく、
チャットにインフラ処理を載せて統合してしまおうという方針のことです。

大抵の会社様ではチャットを使用していると思いますが、
そこへ自作のBOTを置き、BOTと各ツール、サービスを連携して動作させます。

全てチャットで済むので、インターフェースの一元化や学習コストの低減が行えます。
最近ではLINEのBOTを利用したサービスなどもありますね。


うちで動作しているのはこんな感じ。


チャットにいるBOTに特定のキーワードを話しかけることで動作します。
上が僕で下がBOTです。

BOTがjenkinsを起動し、ビルドしたあとexeのサーバーアップロードを行います。

ビルド用マシンで実行されるのでどの人が起動しても同じ処理が走ります。
作業フローの属人化を防ぎ、いざとなればエンジニアでなくてもビルドが可能です。

もちろん途中でエラーが出たらBOTが報告してきます。偉いですね。


また定期的にメッセージを出すことも出来ます。
日報書き忘れ告知とか。



ついでにBOTのメッセージを日本語化＆ランダム化することで、親近感が爆上がりします。
上の処理も接頭語、本文、助詞などの組みあわせでかなりのパターンの返答を作ってます。
無駄ではない。無駄ではないのだ。

ただ日本語をテキトーに書いちゃうとこんなことに。



ここで使用しているツールとサービスは、
Slack ⇔ Hubot ⇔ jenkins です。
一番メジャーなフローなのでWeb資料がたくさん転がっています。


とにかく用途が幅広く、
様々なサービスやツールと連携することで、
社内の面倒な作業を任せるようになるでしょう。

jenkinsのjobを叩くだけでも作ってみてはいかがか！？

おはようございます。
プログラマーのG.Iです。
最近、突然寒くなりましたね。
11月は全然暖かかったのに突然の寒さでスタッフの何人か、風邪を引いている今日この頃です。
まあ、私も絶賛風邪で咳きがとまらない状況ですけどね、、。

新しいプロジェクトも始まり、日々、製作にいそしんでいるのですが
ひとつ感じたことがありました。
それは、製作環境を整える中のひとつのツールを導入したときのことです。
パラメータの中間ファイルを出力する単純なツールなのですが、
今回のプロジェクト用に作成したのではなく
別口で独自で作成したもので、ほとんどそのまま使用できるだろうと思っていました。
ですが、実際にプロジェクトで使ってみると色々足りないところが
いくつも出てきました。
今までの開発においての自分の立ち回りでは、あまりツールを作ったり提供する
という立場になかったので、地味にやりがいを感じています。

それ以外であっても、仕事においては実際に試したり、使ったりすることで
自分の見えない部分が見えてくることが非常に多くなります。
その都度、試行錯誤が必要だったり、失敗してしまうこともあります。
ですが、その積み重ねが経験となり知識となるのも事実です。
新人のみなさんは、まだまだ失敗しても何とか許してもらえると思いますので
色々チャレンジしてみましょう。

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

今年も残すところ、あとわずかですね。

年末商戦ということもあり、
最近はゲームがたくさん発売されて、
どれを遊ぼうかを悩む毎日です…。

今までは後先構わず発売日にゲームを買っていたのですが、
それだと封を開けてないゲームがどんどん積み上がっていきます。

「このままではいけない！」と思い立ち、
少し前からゲームを購入する際は
スケジュールを組み立てるようにしています。

あ、ちなみに仕事のスケジュールみたいに
きっちりしたものではないですよ。

新作ゲームの発売日と、今遊んでいるゲームの状況を考慮して、
もうすぐ終わりそうなので新作ゲームは発売日に買えそうだな、とか
今遊んでいるものを先に終わらせよう、とか
…という程度の事ですね。

ほんの少しだけ気を付けるようにした程度ですが、
それでも効率よくゲームを購入でき、
積みゲーの量も減ってきたような気がします。


仕事で普段しているスケジュール管理が
実生活にも役に立ちましたね！

仕事でも実生活でも、
普段から予定を組むことを心掛ければ、
いろんな事が効率よく回せると思います。


なので、これからもゲームのスケジュール化はしていこうと思ってますよ。
…今月買うゲームについては、まだ悩んでいますが（汗

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

何事かを完遂するためにはそのゴールを定める必要があります。

ゲーム要素を実装する際には、次のように掘り下げていって、
作成された仕様（作成していく仕様）に対して、ゴールを決める必要があります。

・どこまでやるのか？
・その仕様の優先度は高いのか？
・ユーザーが目に触れる、ゲームに占める割合から妥当なコストは？
・かけられるコストから実装可能な方法は？
・その実装方法で目的は達成できるか？
・別案はあるのか？
等など

そして実際に作業にとりかかるわけですが、期日があります。
期日に向けて作業を進めている中、
進捗が芳しくなかったり、
画的な効果が意図どおりでなかったり、
挙動がイマイチだったりと、
現状がよろしくないという事が起こります。

そういった場合に捨てるのか、さらにコストをかけるのか、
予め目標を定めているとぶれることなく判断できます。

また、別案を事前に用意して、問題があった場合は
そちらに差し替える段取りにしていれば、
１００％の効果では無いかもしれませんが、
ゴールへと達成できる方法が残っているわけです。

後々の自分の判断を間違えないためにも、
判断基準となるゴールはしっかりと定められればと思います。

おはようございます。本日の当番、ゴルファー兼プログラマのJ's.Kです。
冬を迎えるにあたり、気温のようにゴルフの内容も下がり調子です。


さて、本日のお題は「スキルと状況判断」です。


先日、ゴルフをしてきました。
しかもグアムで！
初めてのグアム、初めての海外ゴルフ、いろんな初めてを満喫しました。

現地では、土の違い、芝の違いはありましたが、いつも通りにプレー。
ただ、風の強さには脱帽でした…

で、自分ではいつも通りにプレーしていたのですが…
何度か同伴の方に驚かれました。

・よく飛ぶな～！
・そのクラブ何番？
・あそこ狙うの！？

等々。

自分では、いつも通りに

・コースレイアウトを確認
・打つところを決定
・打つクラブを決定

とやっているのですが…


で、はたと気が付きました。
それは…


個々でゴルフのスキルが違う


ということでした。


例えば、目の前が谷の場合、谷を越さなければいけません。
しかし、谷を越えるための距離が打てなければ、谷に落ちます。
谷に落ちるのがイヤならば、谷を回避して打たないといけません。

自分のスキルを自分で把握している。
だから自分に対してベストな状況判断ができる。

そして、その判断は、自分では当然普通だと思っています。
別に背伸びをして、無理をしているわけではありません。
なので、やることに何の疑問もありません。


さて、これは業務にも当てはまります。


自分の仕事上でのスキルを正しく判断しておく。
そして、作業内容から、どの程度の工数で作業が終わるかを判断する。

それらを組み合わせていくことで、精度の高いスケジュールができる。
そうすることで、プロジェクト全体が円滑に進行する。

ですが、できもしないのに作業の安請け合いをしてしまうと大変です…
スケジュールは破綻し、その影響で他の人へも迷惑をかけてしまいます。

そういうことが起こらないように、スキルの把握と正しい判断が必要になります。

若い人ほど背伸びをしがち。
背伸びをして、後で痛い目を見るよりは、正しく判断できる方が信頼されます。
かといって、自分のスキルを下に見過ぎてしまうのも困りもの。
そこも正しく判断しないといけません。
そして、作業経験をもとに、少しずつスキルを上げて行きましょう。


と、言いつつも、ゴルフのスキルは上がってるのか、下がってるのか…
好不調の波が激しすぎて、もっと安定させたい！と思っている今日このごろです…

Bonjour!皆さん。インドネシアから来た新人CGデザイナーA.T.Pです。

ますます寒くなってきましたね～！12月になった途端冬の気分に変わり、クリスマスの気分になりました。
自分に「どんなクリスマスプレゼントをするかな～？」とたくさん考えてしまいました。
欲しいものがありすぎてどれだけお金を持っても足りない気がします。
人間の物欲はその収入が増すにつれて大きくなるので怖いですね。
自制しないとやばいですね。

さてさて、話は変わりますが、皆さんゲーム開発の中で一番大切なものは何だと思いますか？

答えは、いつも健康である事です。

どれだけスキルがあっても体調が崩れていると良い仕事をする事は出来ませんし無理やり仕事しても集中もできず、作業効率も低くなるかと思います。
一年間365日の間でずっと元気で過ごせる人もいるかと思いますが一般的には、風邪を引いたり、体がだるくなったりすることが絶対にあるかと思います。

先月、健康診断があり、「僕は健康ですよ、絶対問題ない！」と思いながら診断を受けました。
すると、先週、とてもショックな結果が返ってきました。
健康診断報告書に所々赤字で書いていた判定がありました。
総合判定で「食事生活の注意しないと多くの生活習慣病を引き起こす原因になりますぞ」と書いていました。

なんとショックだ！いつも自分は元気だと思っていたが、実は中性脂肪が基準値よりはるかに越えてしまい、体重も標準体重よりも10キロぐらい太っていた。
このままだと本当に生活習慣病を引き起こしになりそう～！

話がずれちゃってすみませんでした。

僕が言いたいのは、ゲーム開発の間は毎日8時間以上絶対にパソコンの前で座ったまま作業をしています。
2～3年間ぐらいずっとその状態だと体に負担をかけてしまい、色々な病気を起こすことにもなります。
だから、面接の時何回か聞かれました「ゲーム開発は厳しいぞ、大丈夫？」聞かれましたもちろん、その時その場で僕は「はい！大丈夫です」とすぐに答えました。

７ヶ月間ここで働いて、「厳しい」と言う事実を実感しました。
最近、座りっぱなしのせいで僕の腰が痛くなってきたし、中性脂肪もどんどんたまって腹囲が大きくなりました。
ここで働きたくないというわけではないですよ～。
むしろ、楽しいし、新しい事ばかりやっているので、何から何まで全部勉強になりました。

そのため、このブログで僕は宣言します。
入社してから運動する事が減っていたので、今月からジムに行こうと思います。会員登録とかまだだけどね。
最初の目標は一週間一回でジムに行き、トレッドミルで2時間ぐらい歩きます。
そのあと、少しずつジムに行く機会を増やして一週間2～3回にしたいと思います。
そうすると、体も気持ちよく続けることができ、生活習慣病を引き起こさなくなると思います。
来年の夏までは僕の体重が減るといいですね。
もちろん、次のブログの当番が来た時には進捗を報告します。

それでは、皆さんもいつも健康である事を願っています。油断をせずに健康管理を頑張ってください。
こっちも頑張っていますから!!　

また次の機会に会いましょう。
さらばだ!Adieu!

おはようございます。最近ビートルズにハマっている、新人CGデザイナーのH.Tです。

この頃整理整頓の大切さをひしひしと感じているので、お片付けの話をします。

先日、数週間ぶりに部屋の片付けをしました。
私は焦れば焦るほど部屋が散らかります。
この間は絵が上手く描けなかったので、部屋中が本だらけになりました。

しかし、部屋が散らかっているとなんだかモヤモヤ…。
絵を描きたくない…何もしたくない…、と負の感情が渦巻きます。
悪循環ですね。
なので私は重い腰を上げてお片付けをしたのです。
大事ですお片付け。

部屋を片付けると気持ちがスッキリ！やる気にあふれて、気分転換にもなりあら不思議！
爽やかで素敵な絵が描きあがりました。

前置きはさておき、私は最近、仕事でも整理整頓をしています。

数か月前から先輩や同僚に勧められ、
仕事で必要な作業をエクセルにまとめたチェックリストを作るようになりました。
頭の中の整理整頓です。

焦っている時はすぐにでも作業を始めたくなりますが、この少しの手間で心の余裕を
作ることが出来ます。
まずやることを書きだして、さらにモデリングやウェイト調整などの項目に分けて
表を作ります。
作業が完了したらリストにチェック。
少しずつでも終わった作業が見えるので、モチベーションにもつながります。
情報の視覚化は予定を立てるのにも役立ちますし、何よりもこれをすれば大丈夫！と分かる安心感がすごいです。

前はノートに書いていたのですが、ノートだとどこに書いたか分からなくなってしまうのでアナログとはさようならしました。

こんなこともあり、焦ったときのお片付け、結構大切なのではないかなぁと感じてい
ます。

昔は、あえてメモをせずに記憶しておくことで深層心理の世界で何かが起こって、
なんやかんやあって、芸術が…爆発する…！！
なんておかしなことを考えていた頃がありましたが、今思えばあの頃は若かったです。

これからも片付けをめんどくさがらずに、身の回りや頭の中をスッキリさせていこう
と思います。

おはようございます。新人ＣＧデザイナーのN.Tです。

先日、社内の勉強会でスライドを作る機会がありました。
スライドに限らず、レポートや表を作っているときもそうなのですが、つい趣味に走って凝った画面にしてしまいます。
ガラガラした画面のせいで文章が頭に入ってこない⇒泣く泣く装飾や色を減らしていく。
という作業が学生の頃から習慣になっています。
どう考えてもムダな作業なのでそろそろ改善していかないといけませんね。

突然ですが、みなさんは行間スペースやカーニングを意識してポートフォリオやスライドを作れていますか？
禁則処理はしっかりとできていますか？

作品をしっかりと作れていてもポートフォリオが見にくい…。
なんだか画面に締まりがない…。
スライドを見ていても内容が頭に入ってこない…。

という場合、文字の良し悪しが原因の一つだと思います。

右に比べて左の文章、なんだか読みにくいとは思いませんか。
両方全く同じ文章なのですが、右の文章は、

・見出しは視認性に優れたゴシック体を使う
・見出しと本文のフォントのサイズに差をつける
・句読点の前後でカーニングを行う

等のこだわりを入れてデザインしています。
同じ文章でも、行間スペースやカーニングを整えて、見出しのフォントに少しこだわると、読みやすさがグッと変わりますよね。

「どんなフォントをどんな場面で使えばいいのかわからない！」と思った時は、身近にある雑誌や広告を見てみることをオススメします。
ファッション誌を見れば今流行の色味や商品にマッチしたフォントの使い方を学べますし、情報誌を見れば食べ物やスポットを魅力的に見せる写真の構図を学べます。
（何よりも週末の出掛け先を吟味できますね！！！）

行きつけの美容室で「字がかわいい雑誌を読ませてください」と言ったばかりに、”変な子”の称号を得てしまったわたしですが、日々周りの物から吸収してデザインの引き出しを増やしていきたいと思います。
みなさんもお出かけの際には、意識して誰かのデザインに目を向けてみてはいかがでしょうか。