みつまめ杏仁

アンリアルエンジン(UE4)でGUIを作るためにゴニョゴニョしてます。UIデザイナーの皆様の助けになれば幸いです。

チャットUIを作る

9

 メッセージは立木坂から届いたものだった。一時的にチームから捨てられたという表現をしていたが、まぁアイツのデフォルトの物言いなので無視しつつ、やり取りしていると、どうもスタンプの絵を描く仕事を請けたらしい。プロデューサーの手の速さに若干の不気味さを感じる。良いものにしたいという気持ちで動く分にはプロジェクトチームのメンバーとして当然だ。なぜかプロデューサーという立ち位置が個人的にあまり好きになれない。プロデューサーの職分というより、たまたまそこにいる人間との相性な気もするが。

 ただ、仕様決定の場に不在なことが多いのもあって、どうしても現場からの距離を感じざるを得ないし、外から中をつついてかき混ぜてくるような印象しか持てないのは、個人的すぎる感傷が由来なのは分かっているつもりだ。今のところ、この心象を変えてくれるほどの出会いは無い。単にプロデューサーと仲良くなればいいだけの話だと言われてしまったら、言い返せるほど経験値が高くないし、まぁ人見知りだから仕方がない。ということにしておこう。

 で、プロデューサーのことはさておき、立木坂はスタンプの仕様を教えろと言ってきた。仕様もなにも自分もさっきスタンプ機能追加の件を聞いたばかりだと返したら、

 

(立N)じゃあ表示サイズと、種類を教えてください

・・・コイツ人の話聞かないやつだな・・・

(自分)まだ決めてない

(立N)何にも決まってないのに何を描いたらいいんですか?

(自分)訊かれても困る

(立N)うーん、とりあえず猫でも描いて癒されます

(自分)じゃそれ

(立N)はーい

 

 という流れになった。なんかアヤフヤなままで不安しかないが、出来に関してはこちらから依頼したわけではないので、いったんモックの完成を目指そう。やることは増えたが素材を用意する手間は省けたのはありがたい。絵の内容はまた別途すり合わせの時間をとればいいだけのことだ。後でスケジュールの確認もしなきゃな。

 

 さて、ここまでできたけど、なんか忘れてるものがないか、

f:id:hiyokosabrey:20190907220808j:plain

 ラフはどんな感じだったかな。

f:id:hiyokosabrey:20190513225244j:plain

 そうだ、左右の振り分けが簡単にできたせいで、この < > を置くの忘れてた。

 自分のコメントに色を付けるのは簡単だ。ストラクチャから値を引き出せるようにしたから、すでに要領は得ている。サブメニュー表示はちょっと重めなのと、レイアウトが安定してからにしたい。ここは、 < > を作っていこうか。

 とはいえ、これは少々作り替えが必要だな。

 

 現状、フキダシWidgetは必要最小限のサイズでしか表示していない。そして、横幅が画面サイズと同じ Vertical Box に対して AddChild している。 さらに、isLeft というブーリアンの値でもって、setHorizontalAlignment ノードを使って左右にレイアウトしている。

 

f:id:hiyokosabrey:20190915203017p:plain

 ここに < > を表示しようとすると、①重ねて出すか、②VerticalBox を2つ左右に分割するか、③フキダシの方に追加するか。今思いつくのはこの3つ。

 ①の重ねて出す方法は、新しく< >の専用Widgetを作り、フキダシ追加に合わせて一緒に追加。Y方向にマイナスマージンの値を入れれば実現できそうだ。当然フキダシの高さが可変なので、値を調整してやる必要がある。

 ②は左右が独立することになるため、同じ高さを維持できさえすれば、シンプルなつくりが期待できるが、2つのVerticalBoxにアクセスすることになるので、その切り替えがちょっと面倒な印象。

 ③は、フキダシWidgetのレイアウトをいじるだけで解決できそうなので、今のしくみから大きく変わることはない。ただし、左右の振り分けではなく左右反転になる。

 

 あとは、スクロールアウトした際の処理だけど、①と②、どちらも別々のWidgetが追加されているので、画面から消すときに常に2つづつ消すことになる。③は今まで通り。

 

 これはチャットのUIだ。時系列で過去から現在にかけてリニアに並んでいる。余計な要素は入れない方が、サーバーとの差分が無い分シンプルに管理できるはず。発言順がそのまま表示順になっていた方がチェックがラクだし、なにより表示する側の都合でしかないのに、システム側に表示側の都合に合わせろというのは、後々のことを考えると経験から言ってリスクである可能性が高い。

 ここは③のフキダシWidgetに手を加える方法で進めていこうと思う。

 やることは今のレイアウトにパーツを追加することと、フキダシのサイズ可変に同調できることがゴールだ。左右反転については、フキダシWidgetの中でやってるので、むしろレイアウトWidgetでやってる左右振り分けが不要になるはずだ。

f:id:hiyokosabrey:20190915211124p:plain

 縦方向の可変イメージはこんな感じ。

f:id:hiyokosabrey:20190915212408p:plain

 

 さっそく < のテクスチャを作ってインポートする。

f:id:hiyokosabrey:20190915213331p:plain

 とりあえず、SideArrow と名付ける。

 これをキャンバスに配置するわけだけど、まぁ試しながらやってみるか。

 

 Size to Content の仕様と、アンカーのストレッチに悩まされつつ、1時間ほど試行錯誤を繰り返してようやくなんとかなった。と思う。

f:id:hiyokosabrey:20190915214105p:plain

 フキダシの下敷き画像は、親のキャンバス(CanvasPanel_Container)にサイズ依存していたので、SizeBox以下とフキダシの下敷き画像を、新しく追加したキャンバスパネル(CanvasPanel_fukidashiBody)でくるむことで、階層的に一段下げた。そしてその CanvasPanel_fukidashiBody と同階層に SideArrow  を追加するのだが、親キャンバス(CanvasPanel_Container)のSize to Contetnt が利いているせいで、サイズの変化するフキダシに対して、右端をアンカーとした SideArrow が配置できない。そこで、SideArrow も サイズ固定した CanvasPanel でくるむことで位置を確保。

f:id:hiyokosabrey:20190915215313p:plain

 危なかった。一瞬あきらめかけたけどなんとかなった。

 

 あとは、レイアウトWidgetの方を編集。フキダシWidgetを追加する関数のところで左右振り分けの処理をバッサリ。

f:id:hiyokosabrey:20190915220723p:plain

 

  こうやってノードが減ってスッキリすると気持ちがいい。

f:id:hiyokosabrey:20190915220908p:plain

 

 これでいけるだろう。

f:id:hiyokosabrey:20190915224109j:plain

 何度も再生して、そのたびに落胆してきたので、感動するより安堵の溜息が出る。ようやく想像通りになった。この辺はもっといろんなUIを作って経験を積むしかないなと改めて思う。

 

 あとは、自分のコメントに色を付ける処理か。これは、判定するのは表示側ではないのと、作るとなっても大してコストがかからないので、後回しにしよう。それより真ん中のテキスト入力部分が見た目に重いので、ホバー処理を入れてみたい。普段アルファ値で薄くなってて、カーソルが乗ったらハイライトする。

 

 テキスト入力Widget は レイアウトWidget で管理してるから、そこでホバーの判定を取ってもいいけど、すでにEventTickでスクロールの制御をしてるから、今はまだあまり複雑にはしたくない。やっぱりテキスト入力Widgetの方でやるか。外すときも簡単だ。

 パーツを抱えている親のキャンバスに対して、Is Hovered ノードで判定を取る。on Hovered みたいなちょうどいいマウスイベントはなさそうなので、 EventTickで毎フレームチェックする形になる。処理負荷が心配だけど、後でプログラマに相談しよう。

 

 まずはこんなところか。

f:id:hiyokosabrey:20190916144929p:plain

  Render Opacity は、キャンバスに使うと、配下の子供たちにもフェードが掛けられるとても便利なパラメーターだ。

 

f:id:hiyokosabrey:20190916145820g:plain

 こちらは詰まることなく予想通りにできた。

 

 ふと辺りで人が動いているのに気付いた。自分の位置からはフロアの扉は見えないが、ばたばたと立て続けに出入りする音でわかる。もうこんな時間か。時計を見たら急に疲れが出てきたような気がする。キリがいいから、今日はこの辺にしておこうか。ここまでくれば、テキスト入力を左右個別に配置するタイプを作ってもいいと思う。

 よし、帰ろう。帰り支度をしてフロアを出る。

「お先に失礼しま~す。」

 

 外に出ると雨は止んでいた。薄く雲が残っていて、ぼんやりと残照を拡散していてまだ明るい。急に腹が空いてきた。晩飯について考えながら駅に向かって歩き出した。

 

つづく

 

 

 

 

 

 

 

チャットUIを作る

8

 近くに窓が無いので外の様子が分からないが湿度が高い。帰るまでに雨がやんでるといいんだけど。エレベータを待つ間、ホットにしようかアイスにしようかな迷ったけど、それほど喉が渇いているわけではなかった。少し体が冷えた感じがするので軽くストレッチをして戻ることにする。

 画面丸ごととなると表示するものが多いから結構かかるよな。今日どこまでいけるかな。フキダシの見た目だけでももうちょっと何とかしておきたい。そんなことを考えながら伸びをしていると、カゴが到着する音が鳴って慌てて体勢を整える。ボタンを押してたのを思い出した。幸いドアが開いたけど誰も乗ってなかったので、無駄に乗らなくて済んだ。

 

 さて、まずはフキダシにシッポを付けないとな。Photoshopをアクティブにするとフキダシの作業用ドキュメントが開いたままになっていた。左側のフキダシがデフォだから、画像サイズを右寄せで拡張して、88x64pxくらいかな。

f:id:hiyokosabrey:20190831201733p:plain

 シッポを付けたいけど、ちょっと角削りすぎたか。調整して・・・

 

 サイズが可変にできるよう Boxで指定しているので、分割位置を小数で割り切れるように調整するのが面倒だったけど、どうにかできた。

f:id:hiyokosabrey:20190831203022p:plain

 これをそのまま上書きして、Reimportする。

 

 Reimportしたら、フキダシWidgetを開いて、パラメータを書き換えないといけない。

 分割の指定はMarginのところで行う。まず、左上から Left と Top が 0.625 なので、残りは どちらも 0.375だ。

f:id:hiyokosabrey:20190831205916p:plain

 やっぱり少ない桁で割り切れると気持ちいいな。職業柄 UVを扱って長いので小数点耐性には自信がある。UI制作では小数点で指定することが多かったからだ。そういえばカラーも最近は 0.0~1.0で扱う機会が増えている。

 

 テキストの位置がずれたので、SizeBox にある Paddingで調整する。

f:id:hiyokosabrey:20190831212102p:plain

 ここに、顔アイコンも入れておくか。サイズは 80x80 くらいでいいかな。

 その分、フキダシとSizeBox を右に移動。

f:id:hiyokosabrey:20190831212949p:plain

  フキダシはOffsetX、SizeBoxはPositionXに80を入力する。

 

 ひとまずこの辺でいいだろう。編集モードをグラフに切り替えて、新しく変数を追加する。顔アイコンを受け取るためだ。Textrue2D 型で、Expose on Spawn にチェックを付ける。

f:id:hiyokosabrey:20190831222832p:plain

 コンパイル時に警告が出るので、 Instance Editable にもチェックを付けておく。

 キャンバスに追加した顔アイコンのパーツをGetで配置して、EventConstruct の最後でテクスチャをセットする。

f:id:hiyokosabrey:20190831223319p:plain

 Set Brush from Texture ノードに、さっき用意した変数もつなぐ。

f:id:hiyokosabrey:20190831223608p:plain

 これで受け取り準備完了。

 いったんコンパイルして保存しておく。

 

 

 レイアウトWidgetに戻って、フキダシWidgetを追加するイベントを確認。Create Widgetノードの上で、Refresh Nodes を行うと、ピンが増える。

f:id:hiyokosabrey:20190831224114p:plain

f:id:hiyokosabrey:20190831224349p:plain

 ここに顔アイコンのテクスチャをストラクチャから取り出して渡せばいい。

f:id:hiyokosabrey:20190831224845p:plain

 コメントのテキスト入力ピンが New Var 0 のままだな。ついでに変えておけばよかった。

 

 この辺で様子を見てみようかな。

f:id:hiyokosabrey:20190902214516j:plain

 しまった! 横着してたの忘れてた。テキスト入力用の下敷きを専用で作ってやらないと。

 

 ・・・

 

 気を取り直して再生。適当に入力して試してみる。

f:id:hiyokosabrey:20190902221001j:plain

 右側の時だけ、並びを逆にしたいな。さてやり方はどうしよう。

 

 思いつくのは2つ。今フキダシWidgetを「左専用」にして、新たにフキダシWidget「右専用」を作るか、Widgetは増やさずに今のフキダシWidgetの中でレイアウトをタイムリーに「スイッチ」する処理を追加するか。

 

 ひとまずスイッチするのを考えてみよう。フキダシWidgetを開いて編集モードをグラフにする。isLeft のフラグを受け取ってから左右だけ入れ替えるマクロでも作って入れよう。その前に、フラグを受け取る変数を用意しておかないと。これもExpose on Spawn だな。変数名は、アセットが違うので同じで大丈夫。

f:id:hiyokosabrey:20190902225431p:plain

 まずこれでコンパイルして保存。あ、ついでに New Var 0 だった変数名も変えておこう。テキスト型の変数を、commentBody に変更して、改めてコンパイルして保存する。

 レイアウトWidget を開いて、CreateWidgetノードを確認してみると、New Var 0 のピンが赤くなってる。f:id:hiyokosabrey:20190902231151p:plain

 右クリックして Refresh Nodes すると色が戻った。接続が切れるのでつなぎなおして、増えたピンにストラクチャの isLeft をつなぐ。

f:id:hiyokosabrey:20190902231614p:plain

 これで、左か右かのフラグがフキダシWidgetに渡されるようになった。レイアウトWidgetコンパイルして保存。

 

 再びフキダシWidgetを編集。スイッチ用のマクロを作ろう。名前は switchSide でいいか。

f:id:hiyokosabrey:20190904212655p:plain

 Inputs と Outputs に Exec ピンを一つずつ追加。

 これを Event Construct のところに差し込む。

f:id:hiyokosabrey:20190904212948p:plain

 さて肝心の中身だけど、どうしようかな。ひとまず左右反転してみるか?アンカーいじるのややこしそうだし。Render Transform でひっくり返してみよう。中のテキストはもう一回ひっくり返せば元の見た目に戻るはず。裏の裏は表だ。ひっくり返すのはこいつら。

f:id:hiyokosabrey:20190904213414p:plain

 左右どちらかというのは、 ブーリアンの変数 isLeft が受け取っているはずだから、そこから select ノード使えばいけそう。2つの状態に応じて値を振り分けるのはSelectノードが本当に便利だ。 isLeft が false の時だけひっくり返せばいいから、

f:id:hiyokosabrey:20190904213727p:plain

 こんなとこかな。フキダシWidgetの編集は完了。

 

 さっそく試してみよう。

f:id:hiyokosabrey:20190904214315j:plain

 おお!いいねいいね。

 あ、そうか。顔アイコン白いままだから気にならなかったけど、顔アイコンとかもひっくり返さないといけなくなったな。ひっくり返すものが増えてくると、罪悪感みたいなものが膨らんでくる感じがする。SizeBoxのアンカーを右にしたときにうまくいくか試してみないとわからないな。フキダシの大きさを可変にしたから難易度が上がってしまった。アンカーの設定から見直す必要がありそうだ。この辺は追々詰めるとして、今は先に進もう。

 

 顔アイコンのダミーでも用意してみるか。なんかフリーで使えそうなのないかな。

 しばらくネットを検索結果を行ったり来たりして、まぁ結局いつものとこで調達。ほんとにいつもお世話になってます。手を合わせて心の中でいただきますと呟く。

 透過のPNGPhotoshopでリサイズ。たくさんあるアセットの設定変更は、Asset Action > Bulk Edit via Property Matrix... が便利。一度Importしてから、コンテンツブラウザ上でまとめて選択して右クリックメニューから選ぶ。画像を用意するのに時間がかかったけど、16個のインポートはサクッと終わった。

f:id:hiyokosabrey:20190904224419p:plain

 このアイコンたちを、レイアウトWidgetからフキダシWidgetに渡せばいいだろう。今は左右の矢印ボタンをクリックすると、テキスト入力Widgetとバインドしてイベントディスパッチャーで受け取ってるところがある。そこからフキダシの追加を実行している。

f:id:hiyokosabrey:20190904225649p:plain

 まだテスト用だから、コメント入れておこう。イベントの名前も CustomEvent_0 のままだと役割が分かりにくいので、recieveComment に変えておく。

f:id:hiyokosabrey:20190904230732p:plain

 ここのMakeノード(ストラクチャ用)にテクスチャ2D型のピンがあるからここにつなぐ。そのためにまずはテクスチャを配列にでも入れようか。新しく変数を追加して配列にする。一度コンパイルしてから、16個分の+ボタンをクリックしてエレメントを増やす。テクスチャはプルダウンから選んでもいいし、コンテンツブラウザからドラッグするか、矢印ボタンを使ってもいい。

f:id:hiyokosabrey:20190904231648p:plain

 数が少なければ検索するけど、多いのでドラッグしよう。

 

 配列が用意で来たらグラフに取り出して、GetノードとつないでMakeノードにつなぐ。このままだと 0番のテクスチャしか使われないので、雰囲気を見るためにランダムノードを使う。f:id:hiyokosabrey:20190904232927p:plain

 さっそくテストしてみよう。

f:id:hiyokosabrey:20190904233454j:plain

 かなり雰囲気出てきた。どの顔が出るかわからないながらテキストを打ってみたけど、男の子?以外はキレイに左右に分かれてしまった。うん、確かに顔の向きが反転されていない。

f:id:hiyokosabrey:20190904234048j:plain

 マクロに顔アイコンのパーツも追加するか。

f:id:hiyokosabrey:20190904234213p:plain

 これでどうかな?同じ顔が出るようにランダムノードいったん外して見てみよう。

f:id:hiyokosabrey:20190904234630j:plain

 OK。じゃこの流れでUIDも追加しよう。

 

 テキストブロックをフキダシに追加して、パーツの位置を調整。文字の色はこんな感じかな。小文字が使えたはずだから、ディセンダに注意しないといけない。gyjを追加してみる。

f:id:hiyokosabrey:20190907083331p:plain

 ちょっと被るけど、これくらいならいいかな。ベースラインから下に伸びる文字はいくつかあるけど、意図的に組まない限り出現頻度はそれほど多くない。そこを心配してベースラインがフキダシから離れる方が塊り感が弱くなるのでよろしくない。離れていても、アウトラインや下敷きでグルーピングする方法も採れるけど、チャットなので、縦方向に積み上がっていくことを考えると、あまり上下に無駄な空間は作りたくはない。まぁ画面が採用されて本実装となったら、このまま微調整するか、デザインを見直してもいい。

 TextBlockは Size to Content にチェックを付けておく。これは、サイズを固定すると、余白ができるし、反転した時見た目のズレを、修正する処理が必要になるからだ。

 

 キャンバスはこれでいいとして、UIDを受け取る変数を追加しないと。

f:id:hiyokosabrey:20190907091107p:plain

 これも、Expose on Spawn と Instance Editable にチェックを付けておく。

 次はグラフに、これを書き換える処理を追加しよう。場所は EventConstructの最後に追加でいいかな。

f:id:hiyokosabrey:20190907092007p:plain UID文字列の内容によってフキダシの高さは変化しないから、一番後ろで大丈夫だろう。で、反転対策を入れれば出来上がり。switchSideマクロを編集する。

f:id:hiyokosabrey:20190907092449p:plain

 

 フキダシWidgetの編集は一旦完了。受け取る方の準備ができたら、つぎは値を渡す方。レイアウトWidget の CreateWidgerノードをリフレッシュする。

f:id:hiyokosabrey:20190907093343p:plain

 だいぶ混線してきたな。そろそろ、受け取るフキダシWidgetの変数もストラクチャにした方がスッキリしていいかもしれない。よし一気にやってしまおう。

 

 

 フキダシWidgetスッキリ受け取り改造作戦開始。

 まずフキダシWidget側に変数を追加。もちろん Expose on Spawn と Instance Editable にチェック。

f:id:hiyokosabrey:20190907094422p:plain

 つぎにバラバラと個別に追加した変数たちを、グラフから取り除きつつ、このストラクチャから取り出してつないでやればいい。まずはマクロのブーリアン型 isLeft。マクロの中ではなく、外から入力ピンとして受け取れるようにする。

f:id:hiyokosabrey:20190907094708p:plain

 

 ストラクチャの内容を取り出してつないでいくんだけど、どうしようかな。

f:id:hiyokosabrey:20190907095325p:plain

 ここから、あちこちにラインが伸びていくのが想像できる。そうだ、これを個別の関数にしてしまおうか。いったんこれを Collapse to Function する。

f:id:hiyokosabrey:20190907095636p:plain

 関数名は getSideFlag としておこうか。Return ノードを取り出して、そこへストラクチャの isLeft だけを刺してやる。

f:id:hiyokosabrey:20190907100605g:plain

 関数の仕事結果を返す Returnノードは、ピリオドで検索できるので便利。この関数をイベントグラフのマクロのところにつないでやる。

f:id:hiyokosabrey:20190907100833p:plain

 同じように、他のコメントや顔アイコンのテクスチャとかを関数化しよう。関数って複製できたかな。どうやらできるみたい。

f:id:hiyokosabrey:20190907101029p:plain

 ばばっと複製して、Outputs のピンを差し替えればよさそうだ。Duplicateすると関数のグラフに切り替わって、関数名の変更を要求してくる。このあたり、良く設計されているなといつも感心させられる。エディタ作業においてのヒューマンエラーが時間のロスであることを心得ているかのようだ。実際にプロジェクトで使われて叩き上げられてきた結果だろう。

 コメントとUIDについては表示するときにText型にするので、この関数内でキャスト(型変換)しておこう。

f:id:hiyokosabrey:20190907101822p:plain

 一度String型のまま Returnノードに刺して、出力ピンを作ったあと、接続を切って、Detailタブから変数の型をText型に変える。そして改めてストラクチャのBreakノードからつなぐとキャストノードを入れてくれる。こうするとReturnノードの出力ピン名が分かりやすくなる。まぁReturn Value のままでも不都合があるわけはないので好みの問題か。

 イベントグラフに戻って関数をつなぐ。

f:id:hiyokosabrey:20190907102024p:plain

 この調子で差し替えていこう。

f:id:hiyokosabrey:20190907102757p:plain

 スッキリ。

 全体を眺めてみる。

f:id:hiyokosabrey:20190907102938p:plain

 これで、使わなくなった変数を消してフキダシWidgetの編集終了だ。

 

 さて、次はレイアウトWidgetを開く。

 

f:id:hiyokosabrey:20190907103208p:plain

 予想はしてたけど、ちょっと禍々しい感じ。ここは Refresh Nodesの出番だな。

 

f:id:hiyokosabrey:20190907212634p:plain

 

 Breakeノードは isLeft を別のところで使っているので、ノードをなくすことはできないけど、▲ボタンで少しだけ縮めることができる。

f:id:hiyokosabrey:20190907213126p:plain

 かなりスッキリできた。やっとテストできる。

f:id:hiyokosabrey:20190907220808j:plain

 よしよし。今のところいい感じに進んでる。にやけそうになりながら、適当なコメントを入力して一人チャットを楽しんでいると、後ろから声をかけられた。

「どうすか?」

 谷山田か。「おう」と軽く返事をしつつ手を止めて振り返る。

「メッチャできてるじゃないすか?僕もちょこっとだけ触ってみていいすか?」

 座ったまま少し横に移動し、キーボードの前を開けてやると彼は軽快にキーを叩きだした。

「いいすね。メッチャそれっぽい!」

 後は、と言いかけた時、

「鳥囃子さんに見てもらいましょうか?」

「いや、まだできてないとこあるし。もうちょっと」

 まだ見せられるとこまでできている実感がなかったところへ、突然見せようと言われると躊躇してしまう。確かにある程度のチャット感は出てきたと思う。谷山田が声をかけてきたのは、それが顔に出てたのかもしれないな。

「試してみたいことあるし、形になったらまた声かけるよ。」

 こういった返事は、こちらがいいって言うまで見るんじゃねぇよ、という意味合いを滲ませてしまうので、違う言い方にすればよかったと、口に出してから気づく。

「ですよね、突然ですみません。」

 なんとなく察したか。

「楽しみにしてます。それはそうとして、相談があるんですけど。」

「?」

「スタンプを送れるようにできたらなぁと思うんスけど。いけます?」

 なるほど、これが声をかけてきた目的か。とりあえず即答は避ける。

「うーん。そうだなぁ。」

 UMGのテキストは途中に絵文字やアイコンを混ぜるのは難しい。どちらか一方のみの送信なら。

「コメントかスタンプか、モード切り替えみたいにしていいならそんなにかからないと思う。」

 谷山田の顔がぱっと明るくなった。

「まじっスか?じゃぁまたどんな感じになるかできたら、ちょこっと見せてもらっていいスか?」

「わかった。ところで、そのスタンプ誰が描くの?」

 今のプロジェクトチームにUI担当は自分しかいない。イラストを描くようなデザイナーは今キャラ作成に追われて余裕がないはずだ。 なんとなく自分にお鉢が回ってきそうな気がしたので確認してみる。

「実は鳥囃子さんから聞いた話ですけど、チャットやるならスタンプが欲しい、とプロデューサーが言ってきたそうなんス。ご褒美アイテムとか限定プレゼントとかで使えそうじゃん。て言われたとか。」

 ま、ありそうな話だ。まだ肝心な答えを聞いてないので、だまって次を促す。

「で、もちろん人くれるなら、って鳥囃子さんが条件を付けたそうなんですけど、わかったと。」

「トリさんもやる前提かよ。」

思わずニックネームが出てしまったが、突っ込みを入れたくなったのですかさず返す。

「チームポテイトがいったん企画から練り直しになったんで、デザイナーを一時的に開放するらしいんス。」

 あ、チームポテイトといえば立木坂のいるとこじゃなかったか?まぁエンジンの選定に悩んでるような状態って聞いてたし、あまり健康的にビジョンがまとまってなかったんだろう。

「そこから引っ張ってくるそうです。」

「わかった、こころの準備しとく。まずは今のやつを整えてからで。」

「じゃぁ、よろしくお願いしま~す。」

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

 

  やることが増えた。まだモックを作り始めて1日も終わってないのに。本実装の前だからまだいくらでもやりようはあるし、その分柔軟な仕様拡張への準備だってできる。「できた!」って言ってから「実は・・・」と後出しするよりはいい。と考えると、若干もやもやするが、今でよかったと納得することにしよう。

 作業を再開しようとモニターに目を向けると、メッセージが届いたというポップアップが画面の隅に現れた。誰だろう? 立木坂?

 

つづく

 

 

チャットUIを作る

7

 調べてみたら、テキスト入力を扱った記事が見つかった。思ってたよりむずかしくなさそうだ。よしさっそく参考にしながら作ってみよう。そういえば、入力のスタイルを2種類作ってみる、などと谷山田との会話で豪語していたのを思い出した。仕方がない、まずは中央のボックスバージョンからつくろう。

 

 画面のラフデザインはこれだ。

f:id:hiyokosabrey:20190511100114j:plain

 

 新しくWidgetを作成する。名前は wb_WriteBoxCenter にしておこうか。下敷きの見た目はフキダシ用のテクスチャを代用する。あと左右の矢印ボタンを用意すれば作れそうだ。

 

  Photoshopで右向きの矢印を作る。べき乗が大好きなので大きさは 64x128px。左向きは反転すればいい。背景と距離感を出すためにフチドリを付けておこう。

 f:id:hiyokosabrey:20190819234606p:plain

  デザインはテクスチャサイズいっぱいまで詰めない。何事もゆとりは大事。

 

 テクスチャをインポートしたら、新しく作った Widget を開く。まっさらなキャンバスに向かい合いレイアウトのイメージを頭に思い出す。画面の下にそれほど占有しないので、フルスクリーンのキャンバスは必要ないだろう。エディタ右上の設定を変更する。画面のラフデザインから大体のサイズを測ってキャンバスサイズとして設定。

f:id:hiyokosabrey:20190820000828p:plain

 これでUMGに最初から置かれているデフォルトの CanvasPanel のサイズが変更できる。

f:id:hiyokosabrey:20190820001126p:plain

 

 ここに下敷きと、左右の矢印、テキストボックスを配置していこう。

 まずは 下敷きを中央に。Image を置いて、テクスチャにフキダシで使っているやつをセットする。自分専用なのでカラーを変えておこう。配置はストレッチにするけど、左右にボタンをおくから余白を開けておく。

f:id:hiyokosabrey:20190820233644p:plain

f:id:hiyokosabrey:20190820234243p:plain

この設定にしておけば、あとからキャンバスのサイズを変更しても追随するから安心。


 次は左右の矢印。矢印はクリックを受け付けるので、Imageではなく Buttonで配置する。テクスチャと同じくサイズを64x128にしてレイアウトしておこう。

f:id:hiyokosabrey:20190821011755p:plain

 アンカーを右端中央にして、Pivotを(1.0, 0.5)にして、Positionを (0, 0)。あとは、Buttonに画像をセットする。ふるまいに合わせて画像を変えられるけど、今回は同じ画像にしてカラー変更で対応しておこう。通常時の Normal、マウスカーソルが乗った時の Hovered、そしてクリックしたときのPressedの3箇所に矢印のテクスチャ画像をセットする。

f:id:hiyokosabrey:20190821013224p:plain

 右側ができたから、このButtonを複製して左側に配置する。今度はアンカーを左端中央にして、Pivotを(0.0, 0.5)にして、これもPositionを (0, 0) にする。

f:id:hiyokosabrey:20190820004505p:plain

 左側の RenderTransform の Size X を -1.0 にして左右を反転すると、

f:id:hiyokosabrey:20190820004815p:plain

 よしできた。

 あとは、この上にテキストボックスを載せるだけ。えっとどれだっけ?

EditableText (Multi-Line) こっちだな。

f:id:hiyokosabrey:20190821010250p:plain

 これも下敷きと同じようにアンカーはストレッチでいこう。フォントとMarginを設定して、

f:id:hiyokosabrey:20190821010600p:plain

 よし。こんなもんでいいかな。ヒエラルキーはこんな感じになった。

f:id:hiyokosabrey:20190822225631p:plain

 いったん保存して、レイアウトしてみよう。

 

 レイアウト用のWidgetを開いて、User Created のカテゴリから、作ったばかりのテキスト入力Widgetを探すとすぐに見つかった。早速キャンバスに配置する。

 

あれ?

f:id:hiyokosabrey:20190823232533p:plain

 Size To Content にチェックを付けるとつぶれてしまった。あのエディタ右上のキャンバスサイズはあくまでも作業のための設定ということか。仕方がないので手入力でサイズをセットする。 アンカーは中央下端。

f:id:hiyokosabrey:20190822230218p:plain

 試しに変なサイズにしても、ちゃんと問題なく合わせてくれる。

f:id:hiyokosabrey:20190823233236p:plain

 

 

 再生してみると、特に問題なくレイアウトが確認できた。

f:id:hiyokosabrey:20190823002220j:plain

 さて、ボタンをクリックしたときにメッセージをサーバーに飛ばすことになるんだけど、そういえば、左右の振り分けとテキストの送信については相談してなかったな。

 席を立ち、プログラマの南河原さんのところに向かう。プロジェクトがまだ小規模なので、そんなに席が離れていない。背後からおつかれさまですと声をかける。

 「今、大丈夫ですか?」

 彼はコードを吟味していた手を止め「はいはい。」と振り向いた。

 そこで、

 「例のチャット表示を作ってるんですけど、」と切り出し、ユーザーの発言毎に、画面の左右に表示位置を振り分けたいということと、そのユーザーが任意で右か左かを選べるということを再度確認の意味を込めて話した後、

 「テキストと一緒に左か右かの情報をくっつけて送ることになると思うんですよね。もう準備とか始められてたりします?」

 「いや、まだなんも手ぇ付けてない。来週あたりサーバー担当と話しよかなって。」

 うーん、と言ってつかのま考えてから、

 「そうやなぁ、他にも ユーザーID とかアイコン情報とか諸々決めなアカンねんけど、すぐ決めた方がいい?」

 そう訊かれたので、

 「いえ、大丈夫です。プロトタイプなんで適当にやっときます。」

 と答えると、

 「ゴメンな。決まったらまた共有するし。」

 「はい、お願いします。」

 

 ということで、自席に戻って考えてみる。おそらくサーバーへ送信するための関数を用意してもらえると思うので、それをイメージしたテスト用の関数をこちらで用意しよう。あとは受け取り用のフキダシ追加イベントのパラメータを拡張していけばいいだろう。

 今は実装方法を詰めたいわけではなく、とにかくプロトタイプを触って操作感や挙動について検証し、最終的なゴールをプロジェクト内で共有するのが目的だ。そこで見つかった問題を解決し、「余分」と「余白」について検討する。「余分」は「余白」を最大化するための伸びしろだと捉えるようにしている。一方の「余白」は将来の「余裕」と見るか、「不足」と見るかは判断が難しいところだけど、仕様変更や調整の波をかぶりやすいUIにとっては「保険」という意味合いも含ませていいと個人的には考えている。他人には「物足りない」という印象を与えてしまうリスクがあるけれど、「あ、まだ仮なんで」という決めゼリフがあるので問題ない。ちなみにこの決めゼリフを本実装のあとで吐くことになると辛い。声が震えるのを抑えながら言うことになる。

 

 さてと、フキダシとしてサーバーから送られてくるコメントを表示するにあたって、フキダシWidgetが欲しい情報で思いつくのは以下の 5つ。

 

 ①ユーザーID

 ②コメント本文

 ③左か右

 ④顔アイコン

 ⑤自分かどうか

 

 ローカライズはしないのと、加工や整形ができるので ①と②はString型でいいと思う。③と⑤は選択肢としては2つしかないのでBoolean型でいけそう。④はTexture型で。ひとまずこれでストラクチャを使ってみよう。

 

 ストラクチャはコンテンツブラウザで右クリック、Blueprints の中にある。

 chatComment と命名。あとでちゃんとしたやつが来るので、それまでの暫定ネーム。

f:id:hiyokosabrey:20190824204134p:plain

ダブルクリックして中身を編集。

f:id:hiyokosabrey:20190823235936p:plain

 保存して、レイアウト用Widgetに戻る。

 

 まずセットするのは、フキダシを追加するイベントのところ。

f:id:hiyokosabrey:20190824001605p:plain

 イベントノードをフォーカスして、Detailsタブの項目 Inputs からピンを追加する。型は、さっき作ったストラクチャの名前で検索するとリストから見つかるのでそれを選択。

f:id:hiyokosabrey:20190824203838p:plain


 適当に名前を付けると、カスタムイベントのノードに濃い青色のピンが追加された。

 ストラクチャは、複数のデータの寄せ集めな状態なので、一つのピンから情報を個別に取り出す必要がある。そこで Breakノードの出番。

f:id:hiyokosabrey:20190824211609g:plain

 

 Breakノードで分解されたピンから、ストラクチャで自分が追加した CommentBody があるので、選んでダミーテキストをつないでいたところに刺す。

f:id:hiyokosabrey:20190824204640p:plain

 String型とText型は型が違う。このように違う型同士をつなぐ場合、キャスト(型変換)してからつなぐのが儀式なんだけど、UE4のブループリントエディタは直接つなぐことができて、さらに自動的にキャストノードを間に入れてくれるので、ラクチンだ。

 よし、このままフキダシの左右レイアウト対応もやっておこうか。

 まずはダミーコメントの表示で使ってたカウンター処理を外す。

f:id:hiyokosabrey:20190824212844p:plain

 この右端の外したところに、水平方向のレイアウトで、右寄せ、左寄せを決める set Horizontal Alignment ノードをつなぐんだけど、えっとどこからだっけ? VerticalBoxの設定になるから、Add Child to Vertical Box ノードにある、Return Valueから探せば、あ、あったあった。

f:id:hiyokosabrey:20190824213423p:plain

 なんだか、Vertical(垂直)、Horizontal(水平)と混ざり合ってややこしいけど、カテゴリが、 Layout > Vertical Box Slot になってるからここで間違いない。

 出てきたノードをつないで、ラインを整える。

f:id:hiyokosabrey:20190824214406p:plain

 で、この濃い緑のピンにつなぐのは、ストラクチャの isLeft というBoolean型のピンだけど、こんなときは Select ノードの出番。この濃い緑のピンからドラッグして、Select で検索する。

f:id:hiyokosabrey:20190824220501p:plain

 いい感じにノードが見つかって取り出すとき、思わずドラえもんの声真似をしてしまう。大丈夫、声には出てない。このSelectノードの 一番下にあるピンとストラクチャに設定した isLeft ピンとつなぐ。

f:id:hiyokosabrey:20190824221334p:plain

  どう見ても、Integer型のピンだし、Index って書いてあるけど、ここも気にせずつなげることができる。先にプルダウンを開けてBooleanに変えておいてもいい。

 

f:id:hiyokosabrey:20190824222020p:plain

 つなぐと、Selectノードの 左にある入力ピンのラベルが変更される。isLeft の内容が True なら 左。Falseならその逆の右 になるので、それぞれのプルダウンを変更する。

f:id:hiyokosabrey:20190824222518p:plain

 これで、コメントのフキダシが左右に振られるようになったはず。

 

 

 ここで、現状のコメントが表示されている流れを確認しておこう。

 

 スペースキーが押されたかどうかの検出を、レベルブループリントで行っている。

キー入力系のイベントは、Widget内に置けないからだ。

 

f:id:hiyokosabrey:20190825125518p:plain

  レベルブループリントから、レイアウトWidgetにあるフキダシ追加の関数を呼び出され実行している。コメントはダミーで、レイアウトWidgetが内部で持っている。

f:id:hiyokosabrey:20190825125754p:plain

 

 ここまではコメントの表示方法を検証してきたのでこれでも問題なかったけど、コメントを作成して送る表示ができたので、この仕組みを変える必要が出てきた。

 

 受信時はレイアウトWidget経由で、コメントが渡されることになるのは今の状態とそれほど変わらない。一方の送信時はテキスト入力Widgetがトリガーとなって最初に動くことになる。だから機能として追加しないといけないのが、テキスト入力Widgetからの送信を受け付ける流れ。

f:id:hiyokosabrey:20190825161213p:plain



 フキダシWidgetから親であるレイアウトWidgetに通知するには、イベントディスパッチャーで行う。コメントを入力し終わって、左右のボタンをクリックしたら、入力した内容と左右どちらのボタンを押したかの情報を共に通知する。

 

 さっそく、イベントディスパッチャーを追加する。

f:id:hiyokosabrey:20190825161614p:plain

通知するパラメータに Boolean型の isLeft 、String型の commentBody 2つを追加する。

 

 このイベントディスパッチャーを呼び出すのは、左右ボタンをクリックした時だから、OnClicked のイベントを用意しよう。Buttonで作っておいたので、イベントの追加は簡単だ。

f:id:hiyokosabrey:20190825162725p:plain

 緑のボタンをクリックすると、イベントノードをグラフに置いてくれる。

f:id:hiyokosabrey:20190825162936p:plain

 ここにさっき追加したイベントディスパッチャーを ”Call” のカタチで呼び出してつなげる。このイベントはすでに右か左かハッキリしてるので、isLeft のところもあらかじめチェックを付けておくことができる。

f:id:hiyokosabrey:20190825163439p:plain

 あとはにコメントの内容をゲットしてつなげれば出来上がりだ。

 

 コメント自身は、MultiLineEditableText が持っている。そこからGetしよう。

f:id:hiyokosabrey:20190825164251p:plain

 これ最低限の処理はできたけど、判定とかも加えたいので、さらにこれをマクロにする。マクロの方が関数より分岐がやりやすい。GetText~ノードとキャストノードをフォーカスしておいて、右クリック > Collapse to Macroだ。

f:id:hiyokosabrey:20190825165445p:plain

 

 できたマクロを編集する。

f:id:hiyokosabrey:20190825165817p:plain

 まずは、Inputs に Execute ピン を追加する。同じくInputs にある Self ピンの名前を変えておく。 EditableText あたりでいいだろう。

f:id:hiyokosabrey:20190825170420p:plain

 ブランチノードを追加して、Execピンとつなぐ。

f:id:hiyokosabrey:20190825170811p:plain

 続けてブランチノードの右側のピンを、マクロのOutputsにドラッグ&ドロップする。

f:id:hiyokosabrey:20190825171237g:plain

 ピンの順番はここで変更できる。

f:id:hiyokosabrey:20190825171515p:plain

 今ここで判定したいのは、コメントが空だった場合。

 内容が空っぽかどうかを調べるノードとして Text is Empty ノードが用意されているので、これを使う。

f:id:hiyokosabrey:20190825172021p:plain

 これでマクロはひとまずできあがり。マクロの名前は getSubmitText にしておこう。

 

 イベントグラフに戻ってつなぎなおす。

f:id:hiyokosabrey:20190825172455p:plain

 コメントが空の場合、Text is Empty が True(真) になるので、コメントが入っていると、False(偽)になる。理解していてもイベントグラフだけを見るとなんか気持ち悪い。Outputsのピン名を変えよう。もう一度マクロを編集する。

f:id:hiyokosabrey:20190825173033p:plain

 True を Failur(失敗)、FalseをSuccess(成功)にしよう。

f:id:hiyokosabrey:20190825173147p:plain

 うん。解りやすくなった。

 送信した後は、空にしておかないと。

f:id:hiyokosabrey:20190825195921p:plain

 

 これでテキスト入力Widgetは編集完了。次はレイアウトWidgetでバインドしてコメントを受け取れるようしよう。

 

 レイアウトWidgetのキャンバスに置いた、テキスト入力Widget を グラフに取り出して、ed_submitComment にバインドする。そしてバインドノードの Eventピンからカスタムイベントノードを取り出す。

f:id:hiyokosabrey:20190825200546p:plain

 ここにフキダシ追加イベントをつないでみよう。ひとまず表示テストはできるはず。

 

 フキダシ追加イベント addFukidashi は、コメントをストラクチャで受け取るようにしたばかりなので、渡せるようにMakeノードを使う。

f:id:hiyokosabrey:20190825201353p:plain

  ストラクチャへの受け渡しは、まんま同じ型ならそのままつながるけど、単品で値を書き換えたり読み出したりする場合は、 BreakノードとMakeノードを駆使する。ここでは一部分だけ渡したいのでMakeノードが便利。

f:id:hiyokosabrey:20190825201809p:plain

 

 早速テストしてみよう。

f:id:hiyokosabrey:20190825203309j:plain

 左のボタンをクリックすると、

f:id:hiyokosabrey:20190825203335j:plain

 お、いい感じ。適当に飛ばしてみる。

f:id:hiyokosabrey:20190825203352j:plain

  うん大丈夫そうだ。ちゃんと左右に割り振れてる。できてきた感!

 

 あとは、入力中のテキストに文字数制限処理入れたり、入力中かどうかのハイライト処理とかもあった方がいいかな。その前にいい加減アイコン出せるようにしようか。UIDも出さないとな。フキダシの尻尾もちゃんと作らないといけないし。とりあえず休憩しよう。席を立ち空調の効いたフロアを出る。

 

 

つづく

テキスト入力を試してみる

 最近帰りが遅くて、駅から家までの経路に田んぼがあるんですが、毎晩カエルの大合唱を聞きながら歩いて帰宅しています。 月の映る水面をチラ見しながら歩きつつ、ダンジョンメーカーに勤しんでる今日この頃です。はい、歩きスマホはダメですよ~。

 さてさて、訳あってUMGのテキスト入力を試すことにしました。公式のWebドキュメントを見ていると、何やらいくつか種類がある様子。とりあえず最近のエンジンのバージョンで見てみるとこんな感じ。特に変わった様子はない。

f:id:hiyokosabrey:20190627001306p:plain

 公式ではPrimitiveの中にカテゴライズされた画像が貼ってある。いつのVerだろうか。

 

 

見た目

とりあえず、Text で Box なやつをピックアップして並べてみた。

f:id:hiyokosabrey:20190627223539p:plain

 一見すると背景有り無しと、改行ありの複数行タイプか、改行なしの1行のみのタイプ。名前的に EditableText TextBox この2タイプに分けられている理由が分かれば話が早いんだけど、公式ではこれといって言及されてないっぽい。公式以外で触れている情報が少ない。まぁだいたい理由は想像つくけど。

 

 実際に表示してみて試してみると、ほとんど差が分からない。大きな差があるのは、Style という設定項目を持っている TextBox(Multi-Line) 。こいつはスクロールバーも持っている。それ以外の3つは、いつもお世話になっているTextBlock と同じような Appearance を備える程度。

f:id:hiyokosabrey:20190628180632p:plain

f:id:hiyokosabrey:20190628180642p:plain

f:id:hiyokosabrey:20190628180650p:plain

f:id:hiyokosabrey:20190628180659p:plain

 

 機能要件の差とコンポーネントとして作られ実装された時期によるものだと思うけど、さすがにこれはちょっと躊躇う。TextBox(Multi-Line)だけは、Appearance の項目スッキリしていて、見た目の調整は Style という設定カテゴリにまとめてある。

 

f:id:hiyokosabrey:20190628181611p:plain

 

 自分の作りたい見た目が実現可能かどうか、実際に試してみながら判断するしかなさそう。

 

ちなみに、

キャンバスに置くと、is Variable に最初からチェックが付いてて、どちらもブループリントで触れるようになるんだけど、デフォルトの名前とアイコンがこれ↓

 

f:id:hiyokosabrey:20190628213137p:plain

ほとんど同じ。Box 付きは 実線で、 Box無しは 破線のアイコン。

 

 

イベント

 用意されているバインドできるイベントは4種類とも  OnTextChanged と OnTextCommitted の2つ。

 

f:id:hiyokosabrey:20190628174735p:plain

 

 全部置いてみたらこうなった↓

f:id:hiyokosabrey:20190628214027p:plain

 

OnTextChanged~ は内容が変更されるたびに呼ばれるイベント。

OnTextCommitted~ は内容が確定(編集終了という意味合いだと思う)した際に呼ばれるイベント。このボタンからイベントを作って試してみたら、このWidgetのフォーカスが外れた際に、確定したと認識されるらしい。

 

 変数化したオブジェクトから、 イベントを検索してみても専用のやつは上の2種類だけみたい。

Widget Event というカテゴリにある。

f:id:hiyokosabrey:20190628215206p:plain

 

 ところがTextBox だけは違ってて、Text Box というカテゴリが用意されてる。さすがCommonカテゴリに分類されるだけのことはあるとうことか・・・

f:id:hiyokosabrey:20190628215047p:plain

 

 ブループリントからも見た目をいじることができて、Get Style ノードが用意されているけれど、EditableText (Multi-Line) だけは なぜか、 Get Widget Style という名前のノードで別のカテゴリに分類されている。グラフに取り出してみるとこの通り。

f:id:hiyokosabrey:20190628223031p:plain

 こうやって比較してみると、ややこしい事この上ない。まさに 混ぜるなキケン!

 というやつか。

 

 ここまできて、今更ながら思ってたより深い沼だったことが判ってしまった。そっ閉じしてあとはEpicの猫のひとかhistoria様のブログに期待を寄せる方がいいかもしれない。などと弱音を吐いてみる。

 とりあえず、このまま比較していくと、全て検証を終えた時には夏休みも過ぎ2学期が始まってしまっているかもしれないので、どれかに決めて次に進もう。

 

 改行処理を試したいので複数行が扱える EditableText(Multi-Line) に決める。

 

 

 いじる

 背景があった方が大きさが分かりやすいので、テクスチャを用意。

f:id:hiyokosabrey:20190629101837p:plain

この64x64のテクスチャを Image にセットして、Box で描画する。

f:id:hiyokosabrey:20190629103025p:plain

 

とりあえず必要そうなパーツを置いてそれっぽくする。

f:id:hiyokosabrey:20190629102835p:plain

ヒエラルキーは ↓のような状態。

 f:id:hiyokosabrey:20190629103226p:plain

 

 今回、EditableText(Multi-Line) が主人公なのでサイズが固定。これに合わせて他のパーツを調整することになるので、背景(Image)のサイズをEditableTextと一緒にしておき、マージン設定で内側に余白をつくり、見た目の枠と距離をとるようにしています。

f:id:hiyokosabrey:20190629105047p:plain

 EditableTextのサイズが変わっても、サイズをコピペするだけなので、頭使わなくていいというメリットがあります。この辺は好みの分かれるところかもしれないですね。

 

 改行(Wrapping)の設定もチェック。

 Default Wrapping だと、単語と単語の区切りで改行してくれるけど、日本語のように半角のスペースを入れない文字列だと、意図的に改行しない限り、ず~と右にはみ出してしまう。なので、 Allow Per Character Wrapping に変更します。

 f:id:hiyokosabrey:20190630000030p:plain

 

 ボタンをクリックしたときに実行されるOnClickedイベントをバインド。PrintString につないで確認してみる。

f:id:hiyokosabrey:20190629144331p:plain

 

f:id:hiyokosabrey:20190629145601g:plain

 

 改行文字を置換できるか実験。Get Text ノードから PrintStringノードまでを関数にする。

f:id:hiyokosabrey:20190629152105p:plain

 

 文字列をゴニョゴニョするには、Text型を 一旦 String型にしてやる必要がある。関数にすると、ローカル変数が使えるから一時的にStringの処理をするにはうってつけ。

 関数の中身はこんな感じ。TempStr というのがローカル変数。

f:id:hiyokosabrey:20190629152521p:plain

 Replace ノードは From に置換対象の文字列を入れて、To に 入れ替える文字列を入れて使う。Shift キーを押しながら、Enter キーを押すと、改行文字が入力できるので、From に改行文字を、 To に  <> を入れて試してみる。

 

f:id:hiyokosabrey:20190629153145p:plain

 

 無事置換できた。

 

 次は、行数に制限をかける方法を考えたい。

f:id:hiyokosabrey:20190629154714p:plain

 

 それっぽいノードや設定項目はなさそう。

 とりあえずWidget Reflector で見てみると、

f:id:hiyokosabrey:20190629172843p:plain

 Desired Size が入力した文字によって変動しているのが判った。

 内容が変更されると呼ばれるイベントでGet Desired Size ノードで調べて表示させてみる。

f:id:hiyokosabrey:20190629173223p:plain

 1行・・・52.590

 2行・・・89.181 (+36.591)

 3行・・・125.771 (+36.59)

 4行・・・162.362 (+36.591)

 5行・・・198.952 (+36.59)

 6行・・・235.543 (+36.591)

 

いったん一つ前の内容をキャッシュしておいて、オーバーしたら、強制的にキャッシュで上書きするというのを試してみる。

f:id:hiyokosabrey:20190629180422p:plain

  どうやらDesired Size の値が遅れていることが判明。内容が変化したタイミングでは、Desired Size が更新されていない様子。Reflectorではきっちり取れてたっぽいのだけど。

 

ということで Force Layout Prepass を入れてみたらうまくいった。

f:id:hiyokosabrey:20190629181235p:plain

 

 改行文字を置換する関数を少し整えて、結果をReturnValueにして外に出すようにする。ついでに、キャッシュ用の変数も更新。関数名をFormatTextToStringに変更。

f:id:hiyokosabrey:20190629201931p:plain

 

 ちょっとした演出を作ってみます。

 

まずは、文字を削る関数を用意します。

f:id:hiyokosabrey:20190629203733p:plain

ここでもEditableTextの内容を一旦ローカル変数に入れて、 Right Chop というノードで一文字削って また元に戻しています。

 

この関数を動かすために、カスタムイベントを新しく作ります。

f:id:hiyokosabrey:20190629204050p:plain

結果を見て、引き続き実行するかしないかを分岐します。文字の数だけこのカスタムイベントが実行されます。

 

あとは、送るボタンを押した時に、このカスタムイベントを呼べばいいだけ。

f:id:hiyokosabrey:20190629204310p:plain

 

Playしてみると。

f:id:hiyokosabrey:20190629205131g:plain

送ってる感が出てる気がする。

 

ひとまずこんなとこかな。

 

 

おまけ

ビヘイビアの設定をちょっとだけ確認してみた。

 

■ Select All Text when Focused   初期値:false

これを有効にすると、フォーカスした際に、テキストが全選択された状態になる。

コピペさせたい時に使えそう。

 

■ Clear Text Selection on Focus Loss  初期値:true

選択中の文字列がハイライトされた状態を維持するかどうか。デフォルトだと、フォーカスが他に移った時点でハイライト(Selection)がクリアされる。

 

■ Revert Text on Escape  初期値:false

入力中のテキストを一つ前の状態に戻すかどうか。フォーカスアウトした際にテキストの内容が確定してどこかしらに保存されるようで、内容を書き換えて ESCキーを押すと、フォーカスアウトした時点に戻る。書きかけでも安心。

 

■ Clear Keyboard Focus on Commite  初期値:true

キーボードでのフォーカス遷移に関係してそうだけど、うまく検証できなかった

 

■ Allow Context Menu  初期値:true

 いわゆる右クリックメニュー。有効にするかしないか。

f:id:hiyokosabrey:20190629224351p:plain

 

そういえば、 Appearance の設定で気になるのがあって、まだ使い方が分かってないんだけど、あれは リッチテキスト用かな?また機会があれば触ってみたいと思います。

 

 

最後に

今回の文字入力用Widgetについてあまり記事が上がっていない件で、思いつく範囲で少し触れてみたいと思います。

使い方はそれほど難しいものでもない。

というのが、あえて記事に取り上げる意欲が湧かない要因だと思いますが、ゲームでユーザーのテキスト入力を扱うということは、とてもたくさんのリスクを作り手側が負うことになるので、慎重にならざるを得ないのが実情で、これによって扱わない開発者も多いのでは、というのも結構大きな要因かと思います。

まずこのリスクをいくつか挙げておきます。

 

 アジア圏の文字種の多さ。これは多言語対応する場合はフォントの選択肢が現状ほぼありません。表示できない文字が出てくる。

 フォントの契約によっては、ユーザーが自由に文字組を編集できるということがライセンス許諾外になることが多く、その場合追加のライセンス料が発生することがある。

 差別や性的、侮辱的、ドラッグ絡みなどのNGワードの置き換え処理が大変。オンラインだと多言語での対応になるので。日々ネットスラングが生まれる現状でセンシティブな内容にどこまでシステムがフォローできるかは頭の痛い問題。置き換えをあきらめた場合は、ダイアログウィンドウで事前に告知したり、不快な文章を発信しているユーザーを報告したりキックできる仕組みが必須になります。

 オンラインの場合、UGC(UserGeneratedContents)になりうるので、これもゲームの場合、CEROESRBなど、レーティングが上がることになります。

 

 ちょっと前に流行ったのは自由文ではなく、定型文の組みあわせによる文字列生成。

これはフォントの問題は解決できるし、事前に翻訳できるので多言語対応しやすい。

最近ではスタンプもよく見かけます。

 

 ユーザーが文字入力できるというのはそれなりに覚悟がいるので、実装経験が少ないということだろうと、勝手に推測しています。

 

 

ではでは

今回はこの辺で

ステキな文字入力ライフを!

 

 

 

 

 

チャットUIを作る

6

 ListViewはまた今度時間作っていじってみようと心に決め、VerticalBoxでスクロールアウトした部分の処理について考えることにする。できれば削除せずににひたすらスクロールさせれることができればいいのだけど。短いとはいえ2分程度の観戦時間でもかなりの量のフキダシを抱えることになるだろうから、適度に軽くしてやらないといけない。プログラマにお願いしたいところだけど、見た目の調整も含め設計をやっている以上こちらである程度カタチにしてからの方が、問題点を見つけやすいし改善点についても相談しやすくなる。デザイナーが何をしようとしているのか、どういう部分の見た目にこだわっているのか、といったようなことが口頭だと伝わりにくいので、それなりに動くプロトタイプは結果的に無駄な連携コストを下げることができると思う。実をいうと単に作ってみたいだけだったりする。

 

 まずは確実に画面外に出たかどうかが分かれば、その要素を削除して、間が詰まったことを悟らせないようにする。まず思いつくのは移動した分を戻す方法。

 

f:id:hiyokosabrey:20190615214502p:plain

 

 要素が削除されると当然次の子要素が上がってくる。上に詰められた高さぶんを瞬間的に移動させて、何事もなかったかのようにしないといけない。 

 

f:id:hiyokosabrey:20190616201829p:plain

 

 配列の削除と位置移動を瞬間的に行うことになるので処理落ちした時に大丈夫か心配にはなるけど、その辺の危険性はこのプロトタイプができてからプログラマに訊いてみよう。もっと素敵な方法があればあとから構造を変えればいい。あらかじめ一番上にスペーサーを入れておいて、フキダシを消してからサイズを変更するとか、Paddingの設定でスキマを調整するのもありかもしれない。それはそれで、投稿数が多くなれば危険か。VerticalBoxを使わないというのもありかもしれない。おっといけない。プロトタイプは作ってから検証しないとな。どんどん作ろう。

 

 画面から出たかどうかの判定はどうするか。フキダシ毎に高さが変わるので、フキダシの高さを保存しておく変数が必要だ。画面にいくつも並ぶからそのぶんの変数が要るとなると配列だな。

f:id:hiyokosabrey:20190615212243p:plain

  これは、イベントディスパッチャーから返ってきた値を受け取るイベントがあったから、そこで積もう。

f:id:hiyokosabrey:20190615220503p:plain

  保存した高さは、画面外に出た量と比較するときに使って、また位置を戻すときの量にもなる。設定したMarginの分も入れとかないと。

 

 次は削除イベント作ろうかな。まずはカスタムイベントを置いて、と。

f:id:hiyokosabrey:20190615224133p:plain

 VerticalBoxから一番上に積んであるフキダシ、つまり子要素の削除だから、child で検索すると・・・あった。Remove Child Atノード。

f:id:hiyokosabrey:20190615224555p:plain

 Index番号は常に先頭を削除するから 0のままでOKだ。

 削除したぶんの高さを移動するから、Set Render Translation ノードをつないで。

f:id:hiyokosabrey:20190615225327p:plain

 VerticalBoxの座標は、positionCurrent 変数が持ってるから、そこから差し引けばいいかな。VerticalBoxの子要素削除と移動は処理に間を空けたくないから、事前に計算しておこう。

f:id:hiyokosabrey:20190615230138p:plain

 

 あとは、高さの配列も先頭のやつを削除しておかないとズレてしまう。

f:id:hiyokosabrey:20190616003817p:plain

 

 現在地の座標を下げたら、目的地の座標も下げないと。

f:id:hiyokosabrey:20190616004123p:plain

 よし、ひとまずこれで必要そうな処理はできたはず。このイベントを呼ぶためにチェックするのは座標を更新してるTickで。

f:id:hiyokosabrey:20190616005631p:plain

 

 さてどう比較するかだけど、VerticalBox は画面の下から上に向かって伸びていく。Translation の値は0から増えていくから、はみ出すころには画面の高さを越えてるはず。今回解像度は1080p想定だから、これをスクロール量から引けばいいのか。

f:id:hiyokosabrey:20190616012144p:plain

  こうかな。

f:id:hiyokosabrey:20190616014648p:plain

 よし試してみよう。

f:id:hiyokosabrey:20190616111906g:plain

 ってあれ?

f:id:hiyokosabrey:20190616193504g:plain

 なぜ戻る?目的地と現在地を一緒に戻してるからズレないはずだけど・・・

 

 あ、ここか!

f:id:hiyokosabrey:20190616195708p:plain

 高さをキャッシュしている配列の先頭がいなくなってから目的地を戻してる。それはズレるな。悔しい。順番を逆にしないと。

f:id:hiyokosabrey:20190616195924p:plain

 ふう、これで大丈夫。再生してみても問題なし。

 今は処理に余裕があるから問題ないように見えているだけかもしれないけど。

 

 そうだ、フキダシの追加と削除は随時いろんなタイミングで行われるから、 Tick処理の停止を入れておこう。

 Booleanでフラグを作って。

f:id:hiyokosabrey:20190616112749p:plain

 まずはここで止めねば。

f:id:hiyokosabrey:20190616114019p:plain

 そして初期値が false だからこのWidgetがViewortに置かれた時点ではTickの処理はここで止まり、先へは走らないようになった。となると、このTickを動くようにする蛇口に相当するトリガーのようなものが必要になる。それは、フキダシを追加した後だな。

 バインドしたイベントディスパッチャーの受け取りイベントの最後で、フラグを true にする。ただしここはフキダシが追加される度に来るから、DoOnce ノード入れておこう。

f:id:hiyokosabrey:20190616181131p:plain

 これで、初めてフキダシが追加されて、高さの値が返ってきたらTick開始となる。

 あとは、フラグを false にする部分だけど、フキダシの削除が決定したBrachのところが最適だろう。Tickは常時ものすごく短い間隔で処理されるから少しでもタイムラグをなくしたい。

f:id:hiyokosabrey:20190616181847p:plain

 

 この辺で一旦流れを確認してみよう。

 

1.このWidgetが Viewportに 追加されるとき isAnimEnable は false だからTickは動かない

2.フキダシ「追加」のイベントが呼ばれる まだ isAnimEnable は false

3.バインドしたフキダシWidgetから値が返ってきた ここで isAnimEnable を true

  ※初回の1回だけ

4.Tick が動きだして、VerticalBox が移動を始め、はみだしチェック常時行う

5.はみだし量が先頭のフキダシの高さを超えたので isAnimEnable を false にして Tick止める

6.フキダシ「削除」のイベントしてVerticalBoxの位置を戻す

7.フキダシは随時追加されるたびにスクロールの目的地は増え続けている

8.Tick再開・・・

 

 おっと、 isAnimEnable を 再び true にするの忘れてた。

 フキダシ削除イベントの最後でいいかな。

f:id:hiyokosabrey:20190616200127p:plain

 よし、これで動かしてみて問題なさそうだったら次に進める。

 

f:id:hiyokosabrey:20190616200502g:plain

 大丈夫そう。ちょっとグラフを眺めてみるか。基本の処理はスクロール担当の EventTick と、フキダシの追加と削除の 3つだ。

 

・EventTick

f:id:hiyokosabrey:20190616223018p:plain

・addFukidashi

f:id:hiyokosabrey:20190616223234p:plain

・removeFukidashi

f:id:hiyokosabrey:20190616223531p:plain


あとは、ダミーテキスト用の関数。

f:id:hiyokosabrey:20190616223913p:plain

 

 フキダシの表示は大体できたも同然だな。左右のレイアウト切り替えと顔アイコン、フキダシのしっぽは、パーツを追加すればいい程度だしそんなに心配するような難しさじゃないと思いたい。やっぱりいよいよ入力フォームかな。なんだか緊張する。

 硬くなった筋をほぐすように首と肩を動かす。プログラマたちの談笑が聞こえる。そういえばずっと聞こえていたような気がするが、それだけ集中できていたということだろう。

 さた、フォームはやったことないから、調べないとな。

 

 

つづく

 

 

 

 

 

 

 

 

チャットUIを作る

5

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

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

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

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

 

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

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

f:id:hiyokosabrey:20190604222131p:plain

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

f:id:hiyokosabrey:20190604222259p:plain

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

 

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

f:id:hiyokosabrey:20190604224540p:plain

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

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

f:id:hiyokosabrey:20190604225259p:plain

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

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

 アンカーを変更して、

f:id:hiyokosabrey:20190604231155p:plain

 Position Y を 0 にすればいい。

f:id:hiyokosabrey:20190604230918p:plain

 

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

f:id:hiyokosabrey:20190604234802g:plain

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

f:id:hiyokosabrey:20190604235611p:plain

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

f:id:hiyokosabrey:20190605000350p:plain

 これでどうかな?

f:id:hiyokosabrey:20190605004541g:plain

 なかなかいい感じ。

 

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

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

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

 

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

f:id:hiyokosabrey:20190609011023p:plain

 次は?

 

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

 

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

f:id:hiyokosabrey:20190609223210p:plain

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

 

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

 

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

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

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

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

f:id:hiyokosabrey:20190609232047p:plain

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

 

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

f:id:hiyokosabrey:20190609232633p:plain

 

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

f:id:hiyokosabrey:20190609201627p:plain

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

f:id:hiyokosabrey:20190609221040p:plain

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

 

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

 

f:id:hiyokosabrey:20190609221345p:plain

 ここは問題なさそう。

 

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

f:id:hiyokosabrey:20190609222026p:plain

 再生してみると。

f:id:hiyokosabrey:20190609233533j:plain

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

f:id:hiyokosabrey:20190609234046p:plain

 

f:id:hiyokosabrey:20190609234236j:plain

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

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

f:id:hiyokosabrey:20190610000813p:plain

 

 ・・・

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

 

 

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

 

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

f:id:hiyokosabrey:20190609235548p:plain

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

 

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

f:id:hiyokosabrey:20190610001237p:plain

 これでどうかな。

f:id:hiyokosabrey:20190610001418j:plain

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

 

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

 ふぅ、ちょっと休憩。

 

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

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

「おつかれさまです」

 明るい声だ。

「おつかれさま」

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

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

 ムンムンって。

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

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

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

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

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

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

「うん」

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

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

「どっちって?」

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

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

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

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

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

「そうなんですよね~」

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

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

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

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

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

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

 

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

 

 

 

 

 

 

チャットUIを作る

4

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

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

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

 

f:id:hiyokosabrey:20190526122640p:plain



 

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

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

f:id:hiyokosabrey:20190524235925p:plain

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

f:id:hiyokosabrey:20190525004801p:plain

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

f:id:hiyokosabrey:20190525004621p:plain

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

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

f:id:hiyokosabrey:20190525001535p:plain

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

f:id:hiyokosabrey:20190525002114p:plain

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

f:id:hiyokosabrey:20190525002946p:plain

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

f:id:hiyokosabrey:20190525004935p:plain

 よし、これで再生だ。

f:id:hiyokosabrey:20190525005421g:plain

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

f:id:hiyokosabrey:20190525005721p:plain

 

 ・・・

 

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

f:id:hiyokosabrey:20190525010332p:plain

 どうかな?

f:id:hiyokosabrey:20190525010548g:plain

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

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

f:id:hiyokosabrey:20190525012148p:plain

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

f:id:hiyokosabrey:20190525012451g:plain

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

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

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

 limesode.hatenablog.com

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

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

 

f:id:hiyokosabrey:20190525133453p:plain

 

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

 f:id:hiyokosabrey:20190525194814p:plain

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

f:id:hiyokosabrey:20190525195115p:plain

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

f:id:hiyokosabrey:20190525201225p:plain

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

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

 

f:id:hiyokosabrey:20190525195429p:plain

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

f:id:hiyokosabrey:20190525200016p:plain

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

f:id:hiyokosabrey:20190525200429p:plain

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

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

f:id:hiyokosabrey:20190525212731p:plain

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

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

f:id:hiyokosabrey:20190525212849p:plain

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

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

f:id:hiyokosabrey:20190525213308p:plain

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

 

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

f:id:hiyokosabrey:20190525213835p:plain

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

f:id:hiyokosabrey:20190525222641p:plain

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

f:id:hiyokosabrey:20190525223243g:plain

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

 

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

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

 

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

f:id:hiyokosabrey:20190525225214p:plain

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

f:id:hiyokosabrey:20190525224913p:plain

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

f:id:hiyokosabrey:20190525230009g:plain

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

f:id:hiyokosabrey:20190525232255p:plain

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

 

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

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

 

 

つづく