Hatena::ブログ(Diary)

Ideals and Reality このページをアンテナに追加 RSSフィード Twitter

2012-12-31

2012年振り返り

前回更新からとても時間が経ってしまいました。

今年も色々あったんですが、最後に振り返りをしたいと思います。


SNS依存度が極端に下がった一年

まず私自身のことですが、今年はTwitterfacebookなどのソーシャルネットワークサービスに対する依存度が非常に下がりました。

昨年まではSNSをとても活用していたんですが、SNSを使うほど自分に障害となるものが増えるという認識になりました。

もちろんSNSは便利に使うとすばらしいツールとなるのですが、SNSに依存しすぎると本当にやりたいことができなくなってしまったからです。

あとはSNSの中に依存していると非常に狭い世界の中で起きていることが常識と考えてしまうことです。

気づけば宗教のようなものに知らずのうちに入信していたような感覚です。

ただし、SNS自身は情報を得るためには非常に便利なツールでもあるわけで、今は一線から身を引いて使用することを心がけるようにしています。


ソーシャルゲームを中心に様々な変化が起きた一年

ソーシャルゲームの台頭はもはや言うまでもない一年ではあったのですが、その中でも様々なゲームがあったと思います。

ガンホーから今年リリースされたパズル&ドラゴンズソーシャルゲームのようにみられがちですが、ほとんどソーシャルな要素はありません。

他人のモンスターを借りて一緒に冒険するという程度でこれならコンソールゲームで今年発売されたドラゴンズドグマの他人のキャラを借りることのできるポーンと変わりません。

ここからわかることは必ずしもソーシャルゲームじゃないとヒットしないというわけではないということです。

ただし、ソーシャル要素がなければいいのかと言われるとそうではありません。

日本人が求めているのはユルくても他人と繋がれて気軽に楽しめるソーシャルなんだと私は思っています。

そこに上手くハマるゲームシステムを作りこむことで、きっと今のソーシャルゲームの常識は覆せるんじゃないかと。

来年はまた新機軸のソーシャル要素をもったゲームが確実に現れるでしょう。


技術力よりも価値を重視したい

私は今まで技術力こそが素晴しい価値を生み出す要素となり、技術力を磨けばできることが広がり新しい価値が生まれると思っていました。

今年はずっとそのために今まで挑戦していなかった分野の技術を磨いてきましたが、結果自分が何も生み出せていないことに気付きました。

技術力は大事な要素ですが、そこにこだわりすぎるあまり本当に大事なことを忘れていました。

沢山の技術の塊であるUnityのようなゲームエンジンを使っていたとしても素晴しい価値が生まれるわけではありません。

去に作ってきたゲームでは沢山の苦労をして、いくつもの価値を生み出してきました。

バカみたいにゲームを作ってきてもそれなりにいいものを作ってきたという自信もあります。

しかし今年はそれができませんでした。

何も生み出せていない自分に反省するためにも、来年は技術を磨くよりも価値を生み出したいと思います。


来年はもっとがんばりましょう

結局自分の反省ばかりでしたが、来年こそは自分にとって何かを達成できたなと思える一年にしたいと思います。

それでは今年一年お世話になった方々にお礼を申すと共に来年度もどうかよろしくお願い致します。

2012-08-10

Unityの核であるMonoBehaviourについて

Unityを使っている人なら誰でも見たことがあるであろう、MonoBehaviorクラス。

巷ではMonoBehaviourを使うとC#の機能が使えなくなるとか、コードビハインド出来なくてMVCモデル的な作りが出来ないとか、極力MonoBehaviourは使うな!とまで言われたりしています。

私は逆にUnityを使うのにMonoBehaviourを使わないなんてとんでもない!と思っています。

と、いうかMonoBehaviourを使うことがUnityを使う一番の理由になると思ってるくらいに。

その潜在能力の高さを1度知ってしまうと使わないなんて考えられなくなってしまいます。


1.MonoBehaviourの持つコルーチンが超強力

これもう本当に強力。

おもむろに

yield return 0;

と書けばそのフレームの処理をそこで終了し、次のフレームはそこから処理を再開するのである。

yield return new WaitForSeconds(1f);

と書けばなんと処理を終了し一秒後にはそこから処理を再開してくれるというのが簡単に書ける。

これを使えば非同期処理は簡単に書けるし、何かを待ってステート進行させるというのが一瞬で出来てしまう。

スタートしたコルーチンは簡単に止めることも出来るので、コルーチン中でも対応が出来る。

ここらへんはもう誰でも使っているようなレベルだろう。

が、Unityのコルーチンの強力さはそれだけではない。

本来UnityのコルーチンはMonoBehaviourのUpdate()関数内では使えないが、実はStart()関数無限ループしつつyieldを実行するとUpdate()内で実質的に同じことをやっているようなことが出来る。

http://answers.unity3d.com/questions/8908/is-function-update-short-for-function-start-whilet.html


void Start()
{
	while (true) {
		// 毎フレーム行う処理
		yield;
	}
}

こんな反則技がよく許されたもんだと思いつつもこれでAIのステート管理が超絶的なまでに楽になる。

実際このテクを使ってAIを記述しているケースも多いようだ。


2.OnXxxXxx系のコールバックで各種処理のフックが超簡単

例えばマウスでクリックされたという情報がとりたければOnMouseDown()を呼び出せばそれだけでマウスボタンのイベントが処理出来る。

このコールバックイベントはマウスだけでなくあらゆるものに対応しており、コリジョンのヒット時判定、レンダラーの描画ONOFF時、新しいシーンが読み込まれた時、描画が完了した時など、あらゆる状況で呼ばれる。

これがあるおかげであらゆる状況で処理をフックさせることが出来る。

実際にゲームを作っていると、「あの状況で処理を割り込ませたい…」という状況は多々発生する。

もちろん全てのケースに対応しているということはないだろうが、ほぼ大抵の状況に対応するほどの量は用意されている。

特にカメラ描画内に存在しているかいないかというのは非常に重要でAIの動きの制御や描画の最適化にも使用されるので知っておいて損はない。


3.MonoBehaviourが持つメッセージ機能が超汎用的

SendMessage("FuncName")というような具合で、MonoBehaviourが持つGameObject全体にFuncName()という名前の関数があれば呼び出すことが出来る。

これはそのGameObjectに対象となるスクリプトがアタッチされている必要があるが、やりようによってはかなり汎用的なことが出来る。

これだけならまぁありがちな感じがするが、Unityアニメーションエディターとアニメーションイベントを使ったメッセージが凄い。

UnityアニメーションエディターはGUIで編集する汎用的なものですが、ここで起きるアニメーションイベントにMonoBehaviourのスクリプトがアタッチ出来る。

ここであらかじめGameObjectのヒエラルキー上に位置情報を示すロケーターObjectを配置しておき、イベントが起きた際に

Transform[] transArray = gameObject.GetComponentsInChildren<Transform>();
foreach (Transform trans in transArray) {
	if (trans.name == eventNameString) {
		PlayEffectEvent(eventNameString, trans);
	}
}

上記のようなコードが呼ばれるようにしておく。

次は各GameObjectが持つTransformを取得し、GameObjectにはあらかじめ発生させたいイベント名などをつけておく。

そしてイベント発生時のMessage関数にそのイベント名の文字列を渡しておき、特定のアニメーションクリップに対して指定したタイミングでこの位置に対して汎用的なイベントを起こすということが出来る。

上記の方法では特定の位置のGameObject Transformの名前がイベント名文字列と一致した場合はその位置に対してエフェクトを発生させるというイベントを発生させている。

これはあらゆるものに応用が可能であり、エフェクトだけではなく、SE、カットシーン演出でのカメラ移動やAIアニメーションベースにステート管理させるといったことが簡単に出来るようになる。

ぶっちゃけこの仕組みだけでゲームの動きと演出と制御がかなり出来てしまう。

それくらいに恐しい仕組みであることは間違いない。


4.MonoBehaviourに揃っているコンポーネントたちが超豊富

MonoBehaviourはTransformなど当然のようなコンポーネントを持っているが、それ以外にも剛体物理を実現するrigidbody、カメラ制御をするcamera、ライト担当のlight、音担当のaudio、コリジョン担当のcolliderなどなど実に豊富なコンポーネントがアタッチ出来る。

これらはGetComponent()を使えばどこでも取得出来るし、自身がGameObjectであるのならAddComponet()でいつでも追加も出来る。

もちろん全部のコンポーネントを使うことは間違いなくないが、いつでもそれらを使うことが出来るのがMonoBehaviourの魅力であることは間違いない。

Unityコンポーネント指向という考え方はMonoBehaviourをベースに作られているということでMonoBehaviourの重要さがわかったのではないかと思う。

とはいえこれでもまだMonoBehaviourの魅力としては一部だと思っているし、私自身もまだまだ色々なことが応用出来るのではないかと思っています。

コルーチンと各種コールバック、メッセージなどは全て混ぜて使うことも出来るし、応用すればもっと凄いことが簡単に出来るはずです。

これで少しでもMonoBehaviourを「もっと使ってみたい!」と思ってもらえれば光栄だし、「もっとこんな使い方してる!」とかあればぜひ教えてください。


追記

改めてみても説明がわかりにくい。

そしてUnityの説明はコードや文章だけでは伝えにくいですね…

動画とか撮るべきなんだろうか。

2012-07-09

UGJ2ndに初参加してきました

UnityGameJameというゲームジャム(即興チーム超短期間ゲーム開発)イベントに参加してきました。

http://www.zusaar.com/event/306053


実はゲームジャム自体の参加が始めてだったんですが、限られた時間の中でどうすればいいのかよくわからず時間配分にも非常に悩みました。

開発時間自体は30時間もなく、当然食事や睡眠もその時間でとらないといけないので難しいところ。

Unityは最近本格的に触り始めてまだこれから覚えるという感じだったのですが、一緒にチームを組んだ人もほとんどUnityは初心者で逆に自分の方が教えている時間が長いという事態に。

しかしUnityを使って一通りゲームを作ってみて、意外と自分の知らない事が多くて勉強になる事ばかり。

普段プログラマーとしてコードばかり書いているとUnityの事ってあまり知らないんだなと実感。

チームを組んだ人もみんな初対面でスキルも当然バラバラ。 どこまで出来るのかと不安ばかりでしたが、なんとか形になったものが完成。以下のサイトにて実際にプレイする事が出来ます。

http://c8bkz3-ay9-app000.c4sa.jp/


今回はチームF:Uniben666としてゲームを作らせてもらいました。

色々とゲームとしては酷いところもありますが、少しでも遊んでもらえたら幸いです。

2012-06-23

私の中でのアジャイルに対する考え方

最近どこへいってもアジャイルもしくはそれに関連する話を聞く事が多くなってきました。

実際私も世の中が言うアジャイル開発をやっていたりしますが、少し思うところを書こうと思います。

実は既にアジャイルだった

ゲーム業界で既に数社の中で仕事をしてきた私ですが、大抵の会社ではアジャイルに近いような開発をしていたと思います。

実際エクストリームプログラミングやスクラムを使用して開発していたというわけではありませんが、週単位どころか日数単位で変わる仕様に対応する開発体制、毎日行う報告会、週単位での進行確認、実際に作り上げた成果物報告、マイルストーンを区切っての出来たゲームのレビュー等、細かい単位の中で変化に強い開発はある意味で当たり前の光景です。

無駄のない素早く開発を行うという意味ではアジャイルそのものでしょう。

この話は既に過去に同様の事を仰っている人もいました。


CEDEC事前インタビュー:アジャイルで大規模開発? スクラムを使ったゲーム開発の可能性とは

http://www.4gamer.net/games/105/G010549/20100821003/

更に同記事内にはアンチャーテッド2はスクラムを用いて作られたという事も言われています。


GDC 2010]ゲーム大賞受賞作「Uncharted 2: Among Thieves」のポストモーテム

http://www.4gamer.net/games/093/G009300/20100313002/

これらを見る限りゲーム業界においては既にアジャイルな開発が一般的(XPだとかスクラムだとかは別として)であると言えるでしょう。

実際にアジャイル(素早い開発)なのか?

実際にXPスクラムを取り入れて開発はアジャイルになるのか?そういう疑問は常々湧いてきますが、結局のところ慣れの問題であると思います。

私はXPスクラムを取り入れても開発がアジャイルになるかと言えばそうとは思いませんし、XPスクラムがなくてもアジャイル開発が行えているケースもあると思っています。

特にゲーム業界ではそういう会社が多いでしょう。

アジャイルXPスクラムだけでなく、クリスタルファミリー、フィーチャ駆動開発、適応的ソフトウェア開発、動的システム開発方法論、リーンソフトウェア開発、などなど様々な手法が存在しています。

結局のところは何を選ぶかが重要ではなく、自分達に合った方法で素早く開発するという事に尽きると思います。

何かにこだわるよりも自分が最も素早く開発出来る手段をとる、それこそがアジャイル開発だ、というのが私の中での結論です。

2012-06-16

ソーシャルゲームとコンソールゲームの壁

最近ゲーム業界の人と飲んだりする機会が多くなっているので、色々と感じる事があります。

今の私はオンラインゲームを作っていたりするわけですが、いわゆるソーシャルゲームを作っている人達とコンソールゲームを作っている人達両方と会う機会があります。

しかしやはり同じ場に両者のクリエイターがいる事が少ないです。

特にアーティスト系の人はソーシャルゲーム業界には少なく、イラストレーターだけを雇って作るようなゲームが多いです。

テクニカルアーティストと呼ばれるような技術者がほとんどいないので、グラフィカル面での技術が乏しい。

他にも大きな差を感じるのはソーシャルゲーム業界には優秀なエンジニアが多いですが、それ以外の人達はほとんど目立つような事がありません。

コンソールゲーム業界ではエンジニアプログラマーが表に目立つような事はなく、ディレクターやプロデューサーの人ばかり出てきます。

この差も大きく、両者の交流が薄い一員にもなっていると思います。

私自身は今後ソーシャルゲームと呼ばれるものは確実にコンソールゲームにも取り入れられるものと思っていますので、両者がもっと深く交流する必要はあると思っています。

そして互いの技術力を合わせて世界のコンテンツ競争に打ち勝つ必要があります。

Connection: close