＜前文＞
Juliaと言うプログラミング言語
Convolutionって複雑過ぎて困惑するって意味だったような気がするけど、数学の専門用語でもあったような気がします。うん。良く分からない時はgoogleで調べるに限る。と検索したらYouTubeにとても分かり易いConvolutionの解説がありました。そこで使用していたプログラミング言語がJuliaでした。
正直、全く聞いたことがなかったです。
Convolutionの計算よりもJuliaの方に興味が移ってしまい、その後Juliaばかり調べてしまいました。そしたらかなり科学分野のためのプログラミングとしてはかなり良い言語というか、一番良い言語のような気がしてきました。現状では、データサイエンスの分野ではPythonより劣り、統計の分野ではRより劣り、更にlibraryにはバグが存在していると言う欠点があるそうですが、その辺を差し引いてもかなり魅力的な言語に見えます。
Juliaの何処が優れているのかを解説したサイトは結構あるので、それ以外に私が個人的に感じるJuliaを勉強する利点をここに挙げます。
まずこの言語を管理、推進している人達が超一流の科学者たちと言う事です。
現状ではコミュニティが小さいので、質問したら直接、超一流の科学者たちから直に回答が貰えそうです。そういう人たちから直接、科学分野のプログラミングを教わったら、1000倍くらい深く理解出来ますし、早く理解も出来ます。（勿論、正しい質問をする必要はあります。例えば、数値解析で、端っこの計算方法がどう変わるのか分からない、みたいな些細な問題であるけれども重要な問題でもある所も、超一流の科学者たちはどう計算するのが現状では正解と考えられているのかを理由も含めてバチッと教えてくれるはずです。）
次に将来的には「Juliaが出来る ＝ 科学的なプログラミングの専門家」と言う位置付けになりそうだからです。
Python は一般的な言語でもあるので、Pythonが出来るからと言ってその人の科学分野のプログラミングがどこまで信頼出来るのかは全く不明です。Rが出来る人は統計分野では専門家でしょうが、他の科学のプログラミングにどこまで精通しているのかは分かりません。FORTRANはまさしく科学的な計算をするためのプログラミングですが、もう第一線で耐えれる言語ではないと思われます。 つまり今あるどのプログラミングに精通していても、その人が科学分野のComputingに精通している保証は無いんです。
逆もまたしかりで、理系の博士を持っている人が「Pythonが出来ます。」と言ってもどの程度プログラミングの知識があるのか不明です。ほんとに齧った程度の知識しかないかもしれません。Obama元大統領ですら知っていたBubble sortingすら知らないかもです。
Juliaならばこのギャップを埋める事が可能に思えます。「Juliaが出来る ＝ 科学的なプログラミングの専門家」と言う立ち位置に将来的にですが、なりそうです。
それでは今週の勉強を始めます。
＜本文＞
１. 今週の予定
今週も先週のバグを直して、その後11月22日のブログでまとめた、戦闘システムの改善点を直していきます。
1.1 先週のバグの直し
- NPCキャラに付けたPoint lightが昼間は消えるようにする。
- 武器を持った時の戦闘中のアニメーションが素手と同じ。
- AIの勉強を毎週少しだけやる。
- 戦闘時におけるモンスターの選択に幅を持たせるために…。
1.2 戦闘システムの改善点の直し
先週は、11月22日のブログの「2. 今の戦闘システムを見直して問題点やバグを探しまとめます。」の「2.1 戦闘シーンを復習する」で述べられた改善点を直しました。今週は「2.2 戦闘シーン毎の復習」で述べられている改善点を直します。
2. 先週のバグの直し
2.1 NPCキャラに付けたPoint lightが昼間は消えるようにする。
意外ですが、昼と夜の違いを知る方法が分からないです。
のでとりあえず、キャラと話せる状態になるまではpoint lightは消えていてもらって、キャラと話せる時だけ光るようにします。
最近知ったのですが、Targetには一つ以上のobjectを繋げられます。便利ですね。
テストします。
NPCに近づくと光ります。
離れるとNPCは光りません。
よくよく考えるとランプでも持っていないNPCが光るのはオカシイですし、こっちの方が正しい気がしてきました。これでOKとします。
2.2 武器を持った時の戦闘中のアニメーションが素手と同じ
はい。プレイヤーが操作するキャラは色々な武器を装備出来ますが、その装備した武器によって戦闘時のアニメーションが変わるのは当然です。現状では、弓を引く動作を素手の攻撃のモーションとして使用しています。全部直しましょう。
2.2.1 アニメーションのチェック
どんなアニメーションがあるのかをチェックします。
弓での攻撃モーションです。
２刀での攻撃モーションです。
魔法杖での攻撃モーションです。
素手での攻撃モーションはありませんでした。
剣と盾の攻撃モーションです。
最後に両手剣での攻撃モーションです。
結構あるのでびっくりしました。素手での攻撃モーションがないのが残念ですね。
2.2.2 モーションの切り替えのチェック
キャラが歩行する時に、装備している武器によって歩行のアニメーションを変えた事を思い出しました。どの様に変更したのかを確認します。
武器が無い時の歩きです。かなり走っています。
武器を持っている時の走りです。両腕の動きが武器が無い時と比較して全く違います。
コードを見てみましょう。
ThridPersonCharacterクラスのmeshを見るとAnim ClassにMyThirdPerson_AnimBPがセットされています。
MyThirdPerson_AnimBPを開くと、武器を持った状態と持ってない状態が別々に設定されていました。
武器を持たない状態のアニメーション。
武器を持った時のアニメーション。
MyThirdPerson_AnimBP内のboolean変数であるWithWeaponがTrueの時は武器持ちのアニメーション、Falseの時は武器なしのアニメーションと言う条件になっていました。
この変数にどうやって外部からアクセスするんだと思ったら、ThridPersonCharacterクラス内で以下の方法でアクセスしていました。
言われてみれば当たり前ですね。
2.2.3 戦闘時の攻撃モーションのチェック
戦闘中の攻撃のアニメーションがどのように実装されているのか確認します。
ThirdPersonCharacterクラス内で実装されていました。
攻撃の条件の時に、ある攻撃モーションを実行します。
2.2.3 戦闘時の攻撃モーションの直し
今週は簡単な対症療法で直します。2.2.4に根本的な直し方を示します。
武器を装備していたら、剣盾装備のアニメーション、装備してなかったら今までのアニメーションを流します。
テストしてみます。
武器を装備させた状態で攻撃します。
剣盾装備のモーションで攻撃しました。
武器を外した状態で攻撃します。
素手の攻撃モーション（実際は素手の攻撃モーションはないので、弓の攻撃モーションで代用）で攻撃しました。
出来ました。
2.2.4 戦闘時の攻撃モーションの根本的な直し考察
今週はやりませんが、戦闘時の攻撃モーションは根本的な直しが必要です。以下の問題を抱えています。
- 攻撃モーションの管理にAnimationBPを使用していない。
- 攻撃モーションは、弓、二刀、魔法杖、剣と盾、両手剣、そして素手があるのにそれらの区別を装備する時にしていない。勿論、攻撃時のモーションでも区別していない。
これらの問題を直さなければなりません。来週以降、直していきます。
2.3 AIの勉強を毎週少しだけやる
これはバグと言う訳ではありません。先週、モンスターが攻撃の選択が出来る様にUE4_AIを少し勉強しました。
多分、先週勉強した分で、モンスターが自分で攻撃の選択が出来る様なAIの作成は可能だと思えますが、BehaviorTreeのDecoratorの種類とか、Taskの種類とか知らない事がいっぱいあるのでその辺を勉強したいです。
今週は、公式サイトのBehaviorTreeを読む事にします。
今、最初のBehaviorTreeとBehaviorTree Quick Start Guideだけ読みました。以下に感想をまとめました。
- BlackboardをAIの脳と説明しているのは…。かえって混乱を生むのでは。
- DecoratorとTaskのそれぞれのノードの解説はBehaviorTree Node Referenceをみれば良いみたいですね。
残りは暇なときに読んでいきます。
2.4 戦闘時におけるモンスターの選択に幅を持たせるために…。
モンスターが選択出来る攻撃の種類を増やさないとモンスターの戦闘時のAIの作成はこれ以上は作成出来ません。
戦闘時に、ユーザーが操作出来るキャラが、攻撃、魔法、アイテム、そして「逃げる」から選択出来るので、同様にしようか迷っています。
アイテムはどうすべきでしょうか？
持っているアイテムは敵を討伐したら貰えるのでしょうか？
魔法だって、以下に示したように、EnemyMonsterInfoではMPの変数は作成していません。
作り直すのは大変です。
更にUE4_AIは、結局if節のSyntactic sugar ですし、単純なヤツならBehaviorTreeを使用しない方が分かり易い気もします。
色々考えましたが、結論が出ましたので以下にまとめます。
- モンスターも攻撃、魔法、アイテム、そして「逃げる」が使用出来るように作り直します。
- ただし、今回は、あくまで戦闘時にモンスターのAIが選択を出来るのかどうかを試すだけなので、作り直す前に、攻撃A、攻撃Bの二つを作成してそれからAIに選択させるようにします。
- その結果を見てから、また考える事にします。
今週のバグの直しは以上です。
3. 戦闘システムの改善点の直し
11月22日のブログの「2. 今の戦闘システムを見直して問題点やバグを探しまとめます。」の「2.2 戦闘シーン毎の復習」で述べられている改善点を直していきます。
3.1 戦闘マップへの移動
3.1.1 捕まったモンスターによって戦うモンスターが変わるようにする
いきなりかなり難関な問題です。モンスターの出現は現在、UE4C++のRPGGameModeBaseクラス内のBeginPlay()関数内で初期化されています。
で作成しています。
発生するモンスターの種類はMonsterToSpawn変数で指定しています。
MonsterToSpawn変数の中身は、RPGGameModeBaseBPのMy Monsterで指定しています。
この場合はMonsterBPを指定しています。
MonsterBPを開くとMeshがcomponentとして使用されており、
そのメッシュにSkeleton_Swordmanが使用されていました。
よし、大体分かりました。
Ch4_3Monsterクラスから派生したMonsterBPは一種類のモンスターであるSkeleton_Swordmanしか作成出来ないので、MonsterBPと全く同じですが、生成するモンスターだけが違う、MonsterBP2を作成します。
3.1.1.1 MonsterBP2の作成
MonsterBPを複製してMeshのSkeletal MeshにSkeleton Mageをセットします。
Skeleon_Mageには専用のAnimationBPがありませんのでAnim Classにアニメーションをセットする事が出来ません。
Skeleon_Mage専用のAnimationBPを作成します。
3.1.1.2 Skeleon_Mage専用のAnimationBPの作成
Skeleton_SwordmanのAnimationBPであるSkelSwordAniを見てみます。
これしかありません。
Idle/Runの中身は以下の様です。
Speed変数の値はEventGraphで指定されていました。
これならSkelSword1DのMage版さえ作成出来れば後は同じで良いですね。
SkelSword1Dを見てみましょう。
Speedが0の所でIdle、86.25の所でWalk、そして345の所でrunのアニメーションがセットされています。Mageも同じ様に作成しましょう。
Blend Space 1DからSkelMage1Dを作成します。
このMage歩くのアニメーションがありません。浮いているんでしょうか？
仕方がないので、IdleとRunだけセットしました。
今度は、Mage用のAnimationBPを作成します。
AnimGraphから作成していきます。
State Machineを追加して名前をDefaultとしました。Swordman用のAnimationBPとやり方は全く同じです。
Defaultを開いてStateを追加します。名前はIdle/Runとします。
今度はIdle/Runの実装を行います。
今度はevent graphを開いてSpeedの値を設定します。
これで完成のはずです。
試してみます。
RPGGameModeBaseBPのMy MonsterのMonster to SpawnにMonsterBP２をセットします。
勿論、MonsterBP2のMeshのAnimationのAnim ClassにはSkelMageAniをセットしておきます。
Mageは飛んで追いかけて来ました。
成功ですね。
3.1.1.2 戦闘中のアニメーションの変更
現状では、モンスターの戦闘中のアニメーションはRPGGameModeBaseBP内で以下のように管理しています。
これにMageの場合を追加します。
戦闘中のモンスターのアニメーションはUE4_AIで一括で管理するのか、別な関数を作成してそこで管理すべきなのかどうか？それともこのままダラダラ追加した方が結局は分かり易いのか？まだ結論は出ていません。
今回はこのままでやっていきます。
テストします。
Mageが攻撃しているanimationが表示されています。
出来ていました。
3.1.1.3 いろいろなモンスターを発生させるために更に必要な事のまとめ
色々なモンスターを発生させるためには、更に以下の事をやる必要があります。
- モンスターの発生方法の管理をUE4C++で管理しているので、現在、発生出来るモンスターが限られている。
- 発生出来るモンスターの種類が2つしかない。もっと作成する。
今週は「捕まったモンスターによって戦うモンスターが変わるようにする。」はここまでとします。
3.1.2 キャラとモンスターの登場シーンをアニメーション化すべき
これはSkeleton _Swordmanの発生シーンのアニメーションが非常にカッコイイので、これを使用したいと思って追加しました。
今回は戦闘開始時に限定してアニメーションを追加します。
プレイヤーが操作するキャラの方は単純に発生する場所を高めに設定しました。
これで勝手に落下した時のアニメーションを実行してくれるはずです。
モンスターの発生方法ですがSkelSwordAnimのAnimGraphにSpawnを追加し、
その中でモンスターが発生するアニメーションをプレイします。
Idle/Runに移動するための条件は以下の様にしました。
プレイするアニメーションは発生時の一回だけにするために、EventGraph から以下の様にしました。
これで戦闘開始時にそれぞれのキャラの出現アニメーションが流れるはずです。
テストします。
両方とも動きが速過ぎて、中々スクリーンショットが取れませんが、結構いい感じで出現しています。後でparticle effectを追加すれば更に見栄えが良くなりそうです。
3.2 戦闘開始前
戦闘開始前の改善点を直していきます。
以下の指摘がありました。
3.2.1 タイプライター効果の追加
これは先週も述べましたが、次のプロジェクトでVNを作成するのでその時に作ります。今回はやりません。
3.2.2 読みましたボタンを少し遅らせて表示する
これもタイプライター効果がないと意味がないので今回はパスします。
3.2.3 読みましたボタンのデザインの改良
確かに。直す必要がありますね。
以下の様に変更しました。
3.2.4 戦闘中の画面を少し揺らす
Camera Shake ClassというBPクラスがカメラを揺らすために存在しているらしいです。
ここに詳しい解説がありました。
試してみましょう。
まずCameraShakeクラスからMonsterCameraShakeを作成します。
以下の設定にしました。
モンスターが攻撃した時に画面が揺れる様に実装しました。
テストします。
揺れました。攻撃を食らった感じがします。
以下にスクリーンショットを示しますが、揺れた感じは撮れていませんね。
大袈裟に使ったら乗り物酔い見たくなってしまうかもしれませんが、適度に使用する分にはかなり面白い機能です。
3.3 アクションの選択
アクションの選択では以下の改善点を直していきます。
3.3.1コメントの文字が表示された後で「攻撃」「逃げる」ボタンは表示されるべき
これもタイプライター効果を作成しない今回のプロジェクトではパスします。
3.3.2「攻撃」「逃げる」ボタンが枠で囲われているが何のジャンルの枠なのかわからない
直していきます。
それぞれに簡単な説明を追加しました。
攻撃を選択した時です。
道具を選択した時です。
3.3.2 攻撃、逃げるボタンの色がバックグランドの色と同じで見にくいかもしれません
色を変えました。
３.4 攻撃の詳細について
攻撃を選択した後の詳細がない事に対しての改善点です。
3.4.1 攻撃の種類の作成
攻撃の種類について考えましょう。と言う事です。と言っても魔法でも攻撃しているので、肉体を使った攻撃と言う意味です。
まず、アニメーションの種類から考えると、
- 素手
- 剣盾
- 二刀流
- 両手剣
があります。ただし厳密に言えばこれらは、攻撃の種類ではなく装備の仕方の種類です。攻撃の種類とは、例えば素手の場合は、
- パンチ
- キック
- 頭突き
- タックル
が該当すると考えられます。更には、
- 防御
- 防御重視
- 守りつつ攻撃
- 攻撃重視
- 特攻
の様な戦術を主とした攻撃の種類の分類方法もあります。
以下の様に決めました。
素手、剣盾、二刀流、両手剣は装備の段階で選択出来る様にします。武器を何も持っていなければ素手、剣を持っていれば、両手剣、剣と盾を持っていれば剣盾、そして剣を二本持っていれば二刀流が選択出来るようにします。そして選択した装備方法によって戦闘時のアニメーションも変化します。
戦闘の種類は、防御、防御重視、守りつつ攻撃、攻撃重視、特攻の５種類を基本として、
素手の場合は、防御、守りつつ攻撃、特攻の３つから選択、二刀流の場合は、守りつつ攻撃、攻撃重視、特攻の３つから選択の様に戦闘の種類が選べるようにします。
更に戦闘の種類の効果は以下のようにします。
- 防御：ATKの値を30%減らす。代わりにDEFの値を30%増加。
- 防御重視：ATKの値を15%減らす。代わりにDEFの値を15%増加。
- 守りつつ攻撃：そのまま。
- 攻撃重視： DEFの値を15%減らす。代わりにATKの値を15%増加。
- 特攻：DEFの値を30%減らす。代わりにATKの値を30%増加。
これで行きます。ただ実際に実装するのは来週以降にします。
3.4.2 攻撃の対象に自分の選べるようにする。
元々、教科書では、戦闘はチーム戦を主に考えられていたので、攻撃する対象を選択する必要がありました。今回のゲームでは戦闘は常に一対一に変更したので、攻撃対象を選ぶ必要は本当は無いんです。まあ選べるようにしておきましょう。
以下のコードをCombatUIの攻撃ボタンがクリックされた時に発動するeventに追加しました。
テストします。
戦闘時に攻撃を選択すると以下のように自分も表示されますが、何か変ですね。
ボタンのデザインを担当しているwidget、AttackTargetOptionが以下の様になっていました。
以下の様に変更しました。
その結果、以下の様になりました。
取りあえずこれで良いでしょう。
自分を選択した場合のコメント欄のセリフは後で直します。
3.4.3 攻撃対象を選ぶ枠も何のグループを示しているのか不明です。題をつけましょう。
これは既にやりました。
3.4.4 ここでもボタンのデザインは見にくいです。
色を濃くしました。
3.5 今まで選択した内容がコメント欄に表示される
以下の改善点を直していきます。
3.5.1 確認するのが目的ならばユーザーが選択を変更出来る方法を用意すべきでは？
確認のためのコメントをもう一度読んでみます。
特にオカシクはないですね。
ただしユーザーが選択を変更出来るための戻るボタンはあった方が良いですね。後で作成します。
3.5.2 コメント欄の文「“KUMO”は次の行動を決定しました。」は「“KUMO”は貴方の選択に従って次の行動を決定しました。」の方が正確に今の事態を表しているのでは？
直しました。
テストしている時に突然、エディターがクラッシュしてびっくりしました。再現性がない一回きりのクラッシュですがそれでも焦りました。
3.6 モンスターのターン
この辺は考え中です。
3.7 ユーザーの行動１（操作するキャラのアニメーション表示 ）
これは既に直しました。
3.8 ユーザーの行動2（結果の表示）
はい。次に行きます。
3.9 モンスターの行動１(アニメーションの表示)
3.9.1「“ゴブリン”が“KUMO”を攻撃しました。」のコメントを追加する。
このコメントはモンスターの攻撃の種類や戦闘時の選択の種類を増やした後で、AIがそれらのどれかを選択出来るようになった後で追加します。
3.9.2 モンスターにも攻撃だけでなく、魔法やアイテムが使用出来るようにしたいです。
後で作成します。
3.9.3 ここでコメント欄に「“ゴブリン”は決定した行動を実行しました。」「“KUMO”は10のダメ―ジを受けました。」と表示するのが良いのか、画面が切り替わった後で、これらの内容を示すのが良いのかを考える必要があります。
KUMOも同じタイミングで表示されていました。のでこれで良いと思います。
3.10 モンスターの行動2（結果の表示）
はい。
3.11 戦闘の繰り返し
3.11.1 HPが0以下にならないようにする
簡単に直せるかと思ったら、攻撃のダメージを計算しているのは、自作のcombat engine内で、TestCombatActionクラスのTick()関数の実装部をいじる必要がありました。
しかもこれだけいじっただけで、buildに5分位かかります。BPに慣れると、UE4C++で作成した部分や、普通のC++で作成した部分はいじるのが億劫になります。
結果を見ます。
0になっています。
魔法の時も直します。TestCombatActionMagicクラスのTick()関数の実装部に同じコードを追加します。
何で、HPがマックスを超えないようにチェックしているんですかね。回復魔法の作成はまだしてないんですが？
直しました。
バグが一個見つかりました。魔法を使用した時の使用相手が敵しか表示されません。更にボタンの位置も変です。
直しました。
3.11.2 HPの後の：が文字と被っているので直しましょう。
直しました。
こんな方法で指定していました。
この辺ももっと整理しやすい方法で管理したいです。後で直します。
3.12 戦闘の終了
流石にレベルアップの報告機能の作成を今する体力はないです。来週に持ち越します。
4. まとめと感想
もう疲れました。今週はここまでとします。今週中に改善点を直したかったんですが流石に無理でした。
