KLabGames Tech Blog

KLabは、多くのスマートフォン向けゲームを開発・提供しています。 スマートフォン向けゲームの開発と運用は、Webソーシャルゲームと比べて格段に複雑で、またコンシューマゲーム開発とも異なったノウハウが求められる領域もあります。 このブログでは、KLabのゲーム開発・運用の中で培われた様々な技術や挑戦とそのノウハウについて、広く紹介していきます。

はじめに

この記事は KLab Advent Calendar 2017 15日目の記事です。
こんにちは。S-Typeと申します。普段はプランナーをしている企画の人間ですが、何か書いてみたいと言ってみたところ参加させてもらえることになりました。
Google Home miniから勤怠メールを送る方法をまとめます。

勤怠報告は大変

季節の変わり目は体調を崩しがちです。無理してもパフォーマンスは上がりませんし、そういうときは休みましょう。
しかし、重い体を動かしながら、一生懸命勤怠メールを打とうにも誤字脱字が多発し、修正に時間を取られてしまう……なんてことはありませんか。

byouki_oldman

そこで、Google Home miniの出番です。
Google Home miniに勤怠を送ってほしいと、寝たまま声を発するだけで送ってくれる仕組みをご紹介します。

Google Home miniとは

Google Home miniは、Google アシスタントが利用可能なスマートスピーカーであるGoogle Homeの小型版です。価格も約半額の6,000円で購入することが可能です。
「OK, Google」もしくは「ねえ、Google」から会話を開始し、以降に続けた音声コマンドを実行してくれます。例えば「OK, Google. 明日の天気は?」と聞くと「明日の〜は最高気温〜、最低気温〜で晴れるでしょう」と回答してくれます。
その他にも計算式、radikoやNHKニュースの再生、タイマーや目覚ましアラームなど、日常においての頼れるパートナーとしての役目を担ってくれます。

IFTTTとは

IFTTTは、 If This Then That をコンセプトに生まれたウェブサービスです。
トリガーである【This】とアクションである【That】、それぞれ別々のサービスを設定し、連携させることができます。
IFTTTで特筆すべきはトリガーとアクションそれぞれに設定可能なウェブサービスが豊富にあることと、こうした流れを コードを書くことなく ユーザーが任意に設定できるということです。
そして、こうした設定をレシピと呼び、公開すれば多数のユーザー間で共有することが可能です。
今回は、このIFTTTのトリガー部分にGoogle Homeで利用可能なGoogleアシスタントを設定し、Gmailから勤怠メールを送ってみることを試してみようと思います。

IFTTTレシピ作成前の準備

では、さっそく、レシピを作ってみましょう。準備するものは以下の通りです。

  • Googleアカウント(Gmailで送る際に使用)
    • IFTTTに登録可能なGmailアカウントは一つだけです
  • IFTTTのアカウント

そして、処理の流れは以下の通りとなります。

  • This:Google Home miniに「今日は会社を休みたい」と言う。
  • That:Gmailから勤怠メールが送られる。Google Home miniから「お大事にして下さい」と返される。

レシピの追加

  1. IFTTTにログインし、My AppletからNew Appletをクリックします。

recipe_0

  1. この画面が表示されるのでThisをクリックします。

recipe_1

  1. Google Assistantをクリックします。探しにくい場合は検索で見つけましょう。

recipe_2

  1. Say a simple phraseをクリックします。
    これは「今日は会社を休みたい」という単一のフレーズでの処理結果が確定しているためです。
    今回は解説しませんが、今日ではなく明日だったり、休む理由を体調不良や私用など条件分岐させたい場合はSay a phrase with a text ingredientを選択します。

recipe_3

  1. Google Homeに話しかけるときのフレーズを指定します。
    対象の項目は
    What do you want to say?
    What's another way to say it? (optional)
    And Another way? (optional)
    以上の3つです。
    What do you want the Assistant to say in response? はどんな返事をしてほしいかを設定します。
    日本語で指示し、日本語で返してほしいので Language はJapaneseにしてください。
    ここまで終わったらCreate triggerをクリックしてトリガーの作成を終わらせましょう。

recipe_4

  1. 次にThatをクリックし、トリガーをきっかけに実行される内容を設定しましょう。

recipe_5

  1. Gmail をクリックします。

recipe_6

  1. メールを送りたいので、Send an emailをクリックします。

recipe_7

  1. メール送信にあたって必要な情報を埋めていきます。
    ここで設定しているのは以下の項目です。
    To address で送信先を、Subject で件名を、そして Body で本文を設定します。
    Bodyに改行を含む場合は <pre> タグで文章を全て囲わないと、改行されませんので注意してください。
    ここまで終わったらCreate actionをクリックしてアクションの作成を終わらせましょう。

recipe_8

  1. 最後にレシピの名前を設定します。デフォルトでIfから始まる文章が入っていますので、このままでも良いでしょう。
    Receive notifications when this Applet runs のスイッチはOFFにしておくことをオススメします。
    このスイッチがONになっていると、そのレシピが実行されたらその度にメールで通知されます。
    Finishで完了します。

recipe_9

検証

では、さっそく検証してみましょう。

前提条件

  • メールの送り元は私用のアドレスです
  • メールの送り先は社用のアドレスです

実践

私「ねえ、Google。今日は会社を休みたい」
Google Home mini「お大事にして下さい」
……しばらくしてから ピコン!(メールの着信音)

スクリーンショット

出来ましたね!!

recipe_10

最後に

今回はGoogle Home miniとIFTTTの連携によるメールの送信を紹介しました。
100%衝動買いだったGoogle Home miniでしたが、IFTTTのおかげで様々なウェブサービスとの連携が楽しめるので、無駄にはならなさそうです。
何よりもコードを書く必要がなく、GUIで入力項目を埋めていきながら設定が出来るため、私のような開発職以外の人間でも簡単に出来ました。

余談

Google Home miniを今後も活用していきたいので、nature remoを注文しました。
nature remoと組み合わせることで、音声による赤外線リモコン家電のコントロールが可能になります。
これが出来るようになると、寝たまま部屋のリモコン照明のON/OFFが出来るようになります。もう完全に未来ですね。
本稿を書くまでに届いていれば、そちらをテーマに書こうと思っていたぐらいでしたが、間に合わなかったため、またいつか別の機会で書かせてもらえたらと思っています。

初めに

この記事は KLab Advent Calendar 14日目の記事です。

こんにちは、クライアントエンジニアの norm81 です。

初登場です、よろしくお願いします。  

経緯  

Unityでナビメッシュのベイク情報をプレハブにしたい、そしてアセットバンドルで運用したいという要望がありました。

既存のA*アセットなどを検証していたところ、Unity5.6からNavMeshBuilderが強化されたのでそちらで実現可能か検証しました。 

静的にベイクしたデータを用いたサイトをあまり見掛けなかったので今回纏めてみようと思います。  

検証に用いたUnityバージョンは5.6.3f1です。

結論

いきなり結論になりますが、上記の要望は対応できました。  

但し、制限があります。  

今回の方法において注意点も見つかりましたので、併せて下記に記載しています。  

導入

下記をクローンし、対象のプロジェクトに入れます。

https://github.com/Unity-Technologies/NavMeshComponents/

Assets/NavMeshComponents/フォルダをコピーしてねと書かれてますが、  

今回はAssets/Examples/フォルダも用います。  

手順

基本的には既存にあるナビメッシュの作成の通り、設定を行なっていきます。  

但し、Bakeは別途行うのでこのタイミングでは行いません。  

  

ヒエラルキーでナビメッシュの対象にするRendererコンポーネントを持つオブジェクトの親に、一つ空オブジェクトを作成します。  

そしてAssets/Examples/フォルダに入っているNavMeshPrefabInstanceコンポーネントをAddComponentします。  

01

そのオブジェクトを含むプレハブを保存した後にインスペクタのSelectボタンを押す、或いはプロジェクトウィンドウから保存したプレハブを選択すると、入れ子にあるオブジェクトが表示されます。

そのままNavMeshPrefabInstanceコンポーネントを持つオブジェクトを選択して、インスペクタのNavMeshPrefabInstanceコンポーネントのBakeボタンを押します。  

するとプレハブにNavMeshが追加されます。

確認 

Navigationウィンドウを開き、Show NavMeshを有効にした状態でWalkableのメッシュが表示されていれば成功です。

02

表示されていない場合、追加されたNavMeshを確認してみてください。Source BoundsのExtents値が(0, 0, 0)だと失敗している可能性が高いです。

03

下記の注意点を確認いただき、再度上記のBakeを試みてください。

成功した後は、このプレハブをアセットバンドルにすればそのまま運用可能です。

具体的な挙動については、上記NavMeshComponentsのソースコードを参考されることをオススメします。

注意点

NotWalkableを反映したナビメッシュがBakeできない。

従来のNavigationウィンドウでのBakeとは異なり、差集合のベイクがなされないです。  

対案としてMeshColliderを併用して目的座標に対して上空からのRayCastで判定を行い進入可能か調べる様なような二段構えの対応を検討しています。

FBXなどModelImporterを介するMeshを扱う場合、Bake前にRead/Write Enableを有効にする必要がある。  

04

プレハブに保存した後に無効に戻すのは問題なかったです。  

まとめ

現時点の外部データ化するメリットは、

  • ランタイムでベイクしなくて良いので処理コストが軽減できる。  
  • 1つの背景データと複数の外部データ化したナビメッシュを組み合わせることで、クエスト進行度などに併せてナビメッシュを切り替える運用ができる。  

といったところで、デメリットは注意点で記載したとおりになります。  

今回紹介した機能は折角の標準搭載された機能なので使い倒してみたいと思います。

以上

この記事は KLab Advent Calendar 2017 10日目の記事です。

こんにちは。このブログでは4度めまして、kakkun61 です。

この記事では、10月22日に開催された同人誌即売会技術書典3に KLab の有志で作った同人誌を頒布しましたので、その報告をします。

頒布した同人誌は電子版が無料で、この記事の下部にダウンロード用のリンクを張っています。

技術書典とは

技術書典は、プログラミングについての同人誌を作成しているサークル TechBooster達人出版会が主催する技術・科学系同人誌即売会で、今回含めナンバリングイベントが3回、超会議での超技術書典が1回開催されています。

今回は秋葉原のアキバ・スクエアで開催され、ユニークの来場者数では2750名とかなり大規模なイベントとなっています。

なぜ参加することにしたか

発案は筆者で、筆者は技術書典1と技術書典2そしてその間のコミックマーケット91とで Haskell の同人誌を頒布して同人誌を作る楽しさみたいなものを感じていたことと、KLab のアドベントカレンダーは過去2度ともすぐに枠が埋まってしまっていたので、社内に書きたいと思っている人がある程度いるのではないかと思い、会社に相談し会社として参加することになりました。

どう作ったか

TechBooster の『技術書をかこう!』にしたがって Re:VIEW を使い、GitHub 上で Pull Request 運用で作っていきました。

各章を1人で担当し、章ごとに PR を作成しレビュー後マージという運用をしました。ふだんのソースコードの開発と似せた方が分かりやすいかと思いこのようにしました。

どんな同人誌になったか

表紙

7名で執筆し、校正の協力に1名、表紙の協力に1名という体制のメンバーになりました。

内容は下記です。

  • 物理ベースレンダラーを Rust 実装して、表紙絵をレンダリングした話
  • Sprache を CPS 変換
  • Emscripten で動画再生する
  • テキストマクロプロセッサ「M4」のチューリング完全性
  • FPGA 初心者が試行錯誤しながら疑似乱数生成回路を作る
  • 家庭内ネットストーカーシステムを作った
  • とある KLab のスマホアプリのビルド事情

特にジャンルなどは指定せずみなが書きたいことを書いてもらったのですが、直接しごとと関係あるものは「とある KLab のスマホアプリのビルド事情」のみで、他は各々好き好きな内容になりました。

参加してどうだったか

さいわい印刷した冊数の7割ほど頒布することができました。印象としては KLab だからというよりは、内容で購入してくれていたように思いました。どれもコアな内容なので一部の人には刺さっていたようでよかったです。

メンバーでのふりかえりで、一般にも役に立ちそうなことを下記に抜粋します

ぱっと見てどんな内容の本か分からない

雑多な内容でタイトルに何も情報がないのでどんな本か分からなかったのは失敗でした。表紙に概要を書いたり、内容を書いたものを机に立てるなどしようと思います。

カラーのフェルトペンがあるとよかった

上の項目にも関連して、現地で札などを立てることになったときに黒ペンしかなかったので、見栄えが悪かったです。

人だかりができると立てたものは反対に見にくい

宣伝に札を立てたりしたのですが、人が近くで立って机を見たら上から見下ろすことになるので、そのときは紙を置く形の方がよかったです。机の前に人がいるいないで立てと寝かせとをうまく変えられるとすごくいいと思いました。

レビューに PR を使うことについて

今回は GitHub で PR を作る方式にしたのですが、いくつか問題に感じることがありました。

  • 書きかけの状態で全部の章を合わせてビルドするのが PR 方式だとやりにくい
    • マージしたブランチを作成しないといけないため
  • レビュワーが PR 上で指摘するのはリードタイムが長くなるので、明らかに問題のない修正はレビュワーが直接書きかえたかった

次回は、著者が直接 master にコミットし、レビュワーも直接コミットして訂正する方法を試そうと思います。

余談

調査不足でブースが隣りの Wantedly の書籍と名前かぶりしていました。「Tech Book ください」と言われて「どちらの?」となることがありすみませんでした。あちらの方が技術書典1からその書名を使っていらしたのでこちらがかぶせてしまいました。

電子版

ダウンロード

↑このページのトップヘ