Double Piece

見習いプログラマーによるUnity,DirectXTKだったりのメモブログ

名工大ハッカソンに向けての予習3

久々の更新です。毎日更新はどこへ行ったのやら...

 

今回はUnityのアセットであるDotweenについて書いていこうと思います。

 

まずDotweenがどういうものか。ずばりTweenエンジンです。

いや、だからTweenエンジンってどういう意味だよと。調べました。

 

Tween-トゥイーンtween)とは、between(中間)に由来する言葉で、2つのイラストが変化しながら繋がるアニメーションのことを「トゥイーンアニメーション」といいます。 トゥイーンアニメーションには「モーションアニメーション」と「シェイプアニメーション」の2種類があります。

 

優しすぎるGoogle先生。要はアニメーションの始点、終点、アニメーションの内容を渡せば、中間を勝手に補完してくれるとにかくすげー奴です。コードを書く量がごっそり減ります。

 

というわけでサンプルコード

 

 

まずDotweenを使用するには using DG.Tweeng が必要です。

 

で、あとは簡単。コメントにもある通り1行書くだけで横移動ができちゃいます。

 

もちろんこれだけじゃないです。スケールを変えたり、回転させたり、はたまたジャンプだったりと色々な動きができます。

アニメーションにイージングをかけることもできるのですっごい便利。

 

というわけで他にもいろいろあるので続きを次の記事で書いていこうと思います。

特に多彩なイージングについて。

 

短くなりましたが、無理に長い記事を書かずにこういう記事をポンポン書いていくのもいいかもしれませんね。

 

今回はここまで。

名工大ハッカソンに向けての予習2

こんばんは。

さて、前回はOnCollision系とOnTrigger系の違いについて軽く触れましたが、詳しいのは書いてなかったので今回は続きを書いていきます。

 

まずOnCollision系ですが、前回軽く紹介した通りOnCollisionExitは衝突している状態から離れた時、OnCollisionStayは衝突している間ですね。

この2つは多分皆さんがパッと思いついた挙動と同じような感じになってくれると思うので詳しい紹介は割愛します。

 

というわけで本題。OnTrigger系についてです。

こちらはオブジェクト同士を衝突させずに当たり判定を取るというものですね。例えば「チェックポイントの通過」とかは衝突させずに当たり判定を取りたいですよね。

 

では、分かりやすいようにUnity上でやってみます。前回書いたコードに追記していきます。

 

ちょこっと追加しただけです。どっちの関数が呼ばれるかを試すためにデバッグログ出力してます。

そしてCubeにRigidbodyをアタッチしてUseGravityのチェックを外します。これでCube君は無重力空間にいるみたいな状態になりましたね。

 

じゃ、これで再生します。

f:id:mkp0824:20170423040348g:plain

うん、これCubeのColliderのIsTriggerにチェックつけた方がよかったね。

と思って取り直していたののですが途中でロイロ君がグレてしまったので断念。

次まで使うまでに新しいソフト入れておこう。

IsTriggerにチェックつけるとSphere君がCube君を通過しつつデバッグログの方に「Collider」と出力されます(投げやり)

 

簡単に使い分けをまとめますと

IsTriggerにチェックを付けてるならOnTrigger~~~

IsTriggerにチェックを付けてないならOnCollision~~~

と理解しておけばとりあえずは大丈夫かなと。

 

Rigidbodyの有無に関係する、というような内容の記事も見つけたのですが自分の方で試したところRigidbodyはいまいち関係なさそうだったのと、記事自体が古かったので「う~ん?」

という感じでした。なんかもやもやするので記事自体はここで終わりますがもうちょっと調べてみようと思います。

 

 

 

今回はここまで。

書籍が溜まっていく

こんばんは。昨日は寝落ちして更新できませんでした。

今回は申し訳ないのですが生活サイクルを戻すためにも軽めの内容で行きたいと思います。前回の続きについては本日の22時までに更新できたらいいな~という感じで行きます。

 

今回はタイトル通り、書籍が溜まっていっている話を少しだけ。

 

ゲームプログラマになる前に覚えておきたい技術

言わずと知れた、という感じですね。2D,3D両方解説してくれている上に、自分のような数学ダメダメな人間でもやさし~く解説してくれているのでほんとに助かります。

ボリュームすごいです。まだ全然読めていません。春休みにさぼっていたのが悔やまれますね...

 

・DIRECT3D11必携

ちょうど今日届きました。ちゃんと他の本読み終えてから買えよと。

こちらは学校で薦められたので買ってみました。ん~、学生には痛い出費でした。

とりあえず大雑把に読んでみましたが、こちらも超基礎から学べます。

自分はネット上で効率的に調べるのが超下手くそなのでもう聖書にすら見えてきます。

気になった部分は、聞いたことはあるけどどういうものかいまいち理解できていないシェーダーについて。まだ自分が手を出すには早い感じはしますが、せっかくの聖書を漬物石にするわけにはいかないので、こちらもおいおい読んでいこうかなと。同時進行で理解できるような処理能力は私の頭には備わってないです。

 

さて、1冊目の本をまだ読み終えていない原因なのですが、恥ずかしいことに「環境構築でつまづく」という著者も想定していないようなアホらしいことです。

とはいえ、始める前からやる気をそがれている訳にもいかないので、環境構築に関してはとにかく回数こなして素早くスタートラインに立つ練習からですね...

 

来月中にゲームプログラマになる前に覚えておきたい技術に関しては読み終えたいなあと。

 

ゲームも控えよう。そうしよう。

 

今回はここまで。

名工大ハッカソンに向けての予習1

 こんばんは。今回は自分も参加する名工大ハッカソンが近いということでUnityのことについて簡単に書いていきます。

なぜUnityかと言いますと、前回参加させていただいたときに8割ほどのチームがUnityを使っていたので今回も主にUnityが使われることになるだろうと見越した結果です。

ちなみに前回の私はと言いますと、ほとんどUnityについて理解していない状態での突撃だったのとそもそもプログラミング経験が浅いこともありチームに対して十分な貢献ができたとは言い難いです。

という訳で今年はそのリベンジを果たすため、今のうちに基礎を洗い直しておこうかと。というより中途半端に覚えていた部分を固めていくという感じ。

 

予習第1回の今日はOnCollision系列とOnTrigger系列について書いていきます。

 

・Collision系列

OnCollisionEnter(Collision collision)

OnCollisionExit(Collision collision)

OnCollisionStay(Collision collision)

・Trigger系列

OnTriggerEnter(Collider collider)

OnTriggerExit(Collider collider)

OnTriggerStay(Collider collider)

  

この2つの関数の違いですがOnCollisionの方は衝突時に対応した処理を行うというもので、OnTriggerは衝突させずに対応した処理を行うというものです。

 

実際に違いを見てみましょう。

 

まず適当にUnityのプロジェクトを3Dで作って適当な大きさのSphereとぱっと見で「床だな」とわかるぐらいに伸ばしたCubeをSceneに置きます。分かりやすいように色付けときます。

f:id:mkp0824:20170418041713p:plain

色遣いがセンス無いとかは気にしないで。

 

そしてSphereにRigidbodyをアタッチする。当然、再生するとSphereは重力を受け落下し、Cubeに衝突すればお互いコライダーがついているので止まります。

 

という訳でこれで2つのオブジェクトが衝突しましたのでCubeにスクリプトを追加しOnCollisionEnter、つまり衝突時に呼び出される関数を記述していきます。

 

 

 

これだけ書いて再生してやると

f:id:mkp0824:20170418050251g:plain

 

 ロイロ君のロゴが邪魔なのは置いといて、当たった瞬間にConsoleの方にデバッグログが表示され関数が呼び出されていることが分かりますね。

 

さてじゃあOnTriggerEnterはどういう場合に使うのかですが...

 

はっ!?すっげえ時間になってる!?(現在5時18分)

 

という訳で、あんまり記事を分けたくなかったのですが当然の如く今日も学校なので次の記事に回したいと思います...

あと、OnCollisionEnterしか解説してないので他のも次に回します。

 

というか予習とかいいながらすっごい初歩的なことやってることに気づきましたが、自分の理解の甘い部分を埋めていってはいるので許してやってください。

 

今回はここまで。

ただの自分語り

唐突な自分語り。私は高校生の頃なんとなく、将来普通のサラリーマンになるのが嫌で2年の時に好きだったゲームを作りたいと思い今の学校に入学しました。そう決めてからはそれなりに勉強もしました。

ですが、正直なところこの時は軽い気持ちで考えていたというのが事実です。今もそうかもしれません。

そして、今までそれとなく感じてはいたことなのですが「自分は本当に真剣になれているのか」という点です。こうやってここに書いてどうにかなるわけではありませんが、どっかんナゴヤでLTの方々や企業様のお話を聞いているうちに入学から1年たって、多少技術が上がっても未だに自分の意識に大きな変化がないことに焦りを覚えました。

 

という訳(どういう訳だろう)で最近「毎日ブログを書く」という目標を立てた私ですが変更します。

「毎日、プログラミング関連での1日の成果を記事にする」

真剣になれないなら無理やりにでも。ここまでしないとやらない自分に苛立ちを覚えますが、宣言した以上は明日からまた頑張っていこうと思います。

 

ここまで書いてやたらポエムっぽくなっているのに気づいて前半消そうか迷いました。

 

今回はここまで。

どっかんナゴヤに行ってきました1

こんばんは。と書こうと思ったのですがこの記事を書き終わってから見直しているときに時計を見たら「あっ」となったのでおはようございます。と直しておきます。

今回はタイトル通り新栄で行われたどっかんナゴヤに参加してきたので色々書いていこうと思います。

・どっかんナゴヤとは

dcn.connpass.com

こちらをご覧ください(投げやり)

 

という訳で企業様の講演3つとLT(ライトニングトーク)を聞いてきました。

情報量がめちゃくちゃ多かったので書きたいことは山ほどあるのですが、今回はマイクロソフト様、Unity様、CRI・ミドルウェア様の講演内容について書いていきたいと思います。

 

日本マイクロソフト株式会社 鵜木 健栄様

VR/AR/MR/HDRゲームグラフィックスについて

正直なところ、今の私の知識では講演の内容を完全に理解することは到底かないませんでしたが、Windows10 Creators UpdateHoloLensに興味が湧いたので書きます。

まずCreatora Updateの方ですが、講演の中で気になったのはGame modeです。

・Game mode

私はPCで要求スペックの高いゲームをすることがあまりないのですが、PCゲーマーの方にはとてもうれしい機能だと思います。どういうものなのかというと現在動作中のゲームに、優先してCPU、GPUを割り当てるというもので、お話によると5%ほどパフォーマンスの向上が見込めるそうです。

Windousストアで配信されているものだけではなくデスクトップアプリでも有効なようですね。

ここまで書いて思い出しましたがそういえば自分のPCにもWarframe入ってました。(手が小さいせいで)操作が難しすぎてなかなかやってなかったのですが、週が明けたらCreators Updateかけてやってみようと思います。

 

ここからはHoloLensについて

f:id:mkp0824:20170416031816j:plain

ご存じかと思いますがこんな見た目です。

HTC VIVEなどと違ってケーブルが必要ないのでプレイヤーが自由に動き回れるのが特徴です。

あと調べてみたところHoloLensは現実世界を3Dホログラムに混ぜ込んで表示が可能なようです。一体どうやっているのか見当もつかないです......で終わってしまってはいけないので触る機会があれば触って、ぜひとも自分で味わってみたいですね。

とはいえ、お値段が高い!33万円!しかも開発者のみ対象!遠い!道のりが遠すぎる!

というわけでVRへの興味が一層強くなった私でした。

 

 

株式会社CRI・ミドルウェア 櫻井 敦史様

CRIWAREでゲームサウンドを作り込む

「CriAtomCraft」使わせていただいています。でも私は馬鹿でした。なぜこんなに便利で理にかなったものをただただ音声素材を圧縮して流すだけのものとして使っていたのか。

という訳で本日の講演で聞いた私が衝撃を受けた機能について箇条書き+解説で上げていきます。

・連続呼び出し禁止時間の指定

例として挙げていただいたのはオブジェクト同士が衝突した時の効果音の再生。これに連続呼び出し禁止時間を指定してやればフレーム毎に再生されて音が壊れる、ということは避けれます。

・ランダム再生

例えば、あるゲームでキャラボイスを再生するボタンに複数のセリフが設定されていた時にその複数の中からランダムで再生したいときとか。

ダッキング演出

上記の、キャラボイスが再生されている状態ならBGMの音量を下げるとか、ゲームクリアのSEが流れているならプレイ中のBGM止めてねとか。

 

これ全部、プログラマコード書かずにキューを呼び出すだけでできます。

 

 

嘘やろ?と思いました。めっちゃ前のめりで聞いてました。メモするのを忘れるぐらいに。

 

もちろん、経験が浅いうちは自分でコードを書いて制御するのも大事ですが、ある程度慣れてきたならばどんどん使っていくべきだと思います。

更に利点を挙げますと音声素材の制作側がこの制御を行えば制作側が意図した形でゲームに反映される。これがすごく大きい利点だと思います。

これ知らなかったのめちゃくちゃ後悔しています。自分のPCに入っているソフトウェアぐらい使いこなせよと...

これ以外にもまだまだできることはありますが「これ知らないのもったいなさすぎる」というのを抽出して紹介しました。

といっても、まだまだ自分の知らないだけで他のソフトウェアにも便利な機能はたくさんあると思うので余すことなく使えるよう精進していきたいと思います。

 

 

ユニティ・テクノロジーズ・ジャパン合同会社 鎌田 泰行様

GDC行ってきました報告とゲームアプリマネタイズの最前線

 

まず最初に最近のアプリはリテンション(寿命)が低い。

だから質の悪い広告などで一発屋のようなゲームが量産されている、という話をしていただきました。

自分は主にスマホゲームを良くプレイしていて、目指す方向もそちらなのですがアプリの寿命が短いというのはトップセールスのランキングなどをよく見ていると顕著に表れているのを確かに感じており、スマホアプリに将来性を持たせるにはどのような工夫が必要なのかと考えていたりもしました。

その中で講演していただいた「マネタイズのプロトタイピング」について書いていこうと思います。

 

・何を売るのかはっきりさせる

言わずもがな、作り手側が絶対に理解していなければいけないことだと思います。ガチャであったり、スタミナの回復であったり。

・消費ポイントを自然に組み込めるか,再現性があるか

個人的にはここが一番大事だと感じました。ゲームをプレイしていく中で、いかにプレイヤーに課金が必要だ、あるいはしたいと感じさせるか。またそのような状況を繰り返し起こさせることができるかですね。

・本当に購入可能にするべきか

あるアイテム購入可能にすることによってあまりにもはやい速度でエンドコンテンツに到達してしまう。あと個人的な考えですがユーザーの個性が失われてしまうとか。やはりゲームというのは沢山のプレイヤーがそれぞれ違う方向からアプローチをかけて攻略していくのが面白いのであって皆が皆同じ方法でクリアできる一辺倒なゲームにしないためにはここは難しいラインだと思います。

・拡張性はあるか

最初は面白かったけど、途中からやることが同じようなことの繰り返しになると、やっぱり飽きます。そこで無理やり新規コンテンツを追加してもだいたいの場合は上手くいかないと思うので、やはりある程度早い段階で拡張していく部分は考えておくべきだなと感じました。

 

これらのことがしっかり定まっていないといわゆる量産型の一発屋のアプリになってしまうと私なりに理解しました。

とはいえ完全に私見で書いたので「こいつなんもわかってねーな...」と思われるような点もあると思いますが、間違いなく、私はゲームマネジメントについて学ぶべきことは山ほどあるということを再認識させられた、有意義すぎる時間でした。

 

長々と乱文を並べてきましたが、今回の企業様の講演を聞いて私が感じたことは、「情報収集が甘い」ということです。専門学生になってから色々なイベントに自主的に参加してきましたが、まだまだ自分の意識改革を進めて、もっと知識に貪欲になっていかなければならないなと深く考えさせてくれたカンファレンスでした。

 

学生のうちにこういうカンファレンスに参加するのは間違いなく自分のモチベーションを上げてくれると思うので皆さんもぜひ。

 

それでは、今回はここまで。

チーム制作で失敗しまくった話(制作中編)

 

今回は、3.メンバーの技術レベルを把握しきっていないためなかなか作業が進まない

について書いていきます。

 

今回は自分がUnity経験者ということもあり難しそうな部分は自分が担当して、他のメンバーにはググってきたやつを改変すればなんとかなるレベルの仕事を担当してもらったのですが、自分の予想以上に割り振ったタスクを早く完了させてくるメンバーが多く、最終的には自分が最後の最後までコードを書き続けて、それに加えてタスクが完了した他のメンバーに任せれるような仕事がうまく見つけられずに、自分の作業量に苦しむというアホすぎる結果になってしまいました。

この失敗に関しては最初にタスクを完全に上げきって、隅々まで分担できていれば回避できた問題だったなと思います。

企画を決める際にはとてもスムーズに行った、というより今までの制作で企画に時間をかけすぎて失敗したことが多々あったので、それを嫌い早く進めすぎたのが問題かなと思います。

厄介なことに作り始めた瞬間には企画がガバガバなことになかなか気づかないんですね... 

ちなみにうちのグループはギミックに話が寄りすぎて、ちょっと冷静に考えてみたら「クリア条件なくね?」というひどい状態も起こりました。

そして作っている間に更にこれってどうするの?とか色々問題点が上がってきて、仕様変更してとかやっているうちにどんどん時間が削られ、しかしやることは増えていった結果、私自身が自分の事でいっぱいいっぱいになりメンバーに適切に仕事を振ることができないまま最終日の夜を迎え、1人悲しくカタカタとコードを打ち続ける羽目になってしまいました。

これはもう誰がどう見ても最初にしっかり企画を形にせずにタスク上げを中途半端に行った自分の責任ですね... なんで自分からわざわざ茨の道に進んでいっちゃうかなぁ...

 

というわけで今回の問題はメンバーの技術力の把握というより、メンバーの技術力の把握と自分のキャパシティの把握の両方がうまくできなかった結果の事故でした。地の技術力以上のパフォーマンスが出せる訳ないので自他ともにもっと細かく分担すべきでしたね。

 

もうちょっと書きたかったのですが眠気がひどいのと、本日4/15は「どっかんナゴヤ」に参加するため、今日はもう寝ようともいます。

続きは気が向いたらまた今度に。

今回はここまで。