みつまめ杏仁

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

チャットUIを作る

 12

 予定通りディレクターへのお披露目の時間になり、それほど広くないスペースに召集された4人が密集する。一気に湿度と気温が上がるような気がする。

 あらかじめ動作確認程度にはセッティングを済ませておいた。いつもの軽い挨拶を交わした後ディレクターに直接触ってもらう。

 「チャット画面でコメントを入力するときに、左右のどちら側に飛ばすか、という仕様に対して、2タイプのUIを考えました」

 「まずは中央で、コメントを書き終えてからどちらにするか選ぶタイプ」

 

f:id:hiyokosabrey:20191024224843j:plain

 

 適当に軽い感じのコメントを打ち込みながらうなずく。

 「ふんふん、なるほどね。いいね。はいはい」

 少し改まった感じの空気で始まったので、ややディレクターの反応も固い気がする。予定が空いていたとはいえわざわざ集まるからには、ここに集まったメンバー全員何かしら判断や決定、相談などの重要な案件であることを意識しているだろうけど、もう少し雑談から始めても良かったかもしれない。

 「もう一つは、あらかじめ入力する場所が左右に分かれてるタイプ」

 ちょっと失礼しますと言って、マウス操作でブランチノードの値を切り替えてタイプを変更して見せる。

 「え? 今ので、切り替わるの?」

 「はい」

 入力用のWidgetを2つレイアウトしておいて、表示のON/OFFを切り替えているだけだが、今の驚き様を見る限り、警戒しておくに越したことはない。

 

f:id:hiyokosabrey:20191024224904j:plain

 

  こちらのタイプも適当に文字を打ち込んで試しながら。「うんうん、なるほど、なるほど」という反応。テンションはそれほど違いが無い印象。

 

 「どうです?」

 と谷山田が訊く。

 「うん、悪くないね。企画書見てからあっという間にここまで作れるのすごいね」

 「ええ、まぁ、そこがアンリアルエンジンの素晴らしいところです」

 ここぞとばかりに、UE4推しの返答をする。

 「う~ん、選ぶとなると難しいな。どっちも機能的には出来てるし、使い勝手も悪くない。UI的にはどっちがいいと思う?」

 できれば選んでほしくない決定に向かう気配を感じていたので、ここで水を向けられるのはチャンスかもしれない。

 「そうですね、ポイントはコメントする前に、どちらにメッセージを飛ばすかが決っているかどうかだと思います。さきに決めて書き始める場合、左右に分かれたタイプの方が分かりやすいですし、とりあえずコメントを打ってから、どっちにするか決める場合は中央の方が向いてそうです。コメントを入力中に会話の流れが変わることを考えると、中央の方が状況に対して融通が利く感じでしょうか」

 まずはそれぞれのタイプが持つ特徴について、あまり重みを付けずに説明したつもりだが、ここで息を整える。少しは議論の焦点を絞れたのではないだろうか。

 そこへ「ですよね」と谷山田が続ける。

 「僕も仕様書書いた後にちょこっと考えてまして、どちらに書くかという選択って、気持ち的にいつなのかという」

 うんうん。

 「やっぱ書く前かなぁと思うんスけどね」

 「説明されんと戸惑うやろな」

 「うん、左右に分けてコメントするという仕様自体が普通じゃなくて、既存のチャットUIからしたら、なまじ踏襲しているスタイルだから初見で仕様の意図を理解できる人はいないと思うんだよ。この辺どう説明するかも考えないとな・・・」

 時間をかけて一般化したUIに新な仕様を入れることは難しい。一度慣れたものを壊すのは勇気がいる。また授業料を払わされるのを嫌ってクレームをつけられる可能性が高い。そもそも右側に自分のフキダシがくるのが定番みたいになってるから、左右のフキダシが1P2Pサイドの陣営ぽくなってるのをどう説明する・・・?ここでふとイメージが閃いた。

 ちょっと失礼、といいながら起動しっぱなしのPhotoshopのウィンドウをアクティブにする。以前に作ったデザインラフのドキュメントを開く。

 「ここは1P2Pのカラーを反映したらいけるかもしれません」

  左右のフキダシと入力用ボタンに色を付けてゆく。

 「カラーは後で調整しますんで、とりあえず・・・」

 途中で意図を察した谷山田が声を上げた。

 「なるほど!これなら分かりやすくなりますね」

 

f:id:hiyokosabrey:20191022001544j:plain

 

 「自分のフキダシも統一したカラーになりますが、自分のアイコンを見失うことはないはずなので、それほど心配ないかと」

 「確かに、確かに!」

 ディレクターの顔色が明るくなって、心なしか声のトーンも上がっている。

 

 「中央入力のタイプだとこんな感じでしょうか?」

 レイヤーの表示を切り替えてグラデーションをオーバーレイする。

 

f:id:hiyokosabrey:20191022002535j:plain

 

 「自分のコメントだけ文字の色が違うのいいかも!」

 「こうして見てると、左右の陣営がハッキリしてきて、仕様が分かりやすくなった分、中央入力タイプだっけ?この真ん中のタイプは迷ってる感があるね」

 「やっぱり、書き始める前にどちらの陣営に書くか決ってると思うんスよ」

 「だな。じゃぁこっちの左右分かれた方で行こう!」

 よし、なんとか決まった。両方実装してオプションで切り替えようとか言い出したらどうしようか不安だったけど、無事着地できて一安心だ。両方とも実装というのは、改造やら調整等メンテナンスのコストが地味に重たくなるので避けたかった。

 両サイドで入力する方が、画面は少しうるさくはなるけど結果的に分かりやすくできそうだ。中央入力のタイプはまとまっているけど、操作後の結果が想像しにくいので、操作事故の可能性も想定しないといけない。

 「ちょっとだけ改造してみますね」といってエディタを開く。

 操作しながら気になった質問を投げる。

 「ちなみに、どちらの陣営でもないコメントを送りたいときどうします?」

 考えてもらってる間にフキダシWidgetの左右反転表示するためのマクロを編集する。

 

f:id:hiyokosabrey:20191024225434p:plain

 

 ちょっとの間、ノードの編集を眺めていたディレクターが口を開く。

 「まぁ部屋を作って集まるメンバーといえば、どちらかの知り合いだろうし、まったく知らないプレイヤーを観戦することはほぼないと思うから、おのずと知人の方に付くと思う。それとなく応援って感じで。むしろ左右に分かれることで、プレイに関係ないコメントが自然と控えられたりしない?まぁ使い始めたら、意外と気にしないかもしれないし、また違った方向に向かうこともあるかもな。」

 「確かに」と谷山田が受ける。

 UIは考えつく限りの使い方を想定して設計するけど、やっぱり想定外の使われ方をされることがあるのが面白いし、怖いところでもある。

 左右に分けた入力仕様と表示についてそんなに気にしなくてもいいかもと、今更ディレクター自身が言うと身も蓋も無い気がするけど、今は試せる表現を少しでも探っておこう。

 

 次にテキスト入力Widget を開いて、キャンバス上でカラーを付ける。

 

f:id:hiyokosabrey:20191024231228p:plain

 

 「まぁ、いっかいこれでやってみて、キビシイ意見が出るようだったら、サイアク片側だけにしよう。QAメンバーに伺ってからだと遅いかな?大丈夫?」

 ディレクターはそう言いながら、チラっとリードプロフラマの南河原さんに視線を送る。

 「QAのキックオフは来月やったと思うけど、そのころはまだネットワークの準備できてないんで、今日みたいにエディタで触らせるくらいやけど。いい?」

 「あ、意見聞くだけなんで僕の方から話ししておきます。」

 この辺をさくっと融通できるディレクターのポジションは強い。

 ロケテストやユーザーテスト、フォーカステストなどのリリース前に行うテストで問題点をあぶり出せるのは理想だけど、テスターの確保やNDA(秘密保持契約)等の手続き関連、場所のセッティング、いろいろやることが多く人員に余裕のないプロダクションだと、中の人は面倒がって積極的にやろうとはしない。うちも会社規模はそんなに大きくはない。5年ほど前にQA部門が新設されたけど、常駐のスタッフは2名しかいなくて、外のQA専門会社との窓口役が基本業務だと聞いている。すでにいくつかのプロジェクトを扱っているので、それなりの経験則があると期待されているのだろう。また、QAから上がってくるレポートはすべてディレクターがチェックして、仕様とするか修正するかのジャッジを行う。そこでのやり取りで得た信頼もあるだろう。そんなQAメンバーにも意見がもらえる流れになったので、ここはありがたく受けよう。

 コンパイルが成功したので再生する。

 

  「できました。」

 「どれどれ、おー」

 さっそく入力して確かめる。

 

f:id:hiyokosabrey:20191024233931j:plain

 

 「色は後で調整します」

 「そうっスね、このカラーだとジェンダーを意識しちゃいそうです」

 「いやぁ面白いねUE4

 ここで別のアイデアを思い付いた。「ちょっとすみません」といいながら再びPhotoshopをアクティブにする。

 「フキダシの色はそのままでもいいかもしれません。」

 「エンジンの方ではこのグラデーションを置いてないのですが」

 といいながらレイヤーを操作する。

 

f:id:hiyokosabrey:20191026110242j:plain

 

 「なるほどね、フキダシの色は中立で、対立している感じはマイルドになった。」

 「ただ、背景の色味によっては効果的じゃない気もします」

 自分で思いついて試してみたものの、それほどキャッチーではなかった。

 ここで、もう一つ思いついていたのがあったので、この際試してみてもらおう。

 「あ、もうちょっと時間いいですか? いいアイデアを思いつきました」

 「いいよ」

 「適当に歓談でもしておいてください」

 何が始まるのかと、見守る空気になったけど、すぐに谷山田が話題を提供してくれたので、そこからしばし歓談タイムとなった。

 「え!マジで?!」「めっちゃ強いっス」「俺なんか」「40連したけど出なかった」「ちょ~」「!」「ほんまや!」「?」「だー」 ・・・

 

 「できました」

 

f:id:hiyokosabrey:20191026111750j:plain

 

 「おお!いいじゃんいいじゃん!普通のチャット感あるし、さりげなくボタンの色がフキダシにも入ってて、まったくの無関係じゃなくなってるのイイネ」

 「これっスよ!」

 谷山田の尻馬感のある言葉に苦笑いしつつも、手応えを感じられて気分が軽くなった。 

 「これで行きましょう」

 「南河原さん大丈夫っスか?」

 「ええんちゃう」

 「じゃぁこれで進めますね」

 「よろしくです」

 これでお披露目会はお開きとなった。

 

 結局、完全決定とはならず、少し先送りになった分は油断はできないけど、少なくともモックのせいでチャットそのものに難色が示されることはなかったし、採用さ入力方式のタイプがひとつに決まったので、この先の機能を作り込むのに迷いがなくなったのはありがたい。いくつか問題点を検討できたし、解決策も見えてきた。やっぱりモックを作ってすぐに触れるのはいいなぁ。と一人UE4のありがたみを噛みしめる。

 

 さっそくデザインの改修について、Widgetのパーツをどう変えようか考えながら、コーヒーでも買いに行こうと席を立った。あ、ついでにスタンプの進捗でも見に行ってみよう。

 

 

※この物語はフィクションです。実在の人物・団体などとはいっさい関係がありません。

チャットUIを作る

11

 再生してみると、テキストを何度か入力してうちにズレてくる。手で改行を入れる一つ前の入力タイプでは、自然とこの問題を回避できていたのだ。表示バグというやつだ。

 入力方法の違う2タイプを作ったことで、結果的にモックの段階で発見できたのは良かったが、さて、どうやって解決したものか・・・

 フキダシWidgetの高さを返すところで、UIDをセットしている部分をちょこっといじる。

f:id:hiyokosabrey:20191009214754p:plain

適当な文字列を入力して確認してみる。

f:id:hiyokosabrey:20191009214627j:plain

 

 どうやら自動改行が入った場合、何かしらの条件で正しく行数が計測されないということがわかった。間の半角スペースの数を変えたり、文字を変えたり、いろいろ試してみたけど、今一つこれだ、という法則のようなものにたどり着けない。入力のタイミング的なものかもしれないと思い、クリップボードに入れておいた文字列を適当なタイミングで出力してみると、これは必ず同じ値になる。ということはやはり、改行処理にかかる時間か何かが関係している気がする。Get Desired Size のタイミングなのだろうか。

 改行のルールも今一つピンとこない。適当な文字列を入力して試しているときに気づいたのがこれ。

f:id:hiyokosabrey:20191009222920j:plain

 2つ目の入力で aaa a aaa と入力すると短いセンテンスなのに改行された。真ん中の a が冠詞として判断されたのかと思い、アルファベットb~zに変えて入力してみたら、 i j l のアイ、ジェイ、エル については改行されなかった。文字の幅?と思ってたら、m と w でも改行されなかった。まだまだ自分の知識の及ばない世界のラテン文字文化圏のルールか何かがあるのかもしれない。こんな短いセンテンスでも改行されるうえに、サイズ取得がうまくいかないということで、より謎が深まってしまった。

 首をひねっていると、周りで人の動く気配がする。時計を見ると12時だった。もうこんな時間か。結構集中していたようで伸びをして固くなった背中と首をほぐす。よし気分転換しよう。

 

  外に出てみると、気持ちよく晴れていた。澄んだ空の色がさっきのモヤモヤした気分をいっとき忘れさせてくれたけど、すぐに思い出してしまったので、いつもの書店へは向かわず、コンビニに行くことにした。このまま歩いていると会社に戻るのを忘れてしまいそうで、できれば永遠に忘れてしまいたかったけど、早くこのモヤモヤを解消したいという気持ちが、わずかな責任感という協力を得て勝利を収めた。

 コンビニで適当な炭水化物と適当なお茶を入手。適当なルートを歩いていたらいつの間にか自分の椅子に腰掛けていた。対策を考えながらぼんやりと歩いていたので、まったく気分転換できていない気がする。適当に選んだおにぎりを食べながらノードをいじる。

 Auto Wrapping(自動改行)に頼る以上は、この処理が終ってから高さを調べればいいのだけど、それはタイミング的にいつなのか分からない。描画処理が少しでも進めば良さそうだけど、Tick使ってみるか。

 テキストを流し込んだ後の部分で接続を切る。

f:id:hiyokosabrey:20191010004306p:plain

 Force Layout Prepass ノードとTick をつなぐんだけど、1回でいいので、Do Once ノード入れておこう。

f:id:hiyokosabrey:20191010004617p:plain

 これで再生してみる。

f:id:hiyokosabrey:20191010004839j:plain

 ダメか。

 もう少し進めたらうまくいくのかな。ものは試しで、delayノードを入れてみよう。

まずは Duration を 0.0 で。f:id:hiyokosabrey:20191010005222p:plain

 これでどうだ?

f:id:hiyokosabrey:20191010005459j:plain

 お、端数が出てきた。なんか精度が上がった? でもうまくいってるっぽい。

 ちょっとスマートじゃないけどなんとかなったかな。

 

 最初から改行が入っていると問題はないので、このTick処理が負担になるようだったら、入力フォームをあらかじめ3行にしてしまうのが無難だろう。とにかくモックを仕上げて入力のタイプを決めないと。

 

 ちょうど誰かがセットした目覚ましのアラームが昼休みの終了を告げる。

 UIDの表示を戻して、谷山田を呼びに行く。ゲーム系情報サイトを眺めていた彼は声をかけるとすぐに来てくれた。入力タイプの違う2つを順番に再生して触らせる。

 「うん、うん、いいっスね。」

 「ほうほう」

 ひとしきり触ってから、

 「Dに見てもらいましょう。ちょこっと予定聞いてきますね。」

 と言って立ち上がると、鳥囃子ディレクターのところに向かった。そんなに広いフロアではないし、ほとんど人がうろうろしない職場なので、パーテーションより背が高く動く物体は目で追いやすい。

 どうやら席にいないようだ。そのまま彼は自分の席でPCに向かって操作を始めた。恐らく予定管理ソフトで予定を確認しているのだろう。しばらくして再びこちらに戻ってきた。

 「今ミーティングみたいッスね。予定入れておくんで、後でまたお願いします。」

 「分かった。」

 ということで一時解散することになり、谷山田は自席に戻って行った。コーヒーを飲みたくなったので、いつもの自動販売機コーナーへと向かう。エレベーターから降りると人影があった。

 「あぁ、なんとバッタリ!」

 目が会った。立木坂だった。

 「お、おう、おつかれ。」

 いきなりな言葉で咄嗟に切り返すことができず、動揺してしまった。疲れるから妙なタイミングでこちらの意表を突くのをやめていただきたい。

 「おつかれさまです~」

 手に何も持ってないところを見るとまだ買っていないようだ。すると、

 「あ、どうぞどうぞ。」

 少し下がって自販機の前を空けてくれた。ホットかアイスかも決めていなかったので、急に譲られても戸惑ってしまうじゃないか。

 「いやいやまだ決めてないし、お先にどうぞ。」

 と、こちらも譲り返して手振りで促すが、

 「そんなそんな、わたしもまだ決められないんで大丈夫です。」

 と、一度譲ったものは譲らないという固い意思を感じたので、さすがに折れることにする。

 「じゃお言葉に甘えて。」

 と言ったものの、さっきからのやり取りで、何が飲みたかったのかを一瞬忘れてしまい、いくつもある商品ボタンを一通り眺めてから、ようやくブラックしか飲まないのを思い出した。なんだか妙な汗が出てる気がしてアイスコーヒーのボタンを押す。

  カップが出てくるまで時間がかかるやつである。30という数字が点灯。なんとなく気詰まり感を覚えたので、気になってたことを訊いてみる。

 「そういえば、スタンプの話ってうちのプロデューサーから直々に?」

 「あ、そうです。ふらっとやってきて突然、絵描けるよね?って訊かれて、えぇ、まぁ・・・って答えたら、OKって一言を残して去って行ったんですよ。不吉な予感がするなぁって思ってたら、そのあとスグにチームメンバー全員ミーティングルームに召集されて、プロジェクト見直しの話が出て、あぁって。アイツそれを先に知ってて確認しに来たんですよ?間違ってないけどなんかみんなより先に動けるのってズルイ気がしません?」

 一気に吐き出すように返してきた。

 「アイツって・・・まぁ直前のミーティングで決定したその足で声をかけてきただけだろう?チームのディレクターもその場にいただろうし。」

 その手の話をプロデューサーが後から知ることはないだろう。なにしろプロデューサーが決めるんだから。とツッコミたくなったが、そこまで言うのはさすがにくどい気がしたので飲み込む。

 自販機のカウントが0になり、カップを匿っていた扉がぎこちなく開く。奥の紙コップをそっと取り出す。

 「まぁ、とりあえずイラストよろしく。」

 自販機の前を空けると、

 「了解です。頑張ります。」

 と明るい声で答えた。何気なく顔を見て、初めて見る笑顔に、思わずドキリとした。

 「で、決まった?」

 動揺を隠しながら、自販機を指さすと、

 「いえ、いいんです、本当はちょっとネタに詰まって、誰かと話したかっただけなんで。顔が見れてよかったです。戻りますか。」

 「え、あ、うん。」

 なぜか一緒に戻ることになり、エレベーターの矢印ボタンを押してカゴが降りてくるのを待つ。

 「わたしもアンリアルエンジン触ってみようと思うんですけど、いろいろ教えてもらってもいいですか?」

 「いいよ。」

 「家で勉強できたらいいなぁ。家のパソコンで動くかなぁ。」

 「いつ頃買ったか覚えてる?」

 買った年が分かれば、スペックについてはおおよその見当を付けることができる。

 「いつだったかなぁ?うーん。」

 そこで到着音が鳴ってタイムアップ。エレベータの扉が開くと、先に何人か乗っていて、見知った顔もあった。

 

 フロアに戻ると、予定管理ソフトから通知が来ていた。予約者が谷山田で、出席依頼に自分と、鳥囃子、南河原となっていた。場所は空欄になっている。ミーティングルームじゃないということは、おそらくチャット画面のお披露目会で間違いないだろう。集合時間まで、まだ時間があるな。だいぶ氷の溶けたコーヒーを飲む。ときどき唇に当たる氷の粒を感じながら、さっきの立木坂との会話を思い出す。いつものコーヒーと違う味がした。

 

 

 つづく

 

 

 

 

 

 

 

 

 

 

 

 

 

 

チャットUIを作る

10

 翌日は晴れて澄んだ青空が広がっていた。抱えた屈託が全て溶けてクリアになるようなそんな色。こんな青空を見ていると、どこか遠くに行きたくなる病が発症しそうになる。なんとかチャット画面のモックがそれとなく出来上がってきたのを思い出し、続きを作らないといけない使命感をサルベージしながら移動。ようやく会社にたどり着いた。

 今日は少し早く着いたのでいつもよりフロアは静かだった。PCを起動しUE4のエディタが開くまでの間に昨日帰ってから頭の中で考えていた構造を思い出す。

 テキスト入力を左右に分離させたバージョンを作るにあたって、用意するWidgetはいくつか考えてみた。

 最初、左右反転した見た目になるのであれば、フキダシWidgetのように、片側だけ作って2個置けば?というアイデアが浮かんだ。ただし片方でテキスト入力中、もう一方は触ることができない状態にする必要がある。2つが同時にアクティブになることはない。左右の入力Widget間で相互にやり取りするのはとても面倒だ。かといって親のレイアウトWidget経由も手間が増えるだけでまどろっこしい印象。

 

 ここは一つのWidgetにキャンバスパネルによって左右2つの入力部分を管理するのがよさそうだと思い至った。さらに親のレイアウトWidgetで受け取る際にバインドしている処理も変えなくても済む。

 

f:id:hiyokosabrey:20191002191728p:plain

 

 

 まずは今のテキスト入力Widgetを複製して、これを改造していこう。コンテンツブラウザからテキスト入力Widgetを複製する。

f:id:hiyokosabrey:20190929212152p:plain

f:id:hiyokosabrey:20190929212453p:plain

 とりあえず名前を wb_WriteBox にしておこう。

 使えそうなパーツは流用する。入力用の下敷きは、いまのフキダシと同じテクスチャにして調整。ボタンは一つだけでいいので片方を消す。テキスト入力は1行入力だからMultiLineじゃないやつに差し替える。

f:id:hiyokosabrey:20190929103234p:plain

 大きさはフキダシの許容文字数分横に伸ばしておいてっと・・・こんなもんかな。顔アイコンは適当なやつをセットしておこう。

 

 入力開始ボタンのテクスチャはこんな感じでいいかな。

f:id:hiyokosabrey:20190928230958p:plain

 

 しばらくパーツの調整に手間取ったが、なんとか整った。このテキスト入力で必要な「状態」は3つ。

 

● テキスト入力中

f:id:hiyokosabrey:20190928002555p:plain

 ユーザーがコメントを入力中はこの状態。

 

 

● 待機中  [DEFAULT] 

f:id:hiyokosabrey:20190928002621p:plain

 入力する前の状態。左右どちらも同じ。この状態のみ入力を開始するための +ボタンが表示される。

 

 

● 非アクティブ [N/A] 

f:id:hiyokosabrey:20190928002639p:plain

 反対側で入力を行っている間の状態。見た目に存在感を弱く。CanvasPanelの透明度を変えるとラクチン。

 

 

 ヒエラルキーはこんな状態。

f:id:hiyokosabrey:20190928003255p:plain

 反対側も同じ構成になるので、キャンバスパネルを一つ追加してある。

このCanvasPanel_Left をまるっと複製して 名前を CanvasPanel_Right に変更。

見た目にシンメトリーになるように調整。

f:id:hiyokosabrey:20190928003811p:plain

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

f:id:hiyokosabrey:20190928004527p:plain

 

 入力中、待機中、非アクティブと、見た目にこの3つの状態を遷移させるためにアニメーションを使って切り替える。いきなり切り替わると味気ないので、入力開始と終了時くらいは短いながらもアニメーションを作ってみよう。状態遷移のイメージはこんな感じになると思う。

 

f:id:hiyokosabrey:20190929004248p:plain 

 

 この遷移イメージを元に、左と右それぞれにアニメーションを用意する。待機と非アクティブについては、状態の記憶として利用するので、尺は不要。開始 0.0 の位置にバシっと確実に状態を切り替えるためのキーを打つだけでいい。

 

f:id:hiyokosabrey:20190929092607p:plain

 


 これをブループリントの方で組んでいこう。

 +ボタンは、前のWidgetから残したパーツで、Buttonコンポーネントだから OnClickイベントが有効だ。そこへアニメーションの再生ノードをつなぐ。まずは左側のクリック。

f:id:hiyokosabrey:20190929095541p:plain

 右側のクリックも同じ要領で、再生するアニメーションが変わる。

f:id:hiyokosabrey:20190929095654p:plain

 Widget の Buttonコンポーネントは、画面に表示されている間はクリックを受け付けてくれる。なので、クリックした直後にアニメーションで Visibility を Collapse にするキーを打っておくと必要なクリックを防ぐことができて安全。

 Play Animationノードは、再生のトリガーでしかないので、再生を開始したらすぐに次のノードに処理が流れてくれる。ただ基本的に終わりを待ってくれないので、終わってから何かする場合だけ、特別な処理が必要になる。

 

 次は投稿の処理だけど、送信ボタンが無いので何をトリガーにしようか。確かEnterキーを判定するイベントがあったはず。

f:id:hiyokosabrey:20190929113203p:plain

 

 あった。たぶんこれだ。

f:id:hiyokosabrey:20190929202851p:plain

  Commit Method は ENumのピンだから、判定用の Equalノードが使えそう。

f:id:hiyokosabrey:20190929203134p:plain

 あった!

 ということは、さっそくプルダウンを見てみると・・・

f:id:hiyokosabrey:20190929203325p:plain

 On Enter !

 これをブランチノードで判定すればよさそうな気がする。True の時に、用意してあった、イベントディスパッチャーにテキストのピンをつなげれば入力した内容が送信できるはず。

f:id:hiyokosabrey:20190929204312p:plain

 左側用だから、isLeft を True にしておく。

 右側のも同じように作ってから、テストしてみよう。

f:id:hiyokosabrey:20190929204326p:plain

 

 テストするためには、レイアウトWidgetに配置してやらなければいけない。

 と、その前にコイツをひとまずどかす。

f:id:hiyokosabrey:20190929204705p:plain

 Visibility を Collapse にしてしまえばいいのだけど、ここは Event Pre Construct を使おう。

f:id:hiyokosabrey:20190929204848p:plain

 これで、コンパイルした瞬間にキャンバスから消えてくれる。

f:id:hiyokosabrey:20190929205135p:plain

 ヒエラルキーの可視オプションを見えないようにすればいい。存在を戻すときはノードの接続を切るだけなので安全。

f:id:hiyokosabrey:20190929205629p:plain

 これで、改めて新しい入力Widget を配置できる。

f:id:hiyokosabrey:20190929205847p:plain

 

 テキストをバインドしてイベントディスパッチャーから受け取っているところがあったから、そこをつなぎ変えないと。

 今こうなってる。

f:id:hiyokosabrey:20190929213531p:plain


 wb_WriteBoxCenter のバインドを一時的に外して、今回追加した wb_WriteBox からバインドノードを取り出す。

f:id:hiyokosabrey:20190929213355p:plain

 最終的にどちらの入力方法で行くか決まれば、片方は消滅することになる。

 よし、再生してみるか。

f:id:hiyokosabrey:20190929224404g:plain

 よしよし、うまくいってる。

 

 でも、フキダシの開始位置が低くて重なってしまっているので、VerticalBox の位置を上にあげよう。

f:id:hiyokosabrey:20190929224747p:plain

 あとは、OnEnterで送信した後の処理だな。元の待機状態に戻さないと。レイアウトWidgetコンパイルして編集完了。続いてテキスト入力Widgetの方。

 

 この続きに、閉じて元に戻す処理をつないでいく。

f:id:hiyokosabrey:20190929231149p:plain

f:id:hiyokosabrey:20190929232341p:plain

 左と右、順番に気を付けながら元に戻すためのアニメーションを再生していく。

 

 イベント全体はこんな感じ。

f:id:hiyokosabrey:20190929232604p:plain

 

 再生してみる。 

f:id:hiyokosabrey:20190930230650g:plain

  特に問題はなさそうだ。あとは顔アイコンのセットと入力の途中キャンセル、改行ができたら見せられるかな。

 とりあえず顔アイコンを渡すところを作ってしまおう。テキスト入力Widgetに受け取り用の関数を用意すればいいだろう。 

f:id:hiyokosabrey:20190930233310p:plain

 今はこの関数をに対してレイアウトWidgetから顔アイコンのテクスチャ渡すようにすればいい。

f:id:hiyokosabrey:20190930233732p:plain

 このあたりは画面の初期化処理としてイベントにしておいた方がいいかもしれない。Event Constructで処理している場合、Widget がViewportに追加された段階でデータが渡されていないといけないからだ。データの受け渡しのタイミングはネットワークが絡むと思うようにはコントロールできないことが多い。後でプログラマと相談しよう。

 

 UI表示を作る場合、Viewport に追加された瞬間に動き出すやつと、そうでないやつがある。追加された瞬間動きだすのはワンショット的に役目を果たすと消滅するタイプ。主にエフェクトとか演出系の表示。そうでない方は、基本的に常駐することになる。もう少し細かく分けると、常時表示されていて更新されていくタイプと、適宜必要に応じて呼び出されて表示するタイプに分けられる。これらのタイプを用途に合わせて設計する。プログラマに相談する際にも、この辺の分類を念頭に入れて話すとスムーズに仕様を決めることができる。と考えているのだけれど、なかなかこういった話ができるUIデザイナーが周りにいないのはさみしい。

 さて、わかりやすくコメントをつけておいて、あとで改造しやすくしたところで、次はキャンセル処理か。

 入力用Widgetの外をクリックしたら入力をキャンセルして閉じるようにしてみよう。感触が良くなかったら、キャンセルボタンを置くことになるかな。

 

 テキスト入力エリア以外のクリック判定なので レイアウトWidgetに判定させるのがよさそう。

 OnMouseButtonDown 関数をオーバーライドしてと、

f:id:hiyokosabrey:20191001085914p:plain

f:id:hiyokosabrey:20191001085414p:plain

 ここに判定用のパーツを持ってくるわけだけど、Widgetのクリック検出は、Visible状態じゃないと判定してくれないので、キャンバスに何も置いていないとこの関数が呼び出されることはない。というわけで、キャンバスにテキスト入力Widgetを避けて、CanvasPanelを配置する。

f:id:hiyokosabrey:20191001091446p:plain

 このCanbasPanel の Visibility の設定をVisibleに 変更しておく。

f:id:hiyokosabrey:20191001091653p:plain

 名前を CanvasPanel_CancelArea としておこう。

 これをさっきオーバーライドした関数の中に置く。

f:id:hiyokosabrey:20191001092051p:plain

 レイアウトWidgetのキャンバスに置かれているすべてのパーツが検出対象で、何かあるところでマウスボタンを押すと、この関数が呼び出される。特定のパーツのみを対象にしたい。ここで判定してはじくために isHoverd ノードを使う。hover は WebページのデザインでCSSを触ったことがあるならピンとくるはず。このノードはカーソルが乗っているかどうかをブーリアンの値で返してくれるノード。テストするためにPrintStringをつないでみる。

f:id:hiyokosabrey:20191001093119p:plain

 コンパイルするとWarningが出た。

f:id:hiyokosabrey:20191001093414p:plain

 そうだ、ReturnValue が空いてるとダメなのだった。Handled ノードをつないで祈る。鎮まり給へ!

f:id:hiyokosabrey:20191001093603p:plain

 鎮まった。

 テストしてみよう。

f:id:hiyokosabrey:20191001151550p:plain

 よし、ちゃんと反応してる。

 

 今度は閉じるイベント作って、それを呼び出せばいい。テキスト入力Widgetを編集しよう。

 ただ呼び出すだけでいいのか?勝手にいろんなタイミングでクリックされるから、都合の悪い時がある。あと、入力中のやつはキャンセルするけど、非アクティブの方はすでに閉じてる。となると、フラグが要るな。ブーリアン型の変数を2つ用意しよう。

f:id:hiyokosabrey:20191001152559p:plain

 まずこの値をセットするはここだ。+ のButtonをクリック処理するところ。

f:id:hiyokosabrey:20191001153024p:plain

f:id:hiyokosabrey:20191001153041p:plain

 

 このフラグを元にカスタムイベントで閉じることが可能かチェックする。

f:id:hiyokosabrey:20191001153615p:plain

 このあとに閉じるアニメーションをつなぐんだけど、ちょうどいい場所があった。

f:id:hiyokosabrey:20191001153839p:plain

 すっぽり!

 送信した直後だから、ただ閉じる処理しかしていない。で、この処理の一番最後尾でフラグを元に戻せばいい。

f:id:hiyokosabrey:20191001154238p:plain

 これで、テキスト入力Widget側の準備はできた。レイアウトWidgetの OnMouseButtonDown 関数に戻る。テストでPrintStringをつないでいたところを差し替える。さっき準備したカスタムイベントを呼び出す。f:id:hiyokosabrey:20191001154455p:plain

 これでOK。

 テストしてみよう。

f:id:hiyokosabrey:20191001160146g:plain

 よし、これで良さそうだ。あとはフキダシの改行表示かな。うまくいくといいけど。

 

 

 しばらくキャンバスのパーツを触っていると、SizeBoxにそれっぽいパラメータを発見。あと、TextBlock の改行設定を入れておく必要があった。

 SizeBoxの子供の TextBlock_Body に改行無しのダミーテキストを入れて、Wrappingの設定を変更する。

f:id:hiyokosabrey:20191001181436p:plain

f:id:hiyokosabrey:20191001181642p:plain

f:id:hiyokosabrey:20191002174005p:plain


 で、SiizeBoxの方も設定を変える。

f:id:hiyokosabrey:20191001175946p:plain

 まず SizeBox の Size To Content を一時的に無効にする。

f:id:hiyokosabrey:20191001180237p:plain

  いい感じのサイズになるようにSizeXとYを調整。

 そして、Child Layout カテゴリの  Max Desired WidthMax Desired Height を有効にして Size X と Size Y を移植する。Size To Content のチェックを戻せばOK。

f:id:hiyokosabrey:20191001180755p:plain

 これで大丈夫。

 テストしてみよう。

f:id:hiyokosabrey:20191001200706g:plain

 よかった。なんとかできた。

 

 あとはプレゼンに向けてちょっと細工を。レイアウトWidgetの送信処理のところを、2種類のテキスト入力Widgetを両方有効にしておく。

f:id:hiyokosabrey:20191001222245p:plain

 Event Pre Construct のところで、切り替えられるようにする。

f:id:hiyokosabrey:20191001223509p:plain

 コンパイルが必要だけど、ブランチノードのCondition を切り替えてコンパイルするだけで切り替えができる。確認しておこう。

 

 ?!・・・あれ?なんかスクロールがおかしいな。

 

 

つづく

 

チャット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など、レーティングが上がることになります。

 

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

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

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

 

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

 

 

ではでは

今回はこの辺で

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