チャットUIを作る

5

　外に出たら雨だった。昼休み時間であちこちのオフィスからこぼれ出るように出てきたスーツ姿の人々で、通りは賑やかになる。歩行者用信号待ちでひしめく傘を避けつつ書店へと向かう。ネットで発売日を調べれば無駄足にならないことは分かっているけど、なんとなく発見があるような気がして定期的に通っている。

　店に着いて、最初にPC関連の棚へと向かう。相変わらずアンリアルエンジン関連の書籍は少ない。いつもと同じ顔ぶれだ。技術書などは勢力の移り変わりが激しいので見ていて飽きない。棚の許容量は変わらないので、新しいものが出てくると何かがひっそりと姿を消しているということになる。書棚のタイムラプス動画があったら面白そうだ。ひととおり巡って最後に文庫の棚へ向かう。途中の棚でも、何かステキなゲームのネタやらデザインのヒントになりそうなものに出会えれるかもしれないので、見るとはなしに見る。タイトルや帯の惹句なんかも目に飛び込んでくるものは、それなりに計算して作られているように思う。並べられ方や観察するだけでトレンドが見えてくるようで、本屋は面白い。今日はこれといって収穫はなかったが散歩としては十分満足できた。

　書店を出ると雨は相変わらず降っていたが出てきた時より空が明るい。帰るまでに止むかもしれない。

　フロアに戻ってくると、コンビニで買ってきたおにぎりを食べながらアンリアルエンジンを触る。時折カードゲームをプレイしているグループから叫び声が聞こえてくる。谷山田もそこに混じっているようだ。

　えっと、どこまで作ってたかな。フキダシのサイズを送り返してもらうところまでだったから、次はスクロールする部分だな。とりあえず動かすということはポジションを管理することになるから変数を用意する。座標を扱うので基本的にFloat型だ。

　アニメーションさせたいから、目的地と現在地用の２つ。

　いつも気になるのが、この単語の間のスペース。実際の変数名には半角のスペースは入っていない。

　小文字で始めても勝手に大文字始まりにしてくれさえもする。エンジニア文化に馴染みが無いメンバーでも読みやすく、扱いやすくなるようにという意図で設計されているのだろうか。逆にスペースが入ってない方が気持ち悪いという声が多いとか？それなりに手間を掛けてるはず。ぜひともアンリアルエンジンを作っているスタッフの話が聞けるなら聞いてみたい。公式のブログとかで連載してくれないかな。ぜひ日本語で。

　さっそくこの変数をつないでいく。まずは値を受け取って加算するところ。

　Print String ノードを置いていたところにつなぐ。フキダシからこのイベント経由で値が送られてくるので、そのたびに目的地用の変数に加算していく。フキダシが追加されるたびに目的地は先へ先へと進んでいくことになる。

　一方、現在地用の変数はEvent Tick で頑張ることになる。

  目的地から現在地を引いて、その距離の何％か を現在地に加算することで徐々に目的地に近づいていくやつ。近づくにつれて減速するような動きになる。ブログ『みつまめ杏仁』で何度か見たと思う。まずは 0.125 くらいでいってみよう。方向は下から上に移動させないといけない。0 から引き算するとマイナスの値にできるから、これを VerticalBox の Translation にセットしてやる。

　あとは、VerticalBox の位置を画面の下に配置しなおす。

　アンカーを変更して、

　Position Y を 0 にすればいい。

　よし、再生してみるか。あ、ついでにフキダシの文言も変えよう。

　なんか徐々にズレてきてない？計算おかしかったかな？

　あ、Set Padding というか Margin の分を足すの忘れてた。

　これでどうかな？

　なかなかいい感じ。

　ただこのままフキダシが足され続けると重くなりそうだから対策を考えないといけないな。今回巻き戻さなくていいので、スクロールアウトした部分は要らなくなる。ListView を使えばいいのか？確か詳しく書かれた記事があったはず。あったこれだ。

[UE4]UE4.20で追加されたListViewウィジェットについて｜株式会社ヒストリア

アニメーションはうまくいくかな。さっそく試してみよう。

　ふむ。まずはListVew の 中身にあたるのが フキダシWidget だから、こっちに Interface を追加するのか。UserObjectListEntryを探して・・・、あった。

　次は？

インターフェースのイベントであるEventOnListItemObjectSetを実装します。

　とあるな。こんな感じか？

　ブログではEntryWidgetが使い回され、みたいなことが書いてあるけど、

このイベントは、ListViewのスクロールによって使い回されるウィジェットの内容を更新するときに呼び出されるイベントです。更新する項目の情報を保持するオブジェクトが引数として与えられるので、そのオブジェクトに基づいてウィジェットの内容を更新する処理を実装します。

　そうか。ListViewの仕組みが何となく見えてきた。たぶんこういうことだろう。

　見えている部分のEntryWidget はスクロールアウトして消えるのではなく、EntryWidgetそのものは必要最小限のぶんが画面に残り続けている。そして中身であるところの “内容” だけが、どこかにリスト的に格納されていて、適宜見えているWidgetを選んで再セットされる。このとき再セットの指示をもらって “内容” を受け取るのが Event On List Item Obeject Set ということだ。だからこのイベントが無いと中身が更新されない。

　となると、フキダシWidgetと中身は１対１でない可能性がでてくるな。 なんだか今回のチャットUIには向いていない気がしてきた。とりあえず動くところを見てからにしよう。

　よし、このイベントを外して実験だ。接続を切っておこう。

　フキダシWidgetは一旦編集終了だな。

　次は表示側のレイアウトWidget。ListView を追加してと。とりあえず様子を見るために、キャンバスの真ん中に置いておく。

　List Entries のとこに、リストの中に並べる Widget Class だから フキダシWidgetをセットする。あれ？プルダウンに何もないな。となるとアセットから矢印ボタンでセットできないか試してみよう。

　ちょっと間があったけどできたっぽい。

　へぇ、プレビューしてくれるのか。これで表示範囲の調整ができるな。なんという心遣い。でも今回サイズが可変だった。

　ここまでできたら、あとはVerticalBox との入れ替えだけだな。

　ここは問題なさそう。

　次はリスト要素を追加する部分。VerticalBox に Add Child してるところだけど、どうやら Add Child ～ のノードが見当たらない。代わりに Add Item を使えばいいようだけど、やはり Return Value ピンが無いな。１対１じゃないのは確実だろう。Add Child～ という名前にしなかったのは差別化を図ったのだと思う。実際の意図はどうなんだろう。まあ、今回大して困るわけではないので、Set Padding を飛ばせばいい。ListViewの設定に Entry Spacing というのがあったし。

　再生してみると。

　なんと！Event Construct が動いてない？ フキダシWidgetの方に Hello を追加してみよう。

　動いてる？これって、どういう・・・

　ブレイクポイント 貼って Step実行してみるか。

　・・・

　PrintStringノードの次でエンジンがクラッシュ。

　とりあえずイベント使ってみようか。

　再起動したら、BreakPoint が Disable 状態にされていた。

　Removeしておこう。これは触れてはいけない闇に触れてしまったのか・・・

　Event Construct につないでいた内容を Event On List Item Object Set  に切り替えてみよう。

　これでどうかな。

　うまく表示された。中身の更新は確かに例のイベントがやってくれるみたいだけど、デリゲートが動いてない感じ。そうか、既に１対１じゃないからBindしても無駄ということか・・・。

　ListView もっと検証したい気もするけど、とりあえずこの辺にしておこう。まだまだ用意しないといけない機能もあるし。VerticalBox でプロトタイプを作りきって、処理が問題になるようだったら、改めてListViewで作るのを検討しよう。

　ふぅ、ちょっと休憩。

　いつの間にか昼休憩の時間はとっくに過ぎていた。コーヒーを買いに行こうと席を立つ。

　自動販売機の前でアイスかホットか悩んでいると、後ろから声を掛けられた。

「おつかれさまです」

　明るい声だ。

「おつかれさま」

　すかさず返す。別のプロジェクトでUIを担当している後輩の立木坂だ。

「今日はムンムンしますね」

　ムンムンって。

「相変わらず言葉のチョイスが不可解なやつだな」

　お金を入れてアイスコーヒーのボタンを探しながら言ってやる。

「雨降ってるからじゃない？」

「え、雨降ってるんですか？わたし傘持ってこなかった。やべぇ」

　ボタンを押すと氷が吐き出される音が聞こえてくる。

「そういえばアンリアルエンジン使ってるんでしたっけ？」

「うん」

「うちのプロジェクト、今どっち使うかで戦争が起こりそうなんです」

　戦争って、そんな大層な。

「どっちって？」

「ユニティかアンリアルか」

　アンリアルエンジンはハイエンドな印象からモバイル開発とは縁遠いと思われてるフシが強いが、ようやく選択肢として名が挙がるようになってきたのは嬉しい。とはいえプログラマが開発の主導権を握るプロジェクトでは、アンリアルは選ばれにくいというのも個人的な印象としてはある。プログラムを書けばいいのに何故ブループリントなんぞを触らにゃいかんのか？といった声も聞いたことがある。

　扉が開いて紙コップがライトアップされる。取り出して一口啜る。まだ氷と馴染んでなくてぬるい。

「確かモバイルタイトルだよね？」

　前にうっすら聞いていたのを思い出した。

「そうなんですよね～」

　コインを入れ お砂糖 ボタンを連打しながら彼女は答えた。そして、ホットのほうじ茶ラテのボタンを押すと、

「アンリアルに決まったら、イロイロ教えて下さいね。あんなことや、そんなことも」

　とにこやかな表情で言う。びくっと思わず体が硬くなった気がした。動揺を隠すように、

「別にいいけど、小野杉さんは？」

「あのお方はユニティ派ですね」

　出てきた紙コップをそっと取り出し、あちあちと言いながら答えた。

　狭い自動販売機コーナーでそんな会話を交わしていると、話し声が近づいてきたのでフロアに戻ることにする。共用スペースなので他のテナントの会社員たちも利用するのだ。立木坂と「じゃまた」と言って別れたあと、自席に向かう足が少し軽くなったような気がした。

チャットUIを作る

4

　ミーティング中に出た話はほとんど頭に入ってこなかった。珍しくいつもより短く20分ほどで解散となったが、早く続きを触ってみたくて落ち着かなかったのだ。何となくイメージはするものの、ブループリントは直接ノードを手で並べながら試行錯誤したい。どんな便利な道具や部品に出会えるか想像するだけでワクワクして気が逸る。終わるとすぐ席に戻ってきて再生。さっきまで触ってた感触を取り戻した感じがして落ち着いた。

　ふむ。下からせり上がるようにするためには、まずはVerticalBoxの位置を画面下に移動させる。そこからフキダシの高さ毎に、せり上げていく処理が必要だ。

　フキダシWidgetは、文字列を受け取って表示するだけだから、文字列をフキダシに流し込んだあと自身の高さを調べて返せばいい。それを返してもらったレイアウト用のWidgetがその高さを元に移動量を計算して動かしてやればいいだろう。

　まずは、フキダシから高さを返してもらう部分を作るか。

　フキダシから返事をもらうにはイベントディスパッチャーを使えばいいだろう。フキダシWidgetを開いてイベントディスパッチャーを追加する。名前は ed_resultHeight でいいかな。Inputsのピンを一つ追加して、返す値は整数（Int）じゃないだろうから Float型で。名前はとりあえず Height としておこう。

　これを、テキストをセットしているノードの続きに Call でつなぐ。

　このままだと、0.0 しか返さないのでランダムな数字を出すようにしたい。

　これで、60、120、180 の３種類を返すはずだ。いったんコンパイルして保存する。

　次は、レイアウトWidget側でイベントディスパッチャーの値を受け取る準備をしないとな。フキダシを追加するときに、CreateWidgetノードを使ってたからこのReturnValueピンからバインドしよう。

　ReturnValueピンからドラッグして bind と入力して検索する。

　あった。これをどこにつなごうか。この左右に振り分けてるのどうせいらないから、ここにしよう。

　値をもらって処理するのはイベントだから、カスタムイベントをつないで、PrintStringで確認してみよう。

　よし、これで再生だ。

　あれ？PrintStringは？動いてない？おかしいな、とりあえずBreakPoint貼ってみるか。

　・・・

　さっきと同じで変化はない。うーんなぜか止まらない。コンソールにも Error や Warning の類は出ていない。イベントディスパッチャーをCallしてるとこにPrint Stringを置いてみよう。

　どうかな？

　ここはちゃんと動いてる？

　そうか、こんなに華麗にスルーされているということはフキダシ側のイベントディスパッチャーのノードが処理されるタイミングだと、まだレイアウトWidget側のバインド処理が走っていないという可能性が高そう。であればバインド処理を前に持ってきてみよう。

　CreateWidgetの直後に置いたらどうなるか・・・

　ばっちりだ。これは次から気をつけないとな。

　自分だけ待ち合わせ時間を間違って記憶してて、遅刻して置いてけぼりくらってるのに気づかず「みんな遅いな」というシチュエーションがふと頭に浮かんだ。

　よし、少し前進。教訓も得た。次は、値を返す仕組みはこのままでいけそうだ。フキダシのサイズ調整を作るか。たしかブログで見た気がする。これなんか使えそう？

 limesode.hatenablog.com

　ふむふむ、まずはフキダシのベースになるテクスチャを作ろう。

　Photoshopでフキダシっぽい感じのイメージを作ってみる。ここからテクスチャ用にRGBと透過部分のアルファチャンネルを用意してTarga形式で書き出す。

　これをインポートしてUMGで使えるようにする。さっそくフキダシの下敷きにしていたImageにセットしよう。 Draw As を Box にしてMargin を 0.5 にすればOK。

 

　Imageは、サイズが可変だから、アンカーをタテヨコ両方向のストレッチにしておかないと。

　ストレッチにするなら、ぴったりフィットさせないと意味がないから、Offsetは全て０にする。

　Image は子供を持つことができないので、 Image と TextBlock 同士で直接干渉し合うこともできない。親である Canvas は子供の Size を反映することができる。したがって Image は親のキャンバスに合わせればよいということになる。Image は TextBlockのサイズなんかどうでもよくて、親のサイズにひたすら最大まで合わせればOKなのだ。

　TextBlock は TextBlock で流し込まれた自身の持つフォントの大きさとテキストの量で自動的にサイズが変わってほしいから、Size To Content にチェックを付けてやる。Canvas は、そんな TextBlock の可変を、さらに外側から暖かく寛容に包み込んでほしいので、Canvas の Size To Content も有効にしなければ・・・

　そうだった、一番上の階層にあるCanvasって Slot の項目がないんだった。 これじゃSize To Contentが有効にできない。しかたがないもう一段Canvasパネルで括るか。ついでに名前も整えておこう。

　UMGで配置したパーツは変数として扱うこともできる。グラフに置いた時に全部同じカラーで見た目に分かりにくくなるので、パーツの種別名を残して命名するようにしているが、我ながらナイスアイディアだと思う。

　アンダーバーが消えるのは何故だろう。フォントのせい？　これはこれで いいね してる人がいるからこの仕様なんだろうけども、誰か知っているなら明快な答えを教えてほしいものだ。

　で、Size To Content にチェックをつけると・・・

　うーん、テキストの大きさには追随してる感じだけど余白が無いな。

　テキストを変えてみる。改行も入れてみよう。

　ぴったりフィットしすぎだろう。余白付きでフキダシの真ん中に来てほしいからなぁ。ブログではブループリントで TextBlock のサイズを調べて調整してるけど、なんか他に方法ないかな。

　そうだ SizeBox を試してみよう。TextBlock を SizeBox の子供にして。SizeBox 自身にも Size To Content の設定をしておかないと。確か 子供の方に Padding の設定があったはず・・・よし、あったあった。

　おお、これはいい感じ！SizeBox ステキすぎる。できれば Canvas にこの設定があればよかったんだけどな。

　ヒエラルキーはこうなった。

 　あとは、この Canvas のサイズを調べてイベントディスパッチャーに渡せばいい。サイズを調べるには、この Force Layout Prepass を間に入れて、Get Desired Sizeか。

　さっそくテストしてみる。

　これじゃ、分からないな。ダミーのテキストを用意してみるか。

　こういう場合は、まず関数を一つ新しく作る。カウントアップする変数があるので、それをもらって返すようにしよう。配列型のテキストは、もちろんローカル辺変数にする。関数の中だけで完結するようにしておけば、他からの参照もないので要らなくなったら簡単に捨てられる。

 　エラーが出ても面倒なので、配列が用意されていなければ固定のテキストを出すようにする。

　さらにこの変数を ピュア型にすると使い勝手もよくなるはず。

　グラフに戻ってつないでみる。

　ピュア型にすると白いラインとは別のところに置けてスッキリするので便利。

　おお、なんかできてきた感ある。ログを見てみよう。

　それなりに値を受け取って来られているようだ。

　いい手応えを感じる。このまま今日中に作り切れるといいな。そう思いながら体を伸ばして軽くストレッチをする。ふと時計を見ると間もなく12時だ。今日は紀伊國屋に行かないと。午後からは VerticalBox を動かすところに進もう。

　人がばらばらと席を立って動きだす。自分もサンダルから靴に履き替えてフロアを出る。エレベーターを待っていると、どこからか雨の匂いがした。

つづく

チャットUIを作る

3　

　翌朝出社してメールをチェックすると、最近よく名前を目にするようになったDCCツール関連の案内くらいしか来てなかった。誰かがフロアに入ってくる気配がしたので振り向くと谷山田がこちらに向かってくるところだった。気だるげに挨拶を交わした後、

「昨日はあれからなかなか鳥囃子さんがつかまらなかったんスけど、何とか見ていただけました」

　と報告してきた。静かでなんとなく澱んだようなフロアの空気が、少しだけ動き出したような気がした。まだボンヤリした頭で訊き返す。

「反応は？」

「OKもらいましたよ」

「それはよかった」

　なんて淡々とした会話だろう。安堵したのは確かだが。まあ、これでバトンを受け取ったことになるのだから仕方がない。次に走るのは私で、彼ではない。テンションを上げるより、緊張する方が先に来た感じ。ここでようやく血が巡り出した感覚を覚える。

「鳥囃子さんにちょこっと言われたんスけど」

「はい」

　背筋を伸ばして返事をする。何だろうこの言い回しだとそれなりにツッコミを受けた感じだな。

「ちょこっとでいいんでLINEぽ過ぎるのなんとかならん？って」

　どきっとした。試行錯誤していないところを指摘された気まずさで口の中が酸っぱくなった気がした。

「何となく言われそうな気はしてたのよね」

　動揺を見せないように返す。ふと 谷山田にラフを見せた時に訊いた会話がよみがえる。彼はデザインについては目を向けていなかったのだろう。なんとなくその時の印象もあって、その時はデザインをいじるよりは仕様確認だからという言い訳を考えていたような気がする。どうせそのままという訳にはいかないのを分かってはいたものの、あそこまでデザインが出来上がった雰囲気を醸し出してしまうと、逆にデザイナーはこれで行こうとしている、という認識を持たれるのは今までの経験からも簡単に予想できたはずなのだが。

　一方でプランナーがExcelのシェイプで作った仕様書の場合、OKもらってからUIデザイナーがデザインに落とすときに解釈で悩むことが多い。プランナーの記号化に対するロジックや表組みの意味などヒアリングするなりして理解していないと、どこまでが仕様の範囲か拙いシェイプやどこかからコピペしてきたアイコンからは掴みかねるのだ。面倒だからと、ほぼ仕様書のまんまで見た目だけ整えて見せると、プランナーの性格にもよるが素直に喜ばれないことも多い。谷山田は頭の中のリファレンスとして、既存の画面イメージをLINEから持ってきていたので、ラフを見せたタイミングでは答え合わせとしては及第点だったのだ。このあたりは毎回チーム編成が変わるごとに小さいながらも対応を変えていかないと、ぼたんの掛け違いが起こりやすくなる。気を付けないと。

「他には？」

「他は特に言われてないっス。先に絵ができてたんで説明しやすかったっス」

　仕様がクリアできたのは谷山田のプレゼン能力はもちろんだが、少しは絵の説得力が助け舟として役に立ったということだろう。

「了解、まぁ見た目は追々考えるとして、さっそくモックを作り始めるよ」

「あざっす！よろしくお願いします」

　そう言って自席に戻っていった。

 　時計を見ると始業開始が近い。ようやくわらわらと人が流れるように入ってくる。始業開始と共に、フロアのあちこちで小さな朝会が開かれる。それが済むと自分の仕事時間がスタートするのだ。

　さて、実際作るとなるとどこから手を付けようか。スクロールさせるのは少しやったことあるけど、あまり自身は無い。最近ネットでもUMGのことを書いてるページ増えて来ているし、ヒストリアのブログでそれらしい記事を見かけた気がする。EpicGamesの猫アイコンの人がUMGの資料を公開してたはず、お気に入りのフォルダをいくつか開け閉めしているとブックマークを発見した。ひとまずこのささやかな安心感を胸にアンリアルエンジンを立ち上げようではないか同士諸君！などと無理やり自分自身を鼓舞してみる。

　テスト用プロジェクトのスプラッシュを眺めながら、まだほんのり暖かさの残ったコーヒーをちびちび飲む。カウントアップする数字を見ていると、ふと昔の風景が頭に浮かんだ。ゲームエンジンが無かったころは、画面のデザイン画を作ったらまずプログラマのとこに行って、パーツの構成と動きを相談しながらすり合わせて決める。そして可能な限り、テクスチャの差し替えと最小限の値だけで調整できるように知恵をしぼり、工夫してデータを用意する。頭の中でシミュレーションしたタイミングの動きや演出の流れを指定書に書いてプログラマに持っていくといった仕事のやり方だった。仮データ作成に１日、指定書に２、３日というのが普通な時代があったのだ。

　それが今は、アンリアルエンジンのおかげで指定書の類がほぼ不要になったのだ。

　まず基本的な最小限の動作をするモックアップを作り、仕様のチェックを経たあとは組み込んでもらって自分の席で動かしながら調整して仕上げる。といった工程で進めることができるので、表現の試行錯誤にプログラマを巻き込んで申し訳ない気持ちになることは無くなったが、その時にプログラマにゲームを動かす仕組みやらデバッグのコツなんかを教えてもらうことができたのは、今となっては貴重な体験だったとしみじみ思う。そんなセピアな感傷に浸っていると、いつもの画面が現れた。

 　StarterContents付きのプロジェクト。前にこのテーブルの上に乗っているオブジェクトについて暑い（×熱い）議論が交わされたことがあった。よく見ると、とても官能的な形状をしている。と、チームの誰かが言い出して、その後しばらく肯定派とそれ以外という何の足しにもならない派閥が生まれたことがあった。それはさておき、さっそくアセットを作ろう。

　まずはフキダシの並ぶ方向方法を考えてみる。やっぱり上から下に向かって伸びるイメージ？ Photoshopのタイムラインツールで、フレームアニメーションを作ってみよう。

　画面が埋まるまでしか違わないが、下から現れて上に消えていく方が素直な印象を受ける。新しいフキダシは常に下から、という印象付けができる。背景が動いていないせいもあるだろう。実際の画面でも背景とは連動しないので、下から積み上がっていく方を採用する。

　UMGには、縦に要素を並べるVerticalBox というパネルがあるのでこれを使うのがよさそうだ。これを試すために、フキダシパーツの簡単なやつを用意しよう。機能としては、四角の下敷きと順番を分かりやすくするための TextBlockがあれば十分だろう。

　コンテンツブラウザから、WIdgetを一つ生成してエディット開始だ。

　フキダシはパーツのひとつでレイアウトされる側ということになる。画面上の位置は特に気にする必要がないので、キャンバスの右上にあるプルダウンをDesiredにすれば余計なガイド線が出なくなるのでおススメだ。

Image を置いて適当な大きさにする。とりあえず 400ｘ100。ちょこっと半透明。

TextBlock を手前に配置。

 TextBlockは Is Variable にチェックを付けておく。

　ひとまずキャンバスはこのくらいでいいだろう。つぎはブループリントの編集に移る。

　構想としては、このフキダシ用のWidget にいろいろ情報を渡してからVerticalBoxに追加しようと考えている。情報を渡してもらうのはいつか？やはりCreate Widget した時の方がシンプルでよさそう。ということでText型の変数を一つ用意する。

　Instance Editable と Expose on Spawn にチェックを付けておくのを忘れないようにっと。あとはこの変数をTextBlockの内容を書き換えるために使えばいいだけだ。イベントは、このWidgetが生成されたときに実行されればいいので、Pre～ではなくこっちにつなぐ。

　ようし、こんなもんでいいだろう。保存して閉じて、次のWidgetを用意する。

　とりあえずVerticalBoxを置いてみる。上から下に向かって並ぶはずだから、いったん画面の上端に置くとしてセンタリングしたいから、Anchorはこれにしてみようかな。

Slotの内容は、Alignment の X を 0.5 にして中央に持ってくるようにして、横幅は広めにとって、おっとIs Variableが付いていないじゃないか。

　こんな感じでど真ん中に。

 　ふう。

　首と肩が緊張しているので軽くほぐす。VerticalBoxを置いたし、次はブループリントだな。まずフキダシに渡して表示する数字をカウントする変数を用意しておこう。

　で、次は外から呼ばれたらフキダシを生成する関数。ここはイベントでいいか。

ここから、CreateWidgetノードにつないで、VerticalBox に AddChild だ。

この型が違うピン同士でもつないでくれる仕様は便利。

　これでテストの準備は大体できたはず。仕上げはレベルブループリントでAdd To Viewportすれば。

　レイアウト用のWidgetを Viewportに追加して、スペースキーを押したらイベントを呼ぶようにする。

　これで再生してみよう。何か忘れているような気がするけど・・・。

　しまった。カウントアップ忘れてた。あと、スキマも空けよう。スキマは Set Padding ノードで。カウント用の変数は+1して格納しておけば、次回には変化した数字で渡されることになる。

　よし、これでどうかな。

　よしよし、それほど悩まなくもいいかもしれないという、甘い手ごたえを感じる。ちょっと左右の振り分けをやってみよう。

　Add Child ノードの Return Valueからそれっぽいノードを探す。レイアウト関連のキーワードと言えば Alignment だから、 Ali と入力すると、あったあった。

　水平方向だからこの Set Horizontal Algnmentノードを取り出して、

　Set Padding の後ろに挿入する。カウントアップは次に備えての処理だから最後でいい。このレイアウト変更はすぐに反映したいのだ。

　プルダウンリストで水平方向のどこに寄せるか設定することができる。濃い緑色の入力ピンは Enum（イーナム）型だ。ランダムのノードを使ってみよう。右か左かの２択だから・・・これにしよう Random Bool。 

　さてこれを何とかして、Enum型の Left と Right に錬金するわけだが、Enumは定義された順番を番号として扱うこともできる便利なやつなので、プルダウンに並んでいる順を確認してみると、上から Fill、Left、Center、Right となっている。

 　とりあえず、Left と Right  が設定できればいいので、１と３ か。ふたつの数字を扱うには Selectノードの出番だな。False と True に　１と３ を入れて。

 　まずは Bool（ブール）値 が Integer型に変化した。まだ Enum型のピンにつなげるにはもう一回型変換が必要だったはず。えっとなんだっけ。確か Byte（バイト）型だったっけ。To Byte(Integer) ノードでキャストして、

　たぶんこれでつながるはず。

　ばっちりだ。

　これで再生してみよう。Altキーを押しながらP。スペースキーを叩く。

　実際はフキダシの無い方には  ＞ がくるから、左右の振り分けはいらないな。絵的に左バージョンと右バージョンを作って、普通に Add Child するだけで良さそうだ。まあこういう手軽に試せるところがアンリアルエンジンのいい所。時計をみると定例ミーティングの時間が近い。何人かが立ち上がってフロアを出ていく。いったんここまでか。席を立ち肩を回しながらミーティングルームへ向かう。次はどこから手を付けようか考えながら。

つづく

チャットUIを作る

1

「おつかれさまです」

　後ろから声を掛けられ座ったまま振り向くと、プランナーの谷山田が立っていた。

「このあいだちょこっと相談させていただいたアレなんスけど」

　なんだっけ？記憶を辿ってみたけど急に思考を中断されたせいかすぐに出てこない。こちらが一瞬固まったのを見て

「観戦モードの・・・」

「あぁ！ チャット的なやつがやりたい、とか言ってたよね」

「ええ、あれからちょこっと考えたんスけど、LINEみたいにできないっスかね」

　谷山田は、今開発中の対戦ゲームで観戦モードを担当している。

　入社２年目にしてチームに配属されるも、話題が豊富でチームメンバーと打ち解けるのが早かったのを覚えている。社歴も浅く、チームに入ってそんなに経ってもいないのに、受け答えの正確さと、先回りして会話の流れを誘導しているところなど、すでに古参のような風格を漂わせている。クセのある先輩ばかりのチームだと、下っ端根性が抜けないヤツが多いのに、うまく立ち回っているのを見るととても頼もしい気持ちになる。話術の巧みさは認めるがゲーム開発の経験値ではまだまだ、というところを思い知らさねばなるまい。

　そんなカワイイ後輩プランナーではであるが、やたら「ちょこっと」というコトバを入れてくるので、ちょこっとクンというあだ名を流行らせようか本気で思っている。

「観戦中やることないんで、その瞬間の気持ちとか書き込めると楽しいと思うんスよ」

「そうね。それで？入力した文字が、画面に流れたりとか？」

　私が手をひらひらと水平に動かしながら言うと

「弾幕もちょこっと考えたんスけど、さすがにパクった感あるしちょこっと古いかなって。それと誰がいつ発言したか判らないのはチャットとは言わないかなって」

「チャットというと、テキストがずらずら～と」

　私が手をひらひらと下から上に動かしながら言うと

「そんなの喜ぶのオッサンだけっス」

　なぜ存じ上げておるのだ？

　まあこの辺にしておくか。とどめとして聞いておく。

「やっぱフキダシとか？ キドク とかついたりするやつ？」

「ええ、ちょこっとでも使い慣れたアプリの雰囲気が漂ってるだけで、いろいろ説明しなくてもいいしラクだと思うんスよね」

　こうやってさりげなく会話を進めながら仕様の確認も怠らない。どこまで許容できるのか、どのあたりまで見通しているのか、プランナーの頭の中のイメージを言語化させるのだ。彼らプランナーはじつに幅広く様々なゲームなんかを体験し蓄積している。それらを自分の考えたゲーム画面として頭の中でコラージュする。そのつぎはぎだらけのゲーム画面を見ながら話をしてくるのだ。そしていち早く今作っているゲームにマッチするかどうかを確認したがっている。

　もう最初にLINEみたいな、と言葉になっている時点でほぼ選択肢がないのは気づいてはいたが、とりあえず判ったこととして、古典的なチャットスタイルはもちろんダメで、ニ〇ニコ動画風もやりたいと言われたらどうしようか悩むとこだったがこれもNGだ。使い慣れたアプリといえば、日本では言わずもがなだ。あとはイマドキのメッセージ系やチャット系アプリを調べてデザインを何案か出せばいいだろう。あまり言語化され過ぎて、これから作るもののカタチが鮮明になってしまうと、デザインの案を出すのは易しくなるが、デザインの幅（＝遊び）が無くて、アイデアをデザインに落とし込む側としては面白くなくなる。ある程度の方向性を絞れたら潮時だ。

「わかった、とりあえずデザイン考えてみる」

「すんませんがヨロシクお願いします～」

　私は最初から企画資料はあまり重要視しない主義だ。軽い思い付きでいいから持ってきて、と常々言っている。ちょっとくらい陳腐だったり既視感溢れる企画でも、一度は餅の絵を描いてみせる。ここはなるべく時間を掛けずに手早く共有することが大事で、口頭で説明を聞き、会話をするようにビジュアルを作って反応を見る。間違いに気づかせたり、進もうとしている方向を確認させたり、自分自身の勘違いも正せたり、そこから新しい閃きや欲が出ることもある。ついでに今のプロジェクトのデザインスタイルを取り込んでラフデザインを作ると、完成形がイメージしやすくなって、こいつに任せておけば安心という印象を与えることもできるし、スケジュールを相談するときも聞き入れてもらい易い。

「じゃ、それで」となってからようやく細部のデザインやトーン＆マナーを整えてアートを監修する立場の人間と交渉すればいい。

　よろしくお願いされたので、さっそく資料を漁る。なんとなく予感はしていたが、似たようなチャット系のアプリはたくさん出てきた。どれも大して差が無い印象だ。表示に必要な情報が少ないのもあると思うが、意図的にアレンジの幅を小さくしているようにも思える。見た目で乗り換えのハードルを下げている狙いもあるのかもしれない。

　今回オーダーがあったのは観戦モード中のチャット機能だ。メンバー（Host）が部屋を立ててその部屋が解散するまでのもの。ログは見れた方がいいのかな？その場合検索機能は必要？通報機能は？ラフができたら後で確認しよう。

　開発中のゲームは、海外配信も視野に入れているので、カタカナではなく英語でも検索する。いくつかメジャーそうなのを眺めていく。アイコンがあったりなかったり。たいていフキダシがあって、自分だけ色や向きで差別化されているパターンが多い。

　困った、どれもだいたい同じ見た目だ。ということはちょっとくらい似ててもツッコまれない安心感はあるけど、どうせなら新しい感は出したいという想いがむくむくと立ち上がってくるのを感じるが、ここで悩んでいるのはよろしくない。まずはラフをサクッと作って報告しよう。まずはLINE風とのまんまコラボを見せて、ありやなしやを確認する。

それっぽいのができた。仕様の答え合わせなら画像を彼の席に送りつけるところだが、今回はアイデアをもとにブラッシュアップしたいので、自席に彼を呼ぶ。

 「おぉ、もうできたんスか？」

「フキダシの幅が一律なのはどのくらいまで隠せるかと思って、とりあえず」

サイズ調整が面倒だったというのは黙っておく。

少し考えこむ様子を見せてから

「・・・まんまッスね」

「いろいろ見てみたけど、どれも似たり寄ったりなんで。ここはスタンダードに倣おうかと」

「そうッスね・・・」

多少予測していたけど、何だろうこの物足りない感を露わにしたような間は。もう少し言葉を待ってみる。

「いや、思ってた通りなんでいいんスけど、」

画面をみつめたままで言う。なんとなく空気が止まってる感じ。

「まんま過ぎる？」

「そこは問題ないと思うんスけど、ちょこっと気になるとこがあって。」

なんだか歯切れの悪い感じのやり取り。

「どのあたり？」

「自分のコメントだけ離れているのって、仲間外れみたいじゃありません？あと、左に寄せたほうが読みやすいと思うんスけど、今回の対戦形式って画面の左右にプレイヤーが向かい合うように立つじゃないですか？フキダシを左右どちらかに表示するとしたらどっちがいいかなぁと思って」

なんだレイアウトが気になっていたのか。

「横画面で広いからね。レイアウトしてて気にはなってた」

そこでPhotoshopで自分以外のフキダシをいくつ２つほど選んで左右反転してやる。

「あ、いいかもですね！」

表情に明るさが戻ってきた。

「入力フォームはどこっスか？」

あ、忘れてたという態度を悟らせないように

「この辺でいいかと思うんだけど」

と左下付近を指でくるくる回しながら言うと

「左右に振り分けるのをいつやったらいいか考えてみたんスけど、入力フォームの位置を操作できるようにすると、操作の説明が必要になりますしね」

なるほど、私は少し考えて

「普段はフォーム自体はアイコンボタンにしてコンパクトにしておけば・・・」

「おお分かりやすいッスね！」

「真ん中で書いたあとで、左右どちらかに飛ばす、というのもいいかもしれない」

「ちょっと ボタン感 がないけど」

「なるほど～、これはこれでシンプルでいいですね。フォームの位置が安定してていい感じっス。ちょこっと中立のコメントも出したくなりますが。」

「さすがに画面中央はやりすぎだろ」

「ですね。左右にボタンがある方が、どっちもがんばれ～みたいな中立の発言はやりにくいけど発言のベクトルが分かりやすくなっていですね」

　書いてから考えるか、考えてから書くか。

「じゃとりあえず両方作ってみようか？」

「マジっスか！ぜひぜひ！」

　いい感じにまとまった感があるので、ここでいくつか控えておいた懸念を確認しておきたいが、プログラマもいた方が話が速いので呼びに行ってもらうことにする。

「南河原さんにも話ししておいた方がいいと思うんで呼んできてくれる？」

　南河原さんはプログラマで主にUI全体を取りまとめてくれている。いつもぼんやりした感じの雰囲気をまとっていて、必要最小限のやり取りで十分こちらの意図をくみ取ってくれるし、調整作業でも嫌な顔をせず付き合ってくれる。とても頼りになる先輩だ。積極的に話をするタイプではないようで、仕事以外の話題を交わしたことはない。こちらが年長者に対して気後れするとかではなく、いつも何となく話が転がらないだけである。ちょこっとクンに呼びに行ってもらってる間にフキダシの幅を調整しておこう。

 「呼んで来ました」

　画面を見せて改めて説明をする。

　・・・

　というわけで一通り話を聞いてもらった後、

「で、いくつか確認したいんだけど、顔アイコンいるよね？」

「この黒い四角のとこッスよね？無い方がいいとかっスか？」

「いやロビー画面とゲーム中とはメモリの余裕が違うんでプログラマに訊いてみないとなって思って。最悪 IDだけになるかもしれないんで」

　と私が言うと、南河原さんは腕組みをしたまま天井を見上げるように少し考える仕草をしてから

「うーん、観戦できる人数が16人から増えなければ・・・」

　ちらっとプランナーを見てから続ける

「たぶん大丈夫やと思う。ロビーで顔アイコンをキャッシュしてるし、それ使えるようにしとくワ」

「それと観戦からロビーに帰ってきたら、このメッセージってもっかい見れたりすんの？」

　あ、訊こうと思ってたやつ。

「リプレイが見れるんでそこで表示したらいいと思うんスけど、いけますよね？」

　谷山田が返すと南河原さんは少し考えてから

「じゃそれ」

　しれっと仕事増やしてくれているのが気に入らないけど、納得できたので首肯しておく。谷山田は一瞬嬉しそうな表情を見せたが、床に視線を落としながら

「実はヤバイ発言とかをどうしようかなっていうのはちょこっと考えてて、即座にアクション出来るようにするか、戻ってきてから振り返ってアクションするか・・・」

　と力なく言う。

　確かに、自由文の入力となるので不快な発言を放置できない。

「それな、禁止ワード対策はするとして、通報とかミュートの仕組みが要るんやったらUIも考えなアカンよね」

　と言いながらこちらを窺うように顔を向けてきた。

「そうですねぇ」

　と私が言いかけたところに谷山田が被せてきた。

「通報は即時対応がそもそも期待されてないと思うので、機能としては観戦中じゃなくても大丈夫だと思うんスよ。フレンドリストからでもいいのかなって」

　ここに負けじと私も

「ミュートはすぐに効果があった方がいいので、観戦中に操作できた方がいいと思う」

　口を動かしながら手はPhotoshopを操作する

「フキダシの横にアイコン載せたらどうかなって」

「ああ、ツイッターにあるやつですね」

「これなら、通報 とか いいね とかもできていいと思う」

　コンテキストメニューを作ることになってしまったけど、これでミュートと通報の機能を持たせられるし、いいね もできるし善しとするか。

「じゃこれで」

　南河原さんが腕組みを解いて言った。プログラマが「これで」と言った時は、もう頭の中でどういった処理が必要か、またどのような利害が予想されるのかなどの懸念を一通り検討した結果であることがほとんどだ。これほど頼もしい言葉があるだろうかというくらい強い一言だと私は勝手に思っている。

「もうちょっと整えてからこの画像渡すんで、仕様書の方よろしくね」

　と谷山田の方を向いて言うと、彼は晴れやかな顔して、

「了解っス！」

　この返事が合図になって緊急チャット画面検討会は解散となった。

2

　２人の背中を見た後、私は自販機のコーヒーを買いにフロアを出る。エレベーターのボタンを押してカゴを待つ間に、頭の中で先ほど出たアイデアのデザインを詰める。　　ミュートの表現どうしよう、フキダシを閉じるか？上からバツ印でも乗せるか？スミベタとかってできるかな？UMGでできたら面白そうだな。通報はサーバーに送信すると思うけど、ミュートってあくまでも個人的なものだからな、どこにセーブするんだろう。ちょっと不吉な予感がするけど、まぁ絵には影響なさそうだし、南河原さんが何とかするでしょう。扉が開いたので条件反射的に乗り込んで行先ボタンを押す。あ、そういえば ID を置くの忘れてた。フキダシの上あたりか、中だったら色を変えれば置けそうな気がする。フキダシを中に入れるとフキダシの面積が大きくなるし、メッセージの文字列よりIDの方が長くなることもあるだろう。やっぱりフキダシの外かな。

　目的の階についたので、コーヒーのボタンを押して出てくるのを待つ。ブーンガタガタという音をボンヤリと聞きつつ頭の中で画面を作っていく。

　フキダシが左右に散るとタイムライン感が弱くなりそう。縦のベクトルを維持するようなのが欲しいかも。ラインを引くと画面を切ってしまって狭くなるしな・・・これは戻ってから試してみよう。縦にスクロールするよな。フォームのエリアを確保しないとな。仮の顔アイコンもどっかから調達しないと。

　席に戻るまで細かい部分をイメージしていく。傍から見たら不気味に映ったことだろう。ボンヤリしたまま椅子に座りコーヒーが冷めるのも忘れてラフに手を入れていく。

　まずはアカウントアイコンを適当に拾ってきて重ねる。ユーザーIDも適当に考えたやつを入れてっと。手を動かしながら頭の中で独り言を言いながら進めていく

　よし、ここにラインを入れてみるか。

　白だと目立つから黒かな。

うーん、軸は分かりやすくなったけど、画面を切るし、なんかぞんざいな感じがする。

ならばこれはどうだ。

なんか上から落ちてきてタイミングよくボタンを押すアレみたいだな。

そうだ！これならどうだ？

お、いいかもしれない。

程よく縦を感じさせつつ、同時に反対側にも意識を向けさせる。これだ。

となると、コンテキストメニューのアイコンが気になるな。同じ見た目の記号を違う意味合いで使うのは避けないといけないし、左右の配置で機能が違うというのは無いから下向きにしてみよう。

よしよし。

次はコンテキストメニューか。小さくポップアップする感じで。

観戦中で流れていく可能性が高いから、アイコン付けた方がいいかな。

 こんなとこかな。解除の場合は文言とアイコンを差し替えればいいだろう。

ミュートした時の見た目はこんな感じかな。

　確か自分以外のユーザーにはミュートしたという情報が伝わらない仕組みだったと記憶してる。ミュートされたユーザーが詫びを入れることは無いと思うが、一応解除できるようにフキダシは残しておこう。

　あ、そうなると、相手に「いいね」も通知できないかもしれない。勢いでコンテキストメニューの項目を並べてみたけど、あとで南河原さんに確認してみよう。最悪、ミュート機能だけになるかもしれないけど、その時はその時で。

　「いいね」のようなポジティブな要素は受け入れられ易いが、誰かからミュートされたという事実を気づかせてやったら、慎み深く言葉を選ぶようになるだろうか？自分の発したフキダシに、No Good を表すアイコンが付くとどんな気分になるだろう。そういえばYoutubeの動画には付いてるけど、不特定多数だし、相手の名前が一切判らないからまだ穏やかでいられそうな気がする。名前と人数が判明している場合は、むしろ匿名の方が殺伐としそうだ。

　ユーザーに対してミュートした場合は、出るフキダシ全部をスミベタにすればいい。ブロックはかなりのヘイト状態じゃないと選択しないと思うし、そもそも赦す機会は無いと思われるので戻す必要はないから、非表示でも問題ないだろう。

　そこまでさせるユーザーには出会いたくはないけど、こういったUIが必要とされてるのも事実。できれば今回のゲームではミュートもブロックもいらないチャットであってほしい。この表示が要らないなら無くせばいいだけだし、とりあえず後から慌てて実装というのもスマートじゃないし、作ってる間に何かしら議論すればいいことだった。今は仕様を確実なものにするためにデザインを整えるのを優先しよう。無いものを考えるより不要なものをなくす方がはるかに簡単なのだ。

　いいね はこれくらいのさりげなさでいいかな。

　色付けたのもいいね。

　とりあえず気づきやすそうなピンクにしておこう。最初からハートアイコンを置いておくのもいいかもしれない。フキダシをクリックまたはタップすれば色がつくという仕様。いいねできそうな雰囲気を出せるので、一石二鳥か。ただ全てのフキダシにハートマークがつくことになるので、最初から付けるならアイコンのデザインは考え直した方がいいような気がしてきた。

　できた。

　さっそく谷山田に送信する。すっかり冷めてしまったコーヒーをすすっていると返事が返ってきた。「ありがとうございます！急いで資料まとめて鳥囃子Dのとこに凸ってきます！」と書いてあるメッセージの右上にあるメニューボタンからいいねを押して、がんばれよ、と頭の中で応援する。

　自信というほどではないがここまでの絵を作っておけば恐らく大丈夫だろう。あとは谷山田がうまくやるはず。

　鳥囃子ディレクターと組むのは今回が初めてではない。彼はあまりデザインに口を出すことはない。だが、それが逆にプレッシャーになったりする。OKを出す人間がいるとついそこに甘えるやつが出てくるのを嫌ってか、彼はそのあたり、ゆるいOKしか出さない。やたらと目を光らせて細かいところまでうるさいディレクターだと、スタッフはいいものを作るのがゴールではなく、このディレクターに怒られないように、嫌われないようにするのが目的になる。言うとおりに作れば、怒られないし、終わってから酷評されてもディレクターの責任だと言ってしまえる。

　彼の場合、それぞれの職能を持つ者に責任を感じさせて積極的な姿勢を促すというやりかたを取る。そこをくみ取れない者は彼のようなタイプを「決めないディレクター」だとして不満を漏らす。この手の不満を言う輩は、たいてい自分は悪くないというポジションから動こうとしない。お任せを丸投げとしか捉えられないのは悲しい。

　私自身はプレッシャーに弱く、任されると恐縮してしまう性格だ。彼との仕事は緊張はするけど、その緊張がそのままやり甲斐になって返ってくるのがとてもありがたい。私は彼が投げっぱなしということをしないのを知っている。ダメ出しするときはダメ出しをする。だからOKが出たら、それだけ期待されているということなのだ。

　冷たくなってしまったコーヒーを一気に飲み干して紙コップをゴミ箱に捨てる。省電力で真っ黒になったモニターにはぼやけた顔が写っていてこちらを見つめていた。慌ててマウスを動かす。まだ谷山田からの返信は無かった。

 つづく

UI ボタンでカメラを切り替える《後編》

前回の続きです。

limesode.hatenablog.com

前編ではカメラを切り替えるUIをWidgetで作って、レベルにオブジェクトと切り替えるためのカメラを設置しました。

後編は実際のカメラ制御の部分を作ります。

Blueprint Interface

まず、Widgetからメインカメラ用のブループリントにアクセスするためのインターフェイスを用意します。

コンテンツブラウザから右クリックで、Blueprints ＞ Blueprint Interface を選択。

このブループリントインターフェイスの中身は 関数名 とその 入出力ピン の設定のみで構成されています。

今回の関数名 SwitchCamera を作成して、Inputs に Integer型のピンを１つだけ追加したらコンパイルして保存します。

メインカメラ用Actor

次に、メインカメラ用のブループリントを用意します。

今度は Blueprints  ＞ Blueprint Class を選択。

ダイアログから、Actor を選択します。

さっそく編集していきます。その前にさっき作ったブループリントインターフェイスをセットします。

 できたブループリントを開いて、ツールバーの Class Settings をクリック。

Details（詳細）パネルから Interface の項目を探してセットします。

ブループリントインターフェイスがセットできたら、次はメインのカメラを追加します。

まずは左上の Componentタブから、＋Add Componentボタンを押して Camera を選択します。

次は変数を用意します。

一番上の CameraActor型の配列変数は、 レベルに設置したカメラにアクセスするためのものです。これだけ目玉のアイコンが付いているのは、以下のチェックボックスにチェックを付けているからです。

この２つにチェックを付けると、このブループリントを Spawnする際に値を受け取れるようになります。（Expose on Spawn だけだと 警告が出る）

 変数が用意できたら次は関数を２つほど用意します。

 配列に格納されたカメラの情報を取り出すのと、メインカメラにパラメータをセットする関数です。

まずは情報を取り出す方。getCameraPosition と命名。

中央下のノードは、ちょっと見つけにくいです。

get ノードからドラッグして、 get comp あたりで検索をかけて下の方。

カメラのアイコン付きを選択。

あとは、get Field Of View ノードと、 getActorTransform ノードです。

その二つを、Returnノードの Outputsピンから出します。

また、このGetCameraPosition関数は Pure型にした状態で作っていきます。

次は情報をセットする方。setCameraPosition と命名。

 Transform と FOVを setするだけです。セットする先は別になります。

変数と関数が用意できたので、次はイベント。

Event BeginPlay

まずカメラを乗っ取ります。

※GetCameraPosition関数は Pure型で利用しています。

Set View Target with Blend ノードに Self ノードをつないでいます。このSet View Target with Blendノードは、先に get Player Controller を取り出してからだとすぐに見つかります。

あとは、用意した関数をつないで、開始時のカメラ位置をセット。

Event Switch Camera

ブループリントインターフェイスに仕込んでおいた名前だけの関数みたいなやつを、イベントとして利用します。

グラフで右クリックして SwitchCamera を探すと見つかります。

これはイベントとしておくことで呼び出してもらうかたちとなります。

右上にブループリントインターフェイスのアイコンが付いたノードが出てきます。

ここにカメラ切り替えの処理をつないでいきます。

まずは前半部分。あらかじめ用意した変数と関数を並べるだけ。

※GetCameraPosition関数は Pure型で利用しています。

今のカメラ位置（Old）から、新しいカメラ位置（New）へ移動させるために、それぞれの値を一旦変数に取り置きします。

常に最新のカメラ番号を保持させる Current Index 変数ですが、更新するタイミングがとても重要。つなぐ順番によって結果が変わるからです。

残りの後半部分。

いよいよタイムラインノード登場です。

タイムラインノードのトラックは Floatタイプ が一つだけ。

これでメインカメラActorの完成です。

ボタンWidgetを並べるWidgetの再編集

メインカメラのActorも用意できたので、Widgetの方からアクセスする仕組みを作ります。ボタンWidgetを並べるためのWidgetを編集します。

 カメラにアクセスするために、Actor型の変数を新しく追加します。

Instance Editable と Expose on Spawn にチェックを付けておきます。

この段階ではまだどんな Blueprint Actor が入るか判りません。ただのActor型です。

あたりまえですが、中身にアクセスしたり関数を呼び出したりはできません。

さてこれを、放っておいたバインドからのカスタムイベントにつなぎます。

この空っぽのActor型のオブジェクトに対して、SwitchCamera の関数を取り出してつなぎます。右上に手紙のアイコンが付いたノードが取り出せます。

これは、プロジェクト内にブループリントインターフェイスが存在すると、見つけることができるというちょっと特殊な関係性によるもの。

 その対象がなんであるかも構わず、中に関数を持ってるかどうかも関係なくつなぐことができます。

こんな状態でコンパイルが通ってしまうのです。

試しに適当なオブジェクトにつないでみてもコンパイルは正常です。

再生してもエラーは出ません。

ブループリントインターフェイスにはこんな便利な仕組みが備わっているのです。

Widgetの再編集はこれだけです。

では最後の仕上げとまいりましょう。

Level Blueprint

レベルブループリントを編集します。

まず Spawn Actor From Classノードを取り出してEvent BeginPlay につなぎます。

Class のところに、用意しておいた BP_MainCamera をセットします。

すると Expose on Spawn にチェックをつけておいた配列が入力ピンとなって現れます。

ここにカメラを配列にしてつなぎます。

最近知ったのですが公式に便利な操作方法が載ってました。

まず、レベルに置いたカメラたちを全部、複数選択状態にします。

そしてレベルブループリントのグラフ上で右クリックして、

Create References to X selected Actors を探します。

結構紛れて探しにくいのですが、 cr ref で検索するとすぐ出てきます。

これを選択すると・・・

結構便利かも。

このうちの一つから、Make Array ノードを取り出してつなぎます。

これで配列化できました。

これをさっきのSpawn ノードにつなぎます。

Spawn Transform ピンに何もつながれていないとコンパイルした時にエラーがでます。

これはTransformについて適当な初期値を渡してやれば消えてくれます。

オレンジ色のピンからドラッグして、Make Transform を選択します。

こうなります。

これで、再生したときにメインカメラのブループリントがワールドに誕生します。

あとはWidgetをViewportに描けば完成です。

Widget を表示するのは、おなじみ Create Widget ノードと Add to Viewport ノードのコンボです。

Create Widgetノードも Class を変えると入力ピンが増えます。

ここと、先ほどの Spawn Actor from Class の Return Value とをつなぎます。

ようやく完成です。

再生してみます。

静止画だとタイムラインの動作が伝わらないので動画にしました。

youtu.be

使っているタイムラインは１つです。

ブループリントを触らなくても、カメラのアングルやFOVはワールドに置いてあるカメラを直接触ればすぐに反映してくれます。気に入ったアングルはレベルを保存するだけです。

いかがでしょうか？

キャラクリエイションとかで使えそうな気がします。

例えばキャラの身長に合わせてカメラの距離を調整したりとかも、今回の方法ならタイムラインノードをいじらずに臨機応変に補正ができます。

結構長くなりましたが、今回はここまで

ではでは

ステキなカメラ切り替えライフを！

UI ボタンでカメラを切り替える《前編》

突然ですが、ブループリントのタイムラインノードってものすごく便利なのです。

UMGには専用のタイムラインが装備されていますが、UMG以外でUIのインタラクションを表現する際に利用します。

ただトラックに直接的な値のKeyを打ってしまうと、とたんに汎用性が無くなってしまいます。

先日のぷちコン第11回でも使った方法なんですが、ちょっと扱い方を工夫するだけで汎用性が高くなってさらに調整がラクになる方法があるので記事にしておくことにします。

賢明な読者諸兄はすぐに気づかれるかと思いますが、種明かしをするとこれです。

 

タイムラインノードから出てくる値は、0.0 ～ 1.0 のみ。

 この１個のタイムラインを値を煮るなり焼くなりして使い回すのです。

掛け算したり、

↑この場合、0.0 ～ 5000.0 の値でアニメーションします。

また 0.5から引き算して、２倍すると、 -1.0 ～ 1.0 の値のアニメーションが可能。

しかも、カーブを調整すれば好みのイージングも作れます。

 変に計算が増えると処理への負荷が無視できなくなりますが、ほどほどに、汎用的に使えるカーブを効率よく使えば、調整にかかる時間が減るのでおススメです。

さらにこれを便利に活用するためのノードが、Lerp 系のノード

扱う型専用にいくつか用意されているようです。

入力ピンの Alpha に 0 ～ 1.0 の数値を入れることで 同じく入力ピン A と B の２つの違う値についてその途中の値を取り出すことができます。例えば、Alphaに 0.5 と入れると、A と B のちょうど中間の値がReturnValueから取り出せます。0 だと A に、1 だと B に近い値になります。

Vector や Color のような複数の値を持っている場合で、同時にアニメーションさせる場合にとても効果的なのです。

ちなみに Lerp は Linear Interpolate の略で、 漢字で書くと「線形補間」です。

ですがタイムラインのカーブを使えば、変化量が線形じゃなくなります。

今回この仕組みを使って、UIのメニューに合わせてカメラを切り替えるのをやってみます。

切り替えUIメニュー

まずメニュー用のWidgetから。メニューといっても簡単に四角いボタン的なものが並んでいるだけのものです。

そのボタン的なものは、さくっと簡単に UMG の Button というコンポーネントで作ることにします。まず Button を左のリストから探してキャンバスに 配置します

 Anchor は ストレッチ（親要素に合わせて最大まで拡大）でドーンとスクリーンサイズに。Anchor を変えただけでは変化しないのでパラメータを変えます。

Button の Slot（Canvas Panel Slot） は ↓ こんな感じ。

中にTextBlockを子供として持たせます。

TextBlockは ↓ こんな感じ

階層構造は↓下のようになってます。

ここで、クリックイベントを作成します。

配置した Button のDetails（詳細）パネルの下の方に緑色のボタンが並んでいるので、

On Clicked のボタンをクリックします。

 強制的に編集モードがGraphモードに切り替わります。

イベントノードが置かれていますが、一旦置いておきます。

Integer型の変数をひとつ追加します。

自身が何番目のボタン番号かを受け取っておくためのものです。

次にカスタムイベントを用意します。

Inputピンに、Integer型とText型を追加して、作っておいた 変数 と TextBlock にそれぞれつなぎます。

次はイベントディスパッチャーを用意します。

Inputsのところで＋ ボタンを押してInteger型のピンを追加します。

このイベントディスパッチャーを、On Clicked イベントにつなぎます。

イベントディスパッチャーをグラフにドロップすると小さなコンテキストメニューがポップするので、 Call を選択します。

クリックされたら、自分が持たされているボタン番号を返す仕組みです。

コンパイルして保存します。これでボタンWidgetは完成です。

ボタンWidgetを配置するWidget

次にボタンを並べるための親になるWidgetブループリントを用意します。

キャンバスに HorizontalPanel をひとつ配置します。

Slotはこんな感じ。

このHorozontalPanelに、先に作ってあったボタンのWidgetを追加します。

既に作成済みのWidgetブループリントはアセットになっているので、

UserCreated カテゴリで探すと見つかるはずです。

それを Hierarchey パネルの HorizontalBox 以下にドロップします。

とりあえずカメラを５台置く予定なのでその数ぶん追加します。

追加したらそのまま、まとめて選択状態にします。

レイアウトの設定を変更します。

Size が 初期状態でAuto になってるのを Fill に切り替えます。

HorizontalPanelにぴっちり並んでくれるはず。

キャンバスはこのくらいで。

グラフの方を編集します。

まずは並べたボタンたちを一旦配列にします。配列にした方がForEachLoopが使えるのでこ後でちょっとラクができます。

ざっくりですが手順をGIFにしてみました。

次にボタンのラベルをテキスト型の配列で用意します。

一度コンパイルすると、DefaultValue（初期値）がセットできるようになります。

ここで ForEachLoopの出番です。

右端のノードは、イベントディスパッチャーが存在することが前提で、そのイベントディスパッチャーにBind（バインド：紐づけ）することが可能になります。そうすることで、ボタンのWidgetからイベントディスパッチャー経由で通知を受け取ることができます。要するにボタンが押されたら、カスタムイベントが実行されます。

　カスタムイベントにはとりあえず今は何もつなげないで、コンパイルしてみます。

すると、キャンバスが変化します。

Event Pre Cnstruct につないだ処理は、Play していなくてもコンパイルした時点で、キャンバスに配置したものに影響を与えることができます。


 Widgetは一旦ここまでにします。

カメラの設置

次はカメラとステージを 用意します。

準備としてレベルに、カッコイ風景とカッコイイオブジェクトを設置します。

レベルに直接カメラを５台配置。アングルを決めます。Field Of View（視野角）も調整します。

前編はここまで。

後編は、メインカメラの作成と制御を作っていきます。タイムラインは後編で登場します。

ではでは

ゆらゆらするマテリアル

　なんとか第11回ぷちコンに応募することができました。今回はギリギリまでかかってしまってキツかった。今使ってるPCではパワー不足だということが思い知らされた感があって寂しくはあるけど、あきらめた表現がたくさんあったのもまた事実で、もう買い替えをためらっている場合ではないのだと強く思った次第です。なんてことを書いてますが、かなりの部分は自分の頭の悪さだったりして・・・すみませんマシンパワーのせいにしました。てへぺろ。

 実際シェーダーコンパイルに時間がかかり過ぎたのと、半透明に落とす影の調整に時間がかかり過ぎました。

　応募した動画を貼っておきます。

【第11回UE4ぷちコン応募作品】 ちいさなうきわ。

　動画編集はいまだに不慣れなので、編集に時間を掛けられないと判断。実際にプレイしたキャプチャをそのままノーカットでアップしました。さすがに前後の黒い余白時間をカットするくらいはしてますが、ほんとそれだけです。

　なので、画面遷移やUI表示は職業柄それなりに頑張って作ったつもりです。

まぁそんなこんなで、ブログの更新が止まっていたわけですが、久しぶりに書こうと思います。ネタはぷちコンからで、仕組み自体は過去記事でも紹介したものの応用になります。

ゴールした時の誉め言葉表示です。

この水の屈折のような表現。ディストーション（歪み）エフェクトとも呼ばれるようですがマテリアルで簡単に作ることができます。

　まずは ゆらゆら させるためにはランダムな2D素材が必要です。Noise ノードを使うとテクスチャが不要にできるのですが、やっぱり滑らかさが欲しいので今回 Photoshopを使ってテクスチャを用意するところから説明していこうと思います。

あの有名なフィルタを攻略する

ランダムといっても大きなテクスチャはそのままテクスチャメモリの負担となるのでなるべく小さく、かつタイリングできるように作ります。

そこで登場するのがおなじみのフィルター「雲模様１」

ちなみに↑これは、 512ｘ512 で作成したものを 50％に縮小した状態です。

このフィルターは、２のべき乗で作成すると上下左右がつながったシームレスな状態になります。

フィルター ＞ その他 ＞ スクロール を使うとつながりが確認できます。

２のべき乗というのは、２を何乗かした値で、２、４、８、16、32、64、128、256、512、1024・・・という数字です。縦横をこの数の解像度にすると見事シームレスなテクスチャの完成です。ちなみに他の解像度で雲模様を作ると、つながらなくなります。

これは 250ｘ250で作成してスクロールさせた状態。よく見るとつながっていないのが判ります。下の図はニアレストネイバーで400％に拡大した状態。

これが「雲模様１」の特徴です。

ちなみに、この「雲模様１」は、フィルタを掛ける際に、描画色と背景色の２色を使って作られます。なので、今回のようにモノクロでしっかりと階調差を出したい場合は、直前に D キーを押して、白黒にしておくのをお勧めします。

あと、注意したいのが「解像度」です。雲模様フィルタは、密度の調整ができないので、解像度でコントロールすることになります。

ヒストグラムで比較するとさらに差が分かりやすくなります。

という訳で濃淡の散らばり具合を考慮して今回は 1024ｘ1024で進めます。

素のままだとノイジーなので、ここから加工していきます。

水の揺らめきなので、もっと滑らかな感じが理想。

ボカしたり、明るさの中間値を掛けると速いのですが、この状態でかけると、せっかくシームレスにしたのが台無しになってしまいます。フィルタはドキュメントの上下左右がつながっているなんて気にしないからです。

そこで、面倒ですが一旦 手動でシームレスな状態にします。

まず 新規ドキュメントを 1024ｘ1024で作成して「雲模様１」を使用します。

この状態で、全選択（Ctrl+A） からの コピー（Ctrl+C）までを実行。クリップボードに入れた状態で、カンバスサイズを変更します。

するとこうなります。↓

ここからクリップボードに入れたのをペーストしていくのですが、ちょっとだけ時短できるぷちテクニックを紹介しておきます。選択範囲を作ったペースト方法です。

まず左上に貼り付けたい場合、マウスを下図のように外に向かって適当に動かします。

すると、

このような選択範囲になるので、ここでペースト（Ctrl+V）します。

これを４隅で行います。

上下左右も同じ要領で適当に選択範囲を作って、

ペースト＆ペースト。

多少ずれても中央揃え機能を使えばビシっと隙間なく並びます。

アナログな手操作を確実でブレのない結果にするのが大好きなので紹介しましたが、この時点でピクセルがずれていなければどんな方法でもOK。Photoshopは作業中の表示倍率がキリの悪いときはかなりの確率でピクセルスナップが甘くなるので、こういった倍率に関係なく確実な操作は重要です。

　この９枚がビシっと並んでいる状態でようやくフィルタを掛けます。

せっかくタイリングするように並べたので、ランダム系のフィルタはNG。あくまでもピクセルに合わせて均等に掛かるタイプのフィルタを使います。

今回は、明るさの中間値 を掛けてから ぼかし（ガウス）を掛けました。

ここで解像度を落とします。

最終的に 256ｘ256 のテクスチャにしたいので、256ｘ3 ＝ 768

768ｘ768 に縮小します。もちろん縮小されるときにもピクセルにフィルタが掛かります。

ここで、カンバスサイズを使って 周りの 8枚をカット、中央の１枚だけにします。

シームレスになっているかどうか、「スクロール」を使って確認してみましょう。

つなぎ目が見えなければ完璧です。

これをリニアなグレースケールテクスチャとして、UE4に持っていきたいので、ドキュメントをグレースケールに変更します。イメージ ＞ モード ＞ グレースケール を選択。

おそらくポップアップが表示されるので、カラー情報は破棄します。

チャンネルが 「グレー」だけになったらOK。

　あとは、これをTarga フォーマット（拡張子 .tga）で書き出せば UE4 にインポートできます。

　PNG形式はチャンネルが一つだけ（SingleChannel）という仕様を持っていないため、PNGで保存した際にRGBA32ビットに戻されてしまいます。なのでグレースケールテクスチャの場合は、PNGは使っちゃダメです。チャンネルが一つということはそれだけテクスチャのメモリが1/4になるということで節約になります。

今回よりランダム感を出したいので、もう一枚用意します。

 ↑ Web用にPNG形式になってますが右クリックしてDLしてもらってOK

この２枚をUE4にインポートします。 

いざUE4へ

 インポート設定はこんな感じです。

今回 sRGB のチェックは外しているので、リニアグレースケールテクスチャとして扱うという意味になります。これはPhotoshopでのカラー設定によって書き出す際の補正があるか無いかで決めます。特に何も設定をいじっていなければsRGBにチェックが付いていると思いますが、今回は特に問題ありません。

 ちょうど一年前の記事ですが一応過去記事を貼っておきます。

limesode.hatenablog.com

これを使ってマテリアルを作ります。

Create Material して中にテクスチャをドロップします。

あ、揺らすためのテクスチャを忘れていました。せっかくなんで。

これをつなぐとこうなります。

 速度は左のPannerノード で調整しつつ、揺れ幅というか揺れの度合いは、TexCoordノードで調整します。

参考までに今回の値。

さらに適応する量は、真ん中のScalarParameterValueで調整します。このパラメータノードは、Widgetブループリントから値を受け取って反映する役割のノードです。

雲模様のコントラストや濃淡によりますが、今回の値はこんな感じ。

まず、Amount: 0.15

かなり揺らめいてます。

次は Amount: 0.1 だいぶ落ち着いてきました。

Amount: 0.025

もちろん ０ にすると静止します。

ちなみに 0.5 はまったく読めません。

これだけで一つミニゲームが作れそうです。

なんて書いてあるでしょうか？さぁ早押しでお答えください！　みたいな。

ただあまり揺らすと端の切れてる部分が目につくようになるので注意が必要です。

真ん中上の、Subtract（引き算）ノードでは、グレースケールテクスチャからやってきた値を調整しています。

ここでいう調整というのは、0～1 という範囲を、幅を変えずに -0.5～+0.5 にすることです。テクスチャの黒は 0.0、白は 1.0なので、このまま足し算して使うと、揺れはしますがプラスの方向にしか揺れないので、結果的にテクスチャ全体がプラス側に寄ってしまいます。それをプラスとマイナスの距離が均等になるようにしているのです。

マテリアルはこれで完成です。

ちなみに、↓こんなテクスチャだと。

こんな感じにできます。

Widgetでフェード

まずキャンバスに、Imageを配置します。

配置したら、Detailタブから、Appearance ＞ Brush ＞ Image の部分に用意したマテリアルをセットします。

さらにもう一つ、Imageをキャンバスに追加します。

これは描画しないのでVisibilityを Collapseにしておきます。

ここでアニメーションを用意します。

アニメーションさせるのは２つ。

一つは、Collapseにした方の Pivot。もう一つは、表示する方の Render Opacity 。

つぎにブループリントを用意していきます。

初めから置かれているイベントノードをそのまま利用することにします。

Event Pre Constructから。

Image にセットしているマテリアル（Static）をいじるには、マテリアルを、Material Instance Dynamic型 にする必要があって、Get Dynamic Material ノードを使うと型変換しつつ、置き換えてくれます。この変換処理を頻繁に行いたくなくて、一度きりで十分なので、ReturnValueから Promote to Variable（変数に昇格）させています。

Event Construct。

アニメーションの再生が終わったら、後片付けしてViewportから姿を消します。後片付けといっても変数を空にしてマテリアルへの参照関係を解消するだけです。

最後に、Event Tick。

Widgetは完成です。

テスト用の新規レベルを作ってテストしてみましょう。

レベルブループリントに Create Widget ノード と Add to Viewport ノードをつなぎます。繰り返し確認したいので、Inputノードで何度でもWidgetを呼び出せるようにします。とりあえずスペースキー。

再生してみます。

いい感じです。青い背景を置いたので、マテリアルのBlend Mode は Additive に変更しています。

シームレステクスチャのパターンを工夫したり、タイリングや揺れ加減を調整したり、まだまだ応用できそうです。

ではでは

今回はこの辺で

ステキなゆれゆれマテリアルライフを！