適当おじさんの適当ブログ

技術のことやゲーム開発のことやゲームのことなど自由に雑多に書き連ねます

Unite 2017 Tokyoに初参加してきました

5月8日、9日と2日間に渡って開催されていた Unite 2017 Tokyo に参加してきました!人生初Uniteです! 会場にいた時間すべてが楽しく感じられました。Day1のながーーーい受付行列さえも、Unityユーザが今まさに一同に介しているのだと思うと興奮に変わりました。そんな Unite 2017 Tokyo の発表資料は以下のページで参照できます。 events.unity3d.jp

Twitterで、ハッシュタグ #Unite2017Tokyo をつけたツイートがたくさんされているので、そちらを眺めるのも面白いです。

ピックアップ

ゲーム製作歴が浅い私にとっては、すべてのセッションが新鮮で面白く感じました。その中でも、私が特に面白かったセッションをピックアップします。

Unity UI最適化ガイド 〜ベストプラクティスと新機能

www.slideshare.net

最適化が十分でないUIに少しずつ修正を施して、少しずつ最適化していくデモを披露してくれました。スライドではその過程を見られないので、動画がおすすめです。「Bitbucketにあるソースコードを見てね」と定期的に言っていたのも印象的でした。コードレベルで何が起きているか理解しておけば、更なる最適化への一歩が踏み出せそうです。昨日から早速少しずつ目を通しています。

bitbucket.org

いかにして個人制作ゲームで生きていくか〜スマホゲームレッドオーシャンの泳ぎ方〜

www.slideshare.net

これまでなんとなくで捉えていた物事が、1つ1つ紐解かれていくような感覚に陥りました。セッションを聴き終えると、まるで説法の後のような、妙にスッキリとした感覚になりました。ブランディングに関する話が、特に印象に残っています。

最適化をする前に覚えておきたい技術

www.slideshare.net

こちらは発表資料を後から見ました。Profilerの使い方など、Unityにおけるパフォーマンスチューニングに必要なことが非常にわかりやすく整理されていて勉強になりました。動画の公開が待ち遠しいです・・!

Unityで楽しむノンフォトリアルな絵づくり講座:トゥーンシェーダー・マニアクス

www.slideshare.net

難しそうという理由でシェーダーに関するセッションを避けていましたが、トゥーンシェーダーという言葉に惹かれました。 シェーダーに関する知識はまったくないので不安でしたが、却って、すべてが新情報で非常に面白かったです。シェーダー関連のセッションは他にもいくつかあったので、それらも後で見ておこうと思います。UTS2も使ってみたいなぁ。

好きなゲームを作り続けるために、僕らは何をすべきか

これはDay2のランチタイムに行われたトークセッションです。 https://madewithunity.jp/info/unite-2017-tokyo-day2/

インディーゲーム開発者の方々の生の声を聞ける非常に面白いセッションでした。トークセッションが終わった頃には、ゲーム製作意欲がとんでもないことになっていました。トークセッションについては動画公開されるかどうか不明です・・・されるといいなぁ。

(※動画はありませんでしたが、 まとめ記事が公開されていました!)

補足

タイムテーブル上で資料公開されていない「魔法使いプリキュア!」EDでのUnity映像表現の詳細解説」は、4Gamer.netさんに記事があったのでこちらからどうぞ。

www.4gamer.net

まとめ

Unite 2017に参加して、興味・視野の広がりを感じました。ゲーム製作に関する情熱がより強くなったのも確かに感じました。 来年もぜひ参加したいです。

シーン遷移時に暗転するようにしたときのメモ 〜DOTweenとUniRxを添えて〜

DOTweenUniRx をやっとこさ導入しました。 はじめは勉強の目的で、しばらく便利なアセットを使わず実装をしていました。そろそろいいかな?と思い、これらを導入しました。控えめに言って最高です。

今は勉強のために、DOTweenとUniRxでいろいろな処理をがむしゃらに書き換えているところです。シーン遷移時の暗転処理はその1つです。色々なところに適用してみることを目的としているので、あまり良くない使い方をしてしまっているかもしれません・・・。

public class CustomSceneManager : DontDestroySingletonMonoBehaviour<CustomSceneManager> {
    private const float FADE_DURATION = 0.5f;
    [SerializeField]
    private Image image;
    private CanvasGroup canvasGroup;

    protected override void Awake()
    {
        base.Awake();
        canvasGroup = image.GetComponent<CanvasGroup>();
    }

    public void LoadWithFade(string sceneName)
    {
        image.raycastTarget = true;
        var process = SceneManager.LoadSceneAsync (sceneName);
        process.allowSceneActivation = false;
        process.AsObservable().Where(p => p.isDone).Subscribe(p => 
        {
            canvasGroup.DOFade(0f, FADE_DURATION);
        });

        canvasGroup.DOFade(1f, FADE_DURATION).OnComplete(() =>
        {
            while(process.progress < 0.9f){ /* 何か処理があれば */ }
            process.allowSceneActivation = true;
            image.raycastTarget = false;
        });
    }
}

ポイント

DontDestroyOnLoad

DontDestroySingletonMonoBehaviourはその名の通り、Singleton かつ DontDestroyOnLoad なMonoBehaviourです。元のシーンで画面を真っ黒にして、ロードしたシーンで真っ黒解除という動きにしたかったので、シーンを跨いでも維持されるようにしました。

Imageオブジェクト

uGUIのCanvasに画面全体を覆う黒塗りのImageを作成しておき、ImageにCanvasGroupをアタッチしたものを作成しました。CanvasGroupの透明度を変更することでフェードイン・フェードアウトを表現するようにしてみました。

f:id:subarunari:20170505234517p:plain:w200

Imageの透明度ではなく、CanvasGroupの透明度を変更するようにした理由は、将来的に文字やプログレスバーを暗転後の画面に表示しようと考えているためです。 暗転の始まりと終わりのタイミングで、Image.raycastTargetのtrue/falseを切り替えています。演出中にあらゆるクリックを画面全体を覆うImageオブジェクトで雑にブロックしたかったからです。

DOTweenとUniRxを使ったところ

透明度を徐々に変更するところに DOTween.DOFade を使いました。DOFadeは、CanvasGroupだけでなく、SpriteRenderer, Image, AudioSourceなどにも用意されています。指定したalpha値まで指定した秒数をかけて変化させてくれるので非常に便利です。1行でシンプルに書ける点も好きです。

UniRxは画面をだんだん明るくしはじめるタイミングをコントロールするために利用しました。だんだん暗くする処理は、暗くしたいタイミングで処理を始めれば良いと思うのですが、だんだん明るくする処理は、シーンの読み込みが終わったタイミングで始めたいなぁと思いました。なので、allowSceneActivationtrueにしたタイミングではなく、AsyncOperation.isDonetrueになったタイミングで明るくしてみることにしました。変に作り込むのは避けたかったので、 以下のように、AsyncOperationを AsObservable() して、処理完了フラグが立ったタイミングで画面が明るくなるようにしてみました。果たしてこれで厳密にできているのだろうか・・・。

process.AsObservable().Where(p => p.isDone).Subscribe(p => 
{
    canvasGroup.DOFade(0f, FADE_DURATION);
});

参考

  • progress と isDone には、以下のような仕様があるので注意が必要です。私もこの仕様に気づかずにしばらくハマっておりました・・・ただ、よく考えてみると、allowSceneActivation = false としていてシーンの有効化をブロックしているのだから処理が完了しないのも当然ですよね。 answers.unity3d.com

TODOという名前のTODO管理ツール

TODOという名前通りめちゃくちゃシンプルなTODO管理ツールです。特徴をそれぞれ書いていきます(2017/4/24時点の情報です)。といっても非常にシンプルなので読むより触ったほうが早いです。

todo.io

特徴

ユーザID・パスワードは不要

  • TODOリストを作ると、http://xxxxxxxxxx.todo.io/xxxxxxxxxx 形式のユニークなURLが生成されます。生成されたURLとTODOリストが対応づけられています。このURLをブックマークして使うのが良さそうです。余談ですが、現在は「xxx」の部分の文字長は10文字で固定のようでした。使われる文字は英数字がランダムに使用されるようです。
  • URLを忘れた場合の復旧手段はなさそうです。つらい。アカウント方式であれば、「パスワードを忘れた方はこちら」でなんとかなりますが、正当な利用者であることを保証するのが難しいので「URLを忘れた方はこちら」とはできませんしね・・・。

外部への公開用URLも発行される

  • リストの作成と同時に、http://todo.io/list/yyy 形式で公開用URLが発行されます。
  • 公開用URLの「yyy」と上述したURLの「xxx」はまったく異なるものになっています。何か法則はあるかもしれませんが、少なくともぱっと見で推測はできなさそうです。
  • 公開用はあくまで閲覧のみでそれ以外の操作はできません。

TODOとして書けるのはタイトルのみ

  • 説明文や作業過程を書いたりはできません。タイトルのみ書けます。
  • TODOに対して可能な操作は、追加、削除、並び替え、完了チェックくらいです。必要最低限。完了チェックされたTODOは次回表示時に、下の方にいくようになっています。
  • TODOを追加するボードは複数作成できます。
  • TODOの期日は設定できません。

 そのほか

  • 最近のWebサービスではもはや当たり前となっているWebhookを設定して気持ちよくなったり、ボード間のTODO移動などの定番(?)の操作もできません。
  • 言語は英語とドイツ語のみの対応です。

まとめ

TODOはタイトルのみ登録可能で、期日は設定不可なので、短期的ですぐに終わる用事を登録するのが良さそうな印象を受けました。晩御飯の材料買うとか郵便物出すとかそういった日常的な用事を登録するのに向いてそうです。

プロジェクトなどで多機能なTODO管理ツールを駆使している方々にとっては、なんだかできないことが多いなーという印象だったかもしれません。会社ではRedmine、プライベートではAsanaやTrelloを利用している私も乗り換えるかと言われると微妙なところです。それではなぜ記事にしたのか。

記事にした理由は、「サインアップ不要」であることに良さを感じたからです。私の知り合いには、ITに馴染んでいる人と全くそうでない人がいます。後者の人の中には、「ログイン」や「アカウント作成」に未だ抵抗を持っている人が多いです(抵抗を持っている人達に年齢の偏りはありません)。その人達に勧める上で、「サインアップ不要」という要素は、非常に魅力的な要素だと思います。生成されるURLがどれほどセキュアかどうかなど、別途、議論の余地があるポイントはあるかと思いますが。

余談

「ユーザとそのユーザが持つ情報を結びつけるためにアカウントが本当に必要かどうか」というのは深く考えていなかったポイントなので、それを考える良い機会になりました。

もしアカウントが必要なのであれば、本当にサービス固有のアカウントが必要かどうかも考慮が必要なポイントだと思います。GoogleTwitterなどでは、既存のアカウントでログインできるようにするための仕組みを提供しています。この仕組みで事足りるのであれば、それを利用したほうが良いとも思うのですがどうなんでしょう。

本題からだいぶ脱線してしまいましたが、以上、余談でした。

SHIROBAKOいまさらながら見ました

もう最高すぎました。モノづくりに対して色々と考える良い機会になりました。感想をだらだら書こうと思いましたが最高の一言だけで!

 

今、Amazonプライムで見放題なのでまだ見ていない方は是非!

「書くときに考える」のではなく「書くように考える」

最近、ブログを書き始めて思ったことです。

「結論を出せた!きちんと整理できた!」と、思考を中断してしまっていることがよくあると気づきました。この時点では"中断"という認識はなく、"解決"したという認識です。ですが、実際は"解決"ではなく"中断"です。もっと悪いと"放置"のこともあります。

そしていざブログを書き始めてみると、「もっと考える余地があるな」ということに気づきます。はじめから記事を書き起こしているつもりで考えるようにしてみようと思います。アウトプット前提だと効率上がるよ的なアレです。

アウトプットを前提にすることで得られる様々なメリットを認識しているつもりでしたが、自分が頻繁にアウトプットする立場になって初めて実感できました。これもまたなんとなく理解した気になっていて、"中断"もしくは"放置"していたのかもしれません。自分の考えとして落とし込めていることを意識する必要もありそうです。

考えていることを記事にするかどうかは別として、とりあえずタイトルにある思考法で頑張ってみようと思います。アウトプット前提!

「八百万の人の思い」的なモノの見方のススメ

はじめに 

八百万の神」という言葉、日本人ならほとんどの人が聞いたコトのある言葉だと思います。勉強嫌いで、ろくに本も読まなかった私が幼い頃から知っているくらい有名な言葉だと思います。「万物に神が宿るとし、それらを崇拝する」という感覚、すばらしいですよね。

今回の記事は、この八百万の神という崇拝スタイルに習って、「万物に人の思いが宿るとし、それらを考える・リスペクトする」ということを意識して物事を観察してみると世の中がもっと面白く見えるよ!という記事です。これを「八百万の人の思い」と呼んでいます。微妙に語呂が悪いですがそれは言わない約束。

きっかけ

私は最近、散歩にハマっています。目的は気分転換です。天気がいい日はそりゃもう最高にリフレッシュできます。

ゆらりと散歩していると、街の中にある様々なものが目に入ってきます。初めのうちは、それらを全く気にしていませんでした。風景を見るというよりは、安全に道を歩くための情報を取得しているにすぎませんでした。ウォークマンから流れるお気に入りの曲達やツイッターに意識を奪われていたからかもしれません。

ある日、ウォークマンを洗濯機にぶちこんでしまうという事件が発生しました。ウォークマンはもちろんお亡くなりになりました。「今日は曲なしだな・・・」という憂鬱な気分で散歩へ。悪いことは連鎖するもので、少し歩いてからスマホを忘れたことに気づきました。こうして、手ぶらで散歩することになりました。

そうすると、いつも意識していないものが自然と目に入ってくるようになりました。やがて、お姉さんが店頭ボードに色々書いては消し、書いては消しを繰り返していたのが目に入ってきました。店頭ボードに、その日のおすすめメニューやランチメニューを書いているようでした。このときに、モノに宿る人の思いの存在に気付かされました。それ以来、目に入ってくる様々なモノをどんな思いを込めて作ったんだろう」と意識すようになりました。

手書きのボード、道端にそっと植えられた花々、誰が見てるかわからない掲示板に貼られた様々なチラシ、バス停の脇に置いてあるおそらく近所の誰かが提供したボロボロの椅子などなど、人の思いが込められているであろう物が街中にはあふれています。もちろん家の中にもたくさんあります。私が今使っているMacbook、毎日使う調理器具や家具、世にある様々なソフトウェアやWebサービスなどなど・・・これらは、すべて人によって作られたものです。言われてみれば当然のことですが、ついつい忘れがちなことでもあると思います。

どんな効果があったか

どんな思いを込めて作ったんだろう」と意識するようになってから、街を歩くのが一層楽しくなりました。散歩だけでなく、旅行の際に観光地を練り歩くのも非常に楽しめるようになりました。実際には思いが込められてないものもあるかもしれません。それでも、「何かあるはずだ」と色々妄想してみるのは楽しいです。

いつもと異なる思考を巡らせる良いきっかけになります。異なる思考の強制は、気分転換にも効果バツグンです。思考を完全にリフレッシュすることで、より良いアイデアが思いつくことも何度かありました。

いろんなモノに注視する癖がつくので、アンテナの感度も良くなっていってるような気がします。

 

なんか面白そうだな、と思ったらぜひ試してみてください!

 

コードレビューに対する自分なりの考え方まとめ

はじめに

私はコードレビューするのもされるのも好きです。自分の知らないことをたくさん知れる良い機会ですし、それを簡単にみんなに共有できる場でもありますし、場合によっては熱い議論の場になることもあります。色々なきっかけを作ってくれます。

自分以外のコードレビューの内容をメールで届くようにして、それらすべてに目を通していました。その場でふむふむと思ってもいざ自分で書いた時に忘れてることもよくありましたが・・・無意味。

コードレビューの様子を1年間観察してみて、色々思うところがあったので、だらだらと書いていきます。コードレビューに対する自分なりの心構えや姿勢について書いています。具体的なコーディング規約に関する話は一切しません。具体的には以下のようなことです。

  • なぜを意識した指摘内容になっているか
  • レビュー対象はソースコードだが、それを見るのは人間
  • レビューは本当に人がやらなければいけないのか
なぜを意識した指摘内容になっているか

「なぜその修正が必要か」を書かずに「このように修正しなさい」だけ書かれた指摘をよく目にしました。

プログラマになってまだ日の浅い人やプロジェクトに配属されて日の浅い人は、指摘された理由がわからないこともあります。指摘されたからとりあえず直すという状態になってしまうと、せっかくの学習機会が失われてしまいます。自分で調べて自己完結するのも良いですが、コードレビューという対話の機会を活かすのも手だと思います。

理由を理解せずに修正した場合、誤った修正をしてしまうことが多いです。誤った修正をすると追加の修正に余計な時間がかかるだけでなく、精神的ダメージも大きいです。理由が理解できていると修正が的確になることに加え、議論が深まりやすいです。議論の末、より良い修正案やコーディング規約の変更などに発展することもあります。これはすごく良いことだと思います。

指摘する側は、理由を書くことを意識し、指摘される側は、理由が書かれていなければ質問する、といったようにお互い意識することが大事かと思います。

レビュー対象はソースコードだが、それを見るのは人間

テンションが下がってしまいそうな言葉使い・口調の指摘を何度か目にしたことがありました。

レビューの対象はソースコードですが、指摘を確認して修正するのは人間です。指摘事項を読んだ人のテンションが下がったり、嫌な思いをしないかを意識するのは大事だと思います。コードレビューが気分が乗らないものと認識されてしまうと、前述した議論の発展はほとんど望めないと思います。

ちなみにですが、これは指摘を控えなさいということではありません。指摘することはしっかり指摘して、それが嫌な思い出として残ってしまわないように配慮しよう!ということです。

そのレビューは本当に人がやらなければいけないのか

プロジェクトごとにコーディング規約があるかと思います。コーディング規約には、「少し細かいことだが、そのプロジェクトでは必要とされていること」が定められている場合もあります。

些細な指摘の内容によっては、レビューする側もされる側もうんざりしてしまうことがあります。コーディングは楽しい作業であるはずなのにうんざりした気持ちになってしまうのは悲しいです。些細なことだとそれが何度か繰り返されることもあります。何度か繰り返されると、繰り返した分だけうんざりしてしまうわけです。

「そもそもその規約が必要なのか?」をまず考えると思います。不必要であれば規約から排除してしまえばいいと思います。必要だと判断される場合はそうもいきません。必要であれば、それを機械に任せられないかどうか考えます。一般的なコーディング規約であれば、世にある様々な便利ツールやLintを使えば対応できます。コードをコミットする前にツールにかけて規約から外れている箇所を検出し、それを修正する。これであれば、自分で完結しているのでストレスにならないかと思います。

しかし、プロジェクト特有のコーディング規約の中にはツールでフォローできないことも多いかと思います。C#であれば、RoslynのAPIを使って独自の静的解析ルールを拡張したりもできます。独自の静的解析ルール追加にはそれなりにコストがかかります。時間効率が良くなり、うんざりもしなくなると思えば、コストに見合う効果があると思います。

さいごに

精神的なストレスを緩和するような話が大半となってしまいました。毎日のように行われることなので、ストレスなく進められるかどうかは非常に重要だと思います。コードレビューが辛くなってしまうと、ただのプロセスの1つと捉えられがちです。これでは良いレビューはできないと思います。

変なことを色々と書いているかもしれませんが、これを読んで「コードレビューを幸せなものにしよう!」という意識が少しでも芽生えたなら嬉しい限りです。