null;しています)。長くなると、チャネルにベタでテキストが貼られると邪魔なことがあります。いう時はスニペット投稿です。普通に使う時は、書き込み欄の左にある+マークを押すと出てきます。これと同じことをUnityから行います。単純なメッセージ投稿と違うのは以下です。送り先がchat.postMessageでなく、files.upload。textでなくcontentに中身を入れる。filenameを指定することもできる。channelでなくchannels。単数形じゃなくて複数形。form);...(以下省略)...こういう具合になります。スニペットはファイルのアップロードという扱いなわけです。スクリーンショットを送るのも、ログを送るのも同様です。今度は任意のファイルを投稿しましょう。渡すものがバイト列(byte[])になるので、データの詰め方が変わります。中身はAddBynaryData()でfileに入れる。メッセージはinitial_commentに入れる。メッセージはinitial_commentに入れます。これで好きなファイルを投稿できます。スクリーンショットさていよいよスクリーンショットです。関数をコルーチン(IEnumeratorを返す関数)として用意する。WaitForEndOfFrame();で描画終了時に以後が実行されるようにする。受け取り側Texture2Dを生成。Teture2D.ReadPixelsで描画結果をもらう。ImageConversion.EncodeToPNGでPNG形式のファイルデータを得る。さっきの「任意ファイル投稿」で送る。コードはこんな感じです。任意ファイル送信関数で送る}WaitForEndOfFrameを使っているので、StartCoroutineで呼ぶ必要があります。自前でMoveNextしても正常に動かないでしょう。呼んでいますし、東京プリズンでも書いてあったのですが、必要なのかどうかがよくわかりません。(ApplyってGPUへの転送やミップマップ生成を予約するだけですよね?)。いえ今回実機では試してないので、もしかしたら書かないと動かないのかもしれません。その時は教えてください。運用さて、機能自体はできたわけですが、問題はこれをどう開発に使うかです。DebugSlackクラスとして用意しました。コードを眺めていただけるとわかるのですが、それほど小さくはありません。以下では運用のために行った工夫について紹介します。クラス設計クラスはMonoBehaviourではない普通のクラスです。_defaultChannel);}といった感じです。シングルトンでないかさてこのDebugSlackはどこからでも使いたい機能であり、インスタンスは一個で足ります。なるとシングルトンにしたくなりますが、ここではしていません。木から外れるシングルトンが嫌いなのです。切り出して単体テストしたくなったとします。DebugSlackがシングルトンなら、DebugSlackクラスなしではテストができません。空の実装を用意すれば本物のDebugSlackなしでテストができます。言え、シングルトンの「参照がなくても使える」という便利さは魅力的です。いう妥協が生まれます。そこには同名のBaseSceneというMonoBehaviourクラスのインスタンスがあります。「なんとかマネージャー」の多くはそのインスタンス変数としています。BaseScene.instance.soundManager.PlayBgm("hoge");BaseScene.instance.debugUi.AddButton("ボタン");といった具合にアクセスできます。このままでは切り出せないので台無しなんですが、利便性優先です。テスト時にBaseSceneもロードしちゃう方が楽だったりします。本当に切り出したくなった時に選択肢が残ります。BaseSceneを見ないように直すだけで済むからです。空の偽実装を用意すれば単体テストできます。何もかもがシングルトンだったら、もうどうにもなりません。まとめると、オブジェクトの所有関係を木に保つためいつか切り出してテストしたくなるかもしれないからの2点が、私がシングルトンをあまり使わない理由です。スクリーンショットスクリーンショットの関数は以下のような引数構成を持っています。0)メッセージが省略されれば、自動で機種とOS種別をつけます。SystemInfo.deviceModelとSystemInfo.operatingSystemです。onImageCapturedは、画面データの取得が完了した時に呼ばれます。これを復活させる処理などが考えられます。別に用意してあります。onCompleteは送信完了時の処理です。ポップアップを出したいならここに指定するのが便利でしょう。最後のwaitFrameCountは、画面データを取る前に何フレーム待つかを指定します。何フレームか待たないとデバグUIを消したことが画面に反映されないかもしれません。そのせいで決定的瞬間を逃す場合もあるかと思いますので、実際の環境で決めてみてください。ファイル名は時刻から自動生成しています。任意のテクスチャを送信する機能です。主眼はRenderTextureにあります。東京プリズンでは結構いろんなところでRenderTextureを使っているのです。その時の服の組み合わせを1枚のテクスチャに集めてしまうのです。次のフレームからはそれを使う、ということをしていたりもします。スマホ実機でしかバグらない場合は非常に厄介です。あればSlackに投稿してしまうのが良いでしょう。tex2d.EncodeToPNG();textureが引数でもらったテクスチャです。以前のバージョンではわかりません。そこで、まずそれがRenderTextureかどうか判定します。「画面に今それが映っている」かのようにReadPixelsでデータが取れます。コピーし、ここから受け取り用のTexture2DにReadPixelsする、という順序でデータを取得します。あとは任意ファイル送信と同じです。実機においてはこの助けを得にくくなります。スマホは狭いので、大した量は表示できません。蓄積すればメモリを圧迫します。そこに書きこむようにしました。ような使い分けがあります。これを端末から取り出すのは面倒ですから、当然Slackに送りたくなるわけです。複数のログをzipしてSlackに送る機能を用意していました。多くの開発では標準のDebug.Logを基本にしているでしょう。それをSlackに送る」というところまでとしました。コールバック関数を追加します。別のスレッドでDebug.Logしても来なくなるので、実用性は落ちます。差し換える方法もありますが、今の用途では適しません。文字列フォーマットの負荷も二重にかかります。コールスタックはError系でだけ吐くことにする。設定可能にしても良いかもしれない。Add(message);}MemoryLogHandlerも普通のクラスで、newして使います。その価値はないように感じます。何らかの方法でインスタンスが複数作られないようにしておく方が良いかと思います。シングルトンはその方法の一つです。イベントへの+=を用いているので、複数追加しても誤作動は起こりません。処理の本体はHandleLog()です。Add()で内部メモリに蓄積しています。そこにどんどん記録しているだけです。別のスレッドからも飛んできまので、中はスレッドセーフにする必要があります。