いつも通り投稿頻度が低いのでこの挨拶が今後のデフォルトになるであろう、真機械です。

UIの件は色々と事が進んでいて近いうちに何かしら報告できそうなので置いといて、早速ですが本題に入っていきたいと思います。

タイトル通り「技術者が集まっても必ずしも良い作品が作れない理由について」

こちらの一つの完成形の答えのようなものを教わったので、軽いストーリーテイストでお話していきたいと思います。

１，事の始まり

　私も小さな希望と成り行きから大学に在学して早3年の時が経ち、次はいよいよ4年生となります。

　3年が始まってすぐのころには、私はこのようなブログを掲載しました。

『チーム活動をして気が付いたこと』　久しぶりのブログ更新になります。真機械です。 　この間、ゲームのUIの研究結果を書きたいなぁとTwitterに書いたままUIの完成がまだだという、完全に失踪…ameblo.jp

　※先にこのブログを読んでおくと、後の理解が非常に得られやすくなります。

　今となっては懐かしい記事です。

　こちらのお話を今更ながら少しだけ補足しますとこちらの記事は、とある講義の課題によりチーム活動が始まった際に書いたものになります。

　そしてもう一つ、こちらの課題の制作物は「スマートフォンゲーム」でした。

　更に、私のTwitterを見てくれた方はご存じかと思いますが、こちらのスマートフォンゲームは、G2 Studios株式会社、株式会社f4samurai、ワンダープラネット株式会社、株式会社サイバーコネクトツーの名だたるゲーム企業4社が審査員を務めるゲームコンテスト、「デベロッパーズゲームコンテスト2020」にて大賞を受賞した作品でもあります。

詳細(https://note.g2-studios.net/n/n6389b8a256e6)

　素直に感想を述べれば、実際にゲームで過ごし、ゲームで生きてきた人間としてこれほど嬉しいことは無いですね。

　さて、このようにしてゲームクリエイターとしての道があります。さぞ4年生の就職活動は随分と他の学生と差をつけられるでしょう。

　はい、そんなことは全くありませんでした。

　先に断っておきますが、ここでは別に恨みつらみの話はしませんし、そういった意図や気持ちも一切ありません。私が就職に失敗したゲーム企業に対する恨みも当然無く、むしろとても大きな成果として得られる内容であると確信して、敬意をもってこの話を書きます。

　実際、この後の就職活動での私は大失敗でした。

「小さな業界とは言えど、コンテストで最優秀賞を取るような、直接的に企業に認められているにもかかわらず」です。

　何故でしょうか？

　色々な原因はありますが、一言で結論を先に述べますと「企業が求めている人材として、コンテスト時の私と就活時の私が違っていた」ということです。

　あまりパッとしない言い方ですので具体例を挙げましょう。

　コンテストに出場した作品にて私は「ディレクター」という役職を引き受けました。いわゆる監督です。

　ディレクターの役割はズバリ「作品のゴールを決めること」にあります。

　さて、そして話は飛んで就活時、私がゲーム企業に入るときに志望した役職は「ゲームプランナー(企業によっては"ゲームデザイナー"とも呼ぶ)」です。

　こちらの役割は、作品の企画の立案になります。ディレクターとは違って部分的なものになりますが、似た部分が多い役職なので、これ自体は特に問題はないでしょう。

　問題はこの後です。私がこの時、企業に提出した(見ていただいた)作品にあります。

　コンテストでは言わずもがな、応募した作品のみを判断材料としたでしょう。

　しかし就活時、私が提出したのは「自身が趣味や課題で制作した作品集」でした。

　これの何が問題だったのか、今の私にはわかりますが、当時の私には簡単にはわかりません。

　4年生になったあとの卒業制作も、その作品集の一部で進める予定だったため、「もしかすればこの傾向はゲーム業界からすれば間違いなのかもしれない」と悩みました。

　結果的に私は、このブログを投稿する2日前に、所属する研究室に相談することになります。

２，「目的」と「手段」

真機_械@MABOMEKA_MAIN 

「目的」と「手段」

2021年03月24日 15:24

　まず私の講師からいただいたお話として、「就活と卒業制作は、無理に一緒にしてはいけない」とのこと。

　その前提を踏まえた上で「目的」と「手段」という例を出していただきました。

「目的」とはその通り、「作品の存在意義の追求」や「作品が成し遂げる意味」について、です。

「手段」とは「作品の作る過程」「作品を作るための技術」について、です。

　これらをもう少しわかりやすく言い換えれば「目的」は作品の企画、「手段」は制作の技術となります。

　つまり、もしゲームを制作する場合、そのゲームの存在意義や案を生み出すことは「目的」の追求となり、ゲームを実際に制作するための技術を得ることは「手段」の追求となるわけですね。

　そして私が所属する研究室では、卒業研究以外では「手段」をかなり重要視するとのこと。

　これは要するに「作品を制作する際の目的は追求する必要はなく、ただ自分が得たいと思う技術を得ることに専念してほしい」ということですね。

　確かに、我々のような学生がいきなり目的の追求から始めてしまうと、逆に成長が難しくなる。だからこその配慮だなと思います。実際に、講師もそう語っていたので。

　更に、我々の大学も「手段」で成績を付けてしまいがちである、というお話もいただきました。

　さて、ではこの「目的」と「手段」という言葉を土台として考えると、実は様々な問いの答えにもなります。

　私が就活で提出した「自身が趣味や課題で制作した作品集」がなぜいけなかったのか。

　そして前回のブログ、我々の大学のチーム活動で、闇鍋化現象が発生しやすい理由。

　これらの問題すべてにカタをつけましょう。

３，答え合わせ

　ここからは少しクイズ形式にしましょう。

　ではまず、ディレクターという職に必要なのは「目的」と「手段」のどちらでしょうか。

　答えは「目的」になります。ゲームの完成を決定する立場なので、これは確実でしょう。

　二つ目に、ゲームプランナーに必要なのは「目的」と「手段」のどちらでしょうか。

　こちらも「目的」ですね。実際に起こしている行動はディレクターと似たものですから。

　三つ目に、私がコンテストで評価された技能は「目的」と「手段」のどちらでしょうか。

　これも「目的」になります。一応プログラマーとして「手段」もふるまいましたが、それ以上にディレクターとしての役割が無ければ、それすら発揮は不可能でしたから。

　では最後の四つ目、「自身が趣味や課題で制作した作品集」は「目的」と「手段」のどちらで評価されるでしょうか。

　そう。この答えのみ「手段」になります。

　つまり「私が成りたいと思っている職と、それに該当する作品が噛み合っていなかった」こと。

　これをゲーム企業が見抜いたからこそ、私はそこへの就職に失敗したのです。

　企画力(目的)を、制作の技術(手段)で評価する、そんなことは無理なわけです。

　だってこれを極端に例えれば「ゲームハードの組み立てを仕事にするために、ゲームソフトの作品を書類選考で出した」のと同じですから。そりゃ当然切り捨てられます。

　企業側からすれば「職種は関係なくとりあえず作った作品をかき集めてきたんだな」と思われるのがオチなわけです。

　そしてもう一つ、「我々の大学では「手段」で成績を付けるパターンが多い」という言葉。

　これも我々の大学にて、チーム活動が絶望的に苦手な人が多い最大の原因です。

　実のところ、私のTwitterのTLは授業に対する不満で荒れることが度々ありました。

　荒らした人が間違いだとは思っていませんが、以前からこの違和感の正体についてはずっと謎でした。

　まず彼らの怒りの矛先がなんなのか。何を得たいのか。

　私が大して荒らし側に回らなかったのは何故か。

　講義のコンセプトは悪くないのに、何故あんなにも荒れたのか。

　これを「目的」と「手段」と照らし合わせて考えると、ちゃんと答えが浮かび上がります。

　彼らが怒りを向けていた講義は、基本的に「チーム制作」での講義が大半を占めていました。

　上記から言っている通り、チーム制作は「目的」が最も重要です。

　つまり彼らは、「目的」を重要視する講義に怒りが集中していたわけです。

　それに対し、私を除いた学生は「手段」での対抗を行っていました。「ビジュアルが良ければ評価してくれるであろう」と。実際に私のチームにもそれを強要しようとした人物がいる始末です。

　しかし、それは評価されなかった。就活に失敗した経験談でも言いましたが、これは当たり前ですね。それが怒りの原因だったわけです。

　そしてこの「手段」での対抗、この結果物こそが「企画の闇鍋化」なのです。

　タイトルにもある「技術者が集まっても必ずしも良い作品が作れない理由」の答えにもなりますね。

　また、これしかやり方が無かった、とも捉えられます。

　「手段」は、悪い言い方をしてしまえば「俺が考えた最強の作品を生み出すための技術」とも言えます。確かにこれは作品を作るための動機として最も動きやすい。しかし、他者の理解は得にくい。

　他者の理解を得るためには「目的」が大事。しかしそんなものは大学では学べていない。ましてや、そもそもそれが評価されるとは微塵も思っていない。

　となれば、消去法で「手段」での対抗でしかできなくなるわけです。

　みんなの好きな要素を集めて一つの作品にしよう、という結論に全員が無意識に至るわけです。我々の大学の環境ではこんな暗黙のルールがいつの間にか生まれていました。

　これが逆に仇となりました。

「この講義では、大学側が教育を苦手としている「目的」が評価される」

　これを知らされていなかった学生は、プレゼンの評価の際に肩透かしを食らったわけです。

　これが企画の闇鍋化が各チームで頻発した元凶、そして多くの学生が怒った原因です。

4，まとめ

　私はこの現状が非常に危険だと考えています。

　なぜなら、せっかく「目的」を評価する講義を入れたにもかかわらず、いまだに多くの学生がその重要性に気付いていないわけですから。

　対策案が真逆の方向に働いているのは、決して良くない傾向です。

　なんとかしてこの現状を変えるために教授や講師に助力ができたらなと、私は考えています。

　また、これを見てくれている方も、この際に「目的」と「手段」の意味や重要性に気付いていただけると助かります。
 

　何か意見や質問、お話があれば、気軽にコメントを下さい。

　ブログとは全く関係ないお話でも、すでに答えたかもしれない質問などでも歓迎します。

　それでは、本日はこの辺で…。

　最後に軽くUIの進捗情報を。

　この間、ゲームのUIの研究結果を書きたいなぁとTwitterに書いたままUIの完成がまだだという、完全に失踪案件のようなヘマをやらかしたので、そろそろ気が付いたことでも残しておこうかなと思い、現在に至ります。

(結局UIやんのかやらんのかどうなんだ、と気になる方はご安心ください。私にもわかりません)

　さて、本題に移ります。

　モノづくりや創作をしている皆さんは、自分が好きなものを作れていますでしょうか。

　それらをもし仕事として生かそうとする、そんな日が来たらとても良い人生を送れそうですね。

　はい、そんなわけありません。自分が作りたいと想像した100%が仕事に通用するわけがないです。

　仕事として生かす場合、その仕事の「企画者」が存在します。企画者が提示した「作る物」に対して、企画とは全く異なる、自分が作りたいと思って作ったものを提出すれば、それはクビになるレベルの大失態です。なぜなら、それは仕事ではないですから。

　今回は、その事実をモロに受けた時に知ったことを書いていきます。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

1、企画の闇鍋状態

　私が通っている大学では、「チームを自分たちで組み、一つの作品を共同で作りあげる」という授業があります。
　作るものはMVや映画でも良いし、漫画、アニメ、ゲームなどでもいい。とにかく、かなり自由な環境でモノづくりをします。

　実に楽しそうでしょう。しかし、この授業には強烈な落とし穴がありました。

　「チームで企画を考える」

　この時点で流れに乗るように企画を進めてしまえば、この先はとんでもない地獄に足を突っ込むことになります。

　この"流れ"とはいったい何のことでしょうか。

　それはチームのメンバーがやりたいように作品を作るために「あれやりたい」「じゃあ俺はこれ作りたい」「私これ書きたい」などと言うように徐々に組み立て式で企画が完成していきます。

　実は、この授業は、チームメンバーが自由に選択できるという特徴もあってほとんどのチームがこのように動く可能性が高いんです。

　(私はこれを「企画の闇鍋状態」と呼んでいます。私のチームも、当初はこうなりかけました)

　実はこの方法、作品としてかなり失敗しやすいです。その理由は、

・作品を作る意図が「我々が作りたいものをまとめた結果」という理由で完結してしまっている。(存在意義が薄い)

・具体的に完成させた後の形が見えない。

・完成図が見えている人と見えていない人、見えているがすれ違っている人など、共同制作するメンバーとは思えないほど、考えることがズレやすい。

・中心人物がいないため、作品の方向性やコンセプトがブレる。

　等があります。

　恐らく、「みんな仲良く、楽しく、良いものを作ろう」という他者を思いやる気持ちで無意識にこういう形になっているのでしょうが、それに対してあえて本音を言います。作品の完成度を求めた場合はクソ喰らえな案件です。

 この「企画」というのは、作品完成までに至る土台のようなものですので、それをあやふやにするのは組み立て途中で崩れてしまい、完成まで漕ぎ着けない可能性も考えられます。

 先程「闇鍋」という例えを出したので、便乗して料理でも例えてみますが、いろんな人が「あれ作りたい」「これ作りたい」と言って、何を作りたいのか明確に決めないままポンポン具材だけ投げ込んで1つの料理を作った場合、その料理は果たして確実に美味しくなるでしょうか？

 その答えは「否」です。奇跡でも起きない限りは美味しくなりません。

 逆に言えばそれが成功するのは、個人で企画を立てて、個人で作品を作る場合に限ってなのです。全員が1つの作品を作る際にそれを行うのは企画として失格ですし、それを要求する人間もチームからしてみれば非常に邪魔な存在なわけです。

 では次に、そうならないために私が行った対策法について説明します。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

2、何を作るか決めた1人を最高責任者(ディレクター、監督)にする

 さて、今まで提示してきた問題の根本は「企画の完成を探している」ということに集約できます。そうなってはゴールがないのですから、あるはずのないゴールを探し続けるのと同様です。企画の土台は当たり前と言っていいほどガタガタになります。

 しかし、これに対する対策は比較的簡単です。それは「誰か1人がゴールを先に決める」というものになります。

「それだとチーム全員が納得するかどうかわからないのでは」と思う人もいるかもしれません。しかしそのための「最高責任者」なのです。

 ゴール(作る作品)を決めた人がチームメンバーの役割、企画案、作ってもらう素材などを全て考えます。もちろん、チームメンバーが納得できるような仕事を考えなければいけません。作るものと一緒にメンバーの仕事も考え、それを決定した責任を取る人、それが最高責任者(ディレクター)です。

　先ほどと同様に料理で例えると、「料理長」と呼ばれる人が「この人に〇〇(料理名)を出そう。そのためにはこれだけの材料が必要で、こういう調理法が必要だ」と具体的にチームに提示するわけです。

　それだけでチームメンバーは何をすべきか、ある程度は把握できます。もちろんメンバーの役割を決めたりすれば、更に効率良く動けるでしょう。その料理長がいわゆる最高責任者なのです。

 それを成し遂げられる人がチームにいるかどうか、それはわかりません。しかし、メンバー一人一人は自分自身が何を作りたいかをしっかりと理解しているはずです。でなければ闇鍋現象すら起こるはずがありません。

「作りたいものはあるのに、いざ作り終わり、酷評を受け取ったとしてもその責任は一切取らない。自分の作った作品だと胸を張って言わない」

　それは果たしてチームメンバーとして、何よりクリエイターとしてあっていいことなのでしょうか？

　少なくとも「好きなもの作りたいけどディレクターはやりたくない。責任は取りたくない」という考え方を持つ人は、そういったあまり好ましくない欲がある可能性があるでしょう。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

3、まとめ

 現時点ですでに闇鍋現象が発生してしまっている場合は、一度構想をリセットする必要があります。下手に進めてしまっては、作品のクオリティが低くなってしまう可能性が非常に高いので。

　ただ、一つ、誤解しないでいただきたいのは、闇鍋現象を強制的にやめさせようとしているわけではありません。肝心なのは、その方法がいかに危険であり、その方法でのチーム活動しか知らない方に知らせる、それが目的です。

　もしこれを見ているあなたに「自分が作りたいものを作りたい」と思う心があるのなら、そしてそれを成し遂げたいと思うのであれば、その行動に責任を持つ必要があります。

　なぜならその思いは最高責任者(ディレクター)でしか、基本的には成し遂げられないのですから。

　今回のお話は以上です。
　ご意見、ご感想などがあれば、コメント欄に書いていただけると多分丁寧に反応するので、気軽にどうぞ。

　少し前、とある人物からクリエイターとしての信条(というよりお悩み)で相談を受けたのですが、自分でもいくつか思うところがあったので、それについて少しべらべらと語っていきたいと思います。
　決して名指しで誰かを非難するわけでもなく、そういったネガティブな内容のまま終わらせるということはないので、安心してお聞きくだされば嬉しいです。

　私は今まで、イラスト、映像、プログラムなど、あらゆる形式の作品を作ってきました。

　その根本にあるのが、学校の課題であったり、趣味であったり、お金がもらえる仕事としてであったり、様々なものがあります。

　しかし、この中の「趣味」に関しては、作品を作ったことがあっても「完成させたこと」はほとんどありません。特に長期的に続けているプロジェクトを最終的に完成させたことはないわけです。

　これを前提として、本題に入っていきます。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

Q１.実況動画を制作しているのだが、どうしても続かず失踪してしまう。原因の解明と解決案が欲しい。

　正直なことを言うと、私は実況動画を作ったこともないですし、先ほど記述した通り、そういった長期的なプロジェクトを完成させた経験がないため、非常に難しい問題です。少なくとも私には答えられない問題、そう思っていました。

　ただ、この質問をした彼は少々特殊で、自分の作った作品をとっておくか、それとも捨ててしまうかが非常にはっきりしていました。
　そう、実況動画における失踪とは、まさにその中の「作品を捨てる行為」に入るわけです。それを「良くないことだ」と自覚していたんですね。

　もちろん、私にも似た経験がありました。自分が考えていた物語を結局ボツにしてしまう、という経験です。ただ、それにはある一定の定義がありました。

　その作品の世界観に矛盾があるか無いか、ちゃんと作りこまれているかどうか、などです。作りこまれていない作品は、続ける意味を見失ってしまっていました。

　つまり、自分が一つの長期的に続けられるかどうかの基準は、「作りこまれているか、いないか」でした。

　ただ、これは質問の答えではありません。なぜなら、これを実況動画に当てはめるには難しいからです。

　そもそも実況動画は感情移入を目的とした映像作品ではないので、作りこみを評価されることは極めて少ないです。どちらかと言うと実況動画の根本は「コンテンツが如何に面白いか」になることが多いです。

　私はもっと掘り下げました。「なぜ、私は"作りこまれていると続けられるのか"」についてです。その結果、一つの根本的かつ感情的な結論に至りました。

A１.作者である自分が、その実況動画を"好き"になっていないのではないか？

　「作りこみ」というのは、私の作品に当てはめての話です。基本的に質問に答えるときは、大衆が納得できる形でないと意味がありません。

　この問いは、根っこに立って考えてみると非常に簡単で単純なものです。それは「私は、作りこまれた作品が"好き"だ」という感情論です。

　この「好きかどうか」というのが続けられるかどうかの分かれ目になっているのではないかということですね。

　作品とは、作者の愛によって成り立っています。一種の表現であり、自分の思うままにモノを作っているんですから、当然かと言われれば当然ですね。

　実際に相談をしてくれた彼は私と少し似ていて、自分が作った作品の中でも「ありとあらゆる質問を投げかけられても、全て筋の通った返答ができる」というのに当てはまる作品はとても好んでいました。ただし、実況動画はそうではなかった。自分自身が好んでいない作品なのに、それらを期待されているというプレッシャー、作らなければいけないという使命感に阻まれて動けなくなっていた。それが、失踪してしまう原因なのではないかということです。

　補足ですが、私自身は失踪自体を悪いことだとは考えていません。なぜなら、人が作った作品である以上、そこに「お話」と言う名の矛盾が生じるのは避けられず、それによってその人の好き嫌い、続けたい続けたくないという気持ちは簡単に変動してしまうからです。それに「修正」という形で立ち向かうか、「放棄」と言う形で手放すか、どちらも自身の成長、問題解決を目指す立派な手段です。

　では、次の質問に移りましょう。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

Q2.自分の作品を好きになるにはどうすればよいか。

　これまた難しい質問です。好きになるかどうかの定義は、やはりその人個人によって分かれてしまいます。作品を世に出すにしても、この「好き」の部分が世間とズレてしまっては失敗してしまいますし、逆に他人に無理に合わせようとしても作者側が持ちません。意外とこのあたりで悩んでいる人も多いのかもしれませんね。

　先ほども記述したように、基本的に質問に答えるときは、大衆が納得できる形でないと意味がありません。多くの人に当てはまり、納得できる形でないと説明できないわけです。

　これに対して私は、以下のように回答しました。

A2.自分の好きな他者の作品を分析し、好きなポイントをストックしておく。

　作品に対しての愛がとても重要だと言っている私ですが、一つ非情な現実を言いますと、私の中での"愛"というのは熱しやすくて冷めやすいです。一度好きになっても、しょうもないきっかけや時間経過ですぐ嫌いになったり飽きたりしてしまいます。どちらかと言うと恨みや憎しみ、トラウマの方が遥かに記憶に残り、忘れたくても忘れられなくなることが圧倒的です。

　質問をした彼の癖は、「これをやりたいと思ったらすぐ作り出してしまう」というものでした。そして、彼が好んでいる彼自身の作品は、大体が「短期間で製作されたもの」という一定の定義が存在していました。

　そう、つまり一度好きになったポイントやアイデアをすぐに作品制作に使用し、その作品が長期的なプロジェクトだった場合は製作途中で「好き」から覚めてしまうのが原因だというわけです。

　短期間で作り終わる作品の場合は、「好き」から覚める前に作りあげてしまえばよいのですから。

　実況動画は基本、長期的なプロジェクトです。当然、作者の「好き」が続かなければ終わってしまいます。

　要するに、作品における「好き」とは、作品と作者を繋げる生命線なわけです。それが無くなれば、作品は作者の手元から消えます。確実に。

　私が制作している長期的なプロジェクトは、かれこれ8年ほど続いています。どうしてここまで続けてこれたのか、私が行っている手法としては「生命線の数をこれでもかというほどに増やす」というものがあります。ストックはそのために用意しているのです。

　「好きなポイントやアイデア、シチュエーション」を発見したらすぐに作品に使用するのではなく、それをストックしておきます。
　メモ帳に書くなり、頭に入れておくなり、簡潔な作品を作って世に出さないようにしたり、いかなる場合でも結構です。とにかく溜め込んでおくんです。もちろん多ければ多い程いいでしょう。

　そして、いざ作品制作を行うとき、そのストックしていた「好き」をとことん使い込みます。それだけで、作品は作者から離れることはありませんし、作者が作品を嫌うことはほとんどなくなります。

　一つの「好き」は覚めても、その他の「好き」が作品と作者を結び続けます。これが、失踪を起こさないための私なりの解決方法です。

　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

　ここまで見てくださって、ありがとうございます。
　何の計画もせずに書きなぐっていたので、理解しにくいところがあるかもしれませんが、もし、もっと会話がしたいという話やその他質問があれば、是非コメントにお書きください。しっかりと対応いたします。

　このシステム自体はその他のブログやYoutubeなどでも紹介されていますが、私なりにできるだけ簡潔に、そして他のモデルでも使用しやすいように工夫したものを今回は紹介していきます。

　使用するモデルはお馴染みグレイマンで、コードを書き込む必要は一切ございません。それらは基本的にブループリントのノードのみで行います。
　また「自分のモデルに適用させたい！」という方もいらっしゃると思いますので、できるだけそちらの方にも配慮するよう心がけます。

　使用するUE4のバージョンは、この記事投稿時の最新版である4.25.0です。

　専門用語はバンバン出していくので、もしわからないことがあれば気軽にコメントをお願いします。

　では初めて行きましょう。

　１．ソケットの追加

　足の位置を受け取るためには、まずその起点となるソケットが必要になります。

　まずは足を動かしたいキャラクターのスケルトンを起動

　↑こちらのアイコンですね。ダブルクリックをすることで起動します。

　そして「foot_l」という左足のボーンの下にソケットを一つ追加します。「foot_l」で右クリックをし、「ソケットを追加」をクリックしてください。

　右足は「foot_r」ですので、そちらも同様に追加してください。

　また、モデルによってボーン名が違うと思われるので補足しておきますが、「foot_l」は人体で言う「左すね」に位置するボーンだと思ってください。つまり「foot_r」は「右すね」ですね。

　↑グレイマンでいうと、ちょうどここに位置するボーンになります。

　そして追加したソケットを選択し、右のソケットパラメーターから、左足は「LeftFootSocket」、右足は「RightFootSocket」と名付けます。

　ここの名前は後で手動で入力するので、わかりやすく区別しやすい名前にすることをお勧めします。

　次に、先ほど名前を設定したソケットパラメーターから位置を設定します。
　「RelativeLocation」の値を変え、だいたい足の裏の中央、地面との接地面に設定してください。右足も左右対称になるように調整します。

　↑だいたいこの位置ですね。

　これでソケットの配置は以上になります。

　２．アニメーショングラフの設定

　次はアニメーションブループリントに「実際に動かす」ノードを配置します。

　アニメーションブループリントを起動してください。

　↑こんな感じのアイコンです。

　次にその中の「AnimGraph」のページを表示します。

　もし表示されなければ、ウィンドウ左下のマイブループリントから「AnimGraph」をダブルクリックしてください。

　そして、Defaultと出力ポーズの間に挟み込む形で「Two Bone IK」を２つ、「ボーンをトランスフォーム(修正)する」を入れます。

　この2つの「Two Bone IK」がそれぞれ左足と右足を動かすノードになります。

　↑何やらエラーが発生していますが、あとで設定してエラーを消すので今は放置で大丈夫です。

　では、「ボーンをトランスフォーム(修正)する」を入れているのはなぜか、という話になりますが、図を用いた少々長めの説明をします。必要でない場合は飛ばしてください。

　↑基本的にキャラクターが地面を踏んでいると判定される当たり判定(コリジョン)は画像の赤線の部分になります。

　↑つまり、障害物がこう当たると……

　↑このように上に持ち上げられてしまいます。これではいくら足を動かすように設定しても、当たり判定そのものが邪魔をするので、設定する意味が薄くなってしまいます。

　では、どうすればよいのか……。こうします。

　↑「当たり判定からスケルトンそのものを下にずらす」という対策を施します。

　こうすることで、たとえ当たり判定が障害物により上にあげられようとも、肝心のキャラクター(ボーン)はしっかりとその場に残ってくれるのでちゃんと足を動かすことができます。(当たり判定が上方向に若干ズレてしまうというデメリットはありますが)
　「ボーンをトランスフォーム(修正)する」はこれを作動させるために導入しています。

　さて、では話を戻します。

　「Two Bone IK」を選択し、詳細欄から以下のように設定します。

　・IKBone→foot_l

　・Effector Location Space→BackSpace

　・Effector Target→foot_l

　・Joint Target Location Space→BackSpace

　・Joint Target→calf_l

　↑この場合は左足ですので、右足も間違えないように左右対称になるように設定してください。

　先ほども言った通り、「foot_l」は人体で言う「左すね」のボーン、「calf_l」は「foot_l」の親ボーンで、人体でいう「左ふともも」のボーンだと思ってください。

　↑グレイマンでいうと「calf_r」は、ちょうどここに位置するボーンになります。

　次に「ボーンをトランスフォーム(修正)する」を選択し、同じく詳細欄から以下のように設定します。

　・Bone to Modify→pelvis

　・Translation Mode→Add to Existing

　「pelvis」というボーンは、全ての親のボーン(rootボーン)の一つ下に位置する子のボーンで、MMDでいう「センター」に位置するボーンだと思ってください。

　今度は、「Two Bone IK」の「Effector Location」の上で右クリックをし、「構造体ピンを分割」を選択します。
　これを行うことで、3つの座標による数値(Vector)ではなく、一つ一つの数値(float)として設定することが可能です。
　「ボーンをトランスフォーム(修正)する」の「Translation」も同様に分割してください。

　ここからの作業はモデルによって異なる可能性があるので、注意してください。

　ここまで来たら一度、「Effector Location」の設定をいじり、コンパイルしてみてください。足が動くと思われます。
　ここで重要なのはX、Y、Zのうち、「ボーンが真上に動くもの」を左右それぞれで認識しておいてください。

　また、その数値が+か-かどうかも考慮してください。

　↑グレイマンではX軸が真上に動きましたが、左足は+、右足は-でした。

　　※ここで足を曲げた時に変な曲がり方をした場合は、下の「Joint Target Location」の値を変えることで直ります。ここの数値もモデルによってバラバラなので、グレイマンを参考に自分で適切に曲がると思える数値を探してください。できれば左右対称にするとよいです。

　次に先ほどと同様、「ボーンをトランスフォーム(修正)する」の「Translation」の値もいじり、真上に動くものを認識しておいてください。

　↑グレイマンの場合はZ軸になりました。

　ここまでできたら、先ほど認識したそれぞれの軸に変数を追加します。
　変数の名前はそれぞれ「LeftFootIK」、「RightFootIK」、「BodyFix」とし、ピンタイプは全て「float」にしてください。

　また、必要に応じて「*-1」を追加し、値を調整してください。

　式としては「変数が+の時は上に」「変数が-の時は下に」と考えて設定しましょう。

　↑この変数の値をブループリントで取得することで足と体が動きます。

　３．アニメーションブループリントの設定

　いよいよ足を動かすための処理の設定になります。ノードが一気に複雑化するので、気を付けて取り組んでください。

　まず起動しているアニメーションブループリントにて以下のようなノードを組みます。

　↑解説すると、「Cast To」を使用して最初に変数にキャラクターを割り当てる作業になります。
　画像では「ThirdPersonCharactor」となっていますが、これはあくまでグレイマンのキャラクター名なので、他のモデルを使っている方はそのキャラクター名の「Cast To」を使用してください。

　↑余談ですが、変数を新しく追加するときはノードを引っ張ってきて「変数へ昇格」を押す方が、自動的にピンタイプが割り当てられて楽なのでお勧めです。

　次に起動しているアニメーションブループリントにて、関数を作ってください。名前は「FootIK」としておきます。

　今回の足を動かす処理は基本的に全てこの中で行っていきます。

　まずはこのようにノードを組みます。

　↑解説すると、最初に「キャラクターが空中にいるかどうか」を確認しています。
　画像ではそれが変数で表示されていますが、もしそういった変数が無ければ…

　↑こちらでも構いません。
 

　そして、もし空中にいると判定された場合、先ほど設定した３つの変数の値がなめらかに0になるように設定されています。

　この「なめらかに」というのが「Get World Delta Seconds」と「FInterp」を利用したアニメーションで、これを使用することでより自然に見せることができます。

　「InterpSpeed」は画像では15に設定されていますが、3～20ぐらいの間でお好みで決めてください。(数値が少ないほど遅くなります)

　次にまた新しい関数を追加します。名前は「TraceGround」です。

　これは左右で行う同じような処理を、この関数一つにまとめるために使用します。

　↑一応、現時点で用意されている変数も見せていますが、「IsInAir?」と「Speed」はグレイマンに元々入っていたものなので、なくても問題はありません。「ThirdPersonCharacter」もあくまでグレイマンのキャラクター名なので、もし設定してるモデルの名前と違っていたら、ここで変更しておくことをお勧めします。

　そうしたら「TraceGround」を選択した状態で右の「インプット」から「新規パラメータ」を選択します。

　↑そうして、2つのパラメーターを作ります。使用するピンタイプは「Vector」、名前はそれぞれ「Start」と「End」にしてください。

　次にそれに繋げる形で「LineTraceByChannel」を用意します。

　これは「Ｓｔａｒｔ」から「End」までに一本の線を発射して障害物に当たった場合、その障害物の場所やマテリアルなどのデータを取得するものです。

　↑「LineTraceByChannel」の中の「OutHit」を右クリックし「構造体ピンを分割」を選択するとわかる通り、とんでもない情報量です。わーお…。

　では「LineTraceByChannel」は一旦置いといて、次にリターンノードを追加します。

　リターンノードのアウトプットにパラメータを追加します。ピンタイプは「Float」、名前は「HitLocationZ」

　そして最終的にはこのように繋げます。

　↑解説をすると、「LineTraceByChannel」で取得した障害物の座標がZ軸(高さ)だけ取得され、キャラクターのメッシュのZ軸と引き算されたものが外に出ていく、といった感じです。

　また、もうお分かりかとは思いますが「ThirdPersonCharacter」は、あくまでグレイマンのキャラクター名なので、皆さんの画面上では設定してるモデルの変数を繋げてください。


　ここまで出来たら、先ほどの「FootIK」関数に戻り、「TraceGround」関数を貼り付けて繋げましょう。

　では、「LineTraceByChannel」の始まる位置と終わる位置を設定します。「Start」と「End」を「構造体ピンを分割」しましょう。

　今回は左足から行います。まず、X軸とY軸の位置は最初に追加したソケットの位置を割り当てます。

　「GetSocketLocation」も「構造体ピンを分割」し、「InSocketName」を「LeftFootSocket」にし、ターゲットをキャラクターのメッシュに当てます。

　↑Z軸に関しては、これはモデルの足の長さや等身で変わってきますが、目安としては膝小僧の高さをスタートとしキャラクターの足裏を中心として地面と対照的な長さになるようにするのが最も使いやすいかと思われます。

　今回は後々編集をしやすいようにキャラクターの当たり判定(カプセルコリジョン)から取っています。

　これに右足も組み込むと、このような形になります。「TraceGround」関数をコピーしましょう。

　↑「GetSocketLocation」の「InSocketName」を「RightFootSocket」にするのも忘れずに！

　さて、この後はようやく変数の設定になります。先に「BodyFix」の値を設定していきます。
　先ほどの「Get World Delta Seconds」も繋げつつ以下のように設定します。

　↑解説をすると、まず右と左、どちらの位置が高いかを調べ、低い方の足に合わせて「BodyFix」が下がるようにします。それを「FInterp」でアニメーションを加えることで、より自然に見せます。

　次に左右2つの「FootIK」の設定になります。
　計算された「BodyFix」の値を正の数に変え、それぞれの位置を足した数値をそれぞれの「FootIK」に繋げます。

　↑もちろんこの時も「FInterp」を活用します。

　これで終わりかと思いきや、まだ少し作業が残っています。

　その作業とは、反対側の足を0の値に戻すという作業です。こちらもしっかり「FInterp」を使用していきます。

　↑文字をよく見るとわかる通り、一つ手前の変数は逆の足となっているので気を付けてください。

　４．仕上げ

　では、イベントグラフに戻り、完成した「FootIK」関数を「Update Animation」に接続し、いざキャラクターを動かしてみると…？

　↑足はちゃんと動いているものの若干ズレてしまっています。モデルによってはこのズレがもっと大きくなってしまっているかもしれません…。

　これは、以下のように「実際にプレイしながら、目視で「AnimGraph」で微調整する」という方法で対処することになります。

　↑モデルによっては数値を掛けたり割ったり…、納得のいく足の位置になるまで根気よくコンパイルを続けてください。

　５．結果

真機 械@MABOMEKA_MAIN 

どんなキャラクターで同じノード組んでもなんかうれしくなっちゃう…。 #UE4 https://t.co/EsDNkYpoz7

2020年05月14日 23:56

　いかがでしたでしょうか。
　実はこれに似たシステム、最近だとゲームフリーク開発の「ポケットモンスター ソード・シールド」や任天堂開発の「あつまれ どうぶつの森」でもよーく見るとこっそりと使われていたりします。(ちなみに私が今回参考にしたのは、フロムソフトウェア開発の「ダークソウル」です)
 

　もし、「上手くできない…」や「ちょっとよくわからない…」「ちなみに好きなゲームは？」「今日の朝飯は？」「君可愛いね？いくつ？どこ住み？趣味は？会える？彼氏いる？てかLINEやってる？」など、何か気になること、質問、感想などがあれば、是非コメントに書き込んでくださると、答えられる気があったら答えます。

　もしいろいろな方に感想をもらって私のモチベが上がったりなどで続けられるのであれば、次回は足首の傾きなども紹介していこうかなと思います。

　では、今回はこの辺で…。

　ゲーム製作や小説書き、イラスト作成などを趣味としている真機械と申します。

　この度、こちらのAmebaにて本格的にブログを開設いたしました。

　理由としては、メインで活動しているTwitterにて、たまに自分用のメモや作品の感想、プログラムの仕組みなどを書いたりしているのですが、ご存じの方もいる通り、Twitterでは基本的に長文は書けないので、よりちゃんとした文章を自分なりにしっかりと残しておきたいという意図があったからです。
　また、一応小説を書くサイトとして私が利用している「小説家になろう」や「カクヨム」にもブログと似たような同様の機能がありますが、そこでは基本的に小説のことに限定したような内容しか書けない上、画像を貼ったりするのが基本的に難しいというのもあったりします。

　もともとこのAmebaにはアカウント登録自体はしていたのですが、ずっと他者のブログを読むことを重視していました。しかし、上記のような出来事もあり、この際だから始めてみようか…ということになったわけです。
 

　さて、ここからは初めましての方々にはつまらない内容の話になってしまうかもしれませんのでご了承ください。


　今回、このブログを始めるにあたり、今までの活動からの変更事項を書き込んでおきます。

　・まず、先ほど言った「小説家になろう」と「カクヨム」におけるブログに似た機能については、今後から更新しないようにいたします。ただし、文章自体は残しておくので、興味がある方はぜひ閲覧してみてください。
　・Twitterでの活動は基本的には変わりませんが、こちらのAmebaにて何か書いた際には「こんなブログ書いたよー」という内容のツイートをいたします。また、メインでの活動がTwitterであることも基本的には変わりません。(口が悪いので、そういうのが苦手な人は見ることをお勧めしません)感想なども、これからはTwitterではなくこちらのブログに書き込む予定です。


　それでは、よろしくお願いいたします。