＜前文＞
＜本文＞
先週、この教科書の勉強が終わったので、今週は総括を行います。４つの観点から語りたいと思います。
１．Amazon Reviewの評価について
何度も書きますが、アマゾンにおけるこの本の評価は星一つです。
幾ら何でも酷すぎます。
書かれているコメントは大体同じで、簡単に言えばサンプルに載っているコードのバグが多すぎてコンパイル出来ない。からの星一つです。
私が全て試した結果、はっきり断言しますが、教科書に載っている全てのコードにバグはありません。全てビルド出来ます。更にビルドしたコードは教科書の説明通りの動作をします。
又、提供されているサンプルコードはUE4.12を使用すれば、全てエディターから開けるので、サンプルコード内にある全てのブループリントやデータテーブルの中身も見れます。
敢えて言えば、
- 使用されている図が間違えている箇所が一つ。
- UE4C++では、説明もなくコードの位置が変わっている箇所が２つ。
- ブループリントでは、教科書の説明通りに最後までやらなくても、正しい結果が出る箇所が一つ。
部分がありましたが、この程度のミスはどの本にもあるでしょうし、教科書の内容を理解していれば、読者が簡単に直せる範囲です。
この本で使用されている専門用語も、Computer Scienceで一般的に使用されている用法に沿って使用されています。（Packt社のあるJavaScript ＋αの本では、関数の事をクラスと呼んでいて、ちょっと目眩が、と言うかこの出版社に対する信用がなくなりました。）
では何が問題だったのでしょうか？
まあ、私には分かりませんが、想定している読者のレベルをしっかり説明しなかった事は良くないと思いますね。
この本は、UE4C++とブループリントの基礎が理解出来ていてかつプログラミングで仕事しているレベルの人がRPGをUE4で作成したい時に読むべき本で、ゲーム制作の初心者向けの本では全くないですから。
２．ゲームにおけるソフトウェアデザインとRPG、そしてこの教科書
何で、私がゲームにおけるソフトウェアデザインに異常にこだわるのかと言うと、ゲームデザインと混同している人が多すぎるからです。
- ソフトウェアデザインは完全にソフトウェア工学の一分野で、大学でコンピューターサイエンスを専攻する人は必ず勉強しなければならない学問の一つです。
- ゲームデザインは、まさしく作成するゲームをデザインする事で、RPGにするのかFPSにするのか、もしくはカードバトルゲームにするのかなどを決定する事を含めてのゲームそのもののデザインです。
ゲームにおけるソフトウェアデザインはNystrom, Robert氏のGame Programming Patterns で全て語られていると言っても過言ではないのですが、私、この本途中まで読んで挫折してしまったのです。
何で言うか、一寸抽象的すぎて読んでいて眠くなってしまいました。のでゲーム制作におけるプログラミングにおいてソフトウェアデザイン的に何が正しいのか、今一分からない状態でいます。例えば、ソフトウェアデザインにおいて、シングルトンは、昔はアリでしたが現状は使用すべきではない。となっていますが、ゲーム制作におけるプログラミングではどうなのか全く知らないです。シングルトンはゲームプログラミングに置いて、非常に強力なツールであると確かソフトウェアデザインのクラスで習った気がするのですが、どうなんでしょうか？
そんな訳で、私は直接ゲームの制作する方法を習う事で、最適なソフトウェアデザインを含んだゲームのプログラミングを覚える作戦を考えました。
結果、
結構勉強になったと思います。
例えばGame Programming Patternsで、ゲーム制作の終盤において、デザイナーがこの武器をもう少し強くしたいと言ってきて、その部分を直してコンパイルしたら一日かかってしまい、ものすごく忙しいのに、全てのプログラマーが何もしないで過ごしてしまったと言う話が、悪い例として紹介されています。そしてこの場合は、キャラクターや武器などのパラメーターをプログラム本体と切り離して設定する事で、プログラミングをコンパイルする必要なしにゲームデザイナーがキャラクターや武器のパラメーターを調節出来るようにするのが好ましいと紹介されています。
紹介されていますが、Game Programming Patternsを読んだだけでは、具体的にどういうプログラミングをすればそれが可能なのかが理解出来なかったです。
この本では具体的な方法でそれを実行しています。そしてそのやり方を教えてくれています。
ウン。かなりそういう意味では勉強になりました。
３．RPGゲームを作成するのに足りない部分
この本の最大の不満がこれです。この本に書かれている事だけでは、RPGゲームの基礎は出来ても、RPGゲームそのものは完成しません。折角ここまで勉強したのでRPGゲームとして完成させたいです。そこでゲームとして完成させるためには何が足りないのか考えてみました。
こんなもんですかね。
逆にこの本で完成している部分を以下に示します。
と思って教科書を見返していたら、何と第一章がそれをまとめている事に気が付きました。
1章はこのブログでまとめていないので、ここで簡単に勉強し直してしまいましょう。
教科書には以下に示した内容がまとめられていました。
- ゲームデザインのための道具(Tools for game design)
- デザインとコンセプト(The design and concept phase)
- ゲームの形状とメカニズムの描写(Describing the game’s features and mechanics)
- 存在するRPGsのトロープ(Tropes in existing RPGs)
- RPGのデザインの概要(RPG design overview)
トロープ(tropes)と言う言葉は初めて知りました。カソリックの典礼に使用される装飾的な文の事を指すらしいです。この場合はどのような意味なのでしょうかね。読んでいけば分かりますね。
＜ゲームデザインのための道具(Tools for game design)＞
この節は、Google ドライブやGoogle docそしてGoogle spreadsheetなどを利用するとゲームデザインを効率的に出来ますよ。と言う内容でした。無視して良いと思います。
＜デザインとコンセプト(The design and concept phase)＞
まず、設計文書(design document)が何であるかとそれの作成について説明されていました。簡単に言えば、設計文書(design document)とは、ゲームのほとんど全てを描写する事です。
例えばRPGの場合は、
- プレイヤーがどのようにゲーム内の世界を歩き回るのか？
- どのようにプレイヤーが敵やNPCと干渉しあうのか？
- どのような戦闘を行うのか？
などです。
今思えば、これって大変重要ですよね。私は一人で作成していますが、ほとんどの場合チームでゲームを作成するはずです。全員がゲームのコンセプトを共有出来なければ何をどう作成すればいいのか分からないですから。
教科書とは関係ないですが、私が考えるRPGゲームのための設計文書(design document)の内訳はこうです。
＜第一段階＞
- コンセプトアートの作成：
- ゲームのアイデアを詰め込んだ一枚の絵を作る。例えば「砂漠に王女が座っている。そしてその隣には黒豹がいる。」とか、「真っ黒な森に一人の騎士が立っている。その騎士は大きな犬を連れている。」とか、「町の内部で希望を失って項垂れている人々の中に真っ赤な頭巾を被った少女が立っている。」みたいな、見ているだけで物語が沸いてくる絵が必要だと思います。
- 戦闘システムの決定：
- 早すぎると思われるかもしれませんが、これを最初から決めておかないとプログラムが書けないと思うんです。別に戦闘システムだけのミニゲームを作成しといて、それと合体させるのもありかと思います。
- 収集アイテムの決定：
- やっぱりRPGゲームではアイテムを収集するのは楽しいです。この要素は絶対必要です。
- 街と世界についての決定：
- オープンワールドで行くのか、箱庭式で行くのか。サイズはどうするのか？
- 街の数は、町の中に武器屋や道具屋はあるの？
- ミニゲームの追加：
- パズルゲームを追加する事でゲームの一本道における退屈さを緩和します。どんなパズルゲームを追加するのかを検討します。パズルゲームそのものは前もって制作していたものを使用します。
- インベントリーシステムの決定：
- これも最初から決定しておかないと後で変えたいとか成り易いと思われます。前に作成したインベントリーシステムと同じにするとかしておかないとグダグダになると思います。
- キャラクターと敵の数：
- これも制限を設けないと数が再現なく増えそうです。
これを考え始めると際限なさそうなので取りあえずここで中止します。1章をまとめた後でもう一度考えてみます。
＜ゲームの形状とメカニズムの描写(Describing the game’s features and mechanics)＞
考えたゲームをどのように実際に作成するかを考えます。特にルールはないですが、考えたゲームを需要なコア事に分割してそれぞれがどのように働くかを考えるのが効率的です。
例えば戦闘システムについて：
- 味方がそれぞれ敵を攻撃する。
- 次に敵が生きていれば、味方を攻撃する。
- 死ぬまで１と２を繰り返す。
- どちらかが、全滅したら戦闘が終了。
ここでアルゴリズム化するのですね。これをRPGゲームを作成しながら考えるのは結構大変ですね。先に考えて作成すべきかもしれません。
＜存在するRPGsのトロープ(Tropes in existing RPGs)＞
さあ、トロープ(tropes)とは何を意味するのでしょうか？読んでいきましょう。
非常に沢山の種類のRPGがありますが、それでもほとんどのRPGが使用している共通の要素が沢山あります。
トロープ(tropes)とは全てに共通するものを意味していたんですね。
教科書では以下の事がトロープ(tropes)と言っています。
- 特性とレベル上げ(Stats and progression)
- 特性とは、HP やMPの事です。
- 正直レベルが上昇する事ってそんなに大事でしょうか？世の中には、死ぬほど努力しても上達しない事はザラにあります。
- クラス(Class)
- 味方なら戦士とかヒーラーとかです。敵なら種族でゴブリンとかになります。
- 特殊能力(Special ability)
- 魔法の事です。
もう作っちゃった後で言うのもなんですが、全てのRPGとの名の元に独創性を殺してしまってますね。この部分から全てのRPGと言ってしまうと、ポケモンみたいな発想は生まれてこないですよね。
＜RPGのデザインの概要(RPG design overview)＞
ここから、本格的なこの教科書で作成する（した）一覧が登場します。ココだけまとめても良かったのですが…
＜設定＞
- このゲームはオープンフィールドです。
- プレイヤーは敵にここで遭遇します。
- 敵を倒す事で、プレイヤーの特性を上昇する経験値を得る事が出来ます。
＜探検＞
- 戦闘中以外は、プレイヤーはやや俯瞰した状態で世界を見ます。
- この状態でプレイヤーはNPCと干渉出来ます。
- 更に、ポーズ画面に移行する事も出来ます。
- ポーズ画面では、パーティのメンバー、道具箱、装備品の管理が出来ます。
言われてみれば、カメラの設定をしっかりいじっていましたね。そんな事、すっかり忘れていましてが、プレイヤーがゲームの世界をどのように見るのかを決定するのかは重要な事ですね。
＜対話＞
- NPCらや物品と干渉する時、対話が開始するかもしれません。
- このゲームにおける対話は、テキストを元に作成しています。
- 対話ボックスはもしかしたら線形で、プレイヤーがボタンを押したら次の会話に進みます。
- もしくはいくつかの選択があり、それぞれの選択によって違う画面に進みます。
この対話(dialogue)の部分は、作成はしましたがどのように使用するのかは理解していませんでした。もう一度復習が必要ですね。
＜ショッピング＞
- 店のUIは対話から始まります。
- 例えば、店主がプレイヤーにアイテムを買うかと聞いた所から始まります。
- もしプレイヤーが、ハイと返事をしたら店のUIが表示されます。
- 店の中にいる間、プレイヤーはNPCからアイテムを購入出来ます。
うーん。店の所はよく覚えていますが、こんな感じでは作成していないですね。
まず、プレイヤーが店主に近づいて、Eを押す事で店主と会話します。
あれ、言われて初めて気が付いたけど、しっかり質問に対して選択出来るUIになっていますね。
Talkなんで押したことなかったけど、会話になっているのでしょうか？
なってた。
中身はこうなってました。
NPCDialog変数内に店主の会話が保持されていますね。
ただNPCDialogそのものが何なのか覚えていません。教科書で調べて見ると、NPC_Parent内で作成した変数のようです。
何でパブリック変数になってるの？
それは置いておいて、教科書にバッチリとNPCの会話はこのBPクラスが一括で管理する。
そのほうが、NPCの会話の全てを一括で管理出来るから便利です。と書かれていました。
うーん。これはソフトウェアデザインの見地から言えば、かなり大切な事でしょう。
すっかり見落としていました。
まだまだこの教科書から学ぶ事は多そうですね。
＜ゴールド＞
戦闘で敵を倒す事でゴールドを得る事が出来ます。
前節でkindleの検索機能が滅茶苦茶、便利な事に気が付きました。
どんどん使用して行きましょう。
この教科書内でgoldで検索をかけると、まず最初にPause_MainウィジェットでGoldを使用しています。
GoldのText Block、Get Editable Gold Text 0にバインドしている関数を見てみると、
RPGGameInstanceクラスにある変数、GameGoldから値を得て表示しています。
何処かで、このGameGoldを増やしたり減らしたりしているはずですが、RPGGameInstanceクラスからは追えませんね。
いつもなら、論理性と記憶から戦闘の最後にGoldを増やして、店の買い物で減らすはず、と推測してその辺りのコードをみますが、ここは素直にKindleの検索結果の続きを見ましょう。
次にGoldをコードに追加しているのは、第7章のGold…ですね。
題からすれば当たり前かもしれませんね。
EnemyInfo.h.クラスに敵を倒した時に得られるGoldの値を保持するための変数Goldを作成してます。
このままkindleの検索機能を使用してたどって行けば教科書に基づいて作成した機能の全てを網羅する事が出来そうですね。
出来そうですが、今週はここで止めておきます。何故なら、今週はもう一つ話したい内容があって、そっちをやる時間がなくなってしまうからです。
４．UE4を学ぶ時に、それぞれのUE4の機能から学ぶべきか、それともゲームそのものの機能をユニット毎に分割してそれぞれを学ぶべきなのか
この教科書で勉強していて、結構衝撃だったのは、実践的な技術を最初から修得出来る事でした。
特にインベントリーシステムを作成する部分でその傾向が顕著に現れました。
RPGゲームにおいてアイテムの管理は必須です。だから必ずインベントリーシステムは作成しないといけないのですが、どう作成するのが正しいのかは、今まで良く分かりませんでした。
勿論、基本的なウィジェットブループリントの使用方法は理解していますし、UE4C++を使用して直接Slateモジュールを使う方法も勉強しました。しましたが、だからと言って正しいインベントリーシステムを作成出来る保証はありません。
むしろ、自分で勝手に作成すると、大事な要素を抜いて作成したり、効率が凄く悪くなったりする可能性が高いです。
今回、教科書の指示に従って初めてインベントリーシステムを作成したのですが、まずインベントリーシステムを作成するに辺り、必要とされるウィジェットブループリントの知識があまりにも少なくて済む事に驚きました。なんせこの教科書、バインドのやり方から教えているくらいですから。しかし以下に示すように、このウィジェットブループリントの内部のウィジェットに子として他のウィジェットブループリントを貼り付ける事で、アイテムを管理すると言う私の知らないテクニックを使用しています。
正直、AddChildと言うノードの存在なんて完全に忘れていました。こんな大切なノードだったとは。
ここで大切な事は、インベントリーシステムの作成のために勉強した内容はほとんどそのまま他のゲームのインベントリーシステムの作成に使用出来る事です。このAddChildノードを使用してウィジェットブループリントの中のウィジェットに他のウィジェットブループリントを表示する方法は、どのゲームのインベントリーシステムを作成するに当たっても必須でしょう。
考えてみてください。
いきなりインベントリーシステムを作成して下さいと言われて、AddChildノードを使用してウィジェットブループリントの中のウィジェットに他のウィジェットブループリントを表示する方法を思いつく人なんていますか？
1000人に1人ぐらいはいるかもしれませんね。いわゆる天才と言うやつです。
それを、この教科書でインベントリーシステムを勉強した人は、直ぐに思いつくわけですよ。天才と同等の能力を発揮する事が出来る訳ですよ。これが私が実践的な技術が最初から身に付くと言った理由です。
ここからが私が主張したい内容になります。
今まで、私が勉強したUE4の教科書は全てUE4の機能を中心に教えていました。UE4にはこんな機能があります。その機能の使い方がこうです。例えば、UE4にはカメラがあります。カメラの使い方はこうです。UE4にはInputがあります。Inputの使い方はこうです。こんな感じです。もっと言えば、ブループリントやUE4C++も同じといえます。UE4にはブループリントがあります。使い方はこうです。UE4にはUE4専用のC++ライブラリーがあります。使い方はこうです。と
しかしこの本はRPGゲームには絶対に必要な要素があります。例えばインベントリーシステムです。そのインベントリーシステムはUE4ではこう作ります。と教えています。
前者はUE4が中心にありますが、後者はゲームの制作が中心でUE4はそのために仕方なく使用する道具と言う位置付けになります。
どっちの方法で勉強した方が速くUE4の使用方法をマスターできるのかと言うのが私のここで問いたい事です。
一見すると前者の方法と思われますが、実際は後者の方法のほうが速くUE4の使用方法をマスター出来る気がします。更に言えば後者の方法ならば、学習者の能力がそんなに高くなくても、非常に優秀な人と同様の成果を出せると考えられます。
しかし読者の中には反対の意見を持つ人もいると思います。反論の一つで大変、その通りだなと思った内容を一つだけここで紹介します。
- いきなり、ゲームの作成方法から教えると、初心者はついてこれない。UE4にある機能をそれぞれ教える方法しか初心者は理解出来ない。この本のreviewをみれば分かるが、実際、この本で勉強した初心者は理解出来ていない。UE4の基礎を理解した人だけがゲームの作成方法から教える方法で勉強できる。
うーん。この反論も正しいですね。しかし私としては、ゲームの作成方法からUE4の使用方法を学ぶ学習方法も捨てがたい魅力があると思います。この分野は単純に白黒で分けれる分野ではないのかもしれません。もっと実際に試してみる事や考察したり改良したりする必要があるのかもしれません。
更に踏み込んで言えば、初心者がどの程度の能力の持ち主なのかも関係していると思われます。初心者がプログラマーなのか、デザイナーなのかでも変わってくると思われますし。
